[c-nsp] Using SET commands in policy maps (LLQ)

[John Neiberger]

Chris,

It turns out that I was being an idiot. This QoS was configured for
video conferencing, but I was looking at a site that wasn't
participating in the conference this morning.  :-)  I had just made
the change to mark the packets this morning, but no packets have been
marked because that site hasn't been involved in a video conference
since I made the change.

Once I realized the problem, I looked at a different site that I knew
for certain was involved. The packets were being matched and marked as
expected.

Thanks!
John

On 5/24/06, Bisazza, Chris <Chris.Bisazza at colt.net> wrote:
> John,
>
>
> The output you have given shows that your link is experiencing
> congestion - so it seems not to be marking even in this case.
>
> What version are you running? This does not seem to be LLQ (or it's a
> non-LLQ portion of an LLQ policy-map).
>
> I suspect that the router is trying to apply the policy map in order,
> and given that marking needs to happen before policing or queueing, it's
> never getting down to it. I've noticed that you can enter the commands
> in the 'wrong' order, but never thought that it would actually make a
> difference as there is a fixed order for QoS events.
>
> If that does not solve the problem, then a 'show policy-map xxx' output
> would help.
>
>
> -Chris.
>
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of John Neiberger
> Sent: 24 May 2006 16:26
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Using SET commands in policy maps (LLQ)
>
>
> I have a policy map configured for LLQ and it has a "set" statement in
> each class. However, this does not appear to be working.
>
> Match: access-group 140
>        1681300 packets, 1137370160 bytes
>        30 second rate 0 bps
>      Queueing
>        Output Queue: Conversation 265
>        Bandwidth 400 (kbps) Max Threshold 64 (packets)
>        (pkts matched/bytes matched) 115626/79284247
>        (depth/total drops/no-buffer drops) 0/0/0
>      QoS Set
>        precedence 4
>          Packets marked 0
>
> As you can see, it is configured to mark packets with an IP precedence
> of four. However, none are being marked. This never really occurred to
> me before, but do "set" statements within policy maps only apply when
> the QoS mechanism is active during congestion?
>
> I guess that would make some sense. I just assumed that it worked like a
> route map. If I want these packets to always be marked as IP precedence
> four even when the interface isn't congested, do I need to use a route
> map instead?
>
> Thanks,
> John
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> *************************************************************************************
> The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.
>
> The contents of this message and its attachments are confidential and may also be subject to legal privilege.  If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies.
>
> Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.
>
> No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.
>
> Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
>
>