The debugs are being run on the router that is doing the pinging.

I posted my config and then received the rest of the thread and considered
the matter solved.  I can finish this out if you like, but I think that the
problem has already been solved...


Thanks

Larry
 

-----Original Message-----
From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 11, 2002 10:02 PM
To: [EMAIL PROTECTED]
Subject: RE: The Origin of Echos and Echo Replies [7:53148]


Interesting test. I think I understand it. ;-)

Where are the debugs being run, by the way? The local router that is pinging
or the router at the other end? It looks like they are on the local router
doing the pings? Try running them on the other router. Be sure to turn fast
switching off on the other router.

Regardless, what you are seeing makes sense considering this (unbelievable
but true ;-) discovery that pings to a local serial interface go out across
the serial link and bounce back from the router on the other end of the
link. So the subinterface on the other end of the link better be up, eh?

Thanks

Priscilla

Roberts, Larry wrote:
> 
> OK, I tested a theory.
> 
> I shut down the remote end sub-interface. The local interface is still 
> up. The PVC still shows active.
> I could not ping the local interface hmmmm...
> A debug ip packet still showed the packet being sent.
> 
> Now I bring the interface back up and the ping is successful.
> I did an extended ping and with a count of 1 and here is the
> output.
> 
> 09:41:07: IP: s=172.16.13.1 (local), d=172.16.13.1 (Serial0/0.2), len 
> 100, sending
> 09:41:07:     ICMP type=8, code=0
> 09:41:07: IP: s=172.16.13.1 (Serial0/0.2), d=172.16.13.1
> (Serial0/0.2), len
> 100, rcvd 3
> 09:41:07:     ICMP type=8, code=0
> 09:41:07: IP: s=172.16.13.1 (local), d=172.16.13.1
> (Serial0/0.2), len 100,
> sending
> 09:41:07:     ICMP type=0, code=0
> 09:41:07: IP: s=172.16.13.1 (Serial0/0.2), d=172.16.13.1
> (Serial0/0.2), len
> 100, rcvd 3
> 09:41:07:     ICMP type=0, code=0
> 
> What I find interesting is that both an echo and echo-reply is sent 
> and received.
> 
> Now repeating the first experience with a single packet and debug ip 
> packet 100 detail enabled gives:
> 
> 09:43:51: IP: s=172.16.13.1 (local), d=172.16.13.1 (Serial0/0.2), len 
> 100, sending
> 09:43:51:     ICMP type=8, code=0
> 
> Does this help anyone, or can anyone explain this behavior ?
> 
> 
> 
> Thanks
> 
> Larry
>  
> 
> -----Original Message-----
> From: s vermill [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 11, 2002 8:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: The Origin of Echos and Echo Replies [7:53148]
> 
> 
> Marty,
> 
> And I forgot to ask below, any thoughts as to whether or not the echo
> *replies* are somehow bounced off of the distant-end router
> too?  That is
> what I found the most difficult to accept and was stretching
> for a theory
> that might possibly explain it.
> 
> Thanks again,
> 
> Scott
> 
> s vermill wrote:
> > 
> > Marty Adkins wrote:
> > > > 
> > > 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.
> > 
> > As you surmised, this was sourced from the ethernet interface
> using an
> > extended ping - it did not arrive there from somewhere else.
> > 
> > > 
> > > 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!
> > 
> > I too have done what Priscilla tried and did not see the
> debug output.
> > 
> > > 
> > > 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.
> > 
> > That, sir, is an excellent thing to remember.  I never
> thought about
> > it, but it sure is useful.  Many thanks.
> > 
> > > 
> > > 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=53176&t=53148
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to