RE: 3550 QoS Marking *SHOCKING TEST* :-)

From: Wang Dehong-DWANG1 (Dehong.Wang@motorola.com)
Date: Wed Dec 28 2005 - 20:13:07 GMT-3


Lab this up and the result makes me confused. R1 is sending all the
packets with dscp set to CS3. I also put a policy-map on SW. The policy
map only works when mls qos is enabled. Any explanation on this?
Thanks.

- Dehong

R1 --- SW ------ R3

On SW:
======
class-map match-all ICMP
  match ip dscp cs3
policy-map SW
  class ICMP
   set dscp cs5

interface FastEthernet0/1
 switchport access vlan 10
 switchport mode access
 service-policy input SW

1. Without mls qos configured globally, ping R3 interface from R1. DSCP
is untouched by switch . Policy-map does not work.

Rack1R1#ping 192.10.1.3 re 4

Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 192.10.1.3, timeout is 2 seconds:
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 1/2/4 ms

Rack1R3#sh access-l 155
Extended IP access list 155
    10 permit icmp any any dscp default log
    20 permit icmp any any dscp cs3 log-input (4 matches)
    30 permit icmp any any dscp cs5 log-input
    40 permit ip any any (11 matches)

2. With mls qos enabled

Rack1R1#ping 192.10.1.3 re 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.10.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Rack1R3#sh access-l 155
Extended IP access list 155
    10 permit icmp any any dscp default log
    20 permit icmp any any dscp cs3 log-input (4 matches)
    30 permit icmp any any dscp cs5 log-input (5 matches)
    40 permit ip any any (36 matches)

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis
Sent: Monday, November 21, 2005 3:13 PM
To: dh8@pobox.com; 'Venkataramanaiah.R'; 'Niche'
Cc: 'Daniel Berlinski'; ccielab@groupstudy.com
Subject: RE: 3550 QoS Marking *SHOCKING TEST* :-)

If I read correctly, there's probably an error in the way you're testing
this.
   
  Don't forget the trust state of the cat port.
   
  My testing verifies the following.
   
  With no mls qos configured globally, and no interface qoS commands,
DSCP values are left untouched by the CAT. The config is via the link I
provided.
   
  If you set mls qos trust cos and mls qos cos 3 on an access port, that
sets the internal DSCP value.
   
  Chris

"Dennis J. Hartmann" <dennisjhartmann@hotmail.com> wrote:
  I labbed this up and it did NOT work with the source as an access port
(I tried both the mls qos cos 3 and the mls qos cos override command
independently and together).

I did however; get the scenario working with the the source (R4) to a
trunk interface.

As Chris mentioned, the ingress cos-dscp will set the dscp which is
backward compatible to an IP PREC value. It doesn't matter if there's
not another trunk until the destination, the IP Prec will be in the
packet. The default dscp map will take care of this.

I REMOVED THE MLS QOS COMMAND FROM BOTH SWITCHES AND THIS FUNCTIONALITY
STILL WORKED! THIS IS NOT RIGHT! THE SWITCHES ARE "SUPPOSED"
TO PASS THROUGH VALUES WITH MLS QOS DISABLED. I VERIFIED THAT QOS WAS
DISABLED WITH THE SHOW MLS QOS COMMAND.

CONFIG:

R4(config-subif)#do srb E
interface Ethernet0/0
no ip address
half-duplex
!
interface Ethernet0/0.99
encapsulation dot1Q 99
ip address 10.1.1.4 255.255.255.0

CAT1(config-if)#do srb 0/4
interface FastEthernet0/4
switchport access vlan 99
switchport trunk encapsulation dot1q
switchport mode trunk
mls qos cos 3

CAT2(config)#do srb 0/3
interface FastEthernet0/3
switchport access vlan 99
switchport mode access

R3#srb 0/1
interface Ethernet0/1
ip address 10.1.1.3 255.255.255.0
half-duplex

R3#show access-l
Extended IP access list 100
10 permit ip any any precedence flash

R3#show debug
Generic IP:
IP packet debugging is on (detailed) for access list 100

R4#ping 10.1.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

