<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic RE: Rate Limiting traffic on S series Switch in ExtremeSwitching (EOS)</title>
    <link>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57843#M1173</link>
    <description>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.&lt;BR /&gt;
&lt;BR /&gt;
See Hub KB 11667, "&lt;A href="https://community.extremenetworks.com/extreme/topics/inbound_rate_limiting_is_overly_restrictive_to_tcp_ip" target="_blank" rel="nofollow noreferrer noopener"&gt;Inbound Rate Limiting is Overly Restrictive to TCP/IP&lt;/A&gt;".</description>
    <pubDate>Fri, 14 Oct 2016 23:46:00 GMT</pubDate>
    <dc:creator>Paul_Poyant</dc:creator>
    <dc:date>2016-10-14T23:46:00Z</dc:date>
    <item>
      <title>Rate Limiting traffic on S series Switch</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57841#M1171</link>
      <description>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:  08.61.02.0002  !  # 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</description>
      <pubDate>Mon, 19 Sep 2016 14:58:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57841#M1171</guid>
      <dc:creator>Andre_Brits_Kan</dc:creator>
      <dc:date>2016-09-19T14:58:00Z</dc:date>
    </item>
    <item>
      <title>RE: Rate Limiting traffic on S series Switch</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57842#M1172</link>
      <description>Hi Andre,&lt;BR /&gt;
&lt;BR /&gt;
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.&lt;BR /&gt;
&lt;BR /&gt;
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.&lt;BR /&gt;
&lt;BR /&gt;
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.&lt;BR /&gt;
&lt;BR /&gt;
Best regards,&lt;BR /&gt;
Erik</description>
      <pubDate>Tue, 20 Sep 2016 13:15:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57842#M1172</guid>
      <dc:creator>Erik_Auerswald</dc:creator>
      <dc:date>2016-09-20T13:15:00Z</dc:date>
    </item>
    <item>
      <title>RE: Rate Limiting traffic on S series Switch</title>
      <link>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57843#M1173</link>
      <description>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.&lt;BR /&gt;
&lt;BR /&gt;
See Hub KB 11667, "&lt;A href="https://community.extremenetworks.com/extreme/topics/inbound_rate_limiting_is_overly_restrictive_to_tcp_ip" target="_blank" rel="nofollow noreferrer noopener"&gt;Inbound Rate Limiting is Overly Restrictive to TCP/IP&lt;/A&gt;".</description>
      <pubDate>Fri, 14 Oct 2016 23:46:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremeswitching-eos/rate-limiting-traffic-on-s-series-switch/m-p/57843#M1173</guid>
      <dc:creator>Paul_Poyant</dc:creator>
      <dc:date>2016-10-14T23:46:00Z</dc:date>
    </item>
  </channel>
</rss>

