From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu May 12 2005 - 20:48:43 GMT-3
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
>
>
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:11:57 GMT-3