Zhenghui Xie writes:
> >Such as vni0?
> >
> >
> >
> Please forgive me if i am asking something stupid. (but I really don't
> know) What is vni0.
It's a virtual interface. It's not lo0, so it's not exactly loopback,
but it shares many of the same traits. You can't transmit on it. See
vni(7D).
> and what is the difference between vni0 and bge0 or
> hme0?
The latter will likely have real hardware underneath of some sort.
> I think now I am confused as well. :-)
My work here is done. ;-}
> So basically milestone/network is unnecessary, because all network
> services can be started as long as there is lo0?
Yes. The only bar I can see to starting services early would be
making sure that the right security filters are in place first.
> In this case, do we
> need to distinguish the states that the machine is isolated from outside
> network and the machine is connected to some network? If not, then we
> probably don't need milestone/network. But if we eliminate this
> milestone, what should we do with those 3rd party services that are
> depending on it? (not sure what is the number yet, may need some
> investigation if we decide to delete this milestone.) This milestone was
> designed to be a stable dependency for long term so I guess there must
> be some depending on it.
There are two issues here that I can see. One is defining what
milestone/network actually means, and the other is determining what
sorts of dependencies on it are needed or possible. The two issues,
though, are interrelated.
If we define milestone/network as meaning:
- lo0 is configured (which, frankly, ought to be true by the
time ip`_init returns)
- configured IPsec rules, if any, are loaded
- configured IP Filter rules, if any are loaded
... then I can see a reason for this to exist. All network services
would need to depend on it. It'd sort of be nice if there were no
such thing required, but it seems like a fair solution to tie these
separate subsystems together.
The implication is that services depending on this will know that if
they can reach something, then it's as "safe" as it's going to get;
meaning that the security bits are in place. (Nothing's ever really
safe, but this is as far as we go.)
Services depending on this won't know a priori if they can in fact
reach anything. Sending packets and (more importantly) getting
responses will tell them that. Retransmitting on timeout and (better
yet) listening for updates to the interface table via routing sockets
will provide a way to kickstart into action once there's reason to
believe that more connectivity is possible at some later point.
There's no state, though, in which "perfect" connectivity is known,
except perhaps to a human who is able to examine this system and the
other systems on the network and declare the world safe for bits.
(Even then, I'd question whether that human really has that capacity,
other than in a sort of statistical "it should work now" sense.)
If we were to define milestone/network as additionally meaning that
there's "some" way out of the box and onto some physical network, then
a host of problems occur:
- we don't (and _CANNOT_) know the state of the routers or
peers, so there's no way to know if access to that physical
network buys us anything.
- it might not be the "right" physical network, because the
peer that the service needs is on some _other_ network that
has yet to come up.
- the peer might not be ready to talk yet, so packets from the
service towards that peer may get dropped or result in
errors.
- routes anywhere along the path may be missing.
- there are other cases in which early packets are tossed,
such as with interfaces that intentionally lie about IEEE
negotiation state (they're supposed to, because it confuses
IPMP if they don't) and those that have STP enabled.
In other words, the existence of that externally-connected interface
isn't probative. It's unclear if it's necessary (some services may
need to talk only with other local services over loopback), and it's
clear that it's not sufficient.
I don't quite see the value in having a "might work but who knows?"
definition of milestone/network. I do suspect that this is what quite
a few people think they want, but I'm not sure it's the right
architectural answer.
As for the other issue -- whether it could be removed entirely rather
than just redefined -- it doesn't seem to be one of the documented
milestones, so I don't see where we have a solid commitment to it.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
