[ednog] wireless bridging problem

[David Farmer]

[I'm going to talk about cisco features because it is what I know, but 
other devices have similar capabilities.]

Not sure about other devices but Windows seems to participate in 
spanning tree and send BPDUs.  If you seem to have short term loops 
think about portfast and how it would interact in this situation, portfast 
doesn't disable spanning tree, but it skips the listen state.  You may 
want to think about adding BPDU Guard.  There are two versions, the 
first at a port level disables the port if it sees a BPDU.  The second, 
enabled at a global level, temporarily disables portfast and forces the 
port into listen state when it sees a BPDU.  Also, look into root guard 
and simply properly defining your spanning tree Root would be a big 
help if you haven't done that.  

I think your on the right track looking at spanning tree.  You need to 
look at locking down your spanning tree.  Also keep your user access 
spanning trees very simple.  When your students add a spanning tree 
capable device that causes a topology change and if you have a 
complicated topology it will take time to converge.

Spanning trees need to be gardened and not allowed to grow wild.

I'm not sure why the MAC address of the switch is an issue, most 
users don't communicate with the their local switch. But the router's 
MAC address, of the SVI on one switch, sure would be.  you might 
want to look at locking down the MAC address of the router in the 
forwarding table.

On 18 May 2005 Jeff Murphy wrote:

> the following is a forwarded message of a problem we're having here at
> UB. the last paragraph has some possible solutions. i'm wondering if
> anyone has any other solutions? 
> 
> 
> .....
> 
> 
> 
> Over the last semester we have had several complaints of intermittent
> connectivity within resnet. We investigated and could find no physical
> level problems that would cause this. We did find that our network gear
> in these buildings experienced the same problem. Upon investigation we
> determined that the mac address of our network gear was showing up on
> resnet user ports. This would cause our gear to alarm as the packets
> destined to the switch would instead go to the user port. The problem
> would clear itself once the mac address timed out. 
> 
> The only way the switches mac address could show up on a user port is if
> the user was spoofing mac addresses or bridging the network back on
> itself. We do not believe the users are spoofing mac addresses as the
> mac addresses affected seem pretty random. We do believe that the user
> is bridging the network back onto itself with wireless. We have seen
> this before, laptops come standard with built in wireless cards and have
> the Ethernet bridged to the wireless. If a user where to plug in their
> laptop to a wired Ethernet port and also have a wireless access point
> near by, the network will get bridged back onto itself. Wireless access
> points are installed by the users in resnet and are becoming more common
> with our recommendation for the users to install routers. They install
> wireless routers as they are cheap and more flexible. 
> 
> We currently have no way to automatically find the users in resnet doing
> the bridging. While we run spanning tree on all resnet building
> switches, it did not detect a loop or span out any of the ports. We
> believe this is because the devices doing the bridging are smart enough
> not to bridge spanning tree packets. The duration of the problem is so
> short that most methods will not be able to catch it in time. The only
> accurate way we could track this problem down was to do it manually as
> we noticed the switch start alarming. We spent considerable time this
> last semester tracking down these users and found about 20 of them. We
> stayed on top of the problem and aggressively found and disabled users
> to keep the problem under control. The help desk visited several sites
> and found mixed results. Most had some combination of a laptop with
> wireless, a wireless router, or an access point. They could find no
> common thread or device to attach the problem too at this point.
> 
> We believe that this problem will only increase in frequency in the fall
> semester as wireless routers and laptops will become more popular. We
> believe there are several options in trying to solve this problem. We
> could start a user education program on what not to do. We could ban
> wireless in resnet so this problem does not happen. We could try to
> automatically detect this problem and disable the port when it does
> happen. We could move to a mac locking design to try and prevent this
> problem from happening.
> 
> 
> _______________________________________________
> ednog mailing list
> ednog at puck.nether.net
> https://puck.nether.net/mailman/listinfo/ednog
> 



=================================================
David Farmer				Email:	farmer at umn.edu
Office of Information Technology
University of Minnesota			Phone:	612-626-0815
2218 University Ave SE			Cell:	612-812-9952
Minneapolis, MN 55414-3029		FAX:	612-624-4035
=================================================