NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
 ·Pacific Bell - SBC
| reply to marcelo3d
Re: Lossy (broken?) router dist1-10g1-2.snfcca.sbcglobal.net
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 |
|
