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"
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Linus Torvalds | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Linus Torvalds | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
