Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

CoS marked packets

I am a little confused as to what I am seeing and wondering if I missed something. I have set a class in a policy map with the command 'set ip precedence 2'. Looking at the class it is marking all the packets coming through, but when I look at the table at the bottom of the policy map, the packets for CoS 2 are much lower. Is there something I am missing? Any help is appreciated.

class info:

125042 packets, 25830510 bytes

30 second offered rate 60000 bps, drop rate 0 bps


QoS Set

precedence 2

Packets marked 125042

cos table:

class Transmitted pkts/bytes

0 420342/314242584

1 0/0

2 20019/10794153

3 87/86188

4 0/0

5 1/171

6 928/57904

7 0/0

rsvp 0/0

Hall of Fame Super Silver

Re: CoS marked packets

Hello Derek,

ip precedence 2 ans CoS 2 are not the same fields:

the first is present in the IPv4 header in the DS byte.

the second is present in the 802.1p field in the 802.1Q 4 byte header used in L2 trunks to indicate the vlan-id.

Packets that travel in the native vlan cannot have a CoS tag so the difference could be explained by traffic with ip precedence 2 in the native vlan if this is a L2 trunk.

Hope to help


New Member

Re: CoS marked packets

Thanks Giuseppe - that does help.

What would be the best way to mark this traffic so that its packets take precedence over internet traffic and other non-essential traffic?

Super Bronze

Re: CoS marked packets

"What would be the best way to mark this traffic so that its packets take precedence over internet traffic and other non-essential traffic?"

That's a very open ended question. Using the TOS byte, is important for a start, since it's part of the IP packet unlike the L2 CoS which requires a VLAN tagged packet.

Marking packets, alone, might not have any benefit since every device choses to honor, or not, any QoS markings. If you control devices along the transit path, you can configure them to support whatever QoS scheme you desire (within their capabilities). If you do implement a QoS scheme, there are recommendations for how packets might be marked (the various Cisco QoS design guides can further explain).

One issue you might need to watch for, for devices not under your control, they can erase or reset TOS or CoS.

BTW, it's possible on some network devices to provide precedence to some traffic w/o using any packet markings. (NB: the purpose of packet markings is to avoid the need for every device to [re]classify traffic.)

New Member

Re: CoS marked packets

Thanks for the info. I guess a little more in-depth explanation might help.

We have our main site (router A) and a remote site (router B). The remote site has about 100 pc's connected to the main site by 2 T1's bundled in a multilink. Since our bandwidth is limited I implemented a service policy on the multilink giving critical traffic the priority bandwidth command, policing internet traffic, and the rest falling in the class-default. While this helped, users were still seeing intermittent delays and drops (i.e. they type a letter in a critical app and it appears 1 second later, or they get kicked out of app due to timeout). After implementing the ip precedence command users no longer experienced drops but were still seeing intermittent latency. I am only concerned about marking the traffic going from Router A to Router B and vice versa. Is there a better way to be doing this or something that I am missing? Or is the link speed the main issue?

Thanks for the help.

Re: CoS marked packets


In my opnion it could be simplified as below:

1. Use Access-List to Classify the traffic (by IP Address and Port Numbers)

2. Mark them with the DSCP (critical apps that can tolerate delay (any apps that work on TCP or anything other than VoIP traffic)

3. Make sure you mark them with appropriate number of DSCP Classes (e.g AF31, Af32 etc)

4. If you have Delay Intolerant Traffic (e.g. Voice Pay Load) mark them with EF

5. Assign the Scavanger Traffic to the Default Class

6. Queue all the enterprise traffic in the CBWFQ on outgoing WAN Port

7. Do the Mirror Replica on the other side of WAN

8. Also, if needed you may like Congestion Avoidance on the Scavanger Class traffic (WRED)

Hope this helps, also if you want you may give me the IP Addreses (Network Add) and Port Numbers and I shall give you an example config.

Hope this helps,

Please rate any useful threads.

Kind Regards

wilson Samuel

Super Bronze

Re: CoS marked packets

Yes, you might have insufficient bandwidth for the offered load. Excluding bulk data transfers, for interactive type traffic, if your average load utilization exceeds about two thirds, you're likely to have queuing. Assuming, though, its an issue of a few "bandwidth hogs" adversely impacting other traffic . . .

Good place to start is with FQ for all traffic. If using CBWFQ, something like:

policy-map sample

class default-class


interface multi x

service-policy output sample

You would implement that on both sides.

If a single FQ doesn't solve your problem, there are two approaches you can take (which are not exclusive). You can either set IP Precedence (or DSCP CS), if FQ does WFQ (many Cisco implementations do), and/or you can break other traffic into their own classes using CBWFQ.

If you use IP Precedence, you might try IP Prec 0 for background, IP Prec 2 for normal and IP Prec 4 for critical. WFQ will allow more bandwidth, per flow, if the flow has a higher IP Prec value.

I would not recommend using "priority bandwidth", except for real-time traffic. Nor do I generally recommend policing traffic if priorization is available.

As sample CBWFQ policy for three priority tiers could be as follows:

policy-map sample2

class criticaltraffic

bandwidth remaining percent 60

class backgroundtraffic

bandwidth remaining percent 10

class default-class

bandwidth remaining percent 30

For the above, you'll need to define class-maps for the explicit classes.


If your running a very recent 12.4T version, you could add fair-queue to each class, which would avoid single class queue.