Header Only - DO NOT REMOVE - Extreme Networks

Rate Limiting traffic on S series Switch

Userlevel 5
Hi community I am currently testing some rate limiting on a S series switch. The idea is to rate limit all traffic on a specific port to 200 Mbps. To test the rate limit I have a Iperf Server connected to a 1Gbps port and a client PC connects to the "200 Mbps Rate limited" port For a benchmark we first run the iperf test with out and rate limit applied. Both the server and the client is connected to a 1Gbps port. The iperf results indicate almost 900Mbps throughput. When I apply my 200Mbps policy to the port, iperf reslut goes down to 3Mbps, The COS config on the switch is as follows: # Chassis Firmware Revision: ! # cos port-config ! # cos port-resource set cos port-resource irl 0.1 0 unit mbps rate 200 set cos port-resource orl 0.1 0 unit mbps rate 200 ! # cos reference set cos reference irl 0.1 8 rate-limit 0 set cos reference orl 0.1 0 rate-limit 0 ! # cos settings set cos settings 8 priority 1 txq-reference 8 irl-reference 8 orl-reference 0 ! # cos state set cos state enable ! # cos syslog ! End The Cos is then applied to the port using a Policy # policy set policy profile 1 name "SmartCape Bandwidth Limit" pvid-status enable pvid 4095 cos-status enable cos 8 set policy rule admin-profile port ge.1.9 mask 16 port-string ge.1.9 admin-pid 1 I have played with various settings, from 100Mbps to 500Mbps but I do not see the speeds that I expect. I have also tried to set the rate limit to 20% of the port but this also give me 3Mbps. Anything that I am missing here? Thx

2 replies

Userlevel 7
Hi Andre,

without even looking at the switch configuration I have to ask how you are using iperf. The "almost 900Gbps throughput" suggest you are using TCP. The TCP protocol will react to dropped packets by reducing the rate.

You should use iperf in UDP mode to test rate limiting, because in this mode iperf will just send a constant stream of packets at a specified rate.

You should still check that the UDP packets fit inside the MTU to avoid fragmentation. One dropped fragment results in a completely dropped UDP packet. That can create unexpected measuring results.

Best regards,
Userlevel 4
You can also take the approach of avoiding the use of Inbound Rate Limiting (IRL) and/or Outbound Rate Limiting (ORL), using only Outbound Rate Shaping (TXQ) - which is compatible with both UDP and TCP traffic.

See Hub KB 11667, "Inbound Rate Limiting is Overly Restrictive to TCP/IP".