06-02-2016 02:13 AM - edited 03-05-2019 04:08 AM
Hello,
I have a question regarding srr-queue bandwidth limit 30 command. We have applied it to a switch port connected to one of our servers in site B. This server receives traffic from a remote server located over the VPN in different location, lets say A.
Before we applied this command on the switchport on site B we had a bandwidth saturation inside the VPN tunnel. After configuring this command the bandwidth is working as expected, but I dont understand how this limits the bandwidth all way down from A to B.
As far as I understand, this command limits the bandwidth from switch port to the server. So, if sending server at site A still sending 100Mbs, it will reach site B switch at 100 Mbs and only on this switch the shaping will take place to limit it to 30, am I correct?
Or, the switch and the server on site B negotiate the speed of the port to set it 30 and the server on site B somehow lets server A know that it can only receive 30?
Taking into account that this command successfully shaped the traffic from A to B, I assume the second option (negotiation) is in place, wondering how this negotiation is performed
Thank you
Solved! Go to Solution.
06-03-2016 06:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Shaping generally causes the sender to "perceive" a bottleneck, as if there was an actual bandwidth reduction along the path. (This assuming you're dealing with a rate adaptive protocol.)
How exactly the sending source adjusts its transmission rate depends on the protocol being used. For example, original TCP pushes faster and faster until it sees packet drops (assumed to be caused by congestion) and halves it transmission rate then slowly pushes faster and faster again until again is sees drops. Newer TCP implementations may closely monitor RTT and if they see a jump in latency, they assume there's congestion and react as if there were a packet drop.
06-02-2016 05:01 PM
The switch just transmits the data more slowly on the port to achieve the desired speed. Basically it increases the delay between transmitting each packet. The server will be unaware of this.
06-03-2016 06:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Shaping generally causes the sender to "perceive" a bottleneck, as if there was an actual bandwidth reduction along the path. (This assuming you're dealing with a rate adaptive protocol.)
How exactly the sending source adjusts its transmission rate depends on the protocol being used. For example, original TCP pushes faster and faster until it sees packet drops (assumed to be caused by congestion) and halves it transmission rate then slowly pushes faster and faster again until again is sees drops. Newer TCP implementations may closely monitor RTT and if they see a jump in latency, they assume there's congestion and react as if there were a packet drop.
06-03-2016 07:03 AM
Thank you, Joseph!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide