Bug 1743349

Summary:	0xFE is not allowed as the first byte of the MAC address for emulated network devices based on a tap device
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	Laine Stump <laine>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED ERRATA	QA Contact:	yalzhang <yalzhang>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.0	CC:	ailan, asadan, danken, jdenemar, lmen, rmohr, sscheink, xuzhang
Target Milestone:	pre-dev-freeze
Target Release:	8.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-5.6.0-2.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-11-06 07:18:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Laine Stump 2019-08-19 17:00:55 UTC

(copied verbatim from the patch that fixes the bug)

Back in July 2010, commit 6ea90b84 (meant to resolve https://bugzilla.redhat.com/571991 ) added code to set the MAC address of any tap device to the associated guest interface's MAC, but with the first byte replaced with 0xFE. This was done in order to assure that
    
1) the tap MAC and guest interface MAC were different (otherwise L2
   forwarding through the tap would not work, and the kernel would
   repeatedly issue a warning stating as much).

2) any bridge device that had one of these taps attached would *not*
   take on the MAC of the tap (leading to network instability as
   guests started and stopped)
    
A couple years later, https://bugzilla.redhat.com/798467 was filed, complaining that a user could configure a tap-based guest interface to have a MAC address that itself had a first byte of 0xFE, silently (other than the kernel warning messages) resulting in a non-working configuration. This was fixed by commit 5d571045, which logged an error and failed the guest start / interface attach if the MAC's first byte was 0xFE.
    
Although this restriction only reduces the potential pool of MAC addresses from 2^46 (last two bits of byte 1 must be set to 10) by 2^32 (still 4 orders of magnitude larger than the entire IPv4 address space), it also means that management software that autogenerates MAC addresses must have special code to avoid an 0xFE prefix. Now after 7 years, someone has noticed this restriction and requested that we remove it, i.e. they want libvirt to permit guest interfaces with a MAC address that starts with 0xFE.

Comment 1 Laine Stump 2019-08-19 17:04:57 UTC

The fix is that when we check for an FE prefix in the guest MAC address, instead of failing, we should instead just use a prefix of 0xFA for the tap device. A fix has been pushed upstream, and will be in libvirt-5.7.0:

commit a60ee914009aa7f1a27fc0563337ded08b09247f
Author: Laine Stump <laine>
Date:   Sun Aug 11 16:21:42 2019 -0400

    util: allow tap-based guest interfaces to have MAC address prefix 0xFE

Comment 4 yalzhang@redhat.com 2019-08-21 10:20:17 UTC

Reproduce on libvirt-5.0.0-12.module+el8.0.1+3755+6782b0ed.x86_64:

1. Start vm:
# virsh dumpxml rhel | grep "<mac"
      <mac address='fe:54:00:58:48:ed'/>
# virsh start rhel
error: Failed to start domain rhel
error: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'fe:54:00:58:48:ed' - 

2. hotplug:
prepare a running vm, hotplug an interface with mac address with prefix as "FE"
# virsh attach-interface rhel network default --mac fe:54:00:58:48:ed
error: Failed to attach interface
error: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'fe:54:00:58:48:ed' - 

Test on libvirt-5.6.0-2.module+el8.1.0+4015+63576633.x86_64:

1. Start vm:

# virsh dumpxml rhel | grep "<mac"
      <mac address='fe:54:00:70:58:07'/>

# virsh start rhel 
Domain rhel started

# virsh dumpxml rhel | grep "<mac" -A2
      <mac address='fe:54:00:70:58:07'/>
      <source network='default' portid='a5d3c662-4c87-45a4-a086-cfce1539195e' bridge='virbr0'/>
      <target dev='vnet0'/>

# ip addr | grep vnet0 -A2
98: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000
    link/ether fa:54:00:70:58:07 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f854:ff:fe70:5807/64 scope link 

2. hotplug:

# virsh attach-interface rhel network default --mac fe:54:00:70:58:09
Interface attached successfully

# virsh dumpxml rhel | grep "<mac" -A2
..
 <mac address='fe:54:00:70:58:09'/>
      <source network='default' portid='7f1a8de4-6551-464e-9170-b328fa1faeb6' bridge='virbr0'/>
      <target dev='vnet1'/>

# ip addr | grep vnet1 -A2
101: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000
    link/ether fa:54:00:70:58:09 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f854:ff:fe70:5809/64 scope link 

And check the network function works well, set the bug to be verified.

Comment 6 errata-xmlrpc 2019-11-06 07:18:55 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:3723