BGP: Internet Routing Architectures, Part II

BUILDING PEER SESSIONS

• A BGP neighbor connection can be established within the same AS (internal BGP or iBGP) or between routers in different ASs (external BGP or eBGP).
• During the OPEN message exchange, peer routers compare ASs to determine if they are in the same or different AS.
• The difference between iBGP and eBGP is how BGP would process the routing updates and which attributes are carried in internal vs. external BGP.
• The neighbor negotiation process is mainly the same for internal and external BGP.
• IP connectivity must exist via a protocol different from BGP.

PHYSICAL vs. LOGICAL CONNECTIONS

• Indirectly connected external neighbors require extra configuration (multihop eBGP).
• On the other hand, neighbors within the same autonomous system (internal neighbors) have no restrictions whatsoever on whether the peer is physically connected or separated by multiple IP hops.
• As long as there is IP connectivity between the two neighbors, BGP requires no additional configuration.
• Session stability depends on the stability of neighbor IP address.
• Binding the BGP neighbor connection to a loopback interface will ensure that the BGP session is not reliant on any hardware interface that might be problematic.
• Other than route reflection, BGP does not readvertise iBGP routes learned from other iBGP peers.
• Thus, a full mesh within the AS is required.

SYNCHRONIZATION WITHIN AN AS

• By default, BGP requires that it must be synchronized with the IGP before BGP may advertise transit routes to external ASs.
• Whenever a router receives an update about a destination from an iBGP peer, the router tries to verify internal reachability for that destination before advertising it to other eBGP peers.
• The router does this by checking the destination prefix first to see if a route to the next-hop router exists and second to see if a destination prefix in the IGP exists.
• Otherwise, the router treats the destination prefix as not being synchronized with the IGP and does not advertise it.
• The BGP rule states that a BGP router should not advertise to external neighbors destinations learned from IBGP neighbors unless those destinations are also known via an IGP. This is known as synchronization.
• One option is to use default routes on non-BGP routers but this could lead to suboptimal routing or even routing loops.
• no synchronization will tell BGP to override the synchronization requirement and allow it to advertise routes learned via IBGP, irrespective of the existence of an IGP route.
• That said, by far the most common configuration in Internet-connected networks is to disableBGP synchronization and rely on a full mesh of IBGP routers. The thought of injecting tens of thousands of routes into an IGP is quite frightening.

SOURCES OF ROUTING UPDATES

 

DYNAMICALLY INJECTING INFORMATION INTO BGP

Two options:

1. Purely dynamic: redistribution from an IGP to BGP (the redistribute command).
2. Semidynamic: only certain IGP routes are injected into BGP (the network command).

• If BGP does not find an exact match for routes redistributed via the network command, they will not be advertised.
• If the mask is not specified with the network command and auto-summarization is enabled (default), existence of any subset of the classful prefix will result in the advertisement of the classful prefix.

INJECTION OF UNWANTED OR FAULTY INFORMATION

• Redistributing the whole IGP into BGP could result in the advertisement of private addresses or internal addresses that are supposed to be used within the AS only.
• In mutual redistribution, information that was injected from the outside into the AS could be sent back to the Internet as having originated from the AS.
• Careful filtering is required to guard against these undesired consequences.
• Some IGPs can inherently differentiate between internal and external routes.
• For other IGPs, special route tagging can distinguish between internal and external routes.

UNSTABLE ROUTES

• A process called route dampening penalizes and ultimately discontinues advertisement of fluctuating routes, depending on their degree of instability. Route advertisements may be suppressed for minutes or even hours (until they stabilize).
• One way to minimize route instability is through aggregation. When an aggregate route announcement represents more than one route, the fluctuation of any single route does not cause fluctuation in the aggregate itself.

STATICALLY INJECTING INFORMATION INTO BGP

