It munged the picture. That e0 is on Charlotte, not Boston. Also, I forgot to apologize for suggesting that the writer of the Cisco document might be slightly clueless. :-0 Usually TAC documents are great, which is what this one is.
Priscilla Priscilla Oppenheimer wrote: > > 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=53169&t=53148 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
