Created attachment 1369383 [details] Flows dump from the source compute Description of problem: Using a setup with VLAN networks. Launching instances connected each to a different network and both connected to same router and the router also connected to an external network. Connectivity to the FIP of each instance works. There is no connectivity between the instances internal IPs. Version-Release number of selected component (if applicable): opendaylight-6.2.0-4.el7ost.noarch How reproducible: Steps to Reproduce: 1. Bring a setup with OpenDaylight and VLAN networks 2. Create an external network, two networks , a router. 3. Connect the router to each networks 4. Launch two instances , one connected to the first network and another to the second network 5. Ping from one of the instances to the other one and verify there is no connectivity Actual results: Expected results: Additional info:
After having a session with Aswin: When launching instances connected to each network on each compute node and then removing the interfaces from the router and adding a them back - there is connectivity.
Nir, This bug breaks the tenant network connectivity between vm in different tenant vlan network. This fix may require some significant changes in the netvirt code. Would like to know how important is this usecase for us, vlan tenant networks?
(In reply to Aswin Suryanarayanan from comment #2) > Nir, > > This bug breaks the tenant network connectivity between vm in different > tenant vlan network. This fix may require some significant changes in the > netvirt code. Would like to know how important is this usecase for us, vlan > tenant networks? To clarify, we are talking about east/west routing (one project/tenant, different subnets)? Does it apply for VLAN networks only? IPv4, IPv6, or both? Thanks, Nir
(In reply to Nir Yechiel from comment #3) > (In reply to Aswin Suryanarayanan from comment #2) > > Nir, > > > > This bug breaks the tenant network connectivity between vm in different > > tenant vlan network. This fix may require some significant changes in the > > netvirt code. Would like to know how important is this usecase for us, vlan > > tenant networks? > > To clarify, we are talking about east/west routing (one project/tenant, > different subnets)? Does it apply for VLAN networks only? IPv4, IPv6, or > both? > > Thanks, > Nir Yes it is one tenant different subnets. This affects vlan n/w only , but should affect both Ipv4 and Ipv6.
The connectivity between two tenant vlan n/w seems to be broken with the changes done as a part of [2]. The issue occurs in case where two dpn has just one vm belonging to two different vlan tenant n/w . The table 21 flows will be added only if the dpn has a port in that network. To solve this a pseudo port(uses router port uuid of that n/w) will be added to all vlan network in all dpn when vlan n/w is the part of a router. Thus ensuring necessary flows are programmed. This pseudo-port will be added only in elan-dpn-interfaces model of elan.yang. This port will be removed once the n/w is deleted from the router.
(In reply to Aswin Suryanarayanan from comment #10) > The connectivity between two tenant vlan n/w seems to be broken with the > changes done as a part of [2]. The issue occurs in case where two dpn has > just one vm belonging to two different vlan tenant n/w . > > The table 21 flows will be added only if the dpn has a port in that network. > To solve this a pseudo port(uses router port uuid of that n/w) will be added > to all vlan network in all dpn when vlan n/w is the part of a router. Thus > ensuring necessary flows are programmed. This pseudo-port will be added only > in elan-dpn-interfaces model of elan.yang. This port will be removed once > the n/w is deleted from the router. The link [2]https://github.com/opendaylight/netvirt/blob/stable/nitrogen/docs/specs/vlan-provider-enhancement.rst
The scenario fails. Checked with: opendaylight-8.0.0-5.el7ost.noarch
It seem that there were stale flow s. Fresh setup works. opendaylight-8.0.0-5.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086