External network should not have provider:network_type as vxlan

Bug #1328991 reported by Stephen Ma on 2014-06-11
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Medium
Aman Kumar

Bug Description

Given this is the ml2_conf.ini file on a controller node that also runs neutron API server, DHCP and L3 agents.
[ml2]
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers = openvswitch,l2population
tenant_network_types = vxlan

[ml2_type_flat]

[ml2_type_vlan]

[ml2_type_gre]
tunnel_id_ranges = 1:1000

[ml2_type_vxlan]
vni_ranges = 1001:65535

[database]
connection = mysql://...

[ovs]
local_ip = 192.0.2.24
enable_tunneling = True

[agent]
tunnel_types = vxlan
l2_population = True
polling_interval = 2
minimize_polling = True

[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

When the tripleo-incubator's setup-neutron.sh script creates the external network on this node (devstack runs the same command):

    neutron net-create ext-net --router:external=True

neutron net-show ext-net displays:

# neutron net-show ext-net
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | 94384f38-0cb0-4336-a7c3-293858dec2ba |
| name | ext-net |
| provider:network_type | vxlan |
| provider:physical_network | |
| provider:segmentation_id | 1002 |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | b0585eeb-ea5a-4741-a759-4497f6e6c21a |
| tenant_id | 8b0a6343ca3e471bbcf0a78e084a98c0 |
+---------------------------+--------------------------------------+

The provider:network_type of vxlan is not appropriate for an external network because the only ports possible on it are floatingips and router gateways. There are no VM ports. So vxlan tunnels for this network won't be created at all.

Eugene Nikanorov (enikanorov) wrote :

I think additional validation should be added there

tags: added: api l3-ipam-dhcp
Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
Stephen Ma (stephen-ma) wrote :

Hi Eugene,

Please explain what is meant by "additional validation should be added there".

Stephen Ma (stephen-ma) on 2014-07-01
Changed in neutron:
assignee: nobody → Stephen Ma (stephen-ma)

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

Changed in neutron:
status: Confirmed → In Progress
Changed in neutron:
assignee: Stephen Ma (stephen-ma) → Erik Colnick (erikcolnick)
Robert Kukura (rkukura) wrote :

When no provider attributes are supplied for an external network, setting its network_type to 'local' instead of allocating a tenant network would make sense. There should be no restrictions on what network_types are allowed when the provider attributes are supplied.

Changed in neutron:
status: In Progress → New

Change abandoned by Salvatore Orlando (<email address hidden>) on branch: master
Review: https://review.openstack.org/105639
Reason: This patch has been inactive long enough that I think it's safe to abandon.
The author can resurrect it if needed.

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

Changed in neutron:
assignee: Erik Colnick (erikcolnick) → Aman Kumar (amank)
status: New → In Progress
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Aman Kumar (amank) on 2015-02-04
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Aman Kumar (amank) on 2015-02-05
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Shiv Haris (shh) on 2015-03-04
Changed in neutron:
milestone: none → kilo-3
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Kyle Mestery (mestery) on 2015-03-19
Changed in neutron:
milestone: kilo-3 → kilo-rc1
Eugene Nikanorov (enikanorov) wrote :

I really don't think it makes sense to introduce another config parameter.
By validation I meant that external network creation with inappropriate network type should just fail.

Romil Gupta (romilg) wrote :

@Eugene: Here is the concern is currently, the external_network type is taken from configured types in tenant_network_types config parameter which is not correct.

so, we added a config variable 'external_network_type' which represent the default external network type if we don't provide provider attributes.

And, what do you mean by inappropriate network type for a external network?

Aman Kumar (amank) wrote :

@Eugene: What do mean by inappropriate network type.

Can you tell me if user doesn't provide any network type and any attributes then from where
it will take network type? Currently it is taking from tenant network type which is not correct.

I guess in this case it should not fail, because it is not an inappropriate case. There should be
some default value for external network type and it is 'local'.

Eugene Nikanorov (enikanorov) wrote :

External network creation is typically an admin operation (this is defined by policy.json), so the admin should know how to create it properly.

If you think that default should be 'local' then why don't just hardcode it into ml2 plugin? I think it would make more sense than additional cfg parameter, and that would require less changes.

Romil Gupta (romilg) wrote :

@Eugene: The default value could be local, vlan, vxlan, gre or flat . So, simply hard coding it doesn't make any sense.
Also, probably you may need to look at the discussion happened on the patch set between other core reviewers to get the proper context.

Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Kyle Mestery (mestery) wrote :

Moving this to Liberty-1.

Changed in neutron:
milestone: kilo-rc1 → liberty-1
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)
Changed in neutron:
assignee: Aman Kumar (amank) → Romil Gupta (romilg)
Changed in neutron:
assignee: Romil Gupta (romilg) → Aman Kumar (amank)

Reviewed: https://review.openstack.org/149546
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=26b4e57858ef83ef9343f053c2835a95f6e6c860
Submitter: Jenkins
Branch: master

commit 26b4e57858ef83ef9343f053c2835a95f6e6c860
Author: Aman Kumar <email address hidden>
Date: Fri Jan 23 01:34:00 2015 -0800

    Added config variable for External Network type in ML2

    Description:
    With the ML2 Plugin, every network created has segments with
    provider:network_types being tenant_network_types.
    When applied to external networks, the types that could be in
    tenant_network_types parameter (like vxlan or gre) are not appropriate.

    Implementation:
    Added new config variable 'external_network_type' in ml2_conf.ini
    which contains the default network type for external networks
    when no provider attributes are specified, by default it is None.

    It also includes small code re-factoring/renaming of import statement.

    DocImpact

    Closes-Bug: #1328991

    Co-Authored-By: Romil Gupta <email address hidden>

    Change-Id: Idbbe6bced73cfedbe0f8e7abba35f87589b1a004

Changed in neutron:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2015-06-24
Changed in neutron:
status: Fix Committed → Fix Released
Steve Ruan (ruansx) wrote :

Hi Stephen,

I read all the discussion, BUT I did not get the point: why external network can NOT be vxlan.
Will it lead to any function wrong?

In my opinion, we should keep this option, maybe vxlan will be external connectiontity in some way.

Thierry Carrez (ttx) on 2015-10-15
Changed in neutron:
milestone: liberty-1 → 7.0.0
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers