cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Port based rate limiting on ERS switches

TCP Port based rate limiting on ERS switches

alexplante
New Contributor

Hi all,

 

We’re running in this issue where we have an ERS4548 connected to some servers but all interfaces are running at 1G full capacity. We were investigating a slow throughput issue where some file transfer would take forever. 

By investigating the traffic flows, we determined it was some backup traffic, going over our production network, which was starving all the other traffic. The first thing to come to everyone’s mind would be, why the hell are they running backup on the prod network. Truth is, we can only do that at the moment till the servers folks fix their thing.

To mitigate the impact, I thought I would rate limit the backup flows to a certain level, dropping anything above. I can’t do it on the port itself, because the port going to the “backup server” is actually a port to an hypervisor with multiple VMs, so it really has to be with either IP, or preferable DST port.

So my question is, how would you set up QoS to rate limit flows based on TCP DST port on an ERS4548 ? If I can shape it just as you would do at the port level, that be the ideal.

Thanks !

1 REPLY 1

alexplante
New Contributor

Just figured it out. There may be other ways to do it, but here’s what I did in case other would like to know how:

  1. Define an interface group and assign ports to it. This is the ports where you will apply your QoS policy
  2. Define an ip-element to classify only TCP traffic (protocol #6 in your IP header) and define the port range. In my case, I only had one port, so dst-port-min is the same as dst-port-max
  3. Define a classifier that contains your ip-elements.
  4. Create a mater with your desired
    1. commited rate :Specifies rate that traffic must not exceed for extended periods to be considered in-profile
    2. and burst-rate
      1. In-profile action means what to do with the traffic when it is within the boundaries. Action 2 is, by default, threating the traffic as Standard
      2. Out-profile action is what to do with the traffic once out of the limits. In this case, I want it to drop (Action #1, as defined by default)
  5. Create a  QoS policy and assign
    1. Your interface group
    2. Your classifier
    3. Your meter
    4. Desired precedence over other QoS rules

! *** QOS ***

qos if-group name "Int_group_2" class untrusted

qos meter 1 name meter1 committed-rate 1000 burst-size 512 in-profile-action 2 out-profile-action 1

qos ip-element 1 name dsClfr1 protocol 6 dst-port-min 5201 dst-port-max 5201

qos classifier 1 set-id 1 name c1 element-type ip element-id 1

qos if-assign port 1-2 name Int_group_2

qos policy 1 name iperf if-group "Int_group_2" clfr-type classifier clfr-id 1 meter 1 precedence 3

 

After applying the commands, I ran 2 tests. One iperf3 test on port 5201 (the port I wanted to throttle), and another one on another port which I don’t want to throttle, port 4000. The tests were successful. I did change the committed-rate a few times and the iperf3 tests were all representative of the adjusted committed-rate.

 

eb6bd30c4b5d4b03b87353cb53d10e60_fc3dbc76-06d1-4d69-a886-52710433d793.png

Iperf3 results on throttled TCP port 5201
eb6bd30c4b5d4b03b87353cb53d10e60_3bdae894-6ae0-4425-aeaf-b2863befc1d7.png
Iperf3 results on un-throttled TCP port 4000

 

GTM-P2G8KFN