| Mike Drechsler - SPAM PROTECTED EMAIL 2005-11-02, 7:51 am |
| Vince wrote:
> Boy, if that's the case, I would be ecstatic if I can get this
> resolved. OK, say the scenario you described is applicable in my case.
> How would I best explain this to my ADSL provider (SBC) to convince
> them of an actual problem that falls within the scope of their service
> guarantees? I'm worried that the conversation will end with "Well, you
> can surf the internet, right? Then it's working as it shoud."
>
> routers for 2-3 minutes w/1427 bytes when the tunnels were working,
> wasn't losing anything:
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=216ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=218ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=218ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
> Reply from 192.168.1.1: bytes=1427 time=217ms TTL=254
>
>
> Reply from 192.168.2.1: bytes=1427 time=173ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=170ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=171ms TTL=254
> Reply from 192.168.2.1: bytes=1427 time=172ms TTL=254
>
> Does this mean my problems don't match with what you had?
>
Well, mine was particularly bad. But it did have it's good moments
where I could use the connection and other times when it was horrible
and my internet was basically down. I felt fortunate that the tech came
when it was very bad. The problem was very evident and it continued for
the entire length of the service call so we were able to do the tests
inside the house and out on the street and find that it was an
unbalanced amplifier (low channels where the return path is transmitted
was very low compared to the rest of the channel range)
You can basically just run a continuous ping to the other site you are
having problems with as well as a ping to a default gateway or other
appropriate router on the ISP side that would show if the problem is
local to your connection or more toward the remote end. There are
plenty of third party programs for monitoring your network connection.
Something like Advanced Hostmonitor http://www.ks-soft.net/ is a good
start, but probably not perfect for this purpose.
The hardest problems to troubleshoot are intermittent as everyone knows.
As for your test. You should ping a public interface to check for
packetloss. The VPN can recover from some level of packetloss and hide
this from your ping session. You may see it as higher ping times.
Compare the results of the ping to local ISP default gateway, remote
site public interface and tunneled connection to remote router private
network. The larger packet sizes just seem better at exposing some
problems but are not always necessary.
--
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
|