interesting...

johnnynodough

In setting up a new lab, I discovered something rather interesting today. It seems that you can ping a neighbor device, and get a response back quicker than pinging your own local interface, even when using an extended ping command and specifying that interface is the one to ping, and the one to ping from.

Nothing life changing, just thought it was interesting.

R5_2610_B#show int s1/1
Serial1/1 is up, line protocol is up
Hardware is CD2430 in sync mode
Internet address is 172.0.4.1/24
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: CDPCP, IPCP, loopback not set
Keepalive set (10 sec)
Last input 00:00:04, output 00:00:04, output hang never
Last clearing of "show interface" counters 00:29:52
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 96 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
114 packets input, 7150 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
3 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
145 packets output, 9995 bytes, 0 underruns
0 output errors, 0 collisions, 49 interface resets
0 output buffer failures, 0 output buffers swapped out
9 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
R5_2610_B#ping 172.0.4.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.0.4.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
R5_2610_B#ping 172.0.4.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.0.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
R5_2610_B#ping
Protocol [ip]:
Target IP address: 172.0.4.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.0.4.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.0.4.1, timeout is 2 seconds:
Packet sent with a source address of 172.0.4.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R5_2610_B#

1Ste

I guess thast would be interesting if I understood more than 1/32 of it.
I guess i need to read alot.

SV

Interesting. Does this happen every time or was it just once….

johnnynodough

Its very consistent. I am doing some more playing around, seeing if its consistent across mutilple platforms and accross mutiple links. This was done on a 2610 with a NM-4A/S module with PPP encapsulation, neighbor is a 2501., so I am also checking the delay on the e0 interface, and checking on a 2501 serial port and enet port, and a 1710 e0 and Fa0.

Pretty much useless information, but its kinda interesting to me.

johnnynodough

OK, now its even more useless information

Ran through several scenarios, it seems to be only on this module. A WIC-1T in a 2610 pings at ~ the same speed whether interface or neighbor, the enet ports on 1710, 2610, and 2501 all keep same speed in same scenario, and the serial ports on the 2501's ping at the same speed as well.

So whats the summary? The low speed 4 port synch/asynch modules seem a bit underdesigned, or I just have a flaky one.