* Patrick McHardy wrote, On 26/11/07 15:35: > Amin Azez wrote: >> * Patrick McHardy wrote, On 26/11/07 07:30: >> >>> What advantages does this offer over using realms? > > >>> From my point of view, the advantage is that you don't have to use >>> realms. >> >> 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. 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. Sam - 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
