Flood ping of loopback device gives 20% packet loss!

While trying to diagnose a problem with my Airport Express (high packet loss even with a strong signal), I noticed that my Macbook cannot reliably flood ping its own loopback device!
bash-3.2$ $ sudo ping -f 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
....^C
--- 127.0.0.1 ping statistics ---
994 packets transmitted, 750 packets received, 24% packet loss
round-trip min/avg/max/stddev = 0.012/0.017/0.103/0.007 ms
As the loopback interface is internal, I get precisely the same result whether Airport is turned on or off.
This seems completely crazy to me! Anyone have any idea what might be going on?
Message was edited by: zzz Matt Taylor (replaced ping output with one with linebreaks to avoid excessively wide post)

Can't help you specifically with that, but just last night my Atheros AR5008 adapter starting dropping 40%-80% of the packets to my router. It's unusably slow now. I had this problem with the 2.6.38 kernel and was able to solve it by passing the nohwcrypt option to the ath9k module, but that doesn't work anymore.
I'm now on the 3.0.4 kernel, Arch x64. Last updates that MAY be relevant were dbus-sharp, dbus-sharp-glib, and gnutls. I started having problems the day after upgrading these packages. I'm connecting in 802.11n mode.
I've been looking for evidence of related bugs but so far nothing. I wonder if this is a broader issue affecting more than just the Atheros or Ralink drivers?
EDIT: downgrading gnutls from 3.0.3-1 to 3.0.2-1 reduced my packet loss to about 15%, so the internet is now basically usable. I also tried downgrading glib-networking (which I updated to version 2.28.7-5 a few days back), but that didn't seem to help.
Last edited by rsking84 (2011-09-22 01:32:59)

Similar Messages

Verizon FIOS Intermittent Packet Loss Problem - How to Convince Verizon Support it's NOT ME

Hi,
I have been having a problem with Verizon FIOS Internet AND Phone since Thursday afternoon.
Basically I have intermittent outages several times a day of 15-40 seconds where my download doesn't work, but upload still does. This happens on BOTH my phone and internet. Therefore it's not my router or computer equipment causing the problem.
Here's what happens:
- On the internet: I have a periodic download problem where I can receive no data for about 15 - 40 seconds. After that it returns to normal
- On the phone: If I'm on the phone at the same time then during that period of internet loss I also can not hear anything that the person I am talking to says. However they can hear me just fine (ie. download only problem)
I have been talking to Verizon technical support and they have blamed my router and ONT. I have tried switching off the router, and using a different one. Also they have replaced the ONT twice.
* This problem occurs on BOTH the phone and internet at the same time. This clearly suggests the problem is not in my own house.
In fact I know exactly where the problem lies. I did a traceroute to google below:
Tracing route to google.com [74.125.113.106]
over a maximum of 30 hops:
1     4 ms     1 ms    <1 ms 192.168.1.1
2     5 ms     4 ms     4 ms L300.NWRKNJ-VFTTP-122.verizon-gni.net [74.105.157.1]
3     9 ms     8 ms     7 ms G2-0-0-1822.NWRKNJ-LCR-08.verizon-gni.net [130.81.133.156]
4    11 ms     8 ms     7 ms P15-0.NWRKNJ-LCR-07.verizon-gni.net [130.81.30.148]
5     9 ms     6 ms     7 ms so-5-0-0-0.NWRK-BB-RTR1.verizon-gni.net [130.81.29.8]
6     7 ms     6 ms     7 ms 0.so-7-0-0.XL3.EWR6.ALTER.NET [152.63.19.177]
7     9 ms    10 ms     9 ms 0.so-1-0-1.XL3.NYC4.ALTER.NET [152.63.0.213]
8     9 ms     9 ms     9 ms TenGigE0-6-0-0.GW8.NYC4.ALTER.NET [152.63.22.41]
9    33 ms    31 ms    35 ms google-gw.customer.alter.net [152.179.72.62]
10     8 ms    11 ms    10 ms 209.85.252.215
11    18 ms    17 ms    16 ms 209.85.249.11
12    31 ms    29 ms    29 ms 209.85.241.222
13    30 ms    29 ms    29 ms 209.85.241.207
14    41 ms    39 ms    34 ms 209.85.243.1
15    27 ms    27 ms    29 ms vw-in-f106.1e100.net [74.125.113.106]
Trace complete.
Then I pinged each device for hops 2-4. When the problem occurs the first one in the hop - 74.105.157.1 - runs fine. The second device - 130.81.133.156 - times out, and all other devices further down the chain time out. This clearly suggest that the device:
130.81.133.156 has major problems.
I have mentioned this to tech support, but they have no way for me to send them logs. Apparently the support technicians at Verizon can not be trusted with even the most basic of tools like email and the web. They also shield me from the NT (Network technician), who is so special that even the tech support guys are only allowed to text chat with him, not actually talk to him. I have enough logs here to clearly show what the problem is.
The latest from tech support is that they are sending yet another guy by my house tomorrow to witness this problem firsthand. Then he will call support that will text chat with the NT, and MAYBE they'll start thinking it's not me.
My main question here is: "How do I get Verizon to believe it really could be a problem in their own network?"
Here are some threads from last year that explain exactly the same problem I'm having. So it wasn't just me:
http://forums.verizon.com/t5/FiOS-TV-Technical-Assistance/Verizon-FIOS-intermittent-connection-drops...
http://forums.verizon.com/t5/FiOS-Internet/Intermittent-Network-Timeouts/m-p/28138
One person said Verizon finally fixed it by replacing a PON card. I'm not sure if this is the same problem as that though.
I am an avid Starcraft player and this is driving me crazy because I am getting dropped from my games all the time. Also phone conversations suck when there's these big lags where I can't hear who I'm talking to.
I have had Verizon FIOS internet for 3 years now and this is the first problem I've ever had with it. But I'm starting to get majorly frustrated at how long it's taking to resolve the problem.
Here is a sample of the ping logs I was talking about for different devices all at the same time.
Device 2 in the Trace Route:
Reply from 74.105.157.1: bytes=32 time=78ms TTL=126
Reply from 74.105.157.1: bytes=32 time=57ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=35ms TTL=126
Reply from 74.105.157.1: bytes=32 time=34ms TTL=126
Reply from 74.105.157.1: bytes=32 time=41ms TTL=126
Reply from 74.105.157.1: bytes=32 time=43ms TTL=126
Reply from 74.105.157.1: bytes=32 time=59ms TTL=126
Reply from 74.105.157.1: bytes=32 time=24ms TTL=126
Reply from 74.105.157.1: bytes=32 time=48ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=5ms TTL=126
Reply from 74.105.157.1: bytes=32 time=4ms TTL=126
Reply from 74.105.157.1: bytes=32 time=3ms TTL=126
Reply from 74.105.157.1: bytes=32 time=20ms TTL=126
Reply from 74.105.157.1: bytes=32 time=19ms TTL=126
Reply from 74.105.157.1: bytes=32 time=18ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=37ms TTL=126
Reply from 74.105.157.1: bytes=32 time=17ms TTL=126
Reply from 74.105.157.1: bytes=32 time=16ms TTL=126
Device 3 in the Trace Route:
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=9ms TTL=253
Reply from 130.81.133.156: bytes=32 time=10ms TTL=253
Reply from 130.81.133.156: bytes=32 time=13ms TTL=253
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=7ms TTL=253
Reply from 130.81.133.156: bytes=32 time=6ms TTL=253
Reply from 130.81.133.156: bytes=32 time=8ms TTL=253
Reply from 130.81.133.156: bytes=32 time=14ms TTL=253
Device 4 in the Trace Route:
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Reply from 130.81.30.148: bytes=32 time=8ms TTL=252
Reply from 130.81.30.148: bytes=32 time=7ms TTL=252
Reply from 130.81.30.148: bytes=32 time=6ms TTL=252
Any help, thoughts, suggestions, etc would be great appreciated!
~David

