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

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

Router Trust DSCP?

What if a PC marks a packet with DSCP 46? Is there a way to configure a router to trust the DSCP value the way a switchport can?

2 ACCEPTED SOLUTIONS

Accepted Solutions
Purple

Re: Router Trust DSCP?

Hi Bruce,

Unlike a switch, a router will not reset DSCP values in packets unless explicitly configured to do so. Therefore, you have to do nothing to get a router to trust the DSCP. Having said that, the DSCP will have no meaning for a router unless you then config QoS policies that act on the basis of the DSCP in IP packets.

Hope that helps - pls rate the post if it does.

Paresh

Silver

Re: Router Trust DSCP?

It is generally NOT a good idea to use ACLs for class-map match criteria for the following reasons:

1) An IOS router (like a 7200VXR at headquarters and 870 or 1800/2800 at remote sites) is actually the best device for being able to accurately identify traffic flows. This is because, generally, WAN speeds are much lower than the multi-gigabit speeds in the LAN/MAN. Catalyst switches are much more limited in their ability to accurately identify traffic.

2) An ACL using udp/tcp ports does not guarantee that you are correctly matching the traffic that you think you are. NBAR is much better at this since it is (mostly) signature based so it is not fooled by other traffic masquerading well known ports. This is especially true with peer to peer apps like KazZza, Morpheus, eDonkey, etc. but is also important for less obvious but random high port services like:

tftp

ftp

x-windows

rtp (audio and/or video stream, regardless of call control by h323, sccp, sip, or mgcp).

rtcp (media control)

h323 (signalling)

3) ACLs are generally slower than most other forms of class-map matching, especially in the CEF path (7200/7500 compiled ACLs and 6500/7600 or 2970/3550/3560/3750 TCAM ACLs are exceptions). This is mainly due to an ACL not maintaining flow state, the ACL is re-evaluated per packet.

4) Using an ACL makes for an awkward configuration, matching using native class-map criteria are clearly listed in the config under the class-map, rather than having to additionally look at an ACL to understand what traffic is being matched.

That being said, the most recent Cisco documentation references what they call the 'Cisco QoS Baseline'. This baseline recommends between 5 and 13 classes for identifying and classifying traffic on the WAN.

Since routers usually have multiple interfaces, a best practice is to 'mark' using an inbound service-policy on the inbound interface and 'match' those markings on multiple outbound interfaces. Those outbound interfaces may be a T1 and a DSL or ISDN backup or multiple tunnel interfaces to redundant head-end routers/locations, or a head-end router with hundreds of remote site links or tunnels, etc. The point is you want to do the processor intensive flow packet classification (using NBAR) only once on the inbound interface and set the DSCP values and simply match those values in your outbound queuing policy, possibly on multiple outbound interfaces.

Here is an example (see attachment). This is a snippet from a 7200 at a central site with hundreds of tunnels to remote sites. Note that the FastEthernet interface is the inbound interface (with the inbound service-policy), the ATM interface is the outbound interface (with no service-policy), and the tunnel interfaces are what contains the traffic to the remote sites (with the same outbound service-policy on each interface).

I know this is a lot, and maybe too much info for your project, but this was what worked for us after a year long pilot project tweaking the policy. Your mileage may vary, but you get the idea.

As always, feel free to respond with questions or comments and please rate this post if you found it helpful.

4 REPLIES
Purple

Re: Router Trust DSCP?

Hi Bruce,

Unlike a switch, a router will not reset DSCP values in packets unless explicitly configured to do so. Therefore, you have to do nothing to get a router to trust the DSCP. Having said that, the DSCP will have no meaning for a router unless you then config QoS policies that act on the basis of the DSCP in IP packets.

Hope that helps - pls rate the post if it does.

Paresh

New Member

Re: Router Trust DSCP?

Yes, that is very helpful.

Thanks,

Bruce

New Member

Re: Router Trust DSCP?

I recommend using an inbound service-policy on the ethernet interface of the router. Then use port based matching ACL's to assign DSCP. This will force marking of all packets entering the router from the LAN. It's also good practice as your carrier may expect DSCP but your switches are configured for Auto QoS trusting COS instead of DSCP.

----------------------------------

