Having really high pings, packet loss and been on ...

Hi. I've been on to BT 4-5 times in the last few weeks. Everytime its the same thing I do all their checks and run the speed test. Its the same thing over and over. When i try to explain to them the problems i,m having they said your speed is within the acceptable range. I,m at a loss with dealing with BT. The customer server is terrible.
Basically the problems i,m having is really high pings. Even doing the BTwholesale speedtest my pings was usally in the 30ms range now they are 70 on average now. I play alot of online games. And Everything is unplayable. I know there is definitely something wrong. Either with the routing or some of the nodes on bt.
Today I was trying to play Diablo 3, the lag spikes was huge every 2-3 seconds jumping to 1-2k ms latency. I ran some winMTR tests and i,m having alot of packet loss. I tried to explain that to BT on the phone. But its like the dont have a clue what i,m talking about or wont attempt to help me with the issue. All game companies usally tell me ISPs are always willing to help with these problems. But BT seem to refuse to help with latency ping issues, just your speed is fine etc .
I,ve also noticed people in the BT forums saying something about G.INP and people needing HH5 Type B. Can someone explain to me what this is or if its something happening to my cabinate. I,m using the BT HH5 type A. From what i see the about the G.INP sounds like the issues i,m currently facing.
Can some Mod please help me. I,m really losing hope with BT.

Hi Guys.
Still facing these issues. Is BT not going to do anything about it? Here is a WinMTR test to a game server i,m playing.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| BTHUB5 - 0 | 1132 | 1132 | 0 | 0 | 10 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| 217.41.216.109 - 7 | 901 | 843 | 18 | 30 | 394 | 20 |
| 213.120.158.234 - 7 | 909 | 853 | 21 | 25 | 51 | 23 |
| 31.55.165.151 - 7 | 905 | 848 | 20 | 25 | 51 | 23 |
| 31.55.165.109 - 7 | 905 | 848 | 21 | 25 | 49 | 23 |
| 109.159.250.180 - 7 | 897 | 838 | 20 | 25 | 63 | 23 |
| core1-te0-13-0-16.ilford.ukcore.bt.net - 7 | 913 | 858 | 27 | 34 | 57 | 33 |
| peer6-0-9-0-22.telehouse.ukcore.bt.net - 6 | 917 | 863 | 27 | 32 | 56 | 32 |
| 166-49-211-240.eu.bt.net - 7 | 913 | 858 | 28 | 32 | 59 | 28 |
| 213.248.82.249 - 7 | 909 | 853 | 0 | 33 | 93 | 29 |
| ldn-bb2-link.telia.net - 7 | 909 | 853 | 28 | 36 | 127 | 70 |
| adm-bb4-link.telia.net - 7 | 909 | 853 | 32 | 37 | 76 | 34 |
| adm-b4-link.telia.net - 6 | 917 | 863 | 34 | 38 | 65 | 35 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 227 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|
217.41.216.109 seems to be an issue with this. Getting packet loss of 7% and the the ping shoots up to almost 400 while the average is around 30.
I,ve tried everything BT have told me, i've phoned loads and loads of times to seek help. I dont know what else to do. Pings and latency is horrible. And i dont just mean little lag. Every online game is unplayable. Webpage loading slowing or broken images .

Similar Messages

Tons of packet loss and Verizon techs say its fine

