X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;ds=sidebyside;f=pve-network.adoc;h=b2dae9780247339bbdfdda13deb7fd2bd2d861a5;hb=5dfeeece548c9304fc6cbd51b17679bafeff2bee;hp=d221c321d6d74a81a6b07465457295807697b932;hpb=052130090ec7b76091a27c5f00927067dbd51e52;p=pve-docs.git diff --git a/pve-network.adoc b/pve-network.adoc index d221c32..b2dae97 100644 --- a/pve-network.adoc +++ b/pve-network.adoc @@ -5,14 +5,14 @@ ifdef::wiki[] :pve-toplevel: endif::wiki[] -Network configuration can be done either via the GUI, or by manually +Network configuration can be done either via the GUI, or by manually editing the file `/etc/network/interfaces`, which contains the whole network configuration. The `interfaces(5)` manual page contains the complete format description. All {pve} tools try hard to keep direct user modifications, but using the GUI is still preferable, because it protects you from errors. -Once the network is configured, you can use the Debian traditional tools `ifup` +Once the network is configured, you can use the Debian traditional tools `ifup` and `ifdown` commands to bring interfaces up and down. NOTE: {pve} does not write changes directly to @@ -68,16 +68,16 @@ For more information see https://www.freedesktop.org/wiki/Software/systemd/Predi Choosing a network configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Depending on your current network organization and your resources you can +Depending on your current network organization and your resources you can choose either a bridged, routed, or masquerading networking setup. {pve} server in a private LAN, using an external gateway to reach the internet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The *Bridged* model makes the most sense in this case, and this is also +The *Bridged* model makes the most sense in this case, and this is also the default mode on new {pve} installations. -Each of your Guest system will have a virtual interface attached to the -{pve} bridge. This is similar in effect to having the Guest network card +Each of your Guest system will have a virtual interface attached to the +{pve} bridge. This is similar in effect to having the Guest network card directly connected to a new switch on your LAN, the {pve} host playing the role of the switch. @@ -91,7 +91,7 @@ what your provider allows. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In that case the only way to get outgoing network accesses for your guest -systems is to use *Masquerading*. For incoming network access to your guests, +systems is to use *Masquerading*. For incoming network access to your guests, you will need to configure *Port Forwarding*. For further flexibility, you can configure @@ -102,8 +102,9 @@ virtual networks. Default Configuration using a Bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[thumbnail="default-network-setup-bridge.svg"] Bridges are like physical network switches implemented in software. -All VMs can share a single bridge, or you can create multiple bridges to +All VMs can share a single bridge, or you can create multiple bridges to separate network domains. Each host can have up to 4094 bridges. The installation program creates a single bridge named `vmbr0`, which @@ -138,7 +139,7 @@ Most hosting providers do not support the above setup. For security reasons, they disable networking as soon as they detect multiple MAC addresses on a single interface. -TIP: Some providers allows you to register additional MACs on there +TIP: Some providers allows you to register additional MACs on their management interface. This avoids the problem, but is clumsy to configure because you need to register a MAC for each of your VMs. @@ -146,6 +147,7 @@ You can avoid the problem by ``routing'' all traffic via a single interface. This makes sure that all network packets use the same MAC address. +[thumbnail="default-network-setup-routed.svg"] A common scenario is that you have a public IP (assume `198.51.100.5` for this example), and an additional IP block for your VMs (`203.0.113.16/29`). We recommend the following setup for such @@ -273,7 +275,7 @@ network-peers use different MAC addresses for their network packet traffic. If your switch support the LACP (IEEE 802.3ad) protocol then we recommend using -the corresponding bonding mode (802.3ad). Otherwise you should generally use the +the corresponding bonding mode (802.3ad). Otherwise you should generally use the active-backup mode. + // http://lists.linux-ha.org/pipermail/linux-ha/2013-January/046295.html If you intend to run your cluster network on the bonding interfaces, then you @@ -314,6 +316,7 @@ iface vmbr0 inet static ---- +[thumbnail="default-network-setup-bond.svg"] Another possibility it to use the bond directly as bridge port. This can be used to make the guest network fault-tolerant. @@ -344,6 +347,148 @@ iface vmbr0 inet static ---- + +VLAN 802.1Q +~~~~~~~~~~~ + +A virtual LAN (VLAN) is a broadcast domain that is partitioned and +isolated in the network at layer two. So it is possible to have +multiple networks (4096) in a physical network, each independent of +the other ones. + +Each VLAN network is identified by a number often called 'tag'. +Network packages are then 'tagged' to identify which virtual network +they belong to. + + +VLAN for Guest Networks +^^^^^^^^^^^^^^^^^^^^^^^ + +{pve} supports this setup out of the box. You can specify the VLAN tag +when you create a VM. The VLAN tag is part of the guest network +configuration. The networking layer supports different modes to +implement VLANs, depending on the bridge configuration: + +* *VLAN awareness on the Linux bridge:* +In this case, each guest's virtual network card is assigned to a VLAN tag, +which is transparently supported by the Linux bridge. +Trunk mode is also possible, but that makes configuration +in the guest necessary. + +* *"traditional" VLAN on the Linux bridge:* +In contrast to the VLAN awareness method, this method is not transparent +and creates a VLAN device with associated bridge for each VLAN. +That is, creating a guest on VLAN 5 for example, would create two +interfaces eno1.5 and vmbr0v5, which would remain until a reboot occurs. + +* *Open vSwitch VLAN:* +This mode uses the OVS VLAN feature. + +* *Guest configured VLAN:* +VLANs are assigned inside the guest. In this case, the setup is +completely done inside the guest and can not be influenced from the +outside. The benefit is that you can use more than one VLAN on a +single virtual NIC. + + +VLAN on the Host +^^^^^^^^^^^^^^^^ + +To allow host communication with an isolated network. It is possible +to apply VLAN tags to any network device (NIC, Bond, Bridge). In +general, you should configure the VLAN on the interface with the least +abstraction layers between itself and the physical NIC. + +For example, in a default configuration where you want to place +the host management address on a separate VLAN. + + +.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge +---- +auto lo +iface lo inet loopback + +iface eno1 inet manual + +iface eno1.5 inet manual + +auto vmbr0v5 +iface vmbr0v5 inet static + address 10.10.10.2 + netmask 255.255.255.0 + gateway 10.10.10.1 + bridge_ports eno1.5 + bridge_stp off + bridge_fd 0 + +auto vmbr0 +iface vmbr0 inet manual + bridge_ports eno1 + bridge_stp off + bridge_fd 0 + +---- + +.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux bridge +---- +auto lo +iface lo inet loopback + +iface eno1 inet manual + + +auto vmbr0.5 +iface vmbr0.5 inet static + address 10.10.10.2 + netmask 255.255.255.0 + gateway 10.10.10.1 + +auto vmbr0 +iface vmbr0 inet manual + bridge_ports eno1 + bridge_stp off + bridge_fd 0 + bridge_vlan_aware yes +---- + +The next example is the same setup but a bond is used to +make this network fail-safe. + +.Example: Use VLAN 5 with bond0 for the {pve} management IP with traditional Linux bridge +---- +auto lo +iface lo inet loopback + +iface eno1 inet manual + +iface eno2 inet manual + +auto bond0 +iface bond0 inet manual + slaves eno1 eno2 + bond_miimon 100 + bond_mode 802.3ad + bond_xmit_hash_policy layer2+3 + +iface bond0.5 inet manual + +auto vmbr0v5 +iface vmbr0v5 inet static + address 10.10.10.2 + netmask 255.255.255.0 + gateway 10.10.10.1 + bridge_ports bond0.5 + bridge_stp off + bridge_fd 0 + +auto vmbr0 +iface vmbr0 inet manual + bridge_ports bond0 + bridge_stp off + bridge_fd 0 + +---- + //// TODO: explain IPv6 support? TODO: explain OVS