Zhijun writes:
> Basically we have 3 options for this,
> * have layer 2 filtering enabled by default, so we don't need to add a
> new switch to enable it
> * disable layer 2 filtering by default, and enable it when users first
> adds a rule contains keyword "family ether"
> * disable layer 2 filtering by default, and specify "set
> intercept_layer2 true;" in /etc/ipf/ipf.conf to enable it, and this is
> the one we proposed
>
> With the 1st option, having layer 2 filtering enabled by default will
> have performance impact, even if there're no layer 2 rules configured,
> because additional processing is needed when layer 2 filtering is
> enabled, so this option cannot be used.
The performance impact is present only if the 'ipfilter' service is
enabled, which it's not. And when you enable that service, you
already get an effect on IP, so having "more" shouldn't necessarily be
a problem: those using IP filter have already agreed to pay a
performance price for doing so.
Do you have any numbers to suggest that those who've intentionally
enabled IP filter would be upset at paying a slightly default higher
price in order to support L2 rules as well? I think that's your
assertion, but I don't see why it'd be true.
However, that's not the option I'm arguing for anyway.
> With the 2nd option, we'll enable the layer 2 filtering when the first
> "family ether" rule is added, and disable layer 2 filtering when the
> last "family ether" rule is removed, this has the following issues
> - We need to add check for each addition/removal of "family ether"
> rules, for each addition/removal, we need to check whether this is the
> first rule added, or the last rule removed, I'm not sure whether this is
> desirable
Actually, there are two variants that are possible:
- Keep a count -- a single simple integer -- of all of the
family ether and layer2 rules that are present. If that
count is not zero, then enable. If it's zero, then disable.
- Have a single *internal* flag. If any "family ether" or
"layer2" rule is inserted, then the flag is set. The flag
is reset only when all of the rules are flushed. Users can
then 'recover' from the overhead problem by doing "svcadm
restart ipfilter".
Both of these appear to be simple and don't involve any extra
administrator-controlled flags. That second one is *equivalent* to
what you're proposing, except that it doesn't require extra work by
the administrator.
> - Enabling layer 2 filtering involves registering hooks, today for
> ipfilter, both IPv4 and IPv6 hooks are registered when ipfilter is
> enabled, and unregistered when ipfilter is disabled; for loopback
> filtering, the case is the same. So I think for layer 2 filtering,
> registering/unregistering hooks when a rule is added/removed instead of
> the feature (layer 2 filtering) enabled/disabled sounds inconsistent
> with the existing behavior
Think ahead to when both IPv4 and IPv6 are in the same file, since
Darren has said that this is the intended goal.
It would be perfectly reasonable for us to register hooks for IPv4
only when IPv4 rules are present, and for IPv6 only when IPv6 is
present, so that overhead for one doesn't affect overhead for the
other.
In fact, taking it further still, it'd be perfectly reasonable to
refactor the hooks so that they're per-interface (rather than global),
and have the ipfilter service register hooks only on the interfaces
that are filtered -- so that only the filtered interfaces are saddled
with the overhead, and the other interfaces in the system are not.
That'd be a great improvement over the situation today, as inserting
filters for your 10Mbps management port slows down your 10Gbps data
port as well.
In any event, all of this is a purely internal design matter. It's
not something that ought to have artifacts in the documented
configuration file.
Please don't push system architecture off onto the administrator.
> - Today, with ipfilter you need to enable the ipfilter service before
> you can add rules. If we follow the logic of option 2, why not we change
> ipfilter and let it get enabled automatically when the first ipfilter
> rule is added? But this is not what ipfilter behaves in neveda.
That's not what I'm suggesting.
I'm suggesting that when the administrator puts rules into the file,
and then he enables the service, it should just work. He should not
have to do anything else. There should be no other switches or knobs
to tweak to make it "really enabled."
> I understand optioin 3 may not be a perfect solution in all aspects, but
> if we need a trade-off, sounds like it is a better choice than the rest.
I think it's far worse. It pushes off onto the administrator
something that the system ought to be handling itself.
I'm not talking about "svcadm enable ipfilter". I still expect that
to be there. I'm not asking for the ipfilter service to spring to
life magically when filters are added to the file. Instead, I'm
asking that when it's enabled via SMF and when the rules are present,
those rules *WORK* and don't need extra tweaking.
Doing anything else is, to me, a regression in functionality.
> > There may be such cases, but that's exactly what the existing "group"
> > feature in IP filter is designed to handle. It allows you to specify
> > that packets matching certain criteria are to be further processed by
> > a subset of the rules.
> >
> Right. And we're using "group" together with "ip-head".
> > This new "ip-head" and "ip-nat" feature does the same thing,
> "ip-head" does the similar thing for "head", and "ip-nat" is different.
> Please note the group feature is only available for IP Filtering rules
> today, there're no group support for IP NAT rules. So "ip-nat" is
> irrelevant with the "group" feature.
That's perhaps a bug, but irrelevant.
You still haven't answered what "ip-head" does that "head" doesn't
already do.
> I was talking about using "quick" instead of "ip-head" "ip-nat" is not
> desirable, because the order rules listed in the configuration file may
> not be the same order that rules get processed, so using "quick" can be
> misleading.
The rules in the file are always processed in the order that they're
inserted into the lists, as documented in the ipf.conf man page.
Order has always been significant. I think you're confusing the
"group" feature and the "head" keyword with other bits -- it'd be
confusing indeed if L2 processing were forced to be always at the end
of the file or if it didn't follow the normal order-sensitive behavior
that IP Filter has always had.
> > pass in on nge1 family ether from 0:14:4f:8d:ae:23 to any head 10
> > pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32 port = 8888
> > keep state group 10 layer2
> > pass in proto tcp from 10.10.10.20/32 to 10.10.10.10/32
> > rdr nge1 from 10.10.10.20/32 to 10.10.10.10/32 port = 7777 -> 10.10.10.10
> > port 8888 tcp group 10 layer2
> >
> Today we don't have group support for IP NAT rules in neveda.
> Adding group support for IP NAT rules can be a way to solve this, and
> using "ip-nat" is another way, and requires less changes.
I suspect you can *still* do this without resorting to "ip-nat".
pass in on nge1 family ether from ! 0:14:4f:8d:ae:23 to any quick
rdr nge1 from 10.10.10.20/32 to 10.10.10.10/32 port = 7777 -> 10.10.10.10
port 8888 tcp layer2
(Mixing ipf.conf and ipnat.conf syntax like this is pretty confusing
... is that part of this case ... ?)
> > My point in saying this is that the design looks incomplete. It looks
> > like you've added L2 (Ethernet, really; nothing else seems to be
> > supported) to a single configuration file, but the equivalent work for
> > IPv6 hasn't been done yet, so the design is "mixed" and confusing as a
> > result.
> >
> As Darren has already explained, /etc/ipf/ipf6.conf was introduced as an
> obsolete interface for a historic reason. I fully agree that it is good
> and desirable to have all IPv4, IPv6 and ether rules consistent (maybe
> put altogether in ipf.conf), I'm just not sure if it is needed to be
> done in this project. As this project is only focused on layer 2
> filtering and doesn't touch anything about IPv6. So probably this can be
> addressed via a separate bug/RFE?
Possibly. If we can agree on what the architecture should look like.
I don't think we're at that point yet.
> > All of the L2 examples you've provided use IPv4. What would happen if
> > I needed to add L2+IPv6 rules? Can I do that?
> >
> Sure. Just add the "layer2" keyword to the IPv6 rules, the usage is the
> same as IPv4 rules. :-)
I don't think I follow.
The IPv6 rules are currently in a different file, because they need to
be processed with a special ipf command line flag.
So, is a "family ether" rule legal in ipf6.conf? Since all of the L2
rules are undistinguished with respect to IPv4 and IPv6, what actual
order of L2 rules (in the kernel) do I get if I put these into both
ipf.conf and ipf6.conf? (Again, I care about order because it's
significant for matching rules.)
These things seem to be in conflict, which is why I was pointing out
(above) that it doesn't appear to be complete.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
