#PEERS
Internal BGP (iBGP) peers and external BGP (eBGP) peers are the two types of peers used by BGP. BGP peers in the same Autonomous System are known as internal peers (AS). Peers in various Autonomous Systems are referred to as external BGP peers.
eBGP peers must define each other as neighbors by default, using the subnet that connects them directly. They must use the “ebgp-multihop” neighbor command if they do not use this “directly linked” address (if they use their loopback addresses or if a few hops separate them).
Without the “ebgp-multihop” command, iBGP peers can be up to 255 hops apart by default.
If BGP peers (eBGP or iBGP) communicate across loopback addresses, the “update-source” neighbor command is required. This directs the local router to update the interface provided in its BGP source IP address (such as loopback 0). Otherwise, the router’s BGP source address is set to the IP address of the outgoing interface used to contact the BGP peer. If you are peering across loopback addresses, this address will not match the IP address supplied at the remote peer using the neighbor command. This mismatch will hinder the formation of a BGP peer relationship.
#ADVERTISING TO PEERS
If a router uses the “network” command to create a route, that router’s routing table must contain the network and mask given. This is vital to remember, especially when seeking to advertise a summary route. If the router’s routing table contains networks 10.1.0.0/24 through 10.1.3.0/24, a single summary advertisement (10.1.0.0/22) can be used to promote them. If you type in:
router bgp 65001 network 10.1.0.0 mask 255.255.252.0
The summary, as well as any of the four class C subnets, will not be advertised by the router. This is because you indicated that you want to broadcast the summary, yet the router’s routing database does not contain that specific network and mask. The “aggregate-address” command or a static route to null0 can be used to solve this problem. Place a static route in the routing table as a placeholder for BGP to advertise a route. As an example, you might enter:
Aggregate-Address Example:
router bgp 65001 aggregate-address 10.1.0.0 255.255.252.0 summary-only
Static Route to Null0 Example:
ip route 10.1.0.0 255.255.252.0 null0 router bgp 65001 network 10.1.0.0 mask 255.255.252.0
The router will broadcast the 10.1.0.0/22 summary in this situation since it is now in its routing table. When traffic arrives at this router, it will have a legal route pointing to null0 and four additional /24 routes in its routing table. More specific routes are prioritized over less-specific routes, ensuring traffic is properly handled.
BGP peers do not always notify each other of BGP changes. The following table explains how BGP advertises:
#iBGP FULL MESH
Internal BGP (iBGP), BGP within one Autonomous System, requires a logical “complete mesh” of connection, as briefly explained in the preceding section. In other words, every iBGP router in that AS must have a logical link or a peer relationship with every other BGP router. This is needed because BGP does not come with built-in loop detection, especially within an AS. Having an entire physical mesh is unnecessary, but even a logical full mesh might become problematic!
Route reflectors and confederations are two alternatives to the iBGP complete mesh requirement.
A cluster is a group of routers configured as route reflectors. Each router is either a route reflector server or a route reflector client inside the cluster. A cluster usually consists of one or two route reflector servers. A route reflector cluster might have dozens, if not hundreds, of peers. Clients for route reflectors do not require any setting. They are entirely unaware that they are part of a cluster. Route reflector servers need the “neighbor route-reflector-client” command to identify each client. When route reflector servers receive routing updates from clients, they relay the information to all other clients in the cluster and any iBGP peers they have. When route reflector servers receive routing updates from non-cluster iBGP peers, they relay the information to all clients but not other non-cluster iBGP peers.
Confederation deployment divides an Autonomous System into smaller Autonomous Systems known as confederations. Confederations are a cross between the EBGP and the iBGP. Confederations are entirely disguised while exchanging route updates with other Autonomous Systems like an iBGP. However, EBGP rules should be used when transmitting routing updates across Confederations. That is, there is no necessity for a complete mesh. Two Confederations might have a single link, numerous connections, or no ties.
Route reflectors are the more straightforward alternative to install, with few disadvantages over confederation.
#FILTER
Although BGP has various filtering options, I prefer route maps with prefix lists. Part of the rationale is because you’ll need to master route maps regardless, so this is a talent you’ll need. The route map and prefix-list can have the same sensible name.
You may use the following to filter BGP routes:
A. “neighbor route-map” command in route-map with simply a “match IP address” statement
B. “neighbor distribute-list” is a command (that applies to the neighbor specified)
C. “distribute-list” is a command (that applies to the entire BGP process)
D. “neighbor filter-list” with “ip as-path access-list”
E. “neighbor prefix-list”
The filter is applied to a specific neighbor in the first two selections (A & B). The filter is applied to the entire BGP procedure in the third option – routes learned from any neighbor (C). Using only a “distribute-list” filters changes from the routing table while leaving them in the BGP table. The other two take them out of both.
The “neighbor prefix-list” and “neighbor distribute-list.” commands can be used on the same neighbor, but not at the same time. I like the “neighbor prefix-list” command since I favor prefix lists.
Use the “neighbor filter-list” command to filter depending on AS path. However, using (to signify the start of an AS path) corresponds to the start of the path as specified in the bgp database. For instance, to match:
Network Next Hop Metric LocPrf Weight Path *i172.16.1.0 10.254.254.1 1000 50 0 65022 444 i
Display the BGP entries that match the specified regular expression, which in this case, begins with 65022, followed by 444:
show ip bgp reg ^65022_444_
To build an AS-PATH filter, you follow the following steps:
ip as-path access-list 1 permit ^65022_444_ router bgp 65001 neighbor 10.254.254.1 filter-list 1 in
According to the BGP regular expression command, the AS path’s “beginning” must be 65022, followed by 444. Even though the real “start” of the AS path is 444, the route originated from AS444, then went through 65022.
#COMMUNITIES
To send communities, type “neighbor 10.254.254.1 send-community” on the command prompt. This will send any communities that BGP routes currently have, those that were sent to you from peers and/or ASs, and any communities you create using a route-map to that neighbor. Communities are not automatically sent.
To associate routes with communities, you’ll need:
ip bgp-community new-format route-map RM_MPLS_OUT permit 10 match ip address prefix-list BGP-ADVERTISED-PREFIXES-ADD-COMMUNITY set community ####:#### additive route-map RM_MPLS_OUT permit 20 match ip address prefix-list PL_LOCAL_NETWORKS neighbor 10.254.254.1 send-community neighbor 10.254.254.1 route-map RM_MPLS_OUT out
You’ll need the second route-map declaration to broadcast “all other” routes without communities. Using the global command “ip bgp-community new-format” is also required. This command changes the display format to two 16-bit values separated by a colon. This is what you’ll typically see when working with communities.
#SYNCHRONIZATION
Synchronization is a parameter in the “router bgp” configuration that may be activated or disabled. Before a BGP route can be inserted in the routing table, it must also appear in an IGP (OSPF, EIGRP, etc.) for synchronization. This feature was created if certain routers in a network did not support BGP. Those routers would be unable to appropriately forward packets if they were not running BGP and the routes were not in the IGP since they would be “missing” routes. If one of the following is true, you can ‘officially’ disable synchronization:
1. All routers use BGP in the AS (thus, there is no need to include them in the IGP)
2. The AS is not a transit AS because it does not forward communications between Autonomous Systems (in this case, it is presumed that non-BGP routers will know how to correctly forward traffic since it is destined for within their Autonomous systems).
Simply put, BGP synchronization is a historical feature that is often not required since we had to enter the two instructions below each time we began a new router’s BGP process:
no sync no auto-summary
These two commands are now disabled by default after Cisco received requests to modify their default behavior.
#AGGREGATE ADDRESS
This command can be used to summarize an address block. To omit more particular routes, use the term “summary-only.” If this term is omitted, not only will the aggregate address you give be broadcast, but so will the more specialized routes. However, at least one additional particular route must be in the router’s BGP database to broadcast a summary (an aggregate) (via a network command, redistribution, etc.)
#ATTRIBUTES
Understanding each BGP property is critical, especially the more essential ones (local pref, AS PATH, MEDs, and communities). I won’t go through every BGP property, but I will review the most prevalent ones. I encourage doing more reading and practicing, but here’s a quick rundown:
AS_PATH – Perhaps the most significant BGP characteristic is AS-PATH. It keeps track of all the Autonomous Systems the advertising has passed through. This is significant since only local preference is greater in the order of route selection. On the Internet, this is the most prevalent characteristic used to decide routing. Prepending an ASN (making the AS PATH longer by inserting your own ASN numerous times) is frequently used to manipulate routing.
Local Preference – Local Preference is the BGP route selection algorithm’s initial priority. It is set within an AS and transmitted to all routers within the AS, but it never leaves the AS. It determines how traffic from that AS is routed to other ASs. Because all routers share it in an AS, the local preference for each route should be agreed upon by all routers. The higher the local preference, the better. The local preference can be set on all routes (BGP default local-preference) or individual routes (set local-preference using a route-map).
Origin – The origin of a route is an attribute that describes how it was initially entered into BGP (or its “origin”). As routing advertising cross from one AS to the next, it is included. It ranks unusually high in the route selection algorithm, despite the fact that it is rarely utilized. This is because having two alternative routes (paths) for a route with separate beginnings is highly unusual. The two alternative routes nearly always have the same origin because they both originated from the same AS.
“i” implies it was added to BGP through a network statement, “?” means it was added via redistribution, and “e” means it was added via EGP (rare). It may be configured using BGP; however, this is not typical.
MED – The Multi-Exit Discriminator (MED) characteristic is designed for situations where two ASs has numerous connections. Most other properties, such as local pref, AS-PATH, and origin, will be the same in this instance. MEDs allow one AS to control how traffic is routed to it by another AS. We say “influence” because the other AS can still set the local preference if it wants to, and because local preference is higher on the route selection process than MEDs, MEDs will be disregarded. The lower the MED (similar to an IGP measure), the better. It is transmitted from one AS to another but not forwarded to any other ASs by the receiving AS.
Weight – The route selection algorithm’s first characteristic is weight, although I’ve never seen it utilized. Never in a practice lab, never in real life. It’s a “Cisco proprietary” property that only applies to the router (not passed with a routing advertisement). The commands “neighbor weight” and “set weight” can be used to set it.
Community – Each AS to AS routing advertising includes this characteristic. The route-map command “set community” is used to set it. It’s essentially a method of identifying or categorizing specific routes. There are well-known communities (for example, no-export, which means don’t promote this route to any other AS, and no-broadcast, which means don’t advertise this route to any peer (internal or external)). User-defined communities are also available. These are frequently used inside an AS to indicate or identify specific properties. They can also be utilized between ASs, although this needs cooperation between the two. Their typical application is to identify a route so that later actions may be performed, such as avoiding advertising, establishing local preferences, blocking totally, and so on.
#BGP OFFICIAL PATH SELECTION PROCESS
BGP’s route selection process is relatively complex when presented with the same route from more than one peer. My informal method simplifies the “official” method for the most typical circumstances. My unofficial approach is detailed in the section below. Here’s the “official” procedure from the CCO.
1. Do not evaluate the following hop if it is unreachable.
This is why having an IGP path to the next hop is critical.
2. Do not examine the route if the path is internal, synchronization is enabled, and the route is not in the IGP.
3. Choose the way that has the most weight (weight is a Cisco proprietary parameter).
4. If the routes are equal in weight, choose the path with the most local support.
5. If the routes have the same local preference, choose the route that the local router created.
A route might be created by the local router using the “network bgp” command or by redistribution from an IGP, for example.
6. Prefer the route with the shortest autonomous system path if the local preference is the same or if the local router created no route.
7. If the autonomous system path length is equal, choose the route with the lowest origin code (IGP EGP INCOMPLETE).
8. Choose the route with the lowest Multi Exit Discriminator (MED) metric attribute if the origin codes are the same.
Unless “bgp always-compare-med” is enabled, this comparison is only performed if the nearby autonomous system is the same for all routes investigated.
Note: The most recent IETF decision on BGP MED gives the missing MED a value of infinity, making the route without the MED variable the least favored. BGP routers using Cisco IOS software treat routes without the MED attribute as though they have a MED of 0, making the route without the MED variable the most favored. Use the “bgp bestpath missing-as-worst” command to configure the router to follow the IETF standard.
9. Choose the external (EBGP) route over the internal (IBGP).
10. Internal routes include all confederation paths.
Take the route that passes via the nearest IGP neighbor (the lowest IGP metric).
This means that the router will choose the quickest internal path to the destination within the autonomous system (the shortest path to the BGP next-hop).
11. If all of the following requirements are met, add the following route to the IP routing table:
-The finest and these routes are both external.
-This route and the optimal route are both from the same autonomous system.
-“maximum-paths” is set to true.
Note: At this time, EBGP load sharing is possible, which means numerous pathways can be inserted into the forwarding table.
12. If multipath is not enabled, choose the BGP router ID route with the lowest IP address value.
The router ID is normally the router’s highest IP address or the loopback (virtual) address; however, it can vary depending on the implementation.