cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1327
Views
0
Helpful
8
Replies

Internet Access for MPLS

kmpoon
Level 1
Level 1

Hi,

I am trying out Internet access for MPLS, using NAT at PE. The PE is connected to a internet gateway, and 2 CEs.

Everything works as per expected when different private ip is used in the CE. However, when overlapping private ip is used in the CE, the public ip can be nated to private, but there is only one next-hop for the CE private ip in vrf INTGW-VRF.

Did I miss out anything? How can we distinguish imported vrf routes? Is there another way to do achieve providing Internet access for overlapping private ip?

ip vrf INTGW-VRF

rd 300:1

route-target import 100:1

route-target import 200:1

!

ip vrf TEST1-VRF

rd 100:1

route-target export 100:1

route-target import 100:1

!

ip vrf TEST2-VRF

rd 200:1

route-target export 200:1

route-target import 200:1

interface FastEthernet0/1

ip vrf forwarding INTGW-VRF

ip address 192.168.0.2 255.255.255.0

ip nat outside

interface FastEthernet0/2

ip vrf forwarding TEST1-VRF

ip address 10.0.0.1 255.255.255.252

ip nat inside

interface FastEthernet0/3

ip vrf forwarding TEST2-VRF

ip address 10.0.0.1 255.255.255.252

ip nat inside

router bgp 1111

address-family ipv4 vrf TEST1-VRF

redistribute connected

redistribute static

!

address-family ipv4 vrf TEST2-VRF

redistribute connected

redistribute static

!

address-family ipv4 vrf INTGW-VRF

redistribute connected

redistribute static

ip route vrf TEST1-VRF 0.0.0.0 0.0.0.0 FastEthernet0/1 192.168.0.1 global

ip route vrf TEST1-VRF 10.0.0.0 255.255.255.252 FastEthernet0/2 10.0.0.2

ip route vrf TEST2-VRF 0.0.0.0 0.0.0.0 FastEthernet0/1 192.168.0.1 global

ip route vrf TEST2-VRF 10.0.0.0 255.255.255.252 FastEthernet0/3 10.0.0.2

ip nat pool Public1 192.168.10.112 192.168.10.115 netmask 255.255.255.252

ip nat pool Public2 192.168.10.116 192.168.10.119 netmask 255.255.255.252

ip nat inside source list 1 pool Public1 vrf TEST1-VRF

ip nat inside source list 2 pool Public2 vrf TEST2-VRF

access-list 1 permit 10.0.0.0 0.0.0.3

access-list 2 permit 10.0.0.0 0.0.0.3

1 Accepted Solution

Accepted Solutions

You can never exclude a bug ;o) I ran my test with 12.3(5). Is CEF enabled?

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

8 Replies 8

Harold Ritter
Level 12
Level 12

Using duplicate addresses in different VRFs works fine.

You should not put fa0/1 in a VRF. Leave it as part of the global routing table.

You do not need the following two entries either:

ip route vrf TEST1-VRF 10.0.0.0 255.255.255.252 FastEthernet0/2 10.0.0.2

ip route vrf TEST2-VRF 10.0.0.0 255.255.255.252 FastEthernet0/3 10.0.0.2

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Thanks for your reply.

My initial test actually did not put the fa0/1 in VRF. However, after the return traffic from public is nated back to private, the global routing table has no knowledge of the vrf routes.

From a cisco example, there is a need to put in global static route to point the private address back to the correct CE interface. But, this does not solve the problem of not able to use overlap private address, and it introduced private address in global routing table...

Did i miss out anything? Thanks.

You don't actually need a route to the private address in the global routing table. The global should know exactly which vrf the NAT context belongs to.

I tried it quickly with the following config and it worked well as you can see from the debug output I included at the end:

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname r1

!

boot-start-marker

boot-end-marker

!

!

clock timezone EST -5

no aaa new-model

ip subnet-zero

!

ip vrf INTGW-VRF

rd 300:1

route-target import 100:1

route-target import 200:1

!

ip vrf TEST1-VRF

rd 100:1

route-target export 100:1

route-target import 100:1

!

ip vrf TEST2-VRF

rd 200:1

route-target export 200:1

route-target import 200:1

!

ip cef

!

!

!

interface Ethernet0/0

ip address 192.168.0.2 255.255.255.0

ip nat outside

!

interface Ethernet1/0

ip vrf forwarding TEST1-VRF

ip address 10.0.0.1 255.255.255.252

ip nat inside

!

interface Ethernet2/0

ip vrf forwarding TEST2-VRF

