QoS Trust boundaries

[fabio.marino]

Hi to all,

i'm Fabio and i'm preparing the CCNP exam switch module.

I'm studying the VoIp chapter and i'm fighting wiht the QoS Boundary Concept.

I understood tha i can have three diferrent tyoe of QoS defined:

-CoS for layer 2 data (Frame)

-IP Precedence: old L3 QoS management

-DSCP: new L3 QoS management

Based on these basic concept i'm not able to undserstand what a qos trust boundary is.

Reading i got that: whenever a packet arrives to the edge boundary, its QoS can be untrusted and the edge switch can overwrite the QoS of the incoming packet using the QoS policy adopted inside teh QoS Trust Boundary. On the contary, QoS of packets transmitted inside  the trust boundary is not modified ("trusted").

I need the get the basic concept. Is it correct what i write?

Thanks a lot, Fabio.

[Shashank Singh]

Hi Fabio,

Trust boundary is the interface where the marking on a packet is trusted. Beyond this interface, the packet is said to cross the trust boundary and the marking on the packet (cos for layer2 frame, dscp for layer 3 packet) is used to decide the QoS for that packet.

Before this interface, the marking on the packet is ignored and no QoS is applied.

Hope this helps,

Shashank

Please rate if you found the content useful

[fabio.marino]

Thanks, so my idea was right.

In the case of an Ip-phone, for example we can have:

-an interface connect to an host PC

-an interface connect to a catalyst switch

I understood that, due to best practice, ip-phone and switch "reside" inside the same trust boundary, whereas the PC is outside the trust boundary, so as soon as the ip-phone receive data from PC, it has to overwritte the QoS of incoming packet. Which QoS value the Ip-phone will assign to the packet? (for example, in the case of DSCP: AF31 or AF 32 or AF33 and so on)This decision is based on some parameters?

[Shashank Singh · Accepted solution]

Hi Fabio,

Generally IP Phones assign dscp of EF (46) to voice traffic. This is a convention to avoid incompatibility issues among vendors.

You rated previous answer 1/5 with thanks ... Not sure if you found it good or bad

Cheers,

Shashank

[tharinduko@millenniumitesp.com]

Hi,

Can i know the what are  QOS trust boundaries are and how they work??

[Joseph W. Doherty]

Simply, all QoS markings within a trust boundary are considered to be accurate, in that there's no need to analyze the frame/packet to determine if its QoS marking conforms to policy. In other words, all devices within the boundary "trust" the QoS marking.

Frames/packets crossing a trust boundary are often subject to analysis to confirm their QoS marking conform to policy. If not, the QoS marking is generally changed (or the frame/packet might be dropped).

Consider a trust boundary akin to passing through an international customs stations.

[fabio.marino]

Thanks Shashank,

your response was not bad but, based on my request, my doubts were not resolved by you, especially about the term used by Cisco of "trusted", "untrusted", this is the reasons of my rate. Follow i can explain more deep what i'm looking for.

Using a DiffServ QoS service model and a per-interface trust modes applied to a boundary switch, i got that:

-trusted port  receiving L2/L3 traffic can map QoS from CoS/IP precedence to DSCP

-untrusted port can map QoS to class 0 (??) or using tha QoS policy adopted inside the trust boundary. This sentence, tha i got from the CCNP Cisco book, is not clear and in general is not clear what the definition "trusted", "untrusted" mean.

For example, you wrote that in the case of VoIP traffic, a fix Code point name is used, but this is true for all switch that receive VoIP traffic? I think no, you have to differentiate from trusted port and untrusted port. Based on this i think you can decide with DSCP Code point name you can use, eventually, to map the QoS of the received packet.

From the CCNP Cisco book (switch) , "QoS value are "trusted(??what really mean??)" if they are considered to represent the type of traffic and precedence processing taht the traffic should receive at the trust bounbdary. If untrusted, the traffic is marked with a new QoS value taht is approrpiate for the policy that is in place at the point where the traffic enters the campus network"

So Shashank, i hope now is clear for you what are my doubt?

Thanks a lot for your time and for our discussion that i think can help someone to get tha basic QoS concept, like me.

ps: is clear Shashank that i would want to continue our discussion but i wrong to mark it as "With response", was my fault.

[Shashank Singh]

Hi Fabio,

I am not sure if calling a port trusted or untrusted makes any sense. Technically speaking, traffic entering a port can be either trusted(trusted port ) by the port or untrusted by the port.

When we say that traffic entering a port is trusted, we mean that we trust the marking (cos/dscp/ip-precedence) already present on the traffic, and this marking is used to decide the QoS for this traffic. By default all the ports are untrusted. A port becomes trusted if it is configured with "mls qos trust cos/dscp/ip-precedence".

If we do not trust the marking on the ingress traffic, we do not configure "mls qos trust ***" on the ingress interface. Such a port where the marking of the incoming traffic is not trusted, is called untrusted port.

When a traffic enters an untrusted port, the switch generally remarks the packet with another value. Remarking implies changing the cos/dscp/ip-precedence value. This value is 0 by default.

Sometimes we wish to mark the ingress traffic with a value, different from what it already comes in with. In such cases also we do not trust the marking on the incoming packet. We configure policy maps on the ingress interface which classify (separate) the desired traffic and remark them accordingly. Generally "set dscp xyz" or "set cos **" is used in the policy maps to achieve this.

QoS value are "trusted(??what really mean??)" if they are considered to represent the type of traffic and precedence processing taht the traffic should receive at the trust bounbdary. If untrusted, the traffic is marked with a new QoS value taht is approrpiate for the policy that is in place at the point where the traffic enters the campus network"

