Search similar:
|
|
uniqs 1681 |
|
|
|
yangman join:2012-12-13 Vancouver, BC |
[BC] Week-long TSI outage, no resolution: seems to be Shaw issueI'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
2012-Dec-18 6:38 pm
Re: [BC] Week-long TSI outage, no resolution: seems to be Shaw iAre 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 |
Re: [BC] Week-long TSI outage, no resolution: seems to be ShawGateway 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
2012-Dec-18 7:49 pm
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 |
Re: [BC] Week-long TSI outage, no resolution: seems to be Shaw iPeople 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. | | |
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
2012-Dec-19 2:56 am
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. | | | |
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. | | |
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? | | |
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. | | |
Get in line. | |
your moderator at work
hidden : hidden :
|
|