On 03/25/09 12:30, James Carlson wrote:
> Girish Moodalbail writes:
>   
>> bash-3.2# dladm show-link
>> LINK        CLASS    MTU    STATE    PROMISC    OVER
>> e1000g0     phys     1501       up           off                --
>> e1000g1     phys     1502       up           on                --
>>     
>
> That (plus or minus some column alignment) seems fine.
>
> How will this work with the various sorts of virtual interfaces and
> VLANs?
>   

See below.

> I assume that if someone puts a regular link into promiscuous mode,
> then all of the regular VNICs (including those inside a zone) are in
> promiscuous mode. 
No, they would not be in promiscuous mode. The VNIC's would be in 
promiscuous mode only if a DLPI application enables it using 
dlpi_promiscon() with DL_PROMISC_PHYS flag. So, we do not register 
VNIC's promiscuous call back function if the NIC is put in promiscuous mode.

>  But do VLANs appear as "in promiscuous mode" if the
> underlying interface is set that way?  After all, listeners on the
> underlying interface can see the VLAN traffic.
>   

Since snv_105, VLAN's are implemented as VNIC's so as per explanation 
before VLAN's wouldn't be in promiscuous mode if the underlying NIC is 
put on promiscuous mode.

> If a VNIC is in promiscuous mode, is the underlying link marked that
> way as well even though no clients of the underlying link are using it
> that way? 

Yes, the underlying link will be marked promiscuous because without 
making the underlying NIC promiscuous the VNIC's would not get all the 
packets.

>  Does putting one VNIC into promiscuous mode also put the
> others on that same underlying link into promiscuous mode (as one can
> listen to others)?
>   

No, we don't.

> Iterate the above questions for both VLANs and
VLANs are no different than VNIC's. They work as specified above.

> virtual drivers such as those used for Xen.
>   
I have to look in to this.

thanks
~Girish

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/brussels-dev/attachments/20090325/cf9e45e6/attachment.html>

Reply via email to