As you can see from the below test ran from dslreports.com, I'm having a lot of packet loss issues. This has been going on for nearly two weeks now and tech support has been more of an annoyance than a help upto this point. I've talked to tech support at least 5 times only to be told my line test comes back fine, its normal, reset your modem, delete your cookies, is your pc old, etc. I've even had them vpn itno my system and run pings and they see the packet loss and all the issues I'm having first hand and still say it isn't a big deal. On more than one occasion I've had my modem data light just flashing and had to reset the modem and they suggest I just buy a new modem. Seriously, is this how bad tech support has gotten?
I've shown them test after test after test and the all come back pretty much the same... The thing is its been perfect for years and suddenly this and its like tech support wants to sweep it under the rug or something. I've had it suggested to me the packet loss and high pings when I'm not getting the packet loss is due to my pool being over populated. Like I'm ow getting ping averages of 250-300 instead of 30-40s, again when its not all timing out.
I've posted over on the dslreports forums asking about this as well as in the Verizon specific forums to the techs all with 0 replies from anything and was told to come here and see if anyone would be able to help.
I really not bother with the hassle of switching isps as ive been a loyal Verizon dsl customer for well over 5 years but at this point just knowing how bad tech support is alone might make me want to.
Can anyone offer any insight on what else to do or help on this possibly?
Thanks.
Test Loss Min
Latency Avg
Latency Max
Latency Pass
Fail Simple ping loss check
10secs of 40byte packets 2 per second 5% loss 137ms 141ms 148ms
warn low bandwidth stream
10secs of 56k/bit ping stream 512byte packets 6% loss 142ms 147ms 154ms
warn medium bandwidth stream
10secs of 128k/bit ping stream 512byte packets 2% loss 140ms 147ms 173ms
pass your first hop ping
stream of 40byte pings to 130.81.44.101 4% loss 118ms You are 19ms
to your first hop
pass Ping plot:
Ping plot:
From East Coast - USA to YOU Hop Host LOSS Rcv Sent Best Avg Worst 0 ae-2.bb-b.slr.lxa.us.oneandone.net 0% 60 60 0.46 2.29 59.98 1 te-2-1.bb-b.ms.mkc.us.oneandone.net 0% 60 60 0.92 1.89 36.10 2 64.209.105.233 0% 60 60 13.97 41.38 948.69 3 0.xe-8-2-0.BR3.CHI13.ALTER.NET 0% 60 60 26.13 30.80 80.28 4 0.ae3.CHI01-BB-RTR1.verizon-gni.NET 0% 60 60 26.49 27.84 88.62 5 P15-3.RONKVA-LCR-01.verizon-gni.net 0% 60 60 54.25 55.01 56.32 6 P0-0.RONKVA-RONKVALK-ERXG02.verizon-gni.net 0% 60 60 116.80 121.05 130.35 7 pool-71-171-24-94.nwrknj.east.verizon.net 14% 52 60 142.49 147.61 169.10 (fail) From West Coast - USA to YOU Hop Host LOSS Rcv Sent Best Avg Worst 0 unknown.Level3.net 2% 59 60 0.64 16.67 150.86 1 ae-4-99.edge1.SanJose3.Level3.net 4% 58 60 1.15 5.12 59.35 2 4.68.63.146 0% 60 60 1.25 3.31 55.27 3 0.ae3.XL3.SJC7.ALTER.NET 0% 60 60 1.25 1.68 9.80 4 0.ge-6-3-0.XT1.DCA6.ALTER.NET 0% 60 60 75.58 77.85 108.89 5 0.so-4-0-0.RES-BB-RTR1.verizon-gni.net 0% 60 60 75.52 80.78 136.25 6 P15-3.RONKVA-LCR-01.verizon-gni.net 0% 60 60 90.25 91.97 94.08 7 P0-0.RONKVA-RONKVALK-ERXG02.verizon-gni.net 2% 59 60 154.03 159.68 164.42 8 pool-71-171-24-94.nwrknj.east.verizon.net 4% 58 60 175.74 183.27 187.00 (fail)

