From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7D1A474EC5 for ; Thu, 2 Jun 2022 11:22:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7B2A22314 for ; Thu, 2 Jun 2022 11:22:54 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 6578E2300 for ; Thu, 2 Jun 2022 11:22:53 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 3DBD142A48 for ; Thu, 2 Jun 2022 11:22:53 +0200 (CEST) From: Aaron Lauterer To: pve-devel@lists.proxmox.com Date: Thu, 2 Jun 2022 11:22:51 +0200 Message-Id: <20220602092251.1393709-4-a.lauterer@proxmox.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220602092251.1393709-1-a.lauterer@proxmox.com> References: <20220602092251.1393709-1-a.lauterer@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.016 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SHORT 0.001 Use of a URL Shortener for very short URL SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [lobraun.de, lwn.net] Subject: [pve-devel] [PATCH docs v2 3/3] network: rework introduction for people with less experience X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 09:22:54 -0000 Mentioning explicitly, that the vmbr interfaces can be thought of as a virtual switch and what can be done overall in the introduction will hopefully help new users to grasp the networking more quickly. Also mention the SDN to point people in that direction if they need it Signed-off-by: Aaron Lauterer --- pve-network.adoc | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) diff --git a/pve-network.adoc b/pve-network.adoc index eab0e02..8ad9903 100644 --- a/pve-network.adoc +++ b/pve-network.adoc @@ -5,13 +5,26 @@ ifdef::wiki[] :pve-toplevel: endif::wiki[] -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 +{pve} is using the Linux network stack. This provides a lot of flexibility on +how to set up the network on the {pve} nodes. The 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. +A 'vmbr' interface is needed to connect guests to the underlying physical +network. They are a Linux bridge which can be thought of as a virtual switch +to which the guests and physical interfaces are connected to. This section +provides some examples on how the network can be set up to accomodate different +use cases like redundancy with a xref:sysadmin_network_bond['bond'], +xref:sysadmin_network_vlan['vlans'] or +xref:sysadmin_network_routed['routed'] and +xref:sysadmin_network_masquerading['NAT'] setups. + +The xref:chapter_pvesdn[Software Defined Network] is an option for more complex +virtual networks in {pve} clusters. + Apply Network Changes ~~~~~~~~~~~~~~~~~~~~~ @@ -153,6 +166,7 @@ physical network. The network, in turn, sees each virtual machine as having its own MAC, even though there is only one network cable connecting all of these VMs to the network. +[[sysadmin_network_routed]] Routed Configuration ~~~~~~~~~~~~~~~~~~~~ @@ -195,6 +209,7 @@ iface vmbr0 inet static ---- +[[sysadmin_network_masquerading]] Masquerading (NAT) with `iptables` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -247,7 +262,7 @@ https://lwn.net/Articles/370152/[Patch on netdev-list introducing conntrack zone https://blog.lobraun.de/2019/05/19/prox/[Blog post with a good explanation by using TRACE in the raw table] - +[[sysadmin_network_bond]] Linux Bond ~~~~~~~~~~ @@ -385,6 +400,7 @@ iface vmbr0 inet static ---- +[[sysadmin_network_vlan]] VLAN 802.1Q ~~~~~~~~~~~ -- 2.30.2