MPLS VPN CEs not able to ping another CE even with routes present

[Subhasis1992]

Hello,

Hope you all are doing well. I'm having issue with MPLS L3 VPN where I'm not getting ping reply from one CE to another CE where as routes are present in CE of another CE's. the IGP on the backbone is OSPF and using EIGRP to communicate between PE and CE. I have have attached the configs. Please suggest.

R 3 and R2 is  PE

R9 and R10 is CE

R1 is P

R9#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D 192.168.10.0/24 [90/158720] via 11.11.11.3, 01:07:41, FastEthernet2/0
22.0.0.0/24 is subnetted, 1 subnets
D 22.22.22.0 [90/30720] via 11.11.11.3, 01:09:00, FastEthernet2/0
9.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 9.9.9.0/24 is directly connected, Loopback0
D 9.0.0.0/8 is a summary, 01:05:56, Null0
D 192.168.20.0/24 [90/158720] via 11.11.11.3, 01:09:00, FastEthernet2/0
11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 11.11.11.0/24 is directly connected, FastEthernet2/0
D 11.0.0.0/8 is a summary, 01:05:56, Null0
R9#ping 22.22.22.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

[Harold Ritter]

Could you please attach the Packet Tracer (.pkt) in zip format?

Regards,

[Subhasis1992]

Hello Harold,

Hope you are doing well and thanks for your quick reply. I configure this network in GNS 3 (version : 2.2.20 windows). I'm sharing the file with you. 

Regards,

[Harold Ritter]

HI @Subhasis1992,

I am doing well, thanks. Hope you are doing well too. Thanks for the info.

As Giuseppe suggested you need to change the way you advertise the PEs loopback interfaces, but I would suggest advertising them as /32. The following change should be sufficient.

R2:

interface Loopback0
ip address 2.2.2.2 255.255.255.255

R3:

interface Loopback0
ip address 3.3.3.3 255.255.255.255

And also to remove the "mpls ip" from the CE facing interface (FE0/2) and from the CE interface as well, as LDP is not needed on the PE-CE link.

Regards,

[MHM Cisco World]

I see attach, it clear now.

[Giuseppe Larosa]

Hello @Subhasis1992 ,

an end to end MPLS LSP built by LDP is needed on the two PE nodes in order to have a working forwarding plane.

Looking at R2 configuration I see the following:

interface FastEthernet2/0
ip vrf forwarding 100
ip address 22.22.22.2 255.255.255.0
duplex half
mpls ip
!

mpls ip is needed not on the interface towards the CE node but on the interface toward the P node

interface FastEthernet0/0
ip address 30.30.30.2 255.255.255.0
duplex half
mpls ip
!

Check with

show mpls forwarding 3.3.3.3 on R2

on R2 you should see a value on the P node you should see POP TAG = implicit null if you see UNTAGGED it is not good.

under each loopback interface you need

interface loop

interface Loopback0
ip address 2.2.2.2 255.255.255.0

ip ospf network point-to-point
!

Do it on all devices . OSPF by default announce loopback as /32

Hope to help

Giuseppe

[Subhasis1992]

Hello Giuseppe,

Hope you are doing well and thanks for your quick reply. As you said to check the MPLS forwardin so I checked with your given command and getting this :

R2#sh mpls forwarding-table 3.3.3.3
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
20 Untagged 3.3.3.0/24 0 Fa0/0 30.30.30.1

Please suggest.

Regards,

[Giuseppe Larosa]

Hello @Subhasis1992 ,

>> R2#sh mpls forwarding-table 3.3.3.3
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
20 Untagged 3.3.3.0/24 0 Fa0/0 30.30.30.1

An untagged action is not a correct action in a working MPLS LSP .

Or to better say  it breaks connectivity on an MPLS L3 VPN as UNTAGGED means= remove all the label stack and send as an IP packet the current payload.

The correct action for two devices directly connected is POP TAG that means = remove only the external label ( = impilicit null) and keep the VPN label so that the next router in the path ,the egress PE,  will understand this is traffic for a specific L3 VPN and will not attempt to route it in the Global routing table.

This is caused by the mismatch between the subnet mask advertised by OSPF /32 and the effective subnet mask /24 in LDP bindings.

To fix this you can either:

a)  use ospf network point.-to-point to make OSPF advertise the real /24 subnets of loopbacks

b) change to /32 subnet mask under loopbacks as suggested by Harold.

I have seen this issue the first time in 2001 and it is also a good reason for using /32 loopbacks with OSPF in MPLS environments.

It is a waste of address space to use a /24 for a loopback as no other hosts can be directly connected to it.

Hope to help

Giuseppe

[MHM Cisco World]

Hi friend 
can you remove next-hop-self from the BGP, and see the result.

[MHM Cisco World]

remove next-hop-self and check.

[MHM Cisco World]

Freind,

Next hop in RR make the PE send traffic toward RR not toward Other PE but the tunnel is from PE1 to PE2 not from PE1 to RR and from RR to PE2

[Harold Ritter]

Hi Mahmood,

R3 and R2 (PEs) peer directly. No RR is being used between them.

Regards,

[MHM Cisco World]

But R1 have route reflector to both R2 R3, i see this in attach, may be something I miss.

[Harold Ritter]

R1 is RR for address-family ipv4 only. R1 is not configured to be a RR for address-family VPNv4.

Regards,

[Subhasis1992]

Hello Harold,

the issue happens due to my silly mistake. I use the command " neighbor X.X.X.X ebgp-multihop 2 " in my ibgp topology for every neighbor. This is might be the reason I'm getting the routers but not getting the ping reply. 

Can you verify my observation?

Regards,