As you can see from the below test ran from dslreports.com, I'm having a lot of packet loss issues. This has been going on for nearly two weeks now and tech support has been more of an annoyance than a help upto this point. I've talked to tech support at least 5 times only to be told my line test comes back fine, its normal, reset your modem, delete your cookies, is your pc old, etc. I've even had them vpn itno my system and run pings and they see the packet loss and all the issues I'm having first hand and still say it isn't a big deal. On more than one occasion I've had my modem data light just flashing and had to reset the modem and they suggest I just buy a new modem. Seriously, is this how bad tech support has gotten?
I've shown them test after test after test and the all come back pretty much the same... The thing is its been perfect for years and suddenly this and its like tech support wants to sweep it under the rug or something. I've had it suggested to me the packet loss and high pings when I'm not getting the packet loss is due to my pool being over populated. Like I'm ow getting ping averages of 250-300 instead of 30-40s, again when its not all timing out.
I've posted over on the dslreports forums asking about this as well as in the Verizon specific forums to the techs all with 0 replies from anything and was told to come here and see if anyone would be able to help.
I really not bother with the hassle of switching isps as ive been a loyal Verizon dsl customer for well over 5 years but at this point just knowing how bad tech support is alone might make me want to.
Can anyone offer any insight on what else to do or help on this possibly?
Thanks.
Test Loss Min
Latency Avg
Latency Max
Latency Pass
Fail Simple ping loss check
10secs of 40byte packets 2 per second 5% loss 137ms 141ms 148ms
warn low bandwidth stream
10secs of 56k/bit ping stream 512byte packets 6% loss 142ms 147ms 154ms
warn medium bandwidth stream
10secs of 128k/bit ping stream 512byte packets 2% loss 140ms 147ms 173ms
pass your first hop ping
stream of 40byte pings to 130.81.44.101 4% loss 118ms You are 19ms
to your first hop
pass Ping plot:
Ping plot:
From East Coast - USA to YOU Hop Host LOSS Rcv Sent Best Avg Worst 0 ae-2.bb-b.slr.lxa.us.oneandone.net 0% 60 60 0.46 2.29 59.98 1 te-2-1.bb-b.ms.mkc.us.oneandone.net 0% 60 60 0.92 1.89 36.10 2 64.209.105.233 0% 60 60 13.97 41.38 948.69 3 0.xe-8-2-0.BR3.CHI13.ALTER.NET 0% 60 60 26.13 30.80 80.28 4 0.ae3.CHI01-BB-RTR1.verizon-gni.NET 0% 60 60 26.49 27.84 88.62 5 P15-3.RONKVA-LCR-01.verizon-gni.net 0% 60 60 54.25 55.01 56.32 6 P0-0.RONKVA-RONKVALK-ERXG02.verizon-gni.net 0% 60 60 116.80 121.05 130.35 7 pool-71-171-24-94.nwrknj.east.verizon.net 14% 52 60 142.49 147.61 169.10 (fail) From West Coast - USA to YOU Hop Host LOSS Rcv Sent Best Avg Worst 0 unknown.Level3.net 2% 59 60 0.64 16.67 150.86 1 ae-4-99.edge1.SanJose3.Level3.net 4% 58 60 1.15 5.12 59.35 2 4.68.63.146 0% 60 60 1.25 3.31 55.27 3 0.ae3.XL3.SJC7.ALTER.NET 0% 60 60 1.25 1.68 9.80 4 0.ge-6-3-0.XT1.DCA6.ALTER.NET 0% 60 60 75.58 77.85 108.89 5 0.so-4-0-0.RES-BB-RTR1.verizon-gni.net 0% 60 60 75.52 80.78 136.25 6 P15-3.RONKVA-LCR-01.verizon-gni.net 0% 60 60 90.25 91.97 94.08 7 P0-0.RONKVA-RONKVALK-ERXG02.verizon-gni.net 2% 59 60 154.03 159.68 164.42 8 pool-71-171-24-94.nwrknj.east.verizon.net 4% 58 60 175.74 183.27 187.00 (fail)

Packet loss and eventual shutdown of port 80 on RV180

I have been using my RV180 router for about a year now. I have had very little issues with it overall. I have seperate wireless access points connected and use those for my wireless devices.
Recently, I started getting very odd connection problems it started as packet loss and then turned into connection loss. The odd part is that it only effects port 80 or the secured port, 880, if I remember correctly. Thats right, everything else on the network works fine. However, I can not access the internet or the RV180 router via it's ip address to check the status. VOIP, other lan networking, gaming, and bitcoin mining is completely uneffected. Direct connection to the modem works without any problems.
I have tried updating the router firmware but no help.
Each time I have this issue the problem is cured simply by unplugging the router and plugging it back in. Nothing else works because I can not log into the router. This problem comes along once a week or so. I have also tried enabling the logs but I get absolutly nothing when I reset the router and log back in. I have had similar problems with routers in the past becoming "bent" after about a year of use and requiring a replacement. I sort of thought that this wouldnt be the case with the Cisco because it is a good brand and came with a five year warranty. I have also scanned every PC on the network for viruses and malware but nothing was located. The remainder of the devices are IP cameras and such.
Can anyone think of anything that could be causing this?

