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 11AE2677FC for ; Thu, 27 Aug 2020 13:20:09 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0766A16EC9 for ; Thu, 27 Aug 2020 13:19:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 1FFFB16EBC for ; Thu, 27 Aug 2020 13:19:38 +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 CE68F448E7; Thu, 27 Aug 2020 13:19:37 +0200 (CEST) To: Proxmox VE development discussion , Tom Weber , Stephan Leemburg References: <1877466395.127.1598159022900@webmail.proxmox.com> <292235591.128.1598159408132@webmail.proxmox.com> <15c9ed01-6e88-b3c6-6efd-cb5c881904fb@it-functions.nl> <169647259.135.1598192643864@webmail.proxmox.com> <4da8f252-3599-6af2-f398-3c7ac0010045@it-functions.nl> <41585d8d-d0be-3c71-b2fa-380731133fe7@it-functions.nl> <522191112.137.1598244794966@webmail.proxmox.com> <97fb389a-daae-2787-eac1-39ed2ac23be4@it-functions.nl> <494606189.360.1598284149700@webmail.proxmox.com> <890269350b55f29457cd32bc35911a66ebcd36f3.camel@junkyard.4t2.com> From: Thomas Lamprecht Message-ID: Date: Thu, 27 Aug 2020 13:19:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <890269350b55f29457cd32bc35911a66ebcd36f3.camel@junkyard.4t2.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.025 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -2.239 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [anracom.com] Subject: Re: [pve-devel] More than 10 interfaces in lxc containers 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, 27 Aug 2020 11:20:09 -0000 Am 8/24/20 um 6:14 PM schrieb Tom Weber: > Am Montag, den 24.08.2020, 17:49 +0200 schrieb Dietmar Maurer: >>> On 08/24/2020 12:54 PM Stephan Leemburg wrote: >>> On 24-08-2020 06:53, Dietmar Maurer wrote: >>>>> If I don't put a tag on the device, it seems to behave like a >>>>> trunk. So, that would solve my problem. _If_ the hosts where openvswitch >>>>> enabled. >>>> >>>> I am unable to see why you need openvswitch for that? This also >>>> works with standard linux network. >>> >>> Oh, that is new for me. >>> >>> So, I can have a vlan aware traditional bridge in the firewall >>> that >>> receives tagged frames and at the same time have the clients on >>> the >>> specific 'vlans' receive non-tagged frames for their respective >>> pvid? >>> >>> How can this be configured in Proxmox? >> >> You do not not any special config on the pve host if you do all VLAN >> related >> stuff inside the VM. > > You do realize that Stephan is talking about CT not VM? (althought I > don't think such a setup makes sense) > But it should be also possible to do that with CTs and their veth devices, they can be untagged and act like a trunk interface (and they can to that on one or both side of the veth peers). I found this article which seems to explain the thematic quite well, at least after skimming over it ;-) https://linux-blog.anracom.com/2017/11/20/fun-with-veth-devices-linux-bridges-and-vlans-in-unnamed-linux-network-namespaces-iv/ I applied the increase to the CT NIC limit nonetheless, as it makes sense to have it in sync with VMs. But this use case shouldn't need that increase... cheers, Thomas