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

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 :-)


-----Original Message-----
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.


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
> > leak" somewhere and the only real suggestion I can offer you would be to
> > 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
WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

WISPA Wireless List: wireless@wispa.org


Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to