Explain BGP, the Differences between BGP and OSPF, What Prefixes Are, and What Attributes and Types Are Used in BGP

The Border Gateway Protocol (BGP) is a favorite subject for many technical interviewers. It is the exterior routing protocol of choice in today’s networks and is quite different from interior routing protocols such as OSPF. BGP fulfills the role of mediating between two “administratively controlled” networks.

These administratively controlled networks are known as autonomous systems (ASs). BGP, requiring a reliable connection between peers, uses TCP port 179. Each peer session gets a single TCP session. BGP is an application layer protocol, so it requires the TCP session to be established before exchanging any route information. BGP sessions can be authenticated using MD5 signatures when exchanging updates.
An UPDATE message can have a variable number of attributes; however, they cannot be repeated. As for the prefixes, an UPDATE message can advertise only one route. It can, however, list routes to be deleted. BGP is considered a path vector protocol because it stores route information in addition to path attributes. The route selection is done in a deterministic fashion based on best route policy. The policy is based off the path attributes. Where interior routing protocols use metrics such as delay, link utilization, or hops, BGP does not. Understand that BGP is capable of running in two modes: exterior and interior.

EBGP is used for peering between different autonomous systems (AS). IBGP is used for routers within the same AS. Path attributes are different for the two modes; these are discussed shortly.

There are two key differences between BGP and OSPF (or any internal routing protocol). The first difference is how the protocols scale up to accommodate large numbers of routes. BGP scales up well because it sends a complete route update only once when a session is established with a peer. After that, the BGP speaker will send only incremental changes. Even though OSPF mostly sends link state information, there are still periods in which all its routing information is sent. The second key difference is the support for path attributes in BGP. BGP uses path attributes to form routing policies. This works well when you have to route between separately owned and maintained networks (autonomous systems). The routing policies allow you to make a decision as to whether to accept, reject, or change (summarize/aggregate)
routes from a peer network. This helps protect the network and control how routes are propagated throughout the internal network.
A prefix is the network portion of the IP address and implies the use of classless addressing. BGP uses prefixes in the Network Layer Reachability Information (NRLI) field in the UPDATE messages. The path attributes convey the prefix characteristics to the peer router. Another hot topic in BGP is the ability to perform route dampening. Route dampening is a feature that controls the frequency of routes changing state— up, down, up, down, and so on. This frequent changing of state is called route flapping. Most routers today can sense the flapping and remove the offending route. To do so, they monitor how often the flapping occurs and penalize the route each time. After the penalties exceed a set threshold, the route is removed and updates are ignored. The route can be reused after a certain
amount of time. One of the greatest arguments in BGP is which attributes should or should not be used when sharing information between two networks. (Just a quick definition note: The words update and advertisement are used interchangeably.) In BGP, there are numerous path attributes that accompany an update between
two BGP speakers who wish to exchange routing information. We draw from RFC 4271/1771 for the following information. There are four defined categories for BGP attributes:

❑ Well-known mandatory
❑ Well-known discretionary
❑ Optional transitive
❑ Optional nontransitive

As the name implies, any vendor who wishes to implement BGP must have the well-known attributes. The mandatory attributes are ones that have to be included in every update. Discretionary attributes do not. Optional attributes are ones that some BGP speakers may use and others may not. The transitive bit in the update determines whether a BGP neighbor propagates the attribute or simply deletes it. It is always good to review the well-known mandatory attributes first. There are three mandatory
attributes that are well-known: ORIGIN, AS_PATH, and NEXT_HOP. There are two well-known, discretionary attributes: Local Preference, and Atomic Aggregate. All these attributes are described in the following list:

❑ ORIGIN: The Origin code is how the route originated, or the source of the route. The choices are internal gateway protocol (IGP), external gateway protocol (EGP), or incomplete. A great follow-up question is, “What is the cause of an unknown/incomplete?” Some of the most common reasons are route aggregation/summarization and redistribution.

❑ AS_PATH: The AS_PATH attribute is simply a list of all the autonomous systems (AS) that the given route in the update transits through. As the update passes through each AS, each BGP host adds its own AS to the list.

❑ NEXT_HOP: The NEXT_HOP attribute is the IP address of the first router in the next AS. And this first router may be more than one hop away. When this is the case, the interior routing protocol will compute a route to the BGP NEXT_HOP IP address. Just remember that Internal BGP sessions will not change the NEXT_HOP attribute — only external BGP sessions do.

❑ LOCAL_PREF: The local preference attribute is used to inform internal BGP peers of the preferred AS egress point for the included route.

❑ ATOMIC_AGGREGATE: The atomic aggregate attribute is used when a BGP speaker has overlapping routes from one of its peers. The BGP speaker will set the attribute when it makes a less-specific route selection. Aggregation, also known as summarization, hides network reachability and topology information. The atomic aggregate attribute is the mechanism used to hide the AS path. Examples of the optional transitive attributes are the Aggregator, Communities, and Extended
Communities attributes.

❑ Aggregator: The Aggregator attribute is a way for a BGP speaker to notify its peer that it has aggregated a given route and provides its own AS number and IP address.

❑ Communities: Communities are the “catch-all” attributes. In most large networks today, BGP communities are used to enforce policy. They do not directly affect the route selection algorithm of BGP, but they can shape how routes are treated when received in an update. There are three communities that are commonly used: NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED. The NO_EXPORT community attribute is a tag that notifies the peer whether the route can be exported to an external AS. The NO_ADVERTISE community attribute notifies the peer to not advertise the route at all. The NO_EXPORT_SUBCONFED community extends the NO_EXPORT attribute to include confederated ASs.

❑ Extended Communities: Extended Communities extend the BGP attributes further. There are a number of Extended Communities in draft and used in some BGP implementations. Ones to mention include the Autonomous System Specific, Route Target, Route Origin, and Link Bandwidth.

❑ MULTI_EXIT_DISC: The MED attribute is an optional, nontransitive attribute that provides a means to advertise multiple exit points for the local AS. Each exit point is given a metric, and the lowest metric will be the preferred exit point. Much has been written on BGP but the great references for BGP are still the RFCs. There are many and they all deserve attention: RFC 4271 - A Border Gateway Protocol 4 (BGP-4); RFC 4272 - BGP Security Vulnerabilities Analysis; RFC 4273 - Definitions of Managed Objects for BGP-4; RFC 4276 - BGP-4 Implementation Report; RFC 1772 - Application of the Border Gateway Protocol in the Internet; RFC 1773 - Experience with the BGP-4 protocol; RFC 1774/4274 - BGP-4 Protocol Analysis; RFC 1997 - BGP Communities Attribute; and RFC 1998 - An Application of the BGP Community Attribute in Multi-home
Routing as well as Internet-Draft document draft-ietf-idr-bgp-ext-communities, BGP Extended Communities Attribute.