GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: Class-Based Marking Verification -> AT DESTINATION posted 10/06/2005
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


	That command is fine as long as you're running WFQ and you have a
queue to begin with.  Don't forget that a queue is only created during
periods of congestion.  It's easy to create congestion by clocking the link
at 64kbps and generating large packet sizes so it is a "viable" strategy.

	Here's another potential issue.  You will only see the ping in my
ACL if it's being process level switched.  If CEF is turned on and the
router is an intermediate device, you will not see the CEF switched IP
packet.  

	An alternative to this which Tom Settle from RTP shared with me over
E-Mail is.....  

	I quote... "Now, depending on the platform this may need to be done
differently. If CEF is enabled (def on most Catalyst platforms) and the
packet you are trying to match is not process switched then such a debug
won't see it. You could however add 'access-list 101 permit ip any any' to
the acl and apply the acl inbound on the appropriate interface then use run
'sh ip access-lists' to view hits on the acl."


Sincerely,
 
Dennis J. Hartmann
White Pine Communications
dh8@xxxxxxxxx 
CCSI#23402 / CCVP / CCIP / CCNP 
Cisco Optical, VPN & IDS Specialist
MCSE
 

-----Original Message-----
From: Henk de Tombe [mailto:henk.de.tombe@xxxxx] 
Sent: Thursday, October 06, 2005 1:32 AM
To: 'Dennis J. Hartmann'; 'Cisco certification'
Subject: RE: Class-Based Marking Verification -> AT DESTINATION

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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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

dh8@xxxxxxxxx 

CCSI#23402 / CCVP / CCIP / CCNP 

Cisco Optical, VPN & IDS Specialist

MCSE

_______________________________________________________________________
Subscription information may be found at: 
http://www.groupstudy.com/list/CCIELab.html