So I was able to get the logs tonight by repeatedly pinging the router and it would start letting me get traffic in again.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.390000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.770000] __ratelimit: 111 callbacks suppressed
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.770000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.890000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.890000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.930000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81101.930000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.070000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.230000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:07 2013(GMT-0500) [rv180][Kernel][KERNEL] [81102.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] __ratelimit: 102 callbacks suppressed
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.020000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.270000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.420000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.430000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.520000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:12 2013(GMT-0500) [rv180][Kernel][KERNEL] [81107.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.120000] __ratelimit: 100 callbacks suppressed
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.120000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.310000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.310000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.320000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.500000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:17 2013(GMT-0500) [rv180][Kernel][KERNEL] [81112.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] __ratelimit: 107 callbacks suppressed
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:22 2013(GMT-0500) [rv180][Kernel][KERNEL] [81117.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] __ratelimit: 93 callbacks suppressed
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:27 2013(GMT-0500) [rv180][Kernel][KERNEL] [81122.550000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.560000] __ratelimit: 101 callbacks suppressed
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.600000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.690000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.750000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.790000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.830000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.830000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:32 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.840000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:33 2013(GMT-0500) [rv180][Kernel][KERNEL] [81127.840000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] __ratelimit: 110 callbacks suppressed
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.140000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.260000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.300000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:38 2013(GMT-0500) [rv180][Kernel][KERNEL] [81133.560000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.290000] __ratelimit: 84 callbacks suppressed
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.290000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:43 2013(GMT-0500) [rv180][Kernel][KERNEL] [81138.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81143.710000] __ratelimit: 126 callbacks suppressed
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81143.710000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:49 2013(GMT-0500) [rv180][Kernel][KERNEL] [81144.570000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.580000] __ratelimit: 67 callbacks suppressed
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.580000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.720000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81149.740000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.280000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.330000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.440000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:54 2013(GMT-0500) [rv180][Kernel][KERNEL] [81150.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81154.870000] __ratelimit: 85 callbacks suppressed
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81154.870000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:59 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.030000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.210000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.280000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:00 2013(GMT-0500) [rv180][Kernel][KERNEL] [81155.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] __ratelimit: 114 callbacks suppressed
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.100000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.270000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.330000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.340000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.350000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.350000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:04:05 2013(GMT-0500) [rv180][Kernel][KERNEL] [81160.540000] nf_conntrack: table full, dropping packet.
Wed Dec 4 20:03:02 2013(GMT-0500) [rv180][Kernel][KERNEL] [81097.390000] nf_conntrack: table full, dropping packet.
Sat Jan 01 00:00:13 2011 (GMT +0000): [RV180] [IKE] INFO: IKE started

Airport Extreme N - Optonline - packet loss and resets

Setup:
I have been having the below issue since moving to an area in New Jersey with Optonline (CableVision) cable internet access. The cable modem is a WebStar with connection to a Airport Extreme "N" via ethernet to WAN port on Airport Extreme N.
The issue was not present when I was with Comcast using an Airport Extreme G, it began when using Optline with the Airport Extreme G and continues with the Airport Extreme N. Airport is configured to b/g/n compatible, DHCP, WPA/WPA2 security, various channels used, no interference noted in the wireless spectrum using several software tools.
Issue:
Webpage load speeds are very slow until the Airport Extreme base is restarted, Optonline has confimed a strong signal to the cable modem and when I plug directly into my iBook/iMac from the modem using ethernet they test for packet loss and it is 0-2%. I have confirmed that directly plugging in removes the issue.
When plugged into the Airport Extreme (either the G or N version) packet loss has approcahed 90% and the only way to load a page is to continually hit "reload" to get a slow eventual load. Once a restart of the Airport Extreme is done the issue is resolved for hours/days until it begins again, requiring another restart.
Any help would be appreciated!
iMac G5 2.1GHz 20" Mac OS X (10.4.9) iBook G4 1.33 12"
iMac G5 2.1GHz 20" Mac OS X (10.4.9) iBook G4 1.33 12"

My n Airport doesn't work well on OOL either. Back to using round AEBS g.
The n router when I click a webpage link, has a delay of 5-10 seconds before Safari goes to the link. Using my g Airport I click a link and Safari instantly loads the page.
If I do an OOL speed test, the n router is a bit slower than the g router, but speed tests fine bottomline. But the delay issue has made it impossible for me to work, so I switched back to my UFO AEBS g Airport.
Whatever the imcompatability with OOL is I hope will be rectified when I see a release of an Apple n Airport update. In the mean time, g for me.

E4200 - terrible G-only speed, packet loss and throughput variation

Got this router today, was disappointed to see it fail simple performance tests using wireless G on out-of-the-box firmware 1.0.0.1 and after upgrading to 1.0.0.2.
I tried mixed/G/G+B modes, optimal positioning of the router, manual channels 1,5,6,11 and auto channel, security disabled and 5Ghz disabled, rebooting and power cycling - no difference. I also went on to try a total of 3 different laptops again with no difference (they have Atheros, Realtek and Intel chipsets, all 802.11g, no 802.11n)
Uplink and downlink speeds from WLAN to LAN are consistenly poor (tested using Jperf and Qcheck), with uplink to the router being consistently worse. For example, at my favoured location a few metres from the router with very good signal strength, an Orange Livebox 1.2 (or 'Livebox Mini', which is a standard ISP provided router here in the UK) gives rock solid 22Mbps up and down, a humble Sagem 2504N gives rock solid 21Mbps up and down, the E4200 gives about 11Mbps up and 13Mbps down, even though signal strength at this location as reported by Inssider is in fact highest from the E4200. Wherever I try it, like for like, the E4200 throughput underperforms massively for any wireless router let alone a top-of-the-range model. Even right next to the router, I only seem to get an average of about 18Mbps down, not the full 22Mbps I would expect from 802.11g.
I also see great throughput variation on these tests. So, I ran ping tests from the cmd line (from wireless to a wired computer on the E4200), and sure enough there is packet loss. There is no packet loss on any of my other routers. I also put the E4200 into bridge mode and used it as a wireless access point to another router, again there was packet loss and throughput variation. Coming here to post, I saw some other threads about packet loss, I can confirm I am another user seeing the same thing.
Comments/comparisons/ideas for fixes welcome, but I'm sorry to say, this router is obviously going back.

