Networking / Beginners

---

BGP

Border Gateway Protocol version 4 (BGP4) is the EGP used to exchange routes between autonomous systems in the Internet. BGP was designed based on experience gained with EGP, and provides built-in support for CIDR and route aggregation. BGP4 is specified in RFC 1771 and other BGP-related documents: RFC 1772, RFC 1773, and RFC 1774.

Almost no coordination of global policies takes place between autonomous systems (because of the difficulties of coordinating policies between independently administrated systems, and because ISPs are not inclined to reveal the setup of internal policies). In this context, a distance vector protocol could not by itself guarantee loop-free paths and fast convergence across autonomous systems. BGP is a path vector protocol, essentially a distance vector protocol that does not rely on the distance to destination to guarantee a loop-free path but on the analysis of the path itself. A direct consequence of this approach is that the path, a list of traversed autonomous systems, is accumulated and carried between BGP routers.

The BGP basic unit of routing information is the BGP path, a route to a certain set of CIDR prefixes. Paths are tagged with various path attributes, of which the most important are AS_PATH and NEXT_HOP.

The AS_PATH attribute contains a list of autonomous systems a route goes through to get to the destination. Loops are detected and avoided by checking that the router's own ASN is not in the AS_PATHs received from neighboring autonomous systems.

The NEXT_HOP attribute is another important piece of the BGP route advertisement. When the BGP update crosses autonomous system boundaries (see the eBGP discussion below), the NEXT_HOP attribute is changed to be the IP address of the boundary router, while, as long as updates remain within an autonomous system, the next hop is left unchanged (see the iBGP discussion below). That ensures that within the autonomous system, the next hop is always the IP address of the external peer that announced the destination prefix, and that internal BGP peers do not have to be on the path to the advertised destination.

BGP can be deployed in two forms: exterior BGP (eBGP) and interior BGP (iBGP). eBGP is used for interautonomous system peering, whereas iBGP carries BGP path information inside the same autonomous system. Although some of the information (route, metric) carried by iBGP might be redundant with that advertised by IGPs, such as IS-IS, OSPF, and so on, no IGP is capable of transporting BGP-specific path attributes such as the AS_PATH. Hence, iBGP is necessary to ensure that BGP path attributes received on one edge of the autonomous system, over the eBGP connection, are available on the other edge of the same autonomous system.

To understand how the next hop is updated or propagated, depending on BGP peering type, and how and where the AS_PATH is accumulated, you can look at BGP tables of routers.

Example-18. iBGP: Entry Received with Next Hop Unchanged

PE2#show bgp ipv6
BGP table version is 8, local router ID is 200.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, 
              i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i2001:200:1::/48  2001:100:1:1::2          0    100      0 200 ?

When sent from PE2 to CE2, the prefix is announced with AS_PATH={100,200}, and NEXTHOP 2001:100:2:1::1 (PE2), as illustrated in Example-19.

Example-19. eBGP: Entry Received with Next Hop Changed

CE2#show bgp ipv6
BGP table version is 8, local router ID is 200.15.15.1
Status codes: s suppressed, d damped, h history, * valid, > best,
              i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2001:200:1::/48  2001:100:2:1::1                      0 100 200 ?

BGP runs over a TCP transport protocol. On connection start, BGP peers exchange complete copies of their routing tables. From there, the BGP peers maintain their respective routing database by exchanging only deltas, which makes the protocol fairly efficient as far as number of control messages is concerned.

In addition to BGP attributes, CIDR is used by BGP to aggregate prefixes and reduce the size of the routing tables. When an ISP has been delegated a block of addresses, and has allocated part or this block to its own customers, BGP can aggregate routes received from these customers, and announce the entire block to its BGP peers, allowing a significant reduction in the number of BGP routing tables.