From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Mon Nov 21 2005 - 17:46:50 GMT-3
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" <vramanaiah@gmail.com> 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