Thanks, but Cisco Connect did not help.
I am using this router as a wireless access point, without connecting a modem to the WAN port. Cisco Connect did not like this one bit and would not proceed because it could not detect an Internet Connection. It then tried to send a report of why installation had failed over the internet
Not that I should have to use Cisco Connect to avoid packet loss and extremely poor speeds anyway! Nothing I have seen in the Linksys documentation or during setup suggests it will alter performance so I don't know how it would help anyway (the router page only warned that configuring manually meant my network could be left unsecured).
I don't know what the speed tests are through Cisco Connect, because I cannot install it and I can't find a user guide to the software, not even on the installation disc. I don't see how these speed tests will change anything though, how can they give meaningful, different results of a simple TCP throughput test, as I performed using Jperf/Iperf and IxChariot.

CRS-1 ping packet loss

Hi everyone,
CRS1 IOS-XR 3.8 when i try to ping packet option and got packet loss as below and don't sure that XR limit for ping or not?
RP/0/RP0/CPU0:#ping 10.0.0.1 size 3000 count 1000 (ping to outside switch 3750)
Mon Oct 8 10:12:34.582 THAI
Type escape sequence to abort.
Sending 1000, 3000-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
if i user size 1500 don't have packet losss.
Can anyone explanation to me?
Thanks alot.
Kodos.

Hello,
Above result is PING from CRS-1 to another switch, we try to vary packet size and found that if its size greather than 2800 then we always get 4 packets loss from 1000.
Can you please advice?
Thanks,
Rojarek

Tool like PathPing that can pinpoint packet loss and can be configured to run for 24 hours

Does anybody know if there is a simple tool like PathPing that can pinpoint packet loss and can be configured to run for eg. 24 hours. I need it for windows XP preferable a cmd line tool like PathPing. Thanks Simon.

Thanks for your answer. I already downloaded winmtr.
Regards
Simon
From:
namohamm
To:
Simon Vyrdal/Sweden/Contr/IBM@IBMSE
Date:
2010-12-30 08:29
Subject:
New message: "Tool like PathPing that can pinpoint
packet loss and can be configured to run for 24 hours"
simonvyrdal,
A new message was posted in the Discussion thread "Tool like PathPing that
can pinpoint packet loss and can be configured to run for 24 hours":
https://supportforums.cisco.com/message/3258861#3258861
Author : Nael Mohammad
Profile : https://supportforums.cisco.com/people/namohamm
Message:

100% packet loss and I can't play Online games

Recently I just got cable installed and the Internet works and it connects to my Xbox one but I have 100% packet loss and I can't play any online games or apps on my phone. Can someone please help me out as I have waited about 2 weeks to get it working!

hi AireVuqe101
I'm referring your post to our Social Media Tech Team for some further assistance.
You may not receive any contact from them until Monday, so if you need further assistance in the meanwhile, we do have a 24 hour Technical Support team who can be contacted by either calling 133933 or via Live Chat http://tel.st/gq6m
Regards

Packet loss and high ping

I have been having intermittent packet loss issues for the greater part of this month, Today has made it so I can barely stay connected to the internet. I have gone through customer service a couple times, multiple router resets, wired vs. unwired, nothing changes. Here's some images of the problem from this morning. Just wondering if there was anything I could do on my end to fix this. Modem model is SB6141.

Hi bentheren,
Thanks for posting, have you tried setting up port forwarding to see if this makes any difference?
Cheers
Neil
BTCare Community Mod
If we have asked you to email us with your details, please make sure you are logged in to the forum, otherwise you will not be able to see our ‘Contact Us’ link within our profiles.
We are sorry but we are unable to deal with service/account queries via the private message(PM) function so please don't PM your account info, we need to deal with this via our email account :-)
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

Traffic to TDC DK suffers packet loss and high lat...

