linux bridge trunk wiring shouldn't set tap mac address

[Kevin Benton]

Currently the linux bridge trunk plugin is setting the mac address on the tap devices for the subports to the same macs as the port model. When the VM sends traffic, this results in the warnings below which seems to result in the forwarding behavior being unstable. We shouldn't set the mac on this TAP device since it doesn't really serve a purpose.

Feb 26 16:40:09 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:10 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:10 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPDISCOVER(ns-1b771c00-9e) fa:16:3e:30:23:78
Feb 26 16:40:10 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:10 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPOFFER(ns-1b771c00-9e) 10.1.16.4 fa:16:3e:30:23:78
Feb 26 16:40:10 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:11 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:11 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:11 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:12 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPDISCOVER(ns-1b771c00-9e) fa:16:3e:30:23:78
Feb 26 16:40:12 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:12 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPOFFER(ns-1b771c00-9e) 10.1.16.4 fa:16:3e:30:23:78
Feb 26 16:40:15 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:17 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPDISCOVER(ns-1b771c00-9e) fa:16:3e:30:23:78
Feb 26 16:40:17 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address
Feb 26 16:40:17 ubuntu-xenial-osic-cloud1-s3500-7485658 dnsmasq-dhcp[10567]: DHCPOFFER(ns-1b771c00-9e) 10.1.16.4 fa:16:3e:30:23:78
Feb 26 16:40:19 ubuntu-xenial-osic-cloud1-s3500-7485658 kernel: brq9e974900-cd: received packet on tapa8a6ce4a-e8 with own address as source address

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/439615

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/439616

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/436541
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1fae7ad1085c4548b4019652256bcae49a36f192
Submitter: Jenkins
Branch: master

commit 1fae7ad1085c4548b4019652256bcae49a36f192
Author: Kevin Benton <email address hidden>
Date: Tue Feb 21 08:27:56 2017 -0800

    LB Trunk: Stop matching MAC of subport to port model

    Matching the MAC of the tap interface on the hypervisor
    to the MAC that the VM will actually use to send traffic
    through the tap causes the following error messages:

    brq9e974900-cd: received packet on tapa8a6ce4a-e8 with
    own address as source address

    This is triggering a warning because there are now two
    forwarding entries on the bridge, a static one from the
    tap device, and a learned one from the packets received.[1]

    Due to the presence of a static MAC entry, this will break
    things like allowed_address_pair use cases that allow a MAC
    to be used by multiple ports.

    This patch removes all of the logic to set the MAC
    address on the TAP device because it didn't serve any
    other purpose than easy to correlate output from
    ip link show commands and neutron port MAC addresses.

    TAP devices will now just get whatever MAC address the kernel
    selects for them.

    1. https://lists.linuxfoundation.org/pipermail/bridge/2004-January/003740.html

    Closes-Bug: #1668209
    Change-Id: I0ff46f9550a79f486063a8e2810ed3b1140a4769

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/439616
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bf4b614b5d8d551cece82e8c6aeb37737bce118f
Submitter: Jenkins
Branch: stable/newton

commit bf4b614b5d8d551cece82e8c6aeb37737bce118f
Author: Kevin Benton <email address hidden>
Date: Tue Feb 21 08:27:56 2017 -0800

    LB Trunk: Stop matching MAC of subport to port model

    Matching the MAC of the tap interface on the hypervisor
    to the MAC that the VM will actually use to send traffic
    through the tap causes the following error messages:

    brq9e974900-cd: received packet on tapa8a6ce4a-e8 with
    own address as source address

    This is triggering a warning because there are now two
    forwarding entries on the bridge, a static one from the
    tap device, and a learned one from the packets received.[1]

    Due to the presence of a static MAC entry, this will break
    things like allowed_address_pair use cases that allow a MAC
    to be used by multiple ports.

    This patch removes all of the logic to set the MAC
    address on the TAP device because it didn't serve any
    other purpose than easy to correlate output from
    ip link show commands and neutron port MAC addresses.

    TAP devices will now just get whatever MAC address the kernel
    selects for them.

    1. https://lists.linuxfoundation.org/pipermail/bridge/2004-January/003740.html

    Closes-Bug: #1668209
    (cherry picked from commit 1fae7ad1085c4548b4019652256bcae49a36f192)
    Change-Id: I0ff46f9550a79f486063a8e2810ed3b1140a4769

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/439615
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=70ede4cce4f22a96a0c22cd0ae79c9ca989cb186
Submitter: Jenkins
Branch: stable/ocata

commit 70ede4cce4f22a96a0c22cd0ae79c9ca989cb186
Author: Kevin Benton <email address hidden>
Date: Tue Feb 21 08:27:56 2017 -0800

    LB Trunk: Stop matching MAC of subport to port model

    Matching the MAC of the tap interface on the hypervisor
    to the MAC that the VM will actually use to send traffic
    through the tap causes the following error messages:

    brq9e974900-cd: received packet on tapa8a6ce4a-e8 with
    own address as source address

    This is triggering a warning because there are now two
    forwarding entries on the bridge, a static one from the
    tap device, and a learned one from the packets received.[1]

    Due to the presence of a static MAC entry, this will break
    things like allowed_address_pair use cases that allow a MAC
    to be used by multiple ports.

    This patch removes all of the logic to set the MAC
    address on the TAP device because it didn't serve any
    other purpose than easy to correlate output from
    ip link show commands and neutron port MAC addresses.

    TAP devices will now just get whatever MAC address the kernel
    selects for them.

    1. https://lists.linuxfoundation.org/pipermail/bridge/2004-January/003740.html

    Closes-Bug: #1668209

    (cherry picked from commit 1fae7ad1085c4548b4019652256bcae49a36f192)
    Change-Id: I0ff46f9550a79f486063a8e2810ed3b1140a4769

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.3.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 10.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b1 development milestone.