Re: Diagnose co-location networking problem

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Stephan Wehner <stephanwehner@...>
Cc: <freebsd-net@...>
Date: Wednesday, December 27, 2006 - 9:45 am

Earlier in the linear time track, on approximately Tue, Dec 26, 2006 at 18:45 ,
Stephan Wehner divulged this public information:




That sounds like a transport problem between your machine and the
server.  It could be anywhere on the link.  Is the colo doing any
rate-limiting?

I see this now and then with dropped packets from my machine to my
servers.  And I control the colo with a rack we have in the Level 3
space so I can trace the problems.  One of the strangest - with
intermittent long delays in packet returns made me think I had a
problem with Level 3.

I contact the NOC in the Denver area, and they checked, and saw no
problems on their net, but they checked further, and what was
happening was the my packets were a different route back to me than
going to the server. [this is not a bug but it doesn't happen very
often - usually when someone screws things up in routers].

Packets left Orlando via Sprint, went to Texas, crossed over to
Level 3 there, back to Orlando and my rack, and then they would go
out onto Level 3, and then go to a Sprinr router in Washington
and come back through Atlanta.   

So the first thing I'd suggest is checking your connections via
traceroute. And >>IF<< your provider does not block RECORD ROUTE
and if the hop count is under 8 - you can try  ping -R .

That will show you the IP addresses from which the packets are
leaving, as opposed to the addresses they are going to.


When you way 'other sites are accessible' do you mean other sites
on your machine, or other sites on the 'net.  And what about other
sites that are located in that colo that you don't control?


Well there is always the chance the moving it created a problem -
something shook loose.  I've had the reverse when I was heading up
a recording studio.  Some of the early digital equipment we had
would get flaky.  We'd ship it by FedEX to the factory, and they'd
find nothing, but change out something that may have caused it.

Three times FedEX cured the problem in shipping - and each time
another piece was changed.  Finally - on number 4 - it worked at
the factory, but they changed ALL the internal cables - and that
fixed it permanently.  It was the vibration in shipment that
temporarily fixed things - but shipping an item out wasn't what I
call a good fix :-)


As above - it could be the colo - or it could be your network
connections to the colo.


Bill
-- 
Bill Vermillion - bv @ wjv . com
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Diagnose co-location networking problem, Stephan Wehner, (Tue Dec 26, 10:45 pm)
Re: Diagnose co-location networking problem, Matthew Hudson, (Wed Dec 27, 6:18 pm)
Re: Diagnose co-location networking problem, Stephan Wehner, (Thu Dec 28, 2:08 am)
Re: Diagnose co-location networking problem, Matthew Hudson, (Thu Dec 28, 4:31 pm)
Re: Diagnose co-location networking problem, Stephan Wehner, (Tue Jan 2, 12:07 am)
Re: Diagnose co-location networking problem, Matthew Hudson, (Thu Jan 4, 3:34 pm)
Re: Diagnose co-location networking problem, Stephan Wehner, (Fri Jan 5, 2:33 am)
Re: Diagnose co-location networking problem, Gary Palmer, (Thu Dec 28, 1:31 pm)
Re: Diagnose co-location networking problem, Bill Vermillion, (Thu Dec 28, 8:07 am)
Re: Diagnose co-location networking problem, Stephan Wehner, (Thu Dec 28, 12:31 pm)
Re: Diagnose co-location networking problem, Bill Vermillion, (Thu Dec 28, 5:46 pm)
Re: Diagnose co-location networking problem, Bill Vermillion, (Wed Dec 27, 9:45 am)
Re: Diagnose co-location networking problem, Stephan Wehner, (Wed Dec 27, 1:55 am)