RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1623260 - OVN: configurable dynamic mac range
Summary: OVN: configurable dynamic mac range
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: lorenzo bianconi
QA Contact: haidong li
URL:
Whiteboard:
Depends On:
Blocks: 1647750
TreeView+ depends on / blocked
 
Reported: 2018-08-28 20:42 UTC by Dan Kenigsberg
Modified: 2020-01-14 22:42 UTC (History)
12 users (show)

Fixed In Version: openvswitch-2.9.0-80.el7fdn
Doc Type: Enhancement
Doc Text:
This update adds the possibility to specify an OUI for MAC addresses dynamically allocated by OVN. As a result, users can specify an OUI for each OVN deployment to avoid MAC address collisions.
Clone Of:
: 1647750 (view as bug list)
Environment:
Last Closed: 2019-01-02 17:54:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0014 0 None None None 2019-01-02 17:54:52 UTC

Description Dan Kenigsberg 2018-08-28 20:42:16 UTC 
Currently, OVN allocate MAC addresses from a hard-coded range.

Users have multiple deployments of OVN accessing the same LAN (e.g. via localnet), causing MAC collisions.

As an OVN administrator, I would like to set the start_MAC address and end_MAC address from which my addresses would be allocated. I would set a different range for each of my OVN deployments to avoid collisions.

It would be nice if by default, each deployment would automatically have a big random range, e.g. a single random OUI of locally-administered unicast addresses
Comment 2 Daniel Alvarez Sanchez 2018-11-06 13:53:19 UTC 
Could this work for you [0]?

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1626217
Comment 3 Dan Kenigsberg 2018-11-06 15:00:08 UTC 
Yes, setting options:mac_prefix=<mac_prefix> in NB_Global table seems to solve my RFE.

