BGP Confederations – How, What and Why.

On December 22, 2009, in CCIE, by Darren

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):

Confederations 150x150 BGP Confederations   How, What and Why.

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

Tagged with:  

642-661 BGP passed

On December 17, 2009, in Uncategorized, by Darren

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

Tagged with:  

Changes coming soon

On December 3, 2009, in Uncategorized, by Darren

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.

 

BGP Lab 12

On December 3, 2009, in CCIE, Dynamips, by Darren

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 – 77.48.16.0/24 advertised via a loopback
  • ISP1 owns the address space 180.16.0.0/16
  • AS9 has been assigned 180.16.9.0/24 from ISP1 – insert via loopback
  • AS11 has been assigned 180.16.11.0/24 from ISP1 – insert via loopback
  • Ensure that AS7′s address space is advertised to AS9 and AS11
  • ISP1 needs to advertise the entire 180.16.0.0/16 range and not the more specific routes. Ensure AS7 sees only 180.16.0.0/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 180.16.9.0/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:

BGP 12 150x150 BGP Lab 12

Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved