Well, I haven't tried looking at incoming packets going to a tunnel (e.g.
non-physical) interface, but I would assume the logic works the same way.
Got your lab handy with a sniffer around? :) Or on next-hop router you
can set up an ACL with different criteria. One to match your original DSCP
value, the other to match your changed DSCP value, and see which couter
increments.
Now, I did a short test because I didn't feel like setting up trunks for
CoS... I just did IP-Prec to DSCP. But here's an idea:
Ca1(config)#do sh mls qos map ip-prec-dscp
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56
Ca1(config)#mls qos map ip-prec-dscp ?
<0-63> 8 dscp values separated by spaces
Ca1(config)#mls qos map ip-prec-dscp 46 46 46 46 46 46 46 46
Ca1(config)#do sh mls qos map ip-prec-dscp
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 46 46 46 46 46 46 46 46
Ca1(config)#
R4(config-if)#access-list 101 permit ip any any dscp 0
R4(config)#access-list 101 permit ip any any dscp 46
R4(config)#access-list 101 deny ip any any log
R4(config)#int f0/0
R4(config-if)#ip access-group 101 in
R4(config-if)#
R5(config)#do trace 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
1 10.10.10.4 0 msec * 0 msec
R5(config)#
R4(config)#do sh access-list
Extended IP access list 101
10 permit ip any any dscp default (3 matches)
20 permit ip any any dscp ef
30 deny ip any any log
R4(config)#
Ca1(config)#int range f0/4 - 5
Ca1(config-if-range)#mls qos trust ?
cos Classify by packet COS
device trusted device class
dscp Classify by packet DSCP
ip-precedence Classify by packet IP precedence
<cr>
Ca1(config-if-range)#mls qos trust ip
Ca1(config-if-range)#
R5(config)#do trace 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
1 10.10.10.4 0 msec * 0 msec
R5(config)#
R4(config)#do sh access-list
Extended IP access list 101
10 permit ip any any dscp default (3 matches)
20 permit ip any any dscp ef (3 matches)
30 deny ip any any log
R4(config)#
So yes, it actually modifies the packet.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M
#153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
[EMAIL PROTECTED]
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
-----Original Message-----
From: Suresh Mishra [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2008 8:08 AM
To: [EMAIL PROTECTED]
Cc: OSL CCIE Routing and Switching Lab Exam
Subject: Re: LAB 12 task 7
Originally, I was thinking on the same lines as you are but after reading
the following from Cisco book. I got kind of confused. I might have
misunderstood it. However, I have included it here for your reading and to
help me out with this issue.
The cisco CCIE third edition book has an explanation on page 459 that reads
as follows. It is the second para from the top.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++
"These switches make most internal QOS decisions based on internal DSCP
setting. The internal DSCP has been determined when the frame is forwarded.
So, when a frame has been assigned an internal DSCP and an egress interface,
the following logic determines into which of the four interface output
queues the frame is placed.
1. The frame's internal DSCP is compared to a global DSCP-COS map to
determine a COS vlaue.
2. The per interface COS-queue map determines the queue for a frame based on
the assigned CoS
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++
My interpretation of the above paragraph.
Throughout this paragraph there is no mention of packet anywhere. The DSCP
value is assigned to the frame and not the IP header. It is assumed to be
internal to the switching logic and is not assigned to the packet header.
If a switch were to convert a COS value into a DSCP value, in that an
incorrect mapping in any switch will alter the DSCP in the IP header thus
effectively becoming a marking tool. As far as I know switches do not change
the DSCP value in the IP header for a packet received over a tunnel
interface.
Let me know if you think it is something incorrectly printed in the book
that we need to refer to the author.
Thanks
Suresh
On Thu, Jun 5, 2008 at 8:14 PM, Scott Morris <[EMAIL PROTECTED]> wrote:
> Please let me know where you were reading that, because that's not the
> behavior I've observed in real life!
>
> If it comes in as CoS 5, the DSCP will get rewritten (provided you
> have mls qos enabled and the trust level appropriately set). That
> will indeed affect other devices.
>
> Scott
>
> -----Original Message-----
> From: Suresh Mishra [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 05, 2008 5:15 PM
> To: Scott Morris; OSL CCIE Routing and Switching Lab Exam
> Subject: LAB 12 task 7
>
> Hello all,
>
> This LAB requires that we change the cos-dscp map to map cos 5 to dscp 46.
> Now this is required for dwonstream routers so that they see DSCP
> 46 in the IP packet.
>
> However i was reading the document , it says that cos-dscp mapping is
> used internally by the switch and has nothing to do with changing the
> IP packets DSCP field. In that case downstream routers will not see the
dscp value.
>
> Can somebody help me out on this issue?
>
> Thanks
> Suresh
>
>
