Hi everyone - My question is "why would you do it?" if the question only asks you to ensure that two devices are CDP neighbours and that is it, then there is no need. The proctor at Sydney said that nothing outside the scope of the question was looked at or verified, and any extra configuration was not looked at providing it didn't interfere with the working configuration. So to save time I would leave it alone in that case. After being through the lab and having finished the config section with 30 secs to go, I can definitely see that the extra 5-10 mins taken to reload a switch/s and verify everything has come back up again could hurt.
On 19/10/12 2:58 AM, "Bob McCouch" <[email protected]> wrote: >I would just do it! But a few minutes ago you said you wouldn't bother >unless the task mentioned a 1500-byte MTU so I was curious why you >lean that way vs the "safe" path. Just concern for the time of a >reboot? > >Bob >-- >Sent from my iPhone, please excuse any typos. > >On Oct 18, 2012, at 11:55 AM, Marko Milivojevic <[email protected]> >wrote: > >> It's a tough call to make really. The only correct answer must come >> from someone who's grading the lab. You know what needs to be done to >> be safe, so... why not just do it? >> >> -- >> Marko Milivojevic - CCIE #18427 (SP R&S) >> Senior CCIE Instructor - IPexpert >> >> On Thu, Oct 18, 2012 at 10:46 AM, Bob McCouch <[email protected]> wrote: >>> Ha, got me on that one! Yes, they'd need to specify the df-bit. >>> >>> Here's my question on interpretation then... Cisco's documentation on >>>QQ >>> tunneling states that you "must" bump the MTU: >>> >>> "Because the IEEE 802.1Q tunneling feature increases the frame size by >>>4 >>> bytes when the metro tag is added, you must configure all switches in >>>the >>> service-provider network to be able to process maximum frames by >>>increasing >>> the switch system MTU size to at least 1504 bytes." (emphasis mine, >>>source >>> >>>http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea >>>se/12.2_46_se/configuration/guide/swtunnel.html#wp1001068) >>> >>> With this in mind, should we not assume that means we have to do it, >>>as the >>> config guide states it as a "must"? Just like MTU on PPPoE interfaces >>>-- >>> I've configured PPPoE dialer interfaces just fine without specifying >>>1492 >>> MTU, but every time you see an official example config (or an IPExpert >>>DSG >>> solution as well!) they specify the MTU. I have assumed that means I >>>damn >>> well better do it too if I want points on such a task. >>> >>> What do you think, Marko? >>> >>> >>> On Thu, Oct 18, 2012 at 11:38 AM, Marko Milivojevic >>><[email protected]> >>> wrote: >>>> >>>> On Thu, Oct 18, 2012 at 9:30 AM, Bob McCouch <[email protected]> wrote: >>>>> And if the grading script used "ping X.X.X.X size 1500" to test? :-) >>>> >>>> It would still work, since packets would be fragmented ;-). On the >>>> other hand, if they added "df-bit" to that command... another story. >>>> >>>> That said - unless the lab asks for 1500-byte payload, I wouldn't >>>> bother with it. Then again, if you think rebooting a switch won't take >>>> from your time, why not do it and not worry? Just keep in mind that >>>> changing "system mtu" will change IP MTU as well, which may have >>>> impact for routing protocols running on the switch. Luckily, you can >>>> fix that without a reboot with "system mtu routing" >>>> >>>> -- >>>> Marko Milivojevic - CCIE #18427 (SP R&S) >>>> Senior CCIE Instructor - IPexpert >>>> >>>>> >>>>> How about routing adjacencies? Might OSPF get tripped up by neighbors >>>>> agreeing they have 1500 byte MTU, but not being able to actually pass >>>>> 1500 >>>>> during LSADB sync? >>>>> >>>>> The devil is in those details. >>>>> >>>>> >>>>> On Thu, Oct 18, 2012 at 10:24 AM, Mills, Derek < >>>>> [email protected]> wrote: >>>>> >>>>>> Good questions Bob and I guess I need to know the answers. Perhaps >>>>>>my >>>>>> downfall is that I would configure it, run a few various pings to >>>>>> verify >>>>>> the reachability requirement, and would count those points when >>>>>>there >>>>>> are >>>>>> no other lab requirements indicating that an mtu change is >>>>>> warranted.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> *From:* Bob McCouch [mailto:[email protected]] >>>>>> *Sent:* Thursday, October 18, 2012 9:17 AM >>>>>> *To:* Mills, Derek >>>>>> *Cc:* [email protected] >>>>>> *Subject:* Re: [OSL | CCIE_RS] Dot1q Tunnel and MTU**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Hi Derek,**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> You say "most times" and you are correct. What are the times it >>>>>> wouldn't >>>>>> work? How might those times bite you either while configuring later >>>>>> elements of your lab, or how they might test your solution with a >>>>>> grading >>>>>> script?**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> We must learn the right thing to do, even if IOS doesn't warn you >>>>>>about >>>>>> something. :-)**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> On Thu, Oct 18, 2012 at 9:01 AM, Mills, Derek < >>>>>> [email protected]> wrote:**** >>>>>> >>>>>> Most times configuring dot1q tunnel in the lab will work just fine >>>>>> without >>>>>> changing the MTU on the switches. What is the opinion on whether we >>>>>> should >>>>>> change it or not? If there is a specific task requirement for it >>>>>>there >>>>>> is >>>>>> no question, but is it expected and standard procedure just to >>>>>>increase >>>>>> it >>>>>> ALL the time when you configure it? Will you miss the points if you >>>>>> don't >>>>>> configure it? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> DEREK MILLS >>>>>> <>< >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>--------------------------------------------------------------------- >>>>>>--------------------------------------------------------------------- >>>>>>--------------------------------------------------------------------- >>>>>>---- >>>>>> Anheuser-Busch InBev Email Disclaimer www.ab-inbev.com >>>>>> _______________________________________________ >>>>>> For more information regarding industry leading CCIE Lab training, >>>>>> please >>>>>> visit www.ipexpert.com >>>>>> >>>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>>> www.PlatinumPlacement.com >>>>>> >>>>>> http://onlinestudylist.com/mailman/listinfo/ccie_rs**** >>>>>> >>>>>> ** ** >>>>>> ------------------------------ >>>>>> Anheuser-Busch InBev Email Disclaimer >>>>>> www.ab-inbev.com<http://www.ab-inbev.com/disclaimer.cfm> >>>>>> >>>>> _______________________________________________ >>>>> For more information regarding industry leading CCIE Lab training, >>>>> please visit www.ipexpert.com >>>>> >>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>> www.PlatinumPlacement.com >>>>> >>>>> http://onlinestudylist.com/mailman/listinfo/ccie_rs >>> >>> >_______________________________________________ >For more information regarding industry leading CCIE Lab training, please >visit www.ipexpert.com > >Are you a CCNP or CCIE and looking for a job? Check out >www.PlatinumPlacement.com > >http://onlinestudylist.com/mailman/listinfo/ccie_rs _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
