Amin Azez wrote:
* Patrick McHardy wrote, On 26/11/07 15:35:
Amin Azez wrote:
Also, the match isn't REALLY strongly related to routing, which nexthop
suggests, it's really a dest-mac match but where the mac address is
resolved by IP each time from the neighbour table; so it's also useful
against layer 3 bridges as well, where the bridge hardware is out of
your control (may change) but it has the same IP address; e.g. some
hotspots. Realms can't do that AFAIK;
Not sure I understand - if it has an IP, its not a bridge but a
router. If its visible to routing in any way, realms can be used.
layer 3 bridges work by mac spoofing, so it's not routing or layer 2
bridging.
And so realms can't be used.
And the whole point of (ugh) layer 3 bridges is to join network segments
without the need to scatter routing changes everywhere.
The fact that xt_gatway can cope with this where realms can't is a nice
plus on top of the fact that you don't have to define a realm for each
gateway just to be able to match it's mac address.
The version Jan posted doesn't match on mac but on IP address.
So I still don't see the point. You have a route with a gateway
address, which you can match on. The fact that some MAC spoofing
is done seems irrelevant. Since you have this route, you can also
use realms. What am I missing here?
Another advantage is that it can be used by linux users who haven't
manually defined any routing but still make use of
/etc/sysconfig/iptables to save and restore firewall rules.
(It's a matter of opinion whether or not it is desirable to give this
facility to users who haven't gone to the labour of defining a routing
table. Maybe we don't like those sort of people).
For myself, I have xml-based routing tables (yeah I posted my code to
lartc but no-one cared) but I still prefer xt_gateway over using realms
to indicate mere snat-ability, and to save realms for something more
realm-like. Lack of return routing seems incidental to the connotations
of realm in my mind, so use of realm seems like an abuse
Since we already have a crapload of stuff in the kernel, I prefer to
only add things that extend the expressiveness of iptables to things
not possible otherwise. Mere simplifications can be done in userspace
IMO.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
