Vpnaas: Vpn_agent is not able to handle two vpn service object for the same router.

Bug #1318550 reported by varun kumar yadav
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
vikas

Bug Description

neutron net-create ext-net1 --router:external=True
neutron subnet-create --allocation-pool start=192.142.0.60,end=192.142.0.100 --gateway 192.142.0.1 ext-net1 192.142.0.0/16 --enable_dhcp=False

step 1=>
neutron net-create net1
neutron subnet-create net1 10.10.1.0/24 --name sub1
neutron router-create r1
neutron router-interface-add r1 sub1
neutron router-gateway-set r1 ext-net1

neutron net-create net2
neutron subnet-create net2 10.10.2.0/24 --name sub2
neutron router-create r2
neutron router-interface-add r2 sub2
neutron router-gateway-set r2 ext-net1

neutron vpn-ikepolicy-create ikepolicy1
neutron vpn-ipsecpolicy-create ipsecpolicy1
neutron vpn-service-create --name myvpn1 --description "My vpn service" r1 sub1
neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn1 --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 192.142.0.61 --peer-id 192.142.0.61 --peer-cidr 10.10.2.0/24 --psk secret

neutron vpn-ikepolicy-create ikepolicy2
neutron vpn-ipsecpolicy-create ipsecpolicy2
neutron vpn-service-create --name myvpn2 --description "My vpn service" r2 sub2

neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpn2 --ikepolicy-id ikepolicy2 --ipsecpolicy-id ipsecpolicy2 --peer-address 192.142.0.60 --peer-id 192.142.0.60 --peer-cidr 10.10.1.0/24 --psk secret

create one more network on site1 net3 with subnet 5.5.5.0/24 sub3
create a network on site2 net4 with subnet 8.8.8.0/24 sub4

create a service objects myvpn3 with r1 and sub3
create a service objects myvpn4 with r2 and sub4

create a ipsecsite connection

 neutron ipsec-site-connection-create --name vpnconnection3 --vpnservice-id myvpn3 --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 192.142.0.61 --peer-id 192.142.0.61 --peer-cidr 5.5.5.0/24 --psk secret

neutron ipsec-site-connection-create --name vpnconnection4 --vpnservice-id myvpn2 --ikepolicy-id ikepolicy2 --ipsecpolicy-id ipsecpolicy2 --peer-address 192.142.0.60 --peer-id 192.142.0.60 --peer-cidr 8.8.8.0/24 --psk secret

ipsecsite connection with vpnconnection3 and vpnconnection4 always goes into pending create state.

basically i am trying to bind two vpn service objects with one routerid

Tags: api vpnaas
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

That seems like a severe issue, however it's not whether it is a race condition or vpn agent just can't handle more then one vpn connection.

Is there any errors in neutron server or vpn agent logs related to those vpn connections?

tags: added: vpnaas
Changed in neutron:
importance: Undecided → High
status: New → Incomplete
summary: - vpnaas:Aether->Vpn_agent is not able to handle two ipsec-site connection
+ Vpnaas:Vpn_agent is not able to handle two ipsec-site connection
creation request simultaneously.
vikas (vikas-d-m)
Changed in neutron:
assignee: nobody → vikas (vikas-d-m)
summary: - Vpnaas:Vpn_agent is not able to handle two ipsec-site connection
- creation request simultaneously.
+ Vpnaas: Vpn_agent is not able to handle two vpn service object for the
+ same router.
Revision history for this message
varun kumar yadav (varunkumaryadav) wrote :

Hi Eugene,

i have changed the title of the bug and to be more specific with description here basically i am trying to create the two service objects with same router which is seems to be design constrain of the VPNaaS .

for clear understanding i have attached a bug-description.png in attachement. i thing it will be more of an enhancement if a router can handle more then one service object.

Revision history for this message
Johnson Dantis (johnson-dantis) wrote :

Currently the design and object model in VPNaaS allows creation of 1 service object per router and per subnet. Attached the object diagram to indicate this design. But you can have multiple VPN connection objects per service. Most probably the design of this object model is influenced by L3 design. But I think with current object model design supported by VPNaaS, there is no constraint on creating any deployment scenario. It is a matter of knowing the restriction and designing the topology.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/117403

Changed in neutron:
status: Incomplete → In Progress
vikas (vikas-d-m)
no longer affects: openstack-tempest (Ubuntu)
tags: added: api
Changed in neutron:
importance: High → Medium
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Are you going to continue working on this bug?

Revision history for this message
vikas (vikas-d-m) wrote :

yes added a new patchset

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/117403
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Revision history for this message
Paul Michali (pcm) wrote :

This is, by design, not supported. The service and router must be 1:1. A blueprint would need to be submitted to change the design, IMO. Changing to invalid.

Changed in neutron:
status: In Progress → Invalid
Changed in neutron:
status: Invalid → Fix Released
Revision history for this message
Vicent (vicent-ferrerguasch) wrote :

Hi,

I changed the status to Fix Released and I cannot change it back to Invalid.

Anyway, I would like to have the possibility to have multiple services with the same router. So we could reuse the public IP address with multiple Ipsec Site connections. It is a very useful feature when the public IP addresses are limited.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.