Roberto,
We do use bridging over only one AP hop; however, the Karlnet MAC table is
fairly large, as far as I remember. That should not be your issue if you
cascade bridged links. Thinks to consider:
** if you happen to see broadcasts on the bridged segments (i.e. packets
using the netbase or broadcast address), this will cause a broadcast packet
to go over all air links to all stations because they may want to answer the
broadcast. Depending on the number of broadcasts generated (OSPF is bad for
example, and NETBIOS may be too) this may use your bandwidth to some extent.
Solution: block the base and broadcast addresses of your subnets at the
border router, and prevent you customers from sending broadcasts into your
bridged net.
** Something similar happens if a packet arrives for an IP address that does
not exist (for example from scans coming in from the Internet): This will
generate an ARP request into all APs and out into the air - without any ARP
reply. And if the same IP destination is polled again, the ARP will be
repeated. Other than blocking all unused IP addresses at the border router,
there is no real cure for this.
** proxy-ARPing on the APs will help, but only for existing IP addresses.
The effect of proxy-ARP may be further improved with the
learned-table-lockdown feature. If you use these, the APs closer to your
router will learn the MACs from segments further down the stream, but I
guess that the number of entries is still not the issue.
Notes about #1 and #2:
We found that blocking broadcasts at the border router is necessary even if
we don't cascade bridges and it would even be necessary on cable links ...
that's actually preventing the most primitive form of DDoS attack.
Flooding packets against an unused IP address is not common because the
attacker has no benefit from that except if he targets your net and knows it
causes problems. Therefore, we will start blocking none existing IPs the day
we see someone flood our net with packets against an unused address.
Obviously, if you use NAT at the border router for private addresses on your
wireless segments, NAT will be your "automatic broadcast and
unknown-address-blocker" and solve both issues automagically - just prevent
broadcasts coming out of your customers then.
--
true global communications GmbH
Thomas Giger
In der Au 27, 61440 Oberursel, Germany
fon +49.6171.6381-0, fax +49.6171.6381-19
www.tgnet.de || www.megaspeed-internet.de
> -----Original Message-----
> From: Intercom - Roberto Ravetti [mailto:rravetti@itc.com.ar]
> Sent: Monday, October 20, 2003 11:06 PM
> To: Karlnet Mailing List
> Cc: isp-wireless@isp-wireless.com
> Subject: Re: [Karlnet] Permit Ethernet Broadcast?
>
>
> Broadcast is something that worry me a bit...
>
> We have PtP link in cascade, in the same network segment and
> in the same
> ethernet nivel.. and the ARP LEARN TABLE of each AP could lear the MAC
> adress of others stations.. some of those AP have near of 60
> MAC learned..
>
> How bad could be that if I continue growing wit others PtP..?
>
> I know that the best solution would be ROUTED link but I am
> using PPPoE over
> only one central CISCO 3620 in my NOC, so for now I need that
> all PtP link
> are BRIDGED.
>
> Bye
> Atentamente,
>
> ------------------------------------
> Roberto Ravetti
> Intercom I.S.P
> Gerente de Servicios
> mailto: rravetti@itc.com.ar
> http://www.intercomwireless.com
> Te: (54) 3571 427 777
> Rio Tercero - Cordoba - Argentina
> ------------------------------------
>
> ----- Original Message -----
> From: "Charles Chia Sheng Wu" <cwu@cwlab.net>
> To: "Karlnet Mailing List" <karlnet@WISPNotes.com>
> Sent: Saturday, October 18, 2003 10:07 PM
> Subject: RE: [Karlnet] Permit Ethernet Broadcast?
>
>
> > >Hi,
> > > Anyone care to shed some light on the "Permit Ethernet
> Broadcasts"
> >
> >
> > sure...these are more NETWORKING than wireless questions,
> but that command
> > basically it turns Ethernet Broadcasts ON and OFF
> >
> > What does that mean? in terms of bridging, an important
> characteristic of
> > bridges is that they forward Ethernet broadcasts to all connected
> segments.
> > This behavior is necessary, as Ethernet broadcasts are
> destined for every
> > node on the network, but it can pose problems for bridged
> networks that
> grow
> > too large. When a large number of stations broadcast on a
> bridged network,
> > congestion can be as bad as if all those devices were on a
> single segment.
> >
> > Here's an interesting white paper
> > http://www.cswl.com/whiteppr/white/blocking.html
> >
> > >and "Permit Ethernet Multicasts" settings, such as >whether or not
> they're
> > required, good, bad or other?
> >
> > In my experience,e for WISP networks, multicast traffic is
> not really a
> big
> > issue
> >
> > >I can't seem to find any detailed docs on it. I'm interested in
> TurboCell,
> > SEC-> AP+, and 802.11b (SmartBridges) ->AP+ contexts.
> >
> > well, changing how these applies depends on a number of
> things, namely how
> > your network is configured
> >
> > -Charles
> >
> > _______________________________________________
> > Karlnet mailing list
> > Karlnet@WISPNotes.com
> > http://lists.wispnotes.com/mailman/listinfo/karlnet
> >
>
>
> _______________________________________________
> Karlnet mailing list
> Karlnet@WISPNotes.com
> http://lists.wispnotes.com/mailman/listinfo/karlnet
>
|