E.g. ing.dk (a Danish newspaper):
PING ing.dk (80.63.11.110) 56(84) bytes of data.
64 bytes from 80.63.11.110: icmp_req=2 ttl=52 time=124 ms
64 bytes from 80.63.11.110: icmp_req=41 ttl=52 time=120 ms
^C
--- ing.dk ping statistics ---
41 packets transmitted, 30 received, 26% packet loss, time 40040ms
rtt min/avg/max/mdev = 48.048/97.554/124.198/25.728 ms
The traceroute indicates that it is probably the peering link which suffers the problem:
traceroute to ing.dk (80.63.11.110), 32 hops max, 72 byte packets
1 217.32.142.7 13.212 ms 13.170 ms 13.245 ms
2 217.32.142.30 13.684 ms 13.553 ms 13.989 ms
3 213.120.163.14 13.645 ms 13.576 ms 13.630 ms
4 217.32.27.62 13.666 ms 13.023 ms 13.139 ms
5 217.32.27.182 13.919 ms 13.298 ms 13.136 ms
6 109.159.250.236 13.178 ms 13.587 ms 13.490 ms
7 109.159.250.145 27.855 ms 27.445 ms 27.764 ms
8 109.159.254.110 <acc1-10GigE-0-5-0-7.l-far.21cn-ipp.bt.net> 24.623 ms 24.229 ms 24.320 ms
9 * * 195.66.224.64 <xe-7-1-0-0.ldn4nqp1.uk.ip.tdc.net> 99.000 ms
10 83.88.12.144 <xe-4-0-0.ronnqu1.dk.ip.tdc.net> 78.979 ms 111.297 ms 88.724 ms
11 * 62.243.150.42 <cpe.ge-0-2-0-103.ronnqu1.customer.tele.dk> 125.077 ms 118.138 ms
12 80.63.11.110 82.337 ms 45.478 ms *
Please let me know if I can be of assistance. I can provide traceroutes in the opposite direction if that helps.

you could try live chat http://bt.custhelp.com/app/contact/c/2902/?s_intcid=con_intban_sanda_contact_us_chat_from_forums
we are all customers like you we have no access to check peering or any other function of BT we can only give suggestions an asi I posted I can see no problem are you connecting to your home hub by ethernet cable or wireless ? I also assume you are a BT broadband customer
If you want to say thanks for a helpful answer,please click on the Ratings star on the left-hand side If the reply answers your question then please mark as ’Mark as Accepted Solution’

Wrt310n packet loss and dhcp failure?

I purchased a wrt310n to replace a netgear POS (which was a temp after my wrt54g died) and I'm having issues. The netgear is slow and temporarily freezes every once in a while. I put the wrt310n in and it worked flawlessly... for about a week. Now I'm getting packet loss between 10% and 20%. Also, after leaving the router running for a couple days (upside down, because it seemed to be freezing when it got hot) it would work for 5-10 minutes and then freeze. Power cycle the thing and... repeat.
I'm only using WEP, the machines have 802.11g cards, I've changed the network to 10.4.2.x (only the private side) and left almost everything else stock. The other things that have been changed are the admin password and logging has been enabled. My ISP is comcast cable. Suggestions? More info required? Anyone know how long 'til DD-WRT will work on these things?
ps-just so my skillset is known, i'm a sysadmin for a very large tech company and have been doing this type of role for over 8 years... that puts me slightly above the average home user... i think...
pps-mixed network of Linux and Windows machines
Message Edited by junk on 01-23-2008 06:47 PM

Nothing yet. I've switched back to my Netgear, for the time being. I'm hoping Linksys actually reads these forums and has a firmware update coming out soon. The Netgear works great until you hit something with a lot of jpgs (like myspace) and then it chokes for a couple minutes. I can deal with that until the first firmware update shows. Hopefully it's soon, since I hate having to box things up and send them back. I've read a few other posts about people having problems and they suggest doing a factory reset. I always change my network over to a 10.x.x.x subnet because I like to avoid common RFC1918 address spaces (geek/hacker issues). Perhaps it doesn't like dealing with class A address space...

Extremely high ping times ( 3000ms) and unusable ...