R3#
*Mar 1 06:56:38.371: IP: tableid=0, s=10.1.1.4 (Ethernet0/1), d=10.1.1.3
(Ether net0/1), routed via RIB *Mar 1 06:56:38.371: IP: tableid=0,
s=10.1.1.3 (local), d=10.1.1.4
(Ethernet0/1
), routed via RIB
*Mar 1 06:56:38.375: IP: tableid=0, s=10.1.1.4 (Ethernet0/1), d=10.1.1.3
(Ether net0/1), routed via RIB *Mar 1 06:56:38.375: IP: tableid=0,
s=10.1.1.3 (local), d=10.1.1.4
(Ethernet0/1
), routed via RIB
*Mar 1 06:56:38.379: IP: tableid=0, s=10.1.1.4 (Ethernet0/1), d=10.1.1.3
(Ether net0/1), routed via RIB *Mar 1 06:56:38.379: IP: tableid=0,
s=10.1.1.3 (local), d=10.1.1.4
(Ethernet0/1
), routed via RIB
R3#
*Mar 1 06:56:38.383: IP: tableid=0, s=10.1.1.4 (Ethernet0/1), d=10.1.1.3
(Ether net0/1), routed via RIB *Mar 1 06:56:38.387: IP: tableid=0,
s=10.1.1.3 (local), d=10.1.1.4
(Ethernet0/1
), routed via RIB
*Mar 1 06:56:38.387: IP: tableid=0, s=10.1.1.4 (Ethernet0/1), d=10.1.1.3
(Ether net0/1), routed via RIB *Mar 1 06:56:38.391: IP: tableid=0,
s=10.1.1.3 (local), d=10.1.1.4
(Ethernet0/1
), routed via RIB
R3#

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis
Sent: Monday, November 21, 2005 1:16 PM
To: Venkataramanaiah.R; Niche
Cc: Daniel Berlinski; ccielab@groupstudy.com
Subject: Re: 3550 QoS Marking

Venkat,

The methodology used at
http://www.groupstudy.com/archives/ccielab/200509/msg00464.html can help
in verifying all these things. Here is what I did to verify these
questions.

R1--SWA--R2

R1 (10.1.1.1) can ping R2 (10.1.1.2)

I configure the Switch and check its cos to internal DSCP mapping as
follows:

SW-A#sho mls qos maps cos
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56

mls qos
!
interface FastEthernet0/1
switchport mode access
mls qos cos 3

At this stage R1 can ping R2, now I apply the following ACL inbound on
R2

access-list 100 permit icmp any any prec 3

This is now what happens on R1

R1(config-if)#do ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
U.U.U

Now I add the following to the switch on the interface connecting to R1

SW-A(config-if)#switch trunk encap dot1q SW-A(config-if)#switch trunk
nat vlan 1 SW-A(config-if)#switch mode trunk

R1 still cannot ping R2. I now add the last piece to the switch
interface connecting to R1

SW-A(config-if)#mls qos trust cos

And the ping is replied, R1 is now able to ping R2 successfully again.

The key here is in understanding what you have to do to set the internal
DSCP and how that is used on egress by the switch.

So in summary both 1 and 2 are incorrect..

Chris

"Venkataramanaiah.R" wrote:
Sorry for catching up late on this thread, but just wanted to clarifiy
2 things here, because someone might read this archive later..

1) mls qos cos 3 can work in access port

2) mls qos cos does not set the precendence..

Please correct if i am wrong..

-V

On 11/15/05, Niche wrote:
> Hi there,
>
> "mls qos cos 3" will not kick-in cause your port is not a trunk port
> (and I assume that port is not connecting to a 7960). You can use
> class-default for marking remaining traffic to precedence 3.
>
> Cheers~
> Jacky
>
> On 11/15/05, Daniel Berlinski wrote:
> >
> > Hi everyone.
> >
> > Will the following configs mark HTTP traffic coming from vlan 12
> > with precedence 5 and mark the remaining traffic with precedence 3?
> >
> >
> >
> ----------------------------------------------------------------------
> -------
> ---------------------------------------------
> > mls qos
> > access-list 170 permit tcp any any eq www
> >
> > class-map match-any HTTP
> > match access-group 170
> > class-map match-all VLAN12
> > match vlan 12
> > match class-map HTTP
> >
> > policy-map MARKING
> > class VLAN12
> > set ip precedence 5
> >
> > interface FastEthernet0/2
> > switchport access vlan 12
> > switchport mode access
> > mls qos cos 3
> > service-policy input MARKING
> >
> > Rack1SW1#sh mls qos inter fa0/2
> > FastEthernet0/2
> > Attached policy-map for Ingress: MARKING trust state: not trusted
> > trust mode: not trusted COS override: dis default COS: 3 DSCP
> > Mutation Map: Default DSCP Mutation Map trust device: none
> >
> >
> ----------------------------------------------------------------------
> -------
> ------------------------------------------------------------------
> >
> > From the documentation CD: "You cannot configure both port-based
> > classification and VLAN-based classification at the same time. When
> > you configure the match vlan vlan-list command, the class map
> > becomes per-port per-VLAN based. If you configure a policy map that
> > contains both port-based and VLAN-based class maps, the switch
> > rejects the policy map when you
> attach
> > it to an interface"
> >
> > Will "mls qos cos 3" under the interface mark the remaining traffic
> > with precedence 3?
> >
> > Best regards
> >
> > This communication, including any attachments, is confidential. If
> > you are not the intended recipient, you should not read it - please
> > contact me immediately, destroy it, and do not copy or use any part
> > of this communication or disclose anything about it. Thank you.
> > Please note that this communication does not designate an
> > information system for the
> purposes
> > of the Electronic Transactions Act 2002.
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3