You are right, Marty. I had to enable "no ip route-cache" on the serial
interface of the router doing the relevant debugging, which is the router
that is on the other side of the link where the pings are occurring.
Here's my lab:
Boston Router s0 ------------ s0 Charlotte Router
e0
Boston Router
int s0
192.168.40.1
Charlotte Router
int s0
192.168.40.2
int e0
10.10.0.2
I'm pinging from the Charlotte router to the Charlotte router s0
(192.168.40.2). But I'm debugging on the Boston router, and, sure enough, it
sees the traffic!
The "debug ip icmp" command gives you the first hint that something is
strange.
Boston#debug ip icmp
ICMP packet debugging is on
Boston#
ICMP: redirect sent to 192.168.40.2 for dest 192.168.40.2, use gw
192.168.40.2
ICMP: redirect sent to 192.168.40.2 for dest 192.168.40.2, use gw
192.168.40.2
ICMP: redirect sent to 192.168.40.2 for dest 192.168.40.2, use gw
192.168.40.2
ICMP: redirect sent to 192.168.40.2 for dest 192.168.40.2, use gw
192.168.40.2
ICMP: redirect sent to 192.168.40.2 for dest 192.168.40.2, use gw
192.168.40.2
But "debug ip packet detail" really shows you that the packets are indeed
arriving at the other end of the serial link. As you know, in the following
output, the type 8, code 0 packets are pings. The type 5, code 0 are
redirects. We also see the type 0, code 0 packets, which are ping replies.
Boston#debug ip packet detail
IP packet debugging is on (detailed)
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=8, code=0
IP: s=192.168.40.1 (local), d=192.168.40.2 (Serial0), len 72, sending
ICMP type=5, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=8, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=8, code=0
IP: s=192.168.40.1 (local), d=192.168.40.2 (Serial0), len 60, sending
ICMP type=5, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=8, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=8, code=0
IP: s=192.168.40.1 (local), d=192.168.40.2 (Serial0), len 60, sending
ICMP type=5, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=8, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=8, code=0
IP: s=192.168.40.1 (local), d=192.168.40.2 (Serial0), len 60, sending
ICMP type=5, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=8, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=8, code=0
IP: s=192.168.40.1 (local), d=192.168.40.2 (Serial0), len 60, sending
ICMP type=5, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=8, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), len 104, redirected
ICMP type=0, code=0
IP: s=192.168.40.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2,
forward
ICMP type=0, code=0
The Charlotte router is automatically selecting the serial interface as the
source address. But the results are somewhat similar if I do extended pings
and use the Ethernet interface, with some differences. There's no redirects
and I also don't see the ping replies. The router seems to just happily
forward the packets in this case.
Boston#debug ip packet detail
IP packet debugging is on (detailed)
Boston#
IP: s=10.10.0.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2, forward
ICMP type=8, code=0
IP: s=10.10.0.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2, forward
ICMP type=8, code=0
IP: s=10.10.0.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2, forward
ICMP type=8, code=0
IP: s=10.10.0.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2, forward
ICMP type=8, code=0
IP: s=10.10.0.2 (Serial0), d=192.168.40.2 (Serial0), g=192.168.40.2, forward
ICMP type=8, code=0
Weird. I can see that it is useful, though, that the packet actually goes
out even when the interface is looped.
Priscilla
Marty Adkins wrote:
>
> Priscilla Oppenheimer wrote:
> >
> > s vermill wrote:
> > >
> > > Anyone smart on interworkings of Cisco routers care to
> clarify
> > > something for me? I was in a discussion with someone in
> > > another forum. It was being discussed how pings from a
> local
> > > ethernet interface to a local serial interface on the same
> > > router actually cross the WAN to which that serial
> interface is
> > > attached and are returned by the distand-end router.
> >
> I'm not totally sure what you mean by "from a local ethernet
> interface".
> If you mean that the router forwarded a packet that arrived on
> its
> Ethernet interface, and the destination was its serial IP, then
> the
> packet will definitely *not* leave the router.
>
> OTOH, if the router itself is the source of the packet, and it
> pings
> its own serial IP, and the outbound interface and layer 2 encap
> are
> resolved and unambiguous, then the router will launch the packet
> out that p2p interface or PVC. I have done exactly what
> Priscilla
> describes, and not only seen the output from "debug ip icmp" on
> the
> neighbor router, but also observed it generating ICMP
> redirects, since
> the packet was forwarded out the interface it arrived on!
>
> This Cisco aberation is extremely useful for troubleshooting
> p2p WAN
> links. When the path has been looped (line protocol up
> (looped)), the
> only IP that is pingable is the directly connected one. That
> the router
> actually sends the packet makes it possible to test the link
> with ping.
>
> Now I wasn't performing an extended ping and sourcing the ping
> from a
> different interface. Maybe that's the difference? I last did
> this
> with IOS 12.0(7)T.
>
> Priscilla, I'm not saying what you observed is wrong! I don't
> have
> access at the moment to replicate it, but I'm positive of what
> I saw --
> I had my students do it in class numerous times.
>
> - Marty
>
>
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=53168&t=53148
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
