From: Henk de Tombe (henk.de.tombe@qi.nl)
Date: Thu Oct 06 2005 - 02:32:19 GMT-3
Hi,
The second method could be to check the TOS bits with the "show queue"
command, see the output below:
Remote1# show queue serial 0/0
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 631823
Queueing strategy: weighted fair
Output queue: 101/1000/64/593935 (size/max total/threshold/drops)
Conversations 4/7/256 (active/max active/max total)
Reserved Conversations 3/3 (allocated/max allocated)
Available Bandwidth 1000 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 5/0/346494/0/0
Conversation 264, linktype: ip, length: 72
source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59,
TOS: 184 prot: 17, source port 0, destination port 16384 <------------ TOS
(depth/weight/total drops/no-buffer drops/interleaves) 63/45/166791/0/0
Conversation 267, linktype: ip, length: 1494
source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59,
TOS: 72 prot: 6, source port 0, destination port 23 <------------ TOS
(depth/weight/total drops/no-buffer drops/interleaves) 35/104/13461/0/0
Conversation 266, linktype: ip, length: 1494
source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59,
TOS: 104 prot: 6, source port 0, destination port 80 <------------ TOS
(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/67216/0/0
Conversation 89, linktype: ip, length: 1482
source: 0.0.0.0, destination: 1.1.1.2, id: 0x0000, ttl: 59,
TOS: 0 prot: 17, source port 0, destination port 67 <------------ TOS
You will have to fill the queue by enabling traffic-shaping on the interface
with the lowest configurable BC, and sending lots of packet to or from the
interface which performs traffic-shaping.
I've used the show queue output from the following link:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
_c/fqcprt7/qcfdfsrv.htm#999311
Regards,
Henk
-----Oorspronkelijk bericht-----
Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Dennis J.
Hartmann
Verzonden: donderdag 6 oktober 2005 03:31
Aan: 'Cisco certification'
Onderwerp: Class-Based Marking Verification -> AT DESTINATION
Does anyone know what debug command I can use to verify packet marking
at the destination of the traffic?
The policy is definetely working at the source, but the Networkers 2005
CCIE R&S Techtorial mentioned that a debug can be run at the destination to
verify that the packet was being marked.
The policy is definetely working (below), but a debug ip packet detail
does not decode the ToS byte value.... (the routers are connected by a
back-to-back serial cable).
R2#show policy-m int
Serial1/2
Service-policy output: ping
Class-map: ping (match-all)
30 packets, 3120 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name ping
QoS Set
dscp ef
Packets marked 30
Class-map: class-default (match-any)
228 packets, 14965 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
R2#ping 180.40.7.3 source 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 180.40.7.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
R2#
R3#sh debug
Generic IP:
IP packet debugging is on (detailed) for access list 2
R3#
*Mar 1 01:43:56.959: IP: tableid=0, s=2.2.2.2 (Serial1/2), d=180.40.7.3
(Serial
1/2), routed via RIB
*Mar 1 01:43:56.959: IP: s=2.2.2.2 (Serial1/2), d=180.40.7.3 (Serial1/2),
len 1
00, rcvd 3
*Mar 1 01:43:56.959: ICMP type=8, code=0
*Mar 1 01:43:56.959: IP: tableid=0, s=180.40.7.3 (local), d=2.2.2.2
(Serial1/2)
, routed via FIB
*Mar 1 01:43:56.992: IP: tableid=0, s=2.2.2.2 (Serial1/2), d=180.40.7.3
(Serial
1/2), routed via RIB
*Mar 1 01:43:56.992: IP: s=2.2.2.2 (Serial1/2), d=180.40.7.3 (Serial1/2),
len 1
00, rcvd 3
*Mar 1 01:43:56.992: ICMP type=8, code=0
*Mar 1 01:43:56.992: IP: tableid=0, s=180.40.7.3 (local), d=2.2.2.2
(Serial1/2)
, routed via FIB
*Mar 1 01:43:57.024: IP: tableid=0, s=2.2.2.2 (Serial1/2), d=180.40.7.3
(Serial
1/2), routed via RIB
*Mar 1 01:43:57.024: IP: s=2.2.2.2 (Serial1/2), d=180.40.7.3 (Serial1/2),
len 1
00, rcvd 3
*Mar 1 01:43:57.024: ICMP type=8, code=0
*Mar 1 01:43:57.024: IP: tableid=0, s=180.40.7.3 (local), d=2.2.2.2
(Serial1/
R3#2), routed via FIB
*Mar 1 01:43:57.056: IP: tableid=0, s=2.2.2.2 (Serial1/2), d=180.40.7.3
(Serial
1/2), routed via RIB
*Mar 1 01:43:57.056: IP: s=2.2.2.2 (Serial1/2), d=180.40.7.3 (Serial1/2),
len 1
00, rcvd 3
*Mar 1 01:43:57.056: ICMP type=8, code=0
*Mar 1 01:43:57.056: IP: tableid=0, s=180.40.7.3 (local), d=2.2.2.2
(Serial1/2)
, routed via FIB
*Mar 1 01:43:57.088: IP: tableid=0, s=2.2.2.2 (Serial1/2), d=180.40.7.3
(Serial
1/2), routed via RIB
*Mar 1 01:43:57.088: IP: s=2.2.2.2 (Serial1/2), d=180.40.7.3 (Serial1/2),
len 1
00, rcvd 3
*Mar 1 01:43:57.088: ICMP type=8, code=0
*Mar 1 01:43:57.092: IP: tableid=0, s=180.40.7.3 (local), d=2.2.2.2
(Serial1/2)
, routed via FIB
R3#
Sincerely,
Dennis J. Hartmann
White Pine Communications
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3