I understand your logic, but you have not eliminated 74.105.157.1 as the problem. It could be allowing packets out, like outside callers hearing you, but not allow them back in. Since you have results pinging out, trying ping back in. Use this packet loss tool. You do not need to catch it when it's not working because this tool will ping your IP address (and all the hops in between) for up to 7 days. You will easily see when packet loss is occurring.
If it can successfully ping 74.105.157.1 when the problem occurrs, then 130.81.133.156 is not the issue. This may not help dealing with the personalities at Verizon, but it will help definitively knowing which device is the issue.

"exchange upgrade" now i have 67% packet loss 24...

Following my local exchanges "upgrade" on the 26th of January, my internet is a complete waste of time, my IP profile has been cut in half, and i have had 60-67% packet loss no matter what time of day.
Exchange is Hertford.
Loading even Google takes 3 or 4 refreshes.
"Customer service" in India seem to think the problem can be resolved if I renew my contract. Yeah right!!
So if this is a "care" forum, where is the care for me?

Having finally established that my packet loss was occuring from a BT server and despite over ten hours of calls to "customer help" in India, being repeatedly lied to, fobbed off, and read a script.
I finally got through to a very surprised somebody at BT wholesale who took the issue seriously, having spent over 13 days trying to get action, it got resolved in a day!
My packet loss ceased, however the reset to half IP profile remained, as did my throttled service, to the point I may as well have been on dial up, well I had, had enough!
I requested a MAC code and despite it taking 17 days to get it, not the 5 days as required by Ofcom, I am now free of BT.
My IP profile is reset to where it should be, my service is no longer throttled, and I am now paying only £5.99 a month with plusnet, for the service BT should have been giving me, my line rental is cheaper too.
BT have been a waste of space throughout this whole episode, with the exception of one guy at BT wholesale who was shocked I had managed to get hold of his number, and to give him credit intervened on my behalf when he didn't have too.
BT customer service in India is an absolute disgrace, they work from scripts, lie, obfuscate, prevaricate, are not knowledgeable on any subject, other than contract renewal.
I would rather die a slow and painful death than ever go back.
If you need to check your own line....you can ping it yourself to check for packet loss.
Ping, "pingtest.bt.net" and then traceroute each hop to see where your problem is occuring.
Doing a "whois" on the "bad" hop's IP should give you a "real" world phone number for someone at BT wholesale to plead with.

Router firewall giving packet loss

I have a WRT54GX4 and when I have the built in firewall running it gives me packet loss, most noticibly in the game Red Orchestra. I tried forwaring ports and it still occured. Even if I run the firewall with DMZ on my computer it still gets packet loss. The only way I have found to cure it is to completely disable the routers firewall, which is definantly something I'd like to stay away from.

No issues with the routing.. everything is fine
is this due to flooding, how to rectify it. please help me

Anyone else on 4G LTE seeing fairly high packet loss recently?

For the past week or two I've been noticing quite a bit of packet loss when I run a ping test against 8.8.8.8 (Google DNS) or Yahoo. Each time I run the ping test for 250-500 pings and the packet loss is consistently around 3-5% which is high. Verizon just upgraded the tower in my area to 4G LTE around 3-4 weeks ago and so far my speeds have been pretty great (20-35 Mbps) and my signal is strong without fluctuation (-67 dBi, SINR 20-30) so it's just the packet loss that I'm dealing with.
The first week of being on the 4G LTE I ran a few quick ping tests against Google while setting up my 4G antenna and didn't notice any packet loss but maybe I just didn't run the tests long enough. I've tried pinging a few other servers like 4.2.2.2 (Verizon DNS) and 208.67.220.220 (OpenDNS) and I'm seeing like maybe one dropped packet in 500 pings which is only a .2% packet loss which is a huge difference from results I get pinging Google and Yahoo.
Anyone else noticing packet loss on your 4G LTE connection? I've already opened a ticket with Verizon but I don't know if they'll do anything about it since they like to just tag my location as a marginal coverage area and not look into issues when I report them.

I have as well. I am in Jacksonville, FL and notice when I put my phone into hotspot mode that any machine attached to it will suffer between 6-10% packet loss. It happens in spurts- at first when I connect it is perfect. 60ms pings to www.google.com and barely 1-2 lost packets in the first 5-10 minutes. Then all of a suddenly the whole thing just goes to pot. At first it starts losing a few packets... then it starts losing a BUNCH of packets. Then it gets so bad I start going from the "Request timed out" message to it being "Reply from 192.168.1.1: Destination net unreachable.". This continues for several minutes and then it returns to semi-normality. So a few minutes working, a few minutes not. It's pretty unbearable.
The really frustrating part is seeing AT&T users right next to me with almost 0% packet loss ;_; In the end, I usually have to connect to their phone to do any browsing, since mine simply doesn't allow me to do even the simplest of internet navigation when it gets like that.

PAcket loss during gaming

Hello i have been dealing with bad wifi during gaming. The wifi in general is bad but it is horrible when trying to play online! I am pretty sure that packet loss is the cause of not being able to play online games like Guild Wars and Everquest 2. Have the wifi issues been solved for this computer?

it's a little be hard to help you without laptop model and installed OS. by the way you can try to open a Command prompt and have a ping test once in command prompt type: ping google.com -t check about packet loss or errors. to stop pinging, press Ctrl+C keys

Consistent packet loss just a few hops into Verizon's network

I have had consistent packet loss just a few hops into Verizon's network for some time. I have tried the normal things like rebooting routers and releasing my ip address but none of that helps. Most routes do not have an issue, but there is one particular service in Verizon's network which I have issues with, and it happens to be the server that Verizon routes me through when I am gaming online.
The server is : G0-3-3-6.RCMDVA-LCR-22.verizon-gni.net (130.81.191.80) and I average around 50% packet loss each night. It is just the second hop into my route:
1) My Router Internal IP
2) L100.RCMDVA-VFTTP-16.verizon-gni.net (98.117.88.1) with a ping of 9 and 0 packet loss
3) G0-3-3-6.RCMDVA-LCR-22.verizon-gni.net (130.81.191.80) with a ping of 15 and 50-80% packet loss.
How can I get Verizon to stop routing me through this troublesome server? If I look at the route to goggle.com for example, I don't go through that server and there is no packet loss at all.

mrballcb wrote:
Since it's a congested link, you also should be aware that ICMP (what ping and traceroute use) become nearly useless for determining packet loss. A router backplane assigns a grade to every packet that wants to cross from one network connection to another, and ICMP typically is assigned low grade/value. So when a router is congested and needing to drop packets, ICMP is one of the first ones to get dropped. Less than 1% of your TCP traffic may be having problems, but ICMP failure might be greater than 50%. Find a traceroute program that can use TCP to do the traceroute for more accurate results. I'm not a Windows guy, so I have no clue what programs you have which can do this.
On my Linux/Unix computer, I use tcptraceroute
On a Windows computer, you need to download and install tracetcp.
If you are the original poster (OP) and your issue is solved, please remember to click the "Solution?" button so that others can more easily find it. If anyone has been helpful to you, please show your appreciation by clicking the "Kudos" button.

Packet loss when flood pinging a Mac

I had some trouble transferring large files between my iMac and my MBP the other day and so started a bit of investigation. Mistake really - here is what I found:
All mac targets are running up-to-date Leopard and use intel processors.
The home network has a linksys wireless router - all devices connected by copper.
flood ping tests with command 'sudo ping -f <target>:
from iMac to MBP shows 30% packet loss
from MBP tp iMac shows 33% packet loss
from iMac to windows laptop 0% packet loss
from iMac to linksys router 0% packet loss
from iMac to Freecom NAS box 0% packet loss
from MBP to windows laptop 0% packet loss
from MBP to linksys router 0% packet loss
from MBP to Freecom NAS box 0% packet loss
I took the macbook to work and picked targets on another site, several busy switch hops away.
from MBP to windows desktop 0% packet loss
from MBP to another iMac 26% packet loss
from MBP to mac mini 28% packet loss
from MBP to linux server 0% packet loss
from linux server to MBP 32% packet loss
The firewall is off on all the targets.
Seem clear enough - Mac machines can't handle high ping loads. It is no good telling me they don't have to. If they can answer a ping at all, they should be able to handle the load. It is a perfectly acceptable way of stress testing the link. File transfers are generally not an issue but now I want to know...
Why can't the macs handle the ping floods?
Is this indicative of any other weakness in the IP stack?
Pete

I had a suspicion of packet loss on my internet connection but could not be certain it was the ISP at fault. The fact that I had been having trouble transferring large files between my machines led me to look for possible local problems.
Network fault finding should always examine the hardware first so I wanted to see if there was anything about the cabling or the router which might be causing packet loss.
Actually copying data about the network is a pretty poor way to test things because you have several additional layer of complexity that can colour the results.
When I had narrowed down the flood ping packet loss to the macs, I went hunting on the 'net. There were plenty of people who were reporting various kinds of packet loss. Enough of them that I wondered if there was something more to it. Some of them were talking about similar symptoms to mine. The respondents usually answered a question other than the one asked so I thought I would put up some tests and see if there was actually a problem anywhere.
Now I know it is a 'feature' rather than a fault, I can work around it.
Thanks anyway
Pete