It makes sense to trust the QoS values or markings on the ingress traffic (cos/dscp/ip-precedence) , if they correctly depict the class of the traffic. For eg, voice traffic is supposed to have dscp 46 to ensure proper prioritization. It makes sense to trust a voice packet if it is marked with dscp 46 and it does not make sense to trust it if it is marked with say dscp 16.

In other words, if the marking is appropriate, we trust it blindly but in case it is incorrectly marked or we wish to remark it to some other value we do not trust the marking and make it go through a custom configured policy on the switch, which remarks the traffic.

Trust boundary is just a conceptual term. If you have three routers in a network connected as daisy chain and you have configured mls qos trust *** on the middle router, trust boundary lies on that middle router. In this case, router on one end will lie outside the trust boundary and that on the other end inside the trust boundary.

<----------outside trust boundary---->     <-----inside trust boundary---->

traffic source---->rtr1------------------->rtr2-------------------->rtr3--------------->traffic destination

                                          mls qos trust

Hope this helps clarify some of your doubts. Feel free to post if you have more of them & rate accordingly if you find the answers helpful

Shashank

[ChrisSporer62644]

Hi Shashank,

this information about trusted boundaries is very valuable for me. I am not an admin for CISCO networks but a supplier for a custom made telephony system. A first trial in the field has failed due to heavy congestion on a 2Mbit/s E1 link. Thus I want to point the admin in a direction to solve the problem in a quick and simple way for the next field trial.

I can set the DSCP value in the IP header of my units to EF.
The problem was how to make the router trust this DSCP value.


If I got you correctly the admin has to set the ingress interface to be trusted?

(config-if)#mls qos trust dscp

(config)#class-map efclass

(config-cmap)#match ip dscp 46

(config)#policy-map ef_priority

(config-pmap)#class efclass
(config-pmap-c)#bandwdth 64

-Could that be the correct sequence to prioritize voice with tags set to EF from the external source?
-Presently all traffic is handled as "best effort". I suppose that the non-tagged traffic is still passing as best effort with this configuration?
- This configuration is for the two edge routers on the E1 link (that is leased from a mobile telephone operator)
- The mobile operator has two intermediate routers in between the edge routers. I suppose he has to make the same configuration for the two nodes? (Perhaps he can ommit the trust command?)

Thank you in advance
Chris

[Joseph W. Doherty]

First, older Cisco switches, by default, if QoS enabled, didn't trust ingress traffic's QoS markings. Newer Cisco switches, by default, if QoS enabled, not trust ingress traffic's QoS markings. BTW, Cisco routers, by default, have pretty much always trusted ingress traffic's QoS markings, but also by default, don't provide any QoS treatment. Cisco switches, with QoS disabled, also by default, don't provide any QoS treatment. Cisco switches, with QoS enabled, again by default, provide usually provide some form of default QoS treatment.

Second, QoS features, especially on Cisco switches, can vary much by platform.

The foregoing means, if you want to get into the details of how to actual configure a Cisco switch or router, you need to identify exact what the platform is and what software it's running.

From what you describe, QoS may, or may not, mitigate your VoIP issues. If the link is congested due to just VoIP traffic, QoS will probably not help much. If the link is congested due to non-VoIP traffic, QoS might make a huge difference.

As to the situation with provider's intermediate routers, whether QoS support is need on those depends on whether the provider is sharing one of their links, carrying your traffic, with other customer's (and if the link is congested such that it impacts your traffic).

[ChrisSporer62644]

You say : older Cisco switches, by default, if QoS enabled, didn't trust ingress traffic..
So you mean that the DSCP tags could be already removed by the switch that is ahead of the router?
In fact, the voice traffic passes through a L3 switch before reaching the routers GE interface.

The routers are : 

Routeurs 2911  licence de base, c2900-universalk9-mz.SPA.152-4.M6.bin
Routeurs 1921  licence de Base, c1900-universalk9-mz.SPA.154-1.T1.bin

Switches are:
Switch Catalyst 3560 IOS c3560-ipbasek9-mz.122-55.SE8.bin

Switch Catalyst 2960 (unknown IOS version)

You said : QoS may, or may not, mitigate your VoIP issues

- Congestion is only caused by non VoIP traffic as my own is the only source of VoIP. Thus I am very confident that QoS will solve the problem.

- As for the intermediate provider: He get's the traffic on a GE interface and routes it to his E1 link (2048kbps over microwave).
- This E1 is exclusively paid by and reserved for the customer (a railway operator)

Thank you for your interest in this subject.
Chris

[Joseph W. Doherty]

"You say : older Cisco switches, by default, if QoS enabled, didn't trust ingress traffic..
So you mean that the DSCP tags could be already removed by the switch that is ahead of the router?"

Correct.

I'm almost 100% sure a 3560 running 12.2(55) falls under the "older" classification. BTW, if QoS isn't enabled (on the switch), ToS markings will not be reset.

Also BTW, just having a ToS marking, like DSCP EF pass through a router doesn't do anything (by default).

If the routers have a hand-off greater than 2 Mbps, then you'll want a parent shaper.

e.g. (for a router)

class-map match-any VoIP
match . . .

policy-map Parent
class class-default
shape average 2000 !BTW, you may need to shape slower as router may not account for L2 overhead
service-policy Child

policy-map Child
class VoIP
bandwidth priority percent 33 !normally you use LLQ for VoIP bearer traffic
class class-default
bandwidth remaining percent 100
fair-queue

interface x !egress to WAN's 2 Mbps
service-policy output Parent

[tachavez]

For QoS, Per Hop Behavior (PHB) is a principle to maintain consistency across a network for a given type of traffic.

At some point in the network marking should not be trusted in such way that traffic treatment could be influenced by malicious users or poorly implemented policies. It can change from network to network, but attached, some recommendations of its deployment.