Route My World!


Archive for the 'BGP' Category

BGP RIB Failure

Posted by Aragoen Celtdra on 1st August 2011

While going through some BGP examples in Routing TCP/IP Volume II, I came across an issue where RIB failures continue to pop up in the show commands. To illustrate see the following topology I recreated from the book (pg 175, fig 3-6 on Routing TCP/IP II book)

sh ip bgp produces the following output with the “r>” indicating that there is a RIB failure in router Vail.

sh ip bgp rib-failure provides a clue as to what caused the RIB failure

Further troubleshooting shows why

Telluride is advertising prefixes,, and via IBGP towards Vail. Vail, however, is also learning these same routes via OSPF through Aspen. As shown in the sh ip route output for one of the routes above, an OSPF advertisement has an AD of 110, whereas an IBGP advertisement has an AD of 200. Even though the routes are in Vail’s BGP table, the OSPF route is installed in the routing table because of lower administrative distance. BGP then throws a fit because he has the routes in his table and the router ignored him. 😉

This is normal operation for BGP. In fact, even though Vail does not use the route via BGP it is not suppressed or thrown out. If you check the ip routing table in Taos, you’ll see that BGP is sending these same routes from Vail. So at least BGP is happy there

Posted in BGP | 6 Comments » | Print This Post


Posted by Aragoen Celtdra on 25th May 2011

I’m starting to contemplate taking the CCIP track. I’ve been having a lot of fun with MPLS and BGP lately that I have  this compelling urge to go all the way with the IP track. The only thing that really holds me back is QoS. LOL! For some weird reason, QoS can’t seem to sit well with me. I don’t think it’s way more complicated than either MPLS or BGP, in terms of understanding the concepts. It’s just that it doesn’t seem to arouse interest in me. But then again, frame relay used to suck for me, but now we’re coo. 😉

So CCIP or not? If I do, it would push back my goal of getting the CCIE R&S. On the upside, I’ll probably know BGP well enough to get it out of the way in my CCIE studies. MPLS doesn’t go much in depth in CCIE R&S but taking the CCIP MPLS exam should give me that much more command of the technology.

We shall see where it leads me. For now, to more MPLS fun…

Posted in BGP, CCIP, MPLS, QoS | 7 Comments » | Print This Post

BSCI Exam Resources

Posted by Aragoen Celtdra on 24th March 2009

While trying to organize the multitudes of Cisco documentation web links I’ve accumulated over the past year, I re-discovered these links that I dismissed as trifle information back when I first came across them. I guess I felt that way then because I didn’t consider the information lengthy enough to contain comprehensive theoretical background:

But while looking over some of the FAQs contained in them, I was surprised to discover how many of the very same questions appeared on the BSCI exam (albeit worded and used on the exam a little differently – but the same information nonetheless).

In my opinion, in order to get the most out of the FAQs, you’ll have to thoroughly understand the theories behind each technologies first – this is done by reading your theory books. Once you understand the general makeup and operation of the protocols, the FAQs can serve as review questions that  can be used to verify how much of the details you can remember. The way I would use them in the future is to categorize each protocols, copy the questions into a set of index cards/flash cards (or something similar) and drill myself until I’ve memorized the information.

Posted in BGP, BSCI Exam Prep, CCNP, EIGRP, Hot Links, Multicast, OSPF, Resources, Routing Protocols, Study Strategy | No Comments » | Print This Post

BSCI: BGP Attributes III

Posted by Aragoen Celtdra on 19th December 2008

