QoS trust boundary

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
Hi all,

I've read lots of manuals and configuration guides and tutorials, yet things are not yet really very clear as far as the big picture is concerned.

So, I need some advice concerning QoS and how to use on EOS gear. We have Bs and Cs at the edge, DFEs in the distribution, and 7100 in the core. Essentially we plan to introduce a little VoIP but I'd like to keep the discussion general.

So when QoS comes into play you usually define a trust boundary which obviously is at the edge. How would that look like on EOS?

As far as I understand, the switches simply trust a packet with a 802.1p/q PCP set (0-7) and assign it to the corresponding queue. --> Does this mean there is a prerequisite for NAC / strong endpoint security here?

It would already be an advantage if you could tell the devices not to trust any such priority at all at the edge except for certain VLANs (like VoIP phones, which have limited access to the Call Server anyway).

How do you do this in real life?

Photo of jeronimo


  • 1,290 Points 1k badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of Erik Auerswald

Erik Auerswald, Embassador

  • 13,636 Points 10k badge 2x thumb
Hi Marki,

the EOS devices trust incoming frames by default, thus the trust boundary is at the end-system by default. To change this you can use a policy to set the QoS markings you want, e.g. 0 for most of the traffic and 5 / EF for VoIP.

There are a couple of GTAC Knowledge articles pertaining to your question:
Best regards,
Photo of jeronimo


  • 1,290 Points 1k badge 2x thumb

Doesn't anyone think that just trusting everything incoming is a problem? If asked, everyone suggests to indeed define policies if you don't like it, but there are no examples of a really secure config. So let me give one later.

I've seen all the referenced documents but the problem here is, there is so much info but no canonical reference that would be self-explanatory (including CLI and configuration guides).

It starts with "CoS" not actually meaning the 802.1p header, but the Class-of-service system implemented in the switches, including CoS "priority", ToS and the mapping between both. I highly recommend to everyone to initially get a grip on the nomenclature used!

As for the promised example, the following basically trusts an IP network (in our case the IP phones), since these can only talk to the callserver through our firewall.

For edge ports:
# reset everything to CoS/ToS 0 ...
set policy profile 1 name "TrustNoOneAndPriorityForVoIP" cos-status enable cos 0
# ... except for VoIP phones
set policy rule 1 ipsourcesocket mask 16 cos 5
# apply the previous policy to all user ports but do NOT apply to uplink ports, those should be trusted anyway!
set policy port ge.*.1-46 1
# map CoS 0 to ToS 0: since the policy profile above sets CoS to 0 for unknown traffic, this has the effect of resetting any incoming DSCP to 0 as a consequence
set cos settings 0 tos-value 0
# also map CoS 5 to ToS 184 (Note: This has the general effect of applying a DSCP value 184 to all tagged traffic with an 802.1p priority of 5 on that switch.) This can be useful when there are layer 3 devices (like a firewall) in the data path which evaluate ToS/DSCP but not CoS
set cos settings 5 tos-value 184
# enable the CoS system in the switch to actually perform the defined mappings
set cos state enable
For uplink ports:(the call server's replies)
# for uplink ports: 
set policy profile 2 name "UplinkMapToS"
# map incoming ToS 184 to CoS, since CoS is the only thing that matters to the switch
set policy rule 2 iptos 184 mask 8 cos 5
# apply to uplinks
set policy port ge.*.48 2
# (if not already set) map ToS->CoS: incoming ToS (no CoS) on uplink will set CoS 5 in 802.1p header
set cos settings 5 tos-value 184
set cos state enable

Tests that I carried out:
  • Phone which already sets CoS and ToS: remapped to 0 if no policy rule defined
  • Phone which sets no CoS and/or no ToS: if in the specified IP network, CoS and ToS will be set by the switch
  • --> In other words: no matter what the phone sets it will be rewritten to the CoS specified in the policy (and to ToS specific in "cos settings"). All other traffic will be set to CoS 0. That is what I call having your QoS under control.
BTW I also tried to match traffic based on VLAN but it didn't do anything, that's why I started using IP networks.

set policy profile 2 name "PriorityForVoIP" cos-status enable cos 5
set policy rule admin-profile vlantag 123 admin-pid 2


PS: Using "pre" to display code here sucks because it doesn't create blocks of code but each line becomes a single line of code.