The requirement to plumb the vsw device with the same MAC address as the 
e1000g/nxge is to allow the primary domain to talk across the vswitches 
to the guests on that switch.

This was a bug in ldoms 1.0.2, its fixed with 1.0.3 (if you upgrade 
mamke sure you have appropriate firmware on the system) and the MAC 
address does not need to be manually set anymore, but plumbing the vsw 
is still required if you want the primary to talk to the guests on the 
vswitch, this is intended behavior for security.

Peter

Bernd Schemmer wrote:
> Hi
> 
>>> BTW, you can plumb vsw interface with whatever the mac address
>>> assigned by LDom manager. 
> 
> In our environment the network connection via the switch in the Primary LDom 
> and via the vnet devices in the Guest LDoms only work if we configure the vsw 
> with the mac address of the assigned physical network adapter (on all our 
> T5240). 
> 
> I thought this bug was fixed in one of the latest patches but it's still 
> there (we're using Solaris 10 Update 5 with currnet patches and ldm 1.0.3; We 
> use IPMP with test addresses in the Primary LDom and in the Guest LDom)
> 
> regards
> 
> Bernd
> 
> 
> 
> Raghuram Kothakota wrote:
>> Glen Gunselman wrote:
>>   
>>>> Hi,
>>>>
>>>>     
>>>>       
>>>>>> e1000g1:
>>>>>>         
>>>>>>           
>>>> flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
>>>> mtu 1500 index 3
>>>>     
>>>>       
>>>>>>        inet nnn.nnn.nnn.129 netmask fffffff8
>>>>>>         
>>>>>>           
>>>> broadcast nnn.nnn.nnn.135
>>>>     
>>>>       
>>>>>>        ether 0:21:28:1:5e:99
>>>>>>         
>>>>>>           
>>>> plumb and configure the virtual switch vsw  instead
>>>> of the physical 
>>>> network in the primary ldom.
>>>>
>>>> After doing this we often must stop the Guest LDom,
>>>> unconfigure all 
>>>> network adapters of the Guest LDom, reattach the
>>>> network adapters to the 
>>>> Guest LDom and start the Guest LDom again to make the
>>>> virtual network 
>>>> adapters work. And if you don't have installed the
>>>> latest patches for 
>>>> LDoms you must configure the virtual switch with the
>>>> mac address of the 
>>>> used physical network adapter.
>>>>
>>>>     
>>>>       
>>> I gave this a try and it did not work, so I installed LDoms 1.0.3 but that 
>>> did not help.
>>>
>>> When I try to configure using a mac address i get the following error:
>>>
>>> ifconfig vsw1 nnn.nnn.nnn.129  netmask 255.255.255.248 broadcast 
>>> nnn.nnn.nnn.135 ether 0:21:28:1:5e:99
>>> ifconfig: failed setting mac address on vsw1
>>>   
>>>     
>> The mac address for vswitch or vnet  can only be changed
>> via LDom manager CLIs.
>>
>> BTW, you can plumb vsw interface with whatever the mac address
>> assigned by LDom manager. Only issue you may need to pay attention is
>> to deal with ARP caches on other systems. In general, the GARP packets
>> generated during the plumb operation should cause a flush, otherwise, they
>> get flushed automatically after a timeout(around 5mins).
>>
>> Once you have vsw interface plumbed, I suggest verifying the communication
>> between Guest vnet and vsw. This info will provide an idea where the
>> problem could be. If this is found to be working, I suggest running snoop
>> on vnet1 and ping from an external system, this will give additional 
>> data point.
>>
>> -Raghuram.
>>   
>>> Thanks
>>> Glen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>   
>>>     
>>>> Be aware that the order of the "ldm add-vnet"
>>>> commands define the order 
>>>> of the network adapters in the Guest LDom
>>>>
>>>>
>>>> HTH
>>>>
>>>> Bernd
>>>>
>>>>
>>>> Glen Gunselman wrote:
>>>>     
>>>>       
>>>>> I have a working guest LDom on a T5220 with one
>>>>>       
>>>>>         
>>>> network connection (we call this the management
>>>> network, it's using e1000g0).  I need to add a second
>>>> network connection (we are calling this the public
>>>> network).
>>>>     
>>>>       
>>>>> 1.  ifconfig shows the physical interface is ready:
>>>>>
>>>>> ifconfig -a
>>>>> ...
>>>>> e1000g1:
>>>>>       
>>>>>         
>>>> flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
>>>> mtu 1500 index 3
>>>>     
>>>>       
>>>>>         inet nnn.nnn.nnn.129 netmask fffffff8
>>>>>       
>>>>>         
>>>> broadcast nnn.nnn.nnn.135
>>>>     
>>>>       
>>>>>         ether 0:21:28:1:5e:99
>>>>> ...
>>>>>
>>>>> 2.  I created the virtual switch
>>>>>
>>>>> ldm add-vsw net-dev=e1000g1 primary-vsw1 primary
>>>>>
>>>>> 3.  added the guest domain to the virtual network
>>>>>
>>>>> ldm add-vnet mac-addr=00:ff:00:ff:01:00  vnet2
>>>>>       
>>>>>         
>>>> primary-vsw1 sweetumstest
>>>>     
>>>>       
>>>>> 4.  I did forget to do the reconfigure reboot of
>>>>>       
>>>>>         
>>>> the control domain but have since done that.
>>>>     
>>>>       
>>>>> After booting the guest domain ifconfig shows vnet1
>>>>>       
>>>>>         
>>>> is UP and RUNNING
>>>>     
>>>>       
>>>>> ifconfig -a
>>>>> ...
>>>>> vnet1:
>>>>>       
>>>>>         
>>>> flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
>>>> mtu 1500 index 3
>>>>     
>>>>       
>>>>>         inet nnn.nnn.nnn.149 netmask fffffff8
>>>>>       
>>>>>         
>>>> broadcast nnn.nnn.nnn.151
>>>>     
>>>>       
>>>>>         ether 0:ff:0:ff:1:0
>>>>> ...
>>>>>
>>>>> and traceroute picks vnet1 but fails:
>>>>>
>>>>> traceroute nnn.nnn.nnn.209
>>>>> traceroute: Warning: Multiple interfaces found;
>>>>>       
>>>>>         
>>>> using nnn.nnn.nnn.149 @ vnet1
>>>>     
>>>>       
>>>>> traceroute to nnn.nnn.nnn.209 (nnn.nnn.nnn.209), 30
>>>>>       
>>>>>         
>>>> hops max, 40 byte packets
>>>>     
>>>>       
>>>>> The same traceroute from the control domain
>>>>>       
>>>>>         
>>>> succeeds using e1000g1.
>>>>     
>>>>       
>>>>> I'm no doubt over looking some simple thing but it
>>>>>       
>>>>>         
>>>> escapes me today ... 
>>>>     
>>>>       
>>>>> Thanks,
>>>>> Glen
>>>>> --
>>>>> This message posted from opensolaris.org
>>>>> _______________________________________________
>>>>> ldoms-discuss mailing list
>>>>> ldoms-discuss at opensolaris.org
>>>>>
>>>>>       
>>>>>         
>>>> http://mail.opensolaris.org/mailman/listinfo/ldoms-dis
>>>> cuss
>>>>     
>>>>       
>>>>>   
>>>>>       
>>>>>         
>>>> -- 
>>>> Bernd Schemmer, Frankfurt am Main, Germany
>>>> http://home.arcor.de/bnsmb/index.html
>>>>
>>>> M s temprano que tarde el mundo cambiar .
>>>>                         Fidel Castro
>>>> ________________________
>>>> ldoms-discuss mailing list
>>>> ldoms-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/ldoms-dis
>>>> cuss
>>>>     
>>>>       
>>> --
>>> This message posted from opensolaris.org
>>> _______________________________________________
>>> ldoms-discuss mailing list
>>> ldoms-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
>>>   
>>>     
>> _______________________________________________
>> ldoms-discuss mailing list
>> ldoms-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
>>
>>   
> 
> 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Peter A. Wilson                    Email: Peter.A.Wilson at sun.com
Snr. Technical Marketing Engineer  Phone: (650) 786 0526 / x80526
SG Technical Marketing             Cellphone : (408) 666 9320
Sun Microsystems, Inc.             Fax :       (650) 786 9553
16 Network Circle                  Mail Stop : MPK16-211
Menlo Park CA 94025                Office :    MPK16-2468
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to