MPLS VPN - Problem with communication between CustA-CustA1 and PE1-CA1

[TommyKay]

Hello everyone,

I hope you are doing well. I am having an issue with communication between Customer A router and CustomerA1 router. Additionally, what is strange is that when I try to ping from PEdge2 router to CustomerA router's loopback0, the ping is successful

(ping vrf 101:CustA 100.100.100.100)

However, when I try to ping from PEdge1 router to CustomerA1 router's loopback0, the ping fails

(ping vrf 101:CustA 111.111.111.111)

The topology and configuration have been created with the implementation of 6VPE (once I can resolve the communication issues) and tunneling in the lower part of the topology. Please find the attached images of the topology, interfaces, and their addresses and configurations of the routers(zip file) and the project files(zip and link to Google drive).

I have tried various commands to test the network, but apparently, I am missing something that is causing this problem. The network is set up in GNS3, and the routers are from the 7200 series

(c7200-adventerprisek9-mz.124-24.T5.image)

I would greatly appreciate any guidance that could help me solve this communication problem.

Best regards!

Link to project: https://drive.google.com/drive/folders/1NQ5XiPm_Ic-JKMFjXVsRmPIFr2klTRcV?usp=sharing

[MHM Cisco World · Accepted solution]

You change link subnet did you change the bgp config also? 

[TommyKay]

No, I didn't. You were right @MHM Cisco World ! It seems like changing the subnet between

 PEdge2 - CustA1

did the job!

1. I'm curious why the different subnets have an impact on this simple MPLS topology. I really would like to know, because the bottom part of the topology is still not configured, so maybe it needs also some small tweaks in IP addressing.
2. We also changed you must use

 redistribute connect under pe bgp address vrf that connect to ce

 which I understand, but why did we have to exclude the

 next-hop-self from the vpnv4 PEdge config? (you must never use next-hop-self under bgp address vpnv4 )

It is because it would cause the egress PE router's loopback IP address to be used as the next hop address for all VPNv4 prefixes that are advertised to the neighbor and it would cause the prefixes to become unreachable, as the loopback address of the egress PE router may not be reachable from the neighbor's perspective?
Thank you @MHM Cisco World once again for helping me with this problem. I'm going to implement 6VPE in the meantime and tunneling in the bottom part of the topology.

[MHM Cisco World]

Friend you are so so welcome anytime

Your Q need a lot of work with example I will try to share it with you in few three days.

Thanks 

MHM

[TommyKay]

That would be awesome! Thank you once again for your precious time and I wish you all the best! @MHM Cisco World 

[TommyKay]

Dear @MHM Cisco World . I'm not sure whether I can post once again in this thread if the solution was proposed. If so, let me know in the reply below.
I've implemented

6VPE on PEdge1/2, CustomerA/A1

but have a problem with eBGP peering. The configuration seems good to me, but I don't get any BGP routes on CustomerA and CustomerB. If you could take a brief look at the new configuration of IPv6 then I would be pleased.
I attach the 4 config files of routers

 PEdge1, PEdge2, CustomerA, and CustomerA1

and some commands outputs.

[Harold Ritter]

Hi @TommyKay ,

You are missing the RT configuration for the ipv6 address family on both

PEdge1 and PEdge2

Please configure and it should fix it. Make sure you correct it on all PEs.

PEdge1:

vrf definition 101:CustA
rd 11.11.11.11:1
!
address-family ipv4
route-target export 11.11.11.11:101
route-target import 22.22.22.22:101
exit-address-family
!
address-family ipv6

route-target export 11.11.11.11:101
route-target import 22.22.22.22:101
exit-address-family
!

PEdge2:

vrf definition 101:CustA
rd 22.22.22.22:1
!
address-family ipv4
route-target export 22.22.22.22:101
route-target import 11.11.11.11:101
exit-address-family
!
address-family ipv6

route-target export 22.22.22.22:101
route-target import 11.11.11.11:101
exit-address-family
!

Regards,

[TommyKay]

Thats it! I was skimming through the running config and I focused more on the router BGP configuration. Thank you @Harold Ritter !

[Harold Ritter]

You are very welcome @TommyKay and thanks for the feedback.

[TommyKay]

Hello @Harold Ritter, it's another day and other adventures. I did start to configure tunneling in the lower side of the topology.
First I configured MPLS on the bottom side

 (on routers CustB/B1, PEdge3/4, Provider3/4)

tested the connectivity between

CustB and CustbB1

