Wireless Access

Anyone have some ideas on how to do QOS over a Mesh link using AOS 6.x?    

We have some wired IP phones at the far end I want to prioritize their traffic over the mesh link.  We are using AP-104's using the 5Ghz radio for meshing.

All i can think of is to put the eth 0 port into a bridge mode and assign it a role where I am prioritizing traffic within the user role.   Wired  IP phones do not show up as clients on the controller, I have the eth0 port currently set as trusted, in a tunnel mode, with the port configured as a trunk port.   If i used some kind of QOS within a user role, would this prioritization come across over the mesh link?  If not, what about specifically prioritizing the traffic over the air, across the mesh link?

I cannot find anything in the VRD's or previous posts about how to accomplish this.

Thanks.

I made the eth 0 port on the AP104 untrusted and applied a specific  user role to the wired IP phones and wrote some QOS rules inside of that user role to priotize the phone traffic.

Will that QOS info be carried over the air, in the mesh link? or do i need to do some other type of prioritization over the mesh link to ensure the qos tagging is making it across the link.    I still have the eth0 port configured in trunk / tunnel mode.  Not being on-site i am hesitant to change the eth0 port to bridge mode. 

Sure.Here are the few data points and best practices that I would recommend.

By default, Enbaling WMM on SSID-pofile on the controller will automatically prioritize the traffic on the air.
Aruba controller firewall is capable of doing deep inspection of voice protocols and prioritze them automatically.

On controller, by default we have the configuration of DSCP mapping of 46 and 6 which is still configurable from ssid-profile according to requirement.

Few commands to controller to check for WMM markings. Find below

show ap debug system-status ap-name <name of the ap>
show ap debug client-stats <client- mac address>
show ap debug radio-stats ap-name <name of the ap> radiO 0/1 advanced | include WMM

Enable wwm from SSID-profile, select any upper UNII band channels like 149,161 or 153 as a back-haul and check for RSSI over the mesh link.Configure and prioritize the QOS traffic on the user-role so that any incoming traffic to the controller will have DSCP markings and traffic prioritization.

show datapath session table | include <call-server ip address>
show datapath session table | include <client-ip addres>

From your comments, I understand back-haul is on "a" radio. Things that we need to keep in mind while implemention QOS for mesh here.