Hi all,
I am currently at my girlfriends house, trying to do some work but am experiencing absolutely dreadful internet connectivity.
I have just setup a small *nix box plugged directly into the HH4's gigabit ethernet port purely to monitor this abysmal connectivity. Due to the super high latency and low bandwidth for upload / downloads our internet is virtually unusable.
Here are a couple of excerpts from this mornings logged data.
Firstly latency of 4129.204 ms!!!
23/06/15 : 09:09
./speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from BT (86.165.237.95)...
Selecting best server based on latency...
Hosted by Spectrum Internet (Cardiff) [90.75 km]: 4129.204 ms
Testing download speed........................................
Download: 0.10 Mbit/s
Testing upload speed..................................................
Upload: 0.10 Mbit/s
Secondly ping test to bbc.co.uk again showing very high and varied latency. Avg 1629.844ms high 2361.604ms
PING bbc.co.uk (212.58.244.18) 56(84) bytes of data.
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=1 ttl=50 time=653 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=2 ttl=50 time=730 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=3 ttl=50 time=1188 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=4 ttl=50 time=1529 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=5 ttl=50 time=1464 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=6 ttl=50 time=600 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=7 ttl=50 time=153 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=8 ttl=50 time=491 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=9 ttl=50 time=148 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=10 ttl=50 time=870 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=11 ttl=50 time=1163 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=12 ttl=50 time=1202 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=13 ttl=50 time=1192 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=14 ttl=50 time=1209 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=15 ttl=50 time=1193 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=16 ttl=50 time=644 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=17 ttl=50 time=139 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=18 ttl=50 time=96.6 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=19 ttl=50 time=158 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=20 ttl=50 time=510 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=21 ttl=50 time=653 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=22 ttl=50 time=613 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=23 ttl=50 time=827 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=24 ttl=50 time=829 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=25 ttl=50 time=922 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=26 ttl=50 time=124 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=27 ttl=50 time=94.0 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=28 ttl=50 time=90.9 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=29 ttl=50 time=419 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=30 ttl=50 time=364 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=31 ttl=50 time=358 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=32 ttl=50 time=361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=33 ttl=50 time=402 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=34 ttl=50 time=382 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=35 ttl=50 time=427 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=36 ttl=50 time=409 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=37 ttl=50 time=443 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=38 ttl=50 time=566 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=39 ttl=50 time=651 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=40 ttl=50 time=580 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=41 ttl=50 time=205 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=42 ttl=50 time=361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=43 ttl=50 time=372 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=44 ttl=50 time=386 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=45 ttl=50 time=360 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=46 ttl=50 time=381 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=47 ttl=50 time=419 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=48 ttl=50 time=430 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=49 ttl=50 time=408 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=50 ttl=50 time=409 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=51 ttl=50 time=492 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=52 ttl=50 time=709 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=53 ttl=50 time=817 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=54 ttl=50 time=1073 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=55 ttl=50 time=1373 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=56 ttl=50 time=1197 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=57 ttl=50 time=1406 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=58 ttl=50 time=1565 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=59 ttl=50 time=1714 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=60 ttl=50 time=1835 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=61 ttl=50 time=2018 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=62 ttl=50 time=2151 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=63 ttl=50 time=2237 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=64 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=65 ttl=50 time=2295 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=66 ttl=50 time=2300 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=67 ttl=50 time=2311 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=68 ttl=50 time=2329 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=69 ttl=50 time=2352 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=70 ttl=50 time=2323 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=71 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=72 ttl=50 time=2236 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=73 ttl=50 time=2257 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=74 ttl=50 time=2224 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=75 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=76 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=77 ttl=50 time=2247 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=78 ttl=50 time=2258 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=79 ttl=50 time=2237 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=80 ttl=50 time=2251 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=81 ttl=50 time=2341 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=82 ttl=50 time=2330 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=83 ttl=50 time=2257 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=84 ttl=50 time=2319 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=85 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=86 ttl=50 time=2278 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=87 ttl=50 time=2361 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=88 ttl=50 time=2341 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=89 ttl=50 time=2306 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=90 ttl=50 time=2358 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=91 ttl=50 time=2328 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=92 ttl=50 time=2252 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=93 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=94 ttl=50 time=2248 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=95 ttl=50 time=2302 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=96 ttl=50 time=2322 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=97 ttl=50 time=2281 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=98 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=99 ttl=50 time=2295 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=100 ttl=50 time=2277 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=101 ttl=50 time=2244 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=102 ttl=50 time=2256 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=103 ttl=50 time=2253 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=104 ttl=50 time=2244 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=105 ttl=50 time=2252 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=106 ttl=50 time=2291 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=107 ttl=50 time=2245 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=108 ttl=50 time=2309 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=109 ttl=50 time=2299 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=110 ttl=50 time=2313 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=111 ttl=50 time=2300 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=112 ttl=50 time=2286 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=113 ttl=50 time=2254 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=114 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=115 ttl=50 time=2242 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=116 ttl=50 time=2246 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=117 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=118 ttl=50 time=2251 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=119 ttl=50 time=2253 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=120 ttl=50 time=2219 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=121 ttl=50 time=2210 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=122 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=123 ttl=50 time=2261 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=124 ttl=50 time=2228 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=125 ttl=50 time=2274 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=126 ttl=50 time=2265 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=127 ttl=50 time=2255 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=128 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=129 ttl=50 time=2248 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=130 ttl=50 time=2274 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=131 ttl=50 time=2282 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=132 ttl=50 time=2283 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=133 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=134 ttl=50 time=2270 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=135 ttl=50 time=2273 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=136 ttl=50 time=2192 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=137 ttl=50 time=2304 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=138 ttl=50 time=2296 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=139 ttl=50 time=2284 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=140 ttl=50 time=2270 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=141 ttl=50 time=2272 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=142 ttl=50 time=2263 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=143 ttl=50 time=2305 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=144 ttl=50 time=2283 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=145 ttl=50 time=2250 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=146 ttl=50 time=2266 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=147 ttl=50 time=2269 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=148 ttl=50 time=2247 ms
64 bytes from fmt-vip72.telhc.bbc.co.uk (212.58.244.18): icmp_seq=149 ttl=50 time=2267 ms
^C
--- bbc.co.uk ping statistics ---
151 packets transmitted, 149 received, 1% packet loss, time 150279ms
rtt min/avg/max/mdev = 90.912/1629.844/2361.604/830.792 ms, pipe 3