• The most effective method of ensuring route stability.
• IGP routes (or aggregates) to be advertised to BGP peers are manually defined as static routes.
• If the route is advertised to the Internet from a single point, advertising a route that is actually down is not a big issue.
• Hosts trying to access that destination will fail irrespective of whether the route is advertised.
• On the other hand, if a route is advertised to the Internet from multiple points, advertising the route statically at all times might end up black-holing the traffic.

ORIGIN OF ROUTES

• BGP considers the networks advertised via the network command or via aggregation as being internal to the AS and will include the ORIGIN attribute in each route as being IGP (i).
• On the other hand, whenever a route is injected into BGP via redistribution (whether statically or dynamically), the ORIGIN of the route will be INCOMPLETE because the redistributed routes could have come from anywhere.
• Aggregated routes will assume the worst ORIGIN value of all the component routes.
• The ORIGIN attribute is used by the BGP decision process to favor one route over another.

BGP ROUTES: ADVERTISEMENT AND STORAGE

• A route is defined as a unit of information that pairs a destination with the attributes of a path to that destination.
• Routes are stored in the Routing Information Bases (RIBs): namely, the Adj-RIBs-In, Loc-RIB, and the Adj-RIBs-Out.
• Adj-RIB-Out: Routes that will be advertised to other BGP speakers.
• Loc-RIB: Routes that will be used by the local BGP speaker, and the next hop for each of these routes must be present in the local BGP speakers forwarding information base (FIB).
• Adj-RIBs-In: Routes that are received from other BGP speakers.
• If a BGP speaker chooses to advertise a route, it may add to or modify the route's path attributes before advertising it to the peer.

THE BGP RIB

• Three distinct parts: Adj-RIB-In, Loc-RIB, and Adj-RIB-Out.
• If a route is not placed in the Loc-RIB, it cannot be placed in the Adj-RIB-Out for advertisement to peers.

BGP DECISION PROCESS 

• Based on the attribute values.
• Only one best path is chosen, in the following preference order:

1. If the next-hop is inaccessible, the route is ignored.
2. WEIGHT (Cisco proprietary attribute, local to the router).
3. LOCAL PREFERENCE.
4. AS_PATH.
5. ORIGIN type (IGP < EGP < incomplete).
6. The lowest MED value.
7. eBGP paths over iBGP paths.
8. The route via the closes IGP neighbor. Follow the shortest path to the BGP NEXT_HOP.
9. The lowest BGP ROUTER_ID.

• If BGP Multipath is enabled, some steps could be bypassed, and all paths with the same AS_PATH length and MED value could be installed into the routing table.

BGP PATH ATTRIBUTES

• A set of parameters that describe characteristics of a prefix (route).
• Well-known mandatory: must be recognized by all BGP implementations and included in every UPDATE message.
• Well-known discretionary: must be recognized by all BGP implementations but may or may not be sent in a particular UPDATE message.
• Optional transitive:
• Optional non-transitive:
• Unrecognized non-transitive optional attributes must be quietly ignored and not passed along to other BGP peers.

ORIGIN (Type Code 1)

• A well-known mandatory attribute that defines the origin of the path information.
• 0: IGP - NLRI that is interior to the originating AS.
• 1: EGP - NLRI learned via EGP.
• 2: INCOMPLETE - NLRI learned by some other means.

AS_PATH (Type Code 2)

• A well-known mandatory attribute that is composed of a sequence of AS path segments.
• Inside the AS, the AS_PATH information is intact. However, when sending routes to eBGP peers, the AS that originates the route adds its own AS number.
• Thereafter, each AS that receives the route and passes it on to other eBGP peers will prepend its AS number to the list.
• Prepending is the act of adding the AS number to the beginning of the list.
• Loop prevention: If the route is advertised to an AS whose AS number is already present in the AS_PATH, the UPDATE is ignored.

NEXT_HOP (Type Code 3)

• A well-known mandatory attribute that defines the next-hop IP address.

