From: Krake, Kris (KKrake@xxxxxxxxxxxx)
Date: Mon Dec 10 2001 - 22:11:33 GMT-3
I couldn't resist the sniffer test :)...since you guys resonded I thought
I'd let you know what I found.
This is what I found. The router will replace the MAC of the next hop
router in the layer 2 header and the TCP/UDP layer 3 headers packets will
remain unchanged for the original destination. Routing never takes place
(as you mentioned) and the frame is forwarded to the correct destination
even if the router has a layer 3 ROUTE pointing out the wrong interface.
This explains why the destination debug showed a packet from the *true*
source (I was only seeing layer 3 here).
Thanks for the help,
Kris
-----Original Message-----
From: routerkid [mailto:routerkid@adelphia.net]
Sent: Monday, December 10, 2001 7:06 PM
To: Krake, Kris
Subject: Re: Policy-map - set ip next-hop
basically, the route map next-hop tells the router to set the next hop
address
to what is defined in the route-map regardless of what is in the routing
table.
So you are correct, the routing table will not change but if you were to
look at
the packets on the wire, the packets will be forwarded to the next-hop
definition and not where you would expect if you were looking at the routing
table.. Nothing glamorous...
I would just remember that the route-map next-hop will bypass the routing
table...
HTH...
Krake, Kris wrote:
> I am curious to see what this command actually changes in a packet put on
> the wire (or if it changes that at all?). I am looking at ccbootcamp lab
1
> and have configured it and have it working but expected this to change the
> route table. The route table did not change. Next, I did a debug ip
packet
> on the spoke routers to see if a header had changed and see that the
source
> and destination of the packets is still in tact...again to my surprise. I
> now know that I'm completely off base as to what I thought the (ip
next-hop)
> command actually does. I am considering putting a sniffer on the line and
> see what is actually changed but was wondering if someone who had more
> experience with this could give me the skinny instead so that I may save
> some valuable lab time.
>
> Much obliged...
> KK
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Kris A. Krake
> WAN Engineer
> AEGON Technology Services - NECS
> 502.560.2716
> kkrake@aegonusa.com
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:41 GMT-3