Help: need to disassociate bridging clients !

Hi,

I have several hundred Cisco 1200 APs scattered throughout campus, and
recently there have been HUGE problems with people's XP laptops set up
to bridge between wired and wireless connections. When they do that, the
spanning tree protocol on the switches start shutting down random ports
and affect random amounts of people -- it's a freakin' nightmare

Anyway, we've been thinking about how to fix this, and, essentially, it
boils down to sticking each AP behind a layer-3 hop, which would kill
roaming from one AP to another, and getting a new set of APs that would
allow us to disassociate those clients that send packets sourced from
more than one MAC address (which in our case would be the xp laptops
that are set up as bridges).

You know, like most managed switches would have the ability to shut off
edge ports based on the presence of more than a set limit of mac
addresses, or the ability to hard-code a given mac address to a port.

Do you know of any AP model that would allow a limit on the number of
MAC addresses per associated client ?

Thanks much for any pointers, ideas, hints, whatever. We're getting
hammered here

M.

On Fri, 27 Aug 2004 16:54:43 -0600, Michael Benden <(E-Mail Removed)>
wrote:

>I have several hundred Cisco 1200 APs scattered throughout campus, and
>recently there have been HUGE problems with people's XP laptops set up
>to bridge between wired and wireless connections. When they do that, the
>spanning tree protocol on the switches start shutting down random ports
>and affect random amounts of people -- it's a freakin' nightmare

Easy solution. Ban all XP laptops and offer to replace the OS with
one of several Linux mutations. (It's midnight and my brain isn't
working quite right).

>Anyway, we've been thinking about how to fix this, and, essentially, it
>boils down to sticking each AP behind a layer-3 hop, which would kill
>roaming from one AP to another, and getting a new set of APs that would
>allow us to disassociate those clients that send packets sourced from
>more than one MAC address (which in our case would be the xp laptops
>that are set up as bridges).

If you do that, methinks you might kill any system that has a bunch of
computahs connected to a local switch, and then to the campus network
via a wireless bridge. While I don't think it would be particularly
detrimental, there are probably a few such remote LAN's that you've
never noticed (because they caused no problems). However, they can
buy and install a cheap router between the wireless bridge and the
switch, which would eliminate the issue by making everything appear to
arrive from one MAC and one IP address.

Basically, you want a 1:1 MAC to IP mapping in the ARP cache. I don't
think it's going to do anything for your spanning tree protocol
problem. Spanning tree works on the MAC layer and doesn't know
anything about IP addresses. You can play with the IP addresses all
you want and the multiple paths through the switched MAC layers will
still be there, merrily being thrashed around by the STP. As long as
you want to have the switched find their own best path to wherever,
you're gonna have problems.

The STP was designed specifically to prevent loops.
http://www.cisco.com/univercd/cc/td/...an2/stpapp.htm
Your Windoze XP laptop bridges are creating loops (more than one path
to the same place) and STP sometimes electing to go through some XP
laptop, instead of through various parts of your network. When the
laptop moves or shuts down, STP is suppose to detect this, reconfigure
on the fly, and continue pumping packets. Apparently, this is not
happening on your system. It's suppose to converge in about 30
seconds or less, not permanently disconnect parts of the network.
Some of the gigabit switched networks will reconfigure in less than
500msec. Methinks something is broken or misconfigured on your
network.

You may also have built an oversized network. Do your STP switches
cause packets to blunder through more than 7 bridges to the final
destination? Include the wireless link/bridge as one bridge. If so,
STP stops at 7 bridges.

>You know, like most managed switches would have the ability to shut off
>edge ports based on the presence of more than a set limit of mac
>addresses, or the ability to hard-code a given mac address to a port.

How are you gonna update all these switches with a new MAC to port
address table when a radio moves between ports? Well, actually it can
be done with a "wireless switch".
http://www.symbol.com/products/wirel..._brochure.html
The radios are literally brain dead and devoid of any intelligence.
They shovel 802.11 packets and nothing else. All the intelligence is
in the central switch. You can do your MAC to port mapping, detect
roaming, and generally do tricky things in this centralized scheme
that cannot be done with a distributed switch topology. I'm not sure
if this will do exactly what you want, but it might be worth a call to
the sales droids.

>Do you know of any AP model that would allow a limit on the number of
>MAC addresses per associated client ?

That's redundant. The way an access point recognizes a client radio
association is by the BSSID which is the MAC address. There's no
other way that I can think of determining the number of radios other
than counting the BSSID which will always be the same number as the
MAC addresses.

>Thanks much for any pointers, ideas, hints, whatever. We're getting
>hammered here

Find out why STP is taking so long to reconfigure.
Don't look to layer 3 solutions for layer 2 problems.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

Jeff Liebermann wrote:
>>roaming from one AP to another, and getting a new set of APs that would
>>allow us to disassociate those clients that send packets sourced from
>>more than one MAC address (which in our case would be the xp laptops
>>that are set up as bridges).
>
>
> If you do that, methinks you might kill any system that has a bunch of
> computahs connected to a local switch, and then to the campus network
> via a wireless bridge. While I don't think it would be particularly
> detrimental, there are probably a few such remote LAN's that you've
> never noticed (because they caused no problems). However, they can
> buy and install a cheap router between the wireless bridge and the
> switch, which would eliminate the issue by making everything appear to
> arrive from one MAC and one IP address.

Yeah, that's exactly what I want -- the ability to deny association to
any wireless bridge, and only support individual clients directly. Of
course, the ability to allow bridges on a case-by-case basis (by BSSID,
maybe) would be nice.

