Rishi Srivatsavai writes:
> Garrett D'Amore wrote:
> > On the one hand, this looks pretty good.  On the other hand, I find it 
> > really unfortunate that we have to create yet another kind of virtual 
> > interface in addition to etherstubs and VNICs.

Agreed on that point.

> >  I think many customers 
> > are going to be left wondering which one of these things they should use 
> > and why.

I don't think they will, because they're supposed to be used for
testing purposes.  If they're documented at all, they should be
documented as intended for testing.

> > Is it not possible that we could integrate the functionality (perhaps as 
> > an additional option) to etherstubs or vnics?  (I'm thinking of a kind 
> > of "attach" or "link" command that might be used to link a pair of 
> > etherstubs together, for example: dladm link-etherstub etherstub0 
> > etherstub1, which could have much the same kind of result, although it 
> > wouldn't necessarily support the WiFi semantics....)
> 
> It is possible but I personally think it would be more confusing to 
> introduce simlinks as a new type of etherstub/VNIC. By keeping them 
> distinct and calling them 'simlinks' should be clear that they are a 
> testing resource.

Another problem is that these things are *NOT* the same in design as
etherstubs.

Etherstubs aren't regular mac instances.  Instead, they're actually
created as VNICs, and have no actual I/O (everything just goes through
the "virtual switch" used by VNICs).  This means that you can't (for
instance) put them into aggregations, even if you could some how
"link" them together and get the missing data paths to function, for
the same reason that you can't aggregate a set of VNICs.

At least in theory, one could use simlinks as though they were
etherstubs in order to configure a set of communicating VNICs.  We're
ruling that out as a general for the moment to specify them as "for
test purposes only" devices.  Perhaps when we have more experience
with them, we'll be able to replace the existing etherstubs with
simlinks.

-- 
James Carlson, Solaris Networking              <[email protected]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to