Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What is your favorite method to troubleshoot high-bandwidth/high latency networks?

133 views
Skip to first unread message

Spin

unread,
May 3, 2009, 11:04:23 PM5/3/09
to
Gurus,

What is your favorite method to troubleshoot high-bandwidth/high latency
networks? I know about the ping and telnet tests you can do, aside from
getting on the phone with the ISP, is there anything one can do from the
internal customer's side of the house in order to find the "smoking gun"?

--
Spin

Phillip Windell

unread,
May 4, 2009, 10:16:04 AM5/4/09
to
"Spin" <Sp...@invalid.com> wrote in message
news:7674g2F...@mid.individual.net...

I always look at the network infrastructure design,...the "topology" if you
want to call it that. Most of the time,..if they are designed correctly
they work correctly. Most network problems that I run across are caused by
the Admins and their bad designs. Of course the LAN and the WAN are two
different things and have to be investigated separately.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------


Spin

unread,
May 4, 2009, 2:05:03 PM5/4/09
to
"Phillip Windell" <philw...@hotmail.com> wrote in message
news:uflYVNMz...@TK2MSFTNGP03.phx.gbl...

> I always look at the network infrastructure design,...the "topology" if
> you want to call it that. Most of the time,..if they are designed
> correctly they work correctly. Most network problems that I run across
> are caused by the Admins and their bad designs. Of course the LAN and the
> WAN are two different things and have to be investigated separately.

It's difficult to get Verizon, AT&T and other major ISP players to divulge
their network infrastructure design and the type of equipment they use,
though not impossible if your considered a top tier customer. Getting some
engineer on the phone to help pinpoint an SLA problem is another story. I'm
so tired of spending night son the phone with service providers only to find
out the problem was caused by an admin or bad design. Happens a lot.
That's why I'm looking to develop a little checklist of "smoking guns" to
look for, a or at least put something together based on responses to this
thread in this NG.

Phillip Windell

unread,
May 4, 2009, 4:46:56 PM5/4/09
to
"Spin" <Sp...@invalid.com> wrote in message
news:768p8rF...@mid.individual.net...

> "Phillip Windell" <philw...@hotmail.com> wrote in message
> news:uflYVNMz...@TK2MSFTNGP03.phx.gbl...
>> I always look at the network infrastructure design,...the "topology" if
>> you want to call it that. Most of the time,..if they are designed
>> correctly they work correctly. Most network problems that I run across
>> are caused by the Admins and their bad designs. Of course the LAN and
>> the WAN are two different things and have to be investigated separately.
>
> It's difficult to get Verizon, AT&T and other major ISP players to divulge
> their network infrastructure design and the type of equipment they use,
> though not impossible if your considered a top tier customer. Getting
> some engineer on the phone to help pinpoint an SLA problem is another
> story. I'm

Yea,..that's why we use a local provider that I can hop in the car and drive
over there and grab them by the shirt if I have to.

> so tired of spending night son the phone with service providers only to
> find out the problem was caused by an admin or bad design. Happens a lot.
> That's why I'm looking to develop a little checklist of "smoking guns" to
> look for, a or at least put something together based on responses to this
> thread in this NG.

Well,...it's like I said before. The Internet performance and the LAN
performance have nothing to do with each other. The LAN can run perfectly
fine without the Internet,...like they did before the Interent ever came
along. By the same token the Internet connection can run perfectly fine
without the LAN, like it does with a home user with one machine and no LAN.

So you have to determine what it really is you are looking for. By your
post,...I cannot tell what it is. Is the LAN slow? Is the Internet
slow?,...they are not the same thing.

Spin

unread,
May 4, 2009, 4:55:35 PM5/4/09
to
"Phillip Windell" <philw...@hotmail.com> wrote in message
news:%23VYGwnP...@TK2MSFTNGP06.phx.gbl...

> Well,...it's like I said before. The Internet performance and the LAN
> performance have nothing to do with each other. The LAN can run perfectly
> fine without the Internet,...like they did before the Interent ever came
> along. By the same token the Internet connection can run perfectly fine
> without the LAN, like it does with a home user with one machine and no
> LAN.
>
> So you have to determine what it really is you are looking for. By your
> post,...I cannot tell what it is. Is the LAN slow? Is the Internet
> slow?,...they are not the same thing.

