Solved

Hierarchical QoS Policy - Why is default DSCP marking not occurring at egress?

Posted on 2010-11-23
7
2,125 Views
Last Modified: 2012-05-10
Hi there,
 
I have inherited a QoS configuration I am trying to troubleshoot. The rough setup is as follows. We have an access layer router for network A (A1) connected to a distribution router (Site1), which meets the WAN edge. Site1 is connected to a corresponding peer (Site2) using a DMVPN tunnel. A1 connects to its peer (A2) using another DMVPN tunnel (a tunnel-in-a-tunnel) setup. This gives the required segregation - we have multiple networks (ie. A, B, C etc) which utilise the backbone DMVPN tunnel.
 
Traffic is marked at the access layer egress using a particular DSCP value. To test the setup, all FTP traffic (data and control plane) is marked using dscp af11. This enters the encrypted tunnel, bound for A2, with the tunnel setup using the qos pre-classify command. I can verify this marking is preserved by snooping traffic on the A2 target host.
 
On the edge router (Site1) we want to match inbound traffic from the various networks in a given priority, then each application within that network is remarked for queuing. This allows us to allocate bandwidth for certain traffic, even though it is encrypted at this stage. We have multiple policy maps with different bandwidth allocations, which are used interchangeably on the WAN egress. For example, we have one policy that allocates bandwidth equally to all connected networks, another that gives one network greater bandwidth and so on.
 
The last step in our setup is to reset the DSCP field to 0 on egress - and here's the problem. I sniff traffic on the outbound WAN interface (ie. between Site1 and Site2) using Wireshark, where I can see all the encrypted packets, but the DSCP field has not been reset to 0! Instead it seems to just have the field set by the last statement prior to the set dscp default command.
 
Here's the sample configs, not all details are listed - such as multiple network entries - just trying to get the expected behaviour for one network right before examining the wider setup.
 
Site1:
 
class-map match-all CLASS7
match dscp af11

class-map match-any NETWORK-A
match dscp af41
match dscp af42
match dscp af43

class-map match-any NETWORK-A-CLASS3
match dscp af43

policy-map NETWORK-A-IN
class CLASS7
set dscp af43

policy-map NETWORK-A-SERVICE
class NETWORK-A-CLASS3
bandwidth percent 50
random-detect dscp-based
set dscp default
class class-default
fair-queue
random-detect dscp-based
set dscp default
policy-map EQUAL
class NETWORK-A
shape average percent 15
service-policy NETWORK-A-SERVICE
class NETWORK-B
shape average percent 15
service-policy NETWORK-B-SERVICE


interface FastEthernet2/1
description NETWORK-A LAN
ip address X.X.X.X Y.Y.Y.Y
service-policy input NETWORK-A-IN

interface FastEthernet2/8
description WAN DMVPN (physical)
ip address X.X.X.X Y.Y.Y.Y
bandwidth 512
service-policy output EQUAL

My understanding of the above config is that incoming traffic from Network A with a dscp of af11 is matched to CLASS7, which then gets translated to af43. At egress on the physical interface to the tunnel, this is matched to class NETWORK-A and NETWORK-A-CLASS3. The hierarchical policy map then sets bandwidth allocation for Network A traffic to 15% on average and the previously matched traffic gets 50% of that value. The last step is to reset the dscp field to 0. The encrypted packet then leaves the fa2/8 interface and travels over the wire to where I am sniffing the traffic using Wireshark.
 
In this case, I only see af43, not 0 (default) like I am expecting. Examining counters using show policy-map interface fa2/8 doesn't show much either. I was expecting to see lots of packets for my FTP transfer, but instead only see about 70 or so. I read somewhere that this is because the packet mangling counters only apply to those done in software, not in hardware - is that correct?

If I remove the set dscp default commands above, I still see af43 in the DSCP field of the encrypted packets in Wireshark, yet the IOS command show policy-map interface fa2/8 does show af43 traffic stats, which were previously counted in the default section of the output - so it seems some traffic does have its DSCP field cleared to zero at egress, but not all - why?
 
Is there a way to always ensure the DSCP field is cleared using the above approach?
 
