External network should not have provider:network_type as vxlan

[Stephen Ma]

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)]

I think additional validation should be added there

[Stephen Ma (stephen-ma)]

Hi Eugene,

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

[OpenStack Infra (hudson-openstack)]

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

[Robert Kukura (rkukura)]

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.

[OpenStack Infra (hudson-openstack)]

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.

[OpenStack Infra (hudson-openstack)]

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

[Eugene Nikanorov (enikanorov)]

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)]

@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)]

@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)]

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)]

@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.

[Kyle Mestery (mestery)]

Moving this to Liberty-1.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: neutron-pecan
Review: https://review.openstack.org/185072

[Steve Ruan (ruansx)]

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.