[c-nsp] IOS 12.4 and NAT

[Joe Maimon]

Gert Doering wrote:
> Hi,
> 
> On Thu, May 05, 2005 at 10:34:27AM +0200, Carsten Bormann wrote:
> 
>>>what's "NVI enhancement"?  Any pointers?
>>
>>While the US sleeps:
>>
>>http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/ 
>>123newft/123t/123t_14/gtnatvi.htm
> 
> 
> Ah, thanks.  So finally Cisco has fallen to market pressure "the way
> you do it is much too complicated, we need a simple on/off switch"
> (which computer magazines really love to do - "Cisco: bad marks, too
> complicated, no wizard" - quite unfortunately so).
> 
> I'm sort of sorry to see that happen.  The old way to do it is
> incredibly powerful, and after getting used to it, certainly more than
> appropriate - and having yet another way that basically does the same
> thing in a different way means "more code, more flash+ram, more bugs"
> (as people seem to be observing).
> 
> The benefits listed ("A NAT table is maintained per interface for better
> performance and scalability.") isn't something I buy - that's an internal
> optimization, not something that needs to show up in the config mode.
> 
> gert
> 
The old way was basically "you have to cross the street from outside to 
inside so that the nat car can try to hit you"

The old way has lots of problems, namely being that you now have to 
declare every interface in your nat router as either inside or outside.

Undeclared interfaces in my experience exhibited unpredictable nat 
behavior for flows. Usualy they did NOT get natting, but often enough it 
did. Also proper design demands you do not leak private space to your 
customers who dont expect it, so you have to declare all of them as 
outside as well.

And then you are faced with issues when you want a nat to apply to 
traffic that does not cross the nat "street" from outside to inside, but 
instead merely walks along the side of the street, either the outside or 
the inside one. Nat-on-a-stick anyone?

The old behavior while allowing all kinds of subtle complexity also has 
a tendency of requiring it.

NVI while potentialy something that fits the bill for stuff I have been 
trying to do for a while (havent labbed it yet), doesnt seem to let you 
attach a specific nat statement to a specific interface (let alone in 
only one direction on the interface).

You are apparently supposed to limit the scope of the nat using 
route-map match statements and/or VRF's. Which is fine enough for my 
purposes.

But here is a question:

The ACL example is pretty skimpy (as is usual in CCO documentation). How 
about a real one usuable for the real world that demonstrates how IOS 
evaluates it for ingress AND for egress traffic (note the assumption of 
evaluation for egress traffic instead of just a table check of existing 
sessions)?

Something that would be used for the old way:

int fa0
ip nat outside
ip address 1.1.1.1 255.255.255.0
int fa1
ip nat inside
ip address 10.10.10.0 255.255.255.0
ip nat inside source route-map inside-nat-fa0 fa0 overload
ip access-list extended inside-nat-fa0
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip 10.0.0.0 0.255.255.255
permit ip 172.16.0.0 0.15.255.255
permit ip 192.168.0.0 0.0.255.255
deny ip any any
route-map inside-nat-fa0 permit 10
match interface fa0
match ip address inside-nat-fa0
route-map inside-nat-fa0 deny 100


Which would allow all rfc1918 inside space addressed to non-rfc1918 
outside space to be natted but would not nat

a) sourced from rfc1918 space addressed to "outside" rfc1918
b) sourced from non-rfc1918 space addressed to anything.


How does this translate into NVI ?

And one more thing. Where is the "Virtual" part of this? I am missing 
something here.

Joe