[pve-devel] [PATCH docs] Add a paragraph to explain how network models match use cases

Fabian Grünbichler f.gruenbichler at proxmox.com
Mon Oct 9 10:16:24 CEST 2017


does not apply anymore with your previous docs series applied, please
rebase ;)

On Mon, Oct 02, 2017 at 05:17:26PM +0200, Emmanuel Kasper wrote:
> Also :
>  * explain more clearly when PVE switched to persistent device naming. (5.0)
>  * use eno1 instead of eno0 everywhere when refering to the first onboard device
>  * use IP addresses from the range IPv4 Address Blocks for Documentation
>  (rfc5737) instead of private IPv4 addresses when giving examples of public IPs
> ---
>  pve-network.adoc | 101 ++++++++++++++++++++++++++++++++++---------------------
>  1 file changed, 62 insertions(+), 39 deletions(-)
> 
> diff --git a/pve-network.adoc b/pve-network.adoc
> index beb69ae..5d53924 100644
> --- a/pve-network.adoc
> +++ b/pve-network.adoc
> @@ -5,44 +5,32 @@ ifdef::wiki[]
>  :pve-toplevel:
>  endif::wiki[]
>  
> -{pve} uses a bridged networking model. Each host can have up to 4094
> -bridges. Bridges are like physical network switches implemented in
> -software. All VMs can share a single bridge, as if
> -virtual network cables from each guest were all plugged into the same
> -switch. But you can also create multiple bridges to separate network
> -domains.
> -
> -For connecting VMs to the outside world, bridges are attached to
> -physical network cards. For further flexibility, you can configure
> -VLANs (IEEE 802.1q) and network bonding, also known as "link
> -aggregation". That way it is possible to build complex and flexible
> -virtual networks.
> +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.
>  
> -Debian traditionally uses the `ifup` and `ifdown` commands to
> -configure the network. The file `/etc/network/interfaces` contains the
> -whole network setup. Please refer to to manual page (`man interfaces`)
> -for a complete format description.
> +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
>  `/etc/network/interfaces`. Instead, we write into a temporary file
>  called `/etc/network/interfaces.new`, and commit those changes when
>  you reboot the node.
>  
> -It is worth mentioning that you can directly edit the configuration
> -file. All {pve} tools tries hard to keep such direct user
> -modifications. Using the GUI is still preferable, because it
> -protect you from errors.
> -
> -
>  Naming Conventions
>  ~~~~~~~~~~~~~~~~~~
>  
>  We currently use the following naming conventions for device names:
>  
> -* New Ethernet devices: en*, systemd network interface names.
> +* Ethernet devices: en*, systemd network interface names. This naming scheme is
> + used for new {pve} installations since version 5.0.
>  
> -* Legacy Ethernet devices: eth[N], where 0 ≤ N (`eth0`, `eth1`, ...)
> -They are available when Proxmox VE has been updated by an earlier version.
> +* Ethernet devices: eth[N], where 0 ≤ N (`eth0`, `eth1`, ...) This naming
> +scheme is used for {pve} hosts which were installed before the 5.0
> +release. When upgrading to 5.0, the names are kept as-is.
>  
>  * Bridge names: vmbr[N], where 0 ≤ N ≤ 4094 (`vmbr0` - `vmbr4094`)
>  
> @@ -52,8 +40,7 @@ They are available when Proxmox VE has been updated by an earlier version.
>    separated by a period (`eno1.50`, `bond1.30`)
>  
>  This makes it easier to debug networks problems, because the device
> -names implies the device type.
> -
> +name implies the device type.
>  
>  Systemd Network Interface Names
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> @@ -78,12 +65,46 @@ The most common patterns are:
>  
>  For more information see https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/[Predictable Network Interface Names].
>  
> +Choosing a network configuration
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +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 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 
> +directly connected to your LAN.
> +
> +{pve} server at hosting provider, with public IP ranges for Guests
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +For this setup, you can use either a *Bridged* or *Routed* model, depending on
> +what your provider allows.
> +
> +{pve} server at hosting provider, with a single public IP address
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +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, 
> +you will need to configure *Port Forwarding*.
> +
> +For further flexibility, you can configure
> +VLANs (IEEE 802.1q) and network bonding, also known as "link
> +aggregation". That way it is possible to build complex and flexible
> +virtual networks.
>  
>  Default Configuration using a Bridge
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> +Bridges are like physical network switches implemented in software.
> + 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
> -is connected to the first Ethernet card `eno0`. The corresponding
> +is connected to the first Ethernet card `eno1`. The corresponding
>  configuration in `/etc/network/interfaces` looks like this:
>  
>  ----
> @@ -123,9 +144,9 @@ 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.
>  
> -A common scenario is that you have a public IP (assume `192.168.10.2`
> +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
> -(`10.10.10.1/255.255.255.0`). We recommend the following setup for such
> +(`203.0.113.16/29`). We recommend the following setup for such
>  situations:
>  
>  ----
> @@ -134,17 +155,17 @@ iface lo inet loopback
>  
>  auto eno1
>  iface eno1 inet static
> -        address  192.168.10.2
> +        address  198.51.100.5
>          netmask  255.255.255.0
> -        gateway  192.168.10.1
> +        gateway  198.51.100.1
>          post-up echo 1 > /proc/sys/net/ipv4/ip_forward
>          post-up echo 1 > /proc/sys/net/ipv4/conf/eno1/proxy_arp
>  
>  
>  auto vmbr0
>  iface vmbr0 inet static
> -        address  10.10.10.1
> -        netmask  255.255.255.0
> +        address  203.0.113.17
> +        netmask  255.255.255.248
>          bridge_ports none
>          bridge_stp off
>          bridge_fd 0
> @@ -154,19 +175,21 @@ iface vmbr0 inet static
>  Masquerading (NAT) with `iptables`
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> -In some cases you may want to use private IPs behind your Proxmox
> -host's true IP, and masquerade the traffic using NAT:
> +Masquerading allows guests having only a private IP address to access the
> +network by using the host IP address for outgoing traffic. Each outgoing
> +packet is rewritten by `iptables` to appear as originating from the host,
> +and responses are rewritten accordingly to be routed to the original sender.
>  
>  ----
>  auto lo
>  iface lo inet loopback
>  
> -auto eno0
> +auto eno1
>  #real IP address
>  iface eno1 inet static
> -        address  192.168.10.2
> +        address  198.51.100.5
>          netmask  255.255.255.0
> -        gateway  192.168.10.1
> +        gateway  198.51.100.1
>  
>  auto vmbr0
>  #private sub network
> -- 
> 2.11.0
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



More information about the pve-devel mailing list