Daily Archives: February 18, 2013

3.7.h Implement and troubleshoot other features

3.7.h [ii] BGP synchronization

this is arguably the best definition i have yet read concerning sync in bgp, until the very end..

ccie quick ref guide pg 83

For an iBGP route to be added to the BGP table, the exact prefix must be in the routing table from an IGP.
The synchronization rule is a method that guarantees that a route is known to all routers within the AS even if they are not running BGP. If a route is advertised via iBGP and a non-BGP router sits logically between the BGP peers, the non-BGP router will black hole the traffic because the destination is not known via IGP first. The synchronization check can be turned off (and is by default as of IOS version 12.2(8)T) with the router configuration command:

Router(config-router)# no synchronization
If disabled, it must be guaranteed that a routing black hole exists within the AS by creating a full-mesh iBGP network or using a BGP tool such as route reflectors or confederations.

read that last sentence again… the opposite, i believe is true… if synchronization is to be turned off, it must be guaranteed that a routing black hole DOESN’T exist…

another ccie quick ref boo boo…

i found this, this morning…

Feb 18, 2013 4:56 AM

arteq

1,162 posts since
Sep 11, 2011

i use anki… one of the dangers of anki is programming yourself with long term misinformation…

CCIE Routing and Switching v4.0 Quick Reference, 2nd Edition

pg 17

Alternative port: This port role is new to 802.1w and is a quickly converging backup port to the current DP on a segment.

Backup port: This port role is new to 802.1w and is a quickly converging backup to the root port for a system.

these are backwards… i looked for errata at ciscopress but found none…

from wendell in ccie r&s pg 86:

The Alternate Port concept is like the UplinkFast concept—it offers protection against the loss of a switch’s RP by keeping track of the Alternate Ports with a path to the root. The concept and general operation is identical to UplinkFast, although RSTP might converge more quickly via its active messaging between switches.

The Backup Port role has no equivalent with Cisco-proprietary features; it simply provides protection against losing the DP attached to a shared link when the switch has another physical port attached to the same shared LAN.

and scott morris from here:

https://learningnetwork.cisco.com/thread/5994

Backup port = Backup to same segment (non-designated)

Alternate port = Alternate port to different segment towards root (non-root)

So by that logic, the backup port cannot guarantee it will have a better path towards the root.  While it may become the path of choice, the first choice is actually the alternate port.  (2nd place to root port)

and from here:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#roles

This distinction is already made internally within 802.1D. This is essentially how Cisco UplinkFast functions. The rationale is that an alternate  port provides an alternate path to the root bridge and therefore can replace the root port if it fails. Of course, a backup port provides redundant connectivity to the same segment and cannot guarantee an alternate connectivity to the root bridge. Therefore, it is excluded from the uplink group.

 

3.6.d Implement and troubleshoot network types area types and router types

this is a nice run around… best bet here is that type 4 lsa’s are filtered, or not allowed into stub areas… the ccie quick refererence guide v4.0 however implies that they are… i like to think of type 4 as simply a pointer to the asbr, like it or not that’s how i keep that friggin one straight… and as such, we know the asbr provides redistribution or external routes, type 5’s… since a stub area cannot possibly have type 5’s then it makes sense that the type 4’s are also excluded… however…

pg66 ccie quick reference guide 4.0

Stub area: A stub area is an area that does not permit the advertisement of type 5 (external) LSAs. Instead, these LSAs are replaced with a default route advertisement. Type 3 and 4 advertisements are sent into the area from the ABR. Stub areas are used when all traffic destined to an external network would travel through an ABR. A default route accomplishes this while saving resources.

i hate when that happens…

our man with the plan ivan p. refutes this below…

http://blog.ioshints.info/

To make it more explicit: the type-4 LSA is the glue that ties together a type-5 LSA originated by an out-of-area ASBR with the ABR flooding type-5 into the area. If there are no type-5 LSAs, type-4 LSAs are not needed (you will also not see them for ASBRs in the same area).

i gotta go with ivan here…

note the graphic below implying type 4’s allowed in the stub area, notwithstanding accept is misspelled…

stub_graphic

3.7.e Implement and troubleshoot scalability

3.7.e [i] Route-reflector, cluster

route reflector rules… this is a tough one…

locally originated and best routes received from ebgp neighbors are propagated to all bgp peers (internal and external)

routes received from an ibgp peer that is not an rr, and best routes, are propagated to all rr clients

routes from rr client and best routes are propagated to all peers…

got that…

3.6.a Describe packet types

3.6.a [i] LSA types [1, 2, 3, 4, 5, 7, 9]

type 6 mospf

type 8 external attributes

opaque’s:

http://tools.ietf.org/rfc/rfc2370.txt

 Opaque
   LSAs provide a generalized mechanism to allow for the future
   extensibility of OSPF. The information contained in Opaque LSAs may
   be used directly by OSPF or indirectly by some application wishing to
   distribute information throughout the OSPF domain.
3.0 The Opaque LSA

   Opaque LSAs are types 9, 10 and 11 link-state advertisements.  Opaque
   LSAs consist of a standard LSA header followed by a 32-bit aligned
   application-specific information field.  Standard link-state database
   flooding mechanisms are used for distribution of Opaque LSAs.  The
   range of topological distribution (i.e., the flooding scope) of an
   Opaque LSA is identified by its link-state type.  This section
   documents the flooding of Opaque LSAs.

   The flooding scope associated with each Opaque link-state type is
   defined as follows.

     o Link-state type 9 denotes a link-local scope. Type-9 Opaque
       LSAs are not flooded beyond the local (sub)network.

     o Link-state type 10 denotes an area-local scope. Type-10 Opaque
       LSAs are not flooded beyond the borders of their associated area.

     o Link-state type 11 denotes that the LSA is flooded throughout
       the Autonomous System (AS). The flooding scope of type-11
       LSAs are equivalent to the flooding scope of AS-external (type-5)
       LSAs.  Specifically type-11 Opaque LSAs are 1) flooded throughout
       all transit areas, 2) not flooded into stub areas from the
       backbone and 3) not originated by routers into their connected
       stub areas.  As with type-5 LSAs, if a type-11 Opaque LSA is
       received in a stub area from a neighboring router within the
       stub area the LSA is rejected.