Cathy Zhou wrote: > Sebastien Roy wrote: >> My plan for the iptun interfaces was to move them into network/physical, >> but they're currently plumbed in network/initial. >> > 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. > I see a problem with my proposal though. See more below. > > 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. -Seb
