1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Open vSwitch documentation:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
Avoid deeper levels because they do not render well.
========================
Quality of Service (QoS)
========================
Q: Does OVS support Quality of Service (QoS)?
A: Yes. For traffic that egresses from a switch, OVS supports traffic
shaping; for traffic that ingresses into a switch, OVS support policing.
Policing is a simple form of quality-of-service that simply drops packets
received in excess of the configured rate. Due to its simplicity, policing
is usually less accurate and less effective than egress traffic shaping,
which queues packets.
Keep in mind that ingress and egress are from the perspective of the
switch. That means that egress shaping limits the rate at which traffic is
allowed to transmit from a physical interface, but not the rate at which
traffic will be received on a virtual machine's VIF. For ingress policing,
the behavior is the opposite.
Q: How do I configure egress traffic shaping?
A: Suppose that you want to set up bridge br0 connected to physical
Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces vif1.0
and vif2.0, and that you want to limit traffic from vif1.0 to eth0 to 10
Mbps and from vif2.0 to eth0 to 20 Mbps. Then, you could configure the
bridge this way::
$ ovs-vsctl -- \
add-br br0 -- \
add-port br0 eth0 -- \
add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
set port eth0 qos=@newqos -- \
--id=@newqos create qos type=linux-htb \
other-config:max-rate=1000000000 \
queues:123=@vif10queue \
queues:234=@vif20queue -- \
--id=@vif10queue create queue other-config:max-rate=10000000 -- \
--id=@vif20queue create queue other-config:max-rate=20000000
At this point, bridge br0 is configured with the ports and eth0 is
configured with the queues that you need for QoS, but nothing is actually
directing packets from vif1.0 or vif2.0 to the queues that we have set up
for them. That means that all of the packets to eth0 are going to the
"default queue", which is not what we want.
We use OpenFlow to direct packets from vif1.0 and vif2.0 to the queues
reserved for them::
$ ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal
$ ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal
Each of the above flows matches on the input port, sets up the appropriate
queue (123 for vif1.0, 234 for vif2.0), and then executes the "normal"
action, which performs the same switching that Open vSwitch would have done
without any OpenFlow flows being present. (We know that vif1.0 and vif2.0
have OpenFlow port numbers 5 and 6, respectively, because we set their
ofport_request columns above. If we had not done that, then we would have
needed to find out their port numbers before setting up these flows.)
Now traffic going from vif1.0 or vif2.0 to eth0 should be rate-limited.
By the way, if you delete the bridge created by the above commands, with::
$ ovs-vsctl del-br br0
then that will leave one unreferenced QoS record and two unreferenced Queue
records in the Open vSwich database. One way to clear them out, assuming
you don't have other QoS or Queue records that you want to keep, is::
$ ovs-vsctl -- --all destroy QoS -- --all destroy Queue
If you do want to keep some QoS or Queue records, or the Open vSwitch you
are using is older than version 1.8 (which added the ``--all`` option),
then you will have to destroy QoS and Queue records individually.
Q: How do I configure ingress policing?
A: A policing policy can be configured on an interface to drop packets that
arrive at a higher rate than the configured value. For example, the
following commands will rate-limit traffic that vif1.0 may generate to
10Mbps::
$ ovs-vsctl set interface vif1.0 ingress_policing_rate=10000
$ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000
Traffic policing can interact poorly with some network protocols and can
have surprising results. The "Ingress Policing" section of
ovs-vswitchd.conf.db(5) discusses the issues in greater detail.
Q: I configured Quality of Service (QoS) in my OpenFlow network by adding
records to the QoS and Queue table, but the results aren't what I expect.
A: Did you install OpenFlow flows that use your queues? This is the
primary way to tell Open vSwitch which queues you want to use. If you
don't do this, then the default queue will be used, which will probably not
have the effect you want.
Refer to the previous question for an example.
Q: I'd like to take advantage of some QoS feature that Open vSwitch doesn't yet
support. How do I do that?
A: Open vSwitch does not implement QoS itself. Instead, it can configure
some, but not all, of the QoS features built into the Linux kernel. If you
need some QoS feature that OVS cannot configure itself, then the first step
is to figure out whether Linux QoS supports that feature. If it does, then
you can submit a patch to support Open vSwitch configuration for that
feature, or you can use "tc" directly to configure the feature in Linux.
(If Linux QoS doesn't support the feature you want, then first you have to
add that support to Linux.)
Q: I configured QoS, correctly, but my measurements show that it isn't working
as well as I expect.
A: With the Linux kernel, the Open vSwitch implementation of QoS has two
aspects:
- Open vSwitch configures a subset of Linux kernel QoS features, according
to what is in OVSDB. It is possible that this code has bugs. If you
believe that this is so, then you can configure the Linux traffic control
(QoS) stack directly with the "tc" program. If you get better results
that way, you can send a detailed bug report to bugs@openvswitch.org.
It is certain that Open vSwitch cannot configure every Linux kernel QoS
feature. If you need some feature that OVS cannot configure, then you
can also use "tc" directly (or add that feature to OVS).
- The Open vSwitch implementation of OpenFlow allows flows to be directed
to particular queues. This is pretty simple and unlikely to have serious
bugs at this point.
However, most problems with QoS on Linux are not bugs in Open vSwitch at
all. They tend to be either configuration errors (please see the earlier
questions in this section) or issues with the traffic control (QoS) stack
in Linux. The Open vSwitch developers are not experts on Linux traffic
control. We suggest that, if you believe you are encountering a problem
with Linux traffic control, that you consult the tc manpages (e.g. tc(8),
tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or mailing
lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
Q: Does Open vSwitch support OpenFlow meters?
A: Open vSwitch 2.0 added OpenFlow protocol support for OpenFlow meters.
Open vSwitch 2.7 implemented meters in the userspace datapath. Open
vSwitch 2.10 implemented meters in the Linux kernel datapath.
|
