QoS markings for auto anchor (EoIP)

[Johannes Luther]

Hi there,

does anybody know, how the outer IP header of the EoIP tunnel for guest anchor mobility is marked (DSCP)?

I didn't find any document about this:

Possible options (from my point of view):

• DSCP 0 --> QoS is not considered
• DSCP of EoIP packet is derived by the actual user IP packet
• If the wireless user is sending an IP packet, which is marked with for example DSCP 46 then the EoIP IP header is marked with DSCP 46 as well
• DSCP of EoIP packet is derived by the CAPWAP DSCP
• DSCP of EoIP packet is derived / translated by the layer-2 802.11e UP marking from the wireless client (mapping table)

Anybody has an idea?

Cheers

Johannes

[Freerk Terpstra]

Based on the documentation only the control traffic between the controllers can be configured with a specific DSCP value. The EoIP traffic does not contain any markings when it leaves the WLC. I did not lab this up myself (I don't have two controllers right now), but if you can please do so and use a SPAN port to look at the traffic to verify. Don't forget to let us know what your findings are.

Please rate useful posts... :-)

[Johannes Luther]

Hi Freerk,

thank you for the answer. I'm sorry to say, that I don't believe you without any documentation reference or lab test results :).

I'm in the same situation here. I have access to a remote lab, but the old "remotelabwireless" problem is, I don't have a proper WLAN client. Furthermore the span cabling is missing as well.

I thought there are tons of answers over the last weekend and I don't have to set it up myself :)

Perhaps someone stumbles over this post until I set up the lab.

So, let's assume the data traffic is not marked according to the encapsulated traffic. This means that anchored SSIDs are not really end-to-end QoS - so not suitable for voice deployments. There are cases where EoIP is sent over a WAN connection, which is a potential bottleneck.

Keep you posted.

[Freerk Terpstra · Accepted solution]

Hi Johannes,

I don't know if you tested this yourself in the meantime, but I was still curious and had two controllers available for testing today.. :-) Turned out that I was wrong in my previous statement and that the EoIP "data/user" traffic is actually being marked!

Traffic from anchor towards the foreign controller
Based on the DSCP marking of the original packet the EoIP traffic is being marked. If the marking of the original packet is higher than the value allowed within the QoS profile, the highest value allowed within that QoS profile will be used for the EoIP traffic.

You can find the evidence in the trace below in which you see the EoIP traffic between the anchor (10.1.10.2) and foreign (10.1.10.1) WLC during a "ping" between a wired and wireless end-point. In this test the WLAN had the video QoS profile configured on both controllers explaining the AF41 marking on the EoIP traffic.



Traffic from foreign towards the anchor controller
Here it gets a little weird. Because both controllers use the exact same configured QoS profile on the WLAN I was expecting the same behavior for the "return traffic". However, for some reason the DSCP value of the original packet seems to be used no matter the configured QoS profile (?)



If the original traffic from the wireless client did not have a marking also the EoIP traffic had no marking. This behavior might be a bug, but it occurs with both 8.0.121.0 and 8.3.102.0 versions of AirOS code.

Please rate useful posts... :-)

[Rasika Nayanajith]

Thanks Freek for spending time on this and provide a great response.

[Johannes Luther]

Hi Freerk,

you're right - I didn't have the chance to test it. However I start a PoC this week and will test it as well. Thanks for sharing this - great job!

[Freerk Terpstra]

Hi Johannes,

I'm wondering, did you discover the same behavior? If so, do we already have an bug id? ;-)

[Johannes Luther]

Hi Freerk,

Last week I finally had the chance to test this in a 5508 8.2.141.0 test series. And tested this with various DSCP markings and QoS profile level combinations.

However, I used the feature "trust-dscp-upstream", because otherwise most of the markings vom Windows based systems are messed up in CAPWAP*. But I don't think this has an impact on the whole anchor situation.

Also I did not really check the wired 802.1p CoS values by PoP'ed packets, because typically I only consider DSCP markings on the wired switch platforms (trust DSCP / DSCP match and set class-maps)

So here are my results

Upstream (from WLAN client) with enabled "trust-dscp-upstream"

1. The DSCP value of the original packet is copied to the outer CAPWAP header. (Caution: trust-dscp-upstream behavior)
2. The packet is CAPWAP descapsulated (internally) at the foreign WLC. The foreign WLC encapsulated the packet again in EoIP and copies the DSCP value of the original packet to the outer EoIP IP header.
3. Packet is descapsulated at the anchor. The original DSCP value is maintained.

Downstream (to WLAN client)

1. The DSCP value of the original packet (wired client) is copied to the outer EoIP header with the QoS profile configuration as a high-threshold. If for example the QoS profile is Gold, but the original packet has a DSCP marking of EF (46), then the outer EoIP header would be marked with AF41 (34).
2. The packet is EoIP descapsulated (internally) at the foreign WLC. The foreign WLC encapsulated the packet again in CAPWAP and copies the DSCP value of the original packet to the outer CAPWAP IPv4 header with the QoS profile configuration as a high-threshold.
3. The packet is CAPWAP descapsulated by the AP. The AP adds an 802.11e marking to the frame, derived (translated) by the CAPWAP IPv4 header DSCP marking with the QoS profile configuration as a high-threshold.

You're right, in the downstream direction, the anchor WLC does not consider the max. QoS profile configuration for the EoIP DSCP marking. The original DSCP value is "trusted" independent of the QoS profile level.

However this exactely matches the behavior if trust-dscp-upstream is used in the upstream direction :)

I don't know if it is a bug - it's a certain behavior you have to know :) By the way - I'm not on the customer side and do not own equipment. Even if I want I could not open a bug :)

Anyway. Great discussion. Thank you for sharing your knowledge and participating in this discussion.

(*) The 802.11e layer-2 markings in Windows are based on the wired QoS baseline model. So EF is marked with an 802.11e of 5 instead of 6.

Bye

Joe

[Johannes Luther]

Hi Freerk,

I guess we might hit this:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva95251