Got it, thanks again! As I said, its been a long day here! On Thu, Oct 7, 2010 at 5:36 PM, Di Bias, Steve <[email protected]>wrote:
> Hey Mike, > > > > It seems like you are confusing WFQ with CBWFQ since you are talking about > class-maps, and in this case it would work. However that being said the task > is about enabling flow based WRED on FastEthernet interfaces which use FIFO > by default. Also the task never mentions WFQ or CBQFQ. > > I do apologize I was in a hurry when I posted the link, however looking in > the CCIE R&S study guide, Chapter 15: Congestion Management and Avoidance on > page 542 you can read the following: > > > > “Because WRED manages drops based on queue depth, WRED must be configured > alongside a particular queue. However, most queuing mechanisms do NOT > support WRED; as a result WRED can be configured only in the following > locations” > > > > On a physical interface (with FIFO queuing) > > For a non-LLQ class inside a CBWFQ policy map > > For an ATM VC > > > > “To use WRED on a physical interfaces, IOS actually disables ALL other > queuing mechanisms and creates a single FIFO queue” > > > > So you are correct that it can be configured using CBWFQ however not WFQ. > > > > This is why I’m asking Marko and Tyson if it’s a mistake in the DSG or if > there is a reason unbeknownst to me why it’s in there?? > > > > Thank you, > > > > Steve Di Bias > > Network Engineer - Information Systems > > *Valley Health System – Las Vegas* > > *Office* - 702- 369-7594 > > *Cell* - 702-241-1801 > > [email protected] > > > > *From:* Michael Miller [mailto:[email protected]] > *Sent:* Thursday, October 07, 2010 7:59 AM > *To:* Di Bias, Steve; [email protected] > > *Subject:* Re: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > > > > In your original message, you said "At first I thought I made a mistake but > researching I see that WFQ and WRED can NOT be enabled on the same interface > (which makes sense)." I've looked at that link, and I believe you are > referring to the following passage, when you say that WRED is not compatible > with WFQ: > > > > "You cannot configure WRED on the same interface as Route Switch Processor > (RSP)-based custom queueing (CQ), priority queueing (PQ), or weighted fair > queueing (WFQ). However, you can configure both DWRED and DWFQ on the same > interface." > > > > The key, it would seem is in the qualification of "Route Switch Processor > (RSP)-based." According to Cisco: > http://www.cisco.com/en/US/products/hw/modules/ps3842/ps3843/index.html RSP > is used in the 7500 series routers, which as you know are not on the exam. > > > > In my (again, CCNP level) opinion, it is possible to apply WRED to WFQ. In > fact, I have seen class maps in production that do just that. Furthermore, > in my ONT certification guide, I see several example configurations (see > page 159 Example 5-1) that have a class-default with both fair-queue and > random-detect enabled. > > Finally, to quote the document that you listed: > > > > "The Cisco IOS software provides two forms of WFQ: > > •Standard WFQ, which is enabled by default on all serial interfaces that > run at or below 2 Mbps, and can run on all Cisco serial interfaces...." > > Once again, any interface which runs at E1 (my mistake in my previous > message...) speed or lower uses WFQ by default. According to the link that > you provided, WRED is on by default on these exact interfaces. > > Thanks, > > > > Michael > > > > On Thu, Oct 7, 2010 at 3:29 PM, Di Bias, Steve <[email protected]> > wrote: > > > Michael thanks for the response. While at first i may have agreed with you > my research tells me otherwise. In the link i provided in my previous email > it states that WFQ and WRED can not be configured on the same interface. > > Also although the DSG does show it using both WFQ and flow based WRED the > vide walk through for this task does not. > > When i configured the interfaces i only used random detect commands, if i > was wrong in my configuration i need to know why. > > > > Sent from my T-Mobile myTouch 3G Slide > > ----- Reply message ----- > From: "Michael Miller" <[email protected]> > Date: Thu, Oct 7, 2010 1:47 am > > > Subject: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > To: "Di Bias, Steve" <[email protected]>, " > [email protected]" <[email protected]> > > I'll take a shot at this, but I haven't gotten this far in my CCIE studies. > > > > I believe I recall from my CCNP studies that fair-queue sets the queueing > mechanism, while random-detect applies Random Early Detection (WRED) to the > queues that have been configured. I also recall that the default queueing > mechanism for any high speed link (>T1) is FIFO. Apparently the router will > not allow you to change the type of queue while the RED is applied, however > after you remove RED you are able to select Fair Queueing. Finally, you are > able to reapply the RED to the newly configured queues. > > > > Thanks, > > > > Michael > > > > > > > > On Thu, Oct 7, 2010 at 6:01 AM, Di Bias, Steve <[email protected]> > wrote: > > Guys, > > > > My original question is why does the DSG show the configuration like this? > > > > interface Ethernet0/0 > > fair-queue > > random-detect > > random-detect flow > > random-detect flow count 128 > > random-detect flow average-depth-factor 16 > > > > At first I thought I made a mistake but researching I see that WFQ and WRED > can NOT be enabled on the same interface (which makes sense). > > > > http://tinyurl.com/25f9mk8 > > > > So that being said using the command “fair-queue” before using the command > “random-detect” makes ZERO sense to me. Also I just checked the WB1 video > walk through and the “fair-queue” command was not used there. > > > > So my question again is what is the purpose of doing it this way? Is it a > mistake in the DSG? > > > > Thanks in advance > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Di Bias, Steve > *Sent:* Wednesday, October 06, 2010 5:27 PM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* Re: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > > > > Got ya, but why does the dsg show us configuring fair queue then random > detect after?? > > Sent from my T-Mobile myTouch 3G Slide > > ----- Reply message ----- > From: "Marko Milivojevic" <[email protected]> > Date: Wed, Oct 6, 2010 5:12 pm > Subject: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > To: "Di Bias, Steve" <[email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" <[email protected]> > > Routers don't support RED, only WRED :-) > > -- > Marko Milivojevic - CCIE #18427 > Senior Technical Instructor - IPexpert > > FREE CCIE training: http://bit.ly/vLecture > > Mailto: [email protected] > Telephone: +1.810.326.1444 > Web: http://www.ipexpert.com/ > > On Wed, Oct 6, 2010 at 20:07, Di Bias, Steve <[email protected]> > wrote: > > Tyson looks like i configured RED instead of WRED? > > > > Sent from my T-Mobile myTouch 3G Slide > > > > ----- Reply message ----- > > From: "Di Bias, Steve" <[email protected]> > > Date: Wed, Oct 6, 2010 4:56 pm > > Subject: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > > To: "[email protected]" <[email protected]>, > > "[email protected]" <[email protected]> > > > > So by doing that you proved that you cant enable fair queue after random > > detect but that you can enable random detect after fair queue. > > > > I get that but whats the signifigance? > > > > Sent from my T-Mobile myTouch 3G Slide > > > > ----- Reply message ----- > > From: "Tyson Scott" <[email protected]> > > Date: Wed, Oct 6, 2010 4:45 pm > > Subject: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > > To: "Di Bias, Steve" <[email protected]>, > > "[email protected]" <[email protected]> > > > > R1(config)#int f0/0 > > > > R1(config-if)#rand > > > > R1(config-if)#random-detect > > > > R1(config-if)#fair > > > > R1(config-if)#fair-queue > > > > Must remove RED configuration first. > > > > R1(config-if)#no ran > > > > R1(config-if)#no random-detect > > > > R1(config-if)#fair-queue > > > > R1(config-if)#random-detect > > > > R1(config-if)# > > > > *Oct 7 01:32:21.807: %LINEPROTO-5-UPDOWN: Line protocol on Interface > > FastEthernet0/0, changed state to down > > > > R1(config-if)# > > > > *Oct 7 01:32:25.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface > > FastEthernet0/0, changed state to up > > > > R1(config-if)#do sh int f0/0 | incl Qu > > > > Queueing strategy: random early detection(RED) > > > > R1(config-if)# > > > > > > > > Regards, > > > > > > > > Tyson Scott - CCIE #13513 R&S, Security, and SP > > > > Managing Partner / Sr. Instructor - IPexpert, Inc. > > > > Mailto: [email protected] > > > > Telephone: +1.810.326.1444, ext. 208 > > > > Live Assistance, Please visit: www.ipexpert.com/chat > > > > eFax: +1.810.454.0130 > > > > > > > > IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, > > Audio Tools, Online Hardware Rental and Classroom Training for the Cisco > > CCIE (R&S, Voice, Security & Service Provider) certification(s) with > > training locations throughout the United States, Europe, South Asia and > > Australia. Be sure to visit our online communities at > > www.ipexpert.com/communities and our public website at www.ipexpert.com > > > > > > > > From: [email protected] > > [mailto:[email protected]<[email protected]>] > On Behalf Of Di Bias, Steve > > Sent: Wednesday, October 06, 2010 6:03 PM > > To: [email protected] > > Subject: [OSL | CCIE_RS] WB1 Lab 21 Task 4 > > > > > > > > Hey Everyone! > > > > > > > > In this task we are asked to configure flow-based WRED on the Ethernet > > interfaces of R6, however what I have doesn’t match the DSG. > > > > > > > > In the DSG it shows the first command as “fair-queue” then > “random-detect” > > however don’t these two statements conflict with one another? > > > > > > > > Currently my interface queuing shows like this > > > > > > > > R6(config-if)#do sh int e0/0 | i Que > > > > Queueing strategy: random early detection(RED) > > > > > > > > If you try to go back and configure fair-queue on top of it you get the > > following message > > > > > > > > R6(config-if)#fair-queue > > > > Must remove RED configuration first. > > > > > > > > Seems like a mistake? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > UHS Confidentiality Notice: This e-mail message, including any > attachments, > > is for the sole use of the intended recipient(s) and may contain > > confidential and privileged information. Any unauthorized review, use, > > disclosure or distribution of this information is prohibited, and may be > > punishable by law. If this was sent to you in error, please notify the > > sender by reply e-mail and destroy all copies of the original message. > > > > > > UHS Confidentiality Notice: This e-mail message, including any > attachments, > > is for the sole use of the intended recipient(s) and may contain > > confidential and privileged information. Any unauthorized review, use, > > disclosure or distribution of this information is prohibited, and may be > > punishable by law. If this was sent to you in error, please notify the > > sender by reply e-mail and destroy all copies of the original message. > > > > > > UHS Confidentiality Notice: This e-mail message, including any > attachments, > > is for the sole use of the intended recipient(s) and may contain > > confidential and privileged information. Any unauthorized review, use, > > disclosure or distribution of this information is prohibited, and may be > > punishable by law. If this was sent to you in error, please notify the > > sender by reply e-mail and destroy all copies of the original message. > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, please > > visit www.ipexpert.com > > > > > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. > > > > > > UHS Confidentiality Notice: This e-mail message, including any attachments, > is for the sole use of the intended recipient(s) and may contain > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution of this information is prohibited, and may be > punishable by law. If this was sent to you in error, please notify the > sender by reply e-mail and destroy all copies of the original message. >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
