Advanced Cisco Routing -- BGP and OSPF

If you wish to configure network gear for Service Provider networks, or even for Enterprise networks in large enough companies, you will eventually need to understand BGP. While I have worked for Service Providers for my entire professional career, I have never had the opportunity to work with BGP. However, due to some changes in my current work environment, I realized that I would need to come up to speed on BGP in the fairly near future, so I decided it was time to start playing with that particular routing protocol.

First, a little background. In my earlier Cisco and Juniper posts, we've discussed setting up and configuring OSPF, RIP, and EIGRP, so it might be reasonable to ask, what's so different about BGP? Without getting into too much detail, the bottom line is that the other routing protocols are designed for use within a single provider's network. You might have a lot of routers and a lot of routes, but the Internet's routing tables (for example) are much, much larger than your internal routing tables -- far too big, in fact, to fit on just about any router if you are using one of these protocols. BGP is the answer to this problem. It was designed to efficiently store and share very, very large routing tables on service provider networks. Consequently, you most often (but not exclusively!) see BGP on routers that are sharing publicly accessible routes on the Internet. It is important to note that BGP comes in two flavors: iBGP (internal BGP) that is used to share routes among your own networks, much like the routing protocols we have alread discussed; and eBGP (external BGP), which is used to share routes among other organizations. For this post, we will be discussing eBGP exclusively.

So, let's get started!

Here is the network that I created in GNS3:

Why GNS3 rather than a real hardware network? Well, first, I built this while at work (it was a slow day, and it is work-related learning), and second, because I have had to tear down my Cisco lab at home for reasons I'm sure you don't want to read about now :) Besides...I tried to get GNS3 to work a little while ago and failed, so I figured it was time to figure out how to make this puppy sing! It really wasn't all that difficult, but it did require some non-intuitive experimentation with settings until I got everything working.

Anyway, here's the description of the topology:

R1 and R2 are my core routers on this network -- they are the ones doing the BGP peering with each other. R1 is using AS64512 and R2 is using AS64513. Those AS numbers are not entirely random; they are, in fact, the first two private, reserved AS numbers according to the RFC's (think RFC-1918 for BGP autonomous system numbers, and you'll be pretty close). In GNS3, it doesn't really matter, but if you want to build BGP routers with real iron that might ever be connected to the Internet, you should probably use an AS number in the range 64512 - 65535 until/unless you get a real AS number from ARIN.

R3 and R4 are edge routers connected to R1; R5 and R6 are likewise edge routers connected to R2. R1, R3 and R4 make up the autonomous system in OSPF area 42. R2, R5 and R6 make up the autonomous system in OSPF area 51.

Finally, these are the networks connected to each router:

Router	Interface	IP Address	Subnet Mask	Description
R1	fa0/0	10.0.0.1	255.255.255.252	Uplink to R2
R1	fa1/0	192.168.1.1	255.255.255.0	Uplink to R3
R1	fa3/0	192.168.2.1	255.255.255.0	Uplink to R4
R2	fa0/0	10.0.0.2	255.255.255.252	Uplink to R1
R2	fa1/0	172.16.1.1	255.255.255.252	Uplink to R5
R2	fa2/0	172.16.20.1	255.255.255.252	Uplink to R6
R3	e0/0	192.168.10.1	255.255.255.0	LAN
R3	fa1/0	192.168.1.2	255.255.255.0	Uplink to R1
R4	e0/0	192.168.20.1	255.255.255.0	LAN
R4	fa1/0	192.168.2.2	255.255.255.0	Uplink to R1
R5	e0/0	172.16.10.1	255.255.255.0	LAN
R5	fa1/0	172.16.1.2	255.255.255.252	Uplink to R1
R6	e0/0	172.16.20.1	255.255.255.0	LAN
R6	fa1/0	172.16.2.2	255.255.255.252	Uplink to R1

I started by configuring OSPF on R1, R3 and R4:
R1#sho run | begin router ospf 42
router ospf 42
router-id 10.0.0.1
log-adjacency-changes
network 192.168.1.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 0
!

R3#sho run | begin router ospf 42
router ospf 42
router-id 192.168.10.1
log-adjacency-changes
redistribute connected subnets
network 192.168.1.0 0.0.0.255 area 0
!

R4#sho run | begin router ospf 42
router ospf 42
router-id 192.168.20.1
log-adjacency-changes
redistribute connected subnets
network 192.168.2.0 0.0.0.255 area 0
!

Once I had verified that I was routing between these three routers, I configured OSPF on R2, R5 and R6:
R2#sho run | begin ospf 51
router ospf 51
router-id 10.0.0.2
log-adjacency-changes
network 172.16.1.0 0.0.0.3 area 0
network 172.16.2.0 0.0.0.3 area 0
!

R5#sho run | begin ospf 51
router ospf 51
router-id 172.16.10.1
log-adjacency-changes
redistribute connected subnets
network 172.16.1.0 0.0.0.3 area 0
network 172.16.10.0 0.0.0.255 area 0
!

R6#sho run | begin router ospf 51
router ospf 51
router-id 172.16.20.1
log-adjacency-changes
redistribute connected subnets
network 172.16.2.0 0.0.0.3 area 0
network 172.16.20.0 0.0.0.255 area 0
!


...and checked to make sure that I had routing between these three routers, which I did.
Note: if any of this does not look familiar to you, I'd highly recommend you take a look at my blog entries on OSPF here and here to come up to speed on OSPF before digging into BGP.

Next, I configured the BGP routing process between R1 and R2:
R1#sho run | begin router bgp
router bgp 64512
bgp log-neighbor-changes
neighbor 10.0.0.2 remote-as 64513
address-family ipv4
neighbor 10.0.0.2 activate
no auto-summary
no synchronization
exit-address-family
!

R2#sho run | begin router bgp
router bgp 64513
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 64512
address-family ipv4
neighbor 10.0.0.1 activate
no auto-summary
no synchronization
exit-address-family
!


First, note the AS numbers I mentioned earlier in the "router bgp..." command. In OSPF, we provide a process ID for the OSPF process; in BGP, we provide the AS number that we are advertising with BGP. We use those AS numbers on the very next line on the peer router to specify who we wish to be sharing routes with. Unlike OSPF, with BGP we specify the neighbor router(s) that we want to peer with. After that, we tell BGP what address family (IPv4, IPv6, etc.) that we will be advertising, and then we tell BGP to activate the peering session with our peer at <IP Address>. The rest of the lines were defaults automatically populated by IOS.

Unfortunately, at this point, I didn't see routes propagating between routers like I expected. After a little quality time with Google, I discovered that I hadn't told BGP what routes I wanted to share. Adding the line, "redistribute ospf 42 match internal external 1 external 2" on R1 and "redistribute ospf 51" on R2 solved that problem -- I was now able to see OSPF routes from the BGP peer showing up on R1 and R2.

Note: notice that R1 includes some extra syntax that R2 is missing on the "redistribute ospf..." statement. I don't have time right now to explain why that is necessary, but I'll try to add a post later to discuss what is different about the two networks.

However, all was not well in Mudville. When I got on the console for R6, I found that I could not ping R3 or R4. I ran "sho ip route" and found that, even though BGP had propagated routes from R1 onto R2 and vice versa, R2 hadn't shared those routes with R5 and R6, nor had R1 shared the routes learned through BGP with R3 and R4. That was because, even though I had told BGP to share OSPF routes (which it had), I hadn't told OSPF to share BGP routes! On R1, I added "redistribute bgp 64512 subnets" to the OSPF config, and on R2, I added "redistribute bgp 64513 subnets" which solved the problem. I could now ping any of the six routers from any of the five remaining routers.