Operating System: Linux
Platform: All

Attachment karaf_no_external_flow.zip has been added with description: Karaf logs

Attachment ovs_output.txt has been added with description: ovs outputs

We are using this feature quite a lot in our lab.

Could you please add the following debug information:

• neutron net-show <external-network>
• DS outputs: config/ietf-interfaces:interfaces, operational/ietf-interfaces:interfaces-state, config:elan:elan-instances

I found that the external network was being created without passing provider type "flat" or the physical network (in our case "datacentre"). This causes the external network to be created as a vxlan provider network. In L3 agent this has worked in the past because the agent just uses 'br-ex' by default, and this also used to work with old netvirt.

Once I re-created external network with --provider:network_type flat --provider:physical_network datacentre I see the flows. However, floating IP would still not work. After a fresh install with today's autorelease, I am able to create an external network and ssh into the instance over floating IP. However, I am unable to ping the router external IP. Also, after deleting and recreating the external network (and reassigning a new floating IP), floating IPs break and I cannot ssh into the instance anymore from external net.

I think these 2 issues are 2 different bugs from this one. But for this bug, I think we want to throw an error when an external network is created for type vxlan, right?

Happy to hear you were able to find the problem, this was one of the options I wanted to rule out using "neutron net-show". I wonder whether this configuration should've been blocked by openstack or not.

In any case, both other bugs you were mentioning are already opened:

• https://bugs.opendaylight.org/show_bug.cgi?id=7119 - We figured out this bug is due to a public net delete/create as you mentioned. Currently there is a fix undergoing review.

• https://trello.com/c/aeVj3Qss - Task to implement router gateway interface ping responder in Carbon. Currently the new netvirt only implements a ping responder for router interfaces (internal interfaces of a router).

Do you think we can close this bug?

Sorry, I missed your question regarding throwing an error for this. Let's keep this bug as a reminder, but we should probably lower its severity

After talking with Assaf from Neutron team, VXLAN should not be an allowed external network type. I will take it up with the Neutron project and we can close this bug.

Makes sense, thanks!