Peter A Wilson (Systems Tech Marketing) wrote:
> 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.
>
That's what I thougt after reading one of the Sun blogs. But we use 
1.0.3 and we have a the firmware from patch 136936-04 and the issue 
still exists. I'll double-check this next week when I'm in the office again

BTW: We did not open a call for this bug yet because it's not a big deal 
if you know the workaround -- and hopefully this will work out of the 
box with version 1.1 of the ldm  software.


regards

Bernd

> 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
>>>
>>>   
>>
>>
>


-- 
Bernd Schemmer, Frankfurt am Main, Germany
http://home.arcor.de/bnsmb/index.html

M s temprano que tarde el mundo cambiar .
                        Fidel Castro


Reply via email to