From: Miguel Trejo (mike.trejo@gmail.com)
Date: Fri Jun 01 2007 - 12:10:12 ART
I think it's easier to compare this with the way PIX work for NAT. Every
single vrf is a NAT domain. That's why you specify them to be on different
VRF's. I assume that there is no way to communicate between them unless you
configure NAT for them to see each other.
First you define interface to participate in NAT translations. As you said
every single one of them participates on a different vrf an also the two
Ethernet ones are overlapping. Then you define a pool to use when NAT
should be performed.
The whole trick is on the ip nat source statements.
ip nat source list 1 pool NAT vrf bank overload
ip nat source list 1 pool NAT vrf park overload
Here you configure that everything that mathes ACL 1 (with matches
192.168.122.0/24) should be translated. The key to know when would this
happen is on CCO:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_14/gtnatvi.htm
"When a domain is specified, the translation rules are applied either before
or after route decisions depending on the traffic flow from inside to
outside or outside to inside. The translation rules are applied only after
the route decision for an NVI.`"
For this to be similar to the regular ip nat inside source we are missing
only which side is supposed to be the inside and that's why we need the VRF.
The VRF gives the direction information. In these case the inside is defined
to be on the Ethernet side, diferent VRF's for every interface since they
are overlapping. VRf must be specified if you don't specify inside or
outside on the NAT statement.
So since this is defined as a inside source (at least in the example), when
traffic flows from any of the desired interfaces the routers should check
first if there is an outside rule that may influence routing decisions, this
time there is no such rule. So router proceeds to route to outside if
destination is on the serial side. Given that, router would check if there
is a inside rule that may need to check to translate. Those two statements
for ip nat source would do the trick because they would match the statement
and therefore translated the addresses and create the entry from the pool in
the NAT table.
On the return the add-route statement would add the route to the appropriate
interface and perform the translation back.
Those statements would the equivalent for an ip nat inside source statement
however with regular NAT you wouldn't be able to configure this on a single
router since two interface would be overlapping.
I assume that the VRF on the serial side is not needed as long as you don't
want to create the static NAT statement at the end, seems that the VRF is
needed so for every single specific NAT statement you can state the
direction for the NAT you want. This would be the equivalent for an outside
source.
ip nat source static 192.168.123.1 192.168.125.10 vrf services
my2cents
Hope that helps.
On 6/1/07, Kim <support@isolvesystems.com> wrote:
>
> Below is the example taken from DocCD. Can someone explain the logic of
> NVI
> or point me to more info? What is the "ip vrf forwarding" under the
> interface for?
>
> Enabling NAT Virtual Interface: Example
>
> The following example shows how to configure NAT virtual interfaces
> without
> the use of inside or outside source addresses.
>
> interface Ethernet0/0
>
> ip vrf forwarding bank
>
> ip address 192.168.122.1 255.255.255.0
>
> ip nat enable
>
> !
>
> interface Ethernet1/0
>
> ip vrf forwarding park
>
> ip address 192.168.122.1 255.255.255.0
>
> ip nat enable
>
> !
>
> interface Serial2/0
>
> ip vrf forwarding services
>
> ip address 192.168.123.2 255.255.255.0
>
> ip nat enable
>
> !
>
> ip nat pool NAT 192.168.25.20 192.168.25.30 netmask 255.255.255.0add-route
>
> ip nat source list 1 pool NAT vrf bank overload
>
> ip nat source list 1 pool NAT vrf park overload
>
> ip nat source static 192.168.123.1 192.168.125.10 vrf services
>
> !
>
> access-list 1 permit 192.168.122.20
>
> access-list 1 permit 192.168.122.0 0.0.0.255
>
>
>
> --
> http://www.isolvesystems.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:46 ART