This is against IOS 12.4-7h running on a 3825.
 
Thanks.
0
Comment
Question by:xavier_da
  • 4
  • 3
7 Comments
 
LVL 4

Expert Comment

by:t509
ID: 34204002
I had also such issues with the markings, but on other routers...in these cases solved with IOS-updates.
Your IOS is quite old, i´d say, so in my opinion this would be the first step to go.
0
 

Author Comment

by:xavier_da
ID: 34204585
Hi t509,

Thanks for your response. This was one of the first things I tried. I trialled with 12.4-25 - essentially the latest within the 12.4 line. Same result. I haven't used any 15.0 image yet - which version did you use in your case that resolved the issue?

You mentioned other routers; was this within the 3800 series, eg 3845? Or one of the newer ISRs? I have some older 2851s I could try with the same config.

Finally, was your classification and marking scheme similar to the approach that I have presented here? The reason I ask is that I want to eliminate potential configuration problems. If you have used a similar approach, my confidence that the real issue lies with some obscure IOS/Hardware combo bug improves...
0
 
LVL 4

Expert Comment

by:t509
ID: 34204970
I used IOS versions within the T train, and only minor upgrades were needed...for example 12.4.10 to .13.
I experienced such issues on 18xx, 26xx, 28xx, 38xx.
And no, my marking approach wasn´t similar, because in most cases i used marking i had to use one router, since it was in fact the edge of the network.
0
Free camera licenses with purchase of My Cloud NAS

Milestone Arcus software is compatible with thousands of industry-leading cameras for added flexibility. Upon installation on your My Cloud NAS, you will receive two (2) camera licenses already enabled in the software. And for a limited time, get additional camera licenses FREE.

 

Author Comment

by:xavier_da
ID: 34205317
Alright, seems like I need to experiment some more with different IOS versions. I'll try one from the 12.4T and 15.0 trains and see if anything changes.

In general though, is there any other reason the DSCP field is not set to 0 (default) on egress using the setup I have described? As mentioned, some packets seem to get marked/counted but this figure doesn't correspond to the number of packets I see in Wireshark for my ~6MB FTP transfer test, ie. I only see about 70 or so, instead of the expected thousands - is this because counters against such a policy map configuration only apply when congestion occurs? I'm expecting every packet that matches to be reset - just want to clarify my understanding - is that what is meant to happen?
0
 
LVL 4

Expert Comment

by:t509
ID: 34205860
I don´t think the packets will only be remarked when congestion occurs. You´re using class-based markings, so if the conditions for this class are met, the so classified packet will get marked...in my personal own world of understanding cisco QoS ;)
0
 

Accepted Solution

by:
xavier_da earned 0 total points
ID: 34224825
Okay, the resetting issue is resolved by explicitly including the class class-default section under the EQUAL policy-map:

policy-map EQUAL
class NETWORK-A
shape average percent 15
service-policy NETWORK-A-SERVICE

class NETWORK-B
shape average percent 15
service-policy NETWORK-B-SERVICE

class class-default
fair-queue
random-detect dscp-based
set dscp default

The discrepancy in matching does seem to relate to the shaping command - that is, the packets subject to shaping (NETWORK-A-CLASS3) are the ones reset, which is why I was only seeing about 50 packets remarked, instead of the thousands I was expecting. This occurs at the start of my transfer test.

Every other packet falls through to the newly added default clause and gets remarked. Using Wireshark, I can confirm this is the case - all packets have a DSCP of 0 now.

Still confused as to why this is the case though - any additional comments welcome!

0
 

Author Closing Comment

by:xavier_da
ID: 34265149
All though the outcome (reset DCSP field of all packets at egress to 0) is achieved, it remains unclear why, given the config, the additional class-default class-map is required under the tail of the EQUAL policy.

Would like to get a link to Cisco documentation that clarifies these aspects.
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
Shadow IT is coming out of the shadows as more businesses are choosing cloud-based applications. It is now a multi-cloud world for most organizations. Simultaneously, most businesses have yet to consolidate with one cloud provider or define an offic…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now