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 (click image for full size topology):
The routers are the same that are in my topology that I normally use. The only thing that will change will be the IP addressing so it’ll be easier to see what’s going on. The topology can be found here: http://mellowd.co.uk/ccie/?p=243
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 22.214.171.124, R4 is 126.96.36.199 and so on. All iBGP and intra-confederation peers will be peered using the loopback IP addresses.
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# router bgp 100 no synchronization bgp log-neighbor-changes network 188.8.131.52 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 184.108.40.206 mask 255.255.255.255 neighbor 220.127.116.11 remote-as 10 neighbor 18.104.22.168 update-source Loopback0 neighbor 192.168.1.1 remote-as 100 no auto-summary ! router ospf 1 log-adjacency-changes network 22.214.171.124 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 126.96.36.199 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 188.8.131.52 mask 255.255.255.255 neighbor 184.108.40.206 remote-as 10 neighbor 220.127.116.11 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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 remote-as 30 neighbor 188.8.131.52 ebgp-multihop 2 neighbor 184.108.40.206 update-source Loopback0 neighbor 220.127.116.11 remote-as 10 neighbor 18.104.22.168 ebgp-multihop 2 neighbor 22.214.171.124 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 126.96.36.199 0.0.0.0 network 10.1.1.36 0.0.0.3 auto-summary ! router ospf 1 log-adjacency-changes network 188.8.131.52 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 184.108.40.206 remote-as 30 neighbor 220.127.116.11 update-source Loopback0 no auto-summary
R4# router ospf 1 log-adjacency-changes network 18.104.22.168 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 22.214.171.124 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 126.96.36.199 mask 255.255.255.255 neighbor 188.8.131.52 remote-as 30 neighbor 184.108.40.206 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 220.127.116.11 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 * 18.104.22.168/32 192.168.1.1 0 100 0 (10) 100 i * 22.214.171.124/32 126.96.36.199 0 100 0 (10) i r> 188.8.131.52/32 184.108.40.206 0 100 0 (10) i *> 10.10.10.10/32 0.0.0.0 0 32768 i * 220.127.116.11/32 18.104.22.168 0 100 0 (30) i * 22.214.171.124/32 172.20.1.12 0 100 0 (30) 200 i
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#sh ip bgp BGP table version is 20, local router ID is 126.96.36.199 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> 188.8.131.52/32 184.108.40.206 0 100 0 (20 10) i r> 10.10.10.10/32 10.10.10.10 0 100 0 (20) i r>i220.127.116.11/32 18.104.22.168 0 100 0 i *>i22.214.171.124/32 172.20.1.12 0 100 0 200 i
R3 can see that the IP 126.96.36.199 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 188.8.131.52
SPF algorithm executed 3 times
R3#sh ip ospf Routing Process "ospf 1" with ID 184.108.40.206
SPF 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 220.127.116.11 255.255.255.255 R9(config-if)#router ospf 1 R9(config-router)#network 18.104.22.168 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 22.214.171.124
SPF algorithm last executed 00:00:56.144 ago SPF algorithm executed 4 times
R3#sh ip ospf Routing Process "ospf 1" with ID 126.96.36.199
SPF 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
Just got back from the testing centre now. I passed :)
I’m surprised at how easy these CCIP exams seem so far. All of these 642 exams seem pretty easy compared to the BSCI. I think mainly because there is just so much to learn for that exam and you’re expected to pretty much know the right things about everything.
This now gives me time to do some more more tutorials here on the site instead of just putting labs up. I’ll concentrate and dissecting technologies (mainly BGP first) and I’ll then move to MPLS when I start more in-depth studying for my final CCIP exam
So far the majority of my site is labs I’ve created for myself for practice. My BGP exam is coming soon hence a lot of BGP labs. I’d like to move more into the tutorial side of things eventually. I might take a few of my labs and explain how I’ve come to the solution fully explaining everything. I might also create a few posts about various parts of various technologies (like route-maps, distribute-lists and so on)
I’d also like to change the theme of this site. Perhaps white on black isn’t the easiest to read (or so I’ve heard) I’m going to try and find a nice theme and then the look will change completely.
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 12:
- AS7, AS9 and AS11 are all customers of ISP1
- AS7 has it’s own address space – 188.8.131.52/24 advertised via a loopback
- ISP1 owns the address space 184.108.40.206/16
- AS9 has been assigned 220.127.116.11/24 from ISP1 – insert via loopback
- AS11 has been assigned 18.104.22.168/24 from ISP1 – insert via loopback
- Ensure that AS7′s address space is advertised to AS9 and AS11
- ISP1 needs to advertise the entire 22.214.171.124/16 range and not the more specific routes. Ensure AS7 sees only 126.96.36.199/16 HOWEVER it must still know that some routes have come from AS9 and AS11
- On AS9, configure an attribute so that ISP1 does not advertise the more specific 188.8.131.52/24 address to anyone.
- You should notice that ISP1 is now not advertising the aggregate because it has inherited the no-export community from above
- Now on ISP1, ensure that the community is changed so that the aggregate can be advertised again
Click on the thumbnail for the full size topology: