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:
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.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:
DB related changes, including new table
qos_vpnservice_policy_bindingsaddition and data model change.API changes, including extend the API to accept the Neutron QoS Policy.
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.
