How to understand and culculate with a Meter on a 2920HP-Switch

[Tobias-hab]

Hello,

I try to use a Meter on one of my 2920HP-Switches. I have already one Flow "attached" to the following meter:

{
"version": "1.3.0",
"meter": {
"id": 1,
"flags": [
"kbps"
],
"bands": [
{
"burst_size": 1000,
"rate": 1000,
"mtype": "drop"porev 
},
{
"burst_size": 1000,
"rate": 100,
"mtype": "dscp_remark",
"prec_level": 1
}
]
}
}

I understand this two bands in the following way:

1 band: rate = 1000 = 1 000 000 bit/s = 125 000 byte/s,
mtype : drop = bandwith limitation to the limit of 125 000 byte/s.
I am not sure about the term burst_size. I can change this value to 0 or 10000 and nothing change. According to information from the internet: Time_Window = Burst_Size / Rate. For example Burst_Size = 1 000 000bit/s, Rate = 2 000 000bit/s -> Time_Window= 1 000 000 / 2 000 000 = 0.5. This means that is it allowed to send 1 000 000 bit (the burst_rate) within 0.5 seconds.  But as already mentioned the value burst_Size does not change anything on my HP2920 Switches (I tried different rates and time intervalls). How can I unerstand this value?

1 band: I send data with the ping command with different size and time interval from one client to an other client. There is a flow on this switch which matches and uses the given meter. I made some calculations based on the given parameters to  figure out whether the bandwith limitation works proberbly or not. Rate = 1 000 000 bit/s = 125 000 byte/s. So I guessed that the maximum Rate is 125 000 byte/s. But the limitation hits on ~ 15420 bytes. For a Rate or 250 000 byte/s the limitation hits on ~ 30890. As already mentioned I thought this has something to do with the burst_Size but I can change this value even to 0 and send my data in interval of 0.2 seconds or 30 seconds and this does not change anything. The limitation values are always the same 15420 or 30890 bytes.  I also noticed that 125 000 / 15420 or 250 000 / 30890 is almost 8. So I thought i misscalculated something with Bit and Byte. Maybe something happens what I am not aware of or I should know something else to calculate this right. What did I do wrong?

2 band:   I guess mtype: dscp-remark classifys the packets with level 1? In combination with Rate = 100 kbit/s this causes a guaranteed bandwith of 100kbits/s when I use this meter on a flow?  In addition the  "unknow" burst_rate makes it even more difficult for me to understand this. So, what effects does a band with rate = 100 kbit/s and dscp prec level 1 (or others) have on a flow?

Regards Tobias 

[Abhay_B]

Hello Tobias,

HPE Aruba switches don't support the burst_size parameter. Though it accepts meter bands with any burst_size value, it ignores the same when programming the meter is the hardware. Hope that clarifies why changing it didn't have an impact in your tests.

Regarding the rate limits, I see you have defined the meter type as kbps. So the meter will remark packets between the rates of 100 and 1000kbps and drop them above that.

The remark action will change the DSCP value in the packet by increasing its drop precendence to the value specified in the band definition. So you would see packets that hit this flow and triggered the remark action would have a new DSCP value in it.

Can you please clarify the ingress rates in your tests?

Also, can you please let us know the firmware version you are currently running on the switch.

Thanks!

Abhay

[Tobias-hab]

Hello Abhay,

Thanks for your information. I use the Version WB 16.04.0008 on my HP 2920-Switch. To generate the traffic I send PING commands of different sizes from one to an other client. The flow on the 2920-Switch matches this traffic and uses the above given meter.

I guess I do not understand the combination of the two bands. I thought this two bands are unattached to each other. As mentioned in the post before I guessed that the band with the mtype "drop" causes a strict bandwidth limitation at the rate of 1000 kbps. On the other hand I thought the band with the mtype "dscp_remark"  causes a guaranteed bandwidth of 100 kbps and has nothing to do with the bandwidth limitation.

You say now that these two bands belong together, matching rates between 100-1000 kbps, increasing its precedence level and drop them, is that right? During my tests I could not really confirm that, because it seemed for me some rates above 100 kbps where not blocked/dropped.

So let me try to clarify my ingress rates, setup and calculations. Please tell me if I do or understand something wrong. 

Rate = 100 - 1000 kilo bits per second = 100 000 - 1000 000 bits per second = 12 500 - 125 000 bytes per second. I think now this should stop rates from 12 500 - 125 000 bytes per second. To match this criteria I have the following flow on my switch attached to the meter from my post above:

{

"flow":{

"priority":50100,

"table_id":100,

"match":[

{"eth_type": "ipv4"},

{"ipv4_src": "192.168.59.10", "mask": "255.255.255.255"},

{"ipv4_dst": "192.168.58.10", "mask": "255.255.255.255"}],

"instructions":[{"apply_actions":[{"output":"NORMAL"}]},

{"meter":1}]

}

}

Now I send ICMP (PING) from 192.168.59.10 to 192.168.58.10 and my flow matches these packets. 

Rate = 100 - 1000 kbps = 12 500 - 125 000 Bps.

1. Test.  I send in always 1 second intervals from 10 - 15 418 bytes big pings and the limitation does not hit. 

2. Test. I send 15419 bytes big pings and I get about 75%  packet loss.

3. Test. I send 15420 bytes big pings and get 100% packet loss (It seems to me that the limitation hits here?)

4. Test. I also wanted to know what happend when I send with a rate above 125 000 Bps. Unfortunately the max size of ICMP is 2^16 = 655xx. So I enhanced the rate to 65 000 per 0.5 second = 130 000 per 1 second. But this does not work as mentioned in the earlier post. Even if I send a rate of 15 000 in 0.2 second intervals = 75 000 Bytes per second the limitation does not hit. So my assumption is that the intervals are not recognized and a limitation of 125 000 bytes per second is a limitation of 125 000 bytes at one packet?

I cannot really validate or understand this results so I tried to figure out something else, with the help of wireshark. As far as I know the Ethernet Frame has a max size of about 1500 bytes. And this is the only thing i recognized during my investigation. So in wireshark I saw that the 15 000 bytes big ICMP request is split up in 11 fragments. Having no idea what else to do, I just tried to make my packets smaller than 1500 byte. So I changed my Meter.

New Rate = 1 - 10 kbps = 125 - 1250 Bps.

5. Test. I send Ping from 10 - 1250 bytes  and I have 0 % packet loss:

6. Test. I send 1251 bytes big pings and packet loss beginns to start with 2-5%.

7. Test. I send even more bigger pings 1252-1500 bytes and the loss rate grows linearly.

8. Test. I send a 1501 byte big ping and I get 100% loss. The maximum limitation is therefore not 1250 (it begins there)  but 1500, the maximum size of the ethernet frame. I do not know why this happend, but this also showed that the minimum rate of 125 bytes per second doesent limitate anything, neither in this test nor in the other with 12 500 - 125 000 bytes. I also noticed that 1250 Bps (or here 1500 Bps) seems to be the maximum rate, which I can send. According to your answer I thought it might be possible to send with a higher throughput as the maximum bandwidth limitation, but this does not work obviously. 

9. Test. As far as I can see it, the limitation works here properly in any way. So I tried to figure out the issue with the unrecognized interval times:

I sent a 1250 byte big ping with intervall of 1 seconds and get about 0% packet loss.

I sent a 1250 byte big ping with interval of 0.5 seconds and get about 50% packet loss.

I sent a 1250 byte big ping with intervall of 0.25 seconds and get about 75% packet loss.

I sent a 1250 byte big ping with intervall of 0.2 seconds and get about 80% packet loss.

In conclusion it seems to me that the interval times are considered as long as the ethernet frame is smaller than 1500 bytes or in other words, if the ICMP-Ping has not to be fragmented?

Maybe I did not understand the combination of these two bands or something doesen't work fine. Can you explain me the behavior in my tests and why the limitation does not start with the low level cap (100  or 1 kbps). Due to your answer I even dont understand why the limitation does not stop at the maximum levels ( 1000 or 10 kpbs)?

Thanks a lot for your help!

Tobias