Strange "loopback device" actions on Mac OS X Leopard

Hi all,
I want to explain my little problem to you, hoping someone can give me an answer:
from about a week I'm trying to develop an application that use pylibpcap (a python extension of pcap library) to sniff packets on a pc on ethernet and examine udp packets sniffed.
This python program works very well on LAN, on two different computers (1Gnu/Linux and 1Mac), but if I try to make it work on loopback device (both server program and client program), some strange things happen.
The client simply do this:
*bunnybox:~ alex$ python*
*Python 2.5.1 (r251:54863, Oct 5 2007, 21:08:09)*
*GCC 4.0.1 (Apple Inc. build 5465)] on darwin*
*Type "help", "copyright", "credits" or "license" for more information.*
*>>> import socket*
*>>> s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)*
*>>> s.connect(("127.0.0.1",23))*
*>>> s.send("try to send this")*
16
Listening on loopback device (lo0) with Wireshark (a Sniffer Program), it returns (this is the exported log):
*No. Time Source Destination Protocol Info*
*11 2.840622 127.0.0.1 127.0.0.1 UDP Source port: 49256 Destination port: telnet [UDP CHECKSUM INCORRECT]*
*Frame 11 (48 bytes on wire, 48 bytes captured)*
Null/Loopback
*Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)*
*User Datagram Protocol, Src Port: 49256 (49256), Dst Port: telnet (23)*
*Data (16 bytes)*
*0000 74 72 79 20 74 6f 20 73 65 6e 64 20 74 68 69 73 try to send this*
*As you can see, there is a problem on UDP checksum.*
But if I try the same command on a different computer on my LAN,
for example: a Gnu/Linux Box of Address: 192.168.1.20 (Mac OS X has address: 192.168.1.100),
this is the python code:
*alex@boxxolo ~ $ python*
*Python 2.4.4 (#1, Oct 28 2007, 15:48:55)*
*GCC 4.1.2 (Gentoo 4.1.2)] on linux2*
*Type "help", "copyright", "credits" or "license" for more information.*
*>>> import socket*
*>>> s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)*
*>>> s.connect(("192.168.1.100",23))*
*>>> s.send("try to send this")*
16
and this is the result sniffed by Wireshark on Mac Os X Leopard Computer (this is the exported log):
*No. Time Source Destination Protocol Info*
*4953 57.558319 192.168.1.20 192.168.1.100 UDP Source port: filenet-tms Destination port: telnet*
*Frame 4953 (60 bytes on wire, 60 bytes captured)*
*Ethernet II, Src: 00:e0:18:29:74:28 (00:e0:18:29:74:28), Dst: 00:19:e3:43:85:e8 (00:19:e3:43:85:e8)*
*Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 192.168.1.100 (192.168.1.100)*
*User Datagram Protocol, Src Port: filenet-tms (32768), Dst Port: telnet (23)*
*Data (16 bytes)*
*0000 74 72 79 20 74 6f 20 73 65 6e 64 20 74 68 69 73 try to send this*
As you can see, no errors on UDP Checksum, datagram correctly received and no problems.
*NOTE: don't care about port 23, because no telnet or other services are listening on it, it's only a closed port.*
I don't know if it's a bug of loopback device (lo0),
or a bug of Python's Socket, or pcap problem..
Hope someone can give me an answer,
PS: If this is not an appropriate place to publish this type of question, please tell me where I can.
Have a nice day,
Alessandro.

Hi,
Have you receive some answers about your problem because I have the same ...
Thanks,
Leyoda

Packet loss when pinging from/to a cisco 3560e switch

I see Packet loss when pinging from/to a cisco 3560e switch. CPU utilization is normal.
Switches are running with IOS c3560e-universalk9-mz.122-35.SE5.bin.
Packet loss is observed for all the devices irrespective of directly connected or remote devices.
If i do self pinging, there are no packet loss.
I don't see any error on interface.
Can anyone please help me in resolving this issue.