ACL

----------------------------------

ip access-list extended VVLAN-CALL-SIGNALING

permit tcp any any eq 1720

permit tcp any any range 11000 11999

permit udp any any eq 2427

permit udp any any eq 2428

permit tcp any any range 2000 2002

ip access-list extended VVLAN-VOICE

permit udp any any range 16384 32767

permit ip any any precedence critical

permit ip any any dscp ef

ip access-list extended DVLAN-CRITICAL-DATA

permit tcp any any eq 3200

permit ip 10.9.0.0 0.0.255.255 host REMOVED

permit ip 10.9.25.0 0.0.0.255 any

class-map match-all VVLAN-VOICE

match access-group name VVLAN-VOICE

class-map match-all VVLAN-CALL-SIGNALING

match access-group name VVLAN-CALL-SIGNALING

class-map match-all DVLAN-CRITICAL-DATA

match access-group name DVLAN-CRITICAL-DATA

!

----------------------------------

IN POLICY

----------------------------------

policy-map IPT-LAN-IN

class VVLAN-VOICE

set ip dscp 46

class VVLAN-CALL-SIGNALING

set ip dscp 24

class DVLAN-CRITICAL-DATA

set ip dscp 18

class class-default

set ip dscp 0

----------------------------------

Ethernet Inerface

----------------------------------

service-policy input IPT-LAN-IN

More information can be found in the latest QoS SRND: (http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf).

Silver

Re: Router Trust DSCP?

It is generally NOT a good idea to use ACLs for class-map match criteria for the following reasons:

1) An IOS router (like a 7200VXR at headquarters and 870 or 1800/2800 at remote sites) is actually the best device for being able to accurately identify traffic flows. This is because, generally, WAN speeds are much lower than the multi-gigabit speeds in the LAN/MAN. Catalyst switches are much more limited in their ability to accurately identify traffic.

2) An ACL using udp/tcp ports does not guarantee that you are correctly matching the traffic that you think you are. NBAR is much better at this since it is (mostly) signature based so it is not fooled by other traffic masquerading well known ports. This is especially true with peer to peer apps like KazZza, Morpheus, eDonkey, etc. but is also important for less obvious but random high port services like:

tftp

ftp

x-windows

rtp (audio and/or video stream, regardless of call control by h323, sccp, sip, or mgcp).

rtcp (media control)

h323 (signalling)

3) ACLs are generally slower than most other forms of class-map matching, especially in the CEF path (7200/7500 compiled ACLs and 6500/7600 or 2970/3550/3560/3750 TCAM ACLs are exceptions). This is mainly due to an ACL not maintaining flow state, the ACL is re-evaluated per packet.

4) Using an ACL makes for an awkward configuration, matching using native class-map criteria are clearly listed in the config under the class-map, rather than having to additionally look at an ACL to understand what traffic is being matched.

That being said, the most recent Cisco documentation references what they call the 'Cisco QoS Baseline'. This baseline recommends between 5 and 13 classes for identifying and classifying traffic on the WAN.

Since routers usually have multiple interfaces, a best practice is to 'mark' using an inbound service-policy on the inbound interface and 'match' those markings on multiple outbound interfaces. Those outbound interfaces may be a T1 and a DSL or ISDN backup or multiple tunnel interfaces to redundant head-end routers/locations, or a head-end router with hundreds of remote site links or tunnels, etc. The point is you want to do the processor intensive flow packet classification (using NBAR) only once on the inbound interface and set the DSCP values and simply match those values in your outbound queuing policy, possibly on multiple outbound interfaces.

Here is an example (see attachment). This is a snippet from a 7200 at a central site with hundreds of tunnels to remote sites. Note that the FastEthernet interface is the inbound interface (with the inbound service-policy), the ATM interface is the outbound interface (with no service-policy), and the tunnel interfaces are what contains the traffic to the remote sites (with the same outbound service-policy on each interface).

I know this is a lot, and maybe too much info for your project, but this was what worked for us after a year long pilot project tweaking the policy. Your mileage may vary, but you get the idea.

As always, feel free to respond with questions or comments and please rate this post if you found it helpful.

4197
Views
20
Helpful
4
Replies
CreatePlease login to create content