https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETVIRT-208 netvirt <p>This is a regression compared to Be with vpnservice. </p> <p>The most minimal setup I could reproduce this with was:</p> <p>-Two networks and a subnet for each<br/> -Create two routers and connect each to one subnet<br/> -Create an instance on each subnet<br/> -Pinging instances does not work at this step as it should be<br/> -Create a bgpvpn:<br/> neutron bgpvpn-create --name rski1 --import-targets 88:88 --export-targets 88:88 --route-distinguishers 11:11<br/> -create net assocs with the two networks:<br/> bgpvpn-net-assoc-create --network net1id bgpvpnid<br/> bgpvpn-net-assoc-create --network net2id bgpvpnid<br/> -try to ping instance 2 from instance one: does not work.</p> <p>It seems like the mechanism that ensures that layer 2 routing is disabled and instead packets are routed on layer 3 does not work. ARP related flows are active and the packets' dst ethernet address fields are not rewritten. </p> <p>Tested with Boron 0.5.1-20161017.001225-477</p> <p>Operating System: All<br/> Platform: All</p> NETVIRT-208

BGPVPN Network association does not work if subnets have routers

Bug Medium Resolved Won't Do Abhinav Gupta Romanos Skiadas Tue, 18 Oct 2016 11:30:23 +0000 Tue, 19 Nov 2019 18:34:39 +0000 Fri, 8 Nov 2019 10:46:07 +0000 Boron General 0 6 <p>Attachment karaf.log has been added with description: karaf log</p> <p>Attachment controller_ovs.txt has been added with description: Ovs information from the controller node</p> <p>Attachment compute_ovs.txt has been added with description: Compute ovs information</p> <p>Please use bpvpn-router-assoc-create * commands.</p> <p>Since you have subnets associated to routers, associate these routers to the same vpn and then try out ping between instances.</p> <p>Thanks,<br/> Abhinav</p> <p>Please allow me to correct myself here.</p> <p>1. As per the current implementation, we can associate only one router to a VPN.</p> <p>2. For your use-case, upon router-create for each of the routers, internal VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that, you are essentially indicating for this network to be a part of:</p> <p>a. The internal VPN previously created<br/> AND<br/> b. The new VPN it is being associated to.<br/> This is rightfully not allowed, hence you do not see the ping to be successful.</p> <p>So, either:</p> <p>1. add both of the subnets to router via “router-interface-add” and then do a “bgpvpn-router-assoc-create”<br/> OR<br/> 2. create networks with subnets and instances, then the VPNs, followed by “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via “router-interface-add”.</p> <p>Hope this clarifies.</p> <p>(In reply to Abhinav Gupta from comment #5)<br/> &gt; Please allow me to correct myself here.<br/> &gt; <br/> &gt; 1. As per the current implementation, we can associate only one router to a<br/> &gt; VPN.<br/> &gt; <br/> &gt; 2. For your use-case, upon router-create for each of the routers, internal<br/> &gt; VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that,<br/> &gt; you are essentially indicating for this network to be a part of:<br/> &gt; <br/> &gt; a. The internal VPN previously created<br/> &gt; AND<br/> &gt; b. The new VPN it is being associated to.<br/> &gt; This is rightfully not allowed, hence you do not see the ping to be<br/> &gt; successful.<br/> &gt; So, either:<br/> &gt; <br/> &gt; 1. add both of the subnets to router via “router-interface-add” and then do<br/> &gt; a “bgpvpn-router-assoc-create”<br/> &gt; OR</p> <p>&gt; <br/> &gt; Hope this clarifies.</p> <p>I understand your points, but the openstack documentation states it like so:<br/> Associating a BGPVPN to a Network can be done for both BGPVPN of type l2 and of type l3. For type L3, the semantic is that all Subnets bound to the Network will be interconnected with the BGP VPN (and thus between themselves).<br/> <a href="http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-association" class="external-link" target="_blank" rel="nofollow noopener">http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-association</a></p> <p>It seems to me that limiting the network association depending on whether subnets have been added to routers breaks the semantics of net-assoc. <br/> What I mean is that openstack promises that net-assoc will bind all the subnets to the VPN, but due to opendaylight constraints, this will fail silently, i.e. this bug.</p> <p>Further down in the openstack docs however:<br/> To avoid any ambiguity on semantics in particular the context of processing associated to a Router (e.g. NAT or FWaaS), if a said Subnet in a Network is bound to a Router, this API does not allow to both associate the Network to an L3 BGPVPN and the Router to the same or to a distinct L3 BGPVPN.</p> <p>This is indeed in some way what you're saying, but not exactly. Network assoc should not happen if there is a router assoc. For opendaylight there is an internal router assoc so having a router means that network assoc will always fail.</p> <p>I think that this same paragraph that explains the mutual exclusion of network and router association implies that network assoc should work for subnets attached to routers that don't participate in assocs, which is the gist of this bug.</p> <p>&gt; 2. create networks with subnets and instances, then the VPNs, followed by<br/> &gt; “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via<br/> &gt; “router-interface-add”.<br/> Yes, if we do not create routers this case works for Boron.</p> <p>(In reply to Romanos Skiadas from comment #6)<br/> &gt; (In reply to Abhinav Gupta from comment #5)<br/> &gt; &gt; Please allow me to correct myself here.<br/> &gt; &gt; <br/> &gt; &gt; 1. As per the current implementation, we can associate only one router to a<br/> &gt; &gt; VPN.<br/> &gt; &gt; <br/> &gt; &gt; 2. For your use-case, upon router-create for each of the routers, internal<br/> &gt; &gt; VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that,<br/> &gt; &gt; you are essentially indicating for this network to be a part of:<br/> &gt; &gt; <br/> &gt; &gt; a. The internal VPN previously created<br/> &gt; &gt; AND<br/> &gt; &gt; b. The new VPN it is being associated to.<br/> &gt; &gt; This is rightfully not allowed, hence you do not see the ping to be<br/> &gt; &gt; successful.<br/> &gt; &gt; So, either:<br/> &gt; &gt; <br/> &gt; &gt; 1. add both of the subnets to router via “router-interface-add” and then do<br/> &gt; &gt; a “bgpvpn-router-assoc-create”<br/> &gt; &gt; OR<br/> &gt; <br/> &gt; &gt; <br/> &gt; &gt; Hope this clarifies.<br/> &gt; <br/> &gt; I understand your points, but the openstack documentation states it like so:<br/> &gt; Associating a BGPVPN to a Network can be done for both BGPVPN of type l2 and<br/> &gt; of type l3. For type L3, the semantic is that all Subnets bound to the<br/> &gt; Network will be interconnected with the BGP VPN (and thus between<br/> &gt; themselves).<br/> &gt; <a href="http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-" class="external-link" target="_blank" rel="nofollow noopener">http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-</a><br/> &gt; association<br/> &gt; <br/> &gt; It seems to me that limiting the network association depending on whether<br/> &gt; subnets have been added to routers breaks the semantics of net-assoc. <br/> &gt; What I mean is that openstack promises that net-assoc will bind all the<br/> &gt; subnets to the VPN, but due to opendaylight constraints, this will fail<br/> &gt; silently, i.e. this bug.<br/> &gt; <br/> &gt; Further down in the openstack docs however:<br/> &gt; To avoid any ambiguity on semantics in particular the context of processing<br/> &gt; associated to a Router (e.g. NAT or FWaaS), if a said Subnet in a Network is<br/> &gt; bound to a Router, this API does not allow to both associate the Network to<br/> &gt; an L3 BGPVPN and the Router to the same or to a distinct L3 BGPVPN.<br/> &gt; <br/> &gt; This is indeed in some way what you're saying, but not exactly. Network<br/> &gt; assoc should not happen if there is a router assoc. For opendaylight there<br/> &gt; is an internal router assoc so having a router means that network assoc will<br/> &gt; always fail.<br/> &gt; <br/> &gt; I think that this same paragraph that explains the mutual exclusion of<br/> &gt; network and router association implies that network assoc should work for<br/> &gt; subnets attached to routers that don't participate in assocs, which is the<br/> &gt; gist of this bug.<br/> &gt; <br/> &gt; &gt; 2. create networks with subnets and instances, then the VPNs, followed by<br/> &gt; &gt; “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via<br/> &gt; &gt; “router-interface-add”.<br/> &gt; Yes, if we do not create routers this case works for Boron.</p> <p>I totally agree with you. Due to ODL limitations, we are restricting ourselves here.<br/> All along the implementation for Openstack/REST support for router/network(s) associations to VPN(s), this assumption was always taken into account.<br/> I believe with this bug, we should look at enabling both:<br/> a. L3 forwarding across subnets associated to the router.<br/> b. L3 forwarding across network(s) associated to this VPN</p> <p>Also, for associations/dissociations via REST APIs, we send out explicit detailed error logs, but for BGPVPN APIs, no error is being propagated. This also needs to be fixed.</p> <p>Do we have progress on this bug?</p> <p>(In reply to Nikolas Hermanns from comment #8)<br/> &gt; Do we have progress on this bug?</p> <p>I don't think so, this was in unassigned state until today, and today has been assigned to me.<br/> I don't see any fixes having gone in to take care of this..</p> <p>Ah ok, that is now problem. But thanks that you look into that!</p> <p>Hello, is there any news from this bug?</p> <p>Old bug, will reopen if seen again</p> Development External issue ID 6962 External issue URL Rank 0|i01qdr: