Today we will 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. There is a lot of information on this subject, for example .
So what is BGP? BGP is a dynamic routing protocol and 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. Set them up 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 10Neighborhood within the same autonomous system - AS 10. After entering data on a router, for example, Router1, this router tries to set up a neighbor relationship with Router3. The initial state when nothing happens is called Idle. As soon as bgp is configured on Router1, it will start listening on TCP port 179 - it will go into the state Connect, and when it tries to open a session with Router3, it will go to the state Active.
After the session is established between Router1 and Router3, Open messages are exchanged. 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 switch to the state open confirm. Let's take a closer look at the Open message:
This message conveys information about the BGP protocol itself, which is used by the router. By exchanging Open messages, Router1 and Router3 communicate information about their settings to each other. The following parameters are passed:
- 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.
To establish a neighborhood, the following conditions must be met:
- version number. The current version is 4.
- The AS number must match what 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, then the router will send Notification message indicating the error. After sending and receiving Open messages, the neighborhood relationship enters the state ESTABLISHED. After that, routers can already exchange information about routes and do this using Update messages. This is the Update message sent by 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. Keepalive messages are also sent within the TCP session. They are transmitted, by default, every 60 seconds. This is the Keepalive Timer. If a Keepalive message is not received during the Hold Timer, this will mean a loss of communication with the neighbor. By default, it is equal to 180 seconds.
Useful sign:
It seems that we figured out how routers transmit information to each other, now let's try to figure out the logic of the BGP protocol.
To announce some 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, the IGP looks at which interfaces belong to this subnet and includes them in its table, then the network command in BGP looks into the routing table and looks for accurate match the route in the network command. If such routes are found, 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 let's raise BGP to all the remaining ones and see how the route is selected within one AS. After the BGP router receives routes from the neighbor, then the selection of the optimal route begins. Here you need to understand what kind of neighbors can be - internal and external. Does the router understand by configuration whether the configured neighbor is internal or external? If in a team:
neighbor 192.168.13.3 remote-as 10 as the remote-as parameter, an 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 in relation 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 router number. On Router9, we have a loopback interface with the address - 9.9.9.9 255.255.255.0. We will announce it over BGP and see how it spreads. This route will be passed to Router8 and Router12. From Router8, this route will get to Router6, but it will not be in the routing table on Router5. Also on Router12, this route will be included in the table, but it will not be on Router11 either. Let's try to figure this out. Let's consider what data and parameters are transmitted by Router9 to its neighbors, reporting this route. The packet below will be sent from Router9 to Router8.
The 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 and forwards it to neighbors, keeping 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 discarded when forwarded to 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 transmits between Router8 and Router9, that is, within the same AS, it is considered internal and let's pay attention to Origin.
The Origin attribute indicates how the route was obtained in the update. Possible attribute values:
- 0 - IGP: NLRI received within the source autonomous system;
- 1 - EGP: NLRI learned using the Exterior Gateway Protocol (EGP). Predecessor of BGP, 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 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, within one AS, the Next-hop will be indicated by the one that learned or told about this route. In our case, it will be 192.168.89.9. But when it transfers 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 a router forwards a route to its inner neighbor, then it does not change the Next-hop parameter.
- If the router sends the route to its external neighbor, then it changes the Next-hop to the ip of the interface from which this router sends.
This brings us to the understanding of the first problem - Why won't there be a route in the routing table on Router5 and Router11. Let's consider 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>
Π’Π΅ΠΏΠ΅ΡΡ Router6 ΠΏΠ΅ΡΠ΅Π΄Π°Π» ΠΌΠ°ΡΡΡΡΡ Router5 ΠΈ ΠΏΠ΅ΡΠ²ΠΎΠΌΡ ΠΏΡΠ°Π²ΠΈΠ»Ρ Next-hop Π½Π΅ ΠΈΠ·ΠΌΠ΅Π½ΠΈΠ». Π’ΠΎ Π΅ΡΡΡ, Router5 Π΄ΠΎΠ»ΠΆΠ΅Π½ Π΄ΠΎΠ±Π°Π²ΠΈΡΡ <b>9.9.9.0 [20/0] via 192.168.68.8</b> , Π½ΠΎ Ρ Π½Π΅Π³ΠΎ Π½Π΅Ρ ΠΌΠ°ΡΡΡΡΡΠ° Π΄ΠΎ 192.168.68.8 ΠΈ ΠΏΠΎΡΡΠΎΠΌΡ Π΄Π°Π½Π½ΡΠΉ ΠΌΠ°ΡΡΡΡΡ Π΄ΠΎΠ±Π°Π²Π»Π΅Π½ Π½Π΅ Π±ΡΠ΄Π΅Ρ, Ρ
ΠΎΡΡ ΠΈΠ½ΡΠΎΡΠΌΠ°ΡΠΈΡ ΠΎ Π΄Π°Π½Π½ΠΎΠΌ ΠΌΠ°ΡΡΡΡΡΠ΅ Π±ΡΠ΄Π΅Ρ Ρ
ΡΠ°Π½ΠΈΡΡΡΡ Π² ΡΠ°Π±Π»ΠΈΡΠ΅ BGP:
<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 happen between Router11-Router12. To avoid this situation, you need to configure that Router6 or Router12, when passing the route to their internal neighbors, substitute their ip address as the Next-hop. It is done with 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 of the Gi0 / 0 interface of Router6 - 192.168.56.6, after which this route will already be included 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 was not received there 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 learned from internal neighbors are not propagated 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 must configure the function , or set up a fully connected neighborhood relationship ( 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 need to use this command:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector changes the behavior of BGP when passing a route to an internal neighbor. If the inner neighbor is specified as route-reflector-client, internal routes will be advertised to these clients.
Route not showing up on Router7? Don't forget about Next-hop as well. After these manipulations, the route should also 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 it is necessary to create an environment using static routing or IGP protocols to inform routers about all routes within the AS. We will write static routes on Router6 and Router7 and after that we will 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 will establish a neighborhood relationship 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 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, there are two routes and an arrow ( > ) means that the selected route is through 192.168.112.12.
Let's see how the route selection process works:
- First of all, when getting a route, the availability of its Next-hop is checked. That is why, when we received a route on Router5 without setting Next-hop-self, this route was not further processed.
- Next comes the Weight parameter. This parameter is not a Path Attribute ( PA ) and is not carried in BGP messages. It is configured locally on each router and is only used to manipulate route selection on the router itself. Let's consider an example. Just above, Router10 has chosen a 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 certain routes for certain routes, or assign a weight to its neighbor using the command:
neighbor 192.168.107.7 weight 200Now all routes from this neighbor will have this 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 iAs you can see, the route through Router7 is now selected, but this will not have any effect on other routers.
- In the third position we have - Local Preference. This parameter is a Well-known discretionary attribute, which means that its presence is optional. This setting is only valid within a single AS and only affects path selection for internal neighbors. That is why it is only sent in Update messages destined for the inner neighbor. It is missing from Update messages for external neighbors. 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 iBut 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 iStrange, everything seems to be in order. Why is it not transmitted to Router5? The thing is that BGP has a rule:
The router transmits only those routes that it uses itself.
Router7 uses a route through Router5, so the route through Router10 will not be transmitted. Let's go back to Local Preference. Let's set Local Preference on Router7 and see how Router5 reacts to it:
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 includes all routes and told Router7 to change the Local Preference parameter to 250 when received, the default is 100. Let's 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 iAs we can 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 changing this parameter requires restarting the neighborhood for the change to take effect. Read . We figured out Local Preference. Let's move on to the next option.
- Route preference with Next-hop 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 AS_Path parameter is chosen. The fewer ASs a 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 iAs 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 clear.
- The next parameter is Origin. IGP (route derived from BGP) is better than EGP (route derived from BGP's predecessor, now retired), but EGP is better than Incomplete? (obtained in some other way, such as redistribution).
- The next parameter is MED. We had Wieght, which only worked locally on the router. There was Local Preference, which only worked within the same autonomous system. As you might guess, MED is a parameter that will be passed between autonomous systems. Very good about this setting.
No more attributes will be used, but if 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 let's say Router6 loses route 9.9.9.0/24 through Router9. Let's disable the Gi0 / 1 interface of Router6, which will immediately understand that the BGP session with Router8 is broken and the neighbor is gone, which means that the route received from it is not valid. Router6 immediately sends Update messages, where it specifies the network 9.9.9.0/24 in the Withdrawn Routes field. As soon as Router5 receives such a message, it will send it to Router7. But since Router7 has a route through Router10, it will immediately send an Update with a new route in response. If it is not possible to detect the fall of a neighbor by the state of the interface, then you will have to wait for the Hold Timer to work.
Confederation.
If you remember, we talked about the fact that you often have to use a fully meshed topology. With a large number of routers in one AS, this can be a big problem, 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 meshed topology.
Here is a link to this , configuration for GNS3.
For example, with this topology, we would have to link all routers in AS 2345 to each other, but using Confederation, we can only establish neighbor relationships between routers that are directly connected to each other. Let's talk about this in detail. If we only had AS 2345, then laForge received a route from Picard would tell his routers Data ΠΈ Worf, but they wouldn't tell the router about it Crusher . Also the routes that the router itself propagates laForge, would not be transferred Crusher nor Worfoh, no Data.
You would have to set up a Route-Reflector or a fully connected neighborhood relationship. By splitting one AS 2345 into 4 sub-ASs (2,3,4,5) for each router, we end up with a different work logic. Everything is well described .
Sources:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Site
- Site .
Source: habr.com