Update the OVS agent code to program tunnels using ports instead of tunnel IDs

Bug #1196963 reported by Kyle Mestery
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released
Francois Eleouet

Bug Description

As part of the changes to support multiple tunnel_types [1] and deprecate enable_tunneling [2] in the agent configuration, it was decided during the review to program tunnels using port endpoints instead of using tunnel IDs. Once the OVS agent can concurrently support both GRE and VXLAN tunnel types in the context of ML2, this becomes relevant and will prevent tunnels sharing the same tunnel ID from polluting their BUM traffic between each other.

[1] https://review.openstack.org/#/c/33107/16
[2] https://review.openstack.org/#/c/34779/

Tags: ovs ml2
Changed in neutron:
assignee: nobody → mathieu rohon (mathieu-rohon)
tags: added: ovs
Changed in neutron:
importance: Medium → Wishlist
milestone: havana-2 → none
status: New → Triaged
tags: added: ml2
Robert Kukura (rkukura)
Changed in neutron:
milestone: none → havana-3
Changed in neutron:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

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

Revision history for this message
Mathieu Rohon (mathieu-rohon) wrote :

just a note to specify this bug :

create two networks : one with vxlan segment 101, one with gre segment 101.
deploy vm on two hypervisors, so that each hypervisors have almost one vm in each netwok.
The resulting flow table will be :

NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=49.276s, table=0, n_packets=0, n_bytes=0, idle_age=49, priority=3,tun_id=0x65,dl_dst=fa:16:3e:a4:06:ad actions=mod_vlan_vid:2,NORMAL
 cookie=0x0, duration=831.872s, table=0, n_packets=0, n_bytes=0, idle_age=831, priority=3,tun_id=0x65,dl_dst=fa:16:3e:14:37:15 actions=mod_vlan_vid:1,NORMAL
 cookie=0x0, duration=149.591s, table=0, n_packets=0, n_bytes=0, idle_age=149, priority=3,tun_id=0x65,dl_dst=fa:16:3e:55:a7:b2 actions=mod_vlan_vid:1,NORMAL
 cookie=0x0, duration=1091.831s, table=0, n_packets=89, n_bytes=9138, idle_age=16, priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x65,NORMAL
 cookie=0x0, duration=49.522s, table=0, n_packets=14, n_bytes=1292, idle_age=21, priority=4,in_port=1,dl_vlan=2 actions=set_tunnel:0x65,NORMAL
 cookie=0x0, duration=49.401s, table=0, n_packets=0, n_bytes=0, idle_age=49, priority=3,tun_id=0x65,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:2,output:1
 cookie=0x0, duration=3017.996s, table=0, n_packets=18, n_bytes=1368, idle_age=51, priority=1 actions=drop

as you can see, broadcast incoming packets from tunnel 101 (tun_id=0x65) will go in only one local vlan (vlan_vid:2), so broadcast traffic that come from the GRE tunnel 101 on hypervisor 1, may go to vm that have a port in a VXLan tunnel 101, on hypervisor 2.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in neutron:
assignee: Mathieu Rohon (mathieu-rohon) → Francois Eleouet (fanchon)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/41239
Committed: http://github.com/openstack/neutron/commit/a369f9e39691c01a4e4f7f8668cb37fc17ba03b3
Submitter: Jenkins
Branch: master

commit a369f9e39691c01a4e4f7f8668cb37fc17ba03b3
Author: Francois Eleouet <email address hidden>
Date: Wed Aug 7 11:19:46 2013 +0200

    Enable GRE and VXLAN with the same ID

    Current packet processing in br-tun is based on tun-id,
    as a consequence, two networks using different tunnel
    types but sharing the same tun-id would not be properly isolated.

    To ensure proper isolation within a single bridge, NORMAL action
    can't be used any more as it floods unknown unicasts on all
    bridges ports. It is replaced by a learn action that dynamically
    sets-up flows when packets are recieved from tunnel ports. As mac
    address are learnt in explicit flows (in table 20), we can use a
    default action in that table to flood unknown unicasts to the
    right set of ports, like broadcasts and multicasts packets.

    See https://wiki.openstack.org/wiki/Ovs-flow-logic for a more
    detailled explanation of the flow logic

    Another alternative could have been to use distinct bridges for
    each tunnel type (whithout modifying the current flow logic),
    but previous alternative may be preferable as it paves the way
    for new tunneling optimisations (like RPC based mac learning and
    partial-mesh flooding proposed in bp/l2-population)

    Change-Id: I1dfe74f96680c2c6fe4d8d4aac4821c6b020c005
    Closes-Bug: #1196963

Changed in neutron:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in neutron:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: havana-3 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.