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=53170&t=53148 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
