Today we will discuss the BGP protocol. We won't dwell on why it is used as the sole protocol. There is quite a bit of information available on this subject, for example, .
So, what is BGP? BGP is a dynamic routing protocol that is the only EGP (External Gateway Protocol). This protocol is used for routing on the internet. Let's examine how neighbor relationships are established between two BGP routers.
We will look at the neighbor relationship between Router1 and Router3. We will configure them using the following commands:
router bgp 10
network 192.168.12.0
network 192.168.13.0
neighbor 192.168.13.3 remote-as 10
router bgp 10
network 192.168.13.0
network 192.168.24.0
neighbor 192.168.13.1 remote-as 10Neighboring within the same autonomous system — AS 10. After entering the data on the router, for instance on Router1, this router attempts to establish neighbor relationships with Router3. The initial state, when nothing is happening, is called Idle. Once BGP is configured on Router1, it begins listening on TCP port 179 — transitioning to the Connectstate, and when it tries to establish a session with Router3, it enters the Active.
After the session is established between Router1 and Router3, Open messages are exchanged. When this message is sent by Router1, this state is called Open Sent. And when it receives an Open message from Router3, it transitions to the state Open Confirm. Let's examine the Open message in more detail:
This message conveys information about the BGP protocol that the router is using. By exchanging Open messages, Router1 and Router3 share information about their settings. The following parameters are transmitted:
- Version: this includes the BGP version that the router is using. The current version of BGP is version 4, as described in RFC 4271. Two BGP routers will attempt to negotiate a compatible version; if there is a mismatch, then there will be no BGP session.
- My AS: this includes the AS number of the BGP router. The routers must agree on the AS number(s), and it also defines whether they will be running iBGP or eBGP.
- Hold Time: if BGP does not receive any keepalive or update messages from the other side for the duration of the hold time, it will declare the other side 'dead' and terminate the BGP session. By default, the hold time is set to 180 seconds on Cisco IOS routers, and the keepalive message is sent every 60 seconds. Both routers must agree on the hold time; otherwise, there won't be a BGP session.
- BGP Identifier: this is the local BGP router ID, which is elected in a manner similar to OSPF:
- Use the router-ID that was configured manually with the bgp router-id command.
- Use the highest IP address on a loopback interface.
- Use the highest IP address on a physical interface.
- Optional Parameters: here you will find some optional capabilities of the BGP router. This field has been added so that new features could be added to BGP without having to create a new version. Things you might find here are:
- support for MP-BGP (Multi Protocol BGP).
- support for Route Refresh.
- support for 4-octet AS numbers.
To establish neighbor relationships, the following conditions must be met:
- Version number. The current version is 4.
- The AS number must match what you have configured. neighbor 192.168.13.3 remote-as 10.
- The Router ID must be different from the neighbor's.
If any of these parameters do not meet the requirements, the router will send supports a message indicating the error. After sending and receiving Open messages, the neighbor relationship changes to the ESTABLISHEDstate. After this, the routers can exchange route information, doing so through Update messages. Here's an Update message that Router1 sends to Router3:
Here, the networks that Router1 reports and the Path attributes, which are analogous to metrics, are specified. We will discuss Path attributes in more detail. Also, within the TCP session, Keepalive messages are transmitted. These are sent, by default, every 60 seconds. This is the Keepalive Timer. If a Keepalive message is not received during the Hold Timer, it indicates a loss of connection with the neighbor. By default, it is set to 180 seconds.
Useful table:
Now that we've figured out how routers exchange information, let's try to understand how the BGP protocol works.
To announce a route in the BGP table, like in IGP protocols, the network command is used, but the logic of operation differs. In IGP, after specifying a route in the network command, IGP looks at which interfaces belong to that subnet and includes them in its table; the network command in BGP looks into the routing table and searches for an exact match with the route in the network command. Upon finding such routes, they will be added to the BGP table.
Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.
Now let’s bring up BGP on all the remaining routers and see how route selection occurs within a single AS. Once the BGP router receives routes from a neighbor, the selection of the optimal route begins. Here, it’s important to understand what type of neighbors there can be — internal and external. Does the router, based on its configuration, understand whether the configured neighbor is internal or external? If in the command:
neighbor 192.168.13.3 remote-as 10 The parameter remote-as specifies the AS configured on the router with the command router bgp 10. Routes originating from an internal AS are considered internal, while routes from an external AS are considered external. Different logic applies for receiving and sending regarding each type. Let's consider the following topology:
Each router has a loopback interface configured with ip: x.x.x.x 255.255.255.0 — where x is the router number. On Router9, we have a loopback interface with the address — 9.9.9.9 255.255.255.0. We will announce this via BGP and observe how it propagates. This route will be sent to Router8 and Router12. From Router8, the route will reach Router6, but it will not be in the routing table of Router5. Similarly, from Router12, the route will enter the table, but it will also be absent on Router11. Let’s delve into this. We will examine what data and parameters Router9 sends to its neighbors, notifying them of this route. The packet below will be sent from Router9 to Router8.
Route information consists of path attributes.
Path attributes are divided into 4 categories:
- Well-known mandatory — all routers operating under the BGP protocol must recognize these attributes. They must be present in all updates.
- Well-known discretionary — all routers operating under the BGP protocol must recognize these attributes. They may be present in updates, but their presence is not mandatory.
- Optional transitive — may not be recognized by all BGP implementations. If a router does not recognize the attribute, it marks the update as partial and sends it to its neighbors, retaining the unrecognized attribute.
- Optional non-transitive — may not be recognized by all BGP implementations. If a router does not recognize the attribute, it is ignored and dropped when passed to neighbors.
Examples of BGP attributes:
- Well-known mandatory:
- Autonomous system path
- Next-hop
- Origin
- Well-known discretionary:
- Local preference
- Atomic aggregate
- Optional transitive:
- Aggregator
- Communities
- Optional non-transitive:
- Multi-exit discriminator (MED)
- Originator ID
- Cluster list
In this case, we are currently interested in Origin, Next-hop, AS Path. Since the route is transmitted between Router8 and Router9, that is, within the same AS, it is considered internal, and we will pay attention to Origin.
The Origin attribute indicates how the route was obtained in the update. Possible values for the attribute are:
- 0 — IGP: NLRI obtained within the originating autonomous system;
- 1 — EGP: NLRI was learned via the Exterior Gateway Protocol (EGP). The predecessor of BGP, it is no longer in use.
- 2 — Incomplete: NLRI was learned through some other means.
In our case, as seen from the packet, it is equal to 0. When this route is passed to Router12, this code will have a code of 1.
Next, the Next-hop attribute.
- This is the IP address of the eBGP router through which the path to the destination network is routed.
- The attribute changes when the prefix is transferred to another AS.
In the case of iBGP, meaning within the same AS, the Next-hop will be the one that learned or advertised this route. In our case, this will be 192.168.89.9. However, when this route is passed from Router8 to Router6, Router8 will change it and replace it with its own. The Next-hop will be 192.168.68.8. This leads us to two rules:
- If a router passes a route to its internal neighbor, it does not change the Next-hop parameter.
- If a router passes a route to its external neighbor, it changes the Next-hop to the IP of the interface from which this router is transmitting.
This brings us to the first problem—Why there will not be a route in the routing table on Router5 and Router11. Let’s examine this in more detail. So, Router6 received information about the route 9.9.9.0/24 and successfully added it to the routing table:
Router6#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
9.0.0.0/24 is subnetted, 1 subnets
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Now Router6 has passed the route to Router5 and did not change the first Next-hop rule. That is, Router5 should add <b>9.9.9.0 [20/0] via 192.168.68.8</b> , but it does not have a route to 192.168.68.8, so this route will not be added, although information about this route will be stored in the BGP table:
<source><b>Router5#show ip bgp
BGP table version is 1, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>The same situation will occur between Router11 and Router12. To avoid such a situation, it is necessary to configure Router6 or Router12, when passing a route to their internal neighbors, to insert their own IP address as the Next-hop. This is done using the command:
neighbor 192.168.56.5 next-hop-selfAfter this command, Router6 will send an Update message where the Next-hop for the routes will be the IP address of the Gi0/0 interface of Router6 — 192.168.56.6, after which this route will enter the routing table.
Let’s proceed further and see if this route appears on Router7 and Router10. It will not be found in the routing table, and we might think that the problem lies with the Next-hop parameter, but if we look at the output of the command show ip bgp, we will see that this route was not received even with the incorrect Next-hop, which means that the route was not even transmitted. This leads us to another rule:
Routes learned from internal neighbors are not forwarded to other internal neighbors.
Since Router5 received a route from Router6, it will not pass it to another internal neighbor. To enable the transmission, it is necessary to configure the function , or establish full-mesh neighbor relationships (Full Mesh), that is, Router5-7 will each be a neighbor to each other. In this case, we will use Route Reflector. On Router5, the following command must be used:
neighbor 192.168.57.7 route-reflector-clientThe Route Reflector changes BGP behavior when advertising a route to an internal neighbor. If the internal neighbor is specified as route-reflector-client, then internal routes will be advertised to these clients.
Did the route not appear on Router7? We also need to consider the Next-hop. After these manipulations, the route should be on Router7, but this does not happen. This leads us to another rule:
The next-hop rule applies only to External routes. For internal routes, the next-hop attribute is not modified.
And we end up in a situation where it is necessary to create an environment using static routing or IGP protocols to inform routers about all routes within the AS. We will define static routes on Router6 and Router7, and after this, we will get the desired route in the router's routing table. In AS 678, we will do it a bit differently — we will define static routes for 192.168.112.0/24 on Router10 and 192.168.110.0/24 on Router12. Next, we will establish neighbor relationships between Router10 and Router12. We will also configure Router12 to send its next-hop to Router10:
neighbor 192.168.110.10 next-hop-selfThe result will be that Router10 will receive the route 9.9.9.0/24, it will be received from both Router7 and Router12. Let's see what choice Router10 will make:
Router10#show ip bgp
BGP table version is 3, local router ID is 6.6.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* > i 9.9.9.0/24 192.168.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i As we can see, there are two routes and the arrow ( > ) indicates that the route through 192.168.112.12 was selected.
Let's take a look at how the route selection process occurs:
- First, upon receiving a route, the availability of its Next-hop is checked. This is why, when we received the route on Router5 without the Next-hop-self configuration, this route was not passed for processing.
- The next parameter is Weight. This parameter is not an Attribute of the Path (PA) and is not transmitted in BGP messages. It is configured locally on each router and is used solely for manipulating route selection on the router itself. For instance, it is shown above that Router10 selected the route for 9.9.9.0/24 via Router12 (192.168.112.12). To change the Weight parameter, you can use a route-map to set it for specific routes, or assign weight to a neighbor using the command:
neighbor 192.168.107.7 weight 200Now all routes from this neighbor will have that weight. Let’s see how the route selection changes after this manipulation:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Configured from console by console BGP table version is 2, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * > 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iAs you can see, the route is now selected via Router7, but this will not affect the other routers.
- In the third position, we have – Local Preference. This parameter is a Well-known discretionary attribute, meaning its presence is not obligatory. This parameter is only effective within one AS and influences path selection only for internal neighbors. That is why it is transmitted only in Update messages intended for internal neighbors. In Update messages for external neighbors, it is absent. Therefore, it is classified as Well-known discretionary. We will attempt to apply it on Router5. Router5 should have two routes for 9.9.9.0/24 – one via Router6 and the other via Router7.
Let’s take a look:
Router5#show bgp BGP table version is 2, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 iBut as we can see, there is one route via Router6. Where is the route via Router7? Maybe it is not on Router7 either? Let's check:
Router#show bgp BGP table version is 10, local router ID is 7.7.7.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 iIt's strange, everything seems fine. Why isn't it being transmitted to Router5? The thing is, BGP has a rule:
A router only transmits routes that it itself uses.
Router7 uses the route via Router5, so the route through Router10 will not be transmitted. Let's return to Local Preference. Let's set Local Preference on Router7 and see how Router5 reacts:
route-map BGP permit 10 match ip address 10 set local-preference 250 access-list 10 permit any router bgp 123 neighbor 192.168.107.10 route-map BGP in</b>So, we created a route-map that matches all routes and instructed Router7 to change the Local Preference parameter to 250 upon receipt, which defaults to 100. Let's see what happened on Router5:
Router5#show bgp BGP table version is 8, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 iAs we can see, Router5 now prefers the route via Router7. The same picture will be on Router6, although it would be better for it to choose the route through Router8. It should also be noted that changing this parameter requires a restart of the neighbor, for the change to take effect. Read . We have clarified Local Preference. Let's move on to the next parameter.
- Route preference with the Next-hop parameter set to 0.0.0.0, that is, local or aggregated routes. These routes are automatically assigned a Weight parameter equal to the maximum — 32678 — after entering the network command:
Router#show bgp BGP table version is 2, local router ID is 9.9.9.9 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 9.9.9.0/24 0.0.0.0 0 32768 i - The shortest path through AS. The shortest AS_Path parameter is chosen. The fewer AS the route passes through, the better it is. Let's consider the route to 9.9.9.0/24 on Router10:
Router10#show bgp BGP table version is 2, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 9.9.9.0/24 192.168.107.7 0 123 45 i * >i 192.168.112.12 0 100 0 45 iAs you can see, Router10 chose the route through 192.168.112.12 because for this route, the AS_Path parameter contains only 45, whereas in the other case it contains 123 and 45. This is intuitively clear.
- The next parameter is Origin. IGP (route learned via BGP) is better than EGP (route learned via a predecessor of BGP, which is now obsolete), and EGP is preferable to Incomplete? (learned by some other means, like redistribution).
- The next parameter is MED. We had Weight, which worked only locally on the router. There was Local Preference, which worked only within a single autonomous system. As you might guess, MED is a parameter that will be passed between autonomous systems. It's very good. about this parameter.
No more attributes will be used, but if two routes have the same attributes, the following rules are applied:
- Select the path through the nearest IGP neighbor.
- Choose the oldest route for eBGP paths.
- Select the path through the neighbor with the smallest BGP router ID.
- Select the path through the neighbor with the smallest IP address.
Now let's consider the convergence of BGP.
Let's see what happens if, let's say, Router6 loses the route to 9.9.9.0/24 through Router9. We'll disable interface Gi0/1 on Router6, which will immediately realize that the BGP session with Router8 has been terminated and the neighbor is gone, meaning the route learned from it is no longer valid. Router6 immediately sends Update messages indicating the network 9.9.9.0/24 in the Withdrawn Routes field. Once Router5 receives such a message, it will forward it to Router7. But since Router7 has a route through Router10, it will respond immediately with an Update containing the new route. If it’s not possible to detect the neighbor's outage through interface status, we’ll have to wait for the Hold Timer to expire.
Confederation.
As you may remember, we discussed that it often requires using a fully meshed topology. With a large number of routers in one AS, this can create significant issues. To avoid this, it's necessary to use confederations. One AS is divided into several sub-ASes, allowing them to operate without the requirement of a fully meshed topology.
Here is the link to this , and configuration for GNS3.
For example, in this topology, we would have to link all the routers in AS 2345 to each other, but by using Confederation, we can establish neighbor relationships only between routers that are directly connected. Let's discuss this in detail. If we only had AS 2345, then laForge after receiving the route from Picard would inform his routers Data and Worf, but they would not inform the router Crusher . Additionally, the routes that the router itself disseminates laForge, would not be passed on to Crusher or Worf-, nor to Data.
We would have to configure a Route Reflector or establish fully meshed neighbor relationships. By dividing AS 2345 into 4 sub-ASes (2, 3, 4, 5) for each router, we end up with a different operational logic. Everything is well described in .
Sources:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Website
- Website .
Source: habr.com
