Cathy Zhou wrote:
> Seb/Team,
> 
> After I think about this more. I'd like to propose another option - to defer 
> the creating and plumbing of aggregations later.
> 
> Today we already defer the plumbing of the iptun to the network/initial 
> service.
> 
> The proposal would solve the problem caused by late running of 
> /var/svc/profile/upgrade.

That seems fine to me.  You'll need to figure out which IP interfaces are 
over aggregations so that you don't attempt to plumb them in 
network/physical.  This could be done with "dladm show-aggr -P".

> It also solves another problem:
> 
> Today device/local is the service that that iterates and attaches all the 
> network devices (therefore we know of the existence of a new network 
> data-link). It is especially important during a reconfiguration boot. The 
> device/local service also runs very late, and because network/physical runs 
> before device/local, the "dladm create-aggr -d bge0 1" command might fail 
> because it fails to find the device bge0.
> 
> One might ask how "ifconfig bge0 plumb" works - it works because libdlpi 
> tries to open the /devices pseudo clone device node.
> 
> What do you think? What's your plan for those iptun interfaces.

My plan for the iptun interfaces was to move them into network/physical, 
but they're currently plumbed in network/initial.

-Seb

Reply via email to