On 05/14/10 07:20 AM, [email protected] wrote:
On (05/13/10 13:25), Edward Pilatowicz wrote:
Currently, none, though the "only ipv4 specified implies ipv6-addrs
are forbidden" approach solves that. In retrospect, that choices
seems simpler and cleaner. Is that preferable?
i think so.
On (05/13/10 16:29), [email protected] wrote:
Ok, I'll send out an updated spec (that also incorporates Girish's
feedback) later this week.
As promised.. the new spec is attached. The diffs are
The behavior as seen from the GZ looks fine. But staring at the NGZ we have:
r...@gz# zlogin tz1 ipadm show-addr
ADDROBJ TYPE STATE ADDR
vnic0/_a static ok 11.1.1.1/24
vnic0/_b static ok 12.2.3.4/16
lo0/v4 static ok 127.0.0.1/8
lo0/v6 static ok ::1/128
This looks identical to the case when vnic0 was configured locally in
the ngz (that is what "static" means). Hence the NGZ admin have no
reason to believe it isn't possible to do a ipadm delete-addr vnic0/_a.
But either such a delete fails, or after a reboot the address magically
reappers; either of which would be a surprise to the ngz admin since the
addresses are marked as "static".
These addresses provided and enforced by the GZ are provided by an
external entity (the GZ) the same way as the addresses in a dhcp or
addrconf address object are provided by an external entity (the dhcp
server and stateless addrconf config on the routers, respectively. Thus
I think it makes sense to label them as a different type of address
object to make this clear to the ngz admin
I don't know what a good name would be - we used "from_gz" when we
talked about this on the phone.
That way the ngz admin will see something like
vnic0/_a from_gz ok 11.1.1.1/24
vnic0/_b from_gz ok 12.2.3.4/16
hence have visibility into the origin of these addresses. (Perhaps all
addresses can be part of the same vnic0/_a address object, just like
addrconf address objects contain multiple addresses, but that is a detail.)
Erik
_______________________________________________
opensolaris-arc mailing list
[email protected]
