[c-nsp] IOS 12.4 and NAT

[Gert Doering]

Hi,

On Thu, May 05, 2005 at 06:10:10AM -0400, Joe Maimon wrote:
> >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 old way was basically "you have to cross the street from outside to 
> inside so that the nat car can try to hit you"

Yes, and that was well-documented.

> 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.

Which is a good thing - make up your mind what you want to achieve, and
then tell it to the box, instead of having the box *guess*.

In a way, this is not very much different now, except that "ip nat
inside" is implied (on all interfaces that are not "ip nat enable"), 
*but* you loose flexibility in not being able to say "no NAT here!".

> Undeclared interfaces in my experience exhibited unpredictable nat 
> behavior for flows. Usualy they did NOT get natting, but often enough it 
> did. 

The documented behaviour is "no NAT".  If it doesn't behave that way,
it's a bug - and changing the CLI is not going to fix those (as people
experience).

> 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.

So where's the difference?  Now you need to declare all of them as
"ip nat enabled", now not much gained.  Except, as the documentation seems
to imply ("NAT table tied to interface"), problems with asymmetric routing 
and non-shared NAT state between multiple "outside" interfaces.

> 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?

Will the new way to do things *change* that?

[..]
> 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.

route-maps are not supported, as per the documentation.  

NVIs are not a "more powerful to help you solve things", they are an 
"automatic pushbutton to please lazy admins".

gert
-- 
Gert Doering
Mobile communications ... right now writing from * RIPE 50 @ Stockholm *