04-12-2017 09:27 AM
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.
Solved! Go to Solution.
04-14-2017 07:32 AM
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
:-)
04-14-2017 08:53 AM
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
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
:-)
04-14-2017 07:32 AM
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
:-)
04-14-2017 08:41 AM
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#
04-14-2017 08:53 AM
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
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
:-)
04-16-2017 11:41 PM
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