1. Type of antenna we use and it`s antenna gain
2. Distance between mesh links and how good is the LOS (Line of sight between them)
3. RSSI on the mesh link.
4. Type of application or protocol used in the network for QOs.
5. Bandwidth & throughput we get on the wired-side.
6. Latency to reach the call-server from wired-side.
7. Type of phones/application that will be used on the network.
8. Make sure you set the max power on the phones and disable power-save on the phone for beter performance.
9. Configure the Encryption type WPA2-PSK between mesh link so that we could avoid any packet-corruption over the air.
10. Enable HT with 40 MHZ on the controller (Enabled by default)

Since we are going to user wired phones; try to compare the latency and QOS markings on the wired-side first to measure and understand how is the performance on wired-side and QOS/DSCP markings done on the wired-side. By this way we could optimize the config on the controller to get the END-END QOS delivery with better performance.

Always make sure link quality and RSSI is always good say for example with min of RSSI "40" and link qulaity of "70%" to have a good performance.

show ap mesh topology
show ap mesh neighbours

Above commands will help us to understan RSSI and link quality across the mesh.

I have also attached Voice & QOS VRD implementation and best practice on the Aruba controller.

Please let me know if have any questions specifics on above theory or on VRD that we could help you.

Hope this help you to have a good start.

Thank you.

Attachment(s)

VoiceSupportAppNote_2011-11-14.pdf   785 KB 1 version

Thanks for the detailed reply.

Not sure enabling WMM on SSID profile will be any benefit as there are no wireless clients doing voice.    The Mesh SSID does not have any WMM options I am aware of.  My Mesh SSID does not have a typical ssid profile, unless you recommend creating a SSID profile with the same name as my Mesh SSID name, though i do not see how that would work from a WMM level as I won't be doing any client wireless traffic on my mesh SSID .   Is there a specific way to do QOS over the mesh link on the 5G band that is not handling  wireless clients?

We have 4 wired IP phones that are at a remote building across the mesh link doing voice.  Those are the only voice clients that operate over any part of the Aruba network.

The RSSI over the mesh link changes a bit.  I have seen it operate anywhere from 13-28 in the last couple days.  I am using a UNII band of channel 157+ statically configured.   The speed of the link seems like its constantly changing and does not want to stay the same.   Doing the show ap mesh neighbors ap-name <ap-name> command, I see it running at 135/125 one second, and then 85/15, the next second.   Then it will go back up to 135/125, and a second later, it will be 21/54, and then back up to 150/121, seconds later.   All of this going on while the RSSI is consistently between 26-29 over the mesh link.  Is there a way to try to stablize the link so its not bouncing around the data rates so much like this?  Or do i need a higher RSSI of 35-40+ to accomplish this?

Not sure if it impacts the mesh link, but we are using the 2.4 radio on these AP104's to handle clients as well, though the max number of clients i usually see on these APs are 2 at most.

the mesh link is approx 150ft in length, using Aruba ANT-2X2-D607 on both sides with near perfect LOS. (might be a couple narrow power lines running perpendicular to each other), but for the most part,  fairly clear LOS.   Power levels are running at max level of 28 dbm

Got that. My data points and specification was both wired and wireless. Anyway, for our issue we may need to focus more on RSSI & link-quality. We could try different channels to see for any improvement. Check for antenna alignement /gain/best practice config to have a better RSSI.

Thank you.

I know super old post. Did you ever get an answer to your actual question? As QoS/DSCP packets enter the Ethernet interface on the Portal or Point, are they honored and mapped to WMM values across your MESH Link?

My situation is a Football stadium with a saturated P-to-P MESH link. I want to prioritize certain traffic that is properly marking DSCP EF on the wired side. 

To my knowledge, specific to the mesh, there's no WMM or QoS marking honor in terms of backhaul. 

Thanks. I also opened a TAC case they have confirmed no QoS on Backhaul. 

---

@airhead1234 wrote:

Thanks. I also opened a TAC case they have confirmed no QoS on Backhaul. 

---

I think that is incorrect. QOS is honored by mesh links by way of 802.11e and the default dscp-to-AC mapping. Packets are sent from mesh portal to mesh point or vice versa using the same WMM QOS mechanism as a client connected to an AP. 

A mesh point is essentially a client and if it's associated with 802.11n or better then WMM is by default enabled.

You can prove this by inspecting the radio debug stats and checking for increments of the WMM tx/rx counters while generating some sort of dscp tagged traffic.

(7005) # show ap debug radio-stats ap-name ap92-portal radio 0 advanced | include WMM
Tx WMM [BE]                         30342
Tx WMM [VI]                         1186           <<<
Tx WMM [VO]                         20             <<<

(7005) # show ap debug radio-stats ap-name ap92-portal radio 0 advanced | include WMM
Tx WMM [BE]                         31997
Tx WMM [VI]                         1554            <<<<
Tx WMM [VO]                         31              <<<<

A quick wireless packet capture will show QOS headers are present and non zero values of TID in the capture when dscp is set set, see attached for some AP92 portal talking to an AP109 mesh point, there is some random qos marked traffic going over a trusted bridged ethernet wired-ap-port

TL;DR; yes, mesh honors qos for trusted and untrusted enet port backhaul, primarily by way of dscp tagging and 802.11e WMM

This looks correct but conflicts with the answer I got back from engineering on this. I will see if I can run this down in the near future to see if this is configurable or if it's just taking the defaults. 

---

@jhoward wrote:

This looks correct but conflicts with the answer I got back from engineering on this. I will see if I can run this down in the near future to see if this is configurable or if it's just taking the defaults. 

---

the plot thickens - on the air interface the packets are sent correctly marked with QOS, but on further checking, i can see there are no RX stats for WMM tagged frames, e.g. here are two halves of the mesh link

(7005) #show ap debug radio-stats ap-name ap109-point radio 0 advanced | include WMM
Tx WMM [BE]                         102873
Tx WMM [VI]                         103005

(7005) #show ap debug radio-stats ap-name ap92-portal radio 0 advanced | include WMM
Tx WMM [BK]                         2202
Tx WMM [BE]                         639802
Tx WMM [VI]                         203193
Tx WMM [VO]                         2403

so... it sems when transmitting the QOS is maintained, but the "rx wmm to dscp marking" is not working. Typically on a campus AP no matter the DSCP of the packet, if the traffic arrives with TID=7 then the traffic should be marked with the dscp value for voice.

The QOS is being maintained over the air however - seems to be some sort of quirk about how the BSS tunnels work for wired ports. For what it's worth, i tested with trusted tunnel, untrusted tunnel and bridge (always trusted) mode wired ap ports, with tagged frames the QOS is being used on the air, just doesn't show up in the radio stats at the ap (which makes me wonder if the statement that qos doesnt work correctly is more about that if a frame is sent with a specific QOS but not a specific DSCP (e.g. queue high) it wont get it's dscp updated on the way out.

@Jerrod - let us know what you find when you have a moment

Nice analysis! There is no better way to prove techology then by actually testing it and monitoring and dubuging behavior. 

I thought it odd that backhaul wouldnt support QoS. Makes more sense that it does. 

Thanks Dugem2016!