This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Extreme Networks
- Community List
- Technical Discussions
- Network Architecture & Design
- QoS trust boundary
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
QoS trust boundary
QoS trust boundary
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
10-13-2016 06:36 AM
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?
BFN,
Marki
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?
BFN,
Marki
2 REPLIES 2
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
10-15-2016 02:02 PM
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:
Erik
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:
- How To Priortize All Traffic in a VLAN by Setting the P-Bit on Securestack and S-Series
- How To Configure Policy to Mark Voice/video/data with specific Markings on Securestack and S-Series
- Example Policy to apply cos to prioritise different traffic types
- S-Series Quality of Service for VoIP Traffic marked as DSCP Override (AF41)
- Prioritizing ShoreTel Connect VoIP traffic on SecureStacks
Erik
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
10-15-2016 02:02 PM
Hi,
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 172.16.0.0 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 enableFor 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:
set policy profile 2 name "PriorityForVoIP" cos-status enable cos 5 set policy rule admin-profile vlantag 123 admin-pid 2
Bye,
Marki
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.
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 172.16.0.0 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 enableFor 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.
set policy profile 2 name "PriorityForVoIP" cos-status enable cos 5 set policy rule admin-profile vlantag 123 admin-pid 2
Bye,
Marki
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.