>
> Basically, you want a 1:1 MAC to IP mapping in the ARP cache. I don't

no, that's a layer-3 solution. I want a layer-2 solution, i.e., deny
associations if you see packets sourced from more than one MAC (or a mac
different from the bssid). Don't really want to look at the IP address
at all !


>
>>You know, like most managed switches would have the ability to shut off
>>edge ports based on the presence of more than a set limit of mac
>>addresses, or the ability to hard-code a given mac address to a port.
>
>
> How are you gonna update all these switches with a new MAC to port
> address table when a radio moves between ports?

That was me babbling too much. I don't care about hardcoding a MAC to a
port (or to an association, which is the equivalent of a "port" on
wireless access points, sort-of). I care about limiting the number of
different MACS allowed through the port (or the association), and
shutting down the port (or disassociating) when I see *too many* MACs
(in my case, too many is anything more than 1).

Well, actually it can
> be done with a "wireless switch".
> http://www.symbol.com/products/wirel..._brochure.html
> The radios are literally brain dead and devoid of any intelligence.
> They shovel 802.11 packets and nothing else. All the intelligence is
> in the central switch. You can do your MAC to port mapping, detect
> roaming, and generally do tricky things in this centralized scheme
> that cannot be done with a distributed switch topology. I'm not sure
> if this will do exactly what you want, but it might be worth a call to
> the sales droids.

No, this looks like an AP where the radio communicates with the rest of
it through ethernet -- not really helpful given my layer-2 bridging
problem

>
>
>>Do you know of any AP model that would allow a limit on the number of
>>MAC addresses per associated client ?
>
>
> That's redundant. The way an access point recognizes a client radio
> association is by the BSSID which is the MAC address. There's no
> other way that I can think of determining the number of radios other
> than counting the BSSID which will always be the same number as the
> MAC addresses.

Each radio/association has a BSSID. In the case of a bridge, that would
be the bridge's MAC. But, through that association, packets are being
forwarded that have various source MAC addresses. I want to disassociate
if packets received through an association have too many different
source MACs. Or, as I said before, if there are any packets sourced from
a MAC that's different from that of the client itself (the BSSID). That
would fix my problem -- i.e., disallowing any bridge from associating to
my APs. I kind-of thing this feature would make sense to have on an AP.

> Find out why STP is taking so long to reconfigure.

Yes, spanning tree recovers after the XP bridges are gone, but they tend
to stick around for a while, and while they're on, spanning-tree keeps
the wrong ports shut off. I like my layer-2 config the way it is, that's
the whole point -- I want to avoid having to reconfigure everything to
deal with bridging XP laptops. I want to simply make them go away, and
the best place to do that would be the AP, no ?

> Don't look to layer 3 solutions for layer 2 problems.

Well, I *am* looking for a layer-2 solution, but I kind of liked the
one-giant-wireless-vlan-from-hell approach, and it worked fine as long
as we could control the layer-2 setup (i.e., users didn't get into the
layer-2 business themselves, like with XP bridges )

And I also think that disallowing users from connecting their own
switches to my network is the right approach (not hardcoding macs on
edge ports, but limiting the *number* of simultaneous macs, thus
prohibiting bridges/switches from being hooked up). The wireless
equivalent of that would be to disassociate bridging clients at the AP
level, which is why I was asking if any vendors do that with their APs.
Cisco obviously does not, and I'm willing to ditch them in a hurry if
someone else did... Too bad sales folks don't read Usenet

Thanks,
Gabriel

Hi Michael,

~ I have several hundred Cisco 1200 APs scattered throughout campus, and
~ recently there have been HUGE problems with people's XP laptops set up
~ to bridge between wired and wireless connections. When they do that, the
~ spanning tree protocol on the switches start shutting down random ports
~ and affect random amounts of people -- it's a freakin' nightmare

~ Anyway, we've been thinking about how to fix this, and, essentially, it
~ boils down to sticking each AP behind a layer-3 hop, which would kill
~ roaming from one AP to another, and getting a new set of APs that would
~ allow us to disassociate those clients that send packets sourced from
~ more than one MAC address (which in our case would be the xp laptops
~ that are set up as bridges).
~
~ You know, like most managed switches would have the ability to shut off
~ edge ports based on the presence of more than a set limit of mac
~ addresses, or the ability to hard-code a given mac address to a port.
~
~ Do you know of any AP model that would allow a limit on the number of
~ MAC addresses per associated client ?
~
~ Thanks much for any pointers, ideas, hints, whatever. We're getting
~ hammered here

One way to address this problem is to use the BPDU Guard feature,
assuming that your switches support it. (SOME Cisco Catalysts do.)
The idea is that, if the switch hears any BPDU frames coming from
the port (i.e. bridge protocol frames such as bridge hellos), it
will shut the port down.

Spanning Tree Portfast BPDU Guard Enhancement
http://www.cisco.com/warp/public/473/65.html

When your client's XP laptop is misconfigured to act as a bridge,
and is connected both wirelessly to the AP and wiredly to the switch,
it will start emitting BPDUs. With BPDU guard turned on on the client's
switch port, that port will shut down, allowing the client only to
use the wireless link.

Do NOT turn on BPDU guard on the switch port to which the AP is
connected - you don't want to cut off your AP's network access!

Note that we are considering implementing a BPDU guard feature
on the AP, but it is conceptually more challenging - there's no
physical port dedicated to the wireless client. If you would like
a feature like this, then please email me privately.



Cheers,

Aaron