From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu May 12 2005 - 21:33:38 GMT-3
Hi Dave,
> No disrespect intended. I wasn't aware that your new WB was supposed
to
> be beyond what one might see in the lab.
None taken. What I mean to say is that Volume II is designed
that way on purpose. Think of Volume II as "extra credit" beyond Volume
I. On our difficulty scale of 1 - 10 all the labs in Volume II are
rated "10+". Hopefully for the CCIE candidate's sake you would not see
questions of that level in the actual exam ;)
For example some of the labs in IEWB-RS Volume II have over 20
points (out of 100) of IPv6. Is this realistic of the actual lab today?
I would venture a guess that 20 points in IPv6 is highly unlikely, but
what it *will* do is make sure that you are 100% comfortable with
configuring IPv6 above and beyond what's within the scope of the lab.
This way if you do get IPv6 in the actual lab it will be a piece of
cake.
While Brian Dennis and I have always subscribed to the
philosophy that harder is not always better, we've found that a
significant portion of the CCIE community does not. So... you guys want
hard labs, you've got it ;)
Thanks,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Dave Bregman [mailto:DBregman@Houstons.com]
> Sent: Thursday, May 12, 2005 7:22 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Cc: bstrt2002@gmail.com
> Subject: RE: dot.1q tunneling - IE Vol II, lab 9, task 1.4
>
> Brian,
>
> No disrespect intended. I wasn't aware that your new WB was supposed
to
> be beyond what one might see in the lab. Having just passed the test,
> I've been spending the last several months focusing on problems one
> might actually be expected to solve during the lab.
>
> That's why I guess I was looking for the "simple" solution. It seems
> the actual one is way more complex than what I was thinking.
Excellent
> problem. :-)
>
> Dave Bregman CCIE #14626
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf Of Brian McGahan
> > Sent: Thursday, May 12, 2005 4:49 PM
> > To: ccielab@groupstudy.com
> > Cc: Dave Bregman; bstrt2002@gmail.com
> > Subject: RE: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> >
> >
> > Dave,
> >
> > > While I think this is an excellent question, and I've been stewing
> > about
> > > it for several hours. IMHO it's way beyond what I think
> > you might see
> > > on the lab. YMMV.
> >
> > The topics covered in our new IEWB-RS Volume II are clearly
> > beyond the scope of topics that you would see in the actual
> > lab, and are
> > mainly designed to test your advanced problem solving skills.
> >
> > Jongsoo is correct, the answer is to modify the native VLAN. If
> > SW1 says that the native VLAN is 2, and SW2 says that the
> > native VLAN is
> > 200, 2 & 200 are the same broadcast domain. The 3550 is programmed
to
> > detect this error (through STP) and disable the trunk link,
> > so STP must
> > be disabled. Pruning is also enabled so these VLANs must be removed
> > from the prune-eligible list to prevent their removal from the trunk
> > link.
> >
> > Here is the solution:
> >
> > SW1:
> > no spanning-tree vlan 2
> > !
> > interface Port-channel1
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 2
> > switchport trunk pruning vlan 2-199,201-1001
> > switchport mode trunk
> > !
> > interface FastEthernet0/13
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 2
> > switchport trunk pruning vlan 2-199,201-1001
> > switchport mode trunk
> > channel-group 1 mode on
> > !
> > interface FastEthernet0/14
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 2
> > switchport trunk pruning vlan 2-199,201-1001
> > switchport mode trunk
> > channel-group 1 mode on
> > !
> > interface FastEthernet0/15
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 2
> > switchport trunk pruning vlan 2-199,201-1001
> > switchport mode trunk
> > channel-group 1 mode on
> >
> > SW2:
> > no spanning-tree vlan 200
> > !
> > interface Port-channel1
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 200
> > switchport trunk pruning vlan 3-1001
> > switchport mode trunk
> > !
> > interface FastEthernet0/13
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 200
> > switchport trunk pruning vlan 3-1001
> > switchport mode trunk
> > channel-group 1 mode on
> > !
> > interface FastEthernet0/14
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 200
> > switchport trunk pruning vlan 3-1001
> > switchport mode trunk
> > channel-group 1 mode on
> > !
> > interface FastEthernet0/15
> > switchport trunk encapsulation dot1q
> > switchport trunk native vlan 200
> > switchport trunk pruning vlan 3-1001
> > switchport mode trunk
> > channel-group 1 mode on
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > Dave Bregman
> > > Sent: Thursday, May 12, 2005 6:39 PM
> > > To: ccielab@groupstudy.com
> > > Subject: RE: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > >
> > > I think Josh is on the right track. It only has to do with
> > broadcast
> > > traffic. Let's work backwards. Broadcast traffic is not normally
> > > forwarded between vlans. The only way it would be is if
> > there were a
> > > bridge between the vlans. Therefore, it has to be some form of
vlan
> > > bridging.
> > >
> > > While I think this is an excellent question, and I've been stewing
> > about
> > > it for several hours. IMHO it's way beyond what I think
> > you might see
> > > on the lab. YMMV.
> > >
> > > Dave Bregman
> > > CCIE #14626
> > >
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > > Behalf Of joshua lauer
> > > > Sent: Thursday, May 12, 2005 4:06 PM
> > > > To: Jongsoo kim; Brian McGahan
> > > > Cc: Group Study; ccie2be
> > > > Subject: Re: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > >
> > > >
> > > > Hey guys,
> > > >
> > > > I think I have a clue, it only mentioned broadcast traffic in
the
> > > > question....not all traffic. I dont know the answer
> > either, but I'll
> > > > hopefully find out shortly...It's a good one but I think I've
> > > > seen this type
> > > > of thing before I just cant remember where or why.
> > > >
> > > > josh
> > > >
> > > >
> > > > JOSHUA LAUER
> > > > ----- Original Message -----
> > > > From: "Jongsoo kim" <bstrt2002@gmail.com>
> > > > To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> > > > Cc: "Group Study" <ccielab@groupstudy.com>; "ccie2be"
> > > > <ccie2be@nyc.rr.com>
> > > > Sent: Thursday, May 12, 2005 7:01 PM
> > > > Subject: Re: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > >
> > > >
> > > > > Brian
> > > > > OK
> > > > > it is a tough one as Tim is struggling.
> > > > > If I summarize the requirement in my understanding,
> > > > > SW2 fowards a broadcast frame from vlan2 to the vlan 200
> > > > > SW1 forwards a broadcast frame from vlan 200 to vlan 2
> > > > > This basically rules out fallback-bridging option because
> > > > if bridges arer
> > > > > configured on SW1 and 2 between vlan 2 and 200, STP will do
> > > > its job by
> > > > > blocking one of two bridge and if I configue bridge on one
> > > > sw, then it
> > > > > wouldn't meet the requirement because both SWs need to
> > > > allow intervlan
> > > > > access.
> > > > > Hmm, I can't think of another method allowing intervlan
> > > > traffic. But I saw
> > > > > via some other email, using native vlan 802.1q trunk
> > > > between two SWs.
> > > > > I initaiily thought trunk may failed if native valn
> > > > mismatched but if
> > > > > trunk
> > > > > is manually configured, it may be ok.
> > > > > I also check CCO saying
> > > > > "Make sure the native VLAN for an 802.1Q trunk is the same
> > > > on both ends of
> > > > > the trunk link. If the native VLAN on one end of the trunk
> > > > is different
> > > > > from
> > > > > the native VLAN on the other end, spanning-tree loops might
> > result"
> > > > >
> > > > http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1222
> > > > 5se/3550scg/swv
> > > > > lan.htm#wp1200245
> > > > > So mismatching native vlan seems OK as long as there is no
> > > > potential SPT
> > > > > loop.
> > > > > Having said that, Maybe lets say F0/23 on SW1 and SW2 are
> > > > connected via
> > > > > 802.1q and assuming there is no vlan 200 in SW1 and no vlan
> > > > 2 in SW2.
> > > > > What about the below?
> > > > > SW2
> > > > > F0/23
> > > > > switchport mode trunk
> > > > > switchport trunk encapsulation dot1q
> > > > > switchport trunk native vlan 200
> > > > > SW1
> > > > > F0/23
> > > > > switchport mode trunk
> > > > > switchport trunk encapsulation dot1q
> > > > > switchport trunk native vlan 2
> > > > > In this way, SW2 will assume any untagged traffic received
> > > > via F0/23 as
> > > > > vlan 200
> > > > > and SW1 will assume any untagged traffic received via F0/23
> > > > as vlan 2.
> > > > > Let me know right or wrong for now as I am having fun
> > with this :)
> > > > > Jongsoo
> > > > >
> > > > >
> > > > > On 5/12/05, Brian McGahan
> > <bmcgahan@internetworkexpert.com> wrote:
> > > > >>
> > > > >> No BVI. Here is the task for the benefit of the group:
> > > > >>
> > > > >> 1.4. The port attached to R2 on SW1 is assigned to VLAN 2,
> > > > while the port
> > > > >> attached to BB2 on SW2 is assigned to VLAN 200. Configure
> > > > the network so
> > > > >> that when SW2 receives a broadcast frame originated in
> > > > VLAN 2 on SW1 it
> > > > >> is
> > > > >> forwarded to BB2, and when SW1 receives a broadcast frame
> > > > originated in
> > > > >> VLAN
> > > > >> 200 on SW2 it is forwarded to R2.
> > > > >>
> > > > >> 4 Points
> > > > >>
> > > > >>
> > > > >> Brian McGahan, CCIE #8593
> > > > >> bmcgahan@internetworkexpert.com
> > > > >>
> > > > >> Internetwork Expert, Inc.
> > > > >> http://www.InternetworkExpert.com
> > > > >> Toll Free: 877-224-8987 x 705
> > > > >> Outside US: 775-826-4344 x 705
> > > > >> 24/7 Support: http://forum.internetworkexpert.com
> > > > >> Live Chat: http://www.internetworkexpert.com/chat/
> > > > >>
> > > > >> ________________________________________
> > > > >> From: Jongsoo kim [mailto:bstrt2002@gmail.com]
> > > > >> Sent: Thursday, May 12, 2005 4:56 PM
> > > > >> To: Brian McGahan
> > > > >> Cc: ccie2be; Group Study
> > > > >> Subject: Re: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > > >>
> > > > >> Brian
> > > > >>
> > > > >> What about BVI interface in router?
> > > > >>
> > > > >>
> > > > >> On 5/12/05, Brian McGahan <bmcgahan@internetworkexpert.com>
> > wrote:
> > > > >> Tim,
> > > > >>
> > > > >> Neither fallback bridging nor .1q tunneling are the solution
;)
> > > > >>
> > > > >> HTH,
> > > > >>
> > > > >> Brian McGahan, CCIE #8593
> > > > >> bmcgahan@internetworkexpert.com
> > > > >>
> > > > >> Internetwork Expert, Inc.
> > > > >> http://www.InternetworkExpert.com
> > > > >> Toll Free: 877-224-8987 x 705
> > > > >> Outside US: 775-826-4344 x 705
> > > > >> 24/7 Support: http://forum.internetworkexpert.com
> > > > >> Live Chat: http://www.internetworkexpert.com/chat/
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: nobody@groupstudy.com
> > > > [mailto:nobody@groupstudy.com ] On Behalf
> > > > >> Of
> > > > >> > ccie2be
> > > > >> > Sent: Thursday, May 12, 2005 4:00 PM
> > > > >> > To: 'Jongsoo kim'; Group Study; Brian McGahan; Brian Dennis
> > > > >> > Subject: RE: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > > >> >
> > > > >> > Hi Jongsoo,
> > > > >> >
> > > > >> > I tried your config but, alas, it didn't work.
> > > > >> >
> > > > >> > I also tried using that same config on both switches but
> > > > that didn't
> > > > >> work
> > > > >> > either.
> > > > >> >
> > > > >> > What bothers me most is that even if this did work, I
> > > > can't figure out
> > > > >> how
> > > > >> > it would.
> > > > >> >
> > > > >> > BTW, I didn't change anything on the rtr's on either side
of
> > the
> > > > >> Cat's.I
> > > > >> > left those interfaces with just the ip address configured.
> > > > >> >
> > > > >> > When you think about it, this I don't believe this
> > should work.
> > > > >> Here's my
> > > > >> > thinking.
> > > > >> >
> > > > >> > Fallback bridging is for NON IP traffic ie non-routable
> > traffic.
> > > > >> >
> > > > >> > But, for this scenario to work properly, I need to be
> > > > able to ping
> > > > >> from
> > > > >> > rtr-1 to rtr-2.
> > > > >> >
> > > > >> > Now, the Cat port connected to rtr-1 is configured to be
> > > > in vlan 2 and
> > > > >> the
> > > > >> > cat port connected to rtr-2 is in vlan 20.
> > > > >> >
> > > > >> > And, the cat's are trunked together via 802.1q
> > > > >> >
> > > > >> > With Fallback bridging configured, what happens to a
> > > > packet from rtr-1
> > > > >> > when
> > > > >> > Cat-1 gets it?
> > > > >> >
> > > > >> > Since it's an ip packet, I think the cat will process it
> > > > just like any
> > > > >> > normal ethernet frame ie it will see if the dest mac
> > > > addr is in the
> > > > >> mac
> > > > >> > table for vlan 2.
> > > > >> >
> > > > >> > Not finding it there, it will send it to all ports in
> > > > vlan 2 including
> > > > >> the
> > > > >> > trunk port connecting the 2 Cat's.When the 2nd Cat gets
> > > > it, I think
> > > > >> Cat-
> > > > >> > 2
> > > > >> > will drop it as it won't find that dest mac addr in it's
> > > > vlan 2 table
> > > > >> even
> > > > >> > though vlan 2 is bridged to vlan 20.
> > > > >> >
> > > > >> > What do you think?
> > > > >> >
> > > > >> > Tim
> > > > >> >
> > > > >> > _____
> > > > >> >
> > > > >> > From: Jongsoo kim [mailto:bstrt2002@gmail.com ]
> > > > >> > Sent: Thursday, May 12, 2005 3:53 PM
> > > > >> > To: ccie2be
> > > > >> > Subject: Re: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > > >> >
> > > > >> > I am doing fine.
> > > > >> >
> > > > >> > Can you just do something like the below on one of switch
> > without
> > > > >> > configuring ip address?
> > > > >> >
> > > > >> > interface Vlan 2
> > > > >> > bridge-group 1
> > > > >> > interface Vlan 20
> > > > >> > bridge-group 1
> > > > >> > bridge 1 protocol vlan-bridge
> > > > >> >
> > > > >> >
> > > > >> > Jongsoo
> > > > >> >
> > > > >> > On 5/12/05, ccie2be <ccie2be@nyc.rr.com> wrote:
> > > > >> > Hey Jongsoo,
> > > > >> >
> > > > >> > It's good to hear from you.I hope you're doing well.As
> > > > for me, I'm
> > > > >> > working through the new IE practice labs as you can see.
> > > > >> >
> > > > >> > At the moment, I'm working on labs for which the
> > > > Solutions haven't as
> > > > >> yet
> > > > >> > been posted.
> > > > >> >
> > > > >> > I considered using Fallback Bridging to fulfill this
> > > > task but I can't
> > > > >> see
> > > > >> > how to use it as there are no L3 Cat ports involved in
> > > > this config.
> > > > >> >
> > > > >> > Fallback Bridging requires that L3 ports be put into a
> > > > bridge-group.
> > > > >> In
> > > > >> > this scenario, I could make the port connecting rtr-1 or
> > > > rtr-2 a L3
> > > > >> port
> > > > >> > but
> > > > >> > what about the trunk connecting the 2 Cat's?
> > > > >> >
> > > > >> > If you have any ideas, please show me what you would
> > configure.
> > > > >> >
> > > > >> > Thanks, Tim
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > _____
> > > > >> >
> > > > >> > From: Jongsoo kim [mailto: bstrt2002@gmail.com]
> > > > >> > Sent: Thursday, May 12, 2005 1:22 PM
> > > > >> > To: ccie2be
> > > > >> > Subject: Re: dot.1q tunneling - IE Vol II, lab 9, task 1.4
> > > > >> >
> > > > >> > How are you doing. Tim?
> > > > >> >
> > > > >> > if all you have to do is to make vlan 20 and 2
> > > > communicated in layer
> > > > >> 2,
> > > > >> > I think you need to configure Vlan-bridge in either CAT
> > > > 1 or CAT2 .
> > > > >> >
> > > > >> > Jongsoo
> > > > >> >
> > > > >> > On 5/12/05, ccie2be < ccie2be@nyc.rr.com
> > > > <mailto:ccie2be@nyc.rr.com> >
> > > > >> > wrote:
> > > > >> > Hi guys,
> > > > >> >
> > > > >> > I'm trying to figure out how to configure this.I think
> > > > dot.1q is the
> > > > >> way
> > > > >> > to go but I can't test this with the equipment I have.
> > > > >> >
> > > > >> > rtr-1------------- Cat-1---Cat-2----------------- rtr-2
> > > > >> > .2 < vlan 2>< vlan 20> .254
> > > > >> >
> > > > >> > | < 192.10.1.x/24 >|
> > > > >> >
> > > > >> > 802.1q trunks have been configured between the 2 3550's
> > > > and both Cat's
> > > > >> > have
> > > > >> > their system mtu set as 1504.
> > > > >> > I've configured each cat port connecting the rtr's
> > as follows:
> > > > >> >
> > > > >> > Cat-1
> > > > >> > interface FastEthernet0/2
> > > > >> > switchport access vlan 2
> > > > >> > switchport mode dot1q-tunnel
> > > > >> > no ip address
> > > > >> > no cdp enable <- added by default
> > > > >> > spanning-tree bpdufilter enable<- added by default
> > > > >> >
> > > > >> > Cat-2
> > > > >> > interface FastEthernet0/24
> > > > >> > switchport access vlan 20
> > > > >> > switchport mode dot1q-tunnel
> > > > >> > no ip address
> > > > >> > no cdp enable
> > > > >> > spanning-tree bpdufilter enable
> > > > >> >
> > > > >> > With the rtr's I'm using I can't configure 802.1q trunking
on
> > the
> > > > >> ethernet
> > > > >> > ports connected to the Cat's.And, when I put the ip addr
> > > > on the phy
> > > > >> int,
> > > > >> > pings don't work from rtr-1 to rtr-2.
> > > > >> >
> > > > >> > Am I approaching this problem correctly?If I were able
> > > > to configure
> > > > >> the
> > > > >> > ethernet ports with 802.1q trunks, would this work?
> > > > >> >
> > > > >> > TIA, Tim
> > > > >> >
> > > > >> >
> > > > >>
> > > > ______________________________________________________________
> > > > _________
> > > > >> > Subscription information may be found at:
> > > > >> > http://www.groupstudy.com/list/CCIELab.html
> > > > >> >
> > > > >> >
> > > > >>
> > > > ______________________________________________________________
> > > > _________
> > > > >> > Subscription information may be found at:
> > > > >> > http://www.groupstudy.com/list/CCIELab.html
> > > > >>
> > > > >>
> > > > ______________________________________________________________
> > > > _________
> > > > >> Subscription information may be found at:
> > > > >> http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> > > > ______________________________________________________________
> > > > _________
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > > ______________________________________________________________
> > > > _________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > ______________________________________________________________
> > _________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > ______________________________________________________________
> > _________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:11:57 GMT-3