O Canada! > Canadian > Shaw > [ALL] Ask a Shaw Rep

reply to Jumpy

Re: [ALL] Ask ShawSean

You aren't sending them directly to the routers; you're still addressing your packets to your destination (dragon305). The only difference between the tcptraceroute and a tcp connection is that tcptraceroute artificially limits the TTL of the packet, causing the normal packet handling of each router along the way to encounter an 'expire' condition which _should_ be dealt with by sending an ICMP packet in response. This ICMP response packet is what is used to determine the route the packets are taking.

Looking at your paste, I see the same thing I saw in mine. One router (66.198.97.10, hop 10) shows a bunch of timeouts. This simply means that the ICMP response packet was never seen. The very next hop (11, 154.54.12.21) shows no timeouts. This means that your TCP packets are making it through just fine and the SYNACK response is making its way back just fine.

Actually, it is only hop 10 that is showing any sort of issue. Since we know that it is relaying the TCP packets properly, and that there are no timeouts that occur after it, I don't think we can blame anything on a network issue. I added a longer wait (add -w 10 somewhere in that command) to my trace and the final hop for me showed no loss (some 3 second + responses that were not seen prior to that final hop though). I'd start by opening a ticket with your hosting provider (I assume that dragon305 is your host).

I have opened tickets with the server host, they think that its a problem with as6453 too, but they don't have a peering agreement with them so they can't complain about it. Shaw does have a peering agreement with as6453 though, so I was kind of hoping they could complain about the loss. I can download fast from that server using other servers that don't route through as6453.