10-09-2016 12:24 AM - edited 03-05-2019 07:14 AM
Hello Experts,
Trying to reach CE-B2 Lo from CE-B1 using mpls vpn, with static routing bw CE-PE. Could you please help me
Configs and screenshot attached.
CE-B1 -> PE1 ->P1 -> PE2 -> CE-B2
VRF B
I see packets reaching to PE1 from CE-B1
CE-B1#ping 7.7.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Solved! Go to Solution.
10-09-2016 05:56 AM
Hi,
Your PEs loopback mask needs to be /32.
https://supportforums.cisco.com/discussion/12924891/loopback-interface-32-ldp-work
Regards,
Nicolas
10-09-2016 05:56 AM
Hi,
Your PEs loopback mask needs to be /32.
https://supportforums.cisco.com/discussion/12924891/loopback-interface-32-ldp-work
Regards,
Nicolas
10-09-2016 09:02 AM
Thanks Nicolas,
Earlier, On P1 observed Bytes Tag switched were "0".
Could you tell other ways to identify that Label switching is not working ?
10-09-2016 01:09 PM
Yes,
In fact what is happening is that OSPF is advertising the loopbacks with a /32 mask (default ospf type loopback), but the 2 PEs are advertising a label to P1 (using LDP) with the correct mask. When P1 receives the label mapping infos from the PEs it cannot find a match in its routing table since it has OSPF routes with /32. That's why P1 does not allocate any label to the loopbacks in the LFIB:
P1#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
18 No Label 4.4.4.4/32 835 Fa1/0 34.34.34.4
19 No Label 2.2.2.2/32 689 Fa0/0 23.23.23.2
Normally the PEs should instruct P1 to POP the topmost label (transport label) of the stack letting the last label (VPN label) intact when transmitting the packet. If you see "No Label" it means all labels are removed before transmitting the packets. The packets are then sent to the PE untagged and the PE doesn't know in which VRF to forward since it doesn't see any VPN label.
You can also verify this while you debug mpls packets on P1, you will see only "RX" packets arriving but 0 MPLS packets leaving ("no "TX").
You can also use OAM (enabled by default on IOS) to verify the state of the LSP between the 2 PEs and you will see that the LSP is broken on P1:
PE1#traceroute mpls ipv4 4.4.4.4 255.255.255.255
Tracing MPLS Label Switched Path to 4.4.4.4/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'l' - Label switched with FEC change, 'd' - see DDMAP for return code,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 23.23.23.2 MRU 1500 [Labels: 18 Exp: 0]
B 1 23.23.23.3 MRU 1504 [No Label] 32 ms
B 2 23.23.23.3 MRU 1504 [No Label] 40 ms
B 3 23.23.23.3 MRU 1504 [No Label] 40 ms
B 4 23.23.23.3 MRU 1504 [No Label] 32 ms
.....
To solve this you can either restore the masks of the PEs loopbacks to /32 or change the OSPF network type of these loopbacks to point-to-point.
You can then try again these last commands (also the debugging on P1) and you will see the difference.
Best Regards,
Nicolas.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide