Open Stack

Hi,

My (original) question regarding the uniqueness of Neutron port MAC addresses didn't concern SR-IOV support or vendor NICs. It was simply about the behavior w.r.t. virtual networks. I believe Armando has confirmed what I had been suspecting.

Thanks,
Anil

-----Original Message-----
From: Miguel Angel Ajo Pelayo [mailto:majopela at redhat.com] 
Sent: Friday, August 12, 2016 1:46 AM
To: Moshe Levi
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

That was my feeling Moshe, thanks for checking.

Anil, which card and drivers are you using exactly?

You should probably contact your card vendor and check if they have a fix for the issue, which seems more like a bug on their implementation of the embedded switch, the card or the driver.

Best regards,
Miguel  Ángel.

On Thu, Aug 11, 2016 at 12:49 PM, Moshe Levi <moshele at mellanox.com> wrote:
> Hi Anil,
>
>
> I tested it with Mellanox NIC and it working
>
> 16: enp6s0d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
>     link/ether 00:02:c9:e9:c2:12 brd ff:ff:ff:ff:ff:ff
>     vf 0 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
>     vf 1 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
>     vf 2 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
>     vf 3 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
>     vf 4 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto
>     vf 5 MAC fa:16:3e:0d:8c:a2, vlan 192, spoof checking on, link-state enable
>     vf 6 MAC fa:16:3e:0d:8c:a2, vlan 190, spoof checking on, link-state enable
>     vf 7 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, 
> link-state auto
>
> I guess the problem is with the SR-IOV NIC/ driver you are using maybe 
> you should contact them
>
>
> -----Original Message-----
> From: Moshe Levi
> Sent: Wednesday, August 10, 2016 5:59 PM
> To: 'Miguel Angel Ajo Pelayo' <majopela at redhat.com>; OpenStack 
> Development Mailing List (not for usage questions) 
> <openstack-dev at lists.openstack.org>
> Cc: Armando M. <armamig at gmail.com>
> Subject: RE: [openstack-dev] [neutron] Neutron Port MAC Address 
> Uniqueness
>
> Miguel,
>
> I talked to our driver architect and according to him this is vendor implementation (according to him this  should work with  Mellanox NIC) I need to verify that this indeed working.
> I will update after I will prepare SR-IOV setup and try it myself.
>
>
> -----Original Message-----
> From: Miguel Angel Ajo Pelayo [mailto:majopela at redhat.com]
> Sent: Wednesday, August 10, 2016 12:04 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev at lists.openstack.org>
> Cc: Armando M. <armamig at gmail.com>; Moshe Levi <moshele at mellanox.com>
> Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address 
> Uniqueness
>
> @moshe, any insight on this?
>
> I guess that'd depend on the nic internal switch implementation and how the switch ARP tables are handled there (per network, or global per switch).
>
> If that's the case for some sr-iov vendors (or all), would it make sense to have a global switch to create globally unique mac addresses (for the same neutron deployment, of course).
>
> On Wed, Aug 10, 2016 at 7:38 AM, huangdenghui <hdh_1983 at 163.com> wrote:
>> hi Armando
>>     I think this feature causes problem in sriov scenario, since 
>> sriov NIC don't support the vf has the same mac,even the port belongs 
>> to the different network.
>>
>>
>> 发自网易邮箱手机版
>>
>>
>> On 2016-08-10 04:55 , Armando M. Wrote:
>>
>>
>>
>> On 9 August 2016 at 13:53, Anil Rao <anil.rao at gigamon.com> wrote:
>>>
>>> Is the MAC address of a Neutron port on a tenant virtual network 
>>> globally unique or unique just within that particular tenant network?
>>
>>
>> The latter:
>>
>> https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.
>> py#L139
>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Anil
>>>
>>>
>>> ____________________________________________________________________
>>> _ _____ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>
>> _____________________________________________________________________
>> _ ____ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev