[c-nsp] NAT-ON-A-STICK for VRF Traffic

[Andy Saykao]

Worked it out...had the wrong NAT statement.

Change from: ip nat inside source list NSTEST-NAT-ACL pool
NSTEST-NAT-POOL vrf NSTEST overload

Change to: ip nat source list NSTEST-NAT-ACL pool NSTEST-NAT-POOL vrf
NSTEST overload

Thanks.

Andy


 

-----Original Message-----
From: Andy Saykao 
Sent: Monday, 24 August 2009 10:00 AM
To: 'Ivan Pepelnjak'; 'cisco-nsp at puck.nether.net'
Subject: RE: NAT-ON-A-STICK for VRF Traffic

Hi Ivan,

Thank you for your suggestion of using "ip nat enable". I've given this
a go but can't get it to work. Does this work in a MPLS L3 VPN
environment because I can't get the NAT-PE to nat any traffic coming
from the CE/PE? 

Eg: CE -> PE -> P -> NAT-PE -> Internet

The Cisco examples on using "ip nat enable" with VRF only discuss
physically connected VRF's that are nat enabled. This is different to
what I want to do because I have no physical/virtual VRF interfaces
hanging off the NAT-PE router.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.
pdf

On the NAT-PE I have configured this:

interface GigabitEthernet0/0.11
 description Interface into MPLS Network  encapsulation dot1Q 11  ip
address 203.10.110.x 255.255.255.224  ip nat enable  mpls ip !
interface GigabitEthernet0/0.904
 description Internet GW for VPN
 encapsulation dot1Q 904
 ip address 202.45.118.x 255.255.255.252  ip nat enable  ip
virtual-reassembly !
! Advertise default route to PE's via MP-BGP.
ip route vrf NSTEST 0.0.0.0 0.0.0.0 GigabitEthernet0/0.904 202.45.118.y
global !
ip nat pool NSTEST-NAT-POOL 210.15.230.a 210.15.230.b netmask
255.255.255.252 add-route ip nat inside source list NSTEST-NAT-ACL pool
NSTEST-NAT-POOL vrf NSTEST overload !
ip access-list standard NSTEST-NAT-ACL
 permit 192.168.0.0 0.0.255.255
 permit 10.15.0.0 0.0.255.255
 permit 172.16.0.0 0.0.255.255

When I test from the PE to the Internet, it just times out. 

PE#ping vrf NSTEST
Protocol [ip]:
Target IP address: www.google.com
Translating "www.google.com"...domain server (210.15.254.240) [OK]
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 66.102.11.104, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The trace is hitting the NAT-PE (202.45.118.x) but no natting occurs.

PE#traceroute vrf NSTEST 210.15.254.x

Type escape sequence to abort.
Tracing the route to dns1-1-virtual.netspace.net.au (210.15.254.x)

  1 core1-hs-TenGigE-4-1.Sydney.netspace.net.au (203.12.53.x) [MPLS:
Labels 3043/8653 Exp 0] 16 msec 16 msec 12 msec
  2 core1-ks-gigether-4-0-0.Melbourne.netspace.net.au (203.17.96.x)
[MPLS: Labels 8060/8653 Exp 0] 16 msec 12 msec 16 msec
  3 202-45-118-134-static.spacecentre.com.au (202.45.118.x) [MPLS: Label
8653 Exp 0] 12 msec 12 msec 16 msec
  4  *  *  *
  5  *  *  *

NOTE: IT LOCKS UP MY NAT-PE ROUTER EVERY TIME I DO TESTING FROM THE PE
AND I HAVE TO REBOOT THE NAT-PE.

The NAT-PE is a Cisco 7301 running 12.4(24)T1.

Yeah..so I was just wondering if "ip nat enabled" can be used in a MPLS
L3 VPN enviroment and whether I've set up the NAT-PE correctly???

Thanks.

Andy
 

-----Original Message-----
From: Ivan Pepelnjak [mailto:ip at ioshints.info]
Sent: Monday, 17 August 2009 11:42 PM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] NAT-ON-A-STICK for VRF Traffic

It's probably easier to use the NAT Virtual Interface ("ip nat enable"
instead of "ip nat inside|outside") in a VRF environment. You also don't
need NAT-on-a-stick with NVI.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.