VLAN's and Trunking stop all the broadcast traffic. You won't hear me say NOT to static route (yuck) as I have a lot of my network statically routed, but it does NOT out perform my bridged, VLAN'd network segments.
I did have a completely flat bridged network and never had my network flooded by a single user with a virus. I am not saying that its not possible, but it never happened to me once in 4 years (and I have 15% of the State of Louisiana covered with wireless) before changing half of my network to a statically routed network. I did have a switch to get flooded in the NOC that actually shut my network down many times before I caught that sucker. I realize that a VLAN'd network can still have trouble, but no more than your statically routed network. There are more ways to skin a cat than one :-) although we know your preferences :-) Mac -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lonnie Nunweiler Sent: Saturday, October 28, 2006 4:18 PM To: WISPA General List Subject: SPAM ? Re: [WISPA] "The Gremlin," redux Importance: Low Since your customers are mostly on a bridged network then a single malicious or misbehaving customer radio can take your WHOLE network down. The reason your backhaul is not affected is simply because it has more capacity than the prism AP units. I know you guys are tired of hearing from me about routing versus bridging (You even gave me my own clause) but your problems are precisely what I have been describing for all of these years. The one point you are missing in your overall design is something I have brought up a number of times. A properly functioning bridged system will echo all broadcast traffic throughout the network, thus one system can flood the entire LAN. This leads to the biggest single factor --> your entire network speed is a factor of your slowest AP, since it must rebroadcast all traffic to its users. On a routed design you will still get problems like these slowdowns, but the very important thing to keep in mind is that the slowdown will only take out the one sector. Also (and this should be enough to make you take a hard look at routing) your LAN throughput is the sum total of all of your AP units and thus you might actually start to use your high speed backhaul. Your ping times will go under 2 msec per repeater. Our WAR boards are actually around the 1 msec area. The other thing you have going against you is that you are using a unit based on the Ubicom chipset. Remember the dear old Wet11? That was Ubicom using a prism radio. CB3 is simply a newer version, but still with some issues that seem to be killing networks everywhere. Our last version of the Atheros driver would start to show units could not reconnect and the only way to make the system settle down was to change channels or reboot. What is happening is that the CB3 has trouble when it reconnects to an AP. Something is not quite right with its handshake and it does not get accepted. This causes it to throw a hissy fit and it starts to hammer the AP with reconnection attempts. That massive RF directed at the AP soon causes other units to disconnect and guess what happens if they are a CB3? They try the same techniques the first tried. Suddenly you have this massive reconnect storm and the AP is brought to its knees until you change channels or reboot. Your whole problem is circular and is based on poor choices of both equipment and network design. You chose cheap units that only do a pseudo bridge so you designed your LAN accordingly. You thought you would be safe because you had a good AP, but a LAN is mostly made up of clients, so if the clients are poor, then it follows that your LAN is poor. You have some sectors already routed, but they still have the trouble. I say this is because of the trouble of the clients, which could be at this tower or simply because your tower is visible to them. You are quite likely even using 200 mW prism cards which makes this factor even more probable. So this means you have two issues. 1. Clients that will have to be updated with better firmware or replaced. 2. Your entire system will have to be redesigned for a proper routed design. The way out of this is obvious, but it will be painful and costly. There is going to be a lot of anger directed at me for this message so I am now ducking down to avoid the flames. Regards, Lonnie On 10/28/06, David E. Smith <[EMAIL PROTECTED]> wrote: > Mac Dearman wrote: > > > I tend to believe you will find your answer on your network -vs- "big bad > > leak" somewhere and the only real suggestion I can offer you would be to do > > what we do here when we start having weird issues > > [ snip: Mac's good advice on how to track down broadcast storms and > other network-related problems ] > > If it were a backhaul problem, though, wouldn't I see high latency on my > backhaul links? I haven't, to date. > > Here's one of the (many) experiments I've done in the past (this one was > yesterday, actually): I logged into an affected AP, while the problem > was happening, and firewalled off THE WHOLE INTERNET except for one IP > address, that being the PC in my office I was using to log into that AP. > Then, from that AP, I pinged a CPE associated with it. The problem > persisted, high packet loss and 5000-10000 millisecond latency. > > I quickly undid my changes on that AP, then did exactly the same thing > on another AP, about twenty miles away, with a different radio card, on > a different channel, connected to me through a different backhaul link, > and saw exactly the same performance (high packet loss, obscene latency, > et cetera). > > Meanwhile, pings to and through our backhaul links, to the APs > themselves, various managed switches at tower locations, and so on, > never skipped a beat. (Heck, most of 'em improved a bit, since there > wasn't as much pesky customer traffic going through them. :) > > For that matter, why do I have three towers with a mixture of 2.4GHz and > "other" APs (two with a 900MHz AP, one with a 5.3GHz AP and a 5.8GHz AP) > and the non-2.4 customers aren't affected? Keep in mind that, for > annoying historical reasons, much of our network is still "flat," > bridged addresses flying willy-nilly across four counties. If it were a > network storm, I'd expect it to hit all our towers, on all channels, and > not conveniently skip over the most geographically remote ones. > > There's also all the nasty logistical problems of my company not having > twenty extra hands that we can just have sitting at all our towers for > days, or weeks, at a time, waiting for a problem that shows up > completely randomly, hoping I can call everyone to start unplugging > stuff before the problem magically goes away, but that's another issue > altogether ;) > > Last, remember this really is amazingly random, and usually only shows > up for a minute or two at a time, brief enough that I only see it in our > logs well after the fact. (Yesterday it visited us for a good twenty > minutes, long enough for customers to really notice, and for me to have > time to dig into it again.) > > I certainly don't mean to sound dismissive of any suggestions, it's just > that I've tried most of the "obvious" ones before. > > David Smith > MVN.net > -- > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -- Lonnie Nunweiler Valemount Networks Corporation http://www.star-os.com/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
