brad
join:2007-09-06
Etobicoke, ON | reply to portshner
Re: "Teksavvy Routing Issues (Jan 24th - Present)" said by portshner:At this point I thought it was Soft Layer, but why on earth are our routes going to chicago THEN to washington? Please advise.
Is this supposed to be a bad joke? Packets are supposed to magically jump from point to point?
What site is this anyway? This thread is devoid of any useful information so far. |
|
1 edit | No, but they aren't supposed to go from Toronto, to CHICAGO, then to Washington. That's like me going to Niagara Falls via Newmarket. |
|
| Peer 1 peers with SoftLayer in Chicago not Washington. There is a major exchange in Chicago. Without traces on the other high pings there is no way to tell if there is a problem there either. |
|
brad
join:2007-09-06
Etobicoke, ON | reply to portshner
said by portshner:No, but they aren't supposed to go from Toronto, to CHICAGO, then to Washington. That's like me going to Niagara Falls via Newmarket.
hockeystreams.com is the site in question.
They can't go directly from Toronto to DC if there isn't a route to get there. This should be common sense. |
|
 TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | Chicago, New York and Montreal are pretty much the only major exit points from Toronto. |
|
|
|
| Fair enough - What are our options currently? Who's side is the issue on? |
|
TSI GabePremium,VIP
join:2007-01-03
Chatham, ON
kudos:2 | I routed around it, it looks better now. |
|
Reviews:
 ·TekSavvy DSL
| PING 74.125.226.66 (74.125.226.66) 56(84) bytes of data.
64 bytes from 74.125.226.66: icmp_req=1 ttl=57 time=10.6 ms
64 bytes from 74.125.226.66: icmp_req=2 ttl=57 time=11.1 ms
64 bytes from 74.125.226.66: icmp_req=3 ttl=57 time=12.3 ms
64 bytes from 74.125.226.66: icmp_req=4 ttl=57 time=18.4 ms
64 bytes from 74.125.226.66: icmp_req=5 ttl=57 time=11.4 ms
64 bytes from 74.125.226.66: icmp_req=6 ttl=57 time=12.6 ms
64 bytes from 74.125.226.66: icmp_req=7 ttl=57 time=12.3 ms
64 bytes from 74.125.226.66: icmp_req=8 ttl=57 time=10.8 ms
64 bytes from 74.125.226.66: icmp_req=9 ttl=57 time=11.8 ms
From my teksavvy connection (to the IP the OP was testing with)
So hopefully is also fixed for the OP. |
|
brad
join:2007-09-06
Etobicoke, ON | said by Arcturus:From my teksavvy connection (to the IP the OP was testing with)
So hopefully is also fixed for the OP.
That is Google, nothing changed there. |
|
 PlatooN
