public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: alexandre derumier <aderumier@odiso.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports
Date: Thu, 16 Sep 2021 23:48:15 +0200	[thread overview]
Message-ID: <5e94541c69f65eb9859d6b9f036ed80acf8f113e.camel@odiso.com> (raw)
In-Reply-To: <478a4600-48f4-3fe8-91ec-e2dbb27bd2c8@proxmox.com>

Le mercredi 15 septembre 2021 à 19:09 +0200, Thomas Lamprecht a écrit :
> On 15.09.21 17:33, alexandre derumier wrote:
> > I have looked at other hypervisors implementations (as it don't see
> > to
> > have problem with hetzner),
> > 
> > 
> > https://listman.redhat.com/archives/libvir-list/2014-December/msg00173.html
> > 
> > 
> > https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-C5752084-A582-4AEA-BD5D-03FE5DBC746E.html
> > 
> > 
> > Both vmware && libvirt have a mode to manually manage fdb entries
> > in
> > bridge mac table.
> > 
> > This will work if only 1mac is behind 1 nic, so it should be an
> > option
> > (nested hypervisor for examples).
> > 
> > but for classic vm , it could allow to disable unicast_flood &&
> > learning for the tap interface, but also promisc mode on tap
> > interface!
> > 
> > I was think about add an option on vmbrX  or vnetX directly to
> > enable/disable.
> 
> As this would be on the VM tap devices it would sound somewhat
> reasonable to
> have it as per vNIC setting, but naturally it would then be a bit
> annoying to
> change for all; a tradeoff could be to allow setting the default
> value per
> bridge, node or datacenter (I'd do only one of those).
> 
> What do you think?
> 
I have done test, I think the best way is to enable it on the bridge
 or vnet for sdn.
because ovs don't support it for example, or its not needed for routed
setup or vxlan.
I don't known too much where add this option for classic vmbr ? in
/etc/network/interfaces ?.
I can't reuse bridge-unicast-flood off, bridge-learning off on vmbr
with ifupdown, because it's apply on all ports (ethX), and we don't
want that.
I could add a custom attribute, but I need to parse
/etc/network/interfaces in this case  for the tap_plug sub. 
For vnet, it's easy.

the worktlow is:

1)
- plug veth/tap iface (+fwbr if firewall)
   - disable unicast_flood + bridge_learning on the tap|veth + fwpr
interfaces

2)
then add static mac with "bridge fdb add <mac> dev <tap|veth|fwpr>
master static.

for 2), for live migration, we need to do it just before the resume of
the target vm
         for normal start, just after the start or after a nic hotplug.

static mac is autoremoved if the interface is removed, so it should be
auto handle by cleanup on vm crash too



As bonus, the benefit to configure it at bridge level, is that if all
egress ports (tap|veth|fwpb) have unicast_flood && learning disable,
the only remaining port (physical ethX ingress), is auto set in non-
promiscous, so bad traffic never go inside the server.
(another requirement is that the bridge need to be vlan-aware, but I
think it could work at herzner is default pvid 1 for untagged traffic)
https://git.backbone.ws/kolan/backbone-sources/commit/2796d0c648c9

https://legacy.netdevconf.info/0.1/docs/netdev_tutorial_bridge_makita_150213.pdf

I'ill try to send patches next week, I'm a bit busy at work this week.


Alexandre


> > 
> > I'm going to do tests, testing vlan aware && live migration too.
> 
> great, thanks for your work on this!
> 



  reply	other threads:[~2021-09-16 21:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14  0:26 Alexandre Derumier
2021-09-14  6:32 ` alexandre derumier
2021-09-15 15:33   ` alexandre derumier
2021-09-15 17:09     ` Thomas Lamprecht
2021-09-16 21:48       ` alexandre derumier [this message]
2022-01-14 10:51         ` Wolfgang Bumiller
2022-01-14 11:23           ` Josef Johansson
2022-01-28  3:39             ` Josef Johansson
2022-01-14 16:50           ` DERUMIER, Alexandre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e94541c69f65eb9859d6b9f036ed80acf8f113e.camel@odiso.com \
    --to=aderumier@odiso.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal