We provide SIP service to our subscribers, using mangle rules and simple queues to identify and prioritize SIP traffic. Unfortunately, it looks like the wireless interfaces that connect various buildings are using fast-path, bypassing traffic prioritization and clobbering call quality. After making the following settings:
/ ip settings set allow-fast-path=no
/ interface bridge settings set allow-fast-path=no
the Ethernet and VLAN interfaces now indicate fast-path=no, but all the wireless interfaces still indicate fast-path=yes, and the “FP Rx” column in the Wireless Tables tab continues to show the same amount of traffic as the regular “Rx” column (i.e., inbound traffic on all wireless interfaces is being handled via fast-path).
Can someone help me figure out how to disable FP on wireless interfaces?
They’re all wireless-default (SFQ). I had only set up simple queues. After your question, I searched for more info. Though some of it may be very dated, I get the impression that simple queues are not sufficient to prioritize SIP. (If someone can explain why the obvious-looking solution doesn’t work, and why the warnings to that effect are so well-hidden, I’d appreciate it!)
I added an entry under / queue tree at both ends of a link, but there is a snag. Our wireless links are ap-to-ap using WDS. So the queue can’t name any of the ports as parents, just the WDS bridge interface. When I do that, the queues show traffic during a call, but the wireless interface, WDS interface and even the WDS bridge still indicate fast-path=yes, and the call quality doesn’t improve. What am I missing?
What you have to look at is fast track and not fast-path. Fast path works at the interface and is always good, as it means that the traffic passing via the interface is more efficiently processed. This is done at the driver level. Fast track, on the other hand, is a “shortcut” in the routing engine, which allow traffic to bypass some mechanisms when not needed. Among other things, packet contents do not get inspected and thus mangle does not work.
More experienced users can correct me on this, but I suspect that the only way to get around this is to stop using fast track altogether, by removing or disabling the fast track rule in filter section of the firewall. I don’t know whether there is some way to use it only for some traffic and not for other traffic.
We have no default rules. The first thing we do after a system reset is remove all default configurations, and start from scratch.
I bring up fast-path because the wireless interfaces all show the same rates in the “FP Rx” column as under the “Rx” column. If fast-path is indeed active, it is bypassing queues and defeating our attempts to prioritize SIP traffic–which would explain the call quality issues that prompted this investigation.
Follow-up: According to MT, when the output of / interface print detail indicates fast-path=yes for an interface, it doesn’t mean FastPath is active on that interface; only that the interface is capable of FastPath. The ambiguity is misleading. :-/