?

Log in

No account? Create an account
An e-mail I just sent--and copied to our entire systems team and… - A Suburbs Boy Living a Country Life [My Flickr Photos]
November 18th, 2004
12:51 am

[Link]

Previous Entry Share Next Entry

(12 comments | Leave a comment)

Comments
 
[User Picture]
From:happypete
Date:November 18th, 2004 07:21 pm (UTC)

Re: This morning at our house

(Link)
It just blew me away that they could write an e-mail saying "well, we don't see any problem," after all the documentation.

I had given them these figures over the phone before writing the e-mail and they went off to "investigate."
[User Picture]
From:macthud
Date:November 19th, 2004 02:17 pm (UTC)

Re: This morning at our house

(Link)
fer future consideration... you might dodge the `mildly yelled at` by saying `as I provided in my initial phone call raising this ticket...` before leading into the figures.

Checking pipe performance with larger packets is a good idea, for troubleshooting lots of issues, but unfortunately -- Lots and LOTS of elderly systems, including those in place at many of the LARGE providers have major issues with packets larger than about 1536 bytes...

As unix_vicky says below -- I'd also concentrate on the packet loss much more than the latency -- even to pretending that the latency doesn't bother you at all (even though I gather that is what started *you* on this investigation), and squawk loud and long about the loss.

What *should* happen when you send large packets is that they get fragmented, to the lowest common MTU of the total route traveled, which will increase latency -- but you should *not* see any increase in packet loss, if routers and wires and other elements are operating correctly. Thus, this loss should be the primary focus of complaint and troubleshooting....

oh, and also useful -- tcptraceroute, which gets around all-too-common UDP filtration rules, and also lets you check whether TCP port xxx packets are getting through. I haven't played with UDP port-specific tools, but I would hope they're out there...

Good luck! (As I go download MTR, and look to see whether it builds and runs on Mac OS X...)
From:(Anonymous)
Date:November 23rd, 2004 05:28 am (UTC)

Re: This morning at our house

(Link)
Ted writes:

What *should* happen when you send large packets is that they get fragmented, to the lowest common MTU of the total route traveled, which will increase latency -- but you should *not* see any increase in packet loss, if routers and wires and other elements are operating correctly. Thus, this loss should be the primary focus of complaint and troubleshooting....

Not so actually... the packet (or the GRE-encapsulated PPTP packet) will get fragmented into two packets. Both of these packets must arrive at the destination for the original packet to be reconstituted; thus, the packet loss will double. And indeed we see that when the 1400 byte payload pings go out (1442 bytes total including all headers; < 1518 bytes maximum ethernet frame size), the loss is 7%, while when the 1500 byte payload pings go out (1542 > 1518 therefore fragmenation), the loss is 13%, or almost double.


Pinging *to* a router is not a useful metric. Pinging *through* a router is a useful metric. Be sure of what you're measuring.


If Pete is seeing 2% packet loss on his Ethernet, it's time to start checking for duplex mismatches, etc. Get one's own house in order so as to be able to better see the problem from the service provider.


My $0.02...


--RS

[User Picture]
From:happypete
Date:November 23rd, 2004 03:05 pm (UTC)

Re: This morning at our house

(Link)
Thanks, RS...That's a very cogent summary. Of course, it doesn't explain the quantum jump from 1500 to 1700...By the way, though MCI claims to have made no changes, we are now seeing ~0% loss with >= 1500 byte packets.

Thanks for the explanation of the doubling of the loss rate in addition to increased latency.

We are, of course pinging through several routers--but because it's a managed MCI VPN we don't even see them, e.g.:

H:\>tracert 10.0.2.100

Tracing route to 10.0.2.100 over a maximum of 30 hops

1 1 ms 1 ms 1 ms router.bfs.hpti.com [10.0.10.1]
2 1 ms 1 ms 1 ms router-mci.bfs.hpti.com [10.0.10.254]
3 46 ms 46 ms 50 ms 65.207.28.250
4 84 ms 101 ms 101 ms 10.0.2.100

1st hop, our local router (completely superfluous, but our network guy here keeps it "so we can set up a back-up dial-up path to the network if MCI goes down for a long time."--my thinking is that we could keep that in cold storage, not make it the default gateway, and crack it out for that purpose if such a disaster occurs...but that's just me); 2nd hop our router; 3rd hop === 10.0.2.99's "public face"; 4th hop == node on the other side of the router.

Note that the 2nd hop is in Picatinny, the 3rd hop is in Arlington. MCI has hidden the path between from us. (This is by design--we're not supposed to care, so long as the packets get there, and our network traffic is supposed to be secure and partitioned from everyone else's).

Okay, back to work for me.
Powered by LiveJournal.com