[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <925A849792280C4E80C5461017A4B8A2A0443B@mail733.InfraSupportEtc.com>
Date: Fri, 16 Sep 2011 09:55:47 -0500
From: "Greg Scott" <GregScott@...rasupport.com>
To: "Christian Benvenuti \(benve\)" <benve@...co.com>,
<netdev@...r.kernel.org>
Cc: "Graham Parenteau" <adfgrahame1@...il.com>
Subject: RE: Very confused about broute DROP
Definitely counter-intuitive in my head. Three little ebtables rules -
ACCEPT anything IPv4 - which includes ARPs - for a couple of IP
Addresses and then DROP everything else for all protocols. (Which
really means bridge for those IPv4 Addresses and route for everything
else.)
I don't see how a rule specific to ARPs matters here. ARP is an IPv4
protocol and should be implied in the rules I set up - right? Why a
rule specific to ARPs when it's already part of IPv4?
This just hit me - layer 2 is stateless. I have ACCEPT rules for frames
bound for **destination** IPv4 IP Addresses. I wonder if I need similar
rules for these same IP Addresses as sources? But that still doesn't
make sense - that rule to DROP everything else covers all sources and
all destinations. When I put in that ebtables DROP rule, the box turns
into a black hole instead of a router.
Maybe one day the lightbulb will light up in my head, but right now I
still don't get it.
- Greg
-----Original Message-----
From: Christian Benvenuti (benve) [mailto:benve@...co.com]
Sent: Thursday, September 15, 2011 11:23 PM
To: Greg Scott; netdev@...r.kernel.org
Cc: Graham Parenteau
Subject: RE: Very confused about broute DROP
What I meant is that your host needs to be able to route
(which means ... to process) its own ARP traffic, ... IPv4
does not work without ARP, right?
This means you need to add one more DROP rule for the ARP
traffic that is addressed to the MAC of the host interfaces
(nothing to do with proxy ARP).
/Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists