Duplicated traffic in SR-IOV and DVR mode

[Kristina Berezovskaia]

Detailed bug description:
 On DVR VLAN env vm with SR-IOV has duplicated traffic during pin external host or internal ip

Steps to reproduce:
1. Deployed env with SR-IOV and DVR
2. Create net1, subnet
3. Create net2, subnet
4. Create DVR router, set gatawey, add interface for both nets
5. Create sr-iov port in net1 (port_sriov_1)
6. Create sr-iov port in net2 (port_sriov_2)
7. Boot ubuntu vm1 with port port_sriov_1
8. Boot ubuntu vm 2with port port_sriov_2
9. Associate floating for vm1
10. Ping from vm1 8.8.8.8, ping vm2 by floating

Expected results:
 Ping is available, packets are not duplicated

Actual result:
Packets are duplicated:
ubuntu@vm-ew-1:~$ ping 10.1.2.6
PING 10.1.2.6 (10.1.2.6) 56(84) bytes of data.
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.312 ms
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.313 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.313 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.313 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.314 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.314 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.314 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.315 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.315 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.315 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.316 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.316 ms (DUP!)
64 bytes from 10.1.2.6: icmp_seq=1 ttl=63 time=0.316 ms (DUP!)

ubuntu@vm-ew-1:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=5.41 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=5.41 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=5.41 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=5.41 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=4.36 ms

Description of the environment:
Find on iso 155, vlan+dvr+enable sr-iov

Additional information:
 I boot usual vm in net1 and ping 8.8.8.8 work good

[Atsuko Ito (yottatsa)]

Even with DVR enabled, SR-IOV ports could be used with Provider networks (without DVR). This requires from end user to setup physnets according to it.

[Svetlana Karslioglu (skarslioglu)]

Please describe the documentation impact in more details.

[Evgeny Konstantinov (evkonstantinov)]

Marking this wontfix. Feel free to reopen if you have the doc impact & description of what needs to be implemented in the docs.

[David Hill (david-hill-ubisoft)]

What needs to be documented here is that a SR-IOV port should only be attached to the VM and not put in a DVR router as this will duplicate the ports ... from my understanding of the issue.

Here is a simple representation of what should be configured:

VM -> SR-IOV VF -> SR-IOV PF -> Switch

and here is what you have configured when adding the SR-IOV port to the router:
VM \ -> SR-IOV VF -> SR-IOV PF -> Switch # port attached to the VM
    \ -> SR-IOV VF -> OVS -> SR-IOV-PF -> Switch # port also attached to the OVS router

... and that's what is duplicating the packets. I guess here we could :

1) Prevent attaching the SR-IOV port to a DVR router ...

I can't think of another possibility but it doesn't mean there're none.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/611059

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/615126

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/615126
Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=29f128cd1f9499ad4c600898d90ebf5b9ceca5f3
Submitter: Zuul
Branch: master

commit 29f128cd1f9499ad4c600898d90ebf5b9ceca5f3
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Nov 2 10:29:20 2018 +0000

    Check if a port can be bound to a virtual bridge

    If port VNIC type is "normal", the port can be bound to a virtual bridge;
    e.g.: Linux Bridge, OVS.

    Change-Id: I0dab235bd492538c7fa909dace08fad2267a589d
    Partial-Bug: #1566951

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/611059
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1966ad3945a7a44beeefc603f9d6da54ac67f9a3
Submitter: Zuul
Branch: master

commit 1966ad3945a7a44beeefc603f9d6da54ac67f9a3
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Nov 2 11:35:25 2018 +0000

    Check port VNIC type when associating a floating IP

    When associating a floating IP to a port and the router is distributed,
    the VNIC type of this port must be "normal" only. In any other case,
    the floating IP can't be assigned. For example, a SR-IOV can have a
    floating IP if the router is distributed (the router is in the same
    host of the port).

    Closes-Bug: #1566951

    Change-Id: I4944041df81e24683bc612560808bcdcc2db6bf2

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.openstack.org/631837

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/631842

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/631844

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/631837
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=0f14e30fa4618d0f3041f9f4bfb066ad248f19ed
Submitter: Zuul
Branch: stable/rocky

commit 0f14e30fa4618d0f3041f9f4bfb066ad248f19ed
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Nov 2 11:35:25 2018 +0000

    Check port VNIC type when associating a floating IP

    When associating a floating IP to a port and the router is distributed,
    the VNIC type of this port must be "normal" only. In any other case,
    the floating IP can't be assigned. For example, a SR-IOV can have a
    floating IP if the router is distributed (the router is in the same
    host of the port).

    This patch adds also function can_port_be_bound_to_virtual_bridge to
    neutron/db/l3_db.py module.
    Originally this function was introduced in neutron-lib with [1] but
    in stable branch there is older neutron-lib used so this isn't available
    from neutron-lib.

    [1] https://review.openstack.org/#/c/615126/

    Closes-Bug: #1566951

    Change-Id: I4944041df81e24683bc612560808bcdcc2db6bf2
    (cherry picked from commit 1966ad3945a7a44beeefc603f9d6da54ac67f9a3)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/631842
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1c573bb8b949baf591d8e0744537be4c0d1faa72
Submitter: Zuul
Branch: stable/queens

commit 1c573bb8b949baf591d8e0744537be4c0d1faa72
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Nov 2 11:35:25 2018 +0000

    Check port VNIC type when associating a floating IP

    When associating a floating IP to a port and the router is distributed,
    the VNIC type of this port must be "normal" only. In any other case,
    the floating IP can't be assigned. For example, a SR-IOV can have a
    floating IP if the router is distributed (the router is in the same
    host of the port).

    This patch adds also function can_port_be_bound_to_virtual_bridge to
    neutron/db/l3_db.py module.
    Originally this function was introduced in neutron-lib with [1] but
    in stable branch there is older neutron-lib used so this isn't available
    from neutron-lib.

    [1] https://review.openstack.org/#/c/615126/

    Closes-Bug: #1566951

    Change-Id: I4944041df81e24683bc612560808bcdcc2db6bf2
    (cherry picked from commit 1966ad3945a7a44beeefc603f9d6da54ac67f9a3)
    (cherry picked from commit 0f14e30fa4618d0f3041f9f4bfb066ad248f19ed)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/631844
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=edd8ad31d7cd9f340ebe8a607b6c6487a78ad7e5
Submitter: Zuul
Branch: stable/pike

commit edd8ad31d7cd9f340ebe8a607b6c6487a78ad7e5
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Nov 2 11:35:25 2018 +0000

    Check port VNIC type when associating a floating IP

    When associating a floating IP to a port and the router is distributed,
    the VNIC type of this port must be "normal" only. In any other case,
    the floating IP can't be assigned. For example, a SR-IOV can have a
    floating IP if the router is distributed (the router is in the same
    host of the port).

    This patch adds also function can_port_be_bound_to_virtual_bridge to
    neutron/db/l3_db.py module.
    Originally this function was introduced in neutron-lib with [1] but
    in stable branch there is older neutron-lib used so this isn't available
    from neutron-lib.

    [1] https://review.openstack.org/#/c/615126/

    Closes-Bug: #1566951

    Change-Id: I4944041df81e24683bc612560808bcdcc2db6bf2
    (cherry picked from commit 1966ad3945a7a44beeefc603f9d6da54ac67f9a3)
    (cherry picked from commit 0f14e30fa4618d0f3041f9f4bfb066ad248f19ed)
    (cherry picked from commit 1c573bb8b949baf591d8e0744537be4c0d1faa72)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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