Header Only - DO NOT REMOVE - Extreme Networks

Trouble disabling dot1p and Diffserv examination


Userlevel 5
Hi,

First response might be why!

The reason I want to do this (and hopefully I have my understanding correctly), is that I don't want to trust the QoS markings at layer 2 or 3 but instead be more precise about controlling the prioritisation of traffic through policy.

So in my case I have created a policy that looks at the RTP and Control traffic of Mitel IP phones and it is intended on putting that classified traffic into their respective queues.

It seems as though this is working, as I can observe traffic going into QP3 and QP6 via the show ports qos monitor command (see my policy config at bottom).

The problem I have is that I am also seeing traffic going into QP4 and QP5 as well, and I think it's the voice traffic based on its 802.1p marking.

So I've gone through the commands disabling dot1p and diffserv but in each case you get various messages and a reconfiguration of all the ports to 'enable diffserv replacement ports x.x qosprofile Qp6' etc

Some of the message are:
# After running command "disable diffserv replacement ports x:x"

WARNING: The diffserv replacement status was configured via network management which
requires dot1p replacement on all ports.

# After running command "unconfigure diffserv examination"

The below config is added to all the ports?!:

enable diffserv replacement ports 1:1 qosprofile QP6
enable diffserv replacement ports 1:2 qosprofile QP6
enable diffserv replacement ports 1:3 qosprofile QP6

# After running command "disable dot1p examination ports X:X" WARNING: The intended usage of this command is when another QoS traffic
grouping (e.g. diffserv examination, port QoS, vlan QoS, ACL QoS) is
configured. Disabling all QoS traffic groupings will still result in 802.1p QoS selection.

So it sounds as though that last statement is saying it will default to 802.1p QoS selection when all others are disabled, which might explain why I keep seeing traffic going into other queues even though I've removed all references of examination?!

Think I just need some clarity to help make sense of the messages, results and perfect what I would like to achieve.

Below is a copy of the policy configuration (which seems to work)... this is on a X450G2, Version 22.3.1.4

configure policy profile 11 name "Mitel Phones" pvid 4095

configure policy rule 11 udpsourceportIP 50000 mask 12 forward cos 6
configure policy rule 11 udpsourceportIP 50016 mask 11 forward cos 6
configure policy rule 11 udpsourceportIP 50048 mask 9 forward cos 6
configure policy rule 11 udpsourceportIP 50176 mask 10 forward cos 6
configure policy rule 11 udpsourceportIP 50240 mask 11 forward cos 6
configure policy rule 11 udpsourceportIP 50272 mask 14 forward cos 6
configure policy rule 11 udpsourceportIP 50276 mask 15 forward cos 6
configure policy rule 11 udpdestportIP 50000 mask 12 forward cos 6
configure policy rule 11 udpdestportIP 50016 mask 11 forward cos 6
configure policy rule 11 udpdestportIP 50048 mask 9 forward cos 6
configure policy rule 11 udpdestportIP 50176 mask 10 forward cos 6
configure policy rule 11 udpdestportIP 50240 mask 11 forward cos 6
configure policy rule 11 udpdestportIP 50272 mask 14 forward cos 6
configure policy rule 11 udpdestportIP 50276 mask 15 forward cos 6
configure policy rule 11 tcpsourceportIP 6900 mask 14 forward cos 3
configure policy rule 11 tcpsourceportIP 6904 mask 13 forward cos 3
configure policy rule 11 tcpsourceportIP 6912 mask 10 forward cos 3
configure policy rule 11 tcpsourceportIP 6976 mask 12 forward cos 3
configure policy rule 11 tcpsourceportIP 6992 mask 13 forward cos 3
configure policy rule 11 tcpdestportIP 6900 mask 14 forward cos 3
configure policy rule 11 tcpdestportIP 6904 mask 13 forward cos 3
configure policy rule 11 tcpdestportIP 6912 mask 10 forward cos 3
configure policy rule 11 tcpdestportIP 6976 mask 12 forward cos 3
configure policy rule 11 tcpdestportIP 6992 mask 13 forward cos 3

enable policy

Many thanks in advance

5 replies

Userlevel 6
Martin,

You are right, disabling dot1p and diffserv examination does not disable dot1p exam. You have to use some QoS traffic grouping, or it uses 802.1p examination.

You can try changing all the dot1p examination mappings to QP1. That could effect your policy configuration. I would try it, and see what you get.

Let us know what you find out.
Userlevel 5
Stephen Williams wrote:

