From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Sat Mar 03 2001 - 13:33:47 GMT-3
Now that you mention it, Nigel, this is the router with the 12.0.15 image
that I have had so many bizarre problems as well. It is the router where I
never bothered to upgrade the eproms when I added flash and upgraded to 12.x
in general.
Nope - that's not is. I've set up pvcs with another router, removed ip
routing from a subinterface so that now the only route to the 20.0.0.0
network is through this other router, and I have the same result. Ping goes
one way, trace goes the other.
Did some finagling, and here are some traces. I am pinging from 10.202.12.2
and to 20.40.40.33. As you can see, the debug ip packet SAYS the gateway is
the one I expect.
3d11h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2),
g=10.10.7.5, le
n 100, forward
3d11h: IP: s=20.40.40.33 (Serial0.1), d=10.202.12.2 (Serial0.3),
g=10.10.8.2, le
n 100, forward
3d11h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2),
g=10.10.7.5, le
n 100, forward
3d11h: IP: s=20.40.40.33 (Serial0.1), d=10.202.12.2 (Serial0.3),
g=10.10.8.2, le
n 100, forward
I checked the 12.1 release notes, and did some clear ip cache, with no
effect. Also entered a no ip route-cache on various interfaces but still no
effect.
I'm going to reconfigure things a bit and see if I can identify a similar
issue in the 11.2 domain. I just wonder if this is another one of the
"gotchas" you're sitting there in the lab, pinging away, happy in the belief
that your policy is working, and it is not. Your mouth falls open in
disbelief when the proctor dings you. Or worse yet, you use the extended
ping, discover the problem yourself, and spend too much time trying to fix
it.
Chuck
-----Original Message-----
From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
Sent: Saturday, March 03, 2001 5:57 AM
To: Nigel Taylor; Chuck Larrieu; Larry Roberts; CCIE_Lab Groupstudy Lis
t
Subject: Re: Policy routing Sanity Check
Chuck,
Ok, I mocked up a basic PBR config to see if I would get the
same results. Unfortunately I was not so lucky. I made my list more
specific as to test packet being sourced from specific interface so I could
verify what packet should and should not be policy routed. In every case on
the ping and trace alike it followed the rules of PBR as we understand it.
I also tested this with the "ip" only ACL statement and that pretty much
covered trace and ping as well. I was wondering... what did the trace while
debugging "ip policy" reveal..?
Interesting thing happened to me this morning. in a simple FR setup hub and
spoke(all physical interfaces) I couldn't get RIP to propagate to on of the
spokes.. Debug revealed I was sending and not receiving routes..
As fate would have it I changed the IOS(from 12.0(15) to 12.1(6) and
everything works.. This is the same router that gave me that FR problem
having to use "wr mem" before the commands would take effect.. Go
figure..:->
Nigel.
----- Original Message -----
From: Nigel Taylor <nigel_taylor@hotmail.com>
To: Chuck Larrieu <chuck@cl.cncdsl.com>; Larry Roberts
<lroberts22@uswest.net>; CCIE_Lab Groupstudy List <ccielab@groupstudy.com>
Sent: Saturday, March 03, 2001 7:13 AM
Subject: Re: Policy routing Sanity Check
> Chuck, Larry,
> In looking at this problem I can't see why the trace
> would work and the ping would not. Trace and ping both use "icmp echo
> request" with varying differences. In the original ACL you defined "ip" as
> the protocol to be policy routed. Try removing the icmp statement and
> opening another session to the HUB router and run "debug ip policy" and
then
> ping from the Spoke from another session. Then try it with the icmp
> statement.
>
> Off to take a quick look.
>
> Nigel.
>
> ----- Original Message -----
> From: Chuck Larrieu <chuck@cl.cncdsl.com>
> To: Larry Roberts <lroberts22@uswest.net>; CCIE_Lab Groupstudy List
> <ccielab@groupstudy.com>
> Sent: Saturday, March 03, 2001 3:32 AM
> Subject: RE: Policy routing Sanity Check
>
>
> > According to the Doc CD, ICMP redirects are disabled by default. But not
> to
> > argue, I entered the command on both the global config and the interface
> in
> > question.
> >
> > No dice, as shown below.
> >
> > Reply to request 4 (16 ms). Received packet has options
> > Total option bytes= 40, padded length=40
> > Record route:
> > (10.10.2.2)
> > (20.253.253.5)
> > (20.254.254.5)
> > (20.6.6.1)
> > (20.254.254.6)
> > (20.253.253.6)
> > (10.10.2.1)
> > (10.202.12.2) <*>
> > (0.0.0.0)
> > End of list
> >
> > Chuck
> >
> > -----Original Message-----
> > From: Larry Roberts [mailto:lroberts22@uswest.net]
> > Sent: Saturday, March 03, 2001 12:22 AM
> > To: Chuck Larrieu; CCIE_Lab Groupstudy List
> > Subject: Re: Policy routing Sanity Check
> >
> > Hi Chuck,
> >
> > Try this, turn off icmp redirects on the hub router with the following
> > command - no ip redirects. With ping the router will redirect the icmp
> > packets to another router if it has a better path.
> >
> > Hope this helps,
> > Larry R.
> >
> > ----- Original Message -----
> > From: "Chuck Larrieu" <chuck@cl.cncdsl.com>
> > To: "CCIE_Lab Groupstudy List" <ccielab@groupstudy.com>
> > Sent: Saturday, March 03, 2001 12:43 AM
> > Subject: Policy routing Sanity Check
> >
> >
> > > 'Cuz it ain't behaving the way I think it is supposed to.
> > >
> > > In my current setup I want IP traffic from my OSPF domain bound for my
> > EIGRP
> > > domain to take a certain path. So on my OSPF hub router I have a
policy
> in
> > > place that directs all traffic bound for the 20.0.0.0 domain to a
> > particular
> > > router.
> > >
> > > Trace takes the desired path, but ping does not. Captures using the
> > extended
> > > ping command, as well as the trace command results follow. Also, my
> > relevant
> > > configurations follow. Notice that the route-map sets the next hop to
> > > 10.10.5.5 Notice that the trace goes through 10.10.5.5 Notice that
ping
> > > goes by a completely different path.
> > >
> > > On the access-list, I added the first line specifying ICMP after
> noticing
> > > the failure of the original access-list, which consisted only of the
> > second
> > > line, was not working.
> > >
> > > OK all you comedians out there, here is my straight line for the
> evening.:
> > > Am I nuts or is this not working the way it is supposed to?
> > >
> > > Hub router relevant configuration
> > >
> > > interface Serial0.1 point-to-point
> > > ip address 10.10.2.1 255.255.255.0
> > > no ip directed-broadcast
> > > ip policy route-map R1POLICY
> > > frame-relay interface-dlci 102
> > >
> > > access-list 101 permit icmp any 20.0.0.0 0.255.255.255
> > > access-list 101 permit ip any 20.0.0.0 0.255.255.255
> > > route-map R1POLICY permit 10
> > > match ip address 101
> > > set ip next-hop 10.10.5.5
> > >
> > >
> > > spoke route relevant data traces
> > >
> > > Router_2#trace 20.6.6.1
> > >
> > > Type escape sequence to abort.
> > > Tracing the route to 20.6.6.1
> > >
> > > 1 10.10.2.1 4 msec 4 msec 4 msec
> > > 2 10.10.5.5 24 msec 8 msec 8 msec
> > > 3 20.254.254.6 12 msec * 12 msec
> > > Router_2#
> > >
> > > ( one of the extended ping with record option replies - all of them
are
> > the
> > > same )
> > >
> > > Reply to request 4 (16 ms). Received packet has options
> > > Total option bytes= 40, padded length=40
> > > Record route:
> > > (10.10.2.2)
> > > (20.253.253.5)
> > > (20.254.254.5)
> > > (20.6.6.1)
> > > (20.254.254.6)
> > > (20.253.253.6)
> > > (10.10.2.1)
> > > (10.202.12.2) <*>
> > > (0.0.0.0)
> > > End of list
> > >
> > > Chuck
> > > ----------------------
> > > I am Locutus, a CCIE Lab Proctor. Xx_Brain_dumps_xX are futile. Your
> life
> > as
> > > it has been is over ( if you hope to pass ) From this time forward,
you
> > will
> > > study US!
> > > ( apologies to the folks at Star Trek TNG )
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:19 GMT-3