RE: Catalyst Specialties Question Interpretation

From: Christopher M. Heffner (cheffner@certified-labs.com)
Date: Tue Sep 20 2005 - 12:35:33 GMT-3


Dennis,

Based on the exact wording of the question the proper answer would be to
use the bpdufilter as you suggested since there was no instruction to
either lock the port down or to maximize the port security for the port
if it was to receive bpdu. If the question had called for either then I
would have gone with bpduguard instead. They are basically the same
with the exception of error disabling the port with bpduguard if it
receives a bpdu.

Also as you noted you can globally enable either command but not on a
per vlan basis but only on any access port that already has portfast
enabled.

If there were multiple port ranges for a certain vlan that needed this
type of command repeatedly assigned then I would suggest using the
"DEFINE" command to create a macro to represent all the ports for that
vlan first.

Christopher M. Heffner, CCIE 8211, CCSI 98760
Strategic Network Solutions, Inc.
VP of Internetworking Technologies

www.certified-labs.com

"Complete CCIE R&S and Security Online Rack Rentals"

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Dennis J. Hartmann
Sent: Tuesday, September 20, 2005 11:28 AM
To: 'Arun Arumuganainar'; ccielab@groupstudy.com
Subject: RE: Catalyst Specialties Question Interpretation

        Let's think about the wording of the question a little bit more
here though. They said to filter bpdu(s), not to guard against bpdus.
Would bpdufilter be a better answer than bpduguard? I think bpdufilter
would be a better answer here. Any comments?

Sincerely,
 
Dennis J. Hartmann
White Pine Communications
dh8@pobox.com /
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
 

-----Original Message-----
From: Arun Arumuganainar [mailto:aarumuga@hotmail.com]
Sent: Monday, September 19, 2005 11:53 PM
To: Dennis J. Hartmann; ccielab@groupstudy.com
Subject: Re: Catalyst Specialties Question Interpretation

While answering a question . There could be a implicit answers and
Explicit answers .

Explicit Answer : Enable BPDU Filiter !!!!
Implicit Answer : Enable Portfast ( you can not enable bpdu guard
feature )

I too do not agree with disabling STP as a solution to this problem .
Port fast with BPDU Guard looks much cleaner solution .

Thanks and Regards
Arun

----- Original Message -----
From: "Dennis J. Hartmann" <dennisjhartmann@hotmail.com>
To: <ccielab@groupstudy.com>
Sent: Tuesday, September 20, 2005 6:23 AM
Subject: Catalyst Specialties Question Interpretation

> I'm wondering how everyone would interpret the following question:
>
> Create VLAN 200 and assign port fast 0/20 to it on CAT2. Do not allow
BPDU
> traffic on this VLAN.
>
> The answer says to turn off STP on VLAN 200, but I disagree with
> this solution. Would turning off STP on a VLAN disallow STP traffic?
> I would think that STP could still propagate the switch, but it will
> not be interpretted by the switch because there will not be a static
> mac-address-table entry pointed to the CPU for this particular VLAN.
>
> I believe the solution is to enable one of the follwing commands
>
> (config-if)# spanning-tree portfast bpdufilter enable (the scenario
> did not call for portfast though)

> (config-if)# spanning-tree bpdufilter enable

(the scenario asked to not allow bpdu traffic on this VLAN. Since
there's no global command
> that can not simultaneously filter the traffic from only VLAN 200, I
> think this is the correct answer). If there's any other ports in vlan

> 200, they must have the same command applied to them.
> spanning-tree bpdufilter enable
>
>
> Comments?
>
> Sincerely,
>
> Dennis J. Hartmann
>
> White Pine Communications
>
> dh8@pobox.com
>
> CCSI#23402 / CCVP / CCIP / CCNP
>
> Cisco Optical, VPN & IDS Specialist
>
> MCSE
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3