TCB       Local Address           Foreign Address        (state)
03737C48 10.47.0.229.60053       10.41.81.55.49         CLOSEWAIT
039ACDC4 10.47.0.229.61929       10.41.35.250.49        CLOSEWAIT
03B316C0 10.47.0.229.27544       10.41.81.55.49         CLOSEWAIT
038228F0 10.47.0.229.16506       10.41.35.250.49        CLOSEWAIT
039C3D04 10.47.0.229.15207       10.41.81.55.49         CLOSEWAIT
039A9BD0 10.47.0.229.52983       10.41.81.55.49         CLOSEWAIT
0394152C 10.47.0.229.22425       161.61.35.250.49       CLOSEWAIT
037D811C 10.47.0.229.21117       10.41.81.55.49         CLOSEWAIT
039C12BC 10.47.0.229.37437       10.41.81.55.49         CLOSEWAIT
03933B84 10.47.0.229.34085       161.61.35.250.49       TIMEWAIT
03B32340 10.47.0.229.45729       10.41.81.55.49         CLOSEWAIT
038247D0 10.47.0.229.32816       10.41.81.55.49         CLOSEWAIT
039A92D8 10.47.0.229.38680       161.61.35.250.49       CLOSEWAIT
037370F0 10.47.0.229.13212       10.41.81.55.49         CLOSEWAIT
037D85F0 10.47.0.229.38728       10.41.81.55.49         CLOSEWAIT
03B2B284 10.47.0.229.23428       10.41.81.55.49         CLOSEWAIT
03B2ADB0 10.47.0.229.56836       10.41.81.55.49         CLOSEWAIT
0394BFF0 10.47.0.229.23257       161.61.35.250.49       CLOSEWAIT
036604DC 10.47.0.229.44437       10.41.81.55.49         CLOSEWAIT
0394C700 10.47.0.229.22          192.37.184.211.61639   ESTAB
039B9A68 10.47.0.229.20543       10.41.81.55.49         CLOSEWAIT
03739B28 10.47.0.229.15392       10.41.81.55.49         CLOSEWAIT
TCB       Local Address           Foreign Address        (state)
0392EA48 10.47.0.229.13862       10.41.81.55.49         CLOSEWAIT
0365E23C 10.47.0.229.27856       10.41.81.55.49         CLOSEWAIT
03817C0C 10.47.0.229.64929       10.41.81.55.49         CLOSEWAIT
039357C8 10.47.0.229.22088       10.41.81.55.49         CLOSEWAIT
037375C4 10.47.0.229.21832       10.41.81.55.49         CLOSEWAIT
039C20E8 10.47.0.229.18169       10.41.81.55.49         CLOSEWAIT
03716D08 10.47.0.229.61993       10.41.81.55.49         CLOSEWAIT
039A74E4 10.47.0.229.62948       10.41.81.55.49         CLOSEWAIT
03655480 10.47.0.229.14052       10.41.81.55.49         CLOSEWAIT
039407F0 10.47.0.229.49643       161.61.35.250.49       CLOSEWAIT
039A53AC 10.47.0.229.13233       10.41.81.55.49         CLOSEWAIT
03739FFC 10.47.0.229.16605       10.41.81.55.49         CLOSEWAIT
039B82B8 10.47.0.229.16458       10.41.35.250.49        CLOSEWAIT
039BEBA4 10.47.0.229.64377       10.41.81.55.49         CLOSEWAIT
03741980 10.47.0.229.13866       10.41.81.55.49         CLOSEWAIT
03B3ABF8 10.47.0.229.19365       10.41.81.55.49         CLOSEWAIT
039B5810 10.47.0.229.24768       10.41.81.55.49         CLOSEWAIT
03956E48 10.47.0.229.55980       161.61.35.250.49       CLOSEWAIT
03946820 10.47.0.229.65053       161.61.35.250.49       CLOSEWAIT
037DBE94 10.47.0.229.15283       10.41.81.55.49         CLOSEWAIT
039A4854 10.47.0.229.48562       10.41.81.55.49         CLOSEWAIT
TCB       Local Address           Foreign Address        (state)
03B33320 10.47.0.229.29803       10.41.81.55.49         CLOSEWAIT
03B3B79C 10.47.0.229.12142       10.41.81.55.49         CLOSEWAIT
03713C9C 10.47.0.229.63799       10.41.81.55.49         CLOSEWAIT
039BBECC 10.47.0.229.14763       10.41.81.55.49         CLOSEWAIT
03656E40 10.47.0.229.16357       10.41.81.55.49         CLOSEWAIT
0362A73C 10.47.0.229.62450       10.41.81.55.49         CLOSEWAIT
039B878C 10.47.0.229.64402       161.61.35.250.49       CLOSEWAIT
03826CFC 10.47.0.229.16108       10.41.81.55.49         CLOSEWAIT
03B2CA34 10.47.0.229.17634       10.41.81.55.49         CLOSEWAIT
03AD78D0 10.47.0.229.15249       161.61.35.250.49       CLOSEWAIT
03AD967C 10.47.0.229.20389       161.61.35.250.49       CLOSEWAIT
03B2C560 10.47.0.229.37079       10.41.81.55.49         CLOSEWAIT
039C5128 10.47.0.229.24711       10.41.81.55.49         CLOSEWAIT
03822F74 10.47.0.229.54866       10.41.81.55.49         CLOSEWAIT
0372C5FC 10.47.0.229.13298       10.41.81.55.49         CLOSEWAIT
0372D278 10.47.0.229.12407       10.41.81.55.49         CLOSEWAIT
039A33D0 10.47.0.229.36573       10.41.81.55.49         CLOSEWAIT
039BCEF8 10.47.0.229.53853       10.41.81.55.49         CLOSEWAIT
039C02D8 10.47.0.229.53725       10.41.81.55.49         CLOSEWAIT
039B5CE4 10.47.0.229.58027       10.41.81.55.49         CLOSEWAIT
0381866C 10.47.0.229.17100       10.41.81.55.49         CLOSEWAIT
TCB       Local Address           Foreign Address        (state)
039BB374 10.47.0.229.53148       10.41.81.55.49         CLOSEWAIT
03AD3634 10.47.0.229.19716       161.61.35.250.49       CLOSEWAIT
0362DAA4 10.47.0.229.19479       10.41.81.55.49         CLOSEWAIT
0365AE60 10.47.0.229.62209       10.41.81.55.49         CLOSEWAIT
0362D5D0 10.47.0.229.41327       10.41.81.55.49         CLOSEWAIT
037D7C48 10.47.0.229.58283       10.41.81.55.49         CLOSEWAIT
03955474 10.47.0.229.33810       161.61.35.250.49       CLOSEWAIT
0373B15C 10.47.0.229.23331       10.41.81.55.49         CLOSEWAIT
036628D0 10.47.0.229.46856       10.41.81.55.49         CLOSEWAIT
03819584 10.47.0.229.19861       10.41.81.55.49         CLOSEWAIT
0394D000 10.47.0.229.64732       10.41.35.250.49        CLOSEWAIT
0394B760 10.47.0.229.19967       161.61.35.250.49       CLOSEWAIT
039B6BD4 10.47.0.229.40096       10.41.81.55.49         CLOSEWAIT
03AD7150 10.47.0.229.65184       10.41.35.250.49        CLOSEWAIT
039BC3A0 10.47.0.229.64702       10.41.81.55.49         CLOSEWAIT
03B3A724 10.47.0.229.60399       10.41.81.55.49         CLOSEWAIT
037145E0 10.47.0.229.43951       10.41.81.55.49         CLOSEWAIT
03955EDC 10.47.0.229.29015       161.61.35.250.49       TIMEWAIT
0365FB34 10.47.0.229.13961       10.41.81.55.49         CLOSEWAIT
03828D54 10.47.0.229.12743       10.41.81.55.49         CLOSEWAIT
037DB40C 10.47.0.229.23708       10.41.81.55.49         CLOSEWAIT
TCB       Local Address           Foreign Address        (state)
039AF814 10.47.0.229.15100       10.41.81.55.49         CLOSEWAIT
0392E344 10.47.0.229.23399       10.41.35.250.49        CLOSEWAIT
0393DC3C 10.47.0.229.15393       161.61.35.250.49       CLOSEWAIT
03AD85D0 10.47.0.229.40932       161.61.35.250.49       TIMEWAIT
039574CC 10.47.0.229.25935       10.41.35.250.49        CLOSEWAIT
03738B74 10.47.0.229.58656       10.41.81.55.49         CLOSEWAIT
039AD91C 10.47.0.229.56760       10.41.81.55.49         CLOSEWAIT
03B3BC70 10.47.0.229.15058       10.41.81.55.49         CLOSEWAIT
03B2DC54 10.47.0.229.51131       161.61.35.250.49       CLOSEWAIT
03B393F0 10.47.0.229.11957       10.41.35.250.49        CLOSEWAIT
039B2610 10.47.0.229.33728       10.41.81.55.49         CLOSEWAIT
03B311EC 10.47.0.229.18047       10.41.81.55.49         CLOSEWAIT
039A8E04 10.47.0.229.52022       161.61.35.250.49       CLOSEWAIT
0365D460 10.47.0.229.12241       10.41.81.55.49         CLOSEWAIT
03B33E78 10.47.0.229.47640       10.41.81.55.49         CLOSEWAIT
0372C128 10.47.0.229.60323       10.41.81.55.49         CLOSEWAIT
03661CD8 10.47.0.229.39923       10.41.81.55.49         CLOSEWAIT
0393C73C 10.47.0.229.41864       10.41.35.250.49        CLOSEWAIT
03829584 10.47.0.229.56673       161.61.35.55.49        CLOSEWAIT
0362AC10 10.47.0.229.31952       10.41.81.55.49         CLOSEWAIT
039BF078 10.47.0.229.22636       10.41.81.55.49         CLOSEWAIT
TCB       Local Address           Foreign Address        (state)
0365CF8C 10.47.0.229.14476       10.41.81.55.49         CLOSEWAIT
039B443C 10.47.0.229.59226       10.41.81.55.49         CLOSEWAIT
0393E794 10.47.0.229.56282       10.41.35.250.49        CLOSEWAIT
03657740 10.47.0.229.25769       10.41.81.55.49         CLOSEWAIT
03B2F6E8 10.47.0.229.19328       10.41.81.55.49         CLOSEWAIT
0373AC88 10.47.0.229.25766       10.41.81.55.49         CLOSEWAIT
039B213C 10.47.0.229.28882       10.41.81.55.49         CLOSEWAIT
039C07AC 10.47.0.229.38201       10.41.81.55.49         CLOSEWAIT
03AD8DD0 10.47.0.229.23002       10.41.35.250.49        CLOSEWAIT
03739048 10.47.0.229.29572       10.41.35.250.49        CLOSEWAIT
039BA464 10.47.0.229.32273       10.41.81.55.49         CLOSEWAIT
03B31E6C 10.47.0.229.32521       10.41.81.55.49         CLOSEWAIT
0365EBE0 10.47.0.229.41319       10.41.81.55.49         CLOSEWAIT
03938804 10.47.0.229.62841       10.41.35.250.49        CLOSEWAIT
039A1AF8 10.47.0.229.12758       10.41.81.55.49         CLOSEWAIT
039B7DE4 10.47.0.229.20921       10.41.81.55.49         CLOSEWAIT
036549F8 10.47.0.229.51903       10.41.81.55.49         CLOSEWAIT
03714CC8 10.47.0.229.45145       10.41.81.55.49         CLOSEWAIT
037425F8 10.47.0.229.56492       10.41.81.55.49         CLOSEWAIT
03B39D74 10.47.0.229.18174       10.41.81.55.49         CLOSEWAIT

