cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2463
Views
5
Helpful
4
Replies

MPLS VPN CE to CE not able to ping.

Hi, this is my first MPLS VPN lab. I am not able to ping from R1 to R6 and vice versa. But ping is successful between R9 and R10. Since this is my very first MPLS VPN lab so I am ready to be pointed out for silly rookie mistakes. Please help me find out the fault. I have attached the config as text and GNS3 Topology as png files.

2 Accepted Solutions

Accepted Solutions

Hi

Are you sure if the LDP is running through the ISP network (P and PE routers), you can use the following show line to verify:

show mpls ldp neighbor   in order to verify the LDP neighborship

Also you could verify if Ip cef is enabled on the routers.

I recommend to specify the mpls router id on each P and PE routers, also use OSPF or IS-IS routing protocols into the ISP network, for example on Router3:

int loopback 0
ip add 3.3.3.3 255.255.255.255

router ospf 1   (not sure the IGP that you are using and its process either, it is just an example)
network 3.3.3.3 0.0.0.0 area 
mpls ldp autoconfig     

* You can enable ldp under the interfaces using mpls ip or use mpls ldp autoconfig under the OSPF process, in the case mpls ip under the interface is not required. 

mpls ldp router-id loopback0 force

Could you please provide the following outputs from the PE (R2 & R5)

show bgp vpnv4 unicast all summary 

show ip route vrf CUSTA

show ip route vrf CUSTB

Please rate the comment if it is useful

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

View solution in original post

Hi,

Happy to know that was fixed :-)

About the question, a time ago I had a similar issue, into the MPLS network there were different costs on the OSPF interfaces, so the packet was preferring a specific path than others and it was dropping the communication, I used the following command under the OSPF (it also can be used into IS-IS routing protocol) into the ISP network and it resolved the problem:

router ospf X
mpls ldp sync

It should be configured on all the devices related to the MPLS network (PE & P) in order avoid future inconveniences, please try it and keep me posted. Just wait few seconds to take effect. 

http://www.cisco.com/c/en/us/td/docs/ios/mpls/configuration/guide/convert/mp_ldp_book/mp_ldp_igp_synch.html

MPLS LDP-IGP Synchronization Requires Peer To Be Reachable

When the MPLS LDP-IGP Synchronization feature is enabled on an interface, LDP determines if any peer connected by the interface is reachable by looking up the peer's transport address in routing table. If a routing entry (including longest match and/or default routing entry) for the peer exists, LDP assumes that LDP-IGP Synchronization is required for the interface and notifies the IGP to wait for LDP convergence.

This requires that the routing table be correct and accurate for peer's transport address. If the routing table shows there is a route for the peer's transport address, that route must be able to reach the peer's transport address. However, if the route is a summary route, default route, or a statically configured route, it might not the correct route for the peer. You must verify that the route in the routing table can reach the peer's transport address.

When the routing table has an inaccurate route for peer's transport address, LDP cannot set up a session with the peer, which causes the IGP wait for LDP convergence unnecessarily for the sync holddown time.

Reference: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fsldpsyn.html

Hope it is useful

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

View solution in original post

4 Replies 4

Hi

Are you sure if the LDP is running through the ISP network (P and PE routers), you can use the following show line to verify:

show mpls ldp neighbor   in order to verify the LDP neighborship

Also you could verify if Ip cef is enabled on the routers.

I recommend to specify the mpls router id on each P and PE routers, also use OSPF or IS-IS routing protocols into the ISP network, for example on Router3:

int loopback 0
ip add 3.3.3.3 255.255.255.255

router ospf 1   (not sure the IGP that you are using and its process either, it is just an example)
network 3.3.3.3 0.0.0.0 area 
mpls ldp autoconfig     

* You can enable ldp under the interfaces using mpls ip or use mpls ldp autoconfig under the OSPF process, in the case mpls ip under the interface is not required. 

mpls ldp router-id loopback0 force

Could you please provide the following outputs from the PE (R2 & R5)

show bgp vpnv4 unicast all summary 

show ip route vrf CUSTA

show ip route vrf CUSTB

Please rate the comment if it is useful

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Hi Julio, 

Thanks for helping me out. By your help, I found out that LDP was not running in R7's f3/0 interface. Once I started the LDP session between R2 and R7 by running #mpls ip command under f3/0 I was able to ping between R1-R6 and R6-R1. 

But Julio, could you please help me understand, why is this happening that when I am breaking the LDP session b/w R2-R7 by using no mpls ip command under f3/0, I am not able to ping from R6 to R1. but I am able to ping from R1 to R6 and also bidirectional ping is working between R9 and R10. Why is this peculiar problem happening b/w R1 and R6 only?

R1(CE) Router logs>>>
R1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/96/104 ms


