RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi, Is it a MUST to configure 'fragmentation' (under 1.5M wan link) when enabling LLQ (for voip over frame-relay)? How about if One side connection is FR but another is just a simply leased line? Thanks. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=60939t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi Ivan, Comments within lines From: Ivan Yip Hi All, I am a little bit confused about LLQ. Below is my understanding after digesting some documentation and feedback from others. Please correct me if I'm wrong. 1. LLQ=PQ+CBWFQ and PQ is defined by using 'priority' You are correct. 2. if using 'bandwidth', then I'm not using LLQ. What I'm using is CBWFQ. You are only allowed to use the priority keyword with the PQ where its main concern is to forward packets as fast as it can. That's why no queue size is configured for it. As your main concern is latency so once the defined bandwidth you assigned for the PQ using the priority keyword is reached the PQ will start dropping immediately. The point here is: Dropping a voice packet is better than delivering it delayed - from the voice quality prespective - You start using the bandwidth keyword with the rest of the classes defined to indicate the usage of CBWFQ. Also you will need to use WRED in order to define min_threshold, max_threshold, and how fast you drop from each class via the exponentianl value defined. 3. PQ (from LLQ) defines the min. and max. guaranteed bandwidth to the traffic I defined during congestion. Not necessary during congestion. PQ is treated separetly from the CBWFQ to gurantee low latency for this type of traffic even in normal situations. Imagine a voice packet waiting for a long data packet to be transmitted. This will make the voice packet delayed - i.e. degradation in voice quality which we don't want to happen - this will lead to the fact that you will need to configure LFI to avoid long data packets delaying your voice. Also, do I need to define the class-default under policy? eg,policy-map 1 class 1 priority 80 class class-default fair-queue What's the difference if I'm not defining the class-default? Yes you need doing so. But when you do so you will also define the min_threshold, max_threshold of this class default. After all traffic classified in default class is not sentitive at all for delay and more packets could be kept in its queue without a noticable degradation in performance. For example: Policy-map out class A Bandwidth percent 50 random-detect random-detect exponential-weighting-constant 3 random-detect precedence 3 2 5 1 class class-default fair-queue random-detect random-detect exponential-weighting-constant 2 random-detect precedence 0 6 18 1 Yasser misconduct and Nondisclosure violations to [EMAIL PROTECTED] 3 months FREE*. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59952t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi, Please encure that LLQ( when u use Priority command) is supported on following IOS LLQ on Frame-Relay supported on Ver 12.1(2)T(Your config has frame-relay) and on other interfaces u need 12.0(7)T... -Original Message- From: Ivan Yip [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: FR Low Latency Queuing (LLQ) [7:59820] Hi, I would like to configure QoS by using FR LLQ. I have the following network test lab. pc1 --| ---router1FR network-router FTP server pc2---| I want to test the LLQ feature, ie, fixed bandwidth allocated to certain taffic. I tested with the following steps 1. upload from pc2 to FTP server to make the FR PVC congested. 2. then upload from pc1 to FTP server If no qos defined, the bandwidth will roughly equally shared. (This was tested and OK) 3. Then I define the LLQ on router1 to guarantee the bandwidth from PC1 by 'bandwidth' or 'priority' and test ftp upload again. Configuration is below: class-map match-all 1 match access-group 20 policy-map 1 class 1 bandwidth 80 or priority 80 (** define 80k to this policy) interface Serial0/0 bandwidth 128 no ip address encapsulation frame-relay IETF load-interval 30 no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 10.114.0.14 255.255.255.252 frame-relay interface-dlci 200 class llq1 map-class frame-relay llq1 frame-relay traffic-rate 128000 128000 no frame-relay adaptive-shaping frame-relay cir 128000 frame-relay bc 1280 frame-relay be 0 frame-relay mincir 128000 service-policy output 1 access-list 20 permit 192.168.10.2 (ip address of pc1) However, when I use 'bandwidth 80', I found the average throughput from pc1 will have around 80k but the traffic rate is vary from time to time. (somtimes 100k and sometimes 50k). Why? Even worse, if I use 'priority 80', the traffic from pc1 can only have average around 30k during link congestion. Why? Also, the ping delay from pc1 to router2 and pc2 to router2 are almost equal (either bandwidth or priority). I expected that the ping from pc1 will get better response as the bandwidth was guaranteed. Anyone can give me some hints on above questions? Thanks in advance. rgds, ivan **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *** Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59954t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi, I got the following information during debug. 128K_LL#debug priority Priority output queueing debugging is on 128K_LL# 3d01h: now 263877385 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877750 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877754 tokens 4288 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 3d01h: now 263878034 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263878307 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263878764 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263879040 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263879132 tokens 16000 pak_size 8096 max_token_limit 16000 3d01h: now 263879653 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880046 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263880202 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880202 tokens 3968 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 . Also, I found there is packet drops on the match ip address. The 'priority 80' is configured but there have a lot of dropped packets but default packet have no drop. Why? 128K_LL#show policy-map interface serial 0/0.1 Serial0/0.1: DLCI 200 - Service-policy output: 1 Class-map: 1 (match-all) 15552 packets, 16947920 bytes 30 second offered rate 3 bps, drop rate 7000 bps Match: access-group 21 Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 80 (kbps) Burst 2000 (Bytes) (pkts matched/bytes matched) 2531/1983899 (total drops/bytes drops) 333/495184 Class-map: class-default (match-any) 18281 packets, 22054542 bytes 30 second offered rate 104000 bps, drop rate 0 bps Match: any 128K_LL#show policy-map 1 Policy Map 1 Class 1 Strict Priority Bandwidth 80 (kbps) Burst 2000 (Bytes) It looks like the guaranteed bandwidth 80 was dropped first instead of the default packet? Why? Thanks again. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59936t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
This is something I am researching currently. I believe LLQ is CBWFQ+PQ and the PQ is strict. This means that anything above the allocated rate is dropped. This is fine for voice traffic where you reserve say 200kbps for 8 voice calls, and anything more than that is dropped, but not suitable for data applications. You will need to use CBWFQ for your data apps, not place them in the PQ. The CBWFQ will guarantee bandwidth to PC1 as you mention in your first post. I would say that the PQ only gives you 30k due to slow start after packet loss. Finally, why CBWFQ gives you sometimes 100k, sometimes 50k, - I can understand it giving you more than 80k, if there is more available, but I'm not sure why it gave you less. Perhaps the application or operating system applied some congestion control. I believe Win2k or XP does a lot of good work to not hog all of the WAN bandwidth. At this stage, I would question the appropriateness of FTP as an accurate traffic generation tool. As to the ping times, your bandwidth under the priority condition is only guaranteed up to the amount reserved. Anything above that is dropped if the Q is strict. PC1 would get better response if the ping traffic was in the PQ, but it isn't so it is placed in the same Q as all the FTP traffic. Then within the PQ, your ping has to sit at the end of a bunch of FTP data. I wouldn't be surprised if your ping traffic from PC1 was actually worse that PC2. PC2, under CBWFQ, would be more fair to small ping packets than many large FTP packets. Rik -Original Message- From: Ivan Yip [mailto:[EMAIL PROTECTED]] Sent: Monday, 30 December 2002 12:07 PM To: [EMAIL PROTECTED] Subject: RE: FR Low Latency Queuing (LLQ) [7:59820] Hi, I got the following information during debug. 128K_LL#debug priority Priority output queueing debugging is on 128K_LL# 3d01h: now 263877385 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877750 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877754 tokens 4288 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 3d01h: now 263878034 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263878307 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263878764 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263879040 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263879132 tokens 16000 pak_size 8096 max_token_limit 16000 3d01h: now 263879653 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880046 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263880202 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880202 tokens 3968 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 . Also, I found there is packet drops on the match ip address. The 'priority 80' is configured but there have a lot of dropped packets but default packet have no drop. Why? 128K_LL#show policy-map interface serial 0/0.1 Serial0/0.1: DLCI 200 - Service-policy output: 1 Class-map: 1 (match-all) 15552 packets, 16947920 bytes 30 second offered rate 3 bps, drop rate 7000 bps Match: access-group 21 Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 80 (kbps) Burst 2000 (Bytes) (pkts matched/bytes matched) 2531/1983899 (total drops/bytes drops) 333/495184 Class-map: class-default (match-any) 18281 packets, 22054542 bytes 30 second offered rate 104000 bps, drop rate 0 bps Match: any 128K_LL#show policy-map 1 Policy Map 1 Class 1 Strict Priority Bandwidth 80 (kbps) Burst 2000 (Bytes) It looks like the guaranteed bandwidth 80 was dropped first instead of the default packet? Why? Thanks again. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59942t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi All, Thanks all information. I am a little bit confused about LLQ. Below is my understanding after digesting some documentation and feedback from others. Please correct me if I'm wrong. 1. LLQ=PQ+CBWFQ and PQ is defined by using 'priority' 2. if using 'bandwidth', then I'm not using LLQ. What I'm using is CBWFQ. 3. PQ (from LLQ) defines the min. and max. guaranteed bandwidth to the traffic I defined during congestion. Also, do I need to define the class-default under policy? eg,policy-map 1 class 1 priority 80 class class-default fair-queue What's the difference if I'm not defining the class-default? Thanks again. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59948t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi Ivan, Your configuration is ok,But I want want to stress that when you configure Bandwidth command under class-map you achieve CBWFQ and When u are configuring Priority command under class-map you are achieving LLQ. As you might know that both this method are congestion management Technique i.e your defined traffic will be limited to 80kbps only when the network encounters congestion and is under congestive state (other wise it may go upto 128kbps ur CIR).. If your intention is to always limit the defined traffic to 80kbps use Rate-Limiting. So please ensure that you are simulating congestion in ur setup to verify CBWFQ LLQ.How much traffic are u pumping per sec to simulate congestion ? Kind Regards /Thangavel -Original Message- From: Ivan Yip [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 12:06 PM To: [EMAIL PROTECTED] Subject: FR Low Latency Queuing (LLQ) [7:59820] Hi, I would like to configure QoS by using FR LLQ. I have the following network test lab. pc1 --| ---router1FR network-router FTP server pc2---| I want to test the LLQ feature, ie, fixed bandwidth allocated to certain taffic. I tested with the following steps 1. upload from pc2 to FTP server to make the FR PVC congested. 2. then upload from pc1 to FTP server If no qos defined, the bandwidth will roughly equally shared. (This was tested and OK) 3. Then I define the LLQ on router1 to guarantee the bandwidth from PC1 by 'bandwidth' or 'priority' and test ftp upload again. Configuration is below: class-map match-all 1 match access-group 20 policy-map 1 class 1 bandwidth 80 or priority 80 (** define 80k to this policy) interface Serial0/0 bandwidth 128 no ip address encapsulation frame-relay IETF load-interval 30 no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 10.114.0.14 255.255.255.252 frame-relay interface-dlci 200 class llq1 map-class frame-relay llq1 frame-relay traffic-rate 128000 128000 no frame-relay adaptive-shaping frame-relay cir 128000 frame-relay bc 1280 frame-relay be 0 frame-relay mincir 128000 service-policy output 1 access-list 20 permit 192.168.10.2 (ip address of pc1) However, when I use 'bandwidth 80', I found the average throughput from pc1 will have around 80k but the traffic rate is vary from time to time. (somtimes 100k and sometimes 50k). Why? Even worse, if I use 'priority 80', the traffic from pc1 can only have average around 30k during link congestion. Why? Also, the ping delay from pc1 to router2 and pc2 to router2 are almost equal (either bandwidth or priority). I expected that the ping from pc1 will get better response as the bandwidth was guaranteed. Anyone can give me some hints on above questions? Thanks in advance. rgds, ivan **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59826t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi, Thanks your information. My goal is to make sure from certain source ip (eg, voice gateway) to have guaranteed bandwidth under link congestion. Under normal cases, it can up to 128k. Therefore, 'rate-limit' is not my solution. Due to limited resources, pc2 will upload dummy ftp traffic to the server to make the link congested (As the FR is only 128k, so it can be easily get congested). Afterwards, I will upload from PC1 (source ip defined to have LLQ) to test the LLQ. However, the result was not my expected. The traffic from PC1 was not guaranteed. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59827t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: FR Low Latency Queuing (LLQ) [7:59820]
Hi, Use debug priority (for LLQ)while simulating and see if u get any info.. -Original Message- From: Ivan Yip [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 3:28 PM To: [EMAIL PROTECTED] Subject: RE: FR Low Latency Queuing (LLQ) [7:59820] Hi, Thanks your information. My goal is to make sure from certain source ip (eg, voice gateway) to have guaranteed bandwidth under link congestion. Under normal cases, it can up to 128k. Therefore, 'rate-limit' is not my solution. Due to limited resources, pc2 will upload dummy ftp traffic to the server to make the link congested (As the FR is only 128k, so it can be easily get congested). Afterwards, I will upload from PC1 (source ip defined to have LLQ) to test the LLQ. However, the result was not my expected. The traffic from PC1 was not guaranteed. rgds, ivan **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *** Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59828t=59820 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
