In this recipe, we will see how to measure the total bandwidth over a communication line. The first thing of course is to verify the communication line with the service provider. Check whether it is a symmetric or an asymmetric line, and if it is asymmetric, check what the bandwidth is in both directions.
There are two cases that you might need to test:
To check the bandwidth on a communication line, follow these steps:
When using a PC or laptop for the test, don't forget that the PC itself should be strong enough to generate the traffic. A standard Windows 7 is able to generate around 200 Mbps per TCP connection, and when opening several connections, you can get into other limitations such as disk performance and so on. Therefore, it is recommended to try the transfer first on a LAN, where there are no bandwidth limits (practically), and only then to test the SP or the ISP lines. If you are using FTP, use an efficient one (FileZilla, for example). The best way of course is to use test equipment, if it's available. Dedicated test equipments are available from many vendors such as VeEX, Fluke Networks, and IXIA.
In the following illustration, you can see two local networks connected via a Service Provider (SP) line. The site on the left is connected to the Internet through a firewall. The connection to the Internet goes through the Service Provider (SP, Server 4) to the Internet Service Provider (ISP, Server 5).
Follow these steps to measure the bandwidth over the communication lines:
Following are the steps to measure network bandwidth with IPerf:
When getting less bandwidth than expected, perform the following steps:
It isn't common, but it can also be that your service provider has a configuration problem. Check it with them. If none of the preceding cases are true, it can be that this is the reason.
First, there are two different definitions; it is important to distinguish between:
To check the bandwidth of a communication line, you can ask the service provider for the line details, or you can simply transfer some traffic over it, use Wireshark or SNMP tool, and see what you get.
Most of the cases in which a duplex mismatch problem occurs is when you connect using Ethernet on one side with 100 Mbps full duplex, and the other side configured to auto-negotiate.
As you see in the diagram, when you connect a device (a router in this example) to a switch, when both sides are manually configured, for example, to 100 Mbps Full Duplex (FDX), the intended configuration will take place (numbered 1 in the preceding diagram).
When you configure both sides to auto-negotiation (numbered 4 in the preceding diagram), it will also be fine, and will be automatically set to 1 Gbps (in the case of gigabit adapters).
In the case when one side is configured to 100 FDX and the other side to auto negotiate, the auto negotiate will be automatically set to 100 Mbps Half-Duplex (HDX). In this case, when one side is set to HD and the other to FD, many packets will be lost, and you will experience significant degradation in performance (numbered 2 and 3 in the preceding diagram).
When we buy a line at a certain bandwidth, it can be that we'll get a little bit more or less of what we've bought. For example, when we buy 10 Mbps line, and the line runs over the Synchronous Digital Hierarchy (SDH) or Synchronous Optical Network (SONet) line; the 10 Mbps is made of 5 VC-12s, which is 5*2.176 Mbps, so the total bandwidth will be 10.88 Mbps.
On the other hand if, for example, we use site-to-site VPN over the Internet, and the line is 10 Mbps, even if we have a very good Internet connection (for example, when the two ends are connected to the same ISP), the encryption mechanisms of the VPN itself can take 5 to 10 percent of the line, and when measuring it, you will get somewhere between 9.0 to 9.5 Mbps. In this case, for example, when you transfer a file over the line, you will see that the line is loaded with 10 Mbps (that is, the bandwidth), while what is left for the file copy is usually between 9.0 to 9.5 Mbps (that is, the throughput).
3.128.171.246