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.
![](https://networkdirection.net/wp-content/uploads/Blog/BGP-OSPF-Loopback.png)
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
iproute
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 ospfinterface 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 noBase 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
ospfnetwork point-to-point
This can be seen correctly in the routing table of R2:
R2 – Routing Table
R2#sh
iproute
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 bgpsummary
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/
bestpathattribute 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.