netdev - Re: [PATCH net-next v1 1/1] bonding: Adding limmited support for ARP monitoring with ovs.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z_77On1togfQ1vgM@fedora>
Date: Wed, 16 Apr 2025 00:35:06 +0000
From: Hangbin Liu <haliu@...hat.com>
To: David Wilder <wilder@...ibm.com>
Cc: Jay Vosburgh <jv@...sburgh.net>, Ilya Maximets <i.maximets@....org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"pradeeps@...ux.vnet.ibm.com" <pradeeps@...ux.vnet.ibm.com>,
	Pradeep Satyanarayana <pradeep@...ibm.com>,
	Adrian Moreno Zapata <amorenoz@...hat.com>
Subject: Re: [PATCH net-next v1 1/1] bonding: Adding limmited support for ARP
 monitoring with ovs.

On Tue, Apr 15, 2025 at 10:13:18PM +0000, David Wilder wrote:
> >>> I agree that adding options is almost never a great solution.  But I had a
> >>> similar thought.  I don't think this option should be limited to OVS though,
> >>>as OVS is only one of the cases where the current verification logic is not
> >>>sufficient.
> >
> >        Agreed; I wasn't really thinking about the not-OVS cases when I
> >wrote that, but whatever is changed, if anything, should be generic.
> 
> >>What if we build on the arp_ip_target setting.  Allow for a list of vlan tags
> >> to be appended to each target. Something like: arp_ip_target=x.x.x.x[vlan,vlan,...].
> >> If a list of tags is omitted it works as before, if a list is supplied assume we know what were doing
> >> and use that instead of calling bond_verify_device_path(). An empty list would be valid.
> 
> >        Hmm, that's ... not too bad; I was thinking more along the lines
> >of a "skip the checks" option, but this may be a much cleaner way to do
> >it.
> 
> >        That said, are you thinking that bonding would add the VLAN
> >tags, or that some third party would add them?  I.e., are you trying to
> >accomodate the case wherein OVS, tc, or whatever, is adding a tag?
> 
> It would be up to the administrator to add the list of tags to the arp_target list.
> I am unsure how a third party could know what tags might be added by other components.
> Knowing what tags to add to the list may be hard to figure out in a complicated configuration.
> The upside is it should be possible to configure for any list of tags even if difficult.
> 
> A "skip the checks" option would be easier to code. If we skip the process of gathering tags
> would that eliminate any configurations with any vlan tags?.

+1 for "skip the checks". If arp_ip_target=x.x.x.x[vlan,vlan,...] doesn't
ask bond to add vlan tags, there is no need to set the vlan in parameter.

Since OVS, tc, netfilter can add vlan or change the output ports. A "skip
the checks" setting looks more reasonable.

Thanks
Hangbin