• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Proving to an ISP you are losing packets?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

TechWizard

Member
Joined
Nov 16, 2004
I have a situation that is on going with an ISP. Right now I have Wireshark set up and configure to show me "tcp.analysis.lost_segment". Which to my understanding is essentially lost packets. My reasoning for doing so is I have an issue on going with this ISP... we had slow speeds for the last month since we moved into a new location and just yesterday we were able to rectify having inconsistent, slow speeds. Before we were bottoming out as low as 560kbps. YES, KBPS! However after resolving that issue, I still notice there is a lot of "packet jitter" when the system is under load. Typically when I run speed tests I see this consistently.

The Internet is -usable- for the time being, but there are still moments when files take a long time to download, web pages refuse to load, and overall general connectivity is not what it should be. They do a straight fiber test between our location and theirs (about 3.5 miles) and they claim the connection is 100% solid, stable, and that we are receiving 95/95 mpbs for download and up. This isn't the case though when trying to access the actual outside Internet. They won't escalate me to engineers and simply aren't giving me the time and day anymore since I've called them everyday for two weeks now.

I have been fighting with this ISP and there is zero accountability on their end. I need a way to prove that we are losing these packets and that it is their fault. I'm not quite sure what showing them a long list of packet loss in WireShark will accomplish, but it is all I could think of try to at least verify that reports from speedof.me and DSLReports.com were indeed correct when reflecting how unstable the connection was testing. DSLReports is by far my favorite test as it shows "bufferbloat" which is essentially the same thing as packet loss.

I have a port accessible on the switch for pure speed tests, but that port tests incredibly poor. Right now I get somewhat OK results testing from behind the firewall we have configured (90mbps down, 30 mbps up).

Just not sure where to go from here and I'm not in the mood to battle with them again until I have something 100% definitive to throw in their face. The tech that was out here yesterday saw ONE test run at 90/90 and he ran out the door.
 
What equipment in your home is between you and their lines? Router? Modem? Switch(es)?
 
http://www.pingplotter.com/

Download and run that (you can use the free trial of the pro version). It will allow you to see graphs of loss and at which points along the path from A-B (basically the points of a tracert) the packets are dropping. It's what I used to show WOW when I was having issues.
 
Ehhh! Finally, someone else with the same internet problems as me!
Sub'd for info on the subject. Maybe I can get my ISP to give us a discount on the crappy internet we get.
 
For the record... what bufferfloat is -
Bufferbloat is high latency in packet-switched networks caused by excess buffering of packets. Bufferbloat can also cause packet delay variation (also known as jitter), as well as reduce the overall network throughput. When a router or switch is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like Voice over IP (VoIP), online gaming, and even ordinary web surfing.
https://en.wikipedia.org/wiki/Bufferbloat
 
What equipment in your home is between you and their lines? Router? Modem? Switch(es)?
This isn't my home network. It's work. I'm just dancing around the details for policy reasons.

We have a SonicWall in front of two gigabit NetGear switches. The ISP has provided us with two EX-2200 fiber switches. One is looped to the other which handles the VOIP system. We only are paying for 100/100 so gigabit/fiber is kind of irrelevant.

I slayed the giant spaghetti monster we had and while doing so I isolated our internal network from the phones (when the ISP hooked everything up they looped everything into each other causing packet collision - ugh). It's a very simple setup now.

Really all I'm looking at here when I do testing from the internal network is this: Internet/MainSwitch > SonicWall > Gigabit Switch w/ 1st half of office > Gigabit Switch /w 2nd half of office.

I get the same results of dropped packets though from a dedicated port I had the ISP configure solely for the purpose of testing. I have put in a request to verify that the port is set to AUTO, because we had issues where they had everything set to Full Duplex/100 and that's what was strangling our speed. So it is very peculiar when I go Mainswitch (designed port) straight to the test PC and my speed tests are not only losing packets, but the speed varies between 1-15/5-90 with zero consistency. On the port where the SonicWall is connected, which supplies the office, I'm getting 90/30. It literally makes no sense unless the test port was never switched to AUTO. I have tested from my end by setting the Ethernet driver to Full/100 and back to AUTO with no change in results. Mind you I am doing these tests in the middle of the night with no one else on the network. Plus I have disconnected everyone in the past to do a test without the need to worry about that.


