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

From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Mon Nov 21 2005 - 18:23:31 GMT-3


    What a learning experience.......
 
    Using the debug ip packet with the ACL that matches on the IPPREC of the
packet is HIGHLY unreliable when running on the destination router.
Although I was getting debug output, I verified that I was NOT getting IP
PREC values by running IP Accounting on the interface:
 
interface Ethernet0/1
 ip address 10.1.1.3 255.255.255.0
 ip accounting precedence input
 half-duplex
 
R3#show int e 0/1 precedence
Ethernet0/1
  Input
    Precedence 0: 55 packets, 6270 bytes
    Precedence 3: 6 packets, 684 bytes
 
    I was NOT able to get this working until I changed the source port to an
access port. The CoS was NOT working with the dot1q trunk port, but the
pings were going through. I double-checked this. If I setup a dscp trust
boundary to the source of the traffic and set the ToS to 96 in an extended
ping, it works.
 
Sincerely,
 
Dennis J. Hartmann
White Pine Communications
dh8@pobox.com /
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE

 

 

  _____

From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Monday, November 21, 2005 4: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 : Thu Dec 01 2005 - 09:12:07 GMT-3