03-26-2020 12:22 AM
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 !
03-26-2020 08:43 PM
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:
! *** 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.