During your BGP studies, you’ll come across BGP confederations a couple of times. There are a few things that are easy to miss, and I’d like to clear it up here.
This will be both theory and practical, and I’ll be using this topology to explain things:
R1 config:
R8′s config is like so. The BGP process must be configured under the Sub-AS number. In this case AS 10. The peer connectino between ISP1 and our company will NOT come up until I tell R8 that it should identify itself to ISP1 as being in AS 65535. As soon as the confederation identifier is in place, the peer connection will come up. BGP confederation peers just tells the router itself which AS’s are intra-confederation peers. If you do not add this then the router will assume any AS different to the one it’s using itself will be a full eBGP peer.
I’ve also added the next hop addresses into OSPF so I don’t need to use next-hop-self.
To do a quick check on the peer connection, have a look here:
The peer is up, and as far as R1 is concerned, R8 is in AS 65535
R2 is simply running OSPF and nothing else:
Router 9 is running BGP, OSPF and EIGRP – I wouldn’t do this in the real world. It’s simply to prove a point later. It’s also peered with AS20, a Sub-AS. There is an important thing to note here. Basically iBGP sessions do not need the ‘ebgp-multihop’ command. iBGP peers do NOT have to be directly connected. When Sub-AS’s connect to each other they DO need it though otherwise the peer will simply not come up. You can see that the peer config to R8 does not have it while the peer config to R10 does have it. This is the config:
Router10 is peered with 2 other Sub-AS’s. It’s also running EIGRP:
R3, R4, R11 and R12 are more of the same of what’s just been done. I’ll post just the configs here.
Now there are a couple things we need to note about these special BGP peerings. Usually, the next-hop address will change when an update is given to an eBGP peer. If we check R10′s BGP table though, we can see that the next-hop addresses have NOT changed: (192.168.1.1 is R1′s IP address; 172.20.1.12 is R12′s)
That means updates to confederation peers will have the next-hop stay the same. You need to ensure that those next hop addresses are known by all confederation peers otherwise you’ll get what I have above, most have no valid route.
If we check the BGP table on R3, we see the following:
R3 can see that the IP 9.9.9.9 came through AS 20 and 10, even though all routers are in the same major AS.
The last thing I’d like to point out is the split of the IGP (OSPF in this case) Both Sub-AS 10 and 30 are running OSPF area 0. We can see how many times the SPF algorithm has run in each:
Let’s force the algorithm to run again by adding another loopback on Router9 and advertising it into OSPF:
If we now check the SPF algorithm again in Both Sub-AS’s:
We can see in Sub-AS 10 the SPF algorithm ran 56 seconds ago. In Sub-AS 30 however, it has not forced the algorithm to run again, proving that these IGP domains are completely separate from each other.
So that’s the basics of Confederations. They can be very useful for a number of reasons. Just be sure to remember how exactly they operate. Any questions, feel free to ask
This will be both theory and practical, and I’ll be using this topology to explain things:
Our company, AS 65535 has a multitude of routers running BGP in our core.
N.B: R2 and R4 will NOT be running BGP at all. We are connected to 2 ISP’s – AS100 and AS200. We are also running OSPF internally inside the organisation.
BGP confederations allow your BGP deployment to scale quite nicely internally. Remember the rule of BGP split horizon – i.e. a BGP router learning a route from an iBGP peer will not advertise that to another iBGP peer. Confederations can help with this, as each intra-confederation connection is actually a special eBGP peering and not a regular iBGP peer.
BGP confederations can also help with splitting up your IGP domains. IGP’s like EIGRP or OSPF cannot scale to gigantic routing table sizes. IGP’s also put more emphasis on convergence speed as opposed to stability like BGP. I know the topology I have is no-where near big enough, but it does allow me to show you how it splits these IGP domains. I am going to run OSPF in both Sub-AS 10 and 30, as well as EIGRP in 10, 20 and 30 so I can seperate the OSPF portion out completely. I am going to be running OSPF in area 0 in Sub-AS 10 as well as in 30, but these will be completely independent of each other.
Each router has a loopback which will be advertised. R1 is 1.1.1.1, R4 is 4.4.4.4 and so on. All iBGP and intra-confederation peers will be peered using the loopback IP addresses.
Configuring:
The ISP itself will have a normal BGP config, nothing special needs to be done. You do need to ensure you are configuring a peer with AS 65535. ISP1 and ISP2 do not know anything about the fact that we are running a confederation.R1 config:
R1# router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 neighbor 192.168.1.8 remote-as 65535 no auto-summary
R8′s config is like so. The BGP process must be configured under the Sub-AS number. In this case AS 10. The peer connectino between ISP1 and our company will NOT come up until I tell R8 that it should identify itself to ISP1 as being in AS 65535. As soon as the confederation identifier is in place, the peer connection will come up. BGP confederation peers just tells the router itself which AS’s are intra-confederation peers. If you do not add this then the router will assume any AS different to the one it’s using itself will be a full eBGP peer.
R1# router bgp 10 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 20 30 network 8.8.8.8 mask 255.255.255.255 neighbor 9.9.9.9 remote-as 10 neighbor 9.9.9.9 update-source Loopback0 neighbor 192.168.1.1 remote-as 100 no auto-summary ! router ospf 1 log-adjacency-changes network 8.8.8.8 0.0.0.0 area 0 network 10.1.1.16 0.0.0.3 area 0 network 192.168.1.0 0.0.0.255 area 0
I’ve also added the next hop addresses into OSPF so I don’t need to use next-hop-self.
To do a quick check on the peer connection, have a look here:
R1#sh ip bgp sum Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.1.8 4 65535 17 17 4 0 0 00:10:06 1
The peer is up, and as far as R1 is concerned, R8 is in AS 65535
R2 is simply running OSPF and nothing else:
R2# router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 10.1.1.16 0.0.0.3 area 0 network 10.1.1.20 0.0.0.3 area 0
Router 9 is running BGP, OSPF and EIGRP – I wouldn’t do this in the real world. It’s simply to prove a point later. It’s also peered with AS20, a Sub-AS. There is an important thing to note here. Basically iBGP sessions do not need the ‘ebgp-multihop’ command. iBGP peers do NOT have to be directly connected. When Sub-AS’s connect to each other they DO need it though otherwise the peer will simply not come up. You can see that the peer config to R8 does not have it while the peer config to R10 does have it. This is the config:
R9# router bgp 10 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 20 30 network 9.9.9.9 mask 255.255.255.255 neighbor 8.8.8.8 remote-as 10 neighbor 8.8.8.8 update-source Loopback0 neighbor 10.10.10.10 remote-as 20 neighbor 10.10.10.10 ebgp-multihop 2 neighbor 10.10.10.10 update-source Loopback0 no auto-summary ! router ospf 1 log-adjacency-changes network 9.9.9.9 0.0.0.0 area 0 network 10.1.1.20 0.0.0.3 area 0 network 10.1.1.96 0.0.0.3 area 0 ! router eigrp 1 network 9.9.9.9 0.0.0.0 network 10.1.1.96 0.0.0.3 no auto-summary
Router10 is peered with 2 other Sub-AS’s. It’s also running EIGRP:
#R10 router bgp 20 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 30 network 10.10.10.10 mask 255.255.255.255 neighbor 3.3.3.3 remote-as 30 neighbor 3.3.3.3 ebgp-multihop 2 neighbor 3.3.3.3 update-source Loopback0 neighbor 9.9.9.9 remote-as 10 neighbor 9.9.9.9 ebgp-multihop 2 neighbor 9.9.9.9 update-source Loopback0 no auto-summary ! router eigrp 1 network 10.1.1.36 0.0.0.3 network 10.1.1.96 0.0.0.3 network 10.10.10.10 0.0.0.0 no auto-summary
R3, R4, R11 and R12 are more of the same of what’s just been done. I’ll post just the configs here.
#R3 R3#sh run | begin eigrp router eigrp 1 network 3.3.3.3 0.0.0.0 network 10.1.1.36 0.0.0.3 auto-summary ! router ospf 1 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 10.1.1.36 0.0.0.3 area 0 network 10.1.1.44 0.0.0.3 area 0 ! router bgp 30 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 20 neighbor 10.10.10.10 remote-as 20 neighbor 10.10.10.10 ebgp-multihop 2 neighbor 10.10.10.10 update-source Loopback0 neighbor 11.11.11.11 remote-as 30 neighbor 11.11.11.11 update-source Loopback0 no auto-summary
R4# router ospf 1 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 10.1.1.44 0.0.0.3 area 0 network 10.1.1.52 0.0.0.3 area 0
#R11 router ospf 1 log-adjacency-changes network 10.1.1.52 0.0.0.3 area 0 network 11.11.11.11 0.0.0.0 area 0 network 172.20.1.0 0.0.0.255 area 0 ! router bgp 30 no synchronization bgp log-neighbor-changes bgp confederation identifier 65535 bgp confederation peers 10 20 network 11.11.11.11 mask 255.255.255.255 neighbor 3.3.3.3 remote-as 30 neighbor 3.3.3.3 update-source Loopback0 neighbor 172.20.1.12 remote-as 200 no auto-summary
#R12 router bgp 200 no synchronization bgp log-neighbor-changes network 12.12.12.12 mask 255.255.255.255 neighbor 172.20.1.11 remote-as 65535 no auto-summary
Now there are a couple things we need to note about these special BGP peerings. Usually, the next-hop address will change when an update is given to an eBGP peer. If we check R10′s BGP table though, we can see that the next-hop addresses have NOT changed: (192.168.1.1 is R1′s IP address; 172.20.1.12 is R12′s)
R10#sh ip bgp
BGP table version is 8, local router ID is 10.10.10.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.1/32 192.168.1.1 0 100 0 (10) 100 i
* 8.8.8.8/32 8.8.8.8 0 100 0 (10) i
r> 9.9.9.9/32 9.9.9.9 0 100 0 (10) i
*> 10.10.10.10/32 0.0.0.0 0 32768 i
* 11.11.11.11/32 11.11.11.11 0 100 0 (30) i
* 12.12.12.12/32 172.20.1.12 0 100 0 (30) 200 iThat means updates to confederation peers will have the next-hop stay the same. You need to ensure that those next hop addresses are known by all confederation peers otherwise you’ll get what I have above, most have no valid route.
If we check the BGP table on R3, we see the following:
R3#sh ip bgp
BGP table version is 20, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 9.9.9.9/32 9.9.9.9 0 100 0 (20 10) i
r> 10.10.10.10/32 10.10.10.10 0 100 0 (20) i
r>i11.11.11.11/32 11.11.11.11 0 100 0 i
*>i12.12.12.12/32 172.20.1.12 0 100 0 200 iR3 can see that the IP 9.9.9.9 came through AS 20 and 10, even though all routers are in the same major AS.
The last thing I’d like to point out is the split of the IGP (OSPF in this case) Both Sub-AS 10 and 30 are running OSPF area 0. We can see how many times the SPF algorithm has run in each:
R9#sh ip ospf Routing Process "ospf 1" with ID 9.9.9.9SPF algorithm executed 3 times
R3#sh ip ospf Routing Process "ospf 1" with ID 3.3.3.3SPF algorithm executed 7 times
Let’s force the algorithm to run again by adding another loopback on Router9 and advertising it into OSPF:
R9#conf t Enter configuration commands, one per line. End with CNTL/Z. R9(config)#int lo2 R9(config-if)#ip address 99.99.99.99 255.255.255.255 R9(config-if)#router ospf 1 R9(config-router)#network 99.99.99.99 0.0.0.0 area 0
If we now check the SPF algorithm again in Both Sub-AS’s:
R9#sh ip ospf Routing Process "ospf 1" with ID 9.9.9.9SPF algorithm last executed 00:00:56.144 ago SPF algorithm executed 4 times
R3#sh ip ospf Routing Process "ospf 1" with ID 3.3.3.3SPF algorithm last executed 00:27:18.572 ago SPF algorithm executed 7 times
We can see in Sub-AS 10 the SPF algorithm ran 56 seconds ago. In Sub-AS 30 however, it has not forced the algorithm to run again, proving that these IGP domains are completely separate from each other.
So that’s the basics of Confederations. They can be very useful for a number of reasons. Just be sure to remember how exactly they operate. Any questions, feel free to ask
No comments:
Post a Comment