PING xxxxxxxx (xxx.x.xx.xx) 56(84) bytes of data.
64 bytes from xxx.x.xx.xx: icmp_seq=3 ttl=243 time=56.8 ms
64 bytes from xxx.x.xx.xx: icmp_seq=7 ttl=243 time=57.8 ms
64 bytes from xxx.x.xx.xx: icmp_seq=11 ttl=243 time=59.4 ms
64 bytes from xxx.x.xx.xx: icmp_seq=15 ttl=243 time=56.1 ms
64 bytes from xxx.x.xx.xx: icmp_seq=19 ttl=243 time=54.9 ms
64 bytes from xxx.x.xx.xx: icmp_seq=23 ttl=243 time=56.1 ms
24 packets transmitted, 6 received, 75% packet loss, time 23066ms
rtt min/avg/max/mdev = 54.919/56.885/59.451/1.464 ms
Here is the output of netstat -p udp.
udp:
1110538 datagrams received
0 incomplete headers
0 bad data length fields
0 bad checksums
324 dropped due to no socket
713584 broadcast/multicast datagrams dropped due to no socket
0 socket buffer overflows
396630 delivered
399468 datagrams output
I googled before posting and couldn't find the answer, if anybody can
help me out, i'd appreciate it.
Thanks in advance.
I suspect misconfigured routing. check "netstat -rn" and do "route get
<some host in your public network>" 4 times. check which route and
interface is selected.
jgann
> technick wrote:
>> 64 bytes from xxx.x.xx.xx: icmp_seq=23 ttl=243 time=56.1 ms
^^^^
>> Here is the output of netstat -p udp.
^^^
> I suspect misconfigured routing. check "netstat -rn" and do "route get
><some host in your public network>" 4 times. check which route and
> interface is selected.
Also, try netstat -p icmp to see if something useful comes up there.
Pings use ICMP, not UDP.
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
If you have two default gateways, try disabling one temporarily with a
route delete default (insert ip address here) and try your ping.
Add it back with route add default (ip address)
*note: route command doesn't make a permanent change - reboot will
bring it back.
And obviously if your doing this remotely then only try removing the
private one or else you'll knock yourself off the connection.
We had issues with remote access trying to route in on one interface
and back out through the private.
Local traffic wasn't affected.
Just out of curiosity, is this an Etherchannel interface?
Do an "lsattr -El ent_device -a mode" (where ent_device is, say ent1,
if you are using en1 as your net interface). If you are not running
etherchannel you should get an error like "lsattr: 0514-528 The "mode"
attribute does not exist in the predefined device configuration
database." Else, it will return an etherchannel mode type such as
"8023ad".
It *shouldn't* be the case that this affects anything, but we have had
Etherchannel interfaces drop X of N packets when X ports of the N
making up a channel were down (for err_disable, or by mistaken
unplugging, etc.), and the behavior was as you describe.
If you have etherchannel, have your network guys check all of your
connected ports for down states.
Best,
Mark
--
Mark J. Cecil -- Senior UNIX Engineer and Part-time Curmudgeon
New Orleans, Louisiana
http://notrealswift.blogspot.com
"La Nouvelle-Orleans... Maintenant et pour toujours"
Scottz, I owe you a beer the next time you in the Atlanta area!