From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Sun Mar 04 2001 - 00:09:01 GMT-3
Sorry. Had to put in some wife time :-> And let me just say that the Orchid
Show was something I've been wanting to attend for several years now.....
First - I had made some reconfigurations earlier, to test the theory that
this was an ios bug onR1 in my setup. These traces are being done on R3,
which is the new policy router based on the revised configuration.
Following are some traces from the deb ip policy. What we are looking for is
the redirection of packets to 10.10.5.5 - the interface of the long way
router.
The first is the yield from and extended ping command. Notice that there is
a policy match, and that the trace claims that the packets are sent out the
interface 10.10.7.5 However, and extended ping on the source router, using
the route record feature, continues to indicate the path as being what I
want. Way down at the bottom of this email are traces after reconfiguring
again. I want to test a theory that this had something to do with E1 routes.
So I changed things around to have al EIGRP routes redistributed as E2's. I
did this because other experiments indicate that you cannot use route maps
to change the cost metric of E1 routes, nor the next hop address of E1
routes. But you can with E2. I wanted to be sure that this was not one of
those kinds of issues
I'm at the point where I'm going to conclude that ping is not the right tool
to use to test policy routing. I don't get this. Doyle doesn't mention this
as an issue. ( although I presume he was working with 11.x ios versions. I
have not yet tested this as a theory. )
Chuck
PS I'm going to try to get a diagram of this mess onto my web site. Give me
a few minutes to draw it out
www.chuck.to/policymess.bmp
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33, len 500, policy match
3d21h: IP: route map TESTPOLICY, item 10, permit
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 500,
policy
routed
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33, len 500, policy match
3d21h: IP: route map TESTPOLICY, item 10, permit
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 500,
policy
routed
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33, len 500, policy match
3d21h: IP: route map TESTPOLICY, item 10, permit
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 500,
policy
routed
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33, len 500, policy match
3d21h: IP: route map TESTPOLICY, item 10, permit
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 500,
policy
routed
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33, len 500, policy match
3d21h: IP: route map TESTPOLICY, item 10, permit
3d21h: IP: s=10.202.12.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 500,
policy
routed
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
Router_3#
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33, len 28, policy match
3d21h: IP: route map TESTPOLICY, item 20, permit
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 28,
policy ro
uted
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33, len 28, policy match
3d21h: IP: route map TESTPOLICY, item 20, permit
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 28,
policy ro
uted
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33, len 28, policy match
3d21h: IP: route map TESTPOLICY, item 20, permit
3d21h: IP: s=10.10.8.2 (Serial0.3), d=20.40.40.33 (Serial0.2), len 28,
policy ro
uted
3d21h: IP: Serial0.3 to Serial0.2 10.10.7.5
R1 again
22:45:29: IP: Serial0.1 to Serial0.3 10.10.5.5
22:45:29: IP: s=10.10.2.2 (Serial0.1), d=20.40.40.33, len 28, policy match
22:45:29: IP: route map R1POLICY, item 10, permit
22:45:29: IP: s=10.10.2.2 (Serial0.1), d=20.40.40.33 (Serial0.3), len 28,
policy
routed
22:45:29: IP: Serial0.1 to Serial0.3 10.10.5.5
22:45:32: IP: s=10.10.2.2 (Serial0.1), d=20.40.40.33, len 28, policy match
22:45:32: IP: route map R1POLICY, item 10, permit
22:45:32: IP: s=10.10.2.2 (Serial0.1), d=20.40.40.33 (Serial0.3), len 28,
policy
routed
22:45:32: IP: Serial0.1 to Serial0.3 10.10.5.5
OUTPUT OF RECORD ROUTE OPTION - does not show 10.10.5.5
(20.254.254.5)
(20.40.40.33)
(20.253.253.6)
(10.10.2.1)
(10.202.12.2) <*>
(0.0.0.0)
(0.0.0.0)
End of list
Reply to request 9 (32 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.40.40.33)
(20.253.253.6)
(10.10.2.1)
(10.202.12.2) <*>
(0.0.0.0)
(0.0.0.0)
End of list
Success rate is 100 percent (10/10), round-trip min/avg/max = 28/33/60 ms
Router_2#
Tracing the route to 20.40.40.33 - notice 10.10.5.5 shows as one of the
transit points
1 10.10.2.1 8 msec 8 msec 8 msec
2 10.10.5.5 24 msec 20 msec 24 msec
3 20.254.254.4 24 msec * 108 msec
Router_2#
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nigel Taylor
Sent: Saturday, March 03, 2001 11:28 AM
To: Chuck Larrieu; Larry Roberts; CCIE_Lab Groupstudy List
Subject: Re: Policy routing Sanity Check
Chuck,
The "debug ip policy" on the router where the ip policy map
is defined yield no results....
That's the debug I was looking to see if their were anything weird...
Nigel..
----- Original Message -----
From: Chuck Larrieu <chuck@cl.cncdsl.com>
To: Nigel Taylor <nigel_taylor@hotmail.com>; Larry Roberts
<lroberts22@uswest.net>; CCIE_Lab Groupstudy List <ccielab@groupstudy.com>
Sent: Saturday, March 03, 2001 11:33 AM
Subject: RE: Policy routing Sanity Check
> 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 List
> 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