How BGP works
Today we look at the BGP protocol. Let's not talk for a long time why it is and why it is used as the only protocol. There is a lot of information on this subject, for example, here .
So what is BGP? BGP is a dynamic routing protocol that is the only EGP (External Gateway Protocol) protocol. This protocol is used to build routing on the Internet. Consider how a neighborhood is built between two BGP routers.
Consider the neighborhood between Router1 and Router3. Configure them with the following commands:
Neighborhood within one autonomous system - AS 10. After entering data on a router, for example, on Router1, this router tries to set up a neighborhood relationship with Router3. The initial state when nothing happens is called Idle . As soon as bgp is configured on Router1, it starts listening to TCP port 179 - switches to the Connect state, and when it tries to open a session with Router3, it switches to the Active state.
')
After the session is established between Router1 and Router3, Open messages are exchanged. When this message sends Router1, this status will be called Open Sent . And when it receives an Open message from Router3, it will go to the Open Confirm state. Let us consider in more detail the message Open:
This message conveys information about the BGP protocol itself, which the router uses. By exchanging Open messages, Router1 and Router3 communicate with each other information about their settings. The following parameters are passed:
If any of the parameters does not satisfy these conditions, the router will send a Notification message, where it will indicate an error. After sending and receiving Open messages, the neighborhood relationship enters the ESTABLISHED state. After that, routers can already exchange information about routes and do it with Update messages. This Update message sends Router1 to Router3:
Here indicate the networks reported by Router1 and Path attributes, which are analogous to metrics. We'll talk about Path attributes in more detail. Also inside the TCP session, keepalive messages are transmitted. They are transmitted, by default, every 60 seconds. This is a keepalive timer. If during the Hold Timer a keepalive message is not received, it will mean a loss of communication with the neighbor. By default, it is 180 seconds.
Useful label:
It seems to understand how routers transmit information to each other, now we will try to understand the logic of the BGP protocol.
To announce any route to the BGP table, as in the IGP protocols, the network command is used, but the logic of the work is different. If in IGP, after specifying the route in the network command, the IGP looks at which interfaces belong to this subnet and includes them in its table, then the network command in BGP looks at the routing table and looks for an exact match with the route in the network command. When finding such, these routes will fall into the BGP table.
as the remote-as parameter, the AS is specified, which is configured on the router itself in the router bgp 10 command. Routes coming from the internal AS are considered internal, and routes from the external AS are considered external. And in relation to each different logic of receiving and sending works. Consider this topology:
Each router has a loopback interface configured with ip: xxxx 255.255.255.0 - where x is the number of the router. On Router9 we have a loopback interface with the address - 9.9.9.9 255.255.255.0. We will announce it on BGP and see how it is distributed. This route will be transmitted to Router8 and Router12. With Router8, this route will go to Router6, but it will not be on Router5 in the routing table. Also on Router12, this route will go to the table, but it will not be on Router11 either. Try to figure it out. Consider what data and parameters Router9 sends to its neighbors, reporting this route. The package below will be sent from Router9 to Router8.
Route information consists of Path attributes.
Path attributes are divided into 4 categories:
BGP attribute examples:
In this case, we will be interested in Origin, Next-hop, AS Path. Since the route passes between Router8 and Router9, that is, within the same AS, it is considered internal and we will pay attention to Origin.
Origin attribute - indicates how the route was obtained in the update. Possible attribute values:
In our case, as seen from the packet, it is equal to 0. When this route is transmitted to Router12, then this code will have the code - 1.
Next, Next-hop. Next-hop attribute
In the case of iBGP, that is, within one AS, Next-hop will be the one that has learned or told about this route. In our case, it will be 192.168.89.9. But when it will transmit this route from Router8 to Router6, Router8 will change it and replace it with its own. Next-hop will be - 192.168.68.8. This leads us to two rules:
This leads us to understand the first problem - Why there will not be a route in the routing table on Router5 and Router11. Consider in more detail. So, Router6 received information about route 9.9.9.0/24 and safely added it to the routing table:
Now Router6 passed the Router5 route and did not change Next-hop to the first rule. That is, Router5 should add 9.9.9.0 [20/0] via 192.168.68.8 , but it does not have a route to 192.168.68.8 and therefore this route will not be added, although information about this route will be stored in the BGP table:
The same situation will occur between Router11-Router12. To avoid such a situation, you need to configure that Router6 or Router12, passing the route to its internal neighbors, substitute your ip address as Next-hop. It is done with the help of the command:
After this command, Router6 will send an Update message, where for routes as Next-hop, the ip of Gi0 / 0 Router6 interface will be specified - 192.168.56.6, after which this route will already fall into the routing table.
Go ahead and see if this route appears on Router7 and Router10. It will not appear in the routing table, and we might think that the problem is the same with the Next-hop parameter, but if we look at the output of the show ip bgp command, we will see that the route was not received even with the wrong Next-hop, that means that the route was not even transmitted. And this will lead us to the existence of another rule:
The Route-Reflector changes the behavior of BGP when passing 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.
The route did not appear on Router7? Do not forget also about Next-hop. After these manipulations, the route should also on Router7, but this does not happen. This brings us to another rule:
And we get a situation in which it is necessary to create an environment using static routing or IGP protocols to inform the routers of all routes within the AS. Let's assign static routes to Router6 and Router7 and then get the desired route in the router table. In AS 678, we will do a little differently - we will write static routes for 192.168.112.0/24 on Router10 and 192.168.110.0/24 on Router12. Next, we establish the neighborhood relationship between Router10 and Router12. Also configure on Router12 sending your next-hop for Router10:
The bottom line is that Router10 will receive route 9.9.9.0/24, it will be received from both Router7 and Router12. Let's see what choice Router10 will make:
As we can see, two routes and an arrow (>) means that the route is chosen through 192.168.112.12.
Let's see how the process of choosing the route:
No more attributes will be used, but if the two routes are the same, then the following rules are used:
Now consider the issue of convergence of BGP.
Let's see what happens if we allow Router6 to lose route 9.9.9.0/24 through Router9. Disable the Gi0 / 1 Router6 interface, which will immediately realize that the BGP session with Router8 is broken and the neighbor is gone, and therefore the route received from it is not valid. Router6 immediately sends Update messages, where it indicates the 9.9.9.0/24 network in the Withdrawn Routes field. As soon as Router5 receives a similar message, send it to Router7. But since Router7 has a route through Router10, then in response, it immediately sends an Update with a new route. If you fail to detect a neighbor’s fall due to the interface status, then you have to wait for the Hold Timer to work.
Confederation.
If you remember, we talked about the fact that often we have to use a fully connected topology. With a large number of routers in one AS, this can cause big problems, to avoid this you need to use confederations. One AS is divided into several sub-AS, which allows them to work without the requirement of a fully connected topology.
Here is a link to this lab , and here is the configuration for GNS3.
For example, with this topology, we would have to connect all the routers in AS 2345 to each other, but using Confederation, we can only establish neighborhood relations between the routers directly connected to each other. Let's talk about this in detail. If we only had AS 2345, then laForge would get a route from Picard to tell it to Data and Worf routers , but they wouldn’t tell Crusher about it . Also, the routes that the laForge router itself spreads would not be passed by the Crusher to either Worf or Data .
You would have to tweak the Route-Reflector or fully connected neighborhood relationships. By breaking one AS 2345 into 4 sub-AS (2,3,4,5) for each router, we end up with a different operation logic. Everything is perfectly described here .
sources:
So what is BGP? BGP is a dynamic routing protocol that is the only EGP (External Gateway Protocol) protocol. This protocol is used to build routing on the Internet. Consider how a neighborhood is built between two BGP routers.
Consider the neighborhood between Router1 and Router3. Configure them with 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 10 Neighborhood within one autonomous system - AS 10. After entering data on a router, for example, on Router1, this router tries to set up a neighborhood relationship with Router3. The initial state when nothing happens is called Idle . As soon as bgp is configured on Router1, it starts listening to TCP port 179 - switches to the Connect state, and when it tries to open a session with Router3, it switches to the Active state.
')
After the session is established between Router1 and Router3, Open messages are exchanged. When this message sends Router1, this status will be called Open Sent . And when it receives an Open message from Router3, it will go to the Open Confirm state. Let us consider in more detail the message Open:
This message conveys information about the BGP protocol itself, which the router uses. By exchanging Open messages, Router1 and Router3 communicate with each other information about their settings. The following parameters are passed:
To establish a neighborhood, the following conditions must be met:
- Version : this includes the BGP version that the router is using. This is a mismatch of the current version of the BGP.
- It will be your iBGP or eBGP.
- It is a time for a BGP session to hold a BGP. Cisco IOS has been set to 180 seconds on the IOS routers, it has been sent every 60 seconds. There will be a BGP session.
- BGP Identifier : OSPF does not: BGP router ID:
- Use the router-id command that was configured with the bgp router-id command.
- Use the highest IP address on a loopback interface.
- Use the highest IP address on the physical interface.
- Optional Parameters : here you can find the BGP router. This would have been added to 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.
- Version number Current version 4.
- The AS number must match the fact that you configured neighbor 192.168.13.3 remote-as 10 .
- Router ID must be different from the neighbor.
If any of the parameters does not satisfy these conditions, the router will send a Notification message, where it will indicate an error. After sending and receiving Open messages, the neighborhood relationship enters the ESTABLISHED state. After that, routers can already exchange information about routes and do it with Update messages. This Update message sends Router1 to Router3:
Here indicate the networks reported by Router1 and Path attributes, which are analogous to metrics. We'll talk about Path attributes in more detail. Also inside the TCP session, keepalive messages are transmitted. They are transmitted, by default, every 60 seconds. This is a keepalive timer. If during the Hold Timer a keepalive message is not received, it will mean a loss of communication with the neighbor. By default, it is 180 seconds.
Useful label:
It seems to understand how routers transmit information to each other, now we will try to understand the logic of the BGP protocol.
To announce any route to the BGP table, as in the IGP protocols, the network command is used, but the logic of the work is different. If in IGP, after specifying the route in the network command, the IGP looks at which interfaces belong to this subnet and includes them in its table, then the network command in BGP looks at the routing table and looks for an exact match with the route in the network command. When finding such, these routes will fall into the BGP table.
This is the IP address of the network router; if the IP route exists, put the equivalent NLRI into the local BGP table.Now we will raise BGP on all the remaining ones and see how the route is selected within one AS. After the BGP router receives routes from a neighbor, the choice of the optimal route begins. Here we need to understand what kind of neighbors can be - internal and external. Does the configuration router understand whether the configured neighbor is internal or external? If in command:
neighbor 192.168.13.3 remote-as 10 as the remote-as parameter, the AS is specified, which is configured on the router itself in the router bgp 10 command. Routes coming from the internal AS are considered internal, and routes from the external AS are considered external. And in relation to each different logic of receiving and sending works. Consider this topology:
Each router has a loopback interface configured with ip: xxxx 255.255.255.0 - where x is the number of the router. On Router9 we have a loopback interface with the address - 9.9.9.9 255.255.255.0. We will announce it on BGP and see how it is distributed. This route will be transmitted to Router8 and Router12. With Router8, this route will go to Router6, but it will not be on Router5 in the routing table. Also on Router12, this route will go to the table, but it will not be on Router11 either. Try to figure it out. Consider what data and parameters Router9 sends to its neighbors, reporting this route. The package 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 BGP routers must recognize these attributes. Must be present in all updates (update).
- Well-known discretionary — all BGP routers must recognize these attributes. May be present in updates (update), but their presence is not required.
- Optional transitive - may not be recognized by all BGP implementations. If the router does not recognize the attribute, it marks the update as partial (partial) and sends it further to its neighbors, preserving the unrecognized attribute.
- Optional non-transitive - may not be recognized by all BGP implementations. If the router does not recognize the attribute, the attribute is ignored and discarded when transferred to the neighbors.
BGP attribute examples:
- 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 will be interested in Origin, Next-hop, AS Path. Since the route passes between Router8 and Router9, that is, within the same AS, it is considered internal and we will pay attention to Origin.
Origin attribute - indicates how the route was obtained in the update. Possible attribute values:
- 0 - IGP: NLRI obtained within the original autonomous system;
- 1 - EGP: NLRI is learned using the Exterior Gateway Protocol (EGP). BGP predecessor, not used
- 2 - Incomplete: NLRI has been learned in some other way.
In our case, as seen from the packet, it is equal to 0. When this route is transmitted to Router12, then this code will have the code - 1.
Next, Next-hop. Next-hop attribute
- This is the IP address of the eBGP router through which the path to the destination network goes.
- The attribute changes when a prefix is sent to another AS.
In the case of iBGP, that is, within one AS, Next-hop will be the one that has learned or told about this route. In our case, it will be 192.168.89.9. But when it will transmit this route from Router8 to Router6, Router8 will change it and replace it with its own. Next-hop will be - 192.168.68.8. This leads us to two rules:
- If the router sends a route to its internal neighbor, then it does not change the Next-hop setting.
- If the router forwards its route to its external neighbor, then it changes Next-hop to the ip of the interface from which this router is transmitting.
This leads us to understand the first problem - Why there will not be a route in the routing table on Router5 and Router11. Consider in more detail. So, Router6 received information about route 9.9.9.0/24 and safely 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 Now Router6 passed the Router5 route and did not change Next-hop to the first rule. That is, Router5 should add 9.9.9.0 [20/0] via 192.168.68.8 , but it does not have a route to 192.168.68.8 and therefore this route will not be added, although information about this route will be stored in the BGP table:
<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-Router12. To avoid such a situation, you need to configure that Router6 or Router12, passing the route to its internal neighbors, substitute your ip address as Next-hop. It is done with the help of the command:
neighbor 192.168.56.5 next-hop-self After this command, Router6 will send an Update message, where for routes as Next-hop, the ip of Gi0 / 0 Router6 interface will be specified - 192.168.56.6, after which this route will already fall into the routing table.
Go ahead and see if this route appears on Router7 and Router10. It will not appear in the routing table, and we might think that the problem is the same with the Next-hop parameter, but if we look at the output of the show ip bgp command, we will see that the route was not received even with the wrong Next-hop, that means that the route was not even transmitted. And this will lead us to the existence of another rule:
Routes received from internal neighbors are not transferred to other internal neighbors.Since Router5 received a route from Router6, it will not be transmitted to its other internal neighbor. In order for the transmission to occur, you must configure the Route Reflector function, or configure a fully meshed neighborhood relationship (Full Mesh), that is, Router5-7 will each be a neighbor with each. We will use Route Reflector in this case. On Router5, you must use this command:
neighbor 192.168.57.7 route-reflector-client The Route-Reflector changes the behavior of BGP when passing 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.
The route did not appear on Router7? Do not forget also about Next-hop. After these manipulations, the route should also on Router7, but this does not happen. This brings us to another rule:
The next-hop rule only works for External routes. For internal routes, the next-hop attribute is not replaced.
And we get a situation in which it is necessary to create an environment using static routing or IGP protocols to inform the routers of all routes within the AS. Let's assign static routes to Router6 and Router7 and then get the desired route in the router table. In AS 678, we will do a little differently - we will write static routes for 192.168.112.0/24 on Router10 and 192.168.110.0/24 on Router12. Next, we establish the neighborhood relationship between Router10 and Router12. Also configure on Router12 sending your next-hop for Router10:
neighbor 192.168.110.10 next-hop-self The bottom line is that Router10 will receive 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, two routes and an arrow (>) means that the route is chosen through 192.168.112.12.
Let's see how the process of choosing the route:
- First of all, when you receive a route, it checks the availability of its Next-hop. That is why, when we received the route to Router5 without setting Next-hop-self, this route was not further processed.
- Next is the Weight parameter. This parameter is not a Path Attribute (PA) and is not transmitted in BGP messages. It is configured locally on each router and is used only to manipulate route selection on the router itself. Consider an example. Just above, it shows that Router10 chose a route for 9.9.9.0/24 via Router12 (192.168.112.12). To change the Wieght parameter, you can use a route-map to set specific routes, or assign a weight to its neighbor using the command:
neighbor 192.168.107.7 weight 200
Now all routes from this neighbor will have that weight. Let's see how the choice of the route will change 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 i
As you can see, the route through Router7 is now selected, but it will not have any effect on other routers. - We are in third position - Local Preference. This parameter is a Well-known discretionary attribute, which means that its presence is optional. This parameter is valid only within one AS and affects the choice of the path only for internal neighbors. That is why it is transmitted only in Update messages intended for the internal neighbor. In Update messages for external neighbors, it is missing. Therefore, he was assigned to the Well-known discretionary. We will try to apply it on Router5. On Router5 we should have two routes for 9.9.9.0/24 - one through Router6 and the second through Router7.
We 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 i
But as we see one route through Router6. And where is the route through Router7? Maybe it is not on Router7? We look: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 i
Strange, everything seems to be in order. Why is it not transmitted to Router5? The fact is that BGP has a rule:The router transmits only those routes that it uses itself.
Router7 uses the route through 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 will react to this: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, into which all routes fall and told Router7, so that when it receives, it changes the Local Preference parameter to 250, the default is 100. We look at 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 i
As we can see now Router5 prefers a route through Router7. The same picture will be on Router6, although it is more profitable for him to choose a route through Router8. We also add that changing this parameter requires restarting the neighborhood for the change to take effect. Read here . With Local Preference sorted out. Go to the next parameter. - Prefer route with Next-hop 0.0.0.0, that is, local or aggregated routes. These routes automatically after entering the network command are assigned the Weight parameter equal to the maximum - 32678:
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 is selected. The smaller the number of AS passes the route, the better it is. 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 i
As you can see, Router10 chose a route through 192.168.112.12 because for this route the parameter AS_Path contains only 45, and in the other case 123 and 45. Intuitively understandable. - The next parameter is Origin. IGP (route obtained using BGP) is better than EGP (route obtained using BGP predecessor, now not used), and EGP better Incomplete? (obtained by some other method, for example, redistribution).
- The next parameter is MED. We had a Wieght that worked only locally on the router. There was a Local Preference, which worked only within one autonomous system. As you might guess, MED is a parameter that will be transmitted between autonomous systems. Very good article about this parameter.
No more attributes will be used, but if the two routes are the same, then the following rules are used:
- Choose a path through the nearest IGP neighbor.
- Select the oldest route for the eBGP path.
- Select the path through the neighbor with the lowest BGP router ID.
- Select the path through the neighbor with the smallest IP address.
Now consider the issue of convergence of BGP.
Let's see what happens if we allow Router6 to lose route 9.9.9.0/24 through Router9. Disable the Gi0 / 1 Router6 interface, which will immediately realize that the BGP session with Router8 is broken and the neighbor is gone, and therefore the route received from it is not valid. Router6 immediately sends Update messages, where it indicates the 9.9.9.0/24 network in the Withdrawn Routes field. As soon as Router5 receives a similar message, send it to Router7. But since Router7 has a route through Router10, then in response, it immediately sends an Update with a new route. If you fail to detect a neighbor’s fall due to the interface status, then you have to wait for the Hold Timer to work.
Confederation.
If you remember, we talked about the fact that often we have to use a fully connected topology. With a large number of routers in one AS, this can cause big problems, to avoid this you need to use confederations. One AS is divided into several sub-AS, which allows them to work without the requirement of a fully connected topology.
Here is a link to this lab , and here is the configuration for GNS3.
For example, with this topology, we would have to connect all the routers in AS 2345 to each other, but using Confederation, we can only establish neighborhood relations between the routers directly connected to each other. Let's talk about this in detail. If we only had AS 2345, then laForge would get a route from Picard to tell it to Data and Worf routers , but they wouldn’t tell Crusher about it . Also, the routes that the laForge router itself spreads would not be passed by the Crusher to either Worf or Data .
You would have to tweak the Route-Reflector or fully connected neighborhood relationships. By breaking one AS 2345 into 4 sub-AS (2,3,4,5) for each router, we end up with a different operation logic. Everything is perfectly described here .
sources:
Source: https://habr.com/ru/post/450814/
All Articles