Darren's Blog

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 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 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 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 i

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:

R9#sh ip ospf 
 Routing Process "ospf 1" with ID 9.9.9.9
 
        SPF algorithm executed 3 times

R3#sh ip ospf 
 Routing Process "ospf 1" with ID 3.3.3.3
 
        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 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.9
 
        SPF 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.3
 
        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