Trick Question

Unanswered Question
Nov 18th, 2008

Is there a way to keep this scenario from happening (other than not allowing users to connect a switch to their jack):

Topology:

host -> user switch -> main switch -> router

We actually had this happen last night. In the user switch, a user connected one end of a cable to port 4 and the other end to port 3. This effectively brought the network down at this branch.

I've got a test setup here and I've implemented storm control, but this isn't keeping it from happening. I don't think bpduguard or bpdufilter will work either considering the port that the user switch connects to is already a designated port for spanning tree and forwarding.

Any suggestions or other tricks that could keep this from happening in the future?

Thanks!

John

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Edison Ortiz Tue, 11/18/2008 - 10:16

Any suggestions or other tricks that could keep this from happening in the future?

Read on switchport port-security

:)

__

Edison.

scottmac Tue, 11/18/2008 - 11:41

As Edison says, the port-security is probably best.

If you *really* need to control "clever" users, then you also should set your TTL (Time-to-Live)such that if they drop in a consumer router (for NAT and expand ports) the TTL expires and there's no connection.

I hope the employee was fired for a violation of the policies. You *-DO-* have a policy, don't you?

Good Luck

Scott

Giuseppe Larosa Tue, 11/18/2008 - 11:52

Hello John,

here what helps is

STP bpduguard it should disable both links or at least one of the two:

the designated port will propagate BPDUs and the other port should go in errordisable for the fact of receiving BPDUs regardless of their content.

I think this is the scenario for using this command.

This works if the user switch has the bpduguard feature.

Instead BDPU filter is to be avoided because it is just the opposite : it makes the ports silent and they cannot detect each other.

BPDU filter is to be used only on some L2 Service provider scenarios not inside an enterprise.

port security can help too.

I tested BPDU guard 4 years ago on CatOS and IOS switches and it worked the way I described above.

Hope to help

Giuseppe

Jon Marshall Tue, 11/18/2008 - 12:12

John

I think Scott has hit the nail on the head. You could use port-security and we do to make sure that users don't connect hubs to their PC ports by limiting the amount of mac-addresses seen on the switchport. You could use BPDUGuard but that is assuming that the switches support these features. If they do great but quite often users can plug in their own switch/hub and create the very same problems.

So it really comes down to a security policy that all users are aware of and are also aware of the consequences if they do something they shouldn't.

There are a lot of features you can use to mitigate against these things and if the features are available then i would use them but in the end if a user wants to do something really stupid they probably will :-)

Jon

jedavis Tue, 11/18/2008 - 13:24

Yes, bpduguard will disable the port. However, I have seen instances where bpduguard fails after the switch attempts to automatically recover the port (I still have a TAC case open on this). I would use both bpduguard and port security. At least, that is what I am implementing right now.

Actions

This Discussion