R1#traceroute 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.12.2 8 msec 28 msec 24 msec
2 * * *
3 203.2.2.2 [MPLS: Labels 26/29 Exp 0] 56 msec 76 msec 76 msec
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * *

R1#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
O IA 6.6.6.6 [110/3] via 10.1.12.2, 00:25:21, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.1.12.0/24 is directly connected, FastEthernet0/0
L 10.1.12.1/32 is directly connected, FastEthernet0/0
O IA 10.1.13.0/24 [110/2] via 10.1.12.2, 00:25:21, FastEthernet0/0
R1#
R6 (CE) Router logs>>>
R6#traceroute 1.1.1.1 
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.13.2 32 msec 16 msec 12 msec
2 203.2.0.25 [MPLS: Labels 24/29 Exp 0] 84 msec * 76 msec
3 * * *
4 * * *
5


R6#sh ip route

1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/3] via 10.1.13.2, 00:32:12, FastEthernet0/0
6.0.0.0/32 is subnetted, 1 subnets
C 6.6.6.6 is directly connected, Loopback0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA 10.1.12.0/24 [110/2] via 10.1.13.2, 00:32:12, FastEthernet0/0
C 10.1.13.0/24 is directly connected, FastEthernet0/0
L 10.1.13.1/32 is directly connected, FastEthernet0/0
R2(PE) Router logs>>>
R2#ping vrf CUSTA 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#sh ip route vrf CUSTA

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.1.12.1, 00:34:33, FastEthernet3/0
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [200/2] via 5.5.5.5, 00:33:39
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.1.12.0/24 is directly connected, FastEthernet3/0
L 10.1.12.2/32 is directly connected, FastEthernet3/0
B 10.1.13.0/24 [200/0] via 5.5.5.5, 00:33:39


R2#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/64/76 ms


R2#traceroute 5.5.5.5
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 203.1.0.25 [MPLS: Label 26 Exp 0] 1116 msec
203.1.0.29 20 msec
203.1.0.25 [MPLS: Label 26 Exp 0] 268 msec
2 203.6.6.2 [MPLS: Label 26 Exp 0] 132 msec
203.2.2.2 [MPLS: Label 26 Exp 0] 172 msec
203.6.6.2 [MPLS: Label 26 Exp 0] 64 msec
3 203.2.0.26 64 msec 60 msec 56 msec
R5(PE) Router logs>>>
R5#sh ip route vrf CUSTARouting Table: CUSTA

1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [200/2] via 2.2.2.2, 00:49:01
6.0.0.0/32 is subnetted, 1 subnets
O 6.6.6.6 [110/2] via 10.1.13.1, 00:50:18, FastEthernet3/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.1.12.0/24 [200/0] via 2.2.2.2, 00:49:01
C 10.1.13.0/24 is directly connected, FastEthernet3/0
L 10.1.13.2/32 is directly connected, FastEthernet3/0


R5#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/53/80 ms


R5#ping vrf CUSTA 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/29/56 ms


R5#ping vrf CUSTA 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)
R5#

Hi,

Happy to know that was fixed :-)

About the question, a time ago I had a similar issue, into the MPLS network there were different costs on the OSPF interfaces, so the packet was preferring a specific path than others and it was dropping the communication, I used the following command under the OSPF (it also can be used into IS-IS routing protocol) into the ISP network and it resolved the problem:

router ospf X
mpls ldp sync

It should be configured on all the devices related to the MPLS network (PE & P) in order avoid future inconveniences, please try it and keep me posted. Just wait few seconds to take effect. 

http://www.cisco.com/c/en/us/td/docs/ios/mpls/configuration/guide/convert/mp_ldp_book/mp_ldp_igp_synch.html

MPLS LDP-IGP Synchronization Requires Peer To Be Reachable

When the MPLS LDP-IGP Synchronization feature is enabled on an interface, LDP determines if any peer connected by the interface is reachable by looking up the peer's transport address in routing table. If a routing entry (including longest match and/or default routing entry) for the peer exists, LDP assumes that LDP-IGP Synchronization is required for the interface and notifies the IGP to wait for LDP convergence.

This requires that the routing table be correct and accurate for peer's transport address. If the routing table shows there is a route for the peer's transport address, that route must be able to reach the peer's transport address. However, if the route is a summary route, default route, or a statically configured route, it might not the correct route for the peer. You must verify that the route in the routing table can reach the peer's transport address.

When the routing table has an inaccurate route for peer's transport address, LDP cannot set up a session with the peer, which causes the IGP wait for LDP convergence unnecessarily for the sync holddown time.

Reference: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fsldpsyn.html

Hope it is useful

:-)




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Thanks Julio!

Getting Started

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: