08-17-2009 12:38 PM - edited 03-06-2019 07:17 AM
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.
Solved! Go to Solution.
08-17-2009 01:31 PM
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
08-17-2009 12:52 PM
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
!
08-17-2009 01:31 PM
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
08-17-2009 01:52 PM
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.
08-17-2009 02:01 PM
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
08-17-2009 02:20 PM
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.
08-17-2009 05:28 PM
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?
08-17-2009 07:15 PM
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
08-18-2009 05:54 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: