dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
1681
yangman
join:2012-12-13
Vancouver, BC

yangman

Member

[BC] Week-long TSI outage, no resolution: seems to be Shaw issue

I'm grasping at straws at this point.

My TSI connection has been down for the past week. All indicators point to an issue either at Shaw, or with a specific route between Shaw and TSI. TekSavvy can't seem to get a response out of Shaw after escalating multiple times and I frankly have no reason to doubt them. I've had an outage in the past under similar circumstances and it took Shaw over a week and a half to resolve it.
~ $ /usr/sbin/tracepath -b 8.8.8.8
1: 192.168.8.8 (192.168.8.8) 0.059ms pmtu 1500
1: 192.168.8.1 (192.168.8.1) 0.583ms
1: 192.168.8.1 (192.168.8.1) 10.871ms
2: no reply
3: 64.59.148.129 (64.59.148.129) 22.156ms !H
Resume: pmtu 1500
DHCP resolves fine. I can ping the gateway that comes back with the IP (which I assume is the "no reply" hop in the above log). TSI's support checked that I can ping and trace to other nodes in their network.

But, 64.59.148.129 is dropping *all* traffic from my connection out to the internet. I've had a friend on Shaw verify that they are able to ping it. I can ping other IPs in the same network block. I can't, however, get any traffic *through* that server which is where I'm getting routed to.

What's going on?

kevinds
Premium Member
join:2003-05-01
Calgary, AB

kevinds

Premium Member

Re: [BC] Week-long TSI outage, no resolution: seems to be Shaw i

Are you able to ping other addresses on your side of the 64.59.148.129 router, but a different subnet then you are on right now?

What is your gateway address?
yangman
join:2012-12-13
Vancouver, BC

yangman

Member

Re: [BC] Week-long TSI outage, no resolution: seems to be Shaw

Gateway is 69.172.154.65.

I recall being able to reach a TSI router a support person had me ping that was outside of my subnet, but I can't say for sure, and can't verify at the moment. Both ping and trace worked fine to that node.

kevinds
Premium Member
join:2003-05-01
Calgary, AB

kevinds

Premium Member

4 14 ms 14 ms 15 ms rc2so-tge0-1-1-0.cg.shawcable.net [66.163.71.109
]
5 22 ms 23 ms 35 ms rc2wh-tge0-2-1-0.vc.shawcable.net [66.163.77.226
]
6 35 ms 22 ms 50 ms 10ge.pix-gw.van.peer1.net [206.223.127.1]
7 23 ms 23 ms 24 ms 69.90.31.242
8 27 ms 24 ms 32 ms shaw-van.cable.teksavvy.com [76.10.191.34]
9 * * * Request timed out.
10 * ^C

From Calgary, I wonder why it gets to Vancouver using Shaw, then to Peer1, back to Teksavvy's router to Shaw? But nothing further.

Looks like a routing issue though.
yangman
join:2012-12-13
Vancouver, BC

yangman

Member

Re: [BC] Week-long TSI outage, no resolution: seems to be Shaw i

People I'm sharing the connection got fed up with waiting and ordered Shaw, which just got installed today. Surprise surprise, I'm still routed through the same node, but no issues there.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.8.1 (192.168.8.1) 0.621 ms 0.651 ms 0.708 ms
2 * * *
3 rh30ca-cmts.vc.shawcable.net (64.59.148.129) 16.693 ms 16.693 ms 16.688 ms
4 66.163.68.213 (66.163.68.213) 24.496 ms 24.490 ms 24.485 ms
5 rc2wh-tge0-15-1-0.vc.shawcable.net (66.163.69.121) 18.800 ms 18.801 ms 18.795 ms
6 rc4wt-pos0-0.wa.shawcable.net (66.163.76.154) 24.438 ms 23.428 ms 23.387 ms
(etc, etc)
Yeah, not impressed at Shaw.
ppickfor8
join:2010-01-27
Vancouver, BC

ppickfor8

Member

Some diags I sent to Chad at CSI

root@laptop1:~# ip route
69.172.154.64/26 dev eth0 proto kernel scope link src 69.172.154.75 metric 1
default via 69.172.154.65 dev eth0 proto static

Pings seem to get further if the record route option is used - not necessarily all hops but some indication of where packets are going.

Setting ttl manually allows traceroute like functionality without the host being ping-able.

for ((t=2;t10;t=t+1)) ;do echo $t;ping -R -t $t -c 1 76.10.191.198 &&break;done |tee -a /tmp/diags.txt

PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 69.172.144.193 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 76.10.191.33 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

4
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 76.10.191.26 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

5
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
64 bytes from 76.10.191.198: icmp_req=1 ttl=60 time=61.0 ms
RR: 69.172.154.75
76.10.191.28
76.10.191.198
76.10.191.33
10.93.128.1
69.172.154.75

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 61.000/61.000/61.000/0.000 ms

google dns
for ((t=2;t10;t=t+1)) ;do echo $t;ping -R -t $t -c 1 8.8.8.8 &&break;done |tee -a /tmp/diags.txt
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 64.59.148.129 icmp_seq=28 Packet filtered
2
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 69.172.144.193 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 76.10.191.33 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

4
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 65.19.143.137 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

5
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 184.105.222.1 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

6
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

7

using shaw for dns over wireless tracepath to the border gateway

root@laptop1:~# tracepath -b 76.10.191.33
1: laptop1 (69.172.154.75) 0.281ms pmtu 1500
1: no reply
2: no reply
3: bdr01.van.cable.teksavvy.com (76.10.191.33) 14.065ms reached
Resume: pmtu 1500 hops 3 back 253
root@laptop1:~# tracepath -b 65.19.143.137
1: laptop1 (69.172.154.75) 0.257ms pmtu 1500
1: no reply
2: no reply
3: rh30ca-cmts.vc.shawcable.net (64.59.148.129) 11.386ms !H
Resume: pmtu 1500

from wireshark

60388 15518.112591 64.59.148.129 69.172.154.75 ICMP Destination unreachable (Communication administratively filtered)

packet filtering icmp comes back from 64.59.148.129

If the routing is correct then perhaps its an access list problem?

It is possible to ping from inside Sahw's network to 69.172.154.75.

From outside of Shaw's network (TSI) pings to 69.172.154.75 are received but the echo replies are blocked by the filtering so the sender never gets the reply.

pp
@shawcable.net

pp to yangman

Anon

to yangman
root@laptop1:~# ip route
69.172.154.64/26 dev eth0 proto kernel scope link src 69.172.154.75 metric 1
default via 69.172.154.65 dev eth0 proto static

Pings seem to get further if the record route option is used - not necessarily all hops but some indication of where packets are going.

Setting ttl manually allows traceroute like functionality without the host being ping-able.

for ((t=2;t10;t=t+1)) ;do echo $t;ping -R -t $t -c 1 76.10.191.198 &&break;done |tee -a /tmp/diags.txt

PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 69.172.144.193 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 76.10.191.33 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

4
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
From 76.10.191.26 icmp_seq=1 Time to live exceeded

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

5
PING 76.10.191.198 (76.10.191.198) 56(124) bytes of data.
64 bytes from 76.10.191.198: icmp_req=1 ttl=60 time=61.0 ms
RR: 69.172.154.75
76.10.191.28
76.10.191.198
76.10.191.33
10.93.128.1
69.172.154.75

--- 76.10.191.198 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 61.000/61.000/61.000/0.000 ms

google dns
for ((t=2;t10;t=t+1)) ;do echo $t;ping -R -t $t -c 1 8.8.8.8 &&break;done |tee -a /tmp/diags.txt
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 64.59.148.129 icmp_seq=28 Packet filtered
2
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 69.172.144.193 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 76.10.191.33 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

4
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 65.19.143.137 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

5
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.
From 184.105.222.1 icmp_seq=1 Time to live exceeded

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

6
PING 8.8.8.8 (8.8.8.8) 56(124) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

7

using shaw for dns over wireless tracepath to the border gateway

root@laptop1:~# tracepath -b 76.10.191.33
1: laptop1 (69.172.154.75) 0.281ms pmtu 1500
1: no reply
2: no reply
3: bdr01.van.cable.teksavvy.com (76.10.191.33) 14.065ms reached
Resume: pmtu 1500 hops 3 back 253
root@laptop1:~# tracepath -b 65.19.143.137
1: laptop1 (69.172.154.75) 0.257ms pmtu 1500
1: no reply
2: no reply
3: rh30ca-cmts.vc.shawcable.net (64.59.148.129) 11.386ms !H
Resume: pmtu 1500

from wireshark

60388 15518.112591 64.59.148.129 69.172.154.75 ICMP Destination unreachable (Communication administratively filtered)

packet filtering icmp comes back from 64.59.148.129

If the routing is correct then perhaps its an access list problem?

It is possible to ping from inside Shaw's network to 69.172.154.75.

From outside of Shaw's network (TSI) pings to 69.172.154.75 are received but the echo replies are blocked by the filtering so the sender never gets the reply.

Baud1200
join:2003-02-10

Baud1200

Member

Really don't know why Shaw has so many routing issues constantly. Actually I do... money. Suspect the situation is similar to that posted by ilianame
said by ilianame:

Shaw's route to certain Seattle providers takes you around to South California through Comcast routing and then back up the coast to Seattle (5000 extra km).

If that route is overloaded, you will be switched to a Peer1 route (transit for which is more expensive), and you'll get the 15ms pings to all destinations in Seattle.

I've long been arguing that Shaw should use Peer1 west coast route for all west coast requests, but it seems Shaw has a sweet bilateral deal with Comcast.

With profit being their bottom line, it will only get worse as more and more people accept this level of service, be it out of ignorance or desperation.

rustydusty
join:2009-09-29
Red Deer County, AB

rustydusty

Member

said by Baud1200:

Really don't know why Shaw has so many routing issues constantly. Actually I do... money. Suspect the situation is similar to that posted by ilianame

said by ilianame:

Shaw's route to certain Seattle providers takes you around to South California through Comcast routing and then back up the coast to Seattle (5000 extra km).

If that route is overloaded, you will be switched to a Peer1 route (transit for which is more expensive), and you'll get the 15ms pings to all destinations in Seattle.

I've long been arguing that Shaw should use Peer1 west coast route for all west coast requests, but it seems Shaw has a sweet bilateral deal with Comcast.

With profit being their bottom line, it will only get worse as more and more people accept this level of service, be it out of ignorance or desperation.

Wife crap in your cornflakes, amigo?
Gotspeed
join:2011-12-30

Gotspeed

Member

said by rustydusty:

Wife crap in your cornflakes, amigo?

No just a fed up consumer in need of a change in the quality of service paid for.

rustydusty
join:2009-09-29
Red Deer County, AB

rustydusty

Member

Get in line.
Expand your moderator at work