On 04/22/09 20:55, Erik Nordmark wrote:
I though I saw some email saying we should do a global replace of "intf"
with "if", which is a good idea.
Yes, we are doing that.
Note that
applying a persistent change that relies on the result of a temporary
command may fail with an error.
Thats correct. However handling missing objects (IP interfaces for our
case) is something that we were planning on doing in the next phase of
the project. In the first phase we will be displaying this error message.
If we figure out how to handle missing objects, then we can remove that
may.
For instance, if I do
dladm create-if -t bge0
dladm create-addr -i bge0 10.1.2.3/24
and then reboot it isn't much different than if bge0 goes missing (there
is a difference between the datalink bge0 being missing and the IP
interface being missing, but otherwise the same).
Once we start handling 'missing' interface case, we will re-apply the
above address after the interface reappears.
With today's kernel there will be a difference with -f inet/inet6 for
create-if, because we implicitly end up creating an ipif when we create
the ill.
But a future kernel might not do that. Hence the -f switch for *-if is
something we probably want to remove down the road.
'-f' was provided for few customers who didn't want to create both the
interfaces in one shot. Further it's more of an option in the libipadm
'ipadm_create_interface()' library API. Once the future kernel is in
place we can get rid it.
Section 3.2 says that about delete-if that
All addresses configured on that interface will be torn down.
That sounds counter-intuitive given the "missing" handling.
'delete-if' mimics the 'unplumb interface' logic which in the current
model removes all the addresses configured on the interface.
Instead I think it makes sense to have delete-if return EBUSY if there
are addresses. (Later we can have a -F which forces the interface to go
missing even though there might be addresses that refer to it.)
I don't think the EBUSY changes usability, because I expect the manual
usage of ipadm would be around creating and deleting address objects.
OK.
So what's the real 'delete'? I am asking this because with what you are
saying there will be no way to delete all the addresses configured on
the interface. The user needs to delete each individual address and then
delete the interface.
Section 3.4:
Note that lo0 has different MTU for IPv4 and IPv6 today (so that 8k of
payload fits with the different IP+TCP header sizes.) I think we should
have the kernel move away from that, and until then ipadm somehow has to
paper over that difference.
we will show lesser of the two MTU values. 8232
Section 4.1. As I mentioned elsewhere, is the CIDR mask part of the name
of the object or not?
Thus can I do
ipadm create-addr -i bge0 10.1.2.3/24
followed by
ipadm delete-addr -i bge0 10.1.2.3
or do I need to specify /24 in the delete?
To keep the namespace uniform across create and delete we could have
/24, but it's not necesssary as such to specify /24 in the above case.
[We have a separate thread on hostnames for create-addr and friends.]
Section 4.4. I separately suggested show-addr output where the status
doesn't have the admin up/down flag, but instead shows the RFC 4293
address status.
If the current kernel doesn't have IFF_UP set on an address, then
representing that as the RFC 4293 notion of "invalid" would make sense.
yes we will use IPAddressStatusTC MIB values to specify the status of
the address and as of know it can have following values
(a) duplicate
(b) inaccessible (if interface is down or not operational)
(c) invalid
(d) deprecated and
(e) preferred
Section 5.1:
I'd suggested s/*-v6addrs/*-ipv6addrs/ globally.
Will change.
We need to decide whether the label is globally unique or unique per
interface, since that affects the set-addrprop and delete-ipv6addrs.
Thats correct. set-addrprop and delete-ipv6addrs would take "-i
interface" as a mandatory option. So having labels to be unique across
interface should work and we don't need globally unique 'labels'
We need "-i" option in set-addrprop to identify 'static' addresses. The
tuple <interface, address> uniquely identifies a static address.
How will things work with the current kernel where I don't see to be
able to change the token and have that change the link-local address? Is
that a kernel CR that you will fix?
Ideally, we would like to have it that way. The ability to change the
token to change the link-local address.
Until then we might have to make the "token" an interface property
rather than an address property. It would mean that all the addresses on
that interface would use that token for auto configuration.
Section 6 talks about a set of addresses for DHCPv4, but AFAIK for any
given client-id/MAC address the server can only assign one address.
True. We will correct the design doc.
Section 6.2: Will show-addresss display all the address objects, or do I
have to do show-address, show-dhcp, show-ipv6addrs?
the idea was to have symmetry within ipadm subcommands. Every
'create-xx' command would have the 'show-xx' counterpart. However if
it's convenient for the system-admin to use one command to see all
the addresses, we can do that.
Section 7.
Instead of a "nolocal" property I suggest we name it "invalid". Or
perhaps not - read on ...
There is some overloading of IFF_ flags; ideally we'd like the kernel to
be able to have a separate notion of the status of an address and the
related onlink prefix. For instance, a duplicate address doesn't affect
the validity of the onlink prefix. But the prefix (in ND) can go invalid.
I don't know how far to take that separation. In its most extreme form
there would be a separate <verb>-prefix, but that seems like overkill in
the CLI. Note however that in.ndpd creates prefixes without associated
addresses, in which case they have IFF_NOLOCAL set and a zero address.
Thus it might make sense to have libipadm have <verb>-prefix functions
for ndpd to use.
OK we will add them.
In terms of show-addr things are a bit odd in that it pretends to show
addresses, but when NOLOCAL is set it is really an address-less prefix.
How do such things get reported by ifconfig in BSD?
True, it shows 'subnet' address. Is that OK?
How about including an "auto" in stateful = {true, false}. auto would
mean to do what the RA says, and would be the default. true would mean
to do in independently of what the RA says.
For symmetry having a stateless = {true, false} makes sense; if set as
false no addresses are configured from RAs (but DHCPv6 would run
independently.)
We will do that.
Section 8:
AFAICT an under interface can be added to a group in two ways:
ipadm add-ipmp -i under0 ipmp0
and
ipadm set-ifprop -p groupname=foo under0
Do those have identical semantics? For instance, what about the case
when under0 is already part of a group? (Do I get EBUSY, or do they
remove it from the existing group and then try to add to the specified
group?)
Note that doing a remove+add makes the failure semantics tricky. The
remove might succeed, and then the add could fail. Wouldn't you want to
add it back to the original group in that case? But that could also fail...
Thus EBUSY sounds like better semantics.
And perhaps we don't need to allow set-ifprop on the under.
We could return 'EBUSY' is the under interface is already part of
another group and for cases where we can reassign the interface to
different group, we will do it
So I guess we can have the 'groupname' intf-prop.
Section 9.4. Let's not try to come up with arbitrary acronyms like
frag_to and fragment; too short names are necessarily helpful.
OK
In section 9 I don't see how per-interface things like ip_forwarding is
set. Will that be done with ipadm set-ifprop?
Yes it will be done using 'ipadm set-ifprop'
It would be good to separate out non-interfaces (from an ACR
perspective). I believe section 9.3 falls in that category.
I think you meant ARC perspective. You are right we will separate that out.
Section 11.2 talks about merging /etc/hostname* with ipadm peristent
configuration, and I frankly don't know what that means.
(It could be something complex e.g., detecting when /etc/hostname.bge0
changes from 10.1.2.3 to 10.9.9.9 and moving that change into ipadm, or
it could be something simpler.)
In the first phase we are not doing any migration of "/etc/hostname.*"
stuff to ipadm repository. Both the repositories will co-exist.
From looking at docs.sun.com with Renee a while back it seems like the
main (only?) documented use of /etc/hostname.<ifname> is various driver
docs which suggests adding an IP address to that file.
there are several other places where it's mentioned.
(a) ifconfig manpage
(b) Solaris Administration Guide: IP services section
(c) Solaris Administration guide: IP tunneling configuration
Things can potentially be added with an editor, or with
echo 10.1.2.3 >>/etc/hostname.bge0
If that is all we need to do we can do a few things:
1. If /etc/hostname*<ifname> doesn't exist or only contains comments, do
nothing (leave it in place).
2. If /etc/hostname*<ifname> contains something other than comments,
then take the non-comment stuff and propagate it to ipadm. (An issue is
what we do if this fails due to ipadm not supporting something like
modinsert.) Then replace the removed test with a comment that reads
something like
# This file has been obsoleted and its comments migrated to ipadm(1m)
I am not sure we could add 'comments' to those files. Lot of scripts
just cat the content of that file onto 'ifconfig(1m)'
#ifconfig `cat /etc/hostname.bge0`
If there are comments above command would fail.
Can we realistically do this migration now, or do we need to wait until
more of ifconfig is supported in dladm? (We'll always have things like
modinsert which isn't likely to be carried into ipadm.)
I think we will have to wait for this migration as by the first putback
we might not have all the 'ifconfig' functionality. We will be having
the persistent store for 'ifconfig' and 'ipadm' and they need to
co-exist to begin with.
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
