From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Sep 20 2004 - 18:02:30 GMT-3
Thank you Marvin. It sounds like you've done this before.
Tim
----- Original Message -----
From: "marvin greenlee" <marvin@ccbootcamp.com>
To: <ccielab@groupstudy.com>
Sent: Monday, September 20, 2004 4:44 PM
Subject: RE: NAT on a Stick [bcc][faked-from]
> If you set the next hop to be the address of the loopback, the router will
> respond with the message: "% Warning: Next hop address is our address".
By
> setting the next hop to another address on that network, the router makes
> the decision to send the traffic out that interface.
>
> - Marvin Greenlee, CCIE#12237
> Network Learning Inc
> marvin@ccbootcamp.com
> www.ccbootcamp.com (Cisco Training)
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ccie2be
> Sent: Monday, September 20, 2004 3:01 PM
> To: john matijevic; 'Group Study'
> Subject: Re: NAT on a Stick
>
> Hi John,
>
> Thanks for that comprehensive explanation. However, while I understand
> everything you said re: the order of opertions, etc, what still isn't
> clear
> to me is why the loopback adsress itself wasn't used - just another ip
> address in the same subnet. Couldn't and shouldn't the ip address of
> the
> loopback be used as the next-hop address? If not, why?
>
> Thanks again, Tim
>
> ----- Original Message -----
> From: "john matijevic" <matijevi@bellsouth.net>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Group Study'"
> <ccielab@groupstudy.com>
> Sent: Monday, September 20, 2004 2:11 PM
> Subject: RE: NAT on a Stick
>
>
> > Hello Tim,
> > In this example you stated:
> > "In both examples, in the policy routing route-map, the next-hop
> address
> > is set
> > to a non-existent address. How can this be?"
> >
> > The reason for the policy routing to the non-existent address, is
> stated
> > in the debug of the document you provided:
> > !--- Now that the routing decision has been made, NAT takes place. We
> > can
> > !--- see above that the address 192.168.2.1 is translated to 10.0.0.12
> > and
> > !--- this packet is forwarded out Ethernet 0 to the local host.
> > !--- Note: When a packet is going from inside to outside, it is routed
> > and
> > !--- then translated (NAT). In the opposite direction (outside to
> > inside),
> > !--- NAT takes place first.
> >
> > So in essence the routing has to take place first in the example
> because
> > the inside address is the Ethernet and the outside address is the
> > loopback, because the host that is pinging is from the outside,
> > 177.10.1.3 in this case. I think the confusion in this example, and in
> > many NAT examples I have seen comes from seeing the inside vs. outside
> > network. Even thought the address is non-existent, the important
> concept
> > here is the address is on the same network as the loopback so that the
> > policy routing can take place, in order for nat to follow.
> >
> > In the second case:
> > First there is a ping from inside of the network to the outside, which
> > results in the policy routing before the Nat.
> >
> > Than the ping is issued from outside of the network to the inside.
> > In which case the nat is done before the policy routing, which in this
> > case, its not matched and is forward normally.
> >
> > "!--- The return packet is coming into the e0/0 interface which is a
> NAT
> >
> > !--- outside interface. In this direction (outside to inside),
> > translation
> > !--- occurs before routing. The above output shows the translation
> > taking place."
> >
> >
> > The translation will occur before the policy routing, when the outside
> > host pings to the inside network.
> >
> > Please let me know Tim, if this makes more sense to you, if not I can
> > try and do a repro later on. NAT is very important topic, and can be
> > quite confusing, because it is one of the technologies, in my opinion
> > that is not documented as well as it should be.
> >
> > Sincerely,
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > CEO
> > IgorTek Inc.
> > 151 Crandon Blvd. #402
> > Key Biscayne, FL 33149
> > Hablo Espanol
> > 305-321-6232
> > http://home.bellsouth.net/p/PWP-CCIE
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > ccie2be
> > Sent: Monday, September 20, 2004 11:39 AM
> > To: Group Study
> > Subject: NAT on a Stick
> >
> > Hi guys,
> >
> > I came a cross this doc on the above topic:
> >
> http://www.cisco.com/en/US/partner/tech/tk648/tk361/technologies_tech_no
> > te091
> > 86a0080094430.shtml
> >
> >
> > I must admit I don't really fully understand it.
> >
> > In both examples, in the policy roting route-map, the next-hop address
> > is set
> > to a non-existent address. How can this be?
> >
> >
> > On a more practical level, how possible is something like this in the
> > lab. I
> > know, of course, all supported IOS features are fair game, but I find
> it
> > difficult to imagine Cisco coming up with a scenario that recreates a
> > NAT on a
> > stick requirement given that there aren't any hosts in the actual lab
> > and
> > loopback interfaces don't look like they could substitute for the
> hosts
> > shown
> > in the examples in this doc.
> >
> > BTW, I don't want anyone to break the NDA, just looking for comments
> on
> > the
> > feasibility of creating a similar NAT on a Stick scenario in the lab.
> >
> > Thanks, Tim
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:46 GMT-3