1. For eBGP, the next-hop is the IP address of the neighbor that announced the route.
2. For iBGP, for routes that originated inside the AS, the next-hop is the IP address of the neighbor that announced the route.

• A recursive IP lookup might be required for a router to know where to send the packet.
• If a next-hop cannot be reached, BGP considers the route inaccessible.

MULTI_EXIT_DISC (MED) (Type Code 4)

• An optional non-transitive attribute that is used to discriminate among multiple exits points to a neighboring AS.
• A hint to external neighbors about the preferred path into an AS that has multiple entry points.
• When BGP passes the routing update to another AS, the MED is reset to 0 (unless the outgoing MED is explicitly set to a specific value).
• When the route is originated by the AS itself, the most common practice is for the MED value to follow the internal IGP metric of the route.
• MEDs from different ASs are not comparable.
• Still, for administrators who have a reason to do so, Cisco offers the bgp always-compare-med router command, which tells BGP to compare MEDs from different ASs for the same route.
• When providers don't use MEDs or other attribute manipulation techniques to prefer the best-exit path, it's often referred to as closest-exit or hot potato routing.

LOCAL_PREF (Type Code 5)

• A well-known discretionary attribute that is used to inform other BGP speakers in its own AS of the preference for an advertised route.
• A higher local preference is preferred.
• Exchanged between iBGP peers only.
• Cisco proprietary WEIGHT attribute is similar.
• The difference is that the weight parameter is local to the router and is not exchanged between routers, even internal to an AS.

ATOMIC_AGGREGATE (Type Code 6)

• A well-known discretionary attribute that is used to inform other BGP speakers that the local system chose a less-specific route.

AGGREGATOR (Type Code 7)

• An optinal transitive attribute that contains the last AS number that formed the aggreagate and the IP address of the BGP speaker that formed the aggregate route.

COMMUNITY (Type Code 8)

• An optional transitive attribute that specifies all routes with this attribute belonging to the communities listed in the attribute.

ROUTE FILTERING AND ROUTE MANIPULATION

• A BGP speaker can choose what routes to send and receive.
• Route filtering is essential in defining routing policies.
• Routes permitted through a filter can have their attributes manipulated.
• Manipulating the attributes affects the BGP decision process used to identify the best routes to a given destination.
• Both the inbound and outbound filtering can be applied to the peer and protocol levels.
• Inbound filtering indicates that the BGP speaker is filtering routing updates received from other peers, whereas outbound filtering limits the routing updates advertised from the BGP speaker to other peers.
• Both eBGP and iBGP filtering behavior is the same.
• Three actions:

1. Identifying the routes.
2. Permitting or denying the routes.
3. Manipulating the attributes.

• After a route matches an instance, it is considered identified and will not be compared to any further instances. Hence, the order in which the instances are checked is important.
• If the route proceeds to be compared against the entire list of instances and there is still no match, the route is discarded.
• Prefix lists are currently the preferred mechanism to be used for filter routing information.
• Trying to identify the AS_PATH list consists of comparing the list to what is called a regular expression.

PEER GROUPS

• A group of BGP neighbors that share the same update policies.
• Saves the administrator from repetitive configuration and the BGP router itself from parsing the policies sequentially for each individual neighbor.
• With peer groups, the router formulates the update once, based on the policies of the peer group, and then floods the same update to all the neighbors that fall within the group.

BGP-4 AGGREGATION

• Aggregation applies to routes that do not exist in the BGP routing table (contrary to the network command, which applies to rotes that do exist in the IP routing table).
• Aggregation can be performed if at least one more-specific route of the aggregate exists in the BGP routing table.

Examples:

1. Sending the aggregate route only and suppressing more specific routes.
2. Sending the aggregate route and the more specific routes. Typical in a multihomed ISP scenario. Normally, the ISP does not want to advertise the more-specific routes further to the NAP, so it has the originating AS tag all the more-specific routes with the community attribute NO_EXPORT.
3. Sending the aggregate route and a subset of more-specific routes.