[RFE]Support apply qos policy in VPN service

[zhaobo]

Issue
-------
For site to site type VPN, we need to limit the bandwidth of the VPN services, 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.

Propose
--------
So VPNaaS need find a way to meet this requirement by apply Neutron qos policy in VPN service, then the associated ServiceConnection will be affected by this Qos policy and do some limitation for east-west traffic.

[YAMAMOTO Takashi (yamamoto)]

your main interest is outgoing traffic shaping, right?
what's ServiceConnection? an equivalent of ipsec site connection?
the feature request sounds reasonable to me.
do you have an implementation idea for the reference implementations?

[zhaobo (zhaobo6)]

Thanks YAMAMOTO,
Yeah, just outgoing traffic.

For ServiceConnection, I think it is the same thing, Service Connection is about site connection for current VPNaaS reference implementation.

For VPN qos is very useful for real Datacenter, as the whole traffic will running based on the physical network. I had initial 2 ways for this feature.

1. Apply Neutron qos policy on the router interface port directly, but the ease-west traffic would be affected by this policy if there are other interface attached on the same router. So I think a use case about this, for the real usage of VPN, the user's VM will contain routes like:
VM IP:10.0.0.33

default via 10.0.0.1 (to access east-west or external network)
10.20.0.0 via 10.0.0.3 (to peer_vpn_cidr from other site.)

So I think this way is the right direction from some situation.

If the vm just contains a default route or we don't want to inject some necessary routes into vm, we can easy to set a route into the Router which its subnet gateway locates on. The route may like "10.20.0.0 via 10.0.0.3" either. The function works.

2. Use linux kernel to process the specific traffic and apply QoS with 'tc' command, in Router namespace, the external port 'qg-XXX'. The tc rule should be set like:
tc qdisc del dev qg-XXX root 2>/dev/null
tc qdisc add dev qg-XXX root handle 10: htb default 2254
tc class add dev qg-XXX parent 10: classid 10:1 htb rate 64kbps ceil 64kbps

And if we want more granularity like only some IPs on this subnet will be limited by the QoS. We could add 'tc' rule with iptables. But this way we may need to intro a new API for defining the QoS rule looks like, and it will have a strong-bonding relationship with l3 implementation.

Thanks, yamamoto. Wish you feedback. :)

[YAMAMOTO Takashi (yamamoto)]

what's 10.0.0.1 and 10.0.0.3 in your example?

[zhaobo (zhaobo6)]

10.0.0.1 is the default gw for the vm port. 10.0.0.3 is the nexthop for the traffic which want to access 10.20.0.0 which is the other vpn site cidr.

[zhaobo (zhaobo6)]

                                     +-------------------+ External network
                                     | Router +------Internet
                                     | |
                                     |10.0.0.1 |
                             +-------+ |
                             | | |
                             | | |
                             | | |
                             | +-------------------+
                             |
+-----------------------+ |
| VM A | |
| VNIC IP: 10.0.0.4 +----+
| default via 10.0.0.1 | |
| 10.20.0.0 via 10.0.0.3| |
| | |
| | |
| | | +------------------------+
+-----------------------+ | | Router |
                             | | |
                             | | |
                             | |10.0.0.3 | Internal network of
                             +-------+ RUNNING A +------some companies
                                     | VPN TO ACCESS | the deployed/planed
                                     | INTERNAL ZONE | network is 10.20.0.0/24
                                     | |
                                     | |
                                     | |
                                     +------------------------+

[zhaobo (zhaobo6)]

Oh, it's break. Please see
http://paste.openstack.org/show/628591/

[YAMAMOTO Takashi (yamamoto)]

what's 10.0.0.33?

in your diagram, you mean 10.20.0.0/24 is behind the vpn peer?

how the router 10.0.0.3 reaches to its vpn peer?

in your approach #1, which router interface are you talking about? 10.0.0.3?

in your approach #2, you mean qg-XXX of the router 10.0.0.3? from the diagram it isn't clear to me how the gateway port is set up.

[zhaobo (zhaobo6)]

Hi, YAMAMOTO. I answer below:

* what's 10.0.0.33?
10.0.0.33 is the VM nic IP address. This VM is in the 10.0.0.0/24 subnet, and it got a IP from this subnet.

* in your diagram, you mean 10.20.0.0/24 is behind the vpn peer?
10.20.0.0/24 Yeah, it locates on the internal company network env, this is the destination which the vm wants to access the internal subnet through vpn.