Local Preference Attribute

  • Local preference is a well-known discretionary attribute that tells the routers in an AS which path is the preferred path to exit the AS.
  • If an internal BGP speaker receives a multiple routes to a destination, the router compares the LOCAL_PREF attribute of the routes.
    • The path with the higher local preference is chosen.
  • Local preference is exchanged only among routers in the same AS, among internal BGP neighbors; it is not passed to other autonomous system (ie other EBGP peers).

  • In the figure above, AS100 receives advertisement for network from two different points.
  • As Router A receives the advertisement from Router C, Router A sets the LOCAL_PREF to 50.
  • Likewise, when Router B receives the advertisement to the same network (, Router B sets the LOCAL_PREF to 100.
  • These local preference values will be exchanged between IBGP neighbors, Routers A and B.
  • Based on the higher value LOCAL_PREF for Router B, Router B will be use as the exit point for AS 100 to reach network in AS 200.

Multi-exit Discriminator (MED) Attribute

  • Whereas the local preference attribute affects traffic leaving the AS, The MED attribute influences incoming traffic.
  • Also called the metric. A lower metric is preferred. As is true with most “metrics”, the lowest metrics means the shortest distance, and thus the preferred one.
    • MED is set to 0 (zero) by default.
  • This attribute is carried in EBGP updates and allows an AS to indicate to another AS its preferred incoming points.
  • By default, a router compares the MED attribute only for paths from the neighbors in the same AS.
  • The MED is exchanged between two directly connected autonomous systems only.
    • MEDs are not passed beyond the receiving AS.

  • In the Figure above,  a subscriber in AS 200 is dual-homed to a single ISP (AS 100).
  • Within AS 100, IBGP is being used between the routers. The MEDs from AS 200 are exchanged between these internal peers so that they both know which route to prefer.
  • MEDs also do not go past beyond the receiving AS. IF AS 100 advertises to another AS, for instance, it does not pass along the MED set by the originating AS; AS 200 in this case.
  • Additionally, MEDs are not compared if two routes to the same destination are received from two different autonomous systems.
    • For example, is advertised from AS 200 and another AS, the MEDs are not compared.
    • MEDs are meant only for a single AS (with multiple entry point) in order to compare which entry point to prefer.

Community Attribute

  • Communities are optional transitive attributes that is designed to simplify policy enforcement. It is one way to filter incoming or outgoing routes.
  • BGP communities allow routers to tag routes with a community indicator and allow other routers to make decisions based on that tag.
    • It Identifies a route as a member of some community of routes that share some common properties.
    • An example might be an ISP that assigns a particular COMMUNITY attribute to all of its customers’ routes. The ISP may then set its LOCAL_PREF attribute based on the COMMUNITY value instead of basing it on each inidividual route.
  • The community attribute was originally a Cisco-speficific attribute. But now a RFC standard through RFC 1997.

Weight Attribute (Cisco Only)

  • The weight attribute is a Cisco-specific attribute.
  • It is configured locally on the router and is not communicated or propagated to other routers.
  • The weight ha a value between 0 to 65,535.
    • By default, all routes generated by the local router have a weight of 32,768.
    • All routes learned from a peer have a weight of 0.
    • The higher the weight, the more preferable the route.
  • The weight attribute applies when using one router with multiple exit points out of an AS.
    • Contrast it with the local preference attribute where it is used when two or more routers provide multiple exit points.

  • In the figure above, Router A receives an advertisement for network from Routers B and C.
    • Router A knows about more than one route to the same destination.
  • The route coming from Router B has an associated weight of 50.
  • The route coming from Router C has an associated weight of 100.
  • Both paths for network will be in the BGP routing table, with their respective weights.
  • The route with a higher weight will be installed in the IP routing table.


  1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
  2. RFC 4451 – BGP MULTI_EXIT_DISC (MED) Considerations
  3. RFC 1997 – BGP Communities Attribute
  4. RFC 1998 -An Application of the BGP Community Attribute in Multi-home Routing

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | No Comments » | Print This Post

BSCI: BGP Attributes II

Posted by Aragoen Celtdra on 18th December 2008

AS-Path Attribute

  • Whenever a route update passes through an AS, the AS number is prepended to that update when it is advertised to the next EBGP neighbor.
  • The AS-path attribute is the list of AS numbers that a route has traversed to reach a destination, with the number of the AS that originate the route at the end of the list.
  • The AS-Path attribute avoids routing loops by the local AS simply rejecting any route object that contains its own AS in the AS_PATH attribute.
  • The BGP system prefers the route object with the shortest AS_PATH attribute length.

  • In the above figure, AS1 originates a network and advertises it to AS2 and AS3. AS1 adds its own AS number to the AS_PATH.
  • AS2 and AS3 learns of the route with an associated path vector of <AS1>.
    • AS2 advertises the route to its neighbor AS 4. AS2 prepends its own AS number to the AS_PATH.
    • AS3 advertises the route it learns from AS1 to AS5. AS3 prepends its own AS to the AS_PATH.
  • AS4 learns of the route from AS2 with an associated path vector of <AS2, AS1>.
  • AS 5 eventually learns two paths to
    • One with a path vector of <AS3, AS1>
    • Another with path vector of <AS4, AS2, AS1>
  • AS5 will select the shortest path to reach This path is the one that goes though AS3 –> AS1.
    • This path that AS5 chose will also be advertised to its adjacent AS peers.
  • Loop prevention mechanism on BGP will not allow AS5 to advertise the same path to AS1 because AS1 is already in the path vector.

Next-Hop Attribute

  • The next-hop attribute indicates the next-hop IP address to reach a destination.
  • The next-hop IP address is not always the address of a neighboring router.
    • For EBGP, the next-hop is the IP address of the neighbor that sent the update.
    • For IBGP, it stipulates that the next hop advertised by EBGP should be carried into IBGP.
      • It is not necessarily the connected IGP neighbor that is advertised as the BGP next hop address.

Example 1

  • Consider the diagram above, Router B learns the network from Router A, with the next-hop IP address of Likewise, A uses as the next hop IP address to get to
  • Because the rule for IBGP states that the next hop advertised by EBGP should be carried into IBGP, Router B advertises to its IBGP peer Router C the network, with the next hop of (not as we’re accustomed to seeing in the IGP world).
  • It is important that Router C knows how to reach the subnet, otherwise packets destined for could be dropped.
    • Router C can learn about network by IGP or static route.
  • An IGP uses the IP address of a routing update (route source) as the next-hop address.
  • BGP uses a separate field for each network to record the next-hop address.
  • IBGP neighbors use recursive lookup to reach BGP next-hop address by using its IGP entries in the routing table.
    • Router C learns about from Router B (route source with Router A ( as the next hop.
    • Router C, therefore, installs the route to in the routing table with a next hop of
    • With Router B using an IGP to announce network to Router C, Router C also installs in its routing table with a next hop of
    • When Router C sends a packet to a destination in the network, it looks up the network in the routing table and finds a BGP route with a next hop of
    • Because it is a BGP entry, Router C completes a recursive lookup in the routing table for a path to network
      • There is an IGP route to network in the routing table with a nesxt hop of
    • Router C then forwards the packet destined for the network to

Example 2: Next-Hop Attribute on Multiaccess Network

  • In the above diagram, Routers B and C in AS 65000 are running an IGP.
    • Router B can reach network via
    • Router C can reach network via
  • B and C are also running IBGP between each other.
    • Router B is running EBGP with Router A.
    • Router C is running EBGP with Router D.
  • When B sends a BGP update to A about, it gives (Router C) as the next hop, and not it’s own address.
    • This feature is called a third-party next hop.
      • A BGP speaker can advertise to an external peer an interface of any internal peer router in the next hop component, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. – RFC 2858.
      • It basically means that in a multi-access network, a BGP router can use the a next hop address that is not necessarily its own, by changing the next-hop attribute, in order to avoid inserting additional hops into the path.
  • In the scenario above, If Router A needs to send update to AS 64600, Router B tells Router A to install the AS 64600 networks with next hop address of (Router C)
    • To get to AS 64600, Router A must go through AS 65000.
    • Router B advertises AS 64600 networks to Router A because they have neighbor relationship. But because Router B does not handle traffic to AS 64600, and Router C has neighbor relationship with Router D in AS 64600, Router B tells Router A to get to AS 64600 through Router C. This is of course dependent on Router A and C being on the same subnet.

Example 3: Next-hop Attribute on NBMA

  • In the above figure, Routers A, B, and C are connected via Frame Relay.
  • Router B has a Frame Relay map entry for Router C, therefore it can reach network, using as the next hop address.
  • Router B, with a an EBGP neighbor relationship with Router A, sends a BGP update to Router A about, using as the next hop address.
  • A potential problem can occur if there is no way for Routers A and C to communicate directly because of missing Frame Relay map entry to each other.
    • One solution, of course, is to add a Frame Relay map entry between the two.
    • Another option is a configuration feature called next-hop-self.
      • This configuration is set on Router B by configuring itself to advertise its IP address as the next-hop attribute.

As mentioned earlier, the IP address of the next-hop is not always the address of the directly attached neighboring router. There are some rules that apply to determining the next-hop address:

  1. If the advertising router and receiving router are external peers (ie they are in different autonomous systems), the IP address of the advertising router’s interface is the next-hop address.
  2. If the advertising router and receiving routers are internal peers (in the same AS), and the destination is withing the same AS, the next-hop is the address of the router that advertised the route.
  3. If the advertising router and the receiving router are internal peers and the destination of the update is in a different AS, the next-hop is the IP address of the external peer from which the route was learned.

Origin Attribute

  • A well-known mandatory attribute that specifies the origin of routing updates.
  • It can be one of three values:
    1. IGP
      • The NLRI was learned from a protocol internal to the originating AS. BGP routes are given an origin of IGP when a network command is used to advertise the route via IGP.
      • An origin of IGP is given the highest preference of the ORIGIN values.
      • An origin of IGP is indicated with an i in the BGP table.
    2. EGP
      • This means that the route is learned from Exterior Gateway Protocol (EGP). This is not supported on the Internet because it only does classful routing and does not support CIDR.
      • This is the next preferred to IGP.
      • Indicated by an e in the BGP table
    3. Incomplete
      • This mens that the origin of the route is unknown or learned by other means.
      • Usually a result of a route being redistributed into BGP, because there is no way to determine the original source of the the route.
      • Lowest preferred ORIGIN value.
      • Indicated by a ? in the BGP table.


  1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
  2. An Introduction to BGP – the Protocol – The ISP Column – Geoff Huston
  3. BGP AS-Path – Cisco IOS Hints and Tricks
  4. RFC 2858 – Multiprotocol Extensions for BGP-4

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | 1 Comment » | Print This Post

BSCI: BGP Attributes I

Posted by Aragoen Celtdra on 17th December 2008

A BGP attribute or path attribute is a characteristic of an advertised BGP route to define routing policies and maintain a stable routing environment

  • Attributes can be:
    • Well-known or Optional
    • Mandatory or Discretionary
  • The path attributes described above fall in four categories:
    • Well-known mandatory
    • Well-known discretionary
    • Optional transitive
    • Optional nontransitive

Well-Known Attributes

  • A well-known attribute is one that all BGP implementations must recognize and propagate to BGP neighbors.
    • Well-known mandatory – must appear in all BGP updates.
    • Well-known discretionary – does not have to be present in all BGP updates.

Optional Attributes

  • Attributes that are not well-known.
    • Transitive – a BGP process should accept the path in which it is included, even if it doesn’t support the attribute, and it should pass the path on to its peers.
    • Non-transitive – a BGP process that does not recognize the attribute can ignore the Update in which it is included and not advertise the path to its other peers.
  • BGP routers that implement an optional attribute might propagate it to other BGP neighbors, based on its meaning.
  • BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
  • BGP routers that do not implement an optional non-transitive attribute must delete the attributes and must pass it to other BGP routers.

Defined BGP attributes:

  • Well-known mandatory
    • AS-Path
    • Next Hop
    • Origin
  • Well-known discretionary
    • Local Preference
    • Atomic Aggregate
  • Optional Transitive
    • Aggregator
    • Community
  • Optional Non-transitive
    • Multiexit-discriminator (MED)
  • Cisco also has its own defined weight attribute for BGP.
    • It is configured locally on a router and is not propagated to any other BGP routers.

BGP Attribute Type Codes

  • Type code 1 – Origin
  • Type code 2 – AS-path
  • Type code 3 – Next-hop
  • Type code 4 – MED
  • Type code 5 – Local preference
  • Type code 6 – Atomic aggregate
  • Type code 7 – Aggregator
  • Type code 8 (Cisco-defined) – Community
  • Type code 9 (Cisco-defined) – Originator-ID
  • Type code 10 (Cisco-defined) – Cluster list


  1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | No Comments » | Print This Post

BSCI: BGP Concepts III

Posted by Aragoen Celtdra on 9th December 2008

Neighbor Relationships

  • BGP Peer = BGP Neighbor.
    • A BGP peer is a BGP speaker that is configured to form neighbor relationship with another BGP speaker for the purpose of directly exchanging BGP routing information with one another.
    • Any router running BGP is a BGP speaker.
  • A BGP router forms a direct neighbor relationship with a limited number of other BGP routers.
    • The Internet represents tens of thousands of autonomous systems. It is virtually impossible for one router to have direct neighbor relationship with all the routers that run BGP.

External BGP Neighbors

  • EBGP – BGP is running between routers in different AS.
  • IGP is not run between EBGP neighbors.
  • In order to successfully exchange routing updates between two routers, TCP on each side must successfully pass the TCP 3-way handshake before BGP session can be established.
    • The IP address used in the neighbor command must be reachable without using an IGP. The best way to accomplish this is:
      • Pointing to an address that is directly connected, which is generally the case.
      • Or, use static routes to that IP address.

Internal BGP Neighbors

  • IBGP – When BGP is running between routers within the same AS.
  • IBGP allows routers within the same AS to exchange BGP information and all routers have the same BGP routing information about the outside autonomous systems.
  • As long as routers can reach each other in order to perform TCP handshake and set up the BGP neighbor relationship, it doesn’t matter how they are connected. They can be connected in by:
    • A directly connected network.
    • Static routes.
    • Internal routing protocol (e.g. RIP, OSPF, EIGRP, etc.)
  • Because multiple paths generally exist within an AS to reach other routers, a loopback address is usually used in the BGP neighbor command to establish IBGP sessions.

IBGP is required on all routers in a transit path in order for IBGP route propagation to work properly.

IBGP in a Transit AS

  • Border Gateway in ‘BGP’ was coined because BGP was originally intended to run along the borders of an AS, with the routers in the middle of the AS ignorant of the details of BGP. But it is no longer the case.
  • Transit AS – An AS that routes traffic from one external AS to another external AS.
    • A typical transit AS is an ISP.
    • In the diagram below, AS 65102 routes traffic from AS 65101 to AS 65103. This makes AS 65102 a transit AS.

  • All routers in a transit AS must have complete knowledge of external routes.
    • In theory, this goal can be accomplished by redistributing BGP into the IGP running on the edge routers.
    • The method of redistributing all BGP routes into an IGP is, however, not good practice. Because the current Internet routing table is extremely large, this method is simply impractical.
  • The more practical method for creating complete transparency for all routing information in an AS is by running IBGP on all routers within the AS.

IBGP in a Nontransit AS

  • Non-transit AS – An AS that does not pass routes between the ISPs.
    • A typical example is an organization that is multihoming with two ISPs.
  • BGP specifies that routes learned through IBGP are never propagated to other IBGP peers.
    • This is a mechanism to prevent routing loops.
    • By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP speakers in the AS. This makes it a full mesh IBGP.
    • The default assumption by all routers running BGP within an AS is that each BGP router exchanges IBGP information directly with all other BGP routers in the AS.
    • In a full mesh, when the BGP router receives a change update from an external AS, that BGP router for the local AS is responsible for updating all other IBGP neighbors of that change. All the other neighbors will not update their other IBGP neighbors because they will assume full-mesh topology, thus, all updates are sent only by the original sending IBGP neighbor.
    • If the sending IBGP neighbor is not fully meshed with other IBGP neighbors, there will be inconsistent routing tables and routing loops or routing black holes can occur.

Full Mesh is when all BGP speakers have a neighbor statement for all other IBGP speakers in the AS

BGP Partial-Mesh Example

  • In this example, when Router B receives updates from Router A, B sends updates to Routers C & D. However, it doesn’t send it to Router E because it does not have IBGP neighbore relationship with E.
  • C & D will not send updates to E because by design, they are expected to assume full mesh neighborship so that B will send the update to E.
  • E does not learn of any networks through B and does not use Router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

BGP Full-Mesh Example

  • The above diagram shows a fully meshed BGP toplogy.
  • When router A sends update to Router B. Router B replicates the updates to C, D, and E.
  • Because Router A and Router E are not directly connected, OSPF (or whatever IGP is running) will be used to route the TCP segment containing the BGP update from Router A to Router E.
  • In a fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

Example: BGP Not in All Routers

  • In the example above, Routers A, B, E, and F are the only ones running BGP.
  • Through an EBGP session, Router A advertises network to Router B. Router B in turn advertises the network to Router E, using IBGP. E advertises it to Router F.
  • If Router F tries to send packets to network via router E, Router E will try to send the packet to its BGP peer, Router B.
    • But in order to reach Router B, the packets must go through Router C or D.
    • Because Routers C or D are not running BGP, they don’t have a route to network Therefore the packets are discarded.
  • Assuming Routers C or D have default routes to the exit points, B and E, when Router E sends the packets to E or D, there is a good chance that C or D will send it back to router E. In turn, router E will resend it back again, eventually creating a loop.
  • In order to solve all these problems, BGP must be implemented on Routers C and D.

All routers in the path between IBGP neighbors within an AS, known as the transit path, must also be running BGP. These IBGP sessions must be fully meshed.

BGP Synchronization

BGP Synchronization Rule

The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP

The synchronization rule is best understood with an example:

  • Consider the following scenario above:
    • In the above picture, Router C sends updates about network to Router A.
    • Routers A and B are running IBGP, so Router B receives updates about network via IBGP.
    • In order for Router B to reach network, it has to send the traffic through router E.
      • Router E has no knowledge of network because Router A does not redistribute network into an IGP that is running between them.
      • Therefore, traffic the Router B sends to network via Router E is dropped.
    • If Router B advertises to AS 400 that it can reach before Router E learns about the network via IGP, traffic coming from Router D to Router B with a destination of will flow to Router E and be dropped.
  • In the above scenario, the synchronization rule states that:
    • If an AS (such as AS 100) passes traffic from one AS to another AS, BGP should not advertise a route (route in this case) before all routers within the AS (AS 100) have learned about the route via IGP.
    • In this case Router B waits to hear about network via an IGP before it sens an update to Router D.
  • There are cases where synchronization can be disabled to allow BGP to converge faster. However, this can result in dropped packets if the following conditions are not met before disabling:
    • Your AS does not pass traffic from one AS to another AS.
    • All the transit routers in the AS run BGP.
  • In the past it was best practice to redistribute BGP into IGP running in an AS.
    • In this case, IBGP was not needed for all routers in the transit path. By default, synchronization was on to make sure packets did not get lost.
  • As the Internet grew, it has become more and more impractical to redistribute every single prefix into the IGP, therefore best practice was changed to not redistributing BGP into the IGP.
    • This required using IBGP on all routers in the transit path. In this case, synchronization was no longer needed. Thus, it is now off by default.

Synchronization Rule

  • Enable synchronization if there are routers in the BGP transit path in the AS that are not running BGP.
    • With synchronization on, BGP should not advertise a route before all routers in the AS have learned about the route via IGP.
    • A router learning a route via IBGP waits until the IGP has propagated the route within the AS and then advertises it to external peers.
  • Disable synchronization if routers in the transit path in the AS are running full-mesh IBGP.
    • With synchronization off, BGP can use and advertise to external BGP neighbor routes learned form an IBGP neighbor that are not present in the local routing table.

TCP and Full Mesh

  • Because of its ability to move a large volume of data reliably, TCP is an appropriate transport mechanism to use for BGP.
  • As opposed to the one-to-one windowing capability of OSPF or EIGRP, TCP allows BGP to take advantage of its unique window scaling capability to handle a huge volume of traffic, such as the Internet routing table.
  • TCP sessions cannot be multicast or broadcast because TCP has to ensure the delivery of packets to each recipient.
    • Because TCP cannot use broadcasting, BGP cannot use it either.

BGP Tables

  • BGP keeps a separate table from the IP routing table.
  • Some of the common nomenclature use to describe the BGP table are:
    • BGP Table
    • BGP topology table
    • BGP topology database
    • BGP routing table
    • BGP routing database
  • The router can be configured to share information between the BGP table and the IP routing table.
  • BGP also has a neighbor table containing a list of neighbors with which it has a BGP connection.
  • BGP adjacency must be configured explicitly for each neighbor. A TCP relationship is formed with each configured neighbor.
    • To keep track of the adjacency state, a BGP/TCP keepalive message is sent every 60sec.
  • After an adjacency is established:
    1. The neighbors exchange the BGP routes that are in their IP routing table.
      • Each router collects these routes from each neighbor with which it successfully established and adjacency and places them in its BGP forwarding database
    2. All routes that have been learned from each neighbor are placed in the BGP forwarding database.
    3. The best routes for each network are selected from the BGP forwarding database using the BGP route selection process.
    4. The best routes are offered to the IP routing table.
    5. Each router compares the offered BGP routes to any other possible paths to those networks in its routing table, and the best route, based on administrative distance, is installed in the IP routing table.
      • EBGP routes have an AD of 20.
      • IBGP routes have AD of 200.

BGP Message Types

  • BGP defines the following message types:
    • Open
      • The first message sent by each side.
    • Keepalive
      • If the open message is acceptable, a keepalive message confirming the open message is sent back by the side that received the open message.
    • Update
      • When the open is confirmed, the BGP connections is established, and update, keepalive and notification messages can be exchanged.
    • Notification
      • These are sent in response to errors or special conditions.

BGP Message Type: Open

An open message includes the following information:

  • Version – an 8-bit field that indicates the version of BGP. The highest common version that both routers support is used. Current version is BGP-4.
  • My Autonomous System – A 16-bit field that indicates the sender’s AS number. The peer router verifies this information; if it is not the AS number expected, the BGP session is torn down.
  • Hold Time – A 16-bit field indicating the maximum number of seconds that can elapse between the successive keepalive or update message from the sender. Upon receipt of an open message, the router calculates the value of the hold timer to use by using the smaller of its configured hold time and the hold time received in the open message.
  • BGP Router Identifier (Router ID) – 32-bit field that indicates the BGP identifier. The BGP router ID is chosen the same way the OSPF ID is chosen:
    1. Statically configured
    2. Highest loopback Address
    3. Highest active IP Address
  • Optional parameters – A length field indicates the total length of the optional parameters in octets. These parameters are Type, Length, and Value (TLV)-encoded.
    • Session authentication is one example.

BGP Message Type: Keepalive

  • BGP does not use any transport protocol-based keepalive mechanism to determine whether peers can be reached.
  • Instead, keepalive messages are exchanged between peers often enough to keep the hold timer from expiring.
    • If the negotiatied hold time interval is 0, periodic keepalive message are not sent.
  • A keepalive message consists of only a message header.

BGP Message Type: Update

  • An update message has information on one path only.
    • Multiple paths require paths require multiple messages.
    • All attributes in a message refer to that path, and the networks are those that can be reached through that path.
  • An update message might include the following fields:
    • Withdrawn routes – A list of IP address prefixes for routes that are being withdrawn from service, if any.
    • Path attributes – The AS-path, origin, local preference, and so forth (will be disussed in next post).
      • The attribute type consists of the attribute flags, followed by the attribute type code.
    • Network layer reachability information – A list of IP address prefixes that can be reached by this path.

BGP Message Type: Notification

  • A BGP router sends a notification message when it detects an error condition.
  • The BGP router closes the BGP connection immediately after sending the notification message.
  • Notification messages include an error code, and error subcode, and data related to the error.

BGP Neigbor States

  • BGP is a state machine that takes a router through the following states with its neighbors:
    • Idle
    • Connect
    • Active
    • Open sent
    • Open confirm
    • Established
  • Only when the connection is in the established states are update, keepalive, and notification messages are exchanged.
  • Keepalive messages consist of only a message header and have a length of 19 bytes.
    • The are sent every 60 seconds by default.
    • Other messages might be between 19 and 4096 bytes long.
  • The default hold time is 180 seconds.


  1. Cisco – Internetworking Case Studies Using the Border Gateway Protocol for Interdomain Routing
  2. Synchronization – Using BGP for Interdomain Routing – Internetworking Case Studies – Cisco

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | 1 Comment » | Print This Post

BSCI: BGP Concepts II

Posted by Aragoen Celtdra on 7th December 2008

BGP Path Vector

  • BGP routers exchange network reachability information, called path vectors, made up of path attributes.
  • The path vector information includes:
    • A list of the full path of BGP AS numbers (hop-by-hop) necessary to reach a destination network.
  • Other attributes include:
    • IP address to get to the next AS (next hop attribute)
    • Information about how the networks at the end of the path were introduced into BGP (origin code attributes).
    • There are other attributes that will be discussed later.
  • The BGP AS path is guaranteed to be loop free.

A router running BGP does not accept a routing update that already includes its AS number in the path list, because the update has already passed through the AS, and accepting it again we result in a routing loop.

  • By applying routing-routing policies to the path of BGP AS numbers, routing behavior can be enforced at the AS level to determine how data will flow through the AS.
    • These policies can be implemented for:
      • All networks owned by an AS.
      • Certain CIDR block of network numbers (prefixes).
      • Individual networks or subnetworks.
    • These policies are based on the attributes carried in the routing information and configured on the routers.
  • BGP can advertise only the routes it uses.

BGP specifies that a BGP router can advertise to its peers in neighboring autonomous systems only those routes that it uses. This rule reflects the hop-by-hop routing paradigm generally used throughout the current Internet.

  • There are some policies that cannot be supported by hop-by-hop routing and thus require other technique in order to implement.
    • One example is that BGP does not allow one AS to send traffic to a neighboring AS with the goal of manipulating the traffic to take a different route from that taken by traffic originating in that neighboring AS.
    • In other words, you cannot influence how a neighboring AS will route your traffic, but you can influence how your traffic gets to a neighboring AS.
  • To illustrate the idea enumerated on the two bullet points above, consider the following example:
    • In the above diagram, AS 64520 advertises to AS 64512 only its best path: 64520 64600 64700
    • This path is the only path through 64520 that AS 64512 sees.
    • All packets that are destined for 64700 via 64520 take this path, because it is the AS-by-AS (hop-by-hop) path that AS 64520 uses to reach the networks in AS 64700.
      • AS 64520 doe not announce any other paths because it does not choose any of the other possible paths as the best paths, based on the BGP routing policy in AS 64520.
    • Even if AS 64512 knows of any other paths through AS 64520 and wants to use it, AS 64520 will not allow the packets to route to any other paths, because AS 64520 selected 64520 64600 64700 as its best path, and all AS 64520 routers will use that path based on BGP policy.
      • BGP does not enable one AS to send traffic to a neighboring AS intending that the traffic take a different route from that taken by traffic originating in the neighboring AS.
    • AS 64512 has an option to use AS 64520 or AS 64530 to reach AS 64700 based on its own BGP routing policies.

When to Use BGP

  • BGP is more appropriate to use when at least on of the following conditions exists:
    • The AS allows packets to transit through it to reach other autonomous systems (for example, it is a service provider).
    • The AS has multiple connections to other autonomous systems.
    • Routing policy and route selection for traffic entering and leaving the AS must be manipulated.
  • BGP allows an enterprise to differentiate between its traffic and traffic from its ISP. Therefore BGP is an option if this differentiation is required.
    • A static route to an ISP will not distinguish whether a certain traffic is from the enterprise or from the ISP.
  • BGP is the protocol that is used to implement an agreement between to or more autonomous systems to exchange updates.

When Not to Use BGP

  • BGP should not be used if the following conditions are true:
    • A single connection to the Internet or another AS
    • Lack of memory or processor power on routers to handle constant BGP updates.
    • Limited understanding of route filtering and the BGP path-selection process.

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | 1 Comment » | Print This Post

BSCI: BGP Concepts I

Posted by Aragoen Celtdra on 4th December 2008

Border Gateway Protocol (BGP)

  • BGP is categorized as an advanced distance vector protocol.
  • It is defined in RFC 4271, A Border Gateway Protocol (BGP-4).
  • It uses Transmission Control Protocol (TCP) as its transport protocol.
    • It uses TCP protocol 179 to deliver BGP information.
    • These TCP segments are carried inside IP packets.
    • By contrast:
      • RIP uses UDP as its transport mechnism
      • IS-IS resides on the network layer.
      • OSPF and EIGRP reside directly above the IP layer.
    • TCP somewhat simplifies the delivery mechanism of BGP by handling acknowledgment, retransmission, and secquencing of packets.
    • TCP uses the concept of sliding windows when handling deliveries of packets. This allows a larger number of update packets to be received at one time. This can be a difference of an OSPF, for example, that will handle routing for 100 subnetsm while BGP can easily handle 200,000 subnets.
      • In contrast with BGP, OSPF and EIGRP use a one-for-one windowing, such as when OSPF or EIGRP has to send multiple packets, the next packet cannot be sent until an acknowledgment from the last packet sent is received.
        • TCP uses a dynamic window, which allows for up to 65,576 bytes to be outstanding before it stops and waits for an acknowledgment.
  • BGP is an Interdomain Routing Protocol (IDRP), which is also an EGP.
  • The main goal of BGP is to provide inter-domain routing system that guarantees the loop-free exchange of routing information between autonomous systems. BGP routers exchange information about paths to destination networks.

Autonomous System

A set of routers under the single technical administration, using an Interior Gateway Protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other [autonomous systems].

-RFC 4271

  • Interior Gateway Protocol (IGP)
    • A routing protocol that exchanges routing information within an autonomous system (AS). Examples are: RIP, OSPF, EIGRP, IS-IS.
  • Exterior Gateway Protocol (EGP)
    • A routing protocol that exchanges routing information between different autonomous systems. BGP is the most predominant example.
  • The Internet Assigned Numbers Authority (IANA) allocates the AS numbers
  • Within IANA, several regional  corporations administer and registers IP addresses and AS for their respective region.
    • African Network Information Centre (AfriNIC) – African continent.
    • Asia Pacific Network Information Centre (APNIC) – Asia/Pacific.
    • American Registry for Internet Numbers (ARIN) – Canada, US, parts of Caribbean and islands in North Atlantic Ocean.
    • Latin American and Caribbean IP Address Regional Registry (LACNIC) – Latin America and parts of the Caribbean.
    • Reseaux IP Europeens Network Coordination Centre (RIPE NCC) – Europe, Middle East, and Central Asia.
  • The AS designator is a 16-bit number ranging from 1 to 65535.

Comparing BGP to Other Routing Protocols

  • Most link-state routing protocols such as OSPF and IS-IS require a hierachical design – it allows a large network to be broken down into smaller networks called areas.
  • EIGRP and BGP do not require a hierarchical topology.
  • Internal routing protocols such as RIP, OSPF, EIGRP, and IS-IS use path costs (quickest path) to get to their destination, using certain metrics.
    • RIP uses hop-counts. The fewer the better
    • OSPF uses cost, based on bandwidth as its metric.
    • IS-IS uses a metric based on bandwidth, which defaults to 10.
    • EIGRP uses a composite metric, with bandwidth and accumulated delay considered by default.
  • BGP, in contrast to the protocols mentioned, does not look at speed for the best path. Rather, it uses multiple BGP attributes to influence traffic flow between Autonomous Systems.
    • BGP-enabled routers use path vectors or attributes – network reachability information.

BGP in an Enterprise Network

  • BGP is more suitable in an enterprise if using multiple ISPs to connect to the Internet.
    • If the enterprise has only one connection to one ISP, BGP might not be the best choice.
  • BGP allows an enterprise with multiple connections to decide the best and optimal path by manipulating BGP path attributes.
  • External BGP (EBGP) – when BGP is running between routers in different AS.
  • Internal BGP (IBGP) – when BGP is running between routers in the same AS.


  • Multihoming is when an autonomous system has more than one connection to the Internet.
  • Typical reasons for multihoming are:
    1. Reliability – If one connection to the Internet fails, the other connection is available.
    2. Performance – By using better paths for certain destinations, performance may be increased.
  • Multihoming can be accomplished with multiple connections to a single ISP or multiple connections to mulitple different ISPs.
  • It is preferable to multihome with multiple ISPs instead of one:
    • It has redundancy with multiple connections
    • It is not limited to the policy of a single ISP
    • Has more paths to the same networks for better policy manipulation.
  • Three common ways to multihome with BGP are:
    1. Passing only a default route to the AS – each ISP passes only defualt route to the internal routers
    2. Passing only a default route + specific routes owned by the ISP – each ISP passes defualt route and their own routes to the AS internal routers, or all internal router in the trqansit path can run BGP and pass routes between them.
    3. Passing all routes to the AS – Each ISP passes all route to the AS, with all internal routers int he transit path running BGP and passing all the routes between them.

Option 1: Only Default Route

  • With this option, a router within an AS learns about multiple default routes – these are routes sent by the ISPs.
  • In this case the local IGP chooses the best default route for this router and installs it to the routing table. From its perspective, the router takes the default route with the least-cost IGP metric.
    • The IGP default route will then route packets destined to the external networks to an edge router of this AS, which is running EBGP with the ISPs.
    • The edge router will use the BGP default route to reach all external networks.
  • For incoming traffic, the decision about which route to take is decided within the ISP
  • Some limitations of this option are:
    • Path manipulation cannot be performed because only a single route is being recieved from each ISP
    • It is extremely difficult to manipulate bandwidth. It can be accomplished only by manipulating the IGP metric of the default route.
    • Diverting some of the traffic from one exit point to another is challenging because all destinations are using the same default route for path selection.

Option 2: Send Default Routes and Partial Routes

  • With this option all ISPs pass default routes and select specific routes to the AS.
  • Generally, the partial routing table that is sent to the AS include the networks that the ISP and its customers own.
  • If an ISP passes the partial route information to a customer, this customer can redeistribute these routes into its IGP. By doing this, packets destined to an outside network can take the nearest exit point based on the best metric of the specific network- as opposed to taking the nearest exit point base on the default route.
  • Routes to other autonomous systems that were not passed by the ISPs are decided by the IGP metric that is used to reach the default route within the AS.

Option 3: Full Routes From All Providers

  • All ISPs pass all routes to the AS, and IBGP is run on at least all the routers in the transit path in the AS.
  • This option allows the internal routers of the AS to take the path through the best ISP for each route.
  • Uses a lot of resources within the AS because it must process all the external routers.


  1. Border Gateway Protocol – Wikipedia
  2. RFC 4271: A Border Gateway Protocol (BGP-4)
  3. RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System (AS)

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

Posted in BGP, BSCI Exam Prep, CCNP, Routing Protocols | 2 Comments » | Print This Post

Thoughts on family and… routers

Posted by Aragoen Celtdra on 25th November 2008

Well, I’m back from this weekend’s retreat. Although it’s hard to say that it was a retreat because I came back very tired and exhausted that it hardly felt like a “retreat” from anything at all. I didn’t even get to study last night. After I bathed my son around 8:30 PM, I fell right to sleep. I was supposed to be reading him his bed time books but instead, he read me to sleep. I don’t even remember how I managed to get back to my own bed.

On Thursday night I completed my challenge and clocked in 1:43:04 of study time. I know it’s not exactly 2 hours that I set out to do. But I gave myself some leeway because I never clocked the time I setup lab and some missed time on the clock as well. Also I was under pressure to get the studying done because I had to learn a few songs that night before leaving on Friday night for the weekend retreat.

I just want to jot down a few thoughts about the weekend. It definitely was something that I probably needed in this moment of my life right now. Although I was busy switching roles from being the music guy to a dish-washer :) , I had the opportunity to listen in to some very good talks. Since it is a spiritual retreat, a lot of it was centered on religious topics. I think what I enjoyed the most, though,  were the talks that centered on the family and the issues that affect family life. As a father and a husband, I constantly need a reminder what I’m doing all this for. All this studying and pursuit to becoming a better engineer is inspired by my desire to be a better provider for my family. And I guess sometimes I lose track of that especially when I am too deep into my studies. There are even occasions where I ignored my son while studying when I was supposed to be watching him.

During the retreat, I was particularly inspired by a gentleman, about my age, who was invited to speak to our guests about importance of family in the context of Christian living. The cool thing about it is that I knew this guy from a while back from playing in a basketball league together. I only knew him from seeing him on the courts, but I never had a deeper insight into his life until he had spoken to us. After he spoke I took some time to congratulate him and talk to him a little bit more about his ideas on family living. I was pleased to learn that his goals for his family is in line with my goals for our family. His wife is a stay at home mother, raising their two beautiful kids to be stewards of greatness. And no matter how poor they get, he says, he makes sure that they remain that way. And I believe him. Because no mater how successful he has become as a banker, I see them driving a very modest vehicle, and living in a modest home.

How is this all related to Cisco. Well, probably not much. At least not directly. But thinking about it more allowed me to correlate a lot of my pursuit in my studies to my life’s calling. I believe that to be a good father, a good husband and a good provider, I need to be good at what I do in my profession. I can’t have an orderly family life if everything else in my life is in disarray. If I have a lackluster career because of lackluster skills, then my ability to provide for my family will also be lacking. If I cannot perform at a high level of proficiency and expertise at work, how can I expect myself to do the same at home.  And this is where my calling as a husband/father ties in with my pursuit to become an excellent engineer. Sure many are able to and do separate their day jobs from their family life. But for me, fulfillment is partly defined by how I am able to manage my profession to better serve my family as well as others. This hasn’t happened yet, but one day, I’ll get closer to getting it right.

Tonight, I tackle BGP…

Posted in Aragoen's Musing, BGP, BSCI Exam Prep, General | 1 Comment » | Print This Post