[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
Platform: 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
with name as say "port-router-net1-interface" and fixed-ip as subnet gateway ip of subnet1.

9. Create a port using neutron-port-create
with name as say "port-router-net2-interface" and fixed-ip as subnet gateway ip of subnet2.

10. Attach "port-router-net1-interface' to the router using
neutron router-interface-add Router port=port-router-net1-interface

11. Attach "port-router-net2-interface" to the router using
neutron router-interface-add Router port=port-router-net2-interface

12. Now make sure VM1 pings VM2. It may fail (or) succeed

13. Create a L3 BGPVPN.
neutron bgpvpn-create --route-targets 40:4 --import-targets 40:1 --route-distinguishers '400:1' --tenant_id $(keystone tenant-list | grep '\sadmin' | awk '

{print $2}') --name myBgpVpn1

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:
router-interface-add <router-name> <subnet-name> — (1)

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:
router-interface-add <router-name> port=<port-name>

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!) ?
If it does not, we need to explicitly figure from the fixed IP that it is essentially a router-interface-port and accordingly proceed.

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
carry the device_owner tag (I don't think so!) ?
If it does not, we need to explicitly figure from the fixed IP that it is
essentially a router-interface-port and accordingly proceed.
?"

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.
The port gets updated the way you mentioned.

Looking at the implementation aspects now.

Thanks,
Abhinav

Comment by Abhinav Gupta [ 06/Dec/16 ]

Hi Vivek,

I've tested as per the steps given.
Ping works! (both as per steps 12 and 14)

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.
Unavailability of the UP state for this leads to it being absent from vpninterfaces OPER DS, and thus further processing. This leads to datapath being always in tact.
Just that, some code changes need to be there to avoid vpninterfaces config population.

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,
Abhinav

Comment by Abhinav Gupta [ 08/Dec/16 ]

Hi Vivek,

As discussed, now we do need to create vpn-interfaces for router-interface ports.
So, the fix I was working on to remove the same is no longer required.

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.
Hence closing the bug as "RESOLVED" and "INVALID"

Generated at Wed Feb 07 20:21:12 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.