BGP, OSPF, and Loopback Interfaces

Table Of Contents

BGP, OSPF, and Loopback Interfaces

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 10network 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

R1 – BGP Summary

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

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 1Neighbor 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

R2 – Routing table

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#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.

R3 – Loopback

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

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

R3 – OSPF

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

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

R2 – Routing Table

This can be seen correctly in the routing table of R2

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

R1 – BGP Summary

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

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.