Eric wrote:
Looking at the beacon realtime manager and tcpdump, we've never seen
an unreasonable # of broadcasts when this is happening.
On our network 200 broadcasts per second is pretty typical. When we see it
spike to over 1200 per second (6-fold rise), it really drives the latency
up. Don't be fooled by total bw metrics ... broadcasts are so short that
crippling broadcast storms don't show any spike in total traffic (traffic is
actually squeezed out by the broadcasts dominating the radios). I'm
thinking tcpdump is like the packet dump that ethereal uses. How do you
determine how many broadcasts per second is transiting the AP from it? Just
curious. I'm not familiar with "beacon realtime manager" ... can it tell
you how many broadcasts per second are on the air during your events? When
you say you've never seen an unreasonable # of broadcasts, how many
broadcasts per second do you see during an event? What we do is simply
chart broadcasts in & out for every radio on our network on a continuous
basis. Just about anything will do that, so knowing broadcast levels (and
who's causing them) is a piece of cake ... no harder than opening a web page
and scrolling to spot the offenders.
Rich
----- Original Message -----
From: "Eric Merkel" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Friday, October 27, 2006 3:11 PM
Subject: Re: [WISPA] "The Gremlin," redux
On 10/27/06, Rich Comroe <[EMAIL PROTECTED]> wrote:
>We look at the traffic on the
>tower for abuse and/or virus and don't really find anything.
Just to be clear, you've checked your AP broadcast levels during the
events
and not found found them elevated? We found the most crippling network
events were not coming into the network from the outside, but were
broadcast
storms between 2 or more customers (repeated through the APs). They act
similar to the symptoms you cited (a few minutes of extremely elevated
latency due to the short term load they place over the rf).
Rich
We try to mitigate this problem by the following:
1) Turning off inter-BSS Relay
2) We block all the typical MS ports(135-139) which broadcast all the
time via iptables
3) Packet shape all connections via CBQ on the AP itself to limit how
much bandwidth any one customer can consume
Looking at the beacon realtime manager and tcpdump, we've never seen
an unreasonable # of broadcasts when this is happening.
-Eric
--
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/
