[NETVIRT-297] Router interfaces constructed with pre-created ports fails L3 in Datapath when such router is put into BGPVPN Created: 24/Nov/16 Updated: 19/Nov/19 Resolved: 08/Dec/16 |
|
| Status: | Resolved |
| Project: | netvirt |
| Component/s: | General |
| Affects Version/s: | Boron |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Vivekanandan Narasimhan | Assignee: | Abhinav Gupta |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 7237 |
| Description |
|
When the router interfaces are added using pre-constructed neutron ports (with subnet gateway ips of course), and then when we associate such router to a L3 BGPVPN, L3 forwarding fails in datapath between VMs on the arms of such router. Steps to create the problem: 1. Create network 1 2. Create a subnet1 on network1. 3. Boot VM1 on network 1 4. Create network 2 5. Create a subnet2 on network2. 6. Boot VM2 on network 2 7. Create a Router 8. Create a port using neutron-port-create 9. Create a port using neutron-port-create 10. Attach "port-router-net1-interface' to the router using 11. Attach "port-router-net2-interface" to the router using 12. Now make sure VM1 pings VM2. It may fail (or) succeed 13. Create a L3 BGPVPN. 14. Associate the router to this myBgpVpn1. neutron bgpvpn-net-assoc-create myBgpVpn1 --network $(neutron router-list |grep '\sRouter' |awk '{print $2} ') 15. Now again ping from VM1 to VM2 and it FAILS. |
| Comments |
| Comment by Abhinav Gupta [ 25/Nov/16 ] |
|
Hi Vivek, We have been all through supporting router-interface add by specifying subnet, like as in: Is there a new requirement to support such a config where first the port is manually created to behave like a router interface port and then doing: As of now, we match on the device_owner tag shipped to us by Openstack for the router-interface-port created as part of operation (1) and thereby, we proceed going through the ports on that subnet to add VPN rules. With the way as described in the bug, will this created router-interface-port carry the device_owner tag (I don't think so!) ? Please share your thoughts on this. |
| Comment by Vivekanandan Narasimhan [ 25/Nov/16 ] |
|
"With the way as described in the bug, will this created router-interface-port The port will get updated with DEVICE_ID as router-id and DEVICE_OWNER as network:router_interface and we have to service that updated port the same way we service a brand new router interface port. The IP in itself has no bearing, though it is better to give the fixed_ip to match the subnet-gateway-ip to mimic the subnet attach to router behavior. Try it out yourself on the openstack setup and based on that come back with more questions (if you have |
| Comment by Abhinav Gupta [ 25/Nov/16 ] |
|
Hi Vivek, I've checked on Openstack. Looking at the implementation aspects now. Thanks, |
| Comment by Abhinav Gupta [ 06/Dec/16 ] |
|
Hi Vivek, I've tested as per the steps given. This is because the code to handle updation of a port to become a router-interface port is already there. Besides this, upon explicit creation of such a neutron port, we do treat it like a normal vm interface and add it to VPN Interfaces config DS. I've tested router-interface-delete too, and it works as expected. In this case, shall we close this bug, and create a new with lower priority to handle port-creation handling, or we make that fix with this bug id itself? Regards, |
| Comment by Abhinav Gupta [ 08/Dec/16 ] |
|
Hi Vivek, As discussed, now we do need to create vpn-interfaces for router-interface ports. If you see it deem fit, can we close this bug now? |
| Comment by Vivekanandan Narasimhan [ 08/Dec/16 ] |
|
Hi Abhinav, If the issue is not appearing, yes let us close the bug. Vivek |
| Comment by Abhinav Gupta [ 08/Dec/16 ] |
|
The issue is not reproducible, and all the usecases indicated to be failing work as expected. |