ip address 10.0.0.1 255.255.255.252

ip nat inside

!

router bgp 1111

no synchronization

bgp log-neighbor-changes

no auto-summary

!

address-family ipv4 vrf TEST2-VRF

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

!

address-family ipv4 vrf TEST1-VRF

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

!

address-family ipv4 vrf INTGW-VRF

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

!

ip nat pool Public1 192.168.10.112 192.168.10.115 netmask 255.255.255.252

ip nat pool Public2 192.168.10.116 192.168.10.119 netmask 255.255.255.252

ip nat inside source list 1 pool Public1 vrf TEST1-VRF

ip nat inside source list 2 pool Public2 vrf TEST2-VRF

ip classless

ip route vrf TEST1-VRF 0.0.0.0 0.0.0.0 Ethernet0/0 192.168.0.1 global

ip route vrf TEST2-VRF 0.0.0.0 0.0.0.0 Ethernet0/0 192.168.0.1 global

no ip http server

!

!

access-list 1 permit 10.0.0.0 0.0.0.3

access-list 2 permit 10.0.0.0 0.0.0.3

!

!

!

line con 0

line aux 0

line vty 0 4

login

!

!

end

r1#deb ip nat vrf

IP NAT VRF debugging is on

r1#

*Mar 20 12:58:44.499: NAT*: i: icmp (10.0.0.2, 3) -> (192.168.100.1, 3) [3] vrf=> TEST1-VRF

*Mar 20 12:58:44.499: NAT*: s=10.0.0.2->192.168.10.113, d=192.168.100.1 [3] vrf=> TEST1-VRF

*Mar 20 12:58:44.519: NAT*: o: icmp (192.168.100.1, 3) -> (192.168.10.113, 3) [3] vrf=> TEST1-VRF

*Mar 20 12:58:44.519: NAT*: s=192.168.100.1, d=192.168.10.113->10.0.0.2 [3] vrf=> TEST1-VRF

r1#

r1#

r1#

*Mar 20 12:59:43.459: NAT: i: icmp (10.0.0.2, 1) -> (192.168.100.1, 1) [1]

*Mar 20 12:59:43.459: NAT: s=10.0.0.2->192.168.10.117, d=192.168.100.1 [1] vrf=> TEST2-VRF

*Mar 20 12:59:43.471: NAT*: o: icmp (192.168.100.1, 1) -> (192.168.10.117, 1) [1] vrf=> TEST2-VRF

*Mar 20 12:59:43.471: NAT*: s=192.168.100.1, d=192.168.10.117->10.0.0.2 [1] vrf=> TEST2-VRF

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

One more thing. If you do a "show ip nat tr verbose", you will see that NAT knows exactly what VRF to lookup to map the global to the local address.

r1#sh ip nat tr ve

Pro Inside global Inside local Outside local Outside global

--- 192.168.10.113 10.0.0.2 --- ---

create 00:00:14, use 00:00:13, left 23:59:46, Map-Id(In): 1,

flags:

none, use_count: 0, VRF : TEST1-VRF

--- 192.168.10.117 10.0.0.2 --- ---

create 00:00:06, use 00:00:06, left 23:59:54, Map-Id(In): 2,

flags:

none, use_count: 0, VRF : TEST2-VRF

r1#

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Thanks for your help. I'm getting similar debug results as yours. However, I'm not able to ping vrf to a public ip, traceroute vrf is fine though.

#traceroute TEST1-VRF 203.y.y.1

1 203.x.x.1 4 msec 0 msec 4 msec

2 203.x.x.7 0 msec 4 msec 0 msec

3 203.y.y.1 4 msec 12 msec 4 msec

#ping vrf TEST1-VRF 203.y.y.1

.....

#traceroute 203.y.y.1

1 203.x.x.1 4 msec 0 msec 4 msec

2 203.x.x.7 0 msec 0 msec 4 msec

3 203.y.y.1 4 msec 4 msec 4 msec

#ping 203.y.y.1

!!!!!

Found out that there is this error when i turn on 'debug ip nat detailed'. Could it be an IOS bug? i'm running 12.3(11)T3.

05:22:09: NAT*: Can't create new inside entry - forced_punt_flags: 0

You can never exclude a bug ;o) I ran my test with 12.3(5). Is CEF enabled?

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

It works after i upgrate to 12.3(13)T. However, the 'show ip nat trans' does not give the details NAT anymore.. :( Are you using 12.3(5a)B4? Any idea when there will be a stable release?

Many thanks for your help!