03-18-2016 05:39 AM - edited 03-08-2019 06:59 PM
Supports interface overloading.
interface Vlan1
Description Inside Interface
ip address 172.16.1.1 255.255.255.0
ip nat inside
interface FastEthernet4
Description Outside Interface
ip vrf forwarding INET
ip address 10.150.217.107 255.255.255.0
ip nat outside
ip nat inside source list nat-acl interface FastEthernet4 vrf INET overload
ip access-list extended nat-acl
permit ip 172.16.1.0 0.0.0.255 any
Supports interface overloading
interface GigabitEthernet0/0/3
description WAN side
ip address dhcp
ip nat outside
interface GigabitEthernet0/0/2
description LAN side
ip vrf forwarding inside
ip address 172.16.1.3 255.255.255.0
ip nat inside
ip nat inside source list nat-acl interface GigabitEthernet0/0/2 overload
ip access-list extended nat-acl
ip access-list extended nat-acl
permit ip 172.16.1.0 0.0.0.255 any
Supports interface overloading.
interface Vlan1
Description Inside Interface
ip vrf forwarding INET
ip address 172.16.1.1 255.255.255.0
ip nat inside
interface FastEthernet4
Description Outside Interface
ip vrf forwarding INET
ip address 10.150.217.107 255.255.255.0
ip nat outside
ip nat inside source list nat-acl interface FastEthernet4 vrf INET match-in-vrf overload
ip access-list extended nat-acl
permit ip 172.16.1.0 0.0.0.255 any
This is supported through a feature called NVI (NAT Virtual Interface). NAT NVI is not supported in "NAT on-a-stick" scenario and it was designed for traffic from one vrf to another and not for routing between subnets in the global routing table.
For additional information about this feature please refer:
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/26704-nat-faq-00.html#nat-nvi
Supports interface overloading.
interface GigabitEthernet0/0/2
Description Inside Interface
ip address 172.16.1.1 255.255.255.0
ip nat inside
interface GigabitEthernet0/0/0
Description Outside Interface
ip vrf forwarding INET
ip address 10.107.237.254 255.255.255.240
ip nat outside
ip nat inside source list nat-acl interface GigabitEthernet0/0/0 vrf INET overload
ip access-list extended nat-acl
permit ip 172.16.1.0 0.0.0.255 any
Restrictions for Match-in-VRF Support for NAT
The Match-in-VRF Support for NAT feature is not supported on interface overload configuration.
Need to use an available IP address besides the interface address in a pool and that works as noted in the below example.
interface GigabitEthernet0/0/2
Description Inside Interface
ip vrf forwarding INET
ip address 172.16.1.1 255.255.255.0
ip nat inside
interface GigabitEthernet0/0/0
Description Outside Interface
ip vrf forwarding INET
ip address 10.107.237.254 255.255.255.240
ip nat outside
ip nat pool DIA 10.107.237.253 10.107.237.253 prefix-length 30
ip nat inside source list nat-acl pool DIA vrf INET match-in-vrf overload
ip access-list extended nat-acl
permit ip 172.16.1.0 0.0.0.255 any
Inter VRF communication on IOSXE is supported only through the use of VASI feature. See this document for more details on how to deploy NAT + VASI.
Hi Kurely,
Very useful document indeed.
Even though the Match-in-VRF Support for NAT feature is not supported on interface overload configuration, is it supported on pool overload?
I cannot make it work on a ISR4451-X/K9 runnig sr4400-universalk9.16.03.04 IOS-XE.
Thanks,
Sergio.
Sergio,
Yes, pool works with overload as in the example that I provided above.
-Kureli
Thanks you so much for your response Kureli.
I guessed that based on the configuration you already posted. But now I wonder why is it not working on my 4451 router. Could it be related to the IOS which is isr4400-universalk9.16.03.04?
The router does get the command in the NAT configuration, but eventhough NAT seems to work fine it's not forwarding packets properly within the VRF.
Thanks in advance,
Sergio.
Sergio,
I am not sure what is causing the problem. It would be better if you open a TAC case so, they can troubleshoot this for you.
Besides that you can use this packet tracer tool and try to troubleshoot it.
http://www.cisco.com/c/en/us/support/docs/content-networking/adaptive-session-redundancy-asr/117858-technote-asr-00.html
-Kureli
Hello.
I believe Global (inside) -> VRF (outside) is NOT supported, unless we are running iWAN (with extra configuration, including PBR).
Hey,
Apologies for replying a year old thread. but would this work on an interface configured for multi-vrf.
Just wondering if it will work on a multi-vrf interface like below? Eg
interface fastethernet0/0
ip vrf receive VRFA
ip vrf receive VRFB
ip policy route-map VRF-SELECT
Thanks!
Hi Kureli,
I believe we have to do it other way round in case of GLOBAL to VRF and VRF to GLOBAL NAT.
In case of GLOBAL to VRF NAT, vrf should not be attached in NAT statement as Inside interface in in Global routing table and in case of VRF to GLOBAL NAT, we have to specify VRF in NAT statement.
Regards,
Kuldeep
I tried to configure the Match-in-VRF with pool and overload on an IOS-XE Cat9300 switch with 16.12.2r.
1. Unfortunately it does not give the option to specify the vrf at the ip nat inside source command
2. Is there a way to configure this example while dhcp is set on the outside interface? In that particular case we wouldn't know what pool address to specify so it won't work, am I right?
I have just tested and in fact I believe this is the wrong way around for GRT -> VRF.
I believe the vrf on the NAT statement should be used if the source is in that VRF, not the destination.
Also would probably help more if it explained the routing requirements too. Like for GRT > VRF you need a route pointing out of the physical interface in that VRF. For VRF -> GRT (return traffic), I used PBR with a "set global" statement, matching the internal IPs of the hosts.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: