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
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 |
|