Anyone able to advise what to do about this problem?

Bouts of packet loss and complete loss of connection

Ok forum, I give up! I need your help.
I have an E1200 and am time out and packet loss issues. The internet connection is fine for 30 seconds to five minuets and then everything times out for 15-20 seconds. Although it’s only a minor incontinence to web browsing, it makes playing games and watching videos a nightmare. “Lost connection to server error.” and the like…
This is what I have done to remedy the problem.
I upgraded to a new router, the e1200 I am currently using, from my Tenda 10/100 N. The problems where the same that I am experience currently and the reason I bought it in the firs place.
When I directly connect to the cable modem, I have no issues and everything is fine.
I have run a trace route and the second hop, (the router to the modem) is the choke point.
I have cloned the MAC address
I have updated the firmware and hard reset
I have throttled my MTU to automatic, 1500, and 1472. None making any difference.
I have disabled NAT and all that does is kill my internet connection
I have disabled all firewalls router and windows, no change.
I replaced the physical wire from the router to the modem.
I have disconnected all devices except one computer, and no difference.
I ran a DNS trace and I have… non routable local internet address 192.168.1.1
DNS-cac-lb-01.rr.com and DNS-cac-lb-02.rr.com
I am using windows 7 and my ISP is time Warner so-cal. Help me obiwan, you’re my only hope.

Sorry friend. I have not had the gaul to load the 1.0 firmware. I am 99% sure I have the 2.0 hardware. I did however unplug my modem for an hour and then try and reconnect. The result was a lossless environment for fifteen to twenty minuets (a long time for me.). But, I am right back still having the same problem. A friend gave me a new netgear router, I am going to try that and I am going to go to Timewarner and have them replace my modem just to make sure there is nothing wrong with the surfboard. I will report back with my findings.

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

Need Help with Packet Loss and routing Loop perhaps???

Hi,
I am running into a very odd situation. One of our highly critical systems (172.18.1.2/16) is losing connection intermittently for brief periods of time (1minute, 3 minute, 50 seconds and so on).
I have gathered some information that I would like to share with you guys:
The switch is a 3560 (Show version is in ShowVersion.txt)
default gateway is 172.18.10.254/16 (virtual IP in an HSRP , packet capture is done on the active node)
I have noticed that pings to one of the default gateways drop infrequently (more frequently from machines on 172.18.0.0/16) segment.
total number of machines on 172.18.0.0/16 do not exceed 200
I have captured packets on Interface Vlan1 and I found something very weird, perhaps pointing to a routing loop??? (see capture.png) The ICMP request comes and hits the 172.18.10.254 with TTL of 128 TWICE! then packet capture shows that same packet with TTL decremented by one TWICE! again and again until it reaches TTL of 1 and then it responds with a reply.
At times it completely ignores the requests and causes a request timed out.
I am confused and need help in right direction. I really appreciate it.
can you also confirm if the multiple packets mean routing loop somewhere?
Thanks

Could you post a copy of your HRSP config and the results of a #show standby?
Thanks

Having really high pings, packet loss and been on ...

Similar Messages

Maybe you are looking for