Where to mention the dscp command in qos configuration?

[kishore]

This is a simple qos configuration. I want remark it using the dscp command (ie: where to specify set ip dhcp command and match ip dscp command) .

The intention here is to limit the bandwidth using shape command and if it exceeds then must be dropped and to use dscp to mark the packets and identify it.

ip access-list extended VLAN1
 permit ip 192.168.0.0 255.255.255.0 any
 permit ip any 192.168.0.0 255.255.255.0
.
.
ip access-list extended VLAN#
 permit ip 192.168.0.0 255.255.255.0 any
 permit ip any 192.168.0.0 255.255.255.0

class-map match-all VLAN1
 match access-group name VLAN1
.
.
class-map match-all VLAN#
 match access-group name VLAN1

policy-map ingress
 class VLAN1
  police average 5000000
.
.
 class VLAN#
  police average 5000000 ---------> how to specify here the drop statement

policy-map egress
 class VLAN1
  shape (or police) average 5000000
.
.
 class VLAN#
  shape (or police) average 5000000

interface fastethernet 0
 service-policy input ingress
 service-policy output egress

[kishore]

where to specify set ip dscp command and match ip dscp command

[Joseph W. Doherty]

"(ie: where to specify set ip dhcp command and match ip dscp command) "

Match IP DSCP would be used in class-maps (you can also match ToS, I believe, in an ACL being invoked by the class map).

Set IP DSCP would be used in policy class.

I recall you can match or set DSCP on an ingress or egress policy. You might have an ingress policy that matched, an egress policy that sets, or an ingress/egress policy that does both.

[kishore]

Could you just guide me the use/explanation of dscp setting and matching in class-map and policy-map respectively. This question arised in my mind due to the fact that( on my view point dscp is used for referencing ie: after setting the dscp only we should look for the ip with that assigned dscp(matching), if correct matching is found then transmit).

Could you just explain with some sample configuration.

Please help me.

[Joseph W. Doherty]

DSCP is used as a "shortcut" for determining what QoS treatment a packet should receive. The "shortcut" bypasses the need to to an in-depth analysis of a packet's contents at every hop.

For example, a VoIP bearer packet, rather than being examined at every hop to determine if it's an UDP packet, using the expected ports, having an expected source IP and destination IP, just contains a DSCP value of EF.

Of course, for this approach to work "safely", your initial acceptance of a packet might subject it to such tests to validate and/or set the DSCP value that will be relied upon as the packet continues to transit your network.

Class-maps are used to define the conditions for what packets are part of a particular "class" of packets. Basically the class-map defines one or more match conditions. The match conditions can be a logical and (i.e. they all need to be true for a class match) or they can be a logical or (i.e. any can be true for a class match). The former is set by using a class-map with "match-all" and the latter with "match-any".

A policy-map defines a policy to subject packets to, upon ingress or egress (or both). Its class's class-maps set the match conditions, and they also configure policy treatment. Policy-map classes are applied top to bottom, so the first class that matches a packet will process that packet to that class's rules.

Assume we have a port FE1 with a PC that has a "soft" VoIP app. The "soft" VoIP might, or might not, set DSCP EF, so we want to both validate and/or insure the VoIP traffic has DSCP EF set. We also want to insure that other traffic doesn't use DSCP. We also want to insure an egress port provides 1st out queuing for the VoIP traffic. We could configure something like:

class-map match-all EF_and_RTP
match ip dscp EF
match protocol RTP

class-map match-any DSCP_EF
match ip dscp EF

class-map match-any RTP
match protocol RTP

policy-map ingress
class EF_and_RTP
!nothing happen here beyond this class "capture" packets before the next two classes
class DSCP_EF
!not validated EF packets get marked down to best effort
set ip dscp BE
class RTP
set IP dscp EF

policy-map egress
class DSCP_EF
priority percent 33

interface FE1
desc edge port
service-policy input ingress
service-policy output egress

interface ge1
desc uplink
!no ingress policy - assuming ingress has already been processed before
service policy output egress

[kishore]

So that means configuration below would be done using dscp.

I have one more question could the below configuration canbe used to limit the upload and download speed to 30 Mbps. And could you explain the work flow or control of execution goes from the first line till the end for the commands that is coloured in red.
Please help me.

ip dhcp pool test
network 192.168.23.0 255.255.255.0
default-router 192.168.23.1
dns-server 8.8.8.8 4.2.2.2

ip access-list extended test_ACL
deny ip 192.168.0.0 0.0.255.255 192.168.23.0 0.0.0.255
permit ip any 192.168.23.0 0.0.0.255

class-map match-all test_CMAP_DOWNLOAD
match access-group name test_ACL

class-map match-all test_CMAP
match ip dscp af11

policy-map PARENT_DOWNLOAD14
class test_CMAP_DOWNLOAD
shape average 3000000

policy-map test_PMAP
class class-default
set dscp af11

policy-map PARENT_QOS
class test_CMAP
shape average 3000000

interface GigabitEthernet0/1.23
encapsulation dot1Q 23
ip address 192.168.23.1 255.255.255.0
ip nat inside
service-policy input test_PMAP
service-policy output PARENT_DOWNLOAD14

interface GigabitEthernet0/0
description ****WAN-LINK****
ip address <IP ADD>
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
service-policy output PARENT_QOS

[Joseph W. Doherty]

That might work, although using a shaper for download traffic is likely to allow even more ingress bursting than a shaper would.

As to the statements listed in red, any traffic ingressing g0/1.23 will be tagged with DSCP AF11.

Traffic egressing g0/1.23, if it matches the ACL test_ACL, will be shaped at 3 Mbps.

Any traffic egressing G0/0, tagged with an AF11 will be shaped at 3 Mbps.

[kishore]

So upload and download will be set as 3mbps. And would not involve any traffic drop or loss.

[Joseph W. Doherty]

A shaper will drop packets if you overflow its queues.

Using the shaper downstream of the ingress link will allow ingress to burst above the shaped rate.

[kishore]

No my question is whether the upload and download will be limited to 3 mbps or not ?

[Joseph W. Doherty]

Upload - yes (i.e. past the shaper)
Download - sort of (i.e. before the shaper)

To further clarify, assume I have a traffic generator that sends 4 Mbps of UDP traffic. The shaper will allow 3 Mbps "out" and drop 1 Mbps. I.e. you'll have 4 Mbps to the shaper and 3 Mbps from the shaper.

If you're trying to manage bandwidth on your Internet link, the egress shaper will guarantee that there will not be more than 3 Mbps. But for traffic coming in on the link, the shaper will not stop the 4 Mbps of UDP.

However, if the traffic generator was using TCP, rather than UDP, as the shaper started to drop traffic, TCP would slow its transmission rate, and speed up again until it detected drops again. The would keep reoccurring. The important point, though, the traffic upstream of the shaper would average about 3 Mbps, but at any one time it could be more or less than 3 Mbps.