svn commit: r253841 - head/sys/netinet6

[Bruce Simpson]

On 07/08/13 13:05, Gleb Smirnoff wrote:
> Yes, lack of good management mechanism creates a temptation to create
> a foo(4) interface for any new FOO protocol, with its own if_ioctl method
> that will provide a clean entry into its management. I suspect that was one
> of the reasons to implement carp(4) as interface.

My concern is that whilst the BPF change is well intentioned, we may be 
unravelling a loose thread; other issues loom in the FreeBSD network 
stack elsewhere. These might be considered artefacts of FreeBSD's fairly 
informal approach to network stack management.

This approach has served us reasonably well for many years -- it is 
simple and easier to maintain than the somewhat byzantine NDIS/TDI 
sandwich in Microsoft Windows. This doesn't change the fact that dealing 
with the venerable PF_ROUTE socket is a royal pain.

However we should be careful with refactoring. Changes to network stack 
management may affect stack elements such as net-snmp, snort, ntop, 
Netflow collectors, etc. A managed infrastructure might also use SNMP to 
track network configuration data.

I foresee that this change could help in those deployment scenarios; as 
SNMP is platform agnostic, Netdot (and other management tools) must 
parse and filter out the "non-proto-bound" ifnets (*) as their 
statistics are not normally considered useful. In Netdot, a set of 
heuristics are applied based on the sysObjectID MIB variable.

(*) It's entirely possible someone may want to log these things for 
development purposes, though.


>
> What do you mean about "virtual" interfaces? An interface must represent
> a sink where a route entry can point to and incoming packets can come in.
> With this definition a vlan(4) is a real interface, but pfsync(4), pflog(4),
> ipfwlog(4) are not.

At the moment we have a model whereby protocol families get bound to 
ifnets statically (not dynamically). It's OK for ifnets to be in a state 
of change where they may not have protocols bound to them during early 
system boot. (I guess my question is: packet sockets - why not?)

The specific case I am working with does satisfy this criterion, however 
it relies on other changes which restore the  legacy BSD behaviour where 
loopback traffic will only appear on the BPF instance specific to the 
ifnet. E.g. currently FreeBSD will present all locally looped back 
traffic on lo0 (or the current vnet's "primary" lo(4) instance).

>
> The situation with lack of management mechs should be fixed, and BPF
> providers should be decoupled from ifnet, and no new not-a-true-interface
> ifnets should be introduced in FreeBSD. All these not-a-true-interfaces
> require dozens of special handling around the kernel, an example is a
> commit we are discussing.
>

Agreed. carp(4) does not quite fit the model well at all. FreeBSD's 
implementation of it relies on ipprotosw[] and some other hooks in 
ether(4) leading to nested conditionals (my import of  M_PROMISC from 
NetBSD around 2007 may have helped limit code churn here.)