* how the router 10.0.0.3 reaches to its vpn peer?
We could do it like the general VPN does. Setup vpn services(openswan/strongswan) through the gwport(qg-XXX) to encapsulate traffic for let both site reachable.

* in your approach #1, which router interface are you talking about? 10.0.0.3?
Yes, if users not allow that we inject the routing in the vm, we can do it in the default router which 10.0.0.1 locates on. Then we can add another route like "10.20.0.0/24 via 10.0.0.3" to forward the traffic which want to access the vpn site to the other router which running vpn services(the Router which 10.0.0.3 locates on).

* in your approach #2, you mean qg-XXX of the router 10.0.0.3? from the diagram it isn't clear to me how the gateway port is set up.
No, they are different, the diagram just show the #1. Sorry for confused you. #2 described how to change the default behavior of router. There is only 1 router(which is the 10.0.0.1 locates on) in this case. The proposal is willing to add some "tc" rules in the router namespace.

Thanks

[Slawek Kaplonski (slaweq)]

Hi,

I don't know VPNaaS at all but from QoS point of view, it is already possible to apply QoS policy to router's qgXXX port if it is veth pair for example.
Proposition looks reasonable for me. I would like to read some specs with more detailed informations about it and of course drivers team needs to discuss about that :)

[zhaobo (zhaobo6)]

Hi Slawek,

Thanks very much for aware this. For QoS point of view, you are right and I miss something before, T_T, currently Neutron had supported the qos policy application on router's qg-XX port. And I also think that if there are some requirements from customers who want to migrate the old vpn to cloud application, so the expect is the most similar with the old configuration(config on physic devices), such as qos configuration, etc. So that's the idea. :)

And thanks for discussing. I will post a spec for this if possible. :)

[YAMAMOTO Takashi (yamamoto)]

i guess vpn traffic usually goes through the internet. thus it often traverses the same neutron routers and ports as the ordinary traffic to/from the internet.
my understanding is that you want to shape only vpn traffic, right?

[zhaobo (zhaobo6)]

Thanks, YAMAMOTO. Yeah, vpn traffic usually locates on the same router, but the diagram show that we config some routes into the default router, then forwarding the specific traffic which want to access the specific cidr to the router which vpn service locates on. Does it not work for your opinion? hmmm, I have never test it, as the our product deployed like that. So...

Correct, we only want to shape the vpn traffic, because we want to intro qos into vpn services. :)

[YAMAMOTO Takashi (yamamoto)]

zhaobo,

i didn't say if it works or not. (i don't know. :-)
i just wanted to be sure what's your intention.

i have a vague concern that applying vpn qos on qgXXX interfaces might not be straightforward.
iirc there's no guarantee the vpn traffic goes through via qgXXX, is it?

[zhaobo (zhaobo6)]

Thanks, YAMAMOTO.
I know your point and follow up, sorry. My intent is trying to limit the vpn traffic bandwidth, as the underlay network which the vpn locates on is not free. So I think we could focus on the Router's ports

The qg-XXX of the router which VPN services locates on, if the traffic will go through the external world , it must be encapsulated by the IP of qg-XXX whatever you want to cross openstack env or different tenant networks. hmmm, why the vpn traffic won't pass qgXXX, I still have no idea about this. Could you please help to show some simple examples for it? Thanks very much, i will your feedback, and I will reconsider the implementation if possible.

[zhaobo (zhaobo6)]

Hi all,

I had post a spec for this feature.
https://review.openstack.org/#/c/531074/

Please leave you kind suggestion there. And welcome ask question.

Thanks very much.

[Miguel Lavalle (minsel)]

This RFE was approved in today's drivers meeting. Let's continue the conversation in the spec

[zhaobo (zhaobo6)]

Wow, Thanks very much, Miguel. I just saw your latest comment. Sorry for late reply. I will focus on the spec. Thanks again.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/531074
Committed: https://git.openstack.org/cgit/openstack/neutron-specs/commit/?id=cc8b3ec9eeb2f76c5fd4f6cc8ec5f480fabee098
Submitter: Zuul
Branch: master

commit cc8b3ec9eeb2f76c5fd4f6cc8ec5f480fabee098
Author: ZhaoBo <email address hidden>
Date: Thu Jan 4 13:00:20 2018 +0800

    Spec for VPN service support Qos

    This is the spec for the VPN Qos.

    Paritial-Bug: #1727578
    Change-Id: I5f94b89d2e11734385b58e5e5edf55d149b9f38a
    Depends-On: If40305044c9dfe0024b64bd3921232bb0a6c9372