From: Rick Stephens (rstephens@xxxxxxxxxx)
Date: Fri Jun 08 2001 - 14:50:35 GMT-3
By the same means, in the configuration below, I am using ip unnumbered on
the outside serial. NAT is working. The static NAT (.129) is for the
outside router interface. This configuration works and is running in a
production environment. Also, notice the single ip nat pool with overload
... the names have been changed to protect the innocent.
!
interface FastEthernet0
ip address 192.168.1.2 255.255.255.0
ip access-group 100 in
ip nat inside
speed auto
!
interface Serial0
description link to Carrier
no ip address
encapsulation frame-relay IETF
frame-relay lmi-type ansi
!
interface Serial0.1 point-to-point
description link to ISP
ip unnumbered FastEthernet0
ip nat outside
frame-relay interface-dlci 734 IETF
!
ip nat pool ABC 100.100.14.131 100.100.14.131 netmask 255.255.255.192
ip nat inside source list 1 pool ABC overload
ip nat inside source static 192.168.1.1 100.100.14.129
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1
no ip http server
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
-----Original Message-----
From: Pickell, Aaryn [mailto:Aaryn.Pickell@getronics.com]
Sent: Friday, June 08, 2001 12:37 PM
To: 'Don Dettmore'; CCIE Lab List
Subject: RE: innards of NAT
Don,
The route lookup can't happen until the packet has been translated,
since the destination is used for the route lookup, and the destination is
going to change. Still, the public address must have a route as well. When
the NAT pool uses addresses from the outside segment (assume you have a /24
on your outside interface, one for the interface itself, and the rest being
used for NAT), then the router will alias for all of those addresses. In
this situation, no route is necessary for those addresses, since they're
directly connected. But, I've seen cases where the NAT pool was a /24 range
of addresses, and the outside interface was a /30. NAT wouldn't work,
because when the ISP routed packets for the /24 pool to the outside
interface, the router would route them back out to the ISP (using a default
route, usually), and eventually the packets would expire. When we added a
route for the /24 range, through an inside interface, all of a sudden NAT
would start working. I've talked this over with some Cisco people, who seem
to indicate that this is normal... that the packet must traverse an outside
and an inside interface before translation will happen. So, the public
address must be routed out an inside interface before NAT will function
properly. Even then, the packet is translated, and then routed according to
the private address (even if that takes a different internal path than the
public range was set to. It seems kind of silly to me, but that's how it's
set up.
As I'm about to send this, it seems like I didn't describe it well. My
apologies.
Aaryn Pickell - CCNP ATM, CCDP, MCSE
Senior Engineer - Routing Protocols
Getronics Inc.
Direct: 713-394-1609
Email:aaryn.pickell@getronics.com
This e-mail message and any attachments are confidential and may be
privileged. If you are not the intended recipient, please notify me
immediately by replying to this message and please destroy all copies of
this message and attachments. Thank you.
> -----Original Message-----
> From: Don Dettmore [mailto:don@donshouse.com]
> Sent: Friday, June 08, 2001 10:38 AM
> To: CCIE Lab List
> Subject: innards of NAT
>
>
> I'm trying to understand how NAT works a little better -
> maybe someone can
> explain this to me.
>
> The following refers to a two-way NAT scenario - that is,
> where both the
> source and destination addresses are translated.
>
> I've noticed that when a packet comes in an 'inside'
> interface (destined for
> an outside interface), first the route lookup occurs, and THEN it is
> translated. But when a packet comes in an 'outside'
> interface (destined for
> an inside interface) first it is translated, THEN the route
> lookup occurs.
>
> Why the difference. A beneficial side effect is that your
> routing table need
> only be composed of inside routes. Is that the reason?
>
> I've only implemented this in situations where I had but one outside
> interface. Does this have anything to do with the results
> I'm seeing? It
> would seem to me that if there were more than one outside
> interface, the NAT
> could not occur first - as possible no NAT need occur (I guess there's
> something to try in the lab).
>
> Anyone have any ideas?
>
> TIA
>
> Don Dettmore
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:20 GMT-3