MPLS BGP VPNv4 Loopback Addressing

Hey Guys,

Playing with MPLS recently I have found an interesting error message and troubleshooting problem that I would like some help with. If the loopback interface of a PE router has anything other than a /32 netmask the VPNv4 dosn't work.  In fact, the router spits out an error message indicating that you might not have connectivity.  From the customer routers I have routes in the routing table but no reachability until I fix the loopback interface to have a /32 netmask.  Is this an MPLS requirement or a BGPv4 requirement? LDP protocl requirement?  Is there a way around it?

Also, it appears that there is no way around using loopback interfaces for VPNv4 PE - PE peering.  What's the reason for this?

From a troubleshooting perspective, any hints?  Everything appears normal from what I can see.  Of course, I'm sure I'm not looking at the right table output...

 

Thanks,

Micah

Comments

  • MPLS, whether TDP or LDP, will by default use the highest ip address configured on a loopback interface for peering, similar to OSPF. Like OSPF the LDP/TDP peering can be manually configured (mpls ldp router-id a.b.c.d|interface). This means that the loopback will need to be advertised via IGP - in the service provider world the IGP will need to be ISIS or OSPF to support Traffic Engineering Tunnels, but that is beyond the scope of R&S MPLS, so any R&S IGP can be used.

    As for the /32 - the mpls router-id is a 32-bit number, so it naturally correlates to a host route.

  • %BGP-4-VPNV4NH_MASK : Nexthop [IP_address] may not be reachable from neigbor [IP_address] - not /32 mask

    ExplanationA VPNv4 route is being sent to the IBGP neighbor. The address of the next hop is a loopback interface that does not have a /32 mask defined. OSPF is being used on this loopback interface, and the OSPF network type of this interface is LOOPBACK. OSPF advertises this IP address as a host route (with mask /32), regardless of what mask is configured. This advertising conflicts with TDP, which uses configured masks, so the TDP neighbors may not receive a tag for the route indicated in this error message. This condition could break connectivity between sites that belong to the same VPN.
    Recommended ActionConfigure the loopback that is being used as the next-hop loopback to use a 32-bit network mask (/32), or set the network type to point-to-point by entering the ip ospf network point-to-point command.
    The explanation is quite simple: OSPF announced the loopback IP addresses as host routes (/32). LDP was expecting to find a /24 address at the routing table. Since it couldn’t find it, it didn’t advertise a label for this FEC!!


    HTHs a little!

    -Adrian

    On Sep 11, 2009, at 12:02 AM, micah wrote:

    Hey Guys,

    Playing with MPLS recently I have found an interesting error message and troubleshooting problem that I would like some help with. If the loopback interface of a PE router has anything other than a /32 netmask the VPNv4 dosn't work.  In fact, the router spits out an error message indicating that you might not have connectivity.  From the customer routers I have routes in the routing table but no reachability until I fix the loopback interface to have a /32 netmask.  Is this an MPLS requirement or a BGPv4 requirement? LDP protocl requirement?  Is there a way around it?

    Also, it appears that there is no way around using loopback interfaces for VPNv4 PE - PE peering.  What's the reason for this?

    From a troubleshooting perspective, any hints?  Everything appears normal from what I can see.  Of course, I'm sure I'm not looking at the right table output...

     

    Thanks,

    Micah




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • thanks Adrian, good answer.

     

    %BGP-4-VPNV4NH_MASK : Nexthop [IP_address] may not be reachable from neigbor [IP_address] - not /32 mask

    ExplanationA VPNv4 route is being sent to the IBGP neighbor. The address of the next hop is a loopback interface that does not have a /32 mask defined. OSPF is being used on this loopback interface, and the OSPF network type of this interface is LOOPBACK. OSPF advertises this IP address as a host route (with mask /32), regardless of what mask is configured. This advertising conflicts with TDP, which uses configured masks, so the TDP neighbors may not receive a tag for the route indicated in this error message. This condition could break connectivity between sites that belong to the same VPN.
    Recommended ActionConfigure the loopback that is being used as the next-hop loopback to use a 32-bit network mask (/32), or set the network type to point-to-point by entering the ip ospf network point-to-point command.
    The explanation is quite simple: OSPF announced the loopback IP addresses as host routes (/32). LDP was expecting to find a /24 address at the routing table. Since it couldn’t find it, it didn’t advertise a label for this FEC!!


    HTHs a little!

    -Adrian



    On Sep 11, 2009, at 12:02 AM, micah wrote:


    Hey Guys,

    Playing with MPLS recently I have found an interesting error message and troubleshooting problem that I would like some help with. If the loopback interface of a PE router has anything other than a /32 netmask the VPNv4 dosn't work.  In fact, the router spits out an error message indicating that you might not have connectivity.  From the customer routers I have routes in the routing table but no reachability until I fix the loopback interface to have a /32 netmask.  Is this an MPLS requirement or a BGPv4 requirement? LDP protocl requirement?  Is there a way around it?

    Also, it appears that there is no way around using loopback interfaces for VPNv4 PE - PE peering.  What's the reason for this?

    From a troubleshooting perspective, any hints?  Everything appears normal from what I can see.  Of course, I'm sure I'm not looking at the right table output...

     

    Thanks,

    Micah





    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx





  • i beleive this behavior has been fixed in newer versions of IOS. correct me if im wrong.

  • i beleive this behavior has been fixed in newer versions of IOS. correct me if im wrong.

    Hello Yuri,

    This behavior is not fixed yet and not easy to fix if you clearly look on MPLS PHP process.

    Just for MPLS tunneling is okey (what ever subnet mask you use on Loopback interface):

    R4#show running-config interface lo0
    Building configuration...

    Current configuration : 64 bytes
    !
    interface Loopback0
     ip address 4.4.4.4 255.255.255.0
     !
    end

    R4#show ip bgp neighbors 45.45.45.5 advertised-routes
    BGP table version is 4, local router ID is 4.4.4.4
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

    Originating default network 0.0.0.0

       Network          Next Hop            Metric LocPrf Weight Path
    *>i1.1.1.1/32       2.2.2.2                  0    100      0 1 i

    Total number of prefixes 1
    !

    But for M-BGP VPNv4, you must have /32 mask, see here as soon as you activated vpnv4 peering, you will get this log message:

    R2(config-router)#address-family vpnv4
    R2(config-router-af)# neighbor 4.4.4.4 activate
    R2(config-router-af)# neighbor 4.4.4.4 send-community extended
    R2(config-router-af)#
    *Nov  3 07:00:11.683: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up
    R2(config-router-af)#
    *Nov  3 07:00:11.819: %BGP-4-VPNV4NH_MASK: Nexthop 2.2.2.2 may not be reachable from neigbor 4.4.4.4 - not /32 mask

    FYI this is my working GEEK: Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.0(1)M, RELEASE SOFTWARE (fc2)

    HAPPY STUDY

    [:D]

  • As stated by Adrian, the problem is because of prefix length mismatch between LDP and OSPF. To fix this, without changing Loopback interface subnet mask, we can use "ip ospf net point-to-p" under loopback interface so that OSPF advertises the same subnet mask that LDP uses.

    Or if we are allowed in the exam, we change the loopback subnet mask to /32.

  • Hi Yuri,

       In some IOS'es it may have a different behavior (i for sure used a 12.4 build which allowed this) , but anyways why on earth would you use a non /32 for a loopback? From "NNN" example, in 15.x is still there and alive :)

    Good luck with your studies!

  • but anyways why on earth would you use a non /32 for a loopback?

    For CCIE Lab Exam :)

  • lol...yhe alex....I would agree...spot on!!!

     

    they will use it , just because they can![:P]

  • friend can u explain me in simple words why this error was showing ??? [:)]

     

    *Nov  3 07:00:11.819: %BGP-4-VPNV4NH_MASK: Nexthop 2.2.2.2 may not be reachable from neigbor 4.4.4.4 - not /32 mask

  • ''The explanation is quite simple: OSPF announced the loopback IP addresses as host routes (/32). LDP was expecting to find a /24 address at the routing table. Since it couldn’t find it, it didn’t advertise a label for this FEC!!'

    ok if ospf and LDP have same mask /24 on loopback then what could happend?? [*-)]

  • OSPF will automatically advertise Loopback subnet mask as 32

Sign In or Register to comment.