Queue mangle rules update


#1

Been reading a topic on a Sonar Slack forum about trying to improve CPU use on Mikrotiks when using the address list mangle rules Sonar recommends when doing queues. One suggestion was to only mark “new” connections and connections with “no-mark” by adding the following to the mangle mark connection command:

connection-mark=no-mark connection-state=new

Any thoughts on why this would be a bad idea to add to the prerouting chain to mark connections?


#2

No, I think that makes sense. I don’t know if checking a connection for a mark is going to do anything though, especially if you’re already only checking new ones. Will have to be tested to see if it is a measurable positive impact. Making sure it’s only bound to one interface is the biggest gain, so make sure you have that too. Let me know how much this helps, if it’s worthwhile I can add it to the rule generator.


#3

The redundancy of “no-mark” and “new” make sense - maybe one or the other.

As far as using interfaces, I get the importance of this and it works fine at our mini-pop towers where we use a dedicated interface for WAN and the AP but at some of our edge routers, we have a LAN Bridge for the LAN side and 2 WAN ports to two different providers. This happens at our larger towers. How do you handle specifying an interface when you have 2 WAN interfaces? Is the only solution to put a second router at the tower for the APs and dedicate an edge router to to just edge / BGP?


#4

There isn’t really a one size fits all answer. If you can use a bridge interface and the CPU load is low enough, then it’s OK. In a larger network I’d say yes, have a dedicated shaping router(s) rather than trying to do BGP, NAT, shaping, etc, all on one box.