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:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 2:36 PM To: varaillon; [email protected] Subject: RE: [c-nsp] QoS - questions varaillon <mailto:[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Tuesday, August 21, 2007 10:33 AM > To: varaillon; [email protected] > 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