and everything was great.

I started adding the TE tunneling configuration. I began with enabling MPLS tunnels globally and on links using

mpls traffic-eng tunnels

command. Then configured on the link rsvp bandwidth with ip rsvp bandwidth 10000000 7500000, then used these 3 commands on

PEdge3/4, Provider3/4

router ospf 1 , mpls traffic-eng router-id l0, mpls traffic-eng area 0. 
Near the end I configured the tunnel1 interface on PEdge 3 and PEdge4:

PEdge3(config)#interface tunnel 1
PEdge3(config-if)#ip unnumbered loopback0
PEdge3(config-if)#tunnel mode mpls traffic-eng
PEdge3(config-if)#tunnel destination 44.44.44.44
PEdge3(config-if)#tunnel mpls traffic-eng priority 0 0
PEdge3(config-if)#tunnel mpls traffic-eng bandwidth 7500000
PEdge3(config-if)#tunnel mpls traffic-eng path-option 1 dynamic,
similar to PEdge4. After that, I noticed that the tunnels went up, but started behaving strangely. The tunnel PEdge4_t1 became in STATE/PROT up/down, and after a while one tunnel disappeared. I've removed the tunnel mpls traffic-eng bandwidth 7500000 and the int tunnel1 went up. For the first time, I configured this command with bandwidth 10000000, but I thought it might cause the problem, so downed it to 7500000. I also have changed ip rsvp bandwidth 10000000 7500000  the second value to 7500000(for the first time it was also 10000000).

In the end, I've added these commands to steer the traffic from CustomerB/CustomerB1 to the tunnels:

PEdge3(config)#int tunnel1
PEdge3(config-if)#tunnel mpls traffic-eng autoroute announce
PEdge3(config-if)#tunnel mpls traffic-eng autoroute metric absolute 1
respectively on the PEdge4.
Unfortunately, I've lost connectivity from CustB to CustB1 (ping doesn't work, sourcing it from f.e. CustB's loopback0), but pinging from PEdge3/4 using vrf 102:CustB to loopback CustB/B1 does work.

So there are my questions:
1. Why did the tunnel mpls traffic-eng bandwidth 7500000 affect the state of the tunnel and how to modify it to set the maximum bandwidth? (it's removed, otherwise, tunnels stop working)
2. What's wrong with this configuration and what should be changed in order to achieve connectivity from CustB to CustB1 over the tunnel and reversibly?
I include the configs and screenshots of some

 tunneling-related

command outputs.

[Harold Ritter]

Hi @TommyKay ,

 It has to be related to the IOS version you use (124-24.T5), that is quite old by the way.

I loaded your configurations in 15.9(3)M4 and quickly checked and everything works like a charm and traffic goes from CustomerB to CustomerB1 and vice versa via the tunnel interface with the following configuration:

PEdge3:

interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 44.44.44.44
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric absolute 1
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng bandwidth 7500000
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic


PEdge4:

interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 33.33.33.33
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng autoroute metric absolute 1
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng bandwidth 7500000
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic

Regards,

[TommyKay]

That sounds great that this configuration works. Is there a way to obtain a newer version of IOS( f.e. 15.1) for the Cisco 7200 series router? Maybe it's available for students for free through the Cisco website? Or maybe I can get my old IOS updated by Cisco?

Thanks once again for the answer @Harold Ritter !

[Harold Ritter]

Hi @TommyKay ,

The 7200 has been end of life for a long long time. You will unfortunately be unable to find any recent version for it.

Your best bet to run decent labs would be to consider Cisco Modeling Labs for Education:

https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/modeling-labs/at-a-glance-c45-744340.html

Regards,

[TommyKay]

Thank you for the answer. I would try to change a subnet in this topology. Maybe this resolves the problem once again. If not, I'll be forced to use the modeling labs.

Thank you @Harold Ritter and have a great day!

[Harold Ritter]

You are very welcome @TommyKay  and thanks for the feedback

[TommyKay]

The configuration did start to work again. I guess a random stop of all nodes does the job sometimes haha(previously even turning off the GNS3 did not help).
I'm able to ping from CustB to CustB1 but the path seems not to go through tunnel1. I guess I see the route in the PEdge4 route table for vrf 102:CustB to l0 of CustomerB (200.200.200.200). When I traceroute from CustomerB to CustomerB1 I do not see the traffic go through tunnel1 and back, but it takes the path through the LSP. I think there might be a misconfiguration I was talking about.