Though I would like to see a sane (random) value there on any new installation.
When two OVN instances share the same underlying L2 network, each should have a different prefix (unless the customer is exponentially unlucky).
Comment 4 lorenzo bianconi 2018-11-06 17:28:24 UTC 
-upstream commit:
https://github.com/openvswitch/ovs/commit/282e53576530faab217c61b6eb7e0f5a49da0ce2
Comment 5 Dan Kenigsberg 2018-11-08 15:13:42 UTC 
(In reply to lorenzo bianconi from comment #4)
> -upstream commit:
> https://github.com/openvswitch/ovs/commit/
> 282e53576530faab217c61b6eb7e0f5a49da0ce2

Lorenzo, does this include setting a random default upon installation?
Comment 6 lorenzo bianconi 2018-11-09 14:38:03 UTC 
Hi Dan,

no, it does not. With current implementation you can specify the OUI used by IPAM/MACAM (or the default one if you do not specify it). I think select OUI in a random fashion could be dangerous since duplicate MAC address is a very hard issue to debug if the deployment is huge. Anyway if you think it is an important feature to have we can introduce something like "mac_prefix:random"
Comment 7 Dan Kenigsberg 2018-11-09 16:03:01 UTC 
Yes it is important. Without it, you effectively get mac_prefix:random on an incredibly huge range.

I'm asking to limit it, so that out of the box, people get a wide range that is very likely to differ from other installation nearby.

I'm not asking for logic change, but rather a default overwriable value.
Comment 8 lorenzo bianconi 2018-11-09 16:33:35 UTC 
(In reply to Dan Kenigsberg from comment #7)

Hi Dan,

> Yes it is important. Without it, you effectively get mac_prefix:random on an
> incredibly huge range.
> 

do you think specifying a given OUI for each deployment is not feasible?
If not (since we could have a huge number of deployments) we can add 'mac_prefix:random' where the OUI is chosen in a random fashion at ovn-northd bootstrap, but in order to maintain compatibility with old deployments I guess to not make it the default choice

> I'm asking to limit it, so that out of the box, people get a wide range that
> is very likely to differ from other installation nearby.
> 
> I'm not asking for logic change, but rather a default overwriable value.

what do you mean with 'a default overwriable value'?
Comment 10 haidong li 2018-12-03 03:19:48 UTC 
verified on the latest version:
[root@hp-dl388g8-19 ovn]# uname -a
Linux hp-dl388g8-19.rhts.eng.pek2.redhat.com 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@hp-dl388g8-19 ovn]# rpm -qa | grep openvswitch
openvswitch-2.9.0-81.el7fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-1.0-108.noarch
openvswitch-ovn-common-2.9.0-81.el7fdp.x86_64
openvswitch-ovn-host-2.9.0-81.el7fdp.x86_64
openvswitch-selinux-extra-policy-1.0-8.el7fdp.noarch
openvswitch-ovn-central-2.9.0-81.el7fdp.x86_64
[root@hp-dl388g8-19 ovn]#  ovn-nbctl ls-add sw6
[root@hp-dl388g8-19 ovn]# ovn-nbctl  set NB_Global . options:mac_prefix="00:11:22:33:44:55"
[root@hp-dl388g8-19 ovn]# ovn-nbctl  set Logical-Switch sw6 other_config:subnet=192.168.100.0/24
[root@hp-dl388g8-19 ovn]# ovn-nbctl lsp-add sw6 p6 -- lsp-set-addresses p6 dynamic
[root@hp-dl388g8-19 ovn]# ovn-nbctl get Logical-Switch-Port p6 dynamic_addresses
"00:11:22:a8:64:03 192.168.100.2"
[root@hp-dl388g8-19 ovn]# ovn-nbctl lsp-add sw6 p7 -- lsp-set-addresses p7 dynamic
[root@hp-dl388g8-19 ovn]#  ovn-nbctl get Logical-Switch-Port p7 dynamic_addresses
"00:11:22:a8:64:04 192.168.100.3"
Comment 12 Dan Kenigsberg 2018-12-19 07:56:41 UTC 
(In reply to lorenzo bianconi from comment #8)
> 
> what do you mean with 'a default overwriable value'?

You have introduced a new configurable: options:mac_prefix=<mac_prefix>
However, on installation of ovn, it is left unset. This means that out of the box, ovn would keep generating random MACs which may collide with MACs on other clusters.

You put the burden of setting this on your client.

Instead, I ask to add the following logic to ovn installation:

  if options:mac_prefix is not defined:
    options:mac_prefix=random_6_digit_prefix_of_a_locally_administered_unicast_mac

a user that hates your default can modify it, but most would be silently happy.
Could you add it?
(p.s I've missed your comment 8)
Comment 13 lorenzo bianconi 2018-12-19 15:10:45 UTC 
(In reply to Dan Kenigsberg from comment #12)
> (In reply to lorenzo bianconi from comment #8)
> > 
> > what do you mean with 'a default overwriable value'?
> 
> You have introduced a new configurable: options:mac_prefix=<mac_prefix>
> However, on installation of ovn, it is left unset. This means that out of
> the box, ovn would keep generating random MACs which may collide with MACs
> on other clusters.
> 
> You put the burden of setting this on your client.
> 
> Instead, I ask to add the following logic to ovn installation:
> 
>   if options:mac_prefix is not defined:
>    
> options:
> mac_prefix=random_6_digit_prefix_of_a_locally_administered_unicast_mac
> 
> a user that hates your default can modify it, but most would be silently
> happy.
> Could you add it?

Hi Dan,

I think it is doable, we should just choose mac_prefix in a random manner (let's say according to ovn-northd boot-time) if the user does not provide a value for it.
The only concern is about what happens if the user restart the ovn-northd daemon, is it ok to recompute dynamically allocated mac addresses?
If not, we need to save that info in the NBDB

> (p.s I've missed your comment 8)
Comment 14 Dan Kenigsberg 2018-12-19 15:35:34 UTC 
(In reply to lorenzo bianconi from comment #13)

> > 
> > Instead, I ask to add the following logic to ovn ***installation***:  <----------------
> > 
> >   if options:mac_prefix is not defined:
> >    
> > options:
> > mac_prefix=random_6_digit_prefix_of_a_locally_administered_unicast_mac
> > 
> > a user that hates your default can modify it, but most would be silently
> > happy.
> > Could you add it?
> 
> Hi Dan,
> 
> I think it is doable, we should just choose mac_prefix in a random manner
> (let's say according to ovn-northd boot-time) if the user does not provide a
> value for it.
> The only concern is about what happens if the user restart the ovn-northd
> daemon, is it ok to recompute dynamically allocated mac addresses?

I'd find it very confusing. OVN users shouldn't be aware of an OVN restart/reboot

> If not, we need to save that info in the NBDB

right. that's my preference.
Comment 15 lorenzo bianconi 2018-12-20 09:01:35 UTC 
(In reply to Dan Kenigsberg from comment #14)
> (In reply to lorenzo bianconi from comment #13)
> 
> > > 
> > > Instead, I ask to add the following logic to ovn ***installation***:  <----------------
> > > 
> > >   if options:mac_prefix is not defined:
> > >    
> > > options:
> > > mac_prefix=random_6_digit_prefix_of_a_locally_administered_unicast_mac
> > > 
> > > a user that hates your default can modify it, but most would be silently
> > > happy.
> > > Could you add it?
> > 
> > Hi Dan,
> > 
> > I think it is doable, we should just choose mac_prefix in a random manner
> > (let's say according to ovn-northd boot-time) if the user does not provide a
> > value for it.
> > The only concern is about what happens if the user restart the ovn-northd
> > daemon, is it ok to recompute dynamically allocated mac addresses?
> 
> I'd find it very confusing. OVN users shouldn't be aware of an OVN
> restart/reboot
> 
> > If not, we need to save that info in the NBDB
> 
> right. that's my preference.

ok, I will take care of it
Comment 17 errata-xmlrpc 2019-01-02 17:54:40 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0014
Note You need to log in before you can comment on or make changes to this bug.