High Packet Loss, High Ping and Slow Connection Ov...

Hi There,
I have been a customer with the BT unlimited broadband package for a little under two years and up until recently have had no real issues with the service. This was until around 3/4 weeks ago I noticed that the internet was very slow and certain online games or applications like Netflix would lose all of its quality or stop completely. At first I thought nothing of it and simply reset my BT Home hub router, and sure enough everything was back to normal. However after around 2-3 hours of moderate use (gaming online or watching Netflix) the problem surfaced again.
Now I am lucky if I can get the entire way through a 40 minute TV episode before the quality drops and/or the service requires buffering. I have already contacted BT via the helpline and the service lady ran through the obligatory steps (turn off, wait 5 minutes, reset the home hub etc.) but she failed to understand that although rebooting the home hub does alleviate the problem initially, the symptoms of a slow connection, high packet loss and high ping always return within an hour.
Four the last couple of weeks I have been trying to investigate the problem myself and I have done the following things:
Tested the line using the master socket (no difference)
Opened the ports on my firewall within the home hub (no difference)
Directly wired in the computer instead of relying on the wifi (no difference)
Tested for interference from neighbours wifi using inSSIDider office (it wasn’t, operating on different channels)
Switched every device that requires internet off apart from the PC (no difference)
So with all that in mind I am fairly confident that it is nothing within my house that has caused a significant reduction in internet quality.
Now I have tried my best to display the problem I am having by recording the connection quality for the last 24 hours. The table below represents the condition and quality of the connection after leaving it a period of time without resetting:
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 21:52:14
Downstream:
12.96 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.7 dB / 5.4 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
987297 / 12745
CRC Events (Down/Up):
254 / 15268
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
2437 / 252630
Error Seconds (Local/Remote):
189 / 36430
And here is a result of the ping and packet loss during this time:
Now I immediately reset the home hub after running that test and ran the test again. These are the results I a achieved within 2 minutes of internet connectivity:
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 00:01:05
Downstream:
13.77 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.4 dB / 5.6 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
159 / 12746
CRC Events (Down/Up):
1 / 15573
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
0 / 252639
Error Seconds (Local/Remote):
1 / 36438
Even within the time it has taken to compose this page my internet quality has nose-dived from the previous result above to the following:
Connection Information
Line state:
Connected
Connection time:
0 days, 00:52:31
Downstream:
13.77 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.1 dB / 5.4 dB
Line attenuation (Down/Up):
29.4 dB / 16.4 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
14544 / 12749
CRC Events (Down/Up):
14 / 15584
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
72 / 252647
Error Seconds (Local/Remote):
10 / 36449
What is causing this poor quality in connection and what can be done to rectify the problem?
Thank you for your response in advanced.
Regards,
Richard.