join:2007-02-13
Kitchener, ON | reply to brad
said by brad:said by portshner:No, but they aren't supposed to go from Toronto, to CHICAGO, then to Washington. That's like me going to Niagara Falls via Newmarket.
hockeystreams.com is the site in question.
They can't go directly from Toronto to DC if there isn't a route to get there. This should be common sense. google also has peering within torix ... which should ALSO make sense.
no need for the toronto to chi to washington router ... which frome the looks of things is what Gabe fixed.
Tracing route to www.google.com [74.125.226.49]
over a maximum of 30 hops:
1 1 ms 4 ms 1 ms my.router [192.168.1.1]
2 11 ms 13 ms 12 ms 10.125.99.1
3 15 ms 14 ms 15 ms MHAYZ.wbb.net.cable.rogers.com [24.156.143.73]
4 13 ms 11 ms 11 ms kitchener1.cable.teksavvy.com [24.246.55.38]
5 15 ms 15 ms 14 ms 24-52-255-161.cable.teksavvy.com [24.52.255.161]
6 16 ms 15 ms 14 ms gw-google.torontointernetxchange.net [206.108.34
.6]
7 15 ms 14 ms 15 ms 216.239.47.114
8 16 ms 15 ms 15 ms 64.233.175.132
9 16 ms 15 ms 14 ms yyz06s06-in-f17.1e100.net [74.125.226.49]
Trace complete. |
|
| reply to captainbrew
The original OPs traceroute was to 67.213.218.156.
To me, it still looks like it's going through CHI to me.
Tracing route to 67.213.218.156 over a maximum of 30 hops
1 1 ms 1 ms 1 ms DD-WRT [192.168.1.1]
2 13 ms 14 ms 6 ms 206.248.154.104
3 6 ms 6 ms 6 ms 2120.ae0.bdr01.tor.packetflow.ca [69.196.136.66
4 6 ms 6 ms 6 ms peer1.bdr02.tor.packetflow.ca [64.34.236.121]
5 16 ms 16 ms 16 ms 10ge.xe-2-0-0.chi-eqx-dis-1.peer1.net [216.187.
14.37]
6 16 ms 16 ms 16 ms te1-7.bbr01.eq01.chi01.networklayer.com [206.22
.119.63]
7 16 ms 17 ms 16 ms ae7.bbr02.eq01.chi01.networklayer.com [173.192.
8.171]
8 31 ms 30 ms 56 ms ae0.bbr02.eq01.wdc02.networklayer.com [173.192.
8.154]
9 31 ms 31 ms 31 ms ae1.dar02.sr01.wdc01.networklayer.com [173.192.
8.189]
10 34 ms 47 ms 32 ms po2.fcr03.sr02.wdc01.networklayer.com [208.43.1
8.159]
11 32 ms 32 ms 32 ms 67.213.218.156
Trace complete. |
|
brad
join:2007-09-06
Etobicoke, ON | said by portshner:The original OPs traceroute was to 67.213.218.156.
To me, it still looks like it's going through CHI to me.
And that is expected. |
|
| You stated above that there's exchanges in Chicago, Toronto and New York - wouldn't it make sense to go from Toronto > New York > Washington, DC? (Albeit I don't know much about how this works, just makes very little sense)
This is a traceroute from a toronto IP on Rogers
1 1 ms 1 ms 1 ms 192.168.1.1
2 10 ms 8 ms 7 ms 7.28.128.1
3 14 ms 15 ms 11 ms w-PC.wbb.net.cable.rogers.com [24.156.143.213]
4 18 ms 22 ms 11 ms 69.63.249.173
5 27 ms 27 ms 25 ms 69.63.251.154
6 * * * Request timed out.
7 25 ms 30 ms 27 ms ae0.dar02.sr01.wdc01.networklayer.com [173.192.1
8.203]
8 138 ms 29 ms 27 ms po2.fcr03.sr02.wdc01.networklayer.com [208.43.11
8.159]
9 29 ms 29 ms 28 ms 67.213.218.158
Trace complete.
I do not see any routes going via Chicago... |
|
brad
join:2007-09-06
Etobicoke, ON | reply to PlatooN
said by PlatooN:google also has peering within torix ... which should ALSO make sense.
SoftLayer != Google
said by PlatooN:no need for the toronto to chi to washington router ... which frome the looks of t
hings is what Gabe fixed.
The post about going to DC was about SoftLayer not Google. |
|
brad
join:2007-09-06
Etobicoke, ON
1 edit | reply to portshner
said by portshner:You stated above that there's exchanges in Chicago, Toronto and New York - wouldn't it make sense to go from Toronto > New York > Washington, DC? (Albeit I don't know much about how this works, just makes very little sense)
That's Rogers. Different network. Different design. Different routing policies. Rogers exchanges most of their traffic out of NYC and not a whole lot out of Chicago. Some with traffic coming from Toronto exchange most out of Chicago. Telus for example has most of their traffic out of Chicago. Bell tends to split across the two cities depending on the destination network.
Also BGP has no concept of latency across a route. It can't make routing decisions like that. |
|
| reply to captainbrew
WTF?! I think I've got the worst route and pings of all....
See this illustration:
And the test@test shows this:
 |
|
brad
join:2007-09-06
Etobicoke, ON | said by MrMazda86:WTF?! I think I've got the worst route and pings of all....
See this illustration:
And the test@test shows this:
Different issue. You're on DSL and connected via an overloaded AGAS link from the looks of it. |
|
| Yes... That is correct. I was just horrified when I saw the stats because of how high they are. |
|
PlatooN
join:2007-02-13
Kitchener, ON | reply to MrMazda86
said by MrMazda86:WTF?! I think I've got the worst route and pings of all....
See this illustration:
And the test@test shows this:
yeah that is an overloaded AGAS link, but i have a bit of a side observation.
I know in another post you made you said you have modem -> switch for various static IP's.
is 173.246.156.225 (i assume it is based on the .cpe. in your rDNS entry) your main router wan IP? if so I would be looking into the 100ms latency between your switch and modem, cause that's ugly! |
|
1 edit | Yes... the .225 address is the modem. I'm going to try changing it out for a Comtrend CT-5072T to see what kind of a difference that it yields.
(EDIT: I have just double checked with the Comtrend CT-5072-T modem and the results are unbelievable in terms of the difference between this modem and the Thompson SpeedTouch 516. I'm fairly certain that the result had to do with the way that LAN - LAN access was being handled in the original Thompson SpeedTouch 516 and the fact that I do have a lot of such traffic that takes place. This modem seems to allow the packets to flow through the switch, thus bypassing the internet line completely, whereas the SpeedTouch didn't do that.)
This is what the route to TekSavvy now looks like. Notice the difference when these packets are sent through the modem now. The same amount of LAN traffic still exists, just not through the modem directly anymore. It all stays switch side now. |
|
