>> I thought we defer plumbing iptuns to a later time for a reason. Is >> that no longer true? > > Yes, there is a reason, and the plan was to invalidate that reason. > Today, the source address of a given tunnel must already exist before a > tunnel can be configured to use it, and that's why the creation of > tunnels is deferred until after network/physical has completed plumbing > all other IP interfaces. > > In the future, I'd like to be able to configure the source address of a > tunnel even if that address isn't available. The availability of the > source address would determine the "link state" of the tunnel. > Implementing this would require the iptun module to constantly monitor > IP address changes on the system for all tunnels, and I'm not sure it's > worth doing given the marginal benefit it adds to the system. > Understood.
>> My proposal is, the datalink configuration upgrade would still convert >> the old /etc/dladm/*.conf configuration to a series of "dladm" >> commands, and write them to /var/svc/profile/upgrade. >> >> We'd also need to add a dependency between manifest-import service and >> network/initial service >> >> During system boot: >> >> 1. the network-physical service runs, and it does: >> >> up-aggr, up-vlan, init-linkprop >> plumb physical data-links if /etc/hostname.* exists >> >> 2. the manifest-import service runs, and creates all the aggregations >> and init linkprops for system upgrade. >> >> 3. network/initial service runs, and plumb all the aggregation, VLAN, >> IPtun interfaces etc. >> >> The problem is that how to tell the class (aggr, iptun or phys) of the >> link by its link name. In another word, we have a /etc/hostname.* >> file, how to determine when to plumb which interface? The information >> is not known when the network/physical service runs the first boot >> after system upgrade, because no <link name, linkid> mapping exist yet >> at that time. > > Indeed, this is a problem. > >> >> We could try to plumb every one listed in /etc/hostname.*, and it does >> not matter if it fails (as it will then be plumbed later). But that >> would cause a lot of "plumb failure" warnings. >> >> So, none of the proposals would solve all problems. Do you have better >> suggestion? > > My initial suggestion of having an upgrade service would work in all > cases, no? The only problem with this approach is that it needs to run > before manifests are imported, but to me, that's a bug in SMF which we > can't do anything about but that we can workaround. > No. As long as we need to plumb a subset of interface to a later time than network-physical, it does not work. Consider the old configuration: an aggr1 and /etc/hostname.aggr1 During the first boot of system upgrade, network/physical would try to plumb aggr1, but aggr1 cannot be created because the physical link (say bge1) is not known to the daemon yet (it will not be known until devices/local). My latest proposal can solve this problem. We could not choose to prompt a warning only when none of the interfaces are plumbed successfully), but that changes the today's behavior and I don't know whether that is acceptable. This makes me wonder another problem: the network-nwam service will not be able to walk datalinks either at that point. How does that work? How it used to work? Can we move the iteration of network devices in or before network/physical? I will try it out. Thanks - Cathy
