Solved: MPLS VPN Lab Question

zztopping · ‎08-17-2009

I am setting up a small MPLS VPN Lab using two 6500s running SXI2, utilizing two VRFs. It worked beautifully when the next hop was the interface address of the other. Now I am having trouble using the attached configuration using next hop of loopbacks.

As you can see, BGP seems to be doing its job, propogating the routing table on each, but for some reason my VRF pings across the mpls link are failing(global pings work fine). Something tells me this is the problem:

Router#sh ip cef vrf TEST1 10.1.0.2

10.1.0.2/32

nexthop 10.255.255.2 Port-channel1 unusable: no label

Any help would be greatly appreciated. :-) See attachement for relevant configuration and show commands.

Peter Paluch · ‎08-17-2009

Hello,

Let's try to return to the config where your BGP routers were peered using their Loopback0 interface as that is the correct way to peer BGP routers, especially with MPLS VPNs.

The output of the "show mpls ldp binding" from the attached file suggests that the second router did not send you the label mapping for its 10.0.0.2/32 loopback address. Were the two routers successfully running the LDP protocol? Did they identify themselves correctly as LDP neighbors? That would be the first thing I would test right now. You absolutely need to see the output similar to this one:

tib entry: 10.0.0.2/32, rev 6

local binding: tag: 16

remote binding: tsr: 10.0.0.2:0, tag: imp-null

i.e. the "remote binding" line must be present. If we get this one, we may test it again and go further.

Best regards,

Peter

View solution in original post

zztopping · ‎08-17-2009

Here is a working config:

Switch1

ip vrf TEST1

rd 1:65001

route-target export 100:65001

route-target import 100:65001

!

ip vrf TEST2

rd 1:65002

route-target export 100:65002

route-target import 100:65002

!

interface Port-channel1

mtu 9216

ip address 10.255.255.1 255.255.255.248

no mls qos channel-consistency

mpls ip

!

interface Loopback0

ip address 10.0.0.1 255.255.255.255

!

interface Loopback1

ip vrf forwarding TEST1

ip address 10.1.0.1 255.255.255.255

!

interface Loopback2

ip vrf forwarding TEST2

ip address 10.2.0.1 255.255.255.255

!

router bgp 65001

no synchronization

bgp log-neighbor-changes

neighbor 10.255.255.2 remote-as 65001

neighbor 10.255.255.2 update-source Po1

no auto-summary

!

address-family vpnv4

neighbor 10.255.255.2 activate

neighbor 10.255.255.2 send-community both

exit-address-family

!

address-family ipv4 vrf TEST2

redistribute connected

no synchronization

exit-address-family

!

address-family ipv4 vrf TEST1

redistribute connected

no synchronization

exit-address-family

!

Peter Paluch · ‎08-17-2009

Hello,

Let's try to return to the config where your BGP routers were peered using their Loopback0 interface as that is the correct way to peer BGP routers, especially with MPLS VPNs.

The output of the "show mpls ldp binding" from the attached file suggests that the second router did not send you the label mapping for its 10.0.0.2/32 loopback address. Were the two routers successfully running the LDP protocol? Did they identify themselves correctly as LDP neighbors? That would be the first thing I would test right now. You absolutely need to see the output similar to this one:

tib entry: 10.0.0.2/32, rev 6

local binding: tag: 16

remote binding: tsr: 10.0.0.2:0, tag: imp-null

i.e. the "remote binding" line must be present. If we get this one, we may test it again and go further.

Best regards,

Peter

Edison Ortiz · ‎08-17-2009

You need an IGP running within the MPLS Core to advertise the loopbacks. I'm pretty sure if you issue a 'show mpls ldp neighbor', neither switch sees each other as neighbor as LDP advertises its LDP router ID as the transport address in LDP discovery hello messages sent from the interface. This router ID is the loopback.

You can change this behavior with the command: "mpls ldp discovery transport-address {interface | IP-address} "

http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m2.html#wp1012008

But I still recommend advertising the loopback under an IGP (OSPF or ISIS preferred).

HTH,

__

Edison.

Peter Paluch · ‎08-17-2009

Hello Edison,

It also struck me when I saw that Jonathan's configuration does not use any IGP. Still, if you go over his configuration carefully you will see that he has correctly defined the static routes for his loopbacks to be reachable. I have configured a similar topology a few minutes ago also using only the static routes instead of IGP, and the entire MPLS VPN worked for me. Therefore I assume that the lack of an IGP is not the cause of the problem here.

I was thinking that probably one of those routers had some strange LDP ID causing these two routers not becoming LDP neighbors. Therefore I suggested that Jonathan should first make sure that the LDP is up and running here.

Best regards,

Peter

Edison Ortiz · ‎08-17-2009

I did not see the attached file previously just the posted config. The attached file does indicate some static routing but we need to see if there is any static routing from the remote switch.

zztopping · ‎08-17-2009

Yes. Both switches can ping each others' global loopbacks (Lo0).

To clarify, the interface address as the next-hop was my original config, and my loopback is my current.

They are seeing each other as LDP neighbors, is there a good debug you recommend to ensure all are being exchanged?

zztopping · ‎08-17-2009

Started over with my config(its just a lab afterall) and it seems to work now.

Not sure what was wrong, but I'm glad I have the idea, and what I saw to be the problem you guys agreed upon it.

Thanks

Edison Ortiz · ‎08-18-2009

There are times the order of operations will affect the outcome, I believe if you would've rebooted both switches, the problem would've been solved as well.