BGP, OSPF, and Loopback Interfaces

BGP, OSPF, AND LOOPBACK INTERFACES

Thursday September 29, 2016

I have been working on a lab topology that uses BGP externally, and OSPF as the IGP. While working on this I found something interesting. A LAN network could not be advertised into BGP, even though the neighbours were forming correctly.

Below is a simplified topology to explain.

R1 is an ISP router which runs BGP only. R2 is the customer’s edge router, running BGP and OSPF. R3 is an internal router running OSPF only. R3 uses a loopback interface to simulate the 10.0.0.0 /24 network.

OSPF is configured on R3 and R2. R3 advertises the 10.0.0.0 /24 network.

R3 – OSPF

router ospf 10
  network 10.0.0.0 0.0.0.255 area 0 network 172.16.1.0 0.0.0.3 area 0

R2 – OSPF

router ospf 10
 network 172.16.1.0 0.0.0.3 area 0

BGP is configured on R1 and R2. R2 advertises the 10.0.0.0 /24 network to the ISP

R1 – BGP

router bgp 20
 bgp log-neighbor-changes
 neighbor 172.16.0.2 remote-as 10

R2 – BGP

router bgp 10
 bgp log-neighbor-changes
 network 10.0.0.0 mask 255.255.255.0
 neighbor 172.16.0.1 remote-as 20

Looking at R1, there is a BGP neighbour (R2), but there are no prefixes.

R1 – BGP Summary

R1#sh ip bgp summary 
BGP router identifier 172.16.0.1, local AS number 20 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.0.2 4 10 16 16 1 0 0 00:11:32 0

This happens because the route for 10.0.0.0 /24 is not in the routing table on R2, which prevents R2 from advertising it in BGP:

R2 – Routing table

R2#sh ip route
Output omitted 
10.0.0.0/32 is subnetted, 1 subnets O 10.0.0.1 110/2 via 172.16.1.2, 00:16:02, GigabitEthernet0/2 
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 
  C 172.16.0.0/30 is directly connected, GigabitEthernet0/1 
  L 172.16.0.2/32 is directly connected, GigabitEthernet0/1 C 172.16.1.0/30 is directly connected, GigabitEthernet0/2 L 172.16.1.1/32 is directly connected, GigabitEthernet0/2

Notice how 10.0.0.0/32 is in the routing table, but 10.0.0.0 /24 is not? Turns out that this happens due to the usage of the loopback interface. Loopbacks are intended to be used for specific IP address (that is, /32 networks), so when this is added into OSPF, it is added as a /32, not a /24.

The reason this happens is because of the OSPF network type for loopback interfaces:

R3 – Loopback

R3#sh ip ospf interface lo0 
Loopback0 is up, line protocol is up Internet Address 10.0.0.1/24, Area 0, Attached via Network Statement Process ID 10, Router ID 10.0.0.1, Network Type LOOPBACK, Cost: 1 Topology-MTID Cost Disabled Shutdown Topology Name 0 1 no no Base Loopback interface is treated as a stub Host

If we change the network type to something else, such as point-to-point, this behaviour will change:

R3 – OSPF

R3(config)#int loopback 0
R3(config-if)#ip ospf network point-to-point

This can be seen correctly in the routing table of R2:

R2 – Routing Table

R2#sh ip route 
Output omitted 
10.0.0.0/24 is subnetted, 1 subnets O 10.0.0.0 110/2 via 172.16.1.2, 00:00:28, GigabitEthernet0/2 
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 
  C 172.16.0.0/30 is directly connected, GigabitEthernet0/1 
  L 172.16.0.2/32 is directly connected, GigabitEthernet0/1 
  C 172.16.1.0/30 is directly connected, GigabitEthernet0/2 
  L 172.16.1.1/32 is directly connected, GigabitEthernet0/2

And as this is now in the routing table on R2, it can be advertised into BGP:

R1 – BGP Summary

R1#sh ip bgp summary 
BGP router identifier 172.16.0.1, local AS number 20 BGP table version is 2, main routing table version 2 1 network entries using 144 bytes of memory 1 path entries using 80 bytes of memory 1/1 BGP path/bestpath attribute entries using 152 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 400 total bytes of memory BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 172.16.0.2 4 10 33 32 2 0 0 00:25:51 1

While this is very interesting in a lab, it’s not likely to become an issue in production, as loopback interfaces will generally only be used for specific IP addresses.