Header Only - DO NOT REMOVE - Extreme Networks

Unable to force port/vlan/ipnet to cos on 7100-Series (8.42)


Userlevel 2
Hi,

Our firewall cannot set 802.1p priority, only DSCP. Since the switches consider 802.1p for classification we must match traffic on the switch and set the appropriate priority somehow:
1) by port
2) by IP address/network
3) map ToS 184 to Cos 5 generally
4) .... ? (feel free to comment)

Neither of these approaches work. We do not see the 802.1p priority being set on the egress port.

This is what we tried:

set policy profile 1 name PrioToVoIP cos-status enable cos 5
set policy rule admin-profile port ge.2.35 mask 16 port-string ge.2.35 admin-pid 1

We also tried all of:
set policy rule 1 ipdestsocket 172.16.0.0 mask 16 cos 5 (the destination network of Callserver-->phones)
set policy rule 1 iptos 184 mask 8 cos 5
set cos settings 5 tos-value 184.0
set cos state enable

Note: Port ge.2.35 is the port receiving the output traffic of the firewall (tagged vlans).

When I capture (port mirror) the egress port (in this case ge.2.41) neither of them shows the 802.1p prio properly set. I tried Remote GRE mirror and local port mirror.

PBX ----> Firewall ----------> ge.2.35 -- Switch -- ge.2.41 -------> ......

I found this: https://gtacknowledge.extremenetworks.com/articles/Solution/CoS-not-working-as-expected-on-SSA-runni...
Could this be related?

Anyone have an idea?

Thanks,
Marki

PS: QoS is pain.

5 replies

Userlevel 4
Marki,

I went and looked up the bug that is associated with that article. While it has not been resolved it involves internal queue management,buffering, and internal handling of traffic between chips on the board. And reading into this it seems to me to be a rare event.

It seems to me that you are looking to see if the Priority bits in the 802.1Q tag are being set. Which I don't think this configuration will do. To alter the tag you need to use TCIoverwrite functionality to write the correct bits into the priority field.
Userlevel 2
Daniel Coughlin wrote:

Marki,

I went and looked up the bug that is associated with that article. While it has not been resolved it involves internal queue management,buffering, and internal handling of traffic between chips on the board. And reading into this it seems to me to be a rare event.

It seems to me that you are looking to see if the Priority bits in the 802.1Q tag are being set. Which I don't think this configuration will do. To alter the tag you need to use TCIoverwrite functionality to write the correct bits into the priority field.

Hmm, I don't think the 7100s have TCI overwrite capability. Neither do our B5s, but a configuration similar to this is working nevertheless on that platform...
Userlevel 2
Daniel Coughlin wrote:

Marki,

I went and looked up the bug that is associated with that article. While it has not been resolved it involves internal queue management,buffering, and internal handling of traffic between chips on the board. And reading into this it seems to me to be a rare event.

It seems to me that you are looking to see if the Priority bits in the 802.1Q tag are being set. Which I don't think this configuration will do. To alter the tag you need to use TCIoverwrite functionality to write the correct bits into the priority field.

Correction: Looking at the docs shows that tci-overwrite is always enabled on 7100-Series and cannot be disabled. When trying to set to enabled nevertheless in a policy, I lost the connection to the connected device. Will have to check that.
Userlevel 4
Daniel Coughlin wrote:

Marki,

I went and looked up the bug that is associated with that article. While it has not been resolved it involves internal queue management,buffering, and internal handling of traffic between chips on the board. And reading into this it seems to me to be a rare event.

It seems to me that you are looking to see if the Priority bits in the 802.1Q tag are being set. Which I don't think this configuration will do. To alter the tag you need to use TCIoverwrite functionality to write the correct bits into the priority field.

I overlooked that this was 7100 and was thinking in terms of s/k. The issue previously mentioned was S specific.
Userlevel 2
Daniel Coughlin wrote:

Marki,

I went and looked up the bug that is associated with that article. While it has not been resolved it involves internal queue management,buffering, and internal handling of traffic between chips on the board. And reading into this it seems to me to be a rare event.

It seems to me that you are looking to see if the Priority bits in the 802.1Q tag are being set. Which I don't think this configuration will do. To alter the tag you need to use TCIoverwrite functionality to write the correct bits into the priority field.

Hmm, so we don't know much more right know why this isn't working or why tci-overwrite enable drops traffic: Indeed I tried "set policy profile ..... tci-overwrite enable", which simply has the effect that the traffic in question is not forwarded at all anymore (applies only to tagged traffic, no influence on untagged traffic, since no TCI there I guess)

Reply