[c-nsp] QoS - questions

[varaillon]

Ok, we have both MPLS and IP traffic going through our WAN interface, so
this is why I have that differences of matches in my QoS counters.

Thank you so much for your collaboration!

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

varaillon <mailto:j.varaillon at cosmoline.com> wrote on Tuesday, August
21, 2007 10:51 AM:

> 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?

Are you sending both IP and MPLS packets over this interface? 

can you do a "clear counter", check both counters again and compare them
with "show int accounting"? Which platform is this? config?

	oli

> --------------------------------
> 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


__________ NOD32 2472 (20070821) Information __________

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