From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Thu Sep 29 2005 - 14:25:09 GMT-3
This makes sense. WRED in NOT contingent on WFQ. The class can be
either WFQ or FIFO (bandwidth statement), but the class-default is a FIFO
queue with no bandwidth guarantee by default. I'm sure everyone knows that
the class-default is the only class that can run WFQ. WFQ and FIFO in the
default-class are mutually exclusive as well.
Sincerely,
Dennis J. Hartmann
White Pine Communications
dh8@pobox.com
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
-----Original Message-----
From: simon hart [mailto:simon@harttel.com]
Sent: Thursday, September 29, 2005 1:15 PM
To: Dennis J. Hartmann; gladston@br.ibm.com; 'Chris Lewis (chrlewis)'
Cc: ccielab@groupstudy.com
Subject: RE: WRED on Physical Interface and CBWFQ
Hi Dennis,
Random detect in class default needs fair queueing or a bandwidth statment,
see below
terminal_bb1(config)#policy qos
terminal_bb1(config-pmap)#class class-def terminal_bb1(config-pmap)#class
class-default terminal_bb1(config-pmap-c)#ran
terminal_bb1(config-pmap-c)#random-detect
fair-queue or bandwidth on the class is required to issue this command
Here is the output after adding a bandwidth statement
Policy Map qos
Class class-default
Traffic Shaping
Average Rate Traffic Shaping
CIR 64000 (bps) Max. Buffers Limit 1000 (Packets)
Bc 8000 Be 16000
Weighted Fair Queueing
Bandwidth 64 (kbps)
exponential weight 9
class min-threshold max-threshold mark-probablity
----------------------------------------------------------
0 20 40 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 - - 1/10
7 - - 1/10
rsvp - - 1/10
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Dennis J. Hartmann
Sent: 29 September 2005 13:18
To: gladston@br.ibm.com; 'Chris Lewis (chrlewis)'
Cc: ccielab@groupstudy.com
Subject: RE: WRED on Physical Interface and CBWFQ
CBWFQ, WRED, FIFO, and Fair-Queueing are ALL mutually exclusive at
the interface level. You can only have one configured. Each mechanism will
override the other. The router will take the configuration, but will
override the Queueing Strategy as displayed by the show interface command.
In CBWFQ, WRED is a congestion avoidance mechanism used within each
FIFO based class to prevent tail drop (avoid 100% class congestion). WFQ is
ONLY supported in the class-default. WFQ in the class default is REALLY
only doing fair queueing (it doesn't look at the weight which is derived
from the IP Precedence when configured at the interface level).
WRED can NOT be used with the queue-limit command in any of the
classes. WRED can be combined with the bandwidth command.
I was not aware of the fact that WRED can not be configured in the
class-default without WFQ configured. Can someone verify these results?
-Dennis Hartmann
CCVP/CCIP/CCNP/CCSI
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Thursday, August 11, 2005 9:51 AM
To: Chris Lewis (chrlewis)
Cc: ccielab@groupstudy.com
Subject: RE: WRED on Physical Interface and CBWFQ
Thanks for the reply Chris,
That is interesting. On the case you showed, IOS does not complain.
But it really disable fair-queue on physical, as Wendell says:
Rack2R5(config)#int ser 0/1
Rack2R5(config-if)#fair-queue
Rack2R5(config-if)#random-detect
Rack2R5(config-if)#do sh run int ser 0/1
interface Serial0/1
ip address 148.5.135.5 255.255.255.0
random-detect
Rack2R5(config-if)#do sh int ser 0/1
Serial0/1 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is 148.5.135.5/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: random early detection(RED)
5 minute input rate 2000 bits/sec, 0 packets/sec
5 minute output rate 2000 bits/sec, 0 packets/sec
1520 packets input, 1050047 bytes, 0 no buffer
Received 1516 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 1 frame, 0 overrun, 0 ignored, 0 abort
2666 packets output, 1166529 bytes, 0 underruns
0 output errors, 0 collisions, 15 interface resets
0 output buffer failures, 0 output buffers swapped out
30 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
On the opposite hand, fair-queue is required under CBWFQ class-default to
enable WRED. That is curious.
Cordially,
------------------------------------------------------------------
Gladston
"Chris Lewis \(chrlewis\)" <chrlewis@cisco.com>
11/08/2005 10:39
To
Alaerte Gladston Vidali/Brazil/IBM@IBMBR, <ccielab@groupstudy.com> cc
Subject
RE: WRED on Physical Interface and CBWFQ
Hi Gladston,
This looks like an order of operation issue. For the physical interface, if
you enter the commands in the same order as the class based configuration is
requesting them, the commands are accepted.
Starting here:
!
interface Serial1/0
ip address 131.108.50.1 255.255.0.0
!
The commands can be applied as follows:
R1(config)#int s1/0
R1(config-if)#fair-queue
R1(config-if)#random-detect
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Thursday, August 11, 2005 8:10 AM
To: ccielab@groupstudy.com
Subject: WRED on Physical Interface and CBWFQ
Hi,
Do you know what is the logic behind the following behavior of IOS?
Under class-default of CBWFQ, WRED requires fair-queue to be configured.
Under physical interface, WRED requires fair-queue to be removed.
Tests:
WRED applyed on class-default
Rack2R5(config-pmap)#class class-default
Rack2R5(config-pmap-c)#random-detect dscp-b fair-queue or bandwidth on the
class is required to issue this command Rack2R5(config-pmap-c)#fair-queue
Rack2R5(config-pmap-c)#random-detect
dscp-b
WRED applyed on physical:
Rack2R5(config-if)#int ser 0/1
Rack2R5(config-if)#fair-queue
Must remove RED configuration first.
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3