This topic is to discuss the following lesson:
Hi Rene,
Could you please do a short demo?
I have 1x3560 and 2x3550, i have configured QoS (similar to the first topology) but i think it is not working well.
Br,
István
Hi István,
What would you like to see? We can do classification, marking, queuing, shaping and policing on the switches 
Rene
Hi Rene,
Do we have qos of service on LAN switches only?. Why not on a WAN and Router as well?.
If we can have the same on Router, is it the same procedure as well as well.
Thanks,
peter
Hi Peter,
QoS is applied everywhere, switches and routers. The configuration on routers is very different however…
Rene
Hi Rene/Andrew
Can you help me in understanding AutoQoS concept please ?
Thanks
Hi Abhishek,
Let me jump in to give you a brief explanation of Cisco AutoQos.
Configuring QOS can be a challenge for engineers who aren’t familiar with this topic, but leaving the network without a QOS configuration can cause a lot troubles especially with the bandwidth-hungry applications and the real-time traffic such as VOIP and Video which can partially and/or fully not work if QOS isn’t configured, in addition of problems like latency, jitter, and packet drops.
For this reason, Cisco IOS Software offers a portfolio of QoS features which is enable by a or few commands without an extensive knowledge needed from the IT administrator and it provide the essential QOS needed.
If you want to know more of AutoQOS, I can refer you to this article from Cisco Wesbite.
1 Like
Thankyou Maher, That helps !
Hi Rene
In a access ,distribution and core architecture where we should do the qos
Thanks
Hello Sims
This is a very good question that doesn’t have a clear cut answer.
In the hierarchical model, the core is performing high speed routing and switching to get things from place to place, the distribution layer is applying policies and filtering, and the access layer is providing you with port density and user connectivity. Based on this, and based on most textbooks and CCNP study material, QoS is said to be most commonly applied at the distribution layer.
However, Layer 2 switches at the access layer can perform both marking and queuing and in general it is good design to apply QoS as close to the equipment or services for which you need to guarantee network resources as possible. In a live network that may very well be in the access layer on your switches, or even at the phone port.
I hope this has been helpful!
Laz
Hello Lagapides,
Thank you for your answer.
What if we have an access switch connected to each dist switch (2 DIST sw) and our access switch is 48 port x 1Go , on each 1G port (PC + Phone or PC + softphone) ?
How could we manage 48Go of traffic on 2x10Go uplinks on the DIST switchs?
could i use CBWQ + LLQ in the output direction on the access switch ?
what about the incoming traffic from the DIST switch
what is the best methode to classify traffic the incoming from PCs , from phones and from softphones ?
how could i match and remark traffic in the access switch ? and on the DIST switch ?
could i use a policy map in input direction on the voice SVI in the core ? and in the data svi ?
Thank you for your answers
Hello Zouhair
In such a scenario, I assume you are focusing on the QoS mechanisms for the voice packets delivered by the IP phones and softphones. Classification and marking of voice packets should be done at the devices themselves. A more detailed explanation can be found in the Classification and Marking section of the following lesson:
Once voice packets are classified and marked, they must be acted upon by QoS mechanisms. Such mechanisms on a switch must be applied in an outward direction, as incoming traffic on an interface cannot be controlled. This means that any queues you set up must be on the two 10GE uplink interfaces of the access switch, and on any uplink interfaces of the distribution, layer switches as well, if you are applying QoS on the core. More on how this can be applied can be found here:
You can find information about this at the following lesson:
I hope this has been helpful!
Laz
1 Like
Hello Laz,
It was very hrlpful.
Thank you.
1 Like
Hello, everyone!
When it comes to classifying traffic, the OCG mentions the following traffic descriptor
I’ve learned from NetworkLessons that we can use a variety of descriptors/traffic parameters to match traffic on.
Either on L1 (physical interface), L2 (CoS, MAC address), L2.5 (MPLS), L3 (DSCP, SRC/DST IP), L4 (port numbers), L7 (NBAR).
However, what exactly does Internal QoS Groups mean, please?
Another question.
Could someone explain nested policy maps to me? I understand what they are but not the logic behind them.
In this example above, the OCG has created a policy map which configures LLQ with a 35% guarantee for the VOIP-TELEHPONY class, then that is applied to the PARENT-POLICY policy which applies the CHILD-POLICY to the default class, where CHILD-POLICY classifies VOIP?
What I’ve said probably doesn’t make much sense and I am getting lost in the logic a little. Could someone assist me here, please?
Thank you!
David
Hello David
Internal QoS groups are a feature of Cisco QoS that allows a device to assign an internal label to identify packets as members of a specific class. The distinctive characteristic of these QoS groups is that the label is not part of the packet header itself, and it is only locally significant, that is, only the device on which QoS groups are configured takes these QoS groups into account. QoS groups essentially provide a way to tag a packet for subsequent QoS action locally on the device, without explicitly marking or changing the packet.
Note that a QoS group is identified and applied to the packet at ingress and is used at egress. It is assigned in an input policy to identify packets in an output policy.
For more info, take a look at this Cisco documentation:
Nested policy maps in Cisco QoS are a way to implement more granular and hierarchical QoS policies. They allow the configuration of a policy within another policy, enabling advanced QoS features such as hierarchical queueing.
The diagram you shared shows an example of nested policy maps:
Parent Policy Map: This policy map is the one that is applied to the interface Gi1 in the egress direction. The PARENT-POLICY is the top-level policy map that is directly associated with the interface.
Class-Default: Within the PARENT-POLICY, the class-default class map is specified, which typically matches all traffic not matched by any other class map. A child policy map named CHILD-POLICY is attached to this class.
Child Policy Map: The CHILD-POLICY is nested within the PARENT-POLICY. This child policy map has its own traffic classes, in this case, VOIP-TELEPHONY, and specific actions assigned to it, such as priority percent 35, which indicates that 35% of the available bandwidth is allocated to VoIP telephony traffic.
Arguably the most important aspect of these nested policies is that the child policy’s bandwidth allocation is a portion of the bandwidth assigned to the parent policy, not the total bandwidth of the interface. In a hierarchical QoS structure, the parent policy controls the overall bandwidth allocation to its child policies. The percentages assigned in child policies are a fraction of the bandwidth that the parent policy has at its disposal, which may be less than the total interface bandwidth due to other policies or limitations set at the parent level.
In the example you shared, it looks like all of the bandwidth is available to the parent policy, so the percentage is indeed that of the total interface bandwidth.
Take a look at this Cisco documentation for more information:
I hope this has been helpful!
Laz