?

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
 
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