%BGP-4-VPNV4NH_MASK and OSPF advertising loopback as /32 by default

Recently when doing some MPLS VPN lab work I came across the error

%BGP-4-VPNV4NH_MASK: Nexthop 4.4.4.4 may not be reachable from neigbor 2.2.2.2 - not /32 mask

It occurs because by default OSPF advertises loopback interfaces with a /32 mask even if you have configured another mask e.g. /24! This is the expected way for OSPF to work and is defined under RFC2328 section 9.1 (page 67).  This default behavior can be changed by isssing the ip ospf network point-to-point under the loopback interface config mode.

I was running ospf as the IGP between my P/PE routers in the MPLS backbone and using loopback interfaces on the PE routers for BGP updates and for testing. I did make these interfaces use a /24 mask.  So for PE1 my config was as follows

PE1#show run
interface loopback 0
ip address 2.2.2.2 255.255.255.0
....
router ospf 1
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 0

Checking the routing table on the second router would show that a /32 mask has been advertised for the 2.2.2.2 network rather than 2.2.2.0/24 as I had intended.

PE2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/3] via 192.168.34.3, 00:13:55, FastEthernet1/0

It is therefore not as I intended in the mpls forwarding table as a /24 either

PE2#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     16          2.2.2.2/32 0          Fa1/0      192.168.34.3
17     Untagged    3.3.3.3/32 0          Fa1/0      192.168.34.3
18     Pop tag     192.168.23.0/24 0          Fa1/0      192.168.34.3

Its very easy to resolve though buy issuing the ip ospf network point-to-point command under the interface config mode.

PE1#show run
interface loopback 0
ip address 2.2.2.2 255.255.255.0
ip ospf network point-to-poin
....
router ospf 1
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 0

Now we can check the routing table and the mplf forwarding table are correct and the error %BGP-4-VPNV4NH_MASK no longer appears.

PE2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/3] via 192.168.34.3, 00:01:17, FastEthernet1/0

PE2#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 3.3.3.3/32 0 Fa1/0 192.168.34.3
21 18 2.2.2.0/24 0 Fa1/0 192.168.34.3

Basically just remember OSPF always advertises loopbacks with a /32 unless manually told otherwise.

m00nie 🙂

Comments

  • Hi, m00nie. I’ve stumbled upon this same problem. The fix works but I don’t get why that would be an issue.
    If your next hop in MPLS backbone is 2.2.2.2, what is real difference if you have in your MPLS and CEF entry for 2.2.2.2./32 or 2.2.2.0/24 which are completely identical (next hop, tags, etch)? Shouldn’t it still be reachable?

  • Hi Vadim

    Its basically how things are laid down in the RFC linked in the post. They next hop etc would be the same like you say but it wouldnt be compliant with the standard:

    “If the state of the interface is Loopback, add a Type 3 link (stub network) as long as this is not an interface to an unnumbered point-to-point network. The Link ID should be set to the IP interface address, the Link Data set to the mask 0xffffffff (indicating a host route) and the cost set to 0.”

    But no “real” difference from our point of view in this exercise I think 🙂
    Cheers

    m00nie

  • Since I’ve asked that question I’ve made additional research and that’s what i came up with in one sentence: “LDP discards any incoming labels for prefixes that are not in it’s routing table”.
    Lets look at situation between two routers:
    1) R1 and R2 are OSPF and LDP neighbours, lets look through R1’s eyes
    2) R2 sends OSPF update for 2.2.2.2/32, because RFC is a dick and wants to ruin our lives 🙂
    3) R1 receives it and installs in our routing table.
    4) R2 sends LDP tag for 2.2.2.2/24 and R1 has no entry for that broad subnet and thus just drops that tag announce
    5) LSP is broken, life is sour.