Merge "Spec for VPN service support Qos"
This commit is contained in:
commit
ac7d3cffcc
|
@ -0,0 +1,311 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
========================
|
||||||
|
VPN Services Support QoS
|
||||||
|
========================
|
||||||
|
|
||||||
|
https://bugs.launchpad.net/neutron/+bug/1727578
|
||||||
|
|
||||||
|
Currently, there is no way to set VPN services' bandwidth. This specification
|
||||||
|
proposed a way to set the VPN services' bandwidth limit.
|
||||||
|
|
||||||
|
|
||||||
|
Problem Description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Currently, Neutron VPNaaS provides site to site VPN services, but its bandwidth
|
||||||
|
consumption is not regulated, as the VPN tunnel will cost the bandwidth from
|
||||||
|
the outside public bandwidth provided by the ISP or other organizations. That
|
||||||
|
means it is not free. The OpenStack provider or users should pay for the
|
||||||
|
limited bandwidth. So it is necessary for saving the resources.
|
||||||
|
|
||||||
|
Currently, physical device configurations outside OpenStack environment cannot
|
||||||
|
be modified by OpenStack, but we can shape the outgoing traffic. VPN services
|
||||||
|
provide the security guarantee, but it shouldn't abuse the bandwidth of
|
||||||
|
underlay network that it will affects other traffic.
|
||||||
|
|
||||||
|
Use Case
|
||||||
|
--------
|
||||||
|
|
||||||
|
Consider that an OpenStack public cloud has been deployed in a real data
|
||||||
|
center. A cloud enterprise user has a requirement in which one of the
|
||||||
|
applications should connect to its private network 20.0.0.0/24, but for other
|
||||||
|
traffic flows, still use the original network functionality provided by
|
||||||
|
OpenStack. The network topology diagram is shown below::
|
||||||
|
|
||||||
|
+
|
||||||
|
+--------------------+ + |DataCenter
|
||||||
|
|VM1 | | |external network
|
||||||
|
|nic IP: 10.0.0.11 | | +-------------------------------+ | +----+
|
||||||
|
|default via 10.0.0.1+---+ |Default Router | | | |
|
||||||
|
| | +-----------------+Interface: 10.0.0.1 +------+ | |
|
||||||
|
+--------------------+ | |gw: 172.24.4.11 | | | |
|
||||||
|
OpenStack | |route: 20.0.0.0/24 via 10.0.0.5| | | |
|
||||||
|
private . | | | | | |
|
||||||
|
network . | +-------------------------------+ | | |
|
||||||
|
| | | |
|
||||||
|
subnet: 10.0.0.0/24 | | | |
|
||||||
|
+--------------------+ | | | |
|
||||||
|
|VM2 | | +--------+ |Internet
|
||||||
|
|nic IP: 10.0.0.12 | | | | |
|
||||||
|
|default via 10.0.0.1+---+ | | |
|
||||||
|
| | | | | |
|
||||||
|
+--------------------+ | | | |
|
||||||
|
| | | |
|
||||||
|
. | +--------------------------------+ | | | +-------------------------------+
|
||||||
|
. | |VPN Router | | | | |Vendor GW Router |
|
||||||
|
| |Interface: 10.0.0.5 | | | | |peer vpn service running |
|
||||||
|
+-----------------+gw: 172.24.4.12 +-----+ | +-------+hold private subnet 20.0.0.0/24|
|
||||||
|
+--------------------+ | |VPN service running | | | | | |
|
||||||
|
|VMX | | | | | | | | |
|
||||||
|
|nic IP: 10.0.0.13 | | +--------------------------------+ | +----+ +-------------------------------+
|
||||||
|
|default via 10.0.0.1+---+ |
|
||||||
|
| | | |
|
||||||
|
+--------------------+ | |
|
||||||
|
| |
|
||||||
|
+ +
|
||||||
|
|
||||||
|
As this diagram shows, the enterprise user owned many VMs in the private
|
||||||
|
network and the allocated IPs are from the private subnet 10.0.0.0/24. There
|
||||||
|
are two routers connected, ``Default Router`` is used for the normal network
|
||||||
|
functions, such as NAT, Floating IP, Routing. ``VPN Router`` is mainly used for
|
||||||
|
VPN traffic process, also contains NAT and route for other traffic. Both of the
|
||||||
|
routers are attached to the external network which is the physical underlay
|
||||||
|
network in the real data center. The VPN Router in OpenStack and Vendor GW
|
||||||
|
Router in other site maintain a VPN peer relationship across the Internet.
|
||||||
|
|
||||||
|
There are two scenarios towards the VM outgoing traffic:
|
||||||
|
|
||||||
|
1. VMs in the OpenStack private network access the normal websites, first send
|
||||||
|
the network packets to its gateway which is located on the
|
||||||
|
``Default Router``. Then send to the Internet by the data center devices.
|
||||||
|
2. VMs in the OpenStack private network access the other site private network
|
||||||
|
20.0.0.0/24, still first send the network packets to its gateway 10.0.0.1,
|
||||||
|
then check the route tables, the nexthop of 20.0.0.0/24 is 10.0.0.5 which
|
||||||
|
is located on ``VPN Router``. The network traffic will be sent based on the
|
||||||
|
existing VPN tunnel to Vendor private site.
|
||||||
|
|
||||||
|
Like the diagram shows, the QoS Policy should be set on the qg-XX port of the
|
||||||
|
VPN router for limiting the outgoing VPN traffic.
|
||||||
|
|
||||||
|
This spec focuses on the QoS of VPN outgoing traffic, so for neutron-vpnaas,
|
||||||
|
this spec will focus on the Router related with VPN services. And for the
|
||||||
|
general use cases which is that VPN service usually setup across the Internet
|
||||||
|
in tunnel mode, we will only introduce the QoS support on tunnel type VPN
|
||||||
|
services.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
We propose the ``VPN Service`` resource accepts the Neutron QoS Policy. Once
|
||||||
|
the ``ipsec site connection`` is created, the QoS Policy will be applied on the
|
||||||
|
VPN router's qg-XX port, as the ESP encapsulation will use the qg-XX port's IP
|
||||||
|
to access other sites.
|
||||||
|
|
||||||
|
So there are three parts that require to work:
|
||||||
|
|
||||||
|
1. DB related changes, including new table ``qos_vpnservice_policy_bindings``
|
||||||
|
addition and data model change.
|
||||||
|
2. API changes, including extend the API to accept the Neutron QoS Policy.
|
||||||
|
3. Introduce a new l3 agent extension to extend the ability to process the QoS
|
||||||
|
policy installation on the router.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
* Accept the QoS parameters and implement the QoS function on our own.
|
||||||
|
* Apply QoS Policy on the Router interface directly, but this would affect the
|
||||||
|
west-east traffic.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
In this spec, the QoS data model and function will be provided by Neutron, so
|
||||||
|
``vpnservices`` table need to maintain the relationship with Neutron QoS
|
||||||
|
Policy.
|
||||||
|
|
||||||
|
The following new table is added as part of the VPN QoS feature::
|
||||||
|
|
||||||
|
CREATE TABLE `qos_vpnservice_policy_bindings` (
|
||||||
|
`vpn_service_id` varchar(36) NOT NULL,
|
||||||
|
`qos_policy_id` varchar(36) NOT NULL,
|
||||||
|
UNIQUE KEY `vpn_service_id` (`vpn_service_id`),
|
||||||
|
KEY `qos_policy_id` (`qos_policy_id`),
|
||||||
|
CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_1` FOREIGN KEY (
|
||||||
|
`qos_policy_id`) REFERENCES `qos_policies` (`id`) ON DELETE CASCADE,
|
||||||
|
CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_2` FOREIGN KEY (
|
||||||
|
`vpn_service_id`) REFERENCES `vpnservices` (`id`) ON DELETE CASCADE
|
||||||
|
);
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Proposed attribute::
|
||||||
|
|
||||||
|
EXTEND_FIELDS = {
|
||||||
|
'qos_policy_id':{'allow_post': True, 'allow_put': True,
|
||||||
|
'validate': {'type:uuid': None},
|
||||||
|
'is_visible': True,
|
||||||
|
'default': None}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Some samples in ``VPN service`` create/update. Users are allowed to pass
|
||||||
|
``qos_policy_id``.
|
||||||
|
|
||||||
|
Create/Update ``VPN service`` Request::
|
||||||
|
|
||||||
|
POST /v2.0/vpn/vpnservices
|
||||||
|
{
|
||||||
|
"vpnservice": {
|
||||||
|
"subnet_id": null,
|
||||||
|
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c",
|
||||||
|
"router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa",
|
||||||
|
"name": "myservice",
|
||||||
|
"admin_state_up": true
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Response:
|
||||||
|
{
|
||||||
|
"vpnservice": {
|
||||||
|
"router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa",
|
||||||
|
"status": "PENDING_CREATE",
|
||||||
|
"name": "myservice",
|
||||||
|
"external_v6_ip": "2001:db8::1",
|
||||||
|
"admin_state_up": true,
|
||||||
|
"subnet_id": null,
|
||||||
|
"project_id": "10039663455a446d8ba2cbb058b0f578",
|
||||||
|
"tenant_id": "10039663455a446d8ba2cbb058b0f578",
|
||||||
|
"external_v4_ip": "172.32.1.11",
|
||||||
|
"id": "5c561d9d-eaea-45f6-ae3e-08d1a7080828",
|
||||||
|
"description": "",
|
||||||
|
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
PUT /v2.0/vpn/vpnservices/{service_id}
|
||||||
|
{
|
||||||
|
"vpnservice": {
|
||||||
|
"name": "NEW VPN SERVICE NAME",
|
||||||
|
"description": "Updated description",
|
||||||
|
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
Response:
|
||||||
|
{
|
||||||
|
"vpnservice": {
|
||||||
|
"router_id": "881b7b30-4efb-407e-a162-5630a7af3595",
|
||||||
|
"status": "ACTIVE",
|
||||||
|
"name": "NEW VPN SERVICE NAME",
|
||||||
|
"admin_state_up": true,
|
||||||
|
"subnet_id": null,
|
||||||
|
"project_id": "26de9cd6cae94c8cb9f79d660d628e1f",
|
||||||
|
"tenant_id": "26de9cd6cae94c8cb9f79d660d628e1f",
|
||||||
|
"id": "41bfef97-af4e-4f6b-a5d3-4678859d2485",
|
||||||
|
"description": "Updated description",
|
||||||
|
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
QoS Policy Application Details
|
||||||
|
------------------------------
|
||||||
|
|
||||||
|
The reason for introducing this, for example, we change the use case below, we
|
||||||
|
deploy the vpn service on the ``Default Router``, delete the ``VPN Router``.
|
||||||
|
That means the general traffic and VPN traffic will pass through the
|
||||||
|
``Default Router``, then we apply the Neutron QoS policy on the qg-XX port of
|
||||||
|
the ``Default Router``, it will limit all the bandwidth, so the VPN's bandwidth
|
||||||
|
may have a lower performance, or we can say it is not consistent with
|
||||||
|
expectations.
|
||||||
|
|
||||||
|
Currently, Neutron provides the QoS function but not for some interest streams.
|
||||||
|
Here we will focus on the VPN traffic. For this function, we will combine
|
||||||
|
the ``iptables`` and ``tc`` together. The reason for choosing them is that,
|
||||||
|
``iptables`` could mark the VPN interest stream by the ipsec VPN transform
|
||||||
|
protocols(such as esp, ah-esp protocols), the interface that the packets
|
||||||
|
will go out and the local encapsulated IP if running in tunnel mode. Also we
|
||||||
|
need to shape the vpn traffic before send out to the underlay network, so some
|
||||||
|
new ``iptables`` rules will be installed on mangle table in the router's
|
||||||
|
namespace. Also the ``fwmark`` is eaiser to extend, such as ipchains.
|
||||||
|
|
||||||
|
And we will introduce a new ``tc`` wrapper which will use ``htb`` and it will
|
||||||
|
provides classification algorithm. Then developers can easily implement other
|
||||||
|
complex traffic control. That means we will extend the current tc_lib in
|
||||||
|
Neutron repo. And ``vpn_qos`` will based on this.
|
||||||
|
|
||||||
|
Just like above description, a new L3 agent extension will be introduced like
|
||||||
|
fip_qos done. We suggest to name it ``vip_qos``, it will install the
|
||||||
|
appropriate ``iptables`` rules in the router's namespace which binds with
|
||||||
|
``VPN service``. Then users or managers could use the QoS function to the
|
||||||
|
``Default Router`` and not affect other network streams.
|
||||||
|
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
None
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
No expected change.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
Users will be able to specify qos_policy during create/update ``VPN service``.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
It will save the bandwidth of the underlay network in data center.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
Developer may use the new ``tc`` wrapper to do other things, as it is powerful
|
||||||
|
to support other stream control functionality.
|
||||||
|
But there may be a conflict with openstack/neutron-classifier, as it provides
|
||||||
|
defining the traffic. So we may reconsider that if possible.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
zhaobo
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
* Add the DB model and extend the table column.
|
||||||
|
* Extend VPN API to accept QoS policy.
|
||||||
|
* Extend new tc wrapper which support classification algorithm based on
|
||||||
|
traffic classifier feature.
|
||||||
|
* Extend new L3 agent extension ``vip_qos``.
|
||||||
|
* Add API validation code to validate access/existence of the qos_policy which
|
||||||
|
created in Neutron.
|
||||||
|
* Add UTs to Neutron-vpnaas.
|
||||||
|
* Add API tests.
|
||||||
|
* Update CLI to accept QoS fields.
|
||||||
|
* Documentation work.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
Unit tests, functional tests, API tests and scenario tests are necessary.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
The Neutron API reference will need to be updated.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
Loading…
Reference in New Issue