Martin,

You are right, disabling dot1p and diffserv examination does not disable dot1p exam. You have to use some QoS traffic grouping, or it uses 802.1p examination.

You can try changing all the dot1p examination mappings to QP1. That could effect your policy configuration. I would try it, and see what you get.

Let us know what you find out.

Hi Steve,

Thanks for replying.... right, so that kind of explains it, that's also a good idea about the mapping, should have thought of that.

I'll give that a go and let you know how I get on.

Thanks.
Userlevel 5
Hi,

Been working on this quite a bit and it seems to be fighting me all the way. So I can enter the following commands on the switch:

configure dot1p type 1 qp1
configure dot1p type 2 qp1
configure dot1p type 3 qp1
configure dot1p type 4 qp1
configure dot1p type 5 qp1
configure dot1p type 6 qp1

I've not changed type 7, qp7 because this is used for control traffic - guess this is primarily why it is required to have some kind of QoS method, and not completely being able to turn it off.

I re-enabled dot1p examination, and disabled diffserv examination but I'm still seeing traffic going into queues 4 and 5, even though there is no policy defining those QoS profiles, differserv examination is turned off and I've remapped dot1p?!

The other problem I have with this is that policy is remapping everything back to how it was before i.e. it keeps adding the following config back on the switches:

configure dot1p type 0 qosprofile QP1 ingress-meter ingmeter0
configure dot1p type 1 qosprofile QP2 ingress-meter ingmeter1
configure dot1p type 2 qosprofile QP3 ingress-meter ingmeter2
configure dot1p type 3 qosprofile QP4 ingress-meter ingmeter3
configure dot1p type 4 qosprofile QP5 ingress-meter ingmeter4
configure dot1p type 5 qosprofile QP6 ingress-meter ingmeter5
configure dot1p type 6 qosprofile QP6 ingress-meter ingmeter6
configure dot1p type 7 qosprofile QP8 ingress-meter ingmeter7
configure diffserv replacement priority 6 code-point 46
configure cos-index 8 qosprofile QP4 replace-tos 64

Now I believe this is due to the CoS configuration in policy manager as per the image below:





The problem with this is the "802.1p Priority" section seems to be greyed out so I can't change the values, and if I change any of the Transmit Queue / TXQ index it complains its not support.

So I can't seem to find a way to change the values below in policy, and therefore write the changes on the switch I want:



Unlike EOS device it seems summit apply the 802.1p priority tag based on egress queue not the value specified in the CoS of Policy manager, and the policy manager still seems to be geared towards EOS as I can't find a way to configure it how I want in EXOS.

Not sure if you have any thoughts?
Userlevel 5
Finally worked out how to do this...

I have a full EXOS QoS implementation that is written in the command-line to do exactly what I want, part of that is setting all the dot1p values to use Qp1.

So to stop Extreme Control overwriting those values with its own, which is handy as there currently isn't the ability in Extreme Control / Management to do the finer configuration, is to simply turn-off the elements you don't need - as per the screenshot below:



With those radios disabled my EXOS QoS config now stays as I want it after an enforce.
Userlevel 5
I did hit some problems with disabling the CoS components and instead using command-line QoS. The sum of it was that when doing a policy enforce I would get the following error:

Unable to add TxQueue Port Groups to the device

In the logs it would say the following:

Contacting device [172.25.57.123]. ERROR : SNMP Error: Commit Failed (14). The attribute(s) contained in the failed SNMP packet were: etsysCosTxqPortGroupList.0.0 (FFFFFFFFFFFFF0000000000000000000FFFFFFFFFFFFE0000000000000000000FFFFFFFFFFFFF0), etsysCosTxqPortGroupName.0.0 (Default (TXQ.0))[/code]

So it looked to me that Extreme Management was still trying enforce TxQ configuration that was conflicting with the configuration I had entered and removed that Extreme Management had originally entered.

So went into the options and disabled:

Role-Based Rate Limits / TXQ Configuration

This should have stopped it working, which you do with the following:



Or



But when doing an enforce it was still causing the error. Then noticed the switches where still showing being set to 'Role-Based Rate Limits / TXQ Configuration'



So correct this this I had to delete the switch from Policy Manager and re-add it back in again. At which point it then changed to 'Rate Limit' - the enforce then worked as it no longer was trying to configure the TxQ Configuration.

The other option is to follow this article:

https://gtacknowledge.extremenetworks.com/articles/Solution/Policy-Enforce-to-XoS-switches-fails-wit...

Reply