09-22-2017 11:50 AM - edited 03-08-2019 12:08 PM
Big question: Does the config below work? We have issues with WRED statistics.
Environment:
Two branch locations that use MPLS to connect to a datacenter. The configuration of QoS is applied from CE in the datacenter. Branch uses VOIP and some Core Vendor software (extremely network sensitive).
We want to accept any critiques, and know if the config below would work in general/at all. In particular I would like to ensure the Core Vendor traffic never drops/has too high of a latency.
In the current configuration I didn´t saw packets drops with WRED (avoid congestion).
This is the configuration of QoS.
class-map match-any Mgtm
match access-group name Mgtm-list
class-map match-any VoIP
match protocol rtp audio
match ip dscp ef
match access-group name VoIP-list
class-map match-any VIDEO
match access-group name CUCM
class-map match-any HIGH
match access-group name Aplications-list
class-map match-any MEDIUM
match access-group name Network_list
match access-group name VPN_Services
match access-group name Skype_Business
policy-map Child_Policy-QoS-1MB
!
class VoIP
set dscp ef
priority 64
!
class MGTM
set dscp cs6
bandwidth 32
!
class HIGH
set dscp af31
bandwidth 364
random-detect dscp-based
police cir 512000 bc 16000
conform-action transmit
exceed-action set-dscp-transmit af32
!
class MEDIUM
set dscp af21
bandwidth 400
random-detect dscp-based
police cir 128000 bc 4000
conform-action transmit
exceed-action set-dscp-transmit af22
!
class class-default
fair-queue
random-detect dscp-based
police cir 700000 bc 21875
conform-action transmit
exceed-action drop
policy-map Parent_Policy-QoS-1MB
class class-default
shape average 1024000
service-policy Child_Policy-QoS-1MB
Interface Tunnel0
service-policy output Parent_Policy-QoS-1MB
Solved! Go to Solution.
09-23-2017 01:43 PM
Hi
We get a private troubleshooting session and your WRED information aren't shown in policy-map output.
As I sent you already the output I had from labbing it on different platform (Virl, IOU, ASR1001-x), you can see that this feature is supported.
The config is good, outputs are OK except for the WRED statistics.
I guess you're facing the bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsb09543
As I recommended, upgrade your routers (at least 2 for testing) with the recommended version as you're running a 2013 version.
If possible, raise a Cisco TAC case.
Sorry to not being able to help you more in your issue.
09-22-2017 03:56 PM
Hi
First of all, your config will work if we just take a look at the command level.
I can't confirm for the router of traffic as you're using some acl for voice, video and others. If you paste your acl we can also validate that everything is good.
Now in terms of values:
Your shaping at 1Mbps your traffic interface.
The bandwidth command will ensure the minimum guarantee bandwidth for the class.
Police will setup the maximum traffic for the class.
The priority will setup the minimum and maximum guarantee bandwidth.
Doing a priority at 64k for the voice and 32k for video is very low.
Then for class medium, you guarantee a minimum of 400 but police a maximum 128k. It sounds weird.
Usually, we define each class with a certain value but on the parent policy-map the shape should be able to ensure that all traffic can pass and not be dropped.
In your example, if you committed the value with your customer, and he uses all max traffic for each class, he will have some dropped traffic as global shape is lower than sum of all classes.
09-22-2017 06:36 PM - edited 09-22-2017 06:54 PM
Francesco, thanks for you answer.
With respect to ACL, are the next.
ip access-list extended VoIP-list
permit udp host 10.201.164.93 range 50000 65535 any
permit udp host 10.201.136.15 range 2048 65535 any
ip access-list extended Aplications-list
deny ip host 10.203.5.35 any
permit ip 10.203.4.0 0.0.1.255 any
ip access-list extended Network_list
deny tcp 10.40.120.0 0.0.0.255 any range 22 telnet
permit ip 10.40.120.0 0.0.0.255 any
ip access-list extended CUCM
remark CONTROL_VIDEO_CISCO
permit ip 10.143.0.0 0.0.255.255 any
ip access-list extended VPN_Services
permit ip 172.16.0.0 0.0.255.255 any
permit ip 192.168.3.0 0.0.0.255 any
Repeat again, the configuration of QoS is applied on tunnel interface from PE in the datacenter.
I don´t understand why WRED not work in the configuration. WRED dscp-based was used, but the packets aren´t dropped.
With respect to CBWFQ and policer, the configuration was the better for requeriements of business. The class VoIP and Video don´t have use of bandwithd, only rarely used. The policer have action remarking and not drop in the class High and Medium. The big issue is the configuration of WRED, because no drop packet ramdomly in the class Medium.
Please explain me if WRED not work with tunnel interface, always i have had this question.
Other thing, the main interface is fastethernet, which recieve the conection of service-provider. This interface have bandwitdh 60 Mbps, but we have tunnels ipip to some offices. Each branch have 1Mbps of bandwitdh and the QoS is configured in the PE because the traffic of greater consumption is downstream.
09-22-2017 06:52 PM
09-22-2017 07:02 PM
Good night Francesco,
The tunnel interface have the command qos preclassify. But WRED not work in the configuration because i dont see the package dropdown with the show policy map command on the interface.
The class VoIP an VIDEO rarely are used. The class HIGH and MEDIUM always consume bandwidth, but it is necessary to control the MEDIUM class since it consumes a lot of bandwidth.
Please explain me if WRED not work with tunnel interface, always i have had this question.
09-22-2017 07:49 PM - edited 09-22-2017 08:46 PM
09-22-2017 08:36 PM
09-23-2017 01:43 PM
Hi
We get a private troubleshooting session and your WRED information aren't shown in policy-map output.
As I sent you already the output I had from labbing it on different platform (Virl, IOU, ASR1001-x), you can see that this feature is supported.
The config is good, outputs are OK except for the WRED statistics.
I guess you're facing the bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsb09543
As I recommended, upgrade your routers (at least 2 for testing) with the recommended version as you're running a 2013 version.
If possible, raise a Cisco TAC case.
Sorry to not being able to help you more in your issue.
09-23-2017 01:55 PM
Hi francesco,
We will update the routers to check that WRED work.
Thank you so much for everything.
09-23-2017 02:04 PM
10-09-2017 07:53 AM
10-09-2017 09:47 AM - edited 10-09-2017 09:50 AM
Would your (QoS) config work? Well, maybe not too well if your High class is to provide low latency and/or low drops for your Core Vendor application traffic. To truly guarantee that, you need to give such traffic almost LLQ treatment.
As to not seeing drops in WRED, much depends on what your WRED settings are. I assume you're using default settings, but they vary per platform. (BTW, I generally recommend only QoS experts use WRED if class based FQ is available. [I also recommend that FQ and WRED not be used together.])
I'm unsure all platforms' shapers account for L2 overhead. if your platform does not, you may need to shape at about 15% under your nominal bandwidth. (This can be crucial for VoIP.)
You might try a policy like:
policy-map Child_Policy-QoS
class Realtime
priority percent 33
class High
bandwidth remaining 90
fair-queue
class Low
bandwidth remaining 1
fair-queue
class class-default
bandwidth remaining 9
fair-queue
10-09-2017 11:48 AM
Hi Joseph,
This configuration is wrong. FQ should be configured only on class-default and the class ALTA in my network should be configured with CBWFQ.
10-09-2017 12:17 PM
10-10-2017 07:02 AM
Platform: CISCO3945-CHASSIS
IOS: c3900e-universalk9-mz.SPA.155-3.M5.bin
The class ALTA have all aplications main.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide