Thanks Marko, I guess I was over-thinking it.
On Mon, Apr 4, 2011 at 12:33 PM, Marko Milivojevic <[email protected]> wrote: > I don't think there is much to think about this particular question > and the extra configuration added. Whoever was solving the lab, > thought that using 802.1q over ISL was a better idea. Since not > specified nor restricted in the lab, it falls under "grading doesn't > care about this" category. > > While technically speaking it IS an extra and unnecessary > configuration, it's not the one you should dwell upon. > > -- > 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 Mon, Apr 4, 2011 at 07:02, marc abel <[email protected]> wrote: >> I understand that, this is just a case where it seems like they >> applied extra config for reasons that are unclear to me.If a question >> doesn't seem to ask for something, I don't want to apply extra config. >> I am just wondering if there is maybe a later dependency that I just >> can't see. >> >> It would be nice to have one of our experts weigh in on this topic. >> They seem to be quieter than usual lately. >> >> On Mon, Apr 4, 2011 at 8:37 AM, Jason Maynard <[email protected]> >> wrote: >>> Hey Marc, >>> Don't forget that there are at times more than one way to meet the >>> requirements. If you met the requirements and did not violate >>> any restriction then you would achieve the points. >>> The DSG will not show all possible solutions. >>> >>> On Sun, Apr 3, 2011 at 12:59 PM, marc abel <[email protected]> wrote: >>>> >>>> That is a good suggestion but I don't see it. Here are the requirements: >>>> >>>> >>>> Ensure that the lab switches are configured according to the layer 2 >>>> tables and diagrams (I don't see anything to indicate trunking >>>> encapsulation on any of the drawings or tables) >>>> >>>> All EtherChannel interfaces must be attempting to establish >>>> EtherChannel links using LACP. All inter-switch links should >>>> automatically negotiate trunking. Lower switch should wait >>>> higher-numbered switch before it starts trunking. >>>> >>>> Vlan-1112 should be allowed only links between Cat1 and Cat2. >>>> Vlan-1314 should be allowed only on links between Cat3 and Cat4. >>>> >>>> >>>> >>>> -Marc >>>> >>>> >>>> >>>> On Sun, Apr 3, 2011 at 11:48 AM, Don Lundquist <[email protected]> >>>> wrote: >>>> > To take a stab at this without review of the specific requirements >>>> > stated, my first question would be is there reference to how the tasks >>>> > are >>>> > worded... Does it state "use industry standards"...? LACP is an industry >>>> > standard and so is D1Q..? >>>> > >>>> > Don >>>> > >>>> > >>>> > On Apr 3, 2011, at 12:21, "marc abel" <[email protected]> wrote: >>>> > >>>> >> Vol 3 lab 2 requires dynamic trunking between the switches, and makes >>>> >> certain requirements about LACP on the port channels. I get all of >>>> >> this but am curious about 1 thing. >>>> >> >>>> >> The solutions guide shows specifying Dot1q as the encapsulation type. >>>> >> I don't see a requirement for this. Is there some later task that >>>> >> makes this necessary? I haven't been able to spot it yet if so. >>>> >> >>>> >> Or is it just extra config? Personal preference? >>>> >> >>>> >> Thank you, >>>> >> >>>> >> Marc >>>> >> _______________________________________________ >>>> >> For more information regarding industry leading CCIE Lab training, >>>> >> please visit www.ipexpert.com >>>> > >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, please >>>> visit www.ipexpert.com >>> >>> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
