[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: brconfig and ARP



On Thu, Mar 01, 2001 at 02:19:37PM -0500, Jason Wright wrote:
> On Wed, Feb 28, 2001 at 04:34:27PM -0600, Tillman wrote:
> > Howdy,
> > 
> > I've bumped by brconfig maxaddr up to near-absurb levels, but I still see this
> > ARP traffic coming through. None of it is for my machines or for my gateway,
> > and I'f be fine with blocking all ARP traffic that isn't for me.  I could live
> > with not having a decent ARP cache internally (I'd static my gateway's MAC).
> > 
> > It seems to me that as long as I have this nice bridge learning all these
> > addresses that it ought to be able to determine "ARP request on outside
> > segment, I already know the answer will come on the outside segment, why
> > bother passing it inwards?".
> 
> ARP and bridges have -nothing- to do with each other.  ARP is for creating
> IP->MAC associations and the bridge does not operate at that layer (3).
> Increasing the cache size on the bridge increases the size of the MAC->port
> association table.  You could checkout the 'rule' stuff with brconfig and
> add rules to allow their router's MAC address to talk to your hosts, though.
> 
> On the otherhand, would it be worth adding -another- feature to the
> bridge code: arp selective forwarding?  I think this violates the
> model of an 802.1d bridge and might be difficult to get right.

Howdy,

They do in this sense: bridges repeat traffic, including ARP traffic. I don't
want all that ARP traffic, but ipf won't filter it so that leaves the bridging
code.

What I'd like to do is publish (using choparp) the few MAC's that the gateway
will need to find me on the firewalls outside interface. Then I'll static ARP
the MAC of my gateway on my internal machne's. Then I'd like to block all ARP
traffic.

This naturally means that my ARP caching on the internal machines is going to
be starved for information. I can live with that; the only entry that they
need is the gateway, which has been made static.

With more reflection, I now think that this would properly belong in ipf.
While ARP is specific to certain mediums (and thus doesn't make sense in a
higher level filter like ipf), bridge already knows how to pass things up to
ipf for filtering so it would be cleaner to filter it there. 

Does that make more sense?

-Tillman