%BGP-4-VPNV4NH_MASK: Nexthop

Wha?

Well I found some interesting stuff while trying to run OSPF as a IGP in a MPLS environment while peering BGP by loop back.  Here is the configuration keep in mind this is with INE’s topology.

ip vrf VPN_A
rd 1:1
route-target export 1:1
route-target import 1:1
!
router bgp 1
neighbor 150.1.1.1 remote-as 1
neighbor 150.1.1.1 update-source lo0
neighbor 150.1.2.2 remote-as 1
neighbor 150.1.2.2 update-source lo0
neighbor 150.1.3.3 remote-as 1
neighbor 150.1.3.3 update-source lo0
neighbor 150.1.4.4 remote-as 1
neighbor 150.1.4.4 update-source lo0
neighbor 150.1.5.5 remote-as 1
neighbor 150.1.5.5 update-source lo0
!
address-family vpnv4 unicast
neighbor 150.1.1.1 activate
neighbor 150.1.1.1 send-community both
neighbor 150.1.2.2 activate
neighbor 150.1.2.2 send-community both
neighbor 150.1.3.3 activate
neighbor 150.1.3.3 send-community both
neighbor 150.1.4.4 activate
neighbor 150.1.4.4 send-community both
neighbor 150.1.5.5 activate
neighbor 150.1.5.5 send-community both
!
address-family ipv4 vrf VPN_A
redistribute ospf 3 vrf VPN_A
no synchronization
exit-address-family
!
router ospf 3 vrf VPN_A
redistribute bgp 1 subnets

Then I get this message.. on Each PE router.

*Mar 1 17:10:19.575: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.1.1 may not be reachable from neigbor 150.1.2.2 – not /32 mask
*Mar 1 17:11:26.579: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.3.3 may not be reachable from neigbor 150.1.1.1 – not /32 mask
*Mar 1 17:11:55.683: %BGP-4-VPNV4NH_MASK: Nexthop 150.1.5.5 may not be reachable from neigbor 150.1.1.1 – not /32 mask

On a CE router.

Rack1SW2#sh ip route 155.1.67.7
Routing entry for 155.1.67.0/24
Known via “ospf 1”, distance 110, metric 3, type inter area
Last update from 155.1.58.5 on Vlan58, 00:04:55 ago
Routing Descriptor Blocks:
* 155.1.58.5, from 5.5.5.5, 00:04:55 ago, via Vlan58
Route metric is 3, traffic share count is 1

Traceroute

Rack1SW2#trace 155.1.67.6

Type escape sequence to abort.
Tracing the route to 155.1.67.6

1 155.1.58.5 0 msec 0 msec 9 msec
2 *

Looking over my MPLS forwarding table it appears that since OSPF by default will take my /24 loopback and advertise it by default as a /32 LDP gets confused.  It shows up in the tag switching table as a /24 but a /32 in the routing table.  The fix for this was making each loop back a point-to-point interface under the loopback via OSPF.  Im not sure how this would scale in a large service provider environment… this might even be a IOS bug not sure.

After the change…

Rack1SW2#trace 155.1.67.6

Type escape sequence to abort.
Tracing the route to 155.1.67.6

1 155.1.58.5 8 msec 0 msec 9 msec
2 155.1.146.1 0 msec 8 msec 0 msec
3 155.1.146.6 25 msec * 0 msec

One thing that someone might want to do to make sure that the Loopback is also the router-id as well so there are no problems is by issues the following command under global configuration.

Rack1R1(config)#mpls ldp router-id lo0 force

That way the router-id is always lo0.  By issuing force at the end of the statement it will drop all current ldp connectivity to the loopback.  So if you have MPLS sessions currently using another loopback or interface they will be dropped reinitialize and use lo0.  Otherwise without the force option the mpls neighbor x.x.x.x command will have to be used.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Khan Huzaifah  On October 7, 2015 at 6:06 pm

    Thanks a lot that really realy helped , I did wasted my whole day trying new new Images on GNS3 , thanks a lot buddy , bless you!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: