May 8, 2019 at 09:35How BGP Works
Today we look at the BGP protocol. We will not talk for a long time why it is and why it is used as the only protocol. Quite a lot of information is 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 the neighborhood between two BGP routers is built. Consider the neighborhood between Router1 and Router3. We will configure them using the following commands:
The neighborhood within one autonomous system is 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 will start listening to TCP port 179 - it will go into the Connect state , and when it tries to open a session with Router3, it will go into the Active state .
After the session is established between Router1 and Router3, an Open message exchange takes place. When this message is sent by Router1, this state will be called Open Sent . And when it receives an Open message from Router3, it will go into the Open Confirm state. Consider the Open message in more detail: This message conveys information about the BGP protocol itself, which the router uses. By exchanging Open messages, Router1 and Router3 communicate information about their settings to each other. The following parameters are passed:
If any of the parameters does not satisfy these conditions, the router will send a Notification message where it indicates an error. After sending and receiving Open messages, the neighborhood relationship enters the ESTABLISHED state . After that, routers can exchange information about routes and do this using Update messages. Here is an Update message that sends Router1 to Router3:
Here indicate the networks reported by Router1 and Path attributes, which are analogous to metrics. We will talk about Path attributes in more detail. Also, keepalive messages are transmitted within the TCP session. They are transmitted, by default, every 60 seconds. This is a Keepalive Timer. If the Keepalive message is not received during the Hold Timer, this will mean loss of communication with the neighbor. By default, it is equal to - 180 seconds.
Useful plate: It seems to have figured out how the routers transmit information to each other, now let's try to understand the logic of the BGP protocol.
To advertise a route to the BGP table, as in the IGP protocols, the network command is used, but the logic of operation is different. If in IGP, after specifying the route in the network command, IGP looks at which interfaces belong to this subnet and includes them in its table, then the network command in BGP looks in the routing table and looks for an exact match with the route in the network command. If you find these, 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 that come from the internal AS are considered internal, and routes from the external AS are considered external. And with respect to each, a different logic of receiving and sending works. Consider the following 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 on Router5 it will not be in the routing table. Also, on Router12 this route will get into the table, but on Router11 it will not be either. Let's try to figure it out. Consider what data and parameters are being transmitted by Router9 to its neighbors, reporting 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:
Examples of BGP attributes:
In this case, we will be interested in Origin, Next-hop, AS Path. Since the route passes between Router8 and Router9, that is, inside the same AS, it is considered internal and pay attention to Origin.
Origin attribute - indicates how the route was received in the update. Possible attribute values:
In our case, as can be seen from the packet, it is 0. When this route is transmitted to Router12, this code will have the code - 1.
Next, Next-hop. Next-hop Attribute
In the case of iBGP, that is, inside one AS, Next-hop will be indicated the one that learned or told about this route. In our case, it will be 192.168.89.9. But when it will transfer 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 be no route in the routing table on Router5 and Router11. Let's consider in more detail. So, Router6 received route information 9.9.9.0/24 and safely added it to the routing table:
Now Router6 passed the route to Router5 and did not change the first Next-hop 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. In order to avoid such a situation, it is necessary to configure so that Router6 or Router12, passing the route to their internal neighbors, substitute their IP address as Next-hop. It is done using the command:
After this command, Router6 will send an Update message, where for the routes as Next-hop the ip of the Gi0 / 0 interface of Router6 will be indicated - 192.168.56.6, after which this route will already be in the routing table.
Let's 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 like in the first one with the Next-hop parameter, but if we look at the output of the show ip bgp command, we will see that the route there was not received even with the wrong Next-hop, which means that the route was not even transmitted. And this will lead us to the existence of another rule:
Route-Reflector changes the behavior of BGP when transmitting a route to an internal neighbor. If the internal neighbor is specified as route-reflector-client , then internal routes will be announced to these clients.
Did the route not appear on Router7? Do not forget about Next-hop as well. After these manipulations, the route should be on Router7, but this does not happen. This brings us to another rule:
And we get a situation in which you need to create an environment using static routing or IGP to inform routers about all the routes inside the AS. We will register the static routes on Router6 and Router7 and after that we will get the desired route in the table of the router. In AS 678, we will act a little differently - we will write the 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. We also configure Router12 to send its next-hop for Router10:
The 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 makes:
As we can see, two routes and an arrow (>) mean that the route through 192.168.112.12 is selected.
Let's see how the route selection process takes place:
More attributes will not be used, but if the two routes have the same attributes, then the following rules are used:
Now consider the issue of BGP convergence.
Let's see what happens if, for example, Router6 loses route 9.9.9.0/24 through Router9. We turn off the Gi0 / 1 Router6 interface, which immediately understands that the BGP session with Router8 is disconnected and the neighbor is gone, which means that the route received from it is not valid. Router6 immediately sends Update messages where it indicates the network 9.9.9.0/24 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, it will immediately send Update with a new route in response. If the neighbor’s fall cannot be detected by the state of the interface, then you have to wait for the Hold Timer to trigger.
Confederation.
If you remember, then we talked about the fact that you often have to use a fully connected topology. With a large number of routers in one AS, this can cause big problems, to avoid this it is necessary to use confederations. One AS is divided into several sub-ASs, which allows it 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 such a topology, we would have to connect all the routers in AS 2345 with each other, but using Confederation, we can establish neighborhood relations only between routers directly connected to each other. Let's talk about this in detail. If we had only AS 2345, then laForge received a marshour from
Picard would have told his Data and Worf routers , but they would not have told the Crusher about it . Also, the routes that laForge router itself distributes would not be transmitted by Crusher to either Worf or Data .
I would have to set up a Route-Reflector or fully connected neighborhood relationship. By breaking one AS 2345 into 4 sub-ASs (2,3,4,5) for each router, we end up with a different logic of operation. 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 the neighborhood between two BGP routers is built. Consider the neighborhood 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 10The neighborhood within one autonomous system is 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 will start listening to TCP port 179 - it will go into the Connect state , and when it tries to open a session with Router3, it will go into the Active state .
After the session is established between Router1 and Router3, an Open message exchange takes place. When this message is sent by Router1, this state will be called Open Sent . And when it receives an Open message from Router3, it will go into the Open Confirm state. Consider the Open message in more detail: This message conveys information about the BGP protocol itself, which the router uses. By exchanging Open messages, Router1 and Router3 communicate information about their settings to each other. 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. The current version of BGP is version 4 which is described in RFC 4271. Two BGP routers will try to negotiate a compatible version, when there is a mismatch then there will be no BGP session.
- My AS : this includes the AS number of the BGP router, the routers will have to agree on the AS number (s) and it also defines if they will be running iBGP or eBGP.
- Hold Time : if BGP doesn't receive any keepalive or update messages from the other side for the duration of the hold time then it will declare the other side 'dead' and it will tear down the BGP session. By default the hold time is set to 180 seconds on Cisco IOS routers, the keepalive message is sent every 60 seconds. Both routers have to agree on the hold time or there won't be a BGP session.
- BGP Identifier : this is the local BGP router ID which is elected just like OSPF does:
- 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.
- Version number. Current version 4.
- The AS number must match the one you configured neighbor 192.168.13.3 remote-as 10 .
- The 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 indicates an error. After sending and receiving Open messages, the neighborhood relationship enters the ESTABLISHED state . After that, routers can exchange information about routes and do this using Update messages. Here is an Update message that sends Router1 to Router3:
Here indicate the networks reported by Router1 and Path attributes, which are analogous to metrics. We will talk about Path attributes in more detail. Also, keepalive messages are transmitted within the TCP session. They are transmitted, by default, every 60 seconds. This is a Keepalive Timer. If the Keepalive message is not received during the Hold Timer, this will mean loss of communication with the neighbor. By default, it is equal to - 180 seconds.
Useful plate: It seems to have figured out how the routers transmit information to each other, now let's try to understand the logic of the BGP protocol.
To advertise a route to the BGP table, as in the IGP protocols, the network command is used, but the logic of operation is different. If in IGP, after specifying the route in the network command, IGP looks at which interfaces belong to this subnet and includes them in its table, then the network command in BGP looks in the routing table and looks for an exact match with the route in the network command. If you find these, these routes will fall into 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 we’ll raise BGP to all the remaining ones and see how the route is selected inside one AS. After the BGP router receives routes from the neighbor, the selection of the optimal route begins. Here you need to understand what kind of neighbors can be - internal and external. Does the configuration router understand if the configured neighbor is internal or external? If in a team:
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 that come from the internal AS are considered internal, and routes from the external AS are considered external. And with respect to each, a different logic of receiving and sending works. Consider the following 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 on Router5 it will not be in the routing table. Also, on Router12 this route will get into the table, but on Router11 it will not be either. Let's try to figure it out. Consider what data and parameters are being transmitted by Router9 to its neighbors, reporting 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 BGP routers must recognize these attributes. Must be present in all updates.
- Well-known discretionary — All BGP routers must recognize these attributes. They may be present in updates, but their presence is not necessary.
- Optional transitive - may not be recognized by all BGP implementations. If the router does not recognize the attribute, it marks the update as partial and sends it further to the neighbors, preserving the unrecognized attribute.
- Optional non-transitive - may not be recognized by all BGP implementations. If the router does not recognize the attribute, then the attribute is ignored and is discarded when transmitted 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 will be interested in Origin, Next-hop, AS Path. Since the route passes between Router8 and Router9, that is, inside the same AS, it is considered internal and pay attention to Origin.
Origin attribute - indicates how the route was received in the update. Possible attribute values:
- 0 - IGP: NLRI obtained inside the original autonomous system;
- 1 - EGP: NLRI learned by the Exterior Gateway Protocol (EGP). BGP predecessor, not used
- 2 - Incomplete: NLRI was learned in some other way
In our case, as can be seen from the packet, it is 0. When this route is transmitted to Router12, 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 the prefix is passed to another AS.
In the case of iBGP, that is, inside one AS, Next-hop will be indicated the one that learned or told about this route. In our case, it will be 192.168.89.9. But when it will transfer 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 passes the route to its internal neighbor, then it does not change the Next-hop parameter.
- If the router sends the route to its external neighbor, 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 be no route in the routing table on Router5 and Router11. Let's consider in more detail. So, Router6 received route information 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:25Now Router6 passed the route to Router5 and did not change the first Next-hop 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:
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 iThe same situation will occur between Router11-Router12. In order to avoid such a situation, it is necessary to configure so that Router6 or Router12, passing the route to their internal neighbors, substitute their IP address as Next-hop. It is done using the command:
neighbor 192.168.56.5 next-hop-selfAfter this command, Router6 will send an Update message, where for the routes as Next-hop the ip of the Gi0 / 0 interface of Router6 will be indicated - 192.168.56.6, after which this route will already be in the routing table.
Let's 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 like in the first one with the Next-hop parameter, but if we look at the output of the show ip bgp command, we will see that the route there was not received even with the wrong Next-hop, which 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 the route from Router6, it will not be transmitted to its other internal neighbor. In order for the transfer to occur, you need to configure the Route Reflector function , or configure fully-connected neighborhood relations (Full Mesh), that is, Router5-7 each will be a neighbor to each. We will use the Route Reflector in this case. On Router5, you must use this command:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector changes the behavior of BGP when transmitting a route to an internal neighbor. If the internal neighbor is specified as route-reflector-client , then internal routes will be announced to these clients.
Did the route not appear on Router7? Do not forget about Next-hop as well. After these manipulations, the route should be 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 you need to create an environment using static routing or IGP to inform routers about all the routes inside the AS. We will register the static routes on Router6 and Router7 and after that we will get the desired route in the table of the router. In AS 678, we will act a little differently - we will write the 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. We also configure Router12 to send its next-hop for 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 makes:
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 (>) mean that the route through 192.168.112.12 is selected.
Let's see how the route selection process takes place:
- First of all, upon receiving the route, the availability of its Next-hop is checked. That is why, when we received a route on Router5 without setting up Next-hop-self, this route was not further submitted for processing.
- Next comes 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. It is shown above that Router10 chose the route for 9.9.9.0/24 via Router12 (192.168.112.12). To change the Wieght parameter, you can use route-map to set specific routes, or assign weight to its neighbor using the command:
neighbor 192.168.107.7 weight 200
Now all routes from this neighbor will have such weight. Let's see how the route choice 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 i
As you can see, the route through Router7 is now selected, but this will not have any effect on the other routers. - In third place we have - 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 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 absent. Therefore, he was assigned to the Well-known discretionary. Let's 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 doesn’t even exist 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 being transmitted to Router5? The thing is that BGP has a rule:The router transmits only those routes that it uses.
Router7 uses the route through Router5, so the route through Router10 will not be transmitted. Back to the local preference. Let's set the Local Preference on Router7 and see how Router5 responds 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
So, we created a route-map into which all routes fall into and told Router7 to change the Local Preference parameter to 250 upon receipt, by default it 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 see now, Router5 prefers the 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 changes to this parameter require a restart of the neighborhood for the change to take effect. Read here . With Local Preference sorted out. Go to the next parameter. - Route preference with Next-hop parameter 0.0.0.0, i.e. local or aggregated routes. After entering the network command, these routes are automatically 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 parameter AS_Path is selected. The less AS the route passes through, 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 the route through 192.168.112.12 because for this route the AS_Path parameter contains only 45, and in the other case 123 and 45. Intuitively. - The next parameter is Origin. Is IGP (route obtained using BGP) better than EGP (route obtained using predecessor BGP, now not used), and EGP is better than Incomplete? (received in some other way, for example, by redistribution).
- The next parameter is MED. We had Wieght, which only worked locally on the router. There was a Local Preference that worked only within one autonomous system. As you might guess, MED is a parameter that will be transmitted between autonomous systems. Very good article on this option.
More attributes will not be used, but if the two routes have the same attributes, then the following rules are used:
- Choose a path through the nearest IGP neighbor.
- Select the oldest route for the eBGP path.
- Choose a path through the neighbor with the lowest BGP router ID.
- Choose a path through the neighbor with the lowest IP address.
Now consider the issue of BGP convergence.
Let's see what happens if, for example, Router6 loses route 9.9.9.0/24 through Router9. We turn off the Gi0 / 1 Router6 interface, which immediately understands that the BGP session with Router8 is disconnected and the neighbor is gone, which means that the route received from it is not valid. Router6 immediately sends Update messages where it indicates the network 9.9.9.0/24 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, it will immediately send Update with a new route in response. If the neighbor’s fall cannot be detected by the state of the interface, then you have to wait for the Hold Timer to trigger.
Confederation.
If you remember, then we talked about the fact that you often have to use a fully connected topology. With a large number of routers in one AS, this can cause big problems, to avoid this it is necessary to use confederations. One AS is divided into several sub-ASs, which allows it 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 such a topology, we would have to connect all the routers in AS 2345 with each other, but using Confederation, we can establish neighborhood relations only between routers directly connected to each other. Let's talk about this in detail. If we had only AS 2345, then laForge received a marshour from
Picard would have told his Data and Worf routers , but they would not have told the Crusher about it . Also, the routes that laForge router itself distributes would not be transmitted by Crusher to either Worf or Data .
I would have to set up a Route-Reflector or fully connected neighborhood relationship. By breaking one AS 2345 into 4 sub-ASs (2,3,4,5) for each router, we end up with a different logic of operation. Everything is perfectly described here .
Sources: