marcelo3d
join:2009-06-19
Santa Cruz, CA
|  Lossy (broken?) router dist1-10g1-2.snfcca.sbcglobal.net
I started having problems with dropped packets and traced it to dist1-10g1-2.snfcca.sbcglobal.net. It seems that this router drops 5% - 15% of packets. I've been trying to explain the issue to ATT over the phone, but it has not been easy. So far I got 2 "tear and rebuild" of the circuit, with no real difference.
The dropped packets affects me when working from home and using the VNC to the computers at work (over VPN), so the router is not just dropping ICMP packets, but all kinds.
See »/routerwatch/d···obal.net for a bunch of test from different locations that show the issue.
I'm in Santa Cruz, but have no idea where this router is located. My connection to the redback is really solid. I've never seen my (yes, old) Westell Wirespeed (B90-36R516) loosing sync.
Advice on how to get this issue resolved is appreciated.
Marcelo.- |
|
tonydi
Premium,MVM
join:2001-05-11
San Jose, CA
| Wow, that one has had this problem for more than 6 months so I'm thinking AT&T isn't going to jump to fix it for you. 
The router is in San Francisco, in the same POP where your redback is located. They've rebuilt your circuit but you're still on the same redback so your traffic is still going through the same router.
I'd try and convince them to just move you to a different redback. |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
 ·Pacific Bell - SBC
| reply to marcelo3d
The first five results I sampled showed no loss at the endpoints, except for No.2 showing 2% loss at the tester's end (usually not a problem) and No.5 not being responsive to ping (which masks any near end packet loss).
I am dubious that there is any problem with that router, other than the obvious: It is configured to ignore trace route packets.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
marcelo3d
join:2009-06-19
Santa Cruz, CA
| Norman,
It is dropping more than just traceroute packets. I see the issue with IPSEC packets as well (VPN to office).
I also see random packet loss (DNS, I suspect). It sometimes takes long time to resolve google or CNN, when normally does it really fast. (I know that DNS info is cached for a bit, so it is not that).
Again, the issue is IPSEC traffic being dropped (and VNC not dealing with lost packets that nicelly).
The router is configured to respond to tracert or we wouldn't see any respose at all.
Maybe the router is at capacity, dropping a lot of ping and other traffic.
Marcelo.- |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA | But the "routerwatch" link doesn't show anything about the IPSEC packets. By itself, that link is not demonstrating any kind of problem.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
marcelo3d
join:2009-06-19
Santa Cruz, CA | Norman,
Oh, so I don't have a problem? Gee.
Even the ATT techs agree that there is an issue, that they see it and they try what they can: rip+rebuild.
Do you have a suggestion on an IPSEC based trace tool?
Marcelo.- |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
·Pacific Bell - SBC
| I did not say you don't have a problem. I overlooked your VNC comment in your original post.
All that I am saying is that the link you posted is not evidence of a problem. You need more than some "routerwatch" link, which is only showing evidence of trace route de-prioritization. Surly there are other tools, which can be used in conjunction with IPSEC, to demonstrate the problem! I don't know of any, myself, though. I've not played with VPN tunnels.
Rip and rebuild would fix a problem on your aggregation router; but it doesn't appear to be that router?
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
marcelo3d
join:2009-06-19
Santa Cruz, CA
| Norman,
Yes, and no. I'm not sure what dslreports uses for trace route. It could be udp or ICMP. Even if it is ICMP pings, the fact that all other routers from the east coast to me decide to pass it along and this one has to de-prioritize them is a sign. It is not proof, I agree with you.
I'm sorry, but I don't know which are agregation routers from this path:
bb1-g1-0.pxpaca.sbcglobal.net
dist1-10g1-2.snfcca.sbcglobal.net2
rback35-g1-snfcca.sbcglobal.net
My Address |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
·Pacific Bell - SBC
| The only sign that a router not passing trace route packets (could be UDP, TCP, or ICMP; it is the TTL flag, among other packet header data, which makes it a trace route packet) give is that it is not passing those packets. Whether that is due to problems with the router, or other, can't be determined from the trace.
I am reasonably certain that your aggregation router is 'rback35-g1-snfcca.sbcglobal.net'.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
