[c-nsp] QoS - questions

varaillon j.varaillon at cosmoline.com
Tue Aug 21 04:51:13 EDT 2007


Hi Oliver,

Thank you for your so prompt answer!

I will push my luck a bit further...

LAN---2600---WAN

On the LAN side I am marking relevant traffic with ip precedence 5 AND mpls
exp bit 5.

On the WAN side, I am queuing based on both ip precedence and mpls exp bit.

The following shows an almost equal amount of marked packets should it be
with Ip precendence or mpls exp bit:
--------------------------------
RTR1#show policy-map interface fastEthernet 0/0
 FastEthernet0/0

  Service-policy input: QOS-MARKING

    Class-map: MARK-VOICE-BEARER (match-all)
      321326 packets, 44074699 bytes
      5 minute offered rate 811000 bps, drop rate 0 bps
      Match: access-group 105
      QoS Set
        precedence 5
          Packets marked 321337
        mpls experimental imposition 5
          Packets marked 321339
--------------------------------

However on the WAN side the matched ip precedence and mpls exp are not at
all equal. Given that this router is the only one marking traffic, why would
I have this difference of matches?
--------------------------------
Serial1/0:0

  Service-policy output: QOS-SCHEDULING

    Class-map: SCHEDULE-VOICE-BEARER (match-any)
      668075 packets, 85318946 bytes
      1 minute offered rate 986000 bps, drop rate 0 bps
      Match: ip precedence 5
        412577 packets, 65414519 bytes
        1 minute rate 789000 bps
      Match: mpls experimental  5
        255498 packets, 19904427 bytes
        1 minute rate 196000 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 1440 (kbps) Burst 36000 (Bytes)
        (pkts matched/bytes matched) 63/8916
        (total drops/bytes drops) 0/0
--------------------------------

Thank you.

Christophe

-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
Sent: Tuesday, August 21, 2007 10:33 AM
To: varaillon; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] QoS - questions

varaillon <> wrote on Tuesday, August 21, 2007 9:20 AM:

> I have few questions about queuing on Cisco.
> 
> 7200----HDLC/ISIS/TDP----26xx
> 
> I have set-up QoS between the two Cisco routers mainly use to carry
> voice traffic, as follow:
> 
> Queue1: Voice Bearer    - LLQ        - priority bandwidth 55%
> Queue2: Voice Signaling - CBWFQ      - bandwidth 10%
> Queue3: Any IP traffic  - CBWFQ WRED - bandwidth 10%
> Queue4: default
> 
> * If my LLQ queue is full, can it borrow bandwidth from any other non
> full queues including the default one?

No, "priority" implicitly configures a policer, and excess packets are
dropped.

> * If any of my CBWFQ queues is full, can it borrow bandwidth from any
> other non full queues including the default one?

Yes.

> If I use the command "max-reserved-bandwidth 90" on the serial
> outgoing interface of both routers, and if I have the following
> queues: 
> 
> Queue1: Voice Bearer    - LLQ        - priority bandwidth 70%
> Queue2: Voice Signaling - CBWFQ      - bandwidth 10%
> Queue3: Any IP traffic  - CBWFQ WRED - bandwidth 10%
> Queue4: default

Usually you don't want to provision more than 50% of your BW for LLQ.
Experience has shown that this can introduce some delay..

What would you put into the default class? See also comment below.

> What would happen in case of congestion:
> 
> * Since I know that I have very little IP traffic, Queue 3,
> guaranties that the TDP session won't go down, right?

well, since you enabled WRED, we could also drop TDP packets..

> * Since the default queue has the remaining 10% of the bandwidth,
> HDLC and ISIS won't go down, right?

well, first of all you also want to reserve BW there, i.e. add
"bandwidth percent 10" as well. Then check out
http://www.cisco.com/warp/public/105/rtgupdates.html to see how your
platform treats those packets.
 
> * So, in this case and despite Cisco advices on that matter, is it
> safe to use the "max-reserved-bandwidth 90" command?

I would think so. 

> * Do I risk to lose the serial link due to a lack of bandwidth?
> 
> * Do I risk anything else?

No, looks good with the above changes..

	oli


__________ NOD32 2472 (20070821) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com




More information about the cisco-nsp mailing list