@@ -276,7 +276,7 @@ Q: What DPDK version does each Open vSwitch release work with?
2.6.x 16.07
============ =====
-Q: I get an error like this when I configure Open vSwitch:::
+Q: I get an error like this when I configure Open vSwitch::
configure: error: Linux kernel in <dir> is version <x>, but
version newer than <y> is not supported (please refer to the
@@ -479,7 +479,7 @@ Q: How do I configure a DPDK port as an access port?
startup when other_config:dpdk-init is set to 'true'.
Secondly, when adding a DPDK port, unlike a system port, the type for the
- interface must be specified. For example:::
+ interface must be specified. For example::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
@@ -546,7 +546,7 @@ Q: How do I configure mirroring of all traffic to a GRE tunnel?
A: The following commands configure br0 with eth0 and tap0 as trunk ports.
All traffic coming in or going out on eth0 or tap0 is also mirrored to
gre0, a GRE tunnel to the remote host 192.168.1.10; any traffic arriving on
- gre0 is dropped:::
+ gre0 is dropped::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -557,7 +557,7 @@ Q: How do I configure mirroring of all traffic to a GRE tunnel?
-- --id=@m create mirror name=m0 select-all=true output-port=@p \
-- set bridge br0 mirrors=@m
- To later disable mirroring and destroy the GRE tunnel:::
+ To later disable mirroring and destroy the GRE tunnel::
$ ovs-vsctl clear bridge br0 mirrors
$ ovs-vsctl del-port br0 gre0
@@ -720,7 +720,7 @@ Configuration Problems
----------------------
Q: I created a bridge and added my Ethernet port to it, using commands like
-these:::
+these::
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
@@ -735,7 +735,7 @@ eth0. Help!
You can restore functionality by moving the IP address to an Open vSwitch
"internal" device, such as the network device named after the bridge
itself. For example, assuming that eth0's IP address is 192.168.128.5, you
- could run the commands below to fix up the situation:::
+ could run the commands below to fix up the situation::
$ ifconfig eth0 0.0.0.0
$ ifconfig br0 192.168.128.5
@@ -763,7 +763,7 @@ eth0. Help!
applies to all network devices except Open vSwitch "internal" devices.
Q: I created a bridge and added a couple of Ethernet ports to it, using
-commands like these:::
+commands like these::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -785,7 +785,7 @@ very high.
- If you added eth0 and eth1 to get higher bandwidth or higher reliability
between OVS and your physical Ethernet switch, use a bond. The following
- commands create br0 and then add eth0 and eth1 as a bond:::
+ commands create br0 and then add eth0 and eth1 as a bond::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-bond br0 bond0 eth0 eth1
@@ -814,7 +814,7 @@ very high.
prevent loops, turn on spanning tree protocol (STP). The following
commands create br0, enable STP, and add eth0 and eth1 to the bridge.
The order is important because you don't want have to have a loop in your
- network even transiently:::
+ network even transiently::
$ ovs-vsctl add-br br0
$ ovs-vsctl set bridge br0 stp_enable=true
@@ -898,7 +898,7 @@ Q: Open vSwitch does not seem to obey my packet filter rules.
Q: It seems that Open vSwitch does nothing when I removed a port and then
immediately put it back. For example, consider that p1 is a port of
-``type=internal``:::
+``type=internal``::
$ ovs-vsctl del-port br0 p1 -- \
add-port br0 p1 -- \
@@ -917,7 +917,7 @@ immediately put it back. For example, consider that p1 is a port of
corresponding interface, you need to separate operations into multiple
OVSDB transactions and ensure that at least the first one does not have
``--no-wait``. In the following example, the first ovs-vsctl will block
- until Open vSwitch reloads the new configuration and removes the port:::
+ until Open vSwitch reloads the new configuration and removes the port::
$ ovs-vsctl del-port br0 p1
$ ovs-vsctl add-port br0 p1 -- \
@@ -934,7 +934,7 @@ long (minutes or hours) to do it with ovs-vsctl. How can I do it faster?
significant.
The solution is to add the ports in one invocation of ovs-vsctl (or a small
- number of them). For example, using bash:::
+ number of them). For example, using bash::
$ ovs-vsctl add-br br0
$ cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done
@@ -972,7 +972,7 @@ Q: I have a bridge br0. I added a new port vif1.0, and it shows up in
will immediately report when there is an issue creating a port.
Q: I created a tap device tap0, configured an IP address on it, and added it to
-a bridge, like this:::
+a bridge, like this::
$ tunctl -t tap0
$ ifconfig tap0 192.168.0.123
@@ -985,14 +985,14 @@ network, but it doesn't work. Why not?
A: The short answer is that this is a misuse of a "tap" device. Use an
"internal" device implemented by Open vSwitch, which works differently and
is designed for this use. To solve this problem with an internal device,
- instead run:::
+ instead run::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
$ ifconfig int0 192.168.0.123
Even more simply, you can take advantage of the internal port that every
- bridge has under the name of the bridge:::
+ bridge has under the name of the bridge::
$ ovs-vsctl add-br br0
$ ifconfig br0 192.168.0.123
@@ -1076,7 +1076,7 @@ keep changing internal ports MTU?
Sometimes this behavior is not desirable, for example with tunnels. The
MTU of an internal interface can be explicitly set using the following
- command:::
+ command::
$ ovs-vsctl set int br0 mtu_request=1450
@@ -1085,7 +1085,7 @@ keep changing internal ports MTU?
with `ip` or `ifconfig`).
The MTU configuration can be removed to restore the default behavior
- with:::
+ with::
$ ovs-vsctl set int br0 mtu_request=[]
@@ -1116,7 +1116,7 @@ Q: How do I configure egress traffic shaping?
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:::
+ bridge this way::
$ ovs-vsctl -- \
add-br br0 -- \
@@ -1138,7 +1138,7 @@ Q: How do I configure egress traffic shaping?
"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:::
+ 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
@@ -1153,13 +1153,13 @@ Q: How do I configure egress traffic shaping?
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:::
+ 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:::
+ you don't have other QoS or Queue records that you want to keep, is::
$ ovs-vsctl -- --all destroy QoS -- --all destroy Queue
@@ -1306,7 +1306,7 @@ Q: VLANs don't work.
- Use "VLAN splinters", a feature in Open vSwitch 1.4 upto 2.5 that works
around bugs in kernel drivers. To enable VLAN splinters on interface
- eth0, use the command:::
+ eth0, use the command::
$ ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true
@@ -1353,7 +1353,7 @@ traffic.
- Change the OVS configuration for the physical port to a native VLAN mode.
For example, the following sets up a bridge with port eth0 in
- "native-tagged" mode in VLAN 9:::
+ "native-tagged" mode in VLAN 9::
$ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 tag=9
vlan_mode=native-tagged
@@ -1362,7 +1362,7 @@ traffic.
well. Refer to the documentation for the Port table in
ovs-vswitchd.conf.db(5) for more information.
-Q: I added a pair of VMs on different VLANs, like this:::
+Q: I added a pair of VMs on different VLANs, like this::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -1380,7 +1380,7 @@ but the VMs can't access each other, the external network, or the Internet.
machines you are trying to access are not on VLAN 9 (or 10) and that the
Internet is not available on VLAN 9 (or 10).
-Q: I added a pair of VMs on the same VLAN, like this:::
+Q: I added a pair of VMs on the same VLAN, like this::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -1400,7 +1400,7 @@ Q: Can I configure an IP address on a VLAN?
the following configures IP address 192.168.0.7 on VLAN 9. That is, OVS
will forward packets from eth0 to 192.168.0.7 only if they have an 802.1Q
header with VLAN 9. Conversely, traffic forwarded from 192.168.0.7 to eth0
- will be tagged with an 802.1Q header with VLAN 9:::
+ will be tagged with an 802.1Q header with VLAN 9::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -1410,7 +1410,7 @@ Q: Can I configure an IP address on a VLAN?
See also the following question.
-Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this:::
+Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this::
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 eth0
@@ -1475,7 +1475,7 @@ Q: My OpenFlow controller doesn't see the VLANs that I expect.
"strip_vlan" action.
Q: I configured ports on a bridge as access ports with different VLAN tags,
-like this:::
+like this::
$ ovs-vsctl add-br br0
$ ovs-vsctl set-controller br0 tcp:192.168.0.10:6653
@@ -1564,23 +1564,23 @@ Q: What versions of OpenFlow does Open vSwitch support?
In any case, the user may override the default:
- - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:::
+ - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0::
$ ovs-vsctl set bridge br0 \
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
- - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0:::
+ - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0::
$ ovs-vsctl set bridge br0 \
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15
- - To enable only OpenFlow 1.0 on bridge br0:::
+ - To enable only OpenFlow 1.0 on bridge br0::
$ ovs-vsctl set bridge br0 protocols=OpenFlow10
All current versions of ovs-ofctl enable only OpenFlow 1.0 by default. Use
the -O option to enable support for later versions of OpenFlow in
- ovs-ofctl. For example:::
+ ovs-ofctl. For example::
$ ovs-ofctl -O OpenFlow13 dump-flows br0
@@ -1642,7 +1642,7 @@ going through.
Usually, the hidden flows are desirable and helpful, but occasionally they
can cause unexpected behavior. You can view the full OpenFlow flow table,
- including hidden flows, on bridge br0 with the command:::
+ including hidden flows, on bridge br0 with the command::
$ ovs-appctl bridge/dump-flows br0
@@ -1657,7 +1657,7 @@ going through.
localhost via 127.0.0.1, or on a separate network), then you should
configure your controllers in "out-of-band" mode. If you have one
controller on bridge br0, then you can configure out-of-band mode
- on it with:::
+ on it with::
$ ovs-vsctl set controller br0 connection-mode=out-of-band
@@ -1672,7 +1672,7 @@ bridge/dump-flows" still shows some hidden flows.
A: You probably have a remote manager configured (e.g. with "ovs-vsctl
set-manager"). By default, Open vSwitch assumes that managers need in-band
rules set up on every bridge. You can disable these rules on bridge br0
- with:::
+ with::
$ ovs-vsctl set bridge br0 other-config:disable-in-band=true
@@ -1684,7 +1684,7 @@ Q: My OpenFlow controller doesn't see the VLANs that I expect.
A: See answer under "VLANs", above.
Q: I ran ``ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop`` but I got a
-funny message like this:::
+funny message like this::
ofp_util|INFO|normalization changed ofp_match, details:
ofp_util|INFO| pre: nw_dst=192.168.0.1
@@ -1699,11 +1699,11 @@ disappeared, so that the flow ends up matching every packet.
match was dropped.
In this case, the L3 protocol could be IP or ARP. A correct command for
- each possibility is, respectively:::
+ each possibility is, respectively::
$ ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop
- and:::
+ and::
$ ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop
@@ -1723,11 +1723,11 @@ Q: How can I figure out the OpenFlow port number for a given port?
The Interface table in the Open vSwitch database also maps OpenFlow port
names to numbers. To print the OpenFlow port number associated with
- interface eth0, run:::
+ interface eth0, run::
$ ovs-vsctl get Interface eth0 ofport
- You can print the entire mapping with:::
+ You can print the entire mapping with::
$ ovs-vsctl -- --columns=name,ofport list Interface
@@ -1844,7 +1844,7 @@ Q: How do I make a flow drop packets?
explicitly specifies forwarding actions. Thus, a flow with an empty set of
actions does not forward packets anywhere, causing them to be dropped. You
can specify an empty set of actions with ``actions=`` on the ovs-ofctl
- command line. For example:::
+ command line. For example::
$ ovs-ofctl add-flow br0 priority=65535,actions=
@@ -1852,14 +1852,14 @@ Q: How do I make a flow drop packets?
You can write "drop" explicitly if you like. The effect is the same.
Thus, the following command also causes every packet entering switch br0 to
- be dropped:::
+ be dropped::
$ ovs-ofctl add-flow br0 priority=65535,actions=drop
``drop`` is not an action, either in OpenFlow or Open vSwitch. Rather, it
is only a way to say that there are no actions.
-Q: I added a flow to send packets out the ingress port, like this:::
+Q: I added a flow to send packets out the ingress port, like this::
$ ovs-ofctl add-flow br0 in_port=2,actions=2
@@ -1873,18 +1873,18 @@ but OVS drops the packets instead.
Sometimes one really needs to send a packet out its ingress port
("hairpin"). In this case, output to ``OFPP_IN_PORT``, which in ovs-ofctl
- syntax is expressed as just ``in_port``, e.g.:::
+ syntax is expressed as just ``in_port``, e.g.::
$ ovs-ofctl add-flow br0 in_port=2,actions=in_port
This also works in some circumstances where the flow doesn't match on the
input port. For example, if you know that your switch has five ports
numbered 2 through 6, then the following will send every received packet
- out every port, even its ingress port:::
+ out every port, even its ingress port::
$ ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
- or, equivalently:::
+ or, equivalently::
$ ovs-ofctl add-flow br0 actions=all,in_port
@@ -1895,7 +1895,7 @@ but OVS drops the packets instead.
the ability to modify the in_port field. Whatever value is currently in
the in_port field is the port to which outputs will be dropped, as well as
the destination for ``OFPP_IN_PORT``. This means that the following will
- reliably output to port 2 or to ports 2 through 6, respectively:::
+ reliably output to port 2 or to ports 2 through 6, respectively::
$ ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2
$ ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6
@@ -1910,7 +1910,7 @@ but OVS drops the packets instead.
Q: My bridge br0 has host 192.168.0.1 on port 1 and host 192.168.0.2 on port 2.
I set up flows to forward only traffic destined to the other host and drop
-other traffic, like this:::
+other traffic, like this::
priority=5,in_port=1,ip,nw_dst=192.168.0.2,actions=2
priority=5,in_port=2,ip,nw_dst=192.168.0.1,actions=1
@@ -1920,7 +1920,7 @@ But it doesn't work--I don't get any connectivity when I do this. Why?
A: These flows drop the ARP packets that IP hosts use to establish IP
connectivity over Ethernet. To solve the problem, add flows to allow ARP
- to pass between the hosts:::
+ to pass between the hosts::
priority=5,in_port=1,arp,actions=2
priority=5,in_port=2,arp,actions=1
@@ -1928,14 +1928,14 @@ But it doesn't work--I don't get any connectivity when I do this. Why?
This issue can manifest other ways, too. The following flows that match on
Ethernet addresses instead of IP addresses will also drop ARP packets,
because ARP requests are broadcast instead of being directed to a specific
- host:::
+ host::
priority=5,in_port=1,dl_dst=54:00:00:00:00:02,actions=2
priority=5,in_port=2,dl_dst=54:00:00:00:00:01,actions=1
priority=0,actions=drop
The solution already described above will also work in this case. It may
- be better to add flows to allow all multicast and broadcast traffic:::
+ be better to add flows to allow all multicast and broadcast traffic::
priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
@@ -1985,7 +1985,7 @@ Q: How does OVS divide flows among buckets in an OpenFlow "select" group?
source tree. (OpenFlow 1.5 support in Open vSwitch is still experimental.)
Q: I added a flow to accept packets on VLAN 123 and output them on VLAN 456,
-like so:::
+like so::
$ ovs-ofctl add-flow br0 dl_vlan=123,actions=output:1,mod_vlan_vid:456
@@ -1997,7 +1997,7 @@ but the packets are actually being output in VLAN 123. Why?
effect.
To solve this and similar problems, order actions so that changes to
- headers happen before output, e.g.:::
+ headers happen before output, e.g.::
$ ovs-ofctl add-flow br0 dl_vlan=123,actions=mod_vlan_vid:456,output:1
@@ -66,7 +66,7 @@ Installing
DPDK
~~~~
-1. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``:::
+1. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
$ cd /usr/src/
$ wget http://dpdk.org/browse/dpdk/snapshot/dpdk-16.07.zip
@@ -76,13 +76,13 @@ DPDK
2. Configure and install DPDK
- Build and install the DPDK library:::
+ Build and install the DPDK library::
$ export DPDK_TARGET=x86_64-native-linuxapp-gcc
$ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
$ make install T=$DPDK_TARGET DESTDIR=install
- If IVSHMEM support is required, use a different target:::
+ If IVSHMEM support is required, use a different target::
$ export DPDK_TARGET=x86_64-ivshmem-linuxapp-gcc
@@ -106,7 +106,7 @@ has to be configured with DPDK support (``--with-dpdk``).
2. Bootstrap, if required, as described in the `installation guide
<INSTALL.rst>`__.
-3. Configure the package using the ``--with-dpdk`` flag:::
+3. Configure the package using the ``--with-dpdk`` flag::
$ ./configure --with-dpdk=$DPDK_BUILD
@@ -132,19 +132,19 @@ Setup Hugepages
Allocate a number of 2M Huge pages:
- For persistent allocation of huge pages, write to hugepages.conf file
- in `/etc/sysctl.d`:::
+ in `/etc/sysctl.d`::
$ echo 'vm.nr_hugepages=2048' > /etc/sysctl.d/hugepages.conf
-- For run-time allocation of huge pages, use the ``sysctl`` utility:::
+- For run-time allocation of huge pages, use the ``sysctl`` utility::
$ sysctl -w vm.nr_hugepages=N # where N = No. of 2M huge pages
-To verify hugepage configuration:::
+To verify hugepage configuration::
$ grep HugePages_ /proc/meminfo
-Mount the hugepages, if not already mounted by default:::
+Mount the hugepages, if not already mounted by default::
$ mount -t hugetlbfs none /dev/hugepages``
@@ -157,13 +157,13 @@ VFIO is prefered to the UIO driver when using recent versions of DPDK. VFIO
support required support from both the kernel and BIOS. For the former, kernel
version > 3.6 must be used. For the latter, you must enable VT-d in the BIOS
and ensure this is configured via grub. To ensure VT-d is enabled via the BIOS,
-run:::
+run::
$ dmesg | grep -e DMAR -e IOMMU
If VT-d is not enabled in the BIOS, enable it now.
-To ensure VT-d is enabled in the kernel, run:::
+To ensure VT-d is enabled in the kernel, run::
$ cat /proc/cmdline | grep iommu=pt
$ cat /proc/cmdline | grep intel_iommu=on
@@ -171,7 +171,7 @@ To ensure VT-d is enabled in the kernel, run:::
If VT-d is not enabled in the kernel, enable it now.
Once VT-d is correctly configured, load the required modules and bind the NIC
-to the VFIO driver:::
+to the VFIO driver::
$ modprobe vfio-pci
$ /usr/bin/chmod a+x /dev/vfio
@@ -187,7 +187,7 @@ Open vSwitch should be started as described in the `installation guide
special configuration to enable DPDK functionality. DPDK configuration
arguments can be passed to ovs-vswitchd via the ``other_config`` column of the
``Open_vSwitch`` table. At a minimum, the ``dpdk-init`` option must be set to
-``true``. For example:::
+``true``. For example::
$ export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
$ ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
@@ -216,7 +216,7 @@ listed below. Defaults will be provided for all values not explicitly set.
If allocating more than one GB hugepage (as for IVSHMEM), you can configure the
amount of memory used from any given NUMA nodes. For example, to use 1GB from
-NUMA node 0, run:::
+NUMA node 0, run::
$ ovs-vsctl --no-wait set Open_vSwitch . \
other_config:dpdk-socket-mem="1024,0"
@@ -224,7 +224,7 @@ NUMA node 0, run:::
Similarly, if you wish to better scale the workloads across cores, then
multiple pmd threads can be created and pinned to CPU cores by explicity
specifying ``pmd-cpu-mask``. For example, to spawn two pmd threads and pin
-them to cores 1,2, run:::
+them to cores 1,2, run::
$ ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=6
@@ -245,33 +245,33 @@ Creating bridges and ports
~~~~~~~~~~~~~~~~~~~~~~~~~~
You can now use ovs-vsctl to set up bridges and other Open vSwitch features.
-Bridges should be created with a ``datapath_type=netdev``:::
+Bridges should be created with a ``datapath_type=netdev``::
$ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
Now you can add DPDK devices. OVS expects DPDK device names to start with
``dpdk`` and end with a portid. ovs-vswitchd should print the number of dpdk
-devices found in the log file:::
+devices found in the log file::
$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
$ ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk
After the DPDK ports get added to switch, a polling thread continuously polls
DPDK devices and consumes 100% of the core, as can be checked from 'top' and
-'ps' cmds:::
+'ps' cmds::
$ top -H
$ ps -eLo pid,psr,comm | grep pmd
Creating bonds of DPDK interfaces is slightly different to creating bonds of
system interfaces. For DPDK, the interface type must be explicitly set. For
-example:::
+example::
$ ovs-vsctl add-bond br0 dpdkbond dpdk0 dpdk1 \
-- set Interface dpdk0 type=dpdk \
-- set Interface dpdk1 type=dpdk
-To stop ovs-vswitchd & delete bridge, run:::
+To stop ovs-vswitchd & delete bridge, run::
$ ovs-appctl -t ovs-vswitchd exit
$ ovs-appctl -t ovsdb-server exit
@@ -280,23 +280,23 @@ To stop ovs-vswitchd & delete bridge, run:::
PMD thread statistics
~~~~~~~~~~~~~~~~~~~~~
-To show current stats:::
+To show current stats::
$ ovs-appctl dpif-netdev/pmd-stats-show
-To clear previous stats:::
+To clear previous stats::
$ ovs-appctl dpif-netdev/pmd-stats-clear
Port/rxq assigment to PMD threads
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To show port/rxq assignment:::
+To show port/rxq assignment::
$ ovs-appctl dpif-netdev/pmd-rxq-show
To change default rxq assignment to pmd threads, rxqs may be manually pinned to
-desired cores using:::
+desired cores using::
$ ovs-vsctl set Interface <iface> \
other_config:pmd-rxq-affinity=<rxq-affinity-list>
@@ -308,7 +308,7 @@ where:
``<affinity-pair>`` , ``<non-empty-list>``
- ``<affinity-pair>`` ::= ``<queue-id>`` : ``<core-id>``
-For example:::
+For example::
$ ovs-vsctl set interface dpdk0 options:n_rxq=4 \
other_config:pmd-rxq-affinity="0:3,1:7,3:8"
@@ -343,7 +343,7 @@ the `advanced install guide <INSTALL.DPDK-ADVANCED.md>`__.
.. note::
Support for DPDK in the guest requires QEMU >= 2.2.0.
-To being, instantiate the guest:::
+To being, instantiate the guest::
$ export VM_NAME=Centos-vm export GUEST_MEM=3072M
$ export QCOW2_IMAGE=/root/CentOS7_x86_64.qcow2
@@ -360,7 +360,7 @@ To being, instantiate the guest:::
-netdev type=vhost-user,id=mynet2,chardev=char1,vhostforce \
-device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2,mrg_rxbuf=off \
-Download the DPDK sourcs to VM and build DPDK:::
+Download the DPDK sourcs to VM and build DPDK::
$ cd /root/dpdk/
$ wget http://dpdk.org/browse/dpdk/snapshot/dpdk-16.07.zip
@@ -371,14 +371,14 @@ Download the DPDK sourcs to VM and build DPDK:::
$ cd $DPDK_DIR
$ make install T=$DPDK_TARGET DESTDIR=install
-Build the test-pmd application:::
+Build the test-pmd application::
$ cd app/test-pmd
$ export RTE_SDK=$DPDK_DIR
$ export RTE_TARGET=$DPDK_TARGET
$ make
-Setup huge pages and DPDK devices using UIO:::
+Setup huge pages and DPDK devices using UIO::
$ sysctl vm.nr_hugepages=1024
$ mkdir -p /dev/hugepages
@@ -398,7 +398,7 @@ Testing
-------
Below are few testcases and the list of steps to be followed. Before beginning,
-ensure a userspace bridge has been created and two DPDK ports added:::
+ensure a userspace bridge has been created and two DPDK ports added::
$ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
@@ -407,7 +407,7 @@ ensure a userspace bridge has been created and two DPDK ports added:::
PHY-PHY
~~~~~~~
-Add test flows to forward packets betwen DPDK port 0 and port 1:::
+Add test flows to forward packets betwen DPDK port 0 and port 1::
# Clear current flows
$ ovs-ofctl del-flows br0
@@ -421,14 +421,14 @@ Transmit traffic into either port. You should see it returned via the other.
PHY-VM-PHY (vhost loopback)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add two ``dpdkvhostuser`` ports to bridge ``br0``:::
+Add two ``dpdkvhostuser`` ports to bridge ``br0``::
$ ovs-vsctl add-port br0 dpdkvhostuser0 \
-- set Interface dpdkvhostuser0 type=dpdkvhostuser
$ ovs-vsctl add-port br0 dpdkvhostuser1 \
-- set Interface dpdkvhostuser1 type=dpdkvhostuser
-Add test flows to forward packets betwen DPDK devices and VM ports:::
+Add test flows to forward packets betwen DPDK devices and VM ports::
# Clear current flows
$ ovs-ofctl del-flows br0
@@ -456,7 +456,7 @@ Create a VM using the following configuration:
+----------------------+--------+-----------------+
You can do this directly with QEMU via the ``qemu-system-x86_64``
-application:::
+application::
$ export VM_NAME=vhost-vm
$ export GUEST_MEM=3072M
@@ -475,7 +475,7 @@ application:::
-device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2,mrg_rxbuf=off
Alternatively, you can configure the guest using libvirt. Below is an XML
-configuration for a 'demovm' guest that can be instantiated using `virsh`:::
+configuration for a 'demovm' guest that can be instantiated using `virsh`::
<domain type='kvm'>
<name>demovm</name>
@@ -553,7 +553,7 @@ configuration for a 'demovm' guest that can be instantiated using `virsh`:::
Once the guest is configured and booted, configure DPDK packet forwarding
within the guest. To accomplish this, DPDK and testpmd application have to
be first compiled on the VM as described in **Guest Setup**. Once compiled, run
-the ``test-pmd`` application:::
+the ``test-pmd`` application::
$ cd $DPDK_DIR/app/test-pmd;
$ ./testpmd -c 0x3 -n 4 --socket-mem 1024 -- \
@@ -561,14 +561,14 @@ the ``test-pmd`` application:::
$ set fwd mac retry
$ start
-When you finish testing, bind the vNICs back to kernel:::
+When you finish testing, bind the vNICs back to kernel::
$ $DPDK_DIR/tools/dpdk-devbind.py --bind=virtio-pci 0000:00:03.0
$ $DPDK_DIR/tools/dpdk-devbind.py --bind=virtio-pci 0000:00:04.0
.. note::
Appropriate PCI IDs to be passed in above example. The PCI IDs can be
- retrieved like so:::
+ retrieved like so::
$ $DPDK_DIR/tools/dpdk-devbind.py --status
@@ -50,7 +50,7 @@ Git tree with these instructions.
You do not need to be the superuser to build the Debian packages.
-1. Install the "build-essential" and "fakeroot" packages. For example:::
+1. Install the "build-essential" and "fakeroot" packages. For example::
$ apt-get install build-essential fakeroot
@@ -66,17 +66,17 @@ directory. If you've installed all the dependencies properly,
``dpkg-checkbuilddeps`` will exit without printing anything. If you forgot to
install some dependencies, it will tell you which ones.
-4. Build the package:::
+4. Build the package::
$ fakeroot debian/rules binary
This will do a serial build that runs the unit tests. This will take
approximately 8 to 10 minutes. If you prefer, you can run a faster parallel
- build:::
+ build::
$ DEB_BUILD_OPTIONS='parallel=8' fakeroot debian/rules binary
- If you are in a big hurry, you can even skip the unit tests:::
+ If you are in a big hurry, you can even skip the unit tests::
$ DEB_BUILD_OPTIONS='parallel=8 nocheck' fakeroot debian/rules binary
@@ -85,7 +85,7 @@ install some dependencies, it will tell you which ones.
There are a few pitfalls in the Debian packaging building system so that,
occasionally, you may find that in a tree that you have using for a while,
the build command above exits immediately without actually building anything.
- To fix the problem, run:::
+ To fix the problem, run::
$ fakeroot debian/rules clean
@@ -46,7 +46,7 @@ Setup
For multi-host networking with OVN and Docker, Docker has to be started with a
destributed key-value store. For example, if you decide to use consul as your
distributed key-value store and your host IP address is ``$HOST_IP``, start
-your Docker daemon with:::
+your Docker daemon with::
$ docker daemon --cluster-store=consul://127.0.0.1:8500 \
--cluster-advertise=$HOST_IP:0
@@ -87,7 +87,7 @@ The "overlay" mode
Start ovn-northd daemon. This daemon translates networking intent from Docker
stored in the OVN\_Northbound database to logical flows in ``OVN_Southbound``
- database. For example:::
+ database. For example::
$ /usr/share/openvswitch/scripts/ovn-ctl start_northd
@@ -95,7 +95,7 @@ The "overlay" mode
On each host, where you plan to spawn your containers, you will need to run
the below command once. You may need to run it again if your OVS database
- gets cleared. It is harmless to run it again in any case:::
+ gets cleared. It is harmless to run it again in any case::
$ ovs-vsctl set Open_vSwitch . \
external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
@@ -117,7 +117,7 @@ The "overlay" mode
Open vSwitch kernel module from upstream Linux, you will need a minumum
kernel version of 3.18 for ``geneve``. There is no ``stt`` support in
upstream Linux. You can verify whether you have the support in your kernel
- as follows:::
+ as follows::
$ lsmod | grep $ENCAP_TYPE
@@ -126,7 +126,7 @@ The "overlay" mode
distribution packaging for Open vSwitch (e.g. .deb or .rpm packages), or if
you use the ovs-ctl utility included with Open vSwitch, it automatically
configures a system-id. If you start Open vSwitch manually, you should set
- one up yourself. For example:::
+ one up yourself. For example::
$ id_file=/etc/openvswitch/system-id.conf
$ test -e $id_file || uuidgen > $id_file
@@ -134,7 +134,7 @@ The "overlay" mode
3. Start the ``ovn-controller``.
- You need to run the below command on every boot:::
+ You need to run the below command on every boot::
$ /usr/share/openvswitch/scripts/ovn-ctl start_controller
@@ -146,13 +146,13 @@ The "overlay" mode
The Open vSwitch driver uses the Python's flask module to listen to Docker's
networking api calls. So, if your host does not have Python's flask module,
- install it:::
+ install it::
$ sudo pip install Flask
Start the Open vSwitch driver on every host where you plan to create your
containers. Refer to the note on ``$OVS_PYTHON_LIBS_PATH`` that is used below
- at the end of this document:::
+ at the end of this document::
$ PYTHONPATH=$OVS_PYTHON_LIBS_PATH ovn-docker-overlay-driver --detach
@@ -175,7 +175,7 @@ commands. Here are some examples.
Create a logical switch
~~~~~~~~~~~~~~~~~~~~~~~
-To create a logical switch with name 'foo', on subnet '192.168.1.0/24', run:::
+To create a logical switch with name 'foo', on subnet '192.168.1.0/24', run::
$ NID=`docker network create -d openvswitch --subnet=192.168.1.0/24 foo`
@@ -187,7 +187,7 @@ List all logical switches
$ docker network ls
You can also look at this logical switch in OVN's northbound database by
-running the following command:::
+running the following command::
$ ovn-nbctl --db=tcp:$CENTRAL_IP:6640 ls-list
@@ -204,7 +204,7 @@ Create a logical port
Docker creates your logical port and attaches it to the logical network in a
single step. For example, to attach a logical port to network ``foo`` inside
-container busybox, run:::
+container busybox, run::
$ docker run -itd --net=foo --name=busybox busybox
@@ -212,7 +212,7 @@ List all logical ports
~~~~~~~~~~~~~~~~~~~~~~
Docker does not currently have a CLI command to list all logical ports but you
-can look at them in the OVN database by running:::
+can look at them in the OVN database by running::
$ ovn-nbctl --db=tcp:$CENTRAL_IP:6640 lsp-list $NID
@@ -250,22 +250,22 @@ The "underlay" mode
that belongs to management logical networks. The tenant needs to fetch the
port-id associated with the interface via which he plans to send the container
traffic inside the spawned VM. This can be obtained by running the below
- command to fetch the 'id' associated with the VM:::
+ command to fetch the 'id' associated with the VM::
$ nova list
- and then by running:::
+ and then by running::
$ neutron port-list --device_id=$id
Inside the VM, download the OpenStack RC file that contains the tenant
information (henceforth referred to as ``openrc.sh``). Edit the file and add the
previously obtained port-id information to the file by appending the following
- line:::
+ line::
$ export OS_VIF_ID=$port_id
- After this edit, the file will look something like:::
+ After this edit, the file will look something like::
#!/bin/bash
export OS_AUTH_URL=http://10.33.75.122:5000/v2.0
@@ -298,17 +298,17 @@ The "underlay" mode
networking api calls. The driver also uses OpenStack's
``python-neutronclient`` libraries. If your host does not have Python's
``flask`` module or ``python-neutronclient`` you must install them. For
- example:::
+ example::
$ pip install python-neutronclient
$ pip install Flask
- Once installed, source the ``openrc`` file:::
+ Once installed, source the ``openrc`` file::
$ . ./openrc.sh
Start the network driver and provide your OpenStack tenant password when
- prompted:::
+ prompted::
$ PYTHONPATH=$OVS_PYTHON_LIBS_PATH ovn-docker-underlay-driver \
--bridge breth0 --detach
@@ -37,7 +37,7 @@ Setup
-----
KVM uses tunctl to handle various bridging modes, which you can install with
-the Debian/Ubuntu package ``uml-utilities``:::
+the Debian/Ubuntu package ``uml-utilities``::
$ apt-get install uml-utilities
@@ -45,7 +45,7 @@ Next, you will need to modify or create custom versions of the ``qemu-ifup``
and ``qemu-ifdown`` scripts. In this guide, we'll create custom versions that
make use of example Open vSwitch bridges that we'll describe in this guide.
-Create the following two files and store them in known locations. For example:::
+Create the following two files and store them in known locations. For example::
echo << EOF > /etc/ovs-ifup
#!/bin/sh
@@ -66,18 +66,18 @@ Create the following two files and store them in known locations. For example:::
The basic usage of Open vSwitch is described at the end of the `installation
guide <INSTALL.rst>`__. If you haven't already, create a bridge named ``br0``
-with the following command:::
+with the following command::
$ ovs-vsctl add-br br0
Then, add a port to the bridge for the NIC that you want your guests to
-communicate over (e.g. ``eth0``):::
+communicate over (e.g. ``eth0``)::
$ ovs-vsctl add-port br0 eth0
Refer to ovs-vsctl(8) for more details.
-Next, we'll start a guest that will use our ifup and ifdown scripts:::
+Next, we'll start a guest that will use our ifup and ifdown scripts::
$ kvm -m 512 -net nic,macaddr=00:11:22:EE:EE:EE -net \
tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -drive \
@@ -88,7 +88,7 @@ script will add a port on the br0 bridge so that the guest will be able to
communicate over that bridge.
To get some more information and for debugging you can use Open vSwitch
-utilities such as ovs-dpctl and ovs-ofctl, For example:::
+utilities such as ovs-dpctl and ovs-ofctl, For example::
$ ovs-dpctl show
$ ovs-ofctl show br0
@@ -52,7 +52,7 @@ The following explains the steps in some detail.
automake and autoconf(version 2.68).
Also make sure that ``/mingw`` mount point exists. If its not, please
- add/create the following entry in ``/etc/fstab``:::
+ add/create the following entry in ``/etc/fstab``::
'C:/MinGW /mingw'.
@@ -123,7 +123,7 @@ Bootstrapping
This step is not needed if you have downloaded a released tarball. If
you pulled the sources directly from an Open vSwitch Git tree or got a
Git tree snapshot, then run boot.sh in the top source directory to build
-the "configure" script:::
+the "configure" script::
> ./boot.sh
@@ -134,7 +134,7 @@ Configuring
Configure the package by running the configure script. You should provide some
configure options to choose the right compiler, linker, libraries, Open vSwitch
-component installation directories, etc. For example:::
+component installation directories, etc. For example::
> ./configure CC=./build-aux/cccl LD="$(which link)" \
LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
@@ -146,7 +146,7 @@ component installation directories, etc. For example:::
By default, the above enables compiler optimization for fast code. For
default compiler optimization, pass the ``--with-debug`` configure option.
-To configure with SSL support, add the requisite additional options:::
+To configure with SSL support, add the requisite additional options::
> ./configure CC=./build-aux/cccl LD="`which link`" \
LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
@@ -155,7 +155,7 @@ To configure with SSL support, add the requisite additional options:::
--with-pthread="C:/pthread" \
--enable-ssl --with-openssl="C:/OpenSSL-Win32"
-Finally, to the kernel module also:::
+Finally, to the kernel module also::
> ./configure CC=./build-aux/cccl LD="`which link`" \
LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
@@ -182,7 +182,7 @@ Building
Once correctly configured, building Open vSwitch on Windows is similar to
building on Linux, FreeBSD, or NetBSD.
-#. Run make for the ported executables in the top source directory, e.g.:::
+#. Run make for the ported executables in the top source directory, e.g.::
> make
@@ -198,15 +198,15 @@ building on Linux, FreeBSD, or NetBSD.
> mingw-get upgrade msys-core-bin=1.0.17-1
-#. To run all the unit tests in Open vSwitch, one at a time:::
+#. To run all the unit tests in Open vSwitch, one at a time::
> make check
- To run all the unit tests in Open vSwitch, up to 8 in parallel:::
+ To run all the unit tests in Open vSwitch, up to 8 in parallel::
> make check TESTSUITEFLAGS="-j8"
-#. To install all the compiled executables on the local machine, run:::
+#. To install all the compiled executables on the local machine, run::
> make install
@@ -236,7 +236,7 @@ the target Hyper-V machine.
Now run ``./uninstall.cmd`` to remove the old extension. Once complete, run
``./install.cmd`` to insert the new one. For this to work you will have to
turn on ``TESTSIGNING`` boot option or 'Disable Driver Signature
-Enforcement' during boot. The following commands can be used:::
+Enforcement' during boot. The following commands can be used::
> bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
> bcdedit /set TESTSIGNING ON
@@ -251,7 +251,7 @@ existing switch, make sure to enable the "Allow Management OS" option for VXLAN
to work (covered later).
The command to create a new switch named 'OVS-Extended-Switch' using a physical
-NIC named 'Ethernet 1' is:::
+NIC named 'Ethernet 1' is::
PS > New-VMSwitch "OVS-Extended-Switch" -AllowManagementOS $true \
-NetAdapterName "Ethernet 1"
@@ -262,7 +262,7 @@ NIC named 'Ethernet 1' is:::
In the properties of any switch, you should should now see "Open vSwitch
Extension" under 'Extensions'. Click the check box to enable the extension.
-An alternative way to do the same is to run the following command:::
+An alternative way to do the same is to run the following command::
PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch
@@ -302,7 +302,7 @@ harmless::
> ovs-vsctl --no-wait init
.. tip::
- If you would later like to terminate the started ovsdb-server, run:::
+ If you would later like to terminate the started ovsdb-server, run::
> ovs-appctl -t ovsdb-server exit
@@ -312,7 +312,7 @@ domain socket::
> ovs-vswitchd -vfile:info --log-file --pidfile --detach
.. tip::
- If you would like to terminate the started ovs-vswitchd, run:::
+ If you would like to terminate the started ovs-vswitchd, run::
> ovs-appctl exit
@@ -329,7 +329,7 @@ Add bridges
~~~~~~~~~~~
Let's start by creating an integration bridge, ``br-int`` and a PIF bridge,
-``br-pif``:::
+``br-pif``::
> ovs-vsctl add-br br-int
> ovs-vsctl add-br br-pif
@@ -340,7 +340,7 @@ Let's start by creating an integration bridge, ``br-int`` and a PIF bridge,
issue despite that, hit Ctrl-C to terminate ovs-vsctl and check the output to
see if your command succeeded.
-Validate that ports are added by dumping from both ovs-dpctl and ovs-vsctl:::
+Validate that ports are added by dumping from both ovs-dpctl and ovs-vsctl::
> ovs-dpctl show
system@ovs-system:
@@ -387,7 +387,7 @@ switch using the instructions above. In OVS for Hyper-V, we use a the name of
that specific adapter as a special name to refer to that adapter. By default it
is created under the following rule ``vEthernet (<name of the switch>)``.
-As a whole example, if we issue the following in a powershell console:::
+As a whole example, if we issue the following in a powershell console::
PS C:\package\binaries> Get-NetAdapter | select Name,MacAddress,InterfaceDescription
Name MacAddress InterfaceDescription
@@ -403,12 +403,12 @@ As a whole example, if we issue the following in a powershell console:::
We can see that we have a switch(external) created upon adapter name
'Ethernet0' with an internal port under name ``vEthernet (external)``. Thus
-resulting into the following ovs-vsctl commands:::
+resulting into the following ovs-vsctl commands::
> ovs-vsctl add-port br-pif Ethernet0
> ovs-vsctl add-port br-pif "vEthernet (external)"
-Dumping the ports should show the additional ports that were just added:::
+Dumping the ports should show the additional ports that were just added::
> ovs-dpctl show
system@ovs-system:
@@ -459,11 +459,11 @@ assumed to be the Hyper-V switch with OVS extension enabled.::
PS> Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \
-SwitchName OVS-Extended-Switch
-Next, add the VIFs to ``br-int``:::
+Next, add the VIFs to ``br-int``::
> ovs-vsctl add-port br-int ovs-port-a
-Dumping the ports should show the additional ports that were just added:::
+Dumping the ports should show the additional ports that were just added::
> ovs-dpctl show
system@ovs-system:
@@ -498,19 +498,19 @@ Add patch ports and configure VLAN tagging
The Windows Open vSwitch implementation support VLAN tagging in the switch.
Switch VLAN tagging along with patch ports between ``br-int`` and ``br-pif`` is
used to configure VLAN tagging functionality between two VMs on different
-Hyper-Vs. To start, add a patch port from ``br-int`` to ``br-pif``:::
+Hyper-Vs. To start, add a patch port from ``br-int`` to ``br-pif``::
> ovs-vsctl add-port br-int patch-to-pif
> ovs-vsctl set interface patch-to-pif type=patch \
options:peer=patch-to-int
-Add a patch port from ``br-pif`` to ``br-int``:::
+Add a patch port from ``br-pif`` to ``br-int``::
> ovs-vsctl add-port br-pif patch-to-int
> ovs-vsctl set interface patch-to-int type=patch \
options:peer=patch-to-pif
-Re-Add the VIF ports with the VLAN tag:::
+Re-Add the VIF ports with the VLAN tag::
> ovs-vsctl add-port br-int ovs-port-a tag=900
> ovs-vsctl add-port br-int ovs-port-b tag=900
@@ -520,7 +520,7 @@ Add tunnels
The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add
tunnels. For example, first add the tunnel port between 172.168.201.101 <->
-172.168.201.102:::
+172.168.201.102::
> ovs-vsctl add-port br-int tun-1
> ovs-vsctl set Interface tun-1 type=<port-type>
@@ -529,7 +529,7 @@ tunnels. For example, first add the tunnel port between 172.168.201.101 <->
> ovs-vsctl set Interface tun-1 options:in_key=flow
> ovs-vsctl set Interface tun-1 options:out_key=flow
-...and the tunnel port between 172.168.201.101 <-> 172.168.201.105:::
+...and the tunnel port between 172.168.201.101 <-> 172.168.201.105::
> ovs-vsctl add-port br-int tun-2
> ovs-vsctl set Interface tun-2 type=<port-type>
@@ -554,12 +554,12 @@ daemons via ``make install``.
.. note::
The commands shown here can be run from MSYS bash or Windows command prompt.
-To start, create the database:::
+To start, create the database::
> ovsdb-tool create C:/openvswitch/etc/openvswitch/conf.db \
"C:/openvswitch/usr/share/openvswitch/vswitch.ovsschema"
-Create the ovsdb-server service and start it:::
+Create the ovsdb-server service and start it::
> sc create ovsdb-server \
binpath="C:/openvswitch/usr/sbin/ovsdb-server.exe \
@@ -571,30 +571,30 @@ Create the ovsdb-server service and start it:::
.. tip::
One of the common issues with creating a Windows service is with mungled
paths. You can make sure that the correct path has been registered with the
- Windows services manager by running:::
+ Windows services manager by running::
> sc qc ovsdb-server
-Check that the service is healthy by running:::
+Check that the service is healthy by running::
> sc query ovsdb-server
-Initialize the database:::
+Initialize the database::
> ovs-vsctl --no-wait init
-Create the ovs-vswitchd service and start it:::
+Create the ovs-vswitchd service and start it::
> sc create ovs-vswitchd \
binpath="C:/openvswitch/usr/sbin/ovs-vswitchd.exe \
--pidfile -vfile:info --log-file --service --service-monitor"
> sc start ovs-vswitchd
-Check that the service is healthy by running:::
+Check that the service is healthy by running::
> sc query ovs-vswitchd
-To stop and delete the services, run:::
+To stop and delete the services, run::
> sc stop ovs-vswitchd
> sc stop ovsdb-server
@@ -41,7 +41,7 @@ Git tree. The recommended build environment to build RPMs for Citrix XenServer
is the DDK VM available from Citrix.
1. If you are building from an Open vSwitch Git tree, then you will need to
- first create a distribution tarball by running:::
+ first create a distribution tarball by running::
$ ./boot.sh
$ ./configure
@@ -58,7 +58,7 @@ is the DDK VM available from Citrix.
3. In the DDK VM, unpack the distribution tarball into a temporary directory
and "cd" into the root of the distribution tarball.
-4. To build Open vSwitch userspace, run:::
+4. To build Open vSwitch userspace, run::
$ rpmbuild -bb xenserver/openvswitch-xen.spec
@@ -69,7 +69,7 @@ is the DDK VM available from Citrix.
- ``openvswitch-debuginfo``
The above command automatically runs the Open vSwitch unit tests. To
- disable the unit tests, run:::
+ disable the unit tests, run::
$ rpmbuild -bb --without check xenserver/openvswitch-xen.spec
@@ -79,7 +79,7 @@ Build Parameters
``openvswitch-xen.spec`` needs to know a number of pieces of information about
the XenServer kernel. Usually, it can figure these out for itself, but if it
does not do it correctly then you can specify them yourself as parameters to
-the build. Thus, the final ``rpmbuild`` step above can be elaborated as:::
+the build. Thus, the final ``rpmbuild`` step above can be elaborated as::
$ VERSION=<Open vSwitch version>
$ KERNEL_NAME=<Xen Kernel name>
@@ -103,7 +103,7 @@ where:
``kernel-NAME-xen``, without the ``kernel-`` prefix.
``<Xen Kernel version>``
- is the output of:::
+ is the output of::
$ rpm -q --queryformat "%{Version}-%{Release}" <kernel-devel-package>,
@@ -118,7 +118,7 @@ where:
For XenServer 6.5 or above, the kernel version naming no longer contains
KERNEL_FLAVOR. In fact, only providing the ``uname -r`` output is enough. So,
-the final ``rpmbuild`` step changes to:::
+the final ``rpmbuild`` step changes to::
$ KERNEL_UNAME=<`uname -r` output>
$ rpmbuild \
@@ -130,7 +130,7 @@ Installing Open vSwitch for XenServer
To install Open vSwitch on a XenServer host, or to upgrade to a newer version,
copy the ``openvswitch`` and ``openvswitch-modules-xen`` RPMs to that host with
-``scp``, then install them with ``rpm -U``, e.g.:::
+``scp``, then install them with ``rpm -U``, e.g.::
$ scp openvswitch-$VERSION-1.i386.rpm \
openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm \
@@ -141,7 +141,7 @@ copy the ``openvswitch`` and ``openvswitch-modules-xen`` RPMs to that host with
$ rpm -U openvswitch-$VERSION-1.i386.rpm \
openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm
-To uninstall Open vSwitch from a XenServer host, remove the packages:::
+To uninstall Open vSwitch from a XenServer host, remove the packages::
$ ssh root@<host>
# Enter <host>'s root password again.
@@ -63,7 +63,7 @@ Using the Userspace Datapath with ovs-vswitchd
----------------------------------------------
To use ovs-vswitchd in userspace mode, create a bridge with
-``datapath_type=netdev`` in the configuration database. For example:::
+``datapath_type=netdev`` in the configuration database. For example::
$ ovs-vsctl add-br br0
$ ovs-vsctl set bridge br0 datapath_type=netdev
@@ -76,7 +76,7 @@ the same as the bridge, as well as for each configured internal interface.
Currently, on FreeBSD, the functionality required for in-band control support
is not implemented. To avoid related errors, you can disable the in-band
-support with the following command:::
+support with the following command::
$ ovs-vsctl set bridge br0 other_config:disable-in-band=true
@@ -87,7 +87,7 @@ On Linux, when a physical interface is in use by the userspace datapath,
packets received on the interface still also pass into the kernel TCP/IP stack.
This can cause surprising and incorrect behavior. You can use "iptables" to
avoid this behavior, by using it to drop received packets. For example, to
-drop packets received on eth0:::
+drop packets received on eth0::
$ iptables -A INPUT -i eth0 -j DROP
$ iptables -A FORWARD -i eth0 -j DROP
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it> --- FAQ.rst | 106 +++++++++++++++++++++++++------------------------- INSTALL.DPDK.rst | 74 +++++++++++++++++------------------ INSTALL.Debian.rst | 10 ++--- INSTALL.Docker.rst | 38 +++++++++--------- INSTALL.KVM.rst | 12 +++--- INSTALL.Windows.rst | 68 ++++++++++++++++---------------- INSTALL.XenServer.rst | 16 ++++---- INSTALL.userspace.rst | 6 +-- 8 files changed, 165 insertions(+), 165 deletions(-)