Thank you for you quick reply, I have just moved my hub to the master socket again and re-run the test and I seem to be getting the same results.
ADSL Line Status
Connection Information
Line state:
Connected
Connection time:
0 days, 00:17:47
Downstream:
12.96 Mbps
Upstream:
910 Kbps
ADSL Settings
VPI/VCI:
0/38
Type:
PPPoA
Modulation:
G.992.5 Annex A
Latency type:
Interleaved
Noise margin (Down/Up):
6.0 dB / 5.2 dB
Line attenuation (Down/Up):
28.7 dB / 15.9 dB
Output power (Down/Up):
20.4 dBm / 12.6 dBm
FEC Events (Down/Up):
26417 / 5
CRC Events (Down/Up):
1 / 303
Loss of Framing (Local/Remote):
0 / 0
Loss of Signal (Local/Remote):
0 / 0
Loss of Power (Local/Remote):
0 / 0
HEC Events (Down/Up):
31 / 11
Error Seconds (Local/Remote):
10 / 36522
I have also checked if the bell wire was attached and it is not. My socket is of the new type with the inclusion of an inductor on the faceplate. My ADSL filters and modem cable already have the middle connecting pins removed so I don’t think it is a wiring problem, at least in my apartment anyway. I have also searched for problems with the exchange and they are showing green for my area. (Liverpool Central)
I have just rang the quiet line and I do not appear to have any noise on the line. However, all I have is a cordless phone and I know that is not ideal for determining noise due to the radio frequency interfering with the phone speaker.
Again thank you for you time on this issue.
Regards,
Richard

Transparent FW and pinging to remote device

Hi everyone,
I was reading about transparent FW it says
Unlike a transparent switch, however, the device will not flood frames out interfaces for an unknown MAC address destination. Instead the ASA will respond with an ARP request for a directly connected device. If the destination is remote, the ASA will attempt to ping the remote device.
Question
How ASA will ping the remote device will it ping by static route config on ASA ?
Say we have transparent FW between 2 switches and one side say switch1 has a server is connected to it.
How ASA will ping this server?
Now we can say this server as remote device if it is on different subnet then the ASA interface?
Seems ASA will have mac address of directly connected inetrfaces.
Thanks
Mahesh

Hi,
I actually configured one of my ASA5505 as Transparent last night and tested it abit.
I had NO default route on the ASA5505 and the connections from the host behind the Transparent firewall worked just fine. Though I didnt use any management connection to the ASA other than console cable.
I guess for remote management connections and certain traffic originated by the ASA itself, the default route is needed BUT not for the actual host traffic through the ASA. The host already has a default gateway configured and it will ARP for its MAC address through the Transparent ASA and already knows where to forward the traffic to reach the remote host. ASA just has to determine where to forward the traffic.
I enabled several debugs on the ASA and it would indeed seem that when the ASA still has absoletely no knowledge of MAC address behind its "inside" or "outside" it will at the start use Traceroute.
I will post the debugs shortly.
EDIT: Debugs
L2-FIREWALL(config)# sh debug
debug l2-indication enabled at level 255
debug mac-address-table enabled at level 255
debug arp-inspection enabled at level 255
debug icmp trace enabled at level 255
debug arp enabled at level 1
I first issued a "clear mac-address-table" and after that I initiated ICMP Echo to a remote network.
My IP addresses were
192.168.103.1 Host default gateway - MACaca0.1679.6d1b
192.168.103.2 ASA5505 IP address
192.168.103.3 Host IP address - MAC 1cc1.debe.80c5
192.168.101.1 Remote Host
f1_tf_process_l2_learn:learn indication , cur_ifc inside, new_ifc inside
mac_address: 1cc1.debe.80c5
add_l2fwd_entry: Going to add MAC 1cc1.debe.80c5.
add_l2fwd_entry: Added MAC 1cc1.debe.80c5 into bridge table thru inside.
add_l2fwd_entry: Sending LU to add MAC 1cc1.debe.80c5.
f1_tf_process_l2_miss:MISS indication ip address 165a8c0, Vlan: 1,mac_address aca0.1679.6d1b
MISS IND: Skipping learning for same interface
f1_tf_process_l2_miss:IP address belongs to differentsubnet. Sending ICMP traceroute
icmp_mktracert: Block allocated
ICMP echo request from 192.168.103.2 to 192.168.101.1 ID=4388 seq=0 len=32
f1_tf_process_l2_learn:learn indication , cur_ifc outside, new_ifc outside
mac_address: aca0.1679.6d1b
add_l2fwd_entry: Going to add MAC aca0.1679.6d1b.
add_l2fwd_entry: Added MAC aca0.1679.6d1b into bridge table thru outside.
add_l2fwd_entry: Sending LU to add MAC aca0.1679.6d1b.
ICMP echo reply from 192.168.101.1 to 192.168.103.2 ID=4388 seq=0 len=32
ICMP echo request from inside:192.168.103.3 to outside:192.168.101.1 ID=1 seq=244 len=32
ICMP echo reply from outside:192.168.101.1 to inside:192.168.103.3 ID=1 seq=244 len=32
ICMP echo request from inside:192.168.103.3 to outside:192.168.101.1 ID=1 seq=245 len=32
ICMP echo reply from outside:192.168.101.1 to inside:192.168.103.3 ID=1 seq=245 len=32
ICMP echo request from inside:192.168.103.3 to outside:192.168.101.1 ID=1 seq=246 len=32
ICMP echo reply from outside:192.168.101.1 to inside:192.168.103.3 ID=1 seq=246 len=32
- Jouni

