Solved: Re: VRF-lite, NAT and route-leaking

Eugene Khabarov · ‎10-25-2011

Hello, community. I'm trying to reproduce setup with two customers (R1 and R2), PE router (R3) and common services (R4).

Here is configuration:

R1:

interface Loopback0

ip address 10.10.1.1 255.255.255.255

!

interface FastEthernet1/0

ip address 192.168.15.1 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 192.168.15.5

R2:

interface Loopback0

ip address 10.10.2.2 255.255.255.255

!

interface FastEthernet1/0

ip address 192.168.16.1 255.255.255.192

!

ip route 0.0.0.0 0.0.0.0 192.168.16.5

R3:

ip vrf VRF1

rd 1:1

route-target export 1:1

route-target import 1:1

!

ip vrf VRF2

rd 2:2

route-target export 2:2

route-target import 2:2

!

interface FastEthernet0/0

description R1

ip vrf forwarding VRF1

ip address 192.168.15.5 255.255.255.192

ip nat inside

ip virtual-reassembly

!

interface FastEthernet0/1

description R2

ip vrf forwarding VRF2

ip address 192.168.16.5 255.255.255.192

ip nat inside

ip virtual-reassembly

!

interface FastEthernet1/0

description R4

ip address 1.1.1.1 255.255.255.0

ip nat outside

ip virtual-reassembly

!

ip route 0.0.0.0 0.0.0.0 1.1.1.2

ip route vrf VRF1 0.0.0.0 0.0.0.0 FastEthernet1/0 1.1.1.2 global

ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1

ip route vrf VRF2 0.0.0.0 0.0.0.0 FastEthernet1/0 1.1.1.2 global

ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1

!

ip nat inside source list 15 interface FastEthernet1/0 vrf VRF1 overload

ip nat inside source list 16 interface FastEthernet1/0 vrf VRF2 overload

!

access-list 15 permit 192.0.0.0 0.255.255.255

access-list 15 permit 10.10.0.0 0.0.255.255

access-list 16 permit 192.0.0.0 0.255.255.255

access-list 16 permit 10.10.0.0 0.0.255.255

R4:

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

interface FastEthernet0/0

ip address 1.1.1.2 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 1.1.1.1

The configuration is not operational.

r1#ping 192.168.15.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.15.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/89/116 ms

r1#ping 192.168.15.5 source l0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.15.5, timeout is 2 seconds:

Packet sent with a source address of 10.10.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/86/92 ms

r1#ping 1.1.1.1 source l0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.10.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 292/357/400 ms

r1#ping 1.1.1.2 source l0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:

Packet sent with a source address of 10.10.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 160/187/216 ms

r1#ping 10.10.10.10 source l0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:

Packet sent with a source address of 10.10.1.1

.....

Success rate is 0 percent (0/5)

I can't ping R4's loopback address ("shared resource" or also known as "common service")

The same is with R2 ( second customer).

But I can still ping R4's loopback from R3:

R3#ping 10.10.10.10

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/88/116 ms

This is routing table on R3:

R3#sh ip route | begin Gateway

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, FastEthernet1/0

S* 0.0.0.0/0 [1/0] via 1.1.1.2

R3#sh ip route vrf VRF1 | begin Gateway

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

192.168.15.0/26 is subnetted, 1 subnets

C 192.168.15.0 is directly connected, FastEthernet0/0

10.0.0.0/16 is subnetted, 1 subnets

S 10.10.0.0 [1/0] via 192.168.15.1

S* 0.0.0.0/0 [1/0] via 1.1.1.2, FastEthernet1/0

R3#sh ip route vrf VRF2 | begin Gateway

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

10.0.0.0/16 is subnetted, 1 subnets

S 10.10.0.0 [1/0] via 192.168.16.1

192.168.16.0/26 is subnetted, 1 subnets

C 192.168.16.0 is directly connected, FastEthernet0/1

S* 0.0.0.0/0 [1/0] via 1.1.1.2, FastEthernet1/0

So the question is what is the problem cause? How to troubleshoot? What is the troubleshooting steps?

Vaibhava Varma · ‎10-26-2011

Hi Eugene Khabarov

Its not working since the Destination IP which represents Common Services is found to be locally routed back to the CE itself. Thats the problem here. We need to make sure that the Destination Subnet is not pointed back to CE which is what happening here.

R4:

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

R3-VRF1

S 10.10.0.0 [1/0] via 192.168.15.1

Regards

Varma

View solution in original post

Vaibhava Varma · ‎10-25-2011

Hi Eugene Khabarov

The problem here is that at the PE we have the static route for the Major Subnet 10.10.0.0/16 pointing back to the CEs of which the destination ping IP 10.10.10.10 is part of.

We need to remove the Major X /16 route from PE and configure explicit X /32 route for the CE Loopback to make this work

no ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1

ip route vrf VRF1 10.10.1.1 255.255.0.0 192.168.15.1
no ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1

ip route vrf VRF2 10.10.2.2 255.255.0.0 192.168.16.1

Hope this helps to answer your query.

Regards

Varma

Eugene Khabarov · ‎10-26-2011

no ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1

ip route vrf VRF1 10.10.1.1 255.255.0.0 192.168.15.1
no ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1

ip route vrf VRF2 10.10.2.2 255.255.0.0 192.168.16.1

There is an error I think. You mean host route, so I should be:

no ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1

ip route vrf VRF1 10.10.1.1 255.255.255.255 192.168.15.1
no ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1

ip route vrf VRF2 10.10.2.2 255.255.255.255 192.168.16.1

Eugene Khabarov · ‎10-25-2011

Hi! Thank you for reply. But this don' t make gave me understanding of the issue. What if there subnet on R4 that serve common services?

Sent from Cisco Technical Support iPhone App

Vaibhava Varma · ‎10-25-2011

Hi Eugene Khabarov

Sorry but I don't understand what you mean by Subnet on R4 that serve common services.

If the requirement is that Subnets on R4 and the CE be part of same Subnet then we need an L2 Transport not L3 VPN Transport. Here the problem is that we trying to reach a destination IP which is routed locally only but not configured. The packet from CE is hiiting the PE and going back to the CE as their is specific route in the VRF table for the destination IP and its not looking at the global default route at all.

Hope this clarifies my viewpoint. Do let me know for any questions.

Regards

Varma

Eugene Khabarov · ‎10-26-2011

Sorry but I don't understand what you mean by Subnet on R4 that serve common services.

Here on R1 "common resources" or "shared services" is represented as address on l0. Imagine that this is group of servers in not single address but a specific subnet. So I don't need it to be on the same subnet as CE. There is no such requirement. I would like to use something similar to "MPLS/VPN Common Services" but without MPLS with help of NAT. In my case NAT is not working. Why so? 'show ip nat translations' shows nothing.

Vaibhava Varma · ‎10-26-2011

Hi Eugene Khabarov

Its not working since the Destination IP which represents Common Services is found to be locally routed back to the CE itself. Thats the problem here. We need to make sure that the Destination Subnet is not pointed back to CE which is what happening here.

R4:

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

R3-VRF1

S 10.10.0.0 [1/0] via 192.168.15.1

Regards

Varma

Eugene Khabarov · ‎10-26-2011

Thank you. Now it makes sense. Simple routing problem what was covered by VRF. This make me confuse. Now it is ok.

Vaibhava Varma · ‎10-26-2011

Hi Eugene

Oh yes that was a typo for the host route :-)

Glad to hear that the issue is resolved and we are on the same page :-)

Regards

Varma