Well, consider the case of a dedicated site-to-site VPN, which is an
Internet technology designed to make remote networks "look" local. In this
case, we have a LAN which is really a WAN but made to look like a LAN.
These are the case for which I speak.

Phillip Windell

unread,
May 4, 2009, 5:14:27 PM5/4/09
to
"Spin" <Sp...@invalid.com> wrote in message
news:76938kF...@mid.individual.net...

> Well, consider the case of a dedicated site-to-site VPN, which is an
> Internet technology designed to make remote networks "look" local. In
> this case, we have a LAN which is really a WAN but made to look like a
> LAN. These are the case for which I speak.

In that case it is the Internet. The VPN Tunnel is not "real" it is an
imaginary thing,...a "logical" thing. So they are just "packets" going over
the Internet,..what is ecapsulated within them is not relevant. VPN by
nature is slower than regular Internet traffic for two reasons:

1. The required encapsulation and encryption has a cost in performance

2. VPN runs Synchronous (same speed both ways), so if the Internet
connection is Asynchronous (fast download, slow upload) then it is going to
run at the slower "upload" speed of the connection minus the protocol
overhead (mentioned in #1)and minus whatever bandwidth is already being used
up by other things.

So,...do some speed tests to see what you are dealing with. Anything less
that about 1,200 mbps is going to perform like crap (IMO).

One of the many speed test sites is http://www.speakeasy.net/speedtest

The next important thing to remember is that there are *two* Internet
connections involved with VPN,...one at each end,...it only takes one of
them to screw it up. It is only going to run at the slowest speed of the
slowest connection, minus the other bandwidth eating factors mentioned
above.

Spin

unread,
May 5, 2009, 9:12:29 AM5/5/09
to
How would I test the speed between two buildings which are in two
geographically separate cities in my site-to-site VPN network?

"Phillip Windell" <philw...@hotmail.com> wrote in message

news:uolNI3Pz...@TK2MSFTNGP06.phx.gbl...

Mathieu CHATEAU

unread,
May 5, 2009, 9:32:22 AM5/5/09
to
Hello,

Bandwidth perf: iperf (open source)
Latency: smokeping (open source)

just my 2 cents,

Spin a �crit :

Phillip Windell

unread,
May 5, 2009, 10:02:27 AM5/5/09
to
"Spin" <Sp...@invalid.com> wrote in message
news:76asggF...@mid.individual.net...

> How would I test the speed between two buildings which are in two
> geographically separate cities in my site-to-site VPN network?

Copy a file between the two and time it. Then do the math against the file
size.

Just remember that the file size is in Bytes and the bandwidth speed is in
Bits,...it takes 8 Bits to make a Byte.

So 100 mbps (bits) of line speed = 12.5 MBps (bytes)

So a file that is 25meg in size (bytes) should take two seconds over a 100
mbps line if the whole line's bandwidth is dedicated to the task. But in
"real life" nothing ever max's out the line during a transfer,...there is
*always* some left over bandwidth,...so it would really take more than two
seconds. Remember that if something used all the bandwidth for a single
action then only one thing (user?) could ever use the Line at one
time,...and we know that this is not how it works out in real
life,...multiple things happen over the line at the same time. So in the
end all you are going to get is a general idea of how well it is doing.

Anyone is welcomed to correct my "math" if I screwed it up. I tend to "poke
and eye out" with math if I'm not careful.

Phillip Windell

unread,
May 5, 2009, 10:22:04 AM5/5/09
to
Also keep in mind that Bandwidth is not the speed.
Thoughput is the speed.

To give a physical illustration of this:

Bandwidth = the number of lanes on a road moving in the same direction

Throughput = the speed limit that the road runs at

So a two lane road can move twice and many cars in the same amount of
time,...but both cars still move at the same speed. So if the road has two
lanes (same direction) with a 60mph limit, it does not mean that if there is
only one car on the road it can run a 120mph.

Spin

unread,
May 5, 2009, 5:55:30 PM5/5/09
to
And latency = heavy traffic / slow speeds.

"Phillip Windell" <philw...@hotmail.com> wrote in message

news:u$IkW1YzJ...@TK2MSFTNGP04.phx.gbl...

Phillip Windell

unread,
May 6, 2009, 4:42:54 PM5/6/09
to
"Spin" <Sp...@invalid.com> wrote in message
news:76br53F...@mid.individual.net...

> And latency = heavy traffic / slow speeds.

That would be packet delay (excessive transit time).

Latency is a "processing" thing. It is the time it takes for the packet to
be processed by a particular networking device before the packet is actually
dropped on the wire. So it would be like a car having to wait at a Red
Light before it can pull out onto the two-lane road. The primary cause of
Latency is too many LAN Routers or two many Switches between the end points
(too many traffic lights),...add the processing time of all the devices
together that is passes through and that is your latency time. A faulty or
over loaded Router or Switch can casue a spike in the latency. Another
example is the Application being used by the user taking too long, for
whatever reason, before it begins to communicate with whatever it
communicates with.

Mathieu CHATEAU

unread,
May 6, 2009, 5:01:50 PM5/6/09
to
latency is also the time needed for a packet to go from earth to the
satellite

also for the packet to go through the atlantic. Even fiber goes half the
speed of the light i think, so it needs some time under sea

Phillip Windell a �crit :

Phillip Windell

unread,
May 7, 2009, 11:22:13 AM5/7/09
to
"Mathieu CHATEAU" <goll...@free.fr> wrote in message
news:4a01fac0$0$27392$426a...@news.free.fr...

> latency is also the time needed for a packet to go from earth to the
> satellite
>
> also for the packet to go through the atlantic. Even fiber goes half the
> speed of the light i think, so it needs some time under sea
>

Years back when I went for my CCNA, Cisco was adament that these two things
were Lag-Time and Delay and specifically not Latency. It all seems like
splitting hairs and word-play to me,...but if we didn't answer it right, we
were counted wrong.

It was called Lag Time with the Satelite and was Delay (or Packet Delay, or
Transit Delay) when running over a long cable. With the Satelite the
Latency was the lost time between the Transceiver receiving the packet and
when it sent the packet up,...the second Latency was the time lost between
the Satelite receiving the packet and resending the packet back down,...and
then again at the Tranceiver at the end.

Anyway to me sometimes it is just splitting hairs, but we had to keep it
straight for the exams. I do though try to use proper terminology as best I
know to do since the IT industry is already in a "terminology crisis" over
misused and abused terminology, particularly since the growth of "home user
networking". Examples of that are calling cheap SOHO NAT-Firewalls
"routers" when they are not routers,...and inventing the term "port
forwarding" when the ports are not even the focus of the "action",..it's
really a focus on the IP# and the process is primarily a Layer3 process, not
a Layer4 process, and the real name that has long since been establish for
the process by the industry for years is "Static NAT" or "Reverse-NAT".
There was never a need to invent a new "word".

Dave Warren

unread,
May 7, 2009, 3:08:39 PM5/7/09
to
In message <OirvHeyz...@TK2MSFTNGP03.phx.gbl> "Phillip Windell"

<philw...@hotmail.com> was claimed to have wrote:

>Examples of that are calling cheap SOHO NAT-Firewalls
>"routers" when they are not routers,...and inventing the term "port
>forwarding" when the ports are not even the focus of the "action",..it's
>really a focus on the IP# and the process is primarily a Layer3 process, not
>a Layer4 process, and the real name that has long since been establish for
>the process by the industry for years is "Static NAT" or "Reverse-NAT".
>There was never a need to invent a new "word".

And "DMZ" -- What a bastardization of concepts that one is, since what
most SOHO gear calls a DMZ is all but the opposite of a real DMZ.

Phillip Windell

unread,
May 7, 2009, 4:04:08 PM5/7/09
to
"Dave Warren" <dave-...@djwcomputers.com> wrote in message
news:vta605hoegqtk8gdg...@4ax.com...

AH! Yea!! I forgot about that one! I think that one is from Linksys. I
think what it really is, is a 1:1 NAT directly to whatever IP you tell it.
How in the world they ever came up with DMZ for that one!?! It is almost
like they just grab a "popular" word off the shelf and just use it for
whatever trips their trigger regaurdless of what it really means.

What couldn't they just "make up" a new word!?!,....like a
"dischronificator address" of something instead of a term that already has
an establshed meaning,....of course I'd still complain about that too...

The really sad thing is that they were bought by Cisco,...who is highly
responsible for the proper meaning of a lot of industry terminology,...yet
they have not even attempted to correct that blatant non-sense. What's
wrong with them?,..they asleep?

0 new messages