Using connection-rate to mark traffic with DSCP values

RouterOS General
1

Hello,

Currently have a CCR1072 to be used as an Aggregation Router/BNG for termination of GFast DSL services using IPoE.

We have a 10G transport network connecting to buildings where the GFast services are provided (FTTB then GFast over copper).

I’d like to implement a CIR/EIR arrangement using ‘limit-at’ and ‘max-limit’ so that we can offer varying CIR services to guarantee a certain amount of bandwidth to our customers. An example service would be a 250Mbps/250Mbps plan with say a 25Mbps CIR and 250Mbps PIR so that under extreme congestion 25Mbps is guaranteed to be available.

This is currently possible on Mikrotik as long as the downstream interface is the congestion point either by max port capacity (10G) or by a configured shaping limit applied to the parent queue. I will use limit-at and max-limit to provide limit-at (CIR) priority when the 10G interface experiences 100% utilisation (spikes/peaks etc).

In addition I need to be able to mark the CIR (limit-at) traffic with DSCP=34 to identify this traffic as Business CIR traffic and then prioritise at other points of the network which have less bandwidth and can then ensure the CIR traffic is delivered. The EIR traffic (traffic above CIR but below PIR) will be forwarded unmarked.

To achieve this I am trying to use the mangle feature ‘connection-rate’ to identify the CIR traffic and then mark it with DSCP34.

Operation for say 250M/250M with CIR 25M/25M would be like:

  • mangle connection marking rule using connection-rate to identify 0-25M of traffic
  • mangle packet-mark to match the above connection rule
  • any traffic matching this packet-mark is then marked with DSCP=34 using the action=change-dscp rule
  • any traffic not matching is set with DSCP=0 (below config does not include this)

I’m having a number of issues getting this working trying various configs, initially I was able to mark the first 90 packets of a 1Mbps test traffic flow then no marking for remain 400 odd packets when CIR=512k. More reading and testing and I’ve got what looks like the best config although now all packets are being marked with DSCP34.

The below config is what I have to date, am focusing on getting the DSCP marking side working right now, once this is proved I can move onto the queuing side.

5 - chain=forward action=mark-connection new-connection-mark=all-connections connection-mark=!mark-cir-100.64.10.250-conn
6 - chain=forward action=mark-connection new-connection-mark=mark-cir-100.64.10.250-conn passthrough=no protocol=tcp dst-address=100.64.10.250 connection-mark=all-connections connection rate=0-1M
7 - chain=forward action=mark-packet new-packet-mark=mark-cir-100.64.10.250-packet passthrough=no connection-mark=mark-cir-100.64.10.250-conn
8 - chain=forward action=mark-packet new-packet-mark=non-cir-traffic passthrough=no connection-mark=all-connections
9 - chain=postrouting action=change-dscp new-dscp=46 passthrough=no packet-mark=mark-cir-100.64.10.250-packet

When I do a 2Mbps TCP download, below are the stats I see. I would expect a 50/50 split of CIR matching vs EIR matching but this is not the case. Currently all packets are being marked with DSCP34.

I believe connection-rate measures both up and down traffic but the packets marked still don’t match.

Rules 1-4 are disabled.

																bytes              packets
5    forward                                                                      mark-connection                  23 102             392
6    forward                                                                      mark-connection                     156               3
7    forward                                                                      mark-packet                   5 324 904           4 496
8    forward                                                                      mark-packet                      22 946             389
9    postrouting                                                                change-dscp                   5 324 904           4 496

Any suggestions on whether this configuration is correct or any suggested changes to get this working? I have upgraded to the latest software.

Appreciate any advice and thanks in advance.

Regards,
Roger

2

Hi those in the know, any suggestions on this issue?

Thanks.

3

I’m not sure I understand your intention properly, but you’ve created a one-way trap. As soon as a connection’s rate ever drops below 1 Mbps during a second, it gets the connection-mark mark-cir-100.64.10.250-conn and never loses it any more, as the rule assigning the other connection-mark only acts if connection-mark mark-cir-100.64.10.250-conn is not assigned.

Besides, you have prevented packets with lower connection-rate than 1 Mbps from ever being assigned a packet mark, as there is passthrough=no in the rule No. 6, and no match condition restricting that rule only to packets belonging to connections without any connection-mark. So assigning the connection-mark mark-cir-100.64.10.250-conn to packets matching connection-rate=0-1M is the last action in the prerouting chain of mangle for them.

I also strongly suspect you have missed the role of the connection-mark. One of the purposes of connection-mark is to reduce the number of match conditions necessary to choose a packet for actions like mark-routing, mark-packet, change-dscp by evaluating the complex match conditions only for the first packet of the connection and storing the result, in the form of a connection-mark, in the context data of the connection, so every subsequent packet belonging to that connection could inherit this connection-mark as it is being handled by the connection tracking module, before entering the rest of the firewall. So you don’t need to re-assign the connection-mark “manually” to every single packet, it is enough to do that once, for the first packet, and then only if you need to re-classify the whole connection (e.g. because it has already transported more than N bytes so it is not to be considered a delay-critical one any more, so it can be slowed down to give way to more interactive services).

On the other hand, it is not mandatory that a rule assigning a packet-mark would match on the connection-mark=something condition - it can match on any other conditions instead.

So in my understanding, you can simply assign the packet-mark “don’t slow me down” to all packets which match on connection-rate=0-1M, and assign the packet-mark “only let me through if there is still some bandwidth left” to the rest. Hence all packets of connections whose rate doesn’t exceed 1M will not be affected, and those packets of the connections which exceed the limit in a given second of the connection’s lifetime will become candidates for dropping.

Next, the queues (in /queue tree, not “simple” queues) only look at packet-mark, not at the DSCP header field, whereas the downstream equipment never receives the packet-mark, so the only way to convey the information about priority to it is via the header fields of the “physical” packet, which is the DSCP field in the IP header and also the Priority field in the VLAN header and something similar in the wireless header (WMM).

So if you need queueing/prioritisation in both the Mikrotik and the downstream device(s), you must assign the packet-mark (or DSCP) value using one rule with passthrough=yes, and then use another rule (which can be with passthrough=no if there is nothing else to be done with these packets) which will assign the other field’s value based on the first one’s one (DSCP based on packet-mark or vice versa).

If not for the need to inform the downstream equipment, you could assign the packet-mark alone and the queues would do the rest of the task, as they enforce both the guaranteed rate and maximum rate limits. I suspect that doing the same using mangle rules watching connection-rate is much more CPU-intensive.

Last point, you have to test yourself, but if you have a look at the output of /ip firewall connection print detail, you’ll see that the connection context contains two separate values, orig-rate and repl-rate. So I strongly suspect that connection-rate matches on just one of them, depending on the packets role in that connection (orig = from client (initiator) to server (responder), repl = in the opposite direction).

4

Thanks Sindy for your feedback, has given me a few things to think about.

I think it’s just clicked for me in regards to connection-marks, a single connection-mark rule will identify the traffic which can then be used by packet-marks to break that traffic down into a more specific packet-mark, such as connection-rate=0-1M.

I also see that the connection-rate measure may be reporting individual connection rates (bandwidth) rather than the overall bandwidth of a specific customer service, this may explain some of the results I’ve been seeing during testing.

My intention with this config is to create a 2 rate 3 colour (2R3C) traffic policer/shaper and marker within RouterOS so that packets meeting the Committed Information Rate (CIR) are marked with a specific DSCP value.

In RouterOS I can’t see a way to apply a DSCP marking for traffic meeting ‘limit-at’, this is the problem I am trying to solve. I understand I can use Mikrotik to manage limit-at and max-limit traffic but I need the DSCP markings to be applied to outbound packets so I can manage the CIR bandwidth elsewhere in my network.

Regards,
Roger

5

This is a good link that explains two-rate three colour marking.

https://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=007831&lang=EN