cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
608
Views
5
Helpful
3
Replies
ajayreddy28390
Beginner

MPLS VPN CE-PE static routing

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)

1 ACCEPTED SOLUTION

Accepted Solutions
nicolas.vallet
Beginner

Hi,

Your PEs loopback mask needs to be /32.

https://supportforums.cisco.com/discussion/12924891/loopback-interface-32-ldp-work

Regards,

Nicolas

View solution in original post

3 REPLIES 3
nicolas.vallet
Beginner

Hi,

Your PEs loopback mask needs to be /32.

https://supportforums.cisco.com/discussion/12924891/loopback-interface-32-ldp-work

Regards,

Nicolas

View solution in original post

ajayreddy28390
Beginner

Thanks Nicolas,

Earlier, On P1 observed Bytes Tag switched were "0".

Could you tell other ways to identify that Label switching is not working ?

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.