When doing an extended ping from Ethernet IP to Serial IP and vice versa does this ping cross just the router or does it also cross the WAN included in the serial interface?
Just crosses the router, not the link. Reason is when you ping, router looks in routing table for route, see's it's directly connected and hence no need to send it out the wire. If it's a frame relay serial link, you need to add a mapping to ping it's own IP.
What do you mean by add mapping to ping it's own IP? What kind of commands would you use? We are dropping packets doing extended ping from ethernet to serial and vice versa, loopback to ethernet is OK...
I assume you are using frame then. This is for frame relay only (frame is not like ethernet - which is broadcast). To ping your own IP you need a frame relay map statement (maps layer 3 to layer 2).
ip address 22.214.171.124 255.255.255.0
frame-relay map ip 126.96.36.199 160
frame-relay map ip 188.8.131.52 160
frame-relay interface-dlci 160
You say you are dropping packets, does that mean it fails 100% or 50%?
Is this a busy router? I seem to recall that Cisco routers give a very low priority to echos and echo replies that are generated by the router itself. They are the first to go in a congested environment.
CPU and memory are not an issue. Router has been rebooted along with external CSU/DSU. Concord application polling shows bandwidth utilization of 3 % spike son 64 K CIR. Ping response is 75 % with 1100 byte packet, 20 times and 50 % with 1500 byte packet.
1) Three useful ping data patterns that expose line problems include the
0x0000 - Line-code mismatches
0xFFFF - Repeater power problems
0x4040 - Timing problems
The 0x4040 extended ping pattern also enables you to detect jitter and
wander. T1 phase variations greater than or equal to 10Hz are considered
jitter, and variations less than 10Hz are considered wander.
Target IP address: XXX.XXX.XXX.XXX (local and remote)
Repeat count : 50
Datagram size :
Timeout in seconds :
Extended commands [n]: y
Type of service :
Set DF bit in IP header? [no]:
Validate reply data? [no]: y
Data pattern [0xABCD]: 0x4040
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echoes to XXX.XXX.XXX.XXX, timeout is 2
seconds: Packet has data pattern 0x4040
Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/24 ms"
Ping with each and see results.
2) Also check show controllers T1 for errors (eg slip errors) and show int s0.
Let us know.
In answer to your original question, pings to a local serial interface do cross the WAN - which is likely where your packet loss is taking place.
This doesn't explain why local pings cross the WAN, but I've read this on a couple of occations:
I'll get back to you if I find a better link. Please do likewise.
I did a little more digging around CCO. What I gather is that when you ping an interface, that interface acutally encapsulates the ICMP echo. Thus, it must send it out on the wire and the distant-end device must return it back to be de-encapsulated. According to CCO, the distand-end device must also return the echo reply. It isn't immediately clear to me what that is. I'd still like to see a better step-by-step explanation.
In any case, I saw a few examples where a loopback on the interface was acceptable (mostly ATM examples but I imagine it can be done on a FR interface as well). Give that a try if you can take the link down. See if your success rate improves...
And for anyone interested in a lively discussion and in reading about a bunch of lab experiments that took place in the last day to prove whether or not pings do, in deed, cross the WAN, see a topic on www.groupstudy.com titled "The Origin of Echos and Echo Replies." A noted author tossed her hat into the ring, as did an instructor of one of the better-known Cisco learning partners.