John,
I promise that a lot changed over the weekend. That is the time when the network Nazis are gleefully at their best.
Or this may turn out to be a sad lesson about MS auto-update.
A further test: try pinging Apollo with the default settings, then 1000 packets, then 1000 1500 byte packets.
If you can't ping Apollo, things should not be working for you.
If you use ping with an invalid setting, it will tell you what all the switches are.
John
Well, I cancelled afte the first 80 or so went by:
Ping statistics for 198.80.11.57:
Packets: Sent = 81, Received = 76, Lost = 5 (6% loss),
Approximate round trip times in milli-seconds:
Minimum = 60ms, Maximum = 170ms, Average = 57ms
Those losses were always about every 5 packets to start, then it stablized. Tracert always still fails on the last hop, but only from this office location.
John
OK, it totally times out with 1500 packet size - no replies at all.
John
John,
Interesting. TCP/IP sends a group of packets and waits for an acknowledgment. If a packet is lost, then a retransmission timer must expire and the process restarted. A few lost packets can cause a surprising problem.
The 6% loss you observed is pretty high.
There is a figure agreed upon as a default maximum transmission unit for IP over ethernet and serial links, MTU, of 1500 bytes, hence the 1500 byte test.
There is a provision for using ICMP for negotiation of an MTU other than the default which can causes problems because network Nazis often block ICMP altogether and the negotiation can't take place. One router will use something other than the default and its neighbor will not like that. Hey, I told you and you ignored it. Smaller packets will pass OK.
Apollo # ifconfig alt0
alt0: flags=200c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTI CAST,SIMPLEX,MULTINET>
inet 198.80.11.57 netmask ffffff00 broadcast 198.80.11.255 ipmtu 1500
Can you find what size packets break transmission?
I just realized a possibility... The routing between us is now asymmetric - this may have happened over the weekend - and the return packets may now be sent out from an FDDI interface with a 4352 byte MTU.
Apollo # ifconfig fta0
fta0: flags=8c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICA ST,SIMPLEX>
inet 204.181.152.50 netmask ffffff00 broadcast 204.181.152.255 ipmtu 4352
in which case your packets are now being zapped.
Another possibility is that someone decided to block ICMP who allowed it before. In any case Apollo's FDDI interface has always had a large MTU as FTA0 is generally used for internal communications and the large MTU is more efficient.
John
John
Last edited by John Nebel; 09-22-2004 at 09:43 AM.
OK, I changed fta0 to see what would happen...
Apollo # ifconfig fta0 ipmtu 1500
Apollo # ifconfig fta0
fta0: flags=8c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICA ST,SIMPLEX>
inet 204.181.152.50 netmask ffffff00 broadcast 204.181.152.255 ipmtu 1500
John Nebel
32 bytes works, 64 bytes fail.Can you find what size packets break transmission?
'Good thing I'm in IT at my company - the last few days all I've been doing is sitting in front of various computers, so I can pop in now and then to check.
BTW - I can't ping to ANY sites using 64 bytes, much less 1500 size - they all time out! But this is still the only site giving me problems.
John
John,
IT companies may be the worst offenders in having brilliant, bad ideas about networking.
You tried the site after the MTU change?
John
Last edited by John Nebel; 09-22-2004 at 10:23 AM.
'Still can't ping anything above 32 bytes. I'll get in touch with our ISP/WAN provider and run it by them.
One thing - both our offices connect to each other and the Internet via 2M high-speed wireless. We switched from T1 because the wireless scales to 8M if we want. I wonder if something in this scenario breaks packets down or something to keep them under 32 bytes??
It's still odd that this site is the only one giving me problems...
Edit: It's also odd that intermitently it acts completely normal for an instant or two. Like when I just posted this initial response here, it posted and appeared immediately, with no delay at all. Yet as soon as I hit "Edit" to add that fact, another 20 second delay...
John
Last edited by johnaec; 09-22-2004 at 10:40 AM.
Pinging aside - did the response time change with the MTU size change? If it didn't, I'll set it back.
John Nebel
Response time is exactly the same 60-70ms.
Weird - this reply function popped right up - no delay. Yet doing exactly the same thing at other times give that ~20 second delay...
John
John,
Was the change to wireless at work coincident with the problems?
Another question.. Suppose there is some graphic or graphics which the MS software du jour doesn't like. Is the reply page different in that regard?
John
The wireless has been in place several months, likewise, the problem is from every computer I try it on at the office, whether recently updated or not. Only navigating this website has problems, logged on or not - everything else is normal.
John
Hey, johnaec...
First, I'm sure glad this is you, and not me. I'm not functional in all this to even decipher the symptoms!!
Hey - have you created a dummy login and see if there's something quirky with your current one? Just a random thought...
bo
"Indeed, not!!"
I don't think that's it because if I come here while not logged in, just to browse around, I get the same delays. But I'll probably try that soon - what's to lose.Originally posted by boputnam
Hey - have you created a dummy login and see if there's something quirky with your current one? Just a random thought...
John N. - I can ping with 1000 byte packets just fine from home, so the situation at our office may be related to the fact I can't from there.
That just leaves the problem of why one home computer is fine and one acts just like at the office.
And the real question - why is audioheritage the only site where this happens?
curiouser and curiouser...
John
I'm getting the delays now at home and at my office for this site. Very strange
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote