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' <majop...@redhat.com>; OpenStack Development
Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Cc: Armando M. <arma...@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:majop...@redhat.com]
Sent: Wednesday, August 10, 2016 12:04 PM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Cc: Armando M. <arma...@gmail.com>; Moshe Levi <mosh...@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_1...@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....@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
