From: Vincent Mashburn (vmashburn@fedex.com)
Date: Thu Apr 27 2006 - 10:23:42 GMT-3
It is always best to mark the traffic as close to the edge as possible.
The fact that you are doing both marking and decision making on the same
router may be your problem here. What IOS are you running and what is
the router model number? I had a similar problem with 2500's in a lab
environment. When I upgraded to 2800's the problem went away.
Vince Mashburn
Voice / Data Engineer
901-263-5072
Cisco IP Telephony Support Specialist
CCNP, CCDA,Network +
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Plank, Jason
Sent: Thursday, April 27, 2006 7:03 AM
To: jeff.s.golia@verizon.com
Cc: ccielab@groupstudy.com
Subject: RE: QOS Experts
The config is very simple. I am less concerned about the configuration
and
more concerned about the drops. If somebody knows for sure the answer to
that question it would be great. There is no switch in this scenario
(well
there are, but not where the QOS is happening). Packets are
classified/marked on the Ethernet interface and then matched on DSCP
when
sent out the WAN to customer nodes. I am sure the traffic is going into
the
queue I'd expect, the counters are incrementing (they weren't until we
corrected the ACL for this particular customer).
So the simplest config:
policy-map PROD_WAN_QOS
class ProdHigh
priority percent 25
class ProdMed
bandwidth percent 35
class ProdLow
bandwidth percent 15
class class-default
fair-queue
-------------------
Jason Plank
Network Engineer
101 Bellevue Parkway
Wilmington, DE 19809
E-mail: JPlank@concordefs.com <mailto:JPlank@concordefs.com>
Phone: 302-793-5913
_____
From: jeff.s.golia@verizon.com [mailto:jeff.s.golia@verizon.com]
Sent: Thursday, April 27, 2006 7:57 AM
To: Plank, Jason
Cc: ccielab@groupstudy.com; nobody@groupstudy.com
Subject: Re: QOS Experts
Jason,
Difficult to say exactly what's going on without referencing config.
You
may want to reply and include config.
From what I can see you are matching on PREC or DSCP for your ProdHigh,
ProdMed, ProdLow classes. Can you determine that the traffic you are
seeing
on the sniffer has the appropriate PREC or DSCP value? Need to be sure
that
the traffic is going into the queue you expect. Also look at your
switch.
Is it QoS-enabled? Is the traffic coming in on a trusted port? Also is
the
switch overwriting DSCP to 000000 on transmit? This is the default
behavior
of some switches.
Other than that, until we can see the config, you can try increasing the
bandwidth allocation for the priority queue and see if you get better
results.
Regarding your question on drops, I believe it is only for the queue.
Also
reply with Sho Interface | in drop and Sho Queueing Interface
Thanks,
*******************************************
Jeffrey Golia
CCIE#14849
Tac Engineer (Converged Technology Services)
Verizon Enterprise Premise Solutions
Tel # 1-800-993-2264
email : Jeff.S.Golia@Verizon.com
*******************************************
"Plank, Jason" <JPlank@concordefs.com>
Sent by: nobody@groupstudy.com
04/27/2006 07:09 AM
Please respond to
"Plank, Jason" <JPlank@concordefs.com>
To
cc
Subject
QOS Experts
I realize this may not be the forum for this question, but I am studying
for
my CCIE and want some clarification on something. In a production
environment we have 4 classes of traffic (including class default), on
the
first policy (ProdHigh in this case), which is our strict priority class
-
it has an area called total drops/bytes drops. Now at first I thought
that
was JUST for the ProdHigh queue, but the same field is not in the
ProdMed
and ProdLow. I was looking through the CCO and one place it mentioned it
was
amount of drops for the queue it is listed under but someplace else
mentioned it was the total amount of drops on the interface output
queue.
Both could make sense to me (only because the other queues don't have
the
total drops/bytes drops) field.
The main reason I am looking at this is we have configured FRTS and
applied
this QOS policy and on the low speed circuits (56k) we see FTP (ProdLow)
interfere with our traffic that is in the ProdHigh / Strict Priority
Queue.
I am personally thinking that the bandwidth for the high queue needs to
be
adjusted - would there be any other reason to see the drops? Watching
the
traffic on the sniffer during the time of the FTP transmission showed us
continuously retransmitting the HIGH queue but watching the same sniffer
and
the FTP traffic we saw the FTP server fire off 20 packets immediately,
normally with FTP I only see 2-4 packets get sent and an ack on the
data, so
the issue at hand is a little confusing but the question I would think
is
still direct.
Class-map: ProdHigh (match-any)
1065956 packets, 147872244 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: ip dscp af41 (34)
1065956 packets, 147872244 bytes
5 minute rate 2000 bps
Match: ip precedence 4
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 25 (%)
Bandwidth 62 (kbps) Burst 1550 (Bytes)
(pkts matched/bytes matched) 36743/13870270
(total drops/bytes drops) 5500/7480188
Class-map: ProdMed (match-any)
104811 packets, 72795423 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af21 (18)
104811 packets, 72795423 bytes
5 minute rate 0 bps
Match: ip precedence 2
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 41
Bandwidth 35 (%)
Bandwidth 86 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 39630/49654773
(depth/total drops/no-buffer drops) 0/25/0
Class-map: ProdLow (match-any)
79729 packets, 82581164 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af11 (10)
79729 packets, 82581164 bytes
5 minute rate 0 bps
Match: ip precedence 1
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 42
Bandwidth 15 (%)
Bandwidth 37 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 53609/74991352
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
145710 packets, 19011896 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
-------------------
Jason Plank
Network Engineer
101 Bellevue Parkway
Wilmington, DE 19809
E-mail: JPlank@concordefs.com <mailto:JPlank@concordefs.com>
Phone: 302-793-5913
-----------------------------------------
The information in this message may be proprietary and/or
confidential, and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify First Data
immediately by replying to this message and deleting it from your
computer.
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:59 GMT-3