Hi Rane ,does iperf command supported by Cisco switches like 3650 etc.
HI Rene,
We are making some test of bandwidth with IPERF.
I have two links of dark fiber connected to a Cisco OADM 8A. It is supposed that I have 20Gbps I made some test with IPERF with different windows size but it just gaves me like 0.44 Gbits/sec.
Does IPERF is telling me that I dont have the bandwidth I supossed to have?
iperf.pdf (161.9 KB)
Hello Vinod
iperf is a utility that runs on Linux, Unix and Windows operating systems. It is not a command that is actually implemented on a Cisco device itself. In the lesson, the iperf command was implemented on the Client and Server devices, which were PCs.
I hope this has been helpful!
Laz
Hello Helen
Because youâre using a high speed link, I suggest you try various values for the window starting with 128000, and keep doubling until you get a maximum throughput. A window size of 128000 is typical to maximise throughput on a gigabit link, so itâs a good start. Specifically, test out the following window sizes:
128000
256000
512000
1024000
2048000
4096000
8192000
etcâŚ
For each window size, record the throughput. When you reach a maximum value of throughput, that is the maximum throughput that you can expect from the link.
If it is different than what you expect, you should then begin troubleshooting other issues. Let us know what results you get.
I hope this has been helpful!
Laz
Hi Lazaros, thank you for your reply.
I made a bandwith test with differents windows sizes and I get just 3.5Gbps but when I add the -P (number of parralel clients) with different windows size I get 8.6Mbps of bandwidth.
Now Im more confuse I dont know how many bandwidth does my link really has.iperf-windowssize.pdf (637.5 KB)
Hello Helen
Can you set up a different test without iperf? Try setting up an FTP client and an FTP server, one on each end of the link. Place a large file (several gigabytes if possible) and try to transfer it from server to client and see what kinds of speeds you get. This is a real world example, so it might more accurately state your linkâs speeds. If speed is still limited you may find that there is an issue with your cabling or your terminations. Check out the error rates on the interfaces on both ends to see if that may be the culprit.
You can find large files to use for your tests by searching Google and typing âlarge test files to downloadâ. Several sites have 1 and 10 GB test files that you can use. You will need to first download such a file to your server and then test the FTP transfer from server to client.
Let us know your results!
I hope this has been helpful!
Laz
I was thinking the same until saw Reneâs Post
2 Likes
Hi Rene,
how do we manually change the TCP window size on Windows 10 PC? and how? is there a command we can enter in command line?
Kind regards,
John
Hello John
Each program that runs on a Windows 10 computer creates TCP sessions has its own mechanisms to create and change its window size. However, you can adjust these parameters using the Set-NetTCPSetting command on the Power Shell. You can find out more information about this at the following link:
I hope this has been helpful!
Laz
Hi Rene,
Iâve got a question about maximum bandwidth speed.
The company I work for have a Layer 2 Ethernet circuit connecting our HQ to our DR site. This is a 1Gbps link and thatâs also our Committed Information Rate (CIR). However, today my colleague was testing if we actually get 1Gbps speed between our HQ and DR site. He transferred a 1GB file from a PC in HQ site to a PC in DR site. When we saw the bandwidth speed on SolarWinds for the link it was only using 49Mbps when its actually a 1Gbps link. Note this is a small company that consists of only 30 employees and the link is not utilised much.
A point to also mention is that we have GRE Tunnel with IPSec encryption running over this link, so we adjusted the ip mtu to 1400 and tcp mss value to 1360 under the tunnel interface. Can these values limit the maximum bandwidth we can achieve?
Also, we are using 1Gbps everywhere on the network; PC NICS, Switches, routers, Cat5e cables, etc.
Iâve read online about this and some have mentioned this can be caused by the hard drive speed on the receiving computer.
Would really appreciate if you can shed some light on issues like this, Iâve seen this many times where you are not achieving anywhere near the maximum bandwidth whether on the LAN or WAN but I donât know exactly where to start.
Is there anyway of testing the maximum bandwidth on the link via IP SLA? I know you can test the RTT value with IP SLA Responder configuration.
Many Thanks
Akhas
Hello Akhas
This is an excellent question, and it really highlights all of the parameters that are involved in an end to end communication that can affect the throughput of data.
Things that can affect this particular communication include:
- The application being used to transfer the files. Remember that when sending data using the SMB or FTP protocols, TCP is being used. This means that the receiver can regulate the flow of data using TCP flow control mechanisms. If the receiver canât handle the speed (due to application, bandwidth, or hardware limitations) it will request that the sender slow down sending, which will ultimately reduce the throughput. This is also highly dependant on the operating system being used and how it manages the various TCP sessions.
- QoS policing and shaping parameters that are configured at various parts of your and the ISPâs network.
- Other traffic that may be on the network at the time.
- Overhead from tunnelling protocols.
- Method of measurement used by solar winds (are you sure itâs 49 Mbps and not 49 MBps?)
Now I know that you have taken many of these into consideration, as you mention in your post, but I am mentioning them here for completeness.
In order to remove such factors from the equation, my suggestion would be to use an IP SLA traffic generator as you mention in your post. More info can be found here:
Configure the generator on a device as close as possible to the ISP edge (possibly your edge router) and the responder also as close as possible to the network edge of your DR site. This way you eliminate the passage of traffic on your internal network which may also affect the result.
Next make sure to use UDP for the transmission so that you donât involve any flow control that may limit the transmission.
Finally, use several measuring techniques, including both your solar winds monitoring system as well as using a policy map on the network devices using an access list as described in the above linked lesson. That way you can verify (or not) the measurements being taken by the monitoring system.
I hope this has been helpful!
Laz
Hi Laz,
Thanks for the answer, very clear explanation.
Yes I double checked the speed, it was only 49Mbps. Iâve been busy with other projects and hence was unable to implement and test what youâve suggested. However, I will try scheduling a maintenance window next week sometime to so this.
1 Like
Hello Akhas
That sounds great. Iâd be interested to find out your results and see what you get! Looking forward to it!
Laz
Hi Rene,
I am getting a little bit confused here.
As you stated in the last lesson âTCP window size scalingâ that window size is the size of receive buffer. And it tells the sender how much data it can transmit before the receiver will send ACK.
So according to this the amount of data that can be transferred depends on the window size of receiver. But in this lesson you stated âdata is transferred from the server to the client so you can ignore the default TCP window size for the clientâ.
Shouldnât we take the window size of client into consideration? Could you please clear my doubt.
Warm Regards,
Tanya
Hello Tanya
When talking about âwindowsâ in TCP itâs important to specify that there are several definitions. First, we have the window which is described in the TCP Window Size Scaling lesson. This is called the receive window and itâs purpose is to prevent the receiver from being overwhelmed with data, resulting in lost data. It is maintained by the receiver, and its value is sent to the sender within the acknowledgements. The sender will adjust the window size, which is the maximum number of bytes it can send before receiving an ACK.
But there is another window involved in the TCP process, and this is the congestion window. This is actually maintained by the sender. This window is a way of preventing a link from being overloaded with too much traffic, and it is determined by estimating how much congestion there is on the link.
A sender will use both the congestion window, and the receive window to determine how much data it can send at any one time.
For the specific example in the lesson, you can see that the TCP window size on the client (the receive window) is 85.0 KByte, while the TCP window size on the server (congestion window) is 15.6 KByte. Since the congestion window size is smaller than the receive window size, the receive window size can be ignored. Or in other words, it will not play a role in limiting traffic in this particular case.
As the congestion window size is increased, the throughput increases as well. When this happens, the receive window size still says 85.0 KByte (default) but this may be renegotiated during transfer, and the traffic is able to increase further.
Keep in mind that CCNA and even CCNP certification exams do not touch much upon the details about TCP windows, and this is why the distinction is not made between the congestion and receive windows. Only the receive window is actually covered in detail in the topics of the exams.
I hope this has been helpful!
Laz
1 Like
Thank you Laz. It was really helpful.
1 Like
How the delay is being calculated on the link ??
Hello Narad
The bandwidth delay product is not something that is automatically detected and adjusted by a network. This is something that you must manually calculate in order to determine the nature of the link in question, so that you can apply the appropriate configuration parameters to maximize performance. In order to determine the delay of a link so that you can calculate the BDP, you can use a simple ping just like Rene did in the lesson. Using a Linux device, he determined the minimum, average, and maximum round trip delays, and used that information to determine the BDP.
I hope this has been helpful!
Laz