http://www.pingplotter.com/

Download and run that (you can use the free trial of the pro version). It will allow you to see graphs of loss and at which points along the path from A-B (basically the points of a tracert) the packets are dropping. It's what I used to show WOW when I was having issues.

I'm going to try this now, thanks!

For the record... what bufferfloat is -
https://en.wikipedia.org/wiki/Bufferbloat

Sorry if I use something out of context. I'm still trying to learn to swim when it comes to Networking. I understand simple setups and how to troubleshoot most issues, but when we get to breaking down Internet traffic I'm probably confusing things still. I definately see a lot of bufferbloat when I do a test from DSLReports and I am also seeing packets getting dropped through WireShark when just doing general web browsing, downloading files, etc. Typical Internet usage.
 
usually you can log into your modem and it displays right there lost packets in the ui.
 
Take a laptop and connect directly via Ethernet to the closest point to the ISP as possible and see if you're still dropping packets. You have a lot of intermediate equipment, it's possible a bad cable somewhere could cause this.
 
usually you can log into your modem and it displays right there lost packets in the ui.

We're supposed to have access to a portal where can view these things, but they won't give me the information to access it. No reason why. Just simply won't give it to me. We are at war right now with this ISP because of how horrible the customer service has been.


Take a laptop and connect directly via Ethernet to the closest point to the ISP as possible and see if you're still dropping packets. You have a lot of intermediate equipment, it's possible a bad cable somewhere could cause this.

I have done this. This is what I have been talking about by testing on a separate port. I'm going to load PingPlotter on there as well.

Everything we use is Microsoft. So the catch 22 is that the only websites/connections I seem to be having issues with are Microsoft related. I'm looking for a better example as I am typing this, but you can see the loss at hops 10 and 11 in this picture. This issue has been so hard to pin down because of how erratic it is. Obviously the last hop doesn't go through because MS protects their products from DDoS attacks. That much I understand.

Sometimes everything is fine, but around peak hours (after lunch) the connection gets sketchy. We believe this ISP has oversold their bandwidth and simply won't admit they are having issues keeping up with all their clients in this area. We also experience poor quality on the VOIP system which is also on it's own dedicated ports on the switch - so it should be able to reach the fiber line just fine.

Packetloss.png

This has to deal with congestion. Our office is half as full as it was yesterday and now I'm having a hard time duplicating the results to the same severity. That or they finally fixed the issue.

I'm slowly losing my mind trying to diagnose this though.

--update--

As long as their is virtually no load on the system everything is OK right now. As soon as I run a speed test or try to hammer a multiple GB download things begin to get erratic and stutter.

--update #2--

Yeah, I don't know what to say. Thank you for all the suggestions and I will be monitoring this as the week progresses. It is a million times better today than it was yesterday and the weeks before that. I'm downloading Win 10 at 8-10mbs just fine for the most part. I am seeing some dips into the 7s, but that is acceptable.
 
Last edited by a moderator:
Just one thing to note, if it's ethernet from the telco, their port really should be hard coded to 100/full the rest of the ports can definitely be set to auto/auto for sure. When telco sets their interface to auto/auto all kinds of strange issues can crop up that will affect performance for sure.

Sounds like a lot of good advice thus far for sure.

J :cool:
 
We had everything set for Full/100 - This was a talking point we had going the whole time with their installers. We really made sure they wanted everything on Full/100 before allowing them to set it. In the long run that is what was killing the connection. Once they set it to auto the bandwidth issues cleared up. Now we are just dealing with the connection being inconsistent, but prior to that change I couldn't get more than 30mbps of bandwidth out of the switch.

We're looking at our contact to make sure we aren't on a shared resource, as I previously stated we are under the impression this ISP has oversold their bandwidth and that's probably the source of the inconsistent speeds and massive drop offs once the system is under heavy load.
 
Back