| 1 | diff --git a/debian/openvswitch-switch.README.Debian b/debian/openvswitch-switch.README.Debian
|
| 2 | index cdfc57c26..04432eeb3 100644
|
| 3 | |
| 4 | |
| 5 | @@ -1,7 +1,7 @@
|
| 6 | -README.Debian for openvswitch-switch
|
| 7 | +README.Alpine for openvswitch-switch
|
| 8 | ---------------------------------
|
| 9 |
|
| 10 | -Debian network scripts (ifupdown) integration
|
| 11 | +network scripts integration
|
| 12 | ------------------------------------------------
|
| 13 | This package lets a user to optionally configure Open vSwitch bridges
|
| 14 | and ports from /etc/network/interfaces. Please refer to the interfaces(5)
|
| 15 | @@ -163,115 +163,28 @@ iface gre1 inet manual
|
| 16 |
|
| 17 | ex 8: Create and destroy bridges.
|
| 18 |
|
| 19 | -ifup --allow=ovs $list_of_bridges
|
| 20 | -ifdown --allow=ovs $list_of_bridges
|
| 21 | +ifup $list_of_bridges
|
| 22 | +ifdown $list_of_bridges
|
| 23 |
|
| 24 | -Open vSwitch integration with systemd-networkd
|
| 25 | ------------------------------------------------
|
| 26 | +Notes on LXC integration:
|
| 27 | +-------------------------
|
| 28 |
|
| 29 | -There is no native integration of OVS with systemd-networkd. That is,
|
| 30 | -you cannot create OVS bridges, ports and bonds by simply writing configuration
|
| 31 | -files in /etc/systemd/network. But, you can create OVS devices using ovs-vsctl
|
| 32 | -and then write configuration files to provide them IP addresses.
|
| 33 | +To prevent containers failing to start after hard reboots create:
|
| 34 | +-----------------------------------------------------------------
|
| 35 |
|
| 36 | -As soon as a OVS device is visible, systemd-networkd will provide that device
|
| 37 | -an IP address. Since OVS database is persistent across reboots, the OVS
|
| 38 | -devices will get re-created after a reboot as soon as OVS startup script is
|
| 39 | -invoked. And systemd-networkd will immediately assign the configuration defined
|
| 40 | -in /etc/systemd/network.
|
| 41 | +/etc/lxc/ovsup:
|
| 42 |
|
| 43 | -Example:
|
| 44 | +#!/bin/sh
|
| 45 | +ovs-vsctl --if-exists del-port $5
|
| 46 | +-----------------------------------------------------------------
|
| 47 |
|
| 48 | -If you have a physical ethernet device "ens160" which has been configured with
|
| 49 | -DHCP, your systemd-networkd's .network config file will look something like
|
| 50 | -this:
|
| 51 | +/etc/lxc/ovsdown:
|
| 52 |
|
| 53 | -```
|
| 54 | -[Match]
|
| 55 | -Name=ens160
|
| 56 | +#!/bin/sh
|
| 57 | +ovs-vsctl --if-exists del-port veth.$LXC_NAME
|
| 58 | +-----------------------------------------------------------------
|
| 59 |
|
| 60 | -[Network]
|
| 61 | -DHCP=ipv4
|
| 62 | +& add to the container config file:
|
| 63 |
|
| 64 | -[DHCP]
|
| 65 | -ClientIdentifier=mac
|
| 66 | -```
|
| 67 | -
|
| 68 | -Please note how the DHCP ClientIdentifier above has been configured with the
|
| 69 | -mac address.
|
| 70 | -
|
| 71 | -To create a OVS bridge "br-ens160" and add "ens160" as a port of that
|
| 72 | -bridge, you can change the .network configuration for "ens160" to look like:
|
| 73 | -
|
| 74 | -```
|
| 75 | -[Match]
|
| 76 | -Name=ens160
|
| 77 | -```
|
| 78 | -
|
| 79 | -Now create a new .network configuration file for "br-ens160". Something like:
|
| 80 | -
|
| 81 | -```
|
| 82 | -[Match]
|
| 83 | -Name=br-ens160
|
| 84 | -
|
| 85 | -[Network]
|
| 86 | -DHCP=ipv4
|
| 87 | -
|
| 88 | -[DHCP]
|
| 89 | -ClientIdentifier=mac
|
| 90 | -```
|
| 91 | -
|
| 92 | -Now, use ovs-vsctl to create br-ens160 and add ens160 as a port of it. You
|
| 93 | -will also have to flush the IP address of ens160 and restart systemd-networkd
|
| 94 | -in the same line. It is important to let br-ens160 have the same mac address as
|
| 95 | -ens160 to get the same IP address to br-ens160 from the DHCP server. In the
|
| 96 | -below command, "$mac_of_ens160" holds the mac address of ens160. For e.g:
|
| 97 | -
|
| 98 | -```
|
| 99 | -mac_of_ens160='"00:0c:29:77:27:7a"'
|
| 100 | -ovs-vsctl --may-exist add-br br-ens160 -- \
|
| 101 | - --may-exist add-port br-ens160 ens160 -- \
|
| 102 | - set interface br-ens160 mac="$mac_of_ens160"; ip addr flush dev ens160; \
|
| 103 | - systemctl restart systemd-networkd
|
| 104 | -```
|
| 105 | -
|
| 106 | -br-ens160 should now have the same DHCP IP. It should also have the correct
|
| 107 | -DNS resolution servers configured.
|
| 108 | -
|
| 109 | -Notes on dependencies:
|
| 110 | ----------------------
|
| 111 | -
|
| 112 | -openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
|
| 113 | -This creates some startup dependency issues.
|
| 114 | -
|
| 115 | -* Since openvswitch utilities are placed in /usr and /usr can be mounted
|
| 116 | -through NFS, openvswitch has to start after it. But if a user uses openvswitch
|
| 117 | -for all his networking needs and hence to mount NFS, there will be a deadlock.
|
| 118 | -So, if /usr is mounted through NFS and openvswitch is used for all networking,
|
| 119 | -the administrator should figure out a way to mount NFS before starting OVS.
|
| 120 | -One way to do this is in initramfs.
|
| 121 | -
|
| 122 | -* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
|
| 123 | -script that depends on openvswitch but starts before it, needs to be changed
|
| 124 | -to depend on openvswitch-switch too.
|
| 125 | -
|
| 126 | -* Ideally, an admin should not add openvswitch bridges in the 'auto'
|
| 127 | -section of the 'interfaces' file (i.e., if "br0" is a OVS bridge, you should
|
| 128 | -not have a line "auto br0"). This is because, when ifupdown starts
|
| 129 | -working on bridges listed in 'auto', openvswitch has not yet started.
|
| 130 | -
|
| 131 | -But, if the admin wants to go down this route and adds openvswitch bridges
|
| 132 | -in the 'auto' section, openvswitch-switch will forcefully be started when
|
| 133 | -ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
|
| 134 | -has already been mounted and that a remote $syslog (if used) is ready to
|
| 135 | -receive openvswitch logs.
|
| 136 | -
|
| 137 | -* With systemd, adding openvswitch bridges in the 'auto' section of the
|
| 138 | -'interfaces' file can cause race conditions (i.e., if "br0" is a OVS bridge,
|
| 139 | -you should not have a line "auto br0"). Debian systems have added a
|
| 140 | -systemd [email protected] file. This file will call ifdown and ifup on interfaces
|
| 141 | -in "auto" section automatically when the interfaces disappear and appear
|
| 142 | -respectively. This will cause race conditions if you delete and add the same
|
| 143 | -bridges using tools like "ovs-vsctl" or "ovs-dpctl". This is also a problem
|
| 144 | -when you upgrade your openvswitch kernel module using commands like
|
| 145 | -'force-reload-kmod'.
|
| 146 | +lxc.hook.pre-start = /etc/lxc/ovsup
|
| 147 | +lxc.hook.post-stop = /etc/lxc/ovsdown
|