High ping and packet loss.

How do i fix high ping and packet loss? Also when i ping my own ip, it results in 100.0% packet loss.

Please read this whole message before doing anything.
This procedure is a diagnostic test. It’s unlikely to solve your problem. Don’t be disappointed when you find that nothing has changed after you complete it.
The purpose of the test is to determine whether the problem is caused by third-party software that loads automatically at startup or login, by a peripheral device, by a font conflict, or by corruption of the file system or of certain system caches.
Disconnect all wired peripherals except those needed for the test, and remove all aftermarket expansion cards, if applicable. Start up in safe mode and log in to the account with the problem. You must hold down the shift key twice: once when you turn on the computer, and again when you log in.
Note: If FileVault is enabled, or if a firmware password is set, or if the startup volume is a software RAID, you can’t do this. Ask for further instructions.
Safe mode is much slower to start up and run than normal, with limited graphics performance, and some things won’t work at all, including sound output and Wi-Fi on certain models. The next normal startup may also be somewhat slow.
The login screen appears even if you usually login automatically. You must know your login password in order to log in. If you’ve forgotten the password, you will need to reset it before you begin.
Test while in safe mode. Same problem?
After testing, restart as usual (not in safe mode) and verify that you still have the problem. Post the results of the test.

Three devices on network: 100% packet loss for my iMac.

I'm having intermittent bouts of 100% packet-loss pinging my router from my iMac, at the same time my iPod touch and neighbor's Windows laptop are surfing wirelessly from the same router.
Sometimes these bouts resolve spontaneously. Otherwise I need to shut down, wait, and restart my iMac to reconnect. The longer the shut down, the longer I can connect it seems.
The problem started a few days ago, after months of trouble-free performance with the same settings. The computer usually stayed up all the time. I hoped in vain today's OSX 10.5.4 and AirPort firmware updates would fix the problem ...
Post 10pm is the most common problem time, 'tho I'm not sure if that's a function of my iMac's uptime (wireless module is cooking?) or some electronic interference firing up near by. Maybe a virus?
Known potential sources of interference have been around for months/years: my old wireless 'phone is a 900MHz model, the next door neighbor's satellite antenna's been up for months. The dodgy power in this old building is hopefully offset by the APC UPS that powers my Mac.
Do I keep fiddling with the AirPort channels, or do I take my computer back to the shop for (another) warranty repair?
Greg./

No, I'm not letting my neighbor steal my signal. He's subletting off me, and his access to my network (WPA2 encryption) is part of the "deal". He's a bit of a night-owl, and the late night download limit is pretty big, so it works fine all round.
I used his laptop's (and my iPod Touch's) uninterrupted access (while my iMac's floundering in packet-loss purgatory) as a way of "narrowing down" to the prime suspect: the iMac wireless module.
Greg./
ps sorry about the unnecessary alliteration; I had to substitute "purgatory" because the forum software censors "****" (aich, ee, ell, ell).
Message was edited by: gregreedee
Message was edited by: gregreedee

Ping Packet Loss across MPLS TE Tunnels

Hello...Please Help,
I have a Single Area OPSF network running across 4 main routers via GigEth Ckts. The OSPF Network is working correctly. I recently implemented MPLS TE creating two Tunnels - One Explicit Path and One Dynamic Path. Two of the Routers also have a T1 Frame Relay Link over which the Explicit path is configured. It is up and woking but I am experiencing 50-60 percent packet loss when pinging between these PE routers. When I force it to the dynamic tunnel it follows the same FR path and experiences the same packet loss. There is no packet loss anywhere else in the network.
This is a Lab environment w/three LAN's Two 7206VXR & Two 3745 routers and Three 3550 Switches - one per LAN
Suggestions?

Thank You for your response. The problem may not be an MPLS TE problem.
But would my "path-option" and "priority" being set the same for the Dynamic and Explicit Tunnels cause one tunnel to come up and the other go down and cease to signal. Right now I have one or the other working when viewed w/the "show mpls traffic-eng tunnels" command. If I take one down the other works.
The IPs are 10.1.101.1 & 2/30 respectively for the FR Link. That was a Typo...I have corrected it.
The FR interfaces are not SubInt's as the Serial Interface holds the IP address. These are strictly Point to Point but I have the "IP OSPF Network Broadcast" command set and OSPF going across them.
I have SubInt's set on the Gi0/3 Interface.
Gi0/3.1 & 3.10 for VLAN's 1 & 10
There are not any drops when pinging from Within the routers "Interface to Interface".
But when I ping the LAN Node to Node or from within the Router "if" I do not specify an "interface source" I receive the drops.
The result is the same from either side of the Network on both of the 7206 Routers.
Thanks, Kevin

Flood ping of loopback device gives 20% packet loss!

Similar Messages

Maybe you are looking for