sowmini.varadhan at sun.com wrote:
>> That is an implementation matter, right?
>> For dladm we solve it my keeping the properties for missing interfaces
>> in user space and some upcall to retrieve them when the object comes
>> into existence. One could do the same for these missing objects, or one
>
> But dladm doesn't allow you to create configuration for a missing
> interface today, right (it only reapplies previously created config,
> and the first creation requires the interfce to be present)?
Yes, but that doesn't change anything with respect to this issue. I can
create a property for bge3 while it exists, and then bge3 is missing. At
that point in time the system is in the same state as if I was allowed
to create the property for bge3 even if bge3 had never existed.
The system needs to deal with bge3 for the first case, and whatever that
implementation mechanism is, it can presumably handle the second case as
well.
> My question was: if we have a way of creating configuration for missing
> objects, and the admin creates this virtual configuration, then what
> is the administrative step to actually enable that configuration.
> I was thinking of "ipadm create-link" as a way of applying the virtual
> config. (But I think what you are suggesting is to have the actual
> datalink create/rename commands itself apply this?)
Did you mean 'ipadm create-if'? (Using "link0" as the example IP
interface name isn't a good choice; calling it net0 or if0 would reduce
the risk of confusing links and IP interfaces.)
The properties for a missing object should be applied when that object
comes into existence.
The way I think about this is to start with a system that has all the
dependencies satisfied, and then remove something e.g., the datalink
disappearing, and then adding the datalink back in. I think it makes
sense that the end state be the same as the initial state, whether or
not there were any intervening reboots.
Thus if I have the bge0 datalink (with some set of properties), the bge0
interface (with some set of properties), some addresses on bge0 (with
some properties), and I then remove the datalink, what happens? (I can
do that today with a poweroff, remove the PCI card, and power back on;
it might make sense to allow the same operation using software as some
-force flag for dladm delete-link since we can get into the same state
using reboot.)
When the system comes up and the bge0 datalink is removed,what does
ipadm show-* tell me?
It could say something like
# ipadm show-if
IF LINKS MTU STATUS SRCFROM FLAGS
lo0 - 8232 RUNNING UP, MULTICAST, VIRTUAL
bge0 bge0 1500 MISSING UP, BROADCAST, MULTICAST
# ipadm show-addr
IF STATUS ADDR/MASK
lo0 PREFERRED 127.0.0.1/8
bge0 INACCESSIBLE, PREFERRED 129.146.228.81/23
(Note that the admin state of UP doesn't change above; the
administrators intent is that the IF be UP, but it isn't running. The
addr status is from RFC 4293.)
When the bge0 datalink reappears the system should drive towards a
running status for the interface, and that will clear the INACC status
of the address.
>> We probably have a lot more non-universal properties in dladm than in
>> ipadm. But I can think of one for ipadm.
>>
>> I setup the system with link1 being a pt-pt interface.
>> Thus I do some
>> ipadm create-address destination=10.2.2.2 link1/10.1.1.1
>>
>> Then link1 disappears.
>> When it reappears, whether or not Vanity naming is involved, it is no
>> longer a pt-pt type link.
>>
>> What we'd want for those cases is that the whole create-address that is
>> triggered by the link reappearing fail. We don't want e.g., that the
>> address is created and the local address is set, but the destination is
>> not set.
>>
>> And we'd need some place to report these errors.
>
> right, there would have to be a lot of error-checking.
Not any more than today; we need to check that SIOCSLIFDSTADDR is
consistent with the IFF_POINT2POINT when we do a manual ifconfig/ipadm,
and the same check would catch the mismatch when a datalink reappears.
The difference is how/where errors are reported.
Erik
