Re: vsw.4: mention veb next to bridge
On Wed, Jul 20, 2022 at 05:27:51PM -0700, Chris Cappuccio wrote: > Klemens Nanni [k...@openbsd.org] wrote: > > veb(4) works just fine in this setup, so don't give the impression only > > bridge(4) would work. > > > > In related items, is it time to tedu bridge(4) and vether(4) ? Is there > anything veb(4) and vport(4) can't do? You can't use veb(4) to quickly bridge configured networks together. e.g. you want to run a VM that has L2 access to your main interface. With veb(4) you have to fully reconfigure the system since you can't assign IP addrs to interfaces added to veb (apart from vport). -- :wq Claudio
Re: vsw.4: mention veb next to bridge
Damien Miller wrote: > On Wed, 20 Jul 2022, Chris Cappuccio wrote: > > > Klemens Nanni [k...@openbsd.org] wrote: > > > veb(4) works just fine in this setup, so don't give the impression only > > > bridge(4) would work. > > > > In related items, is it time to tedu bridge(4) and vether(4) ? Is there > > anything veb(4) and vport(4) can't do? > > There's the link2 ipsec stuff that bridge(4) supports but veb(4) > doesn't, IDK if anyone uses it. There's some commented out code in > if_veb.c for this, but I don't know whether it is commented out because > it doesn't work or because nobody has asked for it > > At the very least, the ioctls documentation in bridge.4 would need > to be copied over to veb.4 - it looks like most of them are supported. Let me make a guess where this will go Someone will now try to add code to support all these gaps to veb. And veb will develop bugs, mostly due to complexity. And someone will write a new replacement, while others mourn the past where stuff just worked in it's own ways, with bugs but they didn't hit them with their use case. The worm will eat it's tail. There are people *TODAY RIGHT NOW* using the bridge and vether to solve problems, and they understand what they are doing and they do not need to immediately flip to the tech-de-jour. When new things arise, must they become dominant? Must people using existing things migrate to them? Is it the idea that everything we do is a MANDATORY transition? I think not. So can we stop please this? If you all haven't noticed, in the last two years we are short on people fixing bugs and writing new code, and yet this delete-delete-delete fetish is crazy strong.
Re: vsw.4: mention veb next to bridge
On Wed, 20 Jul 2022, Chris Cappuccio wrote: > Klemens Nanni [k...@openbsd.org] wrote: > > veb(4) works just fine in this setup, so don't give the impression only > > bridge(4) would work. > > In related items, is it time to tedu bridge(4) and vether(4) ? Is there > anything veb(4) and vport(4) can't do? There's the link2 ipsec stuff that bridge(4) supports but veb(4) doesn't, IDK if anyone uses it. There's some commented out code in if_veb.c for this, but I don't know whether it is commented out because it doesn't work or because nobody has asked for it At the very least, the ioctls documentation in bridge.4 would need to be copied over to veb.4 - it looks like most of them are supported. -d
Re: vsw.4: mention veb next to bridge
Klemens Nanni [k...@openbsd.org] wrote: > veb(4) works just fine in this setup, so don't give the impression only > bridge(4) would work. > In related items, is it time to tedu bridge(4) and vether(4) ? Is there anything veb(4) and vport(4) can't do?
vsw.4: mention veb next to bridge
veb(4) works just fine in this setup, so don't give the impression only bridge(4) would work. OK? Index: vsw.4 === RCS file: /cvs/src/share/man/man4/man4.sparc64/vsw.4,v retrieving revision 1.3 diff -u -p -r1.3 vsw.4 --- vsw.4 16 Jul 2013 16:05:50 - 1.3 +++ vsw.4 20 Jul 2022 22:03:08 - @@ -33,6 +33,8 @@ It attaches a separate interface for each switch port. These ports can be added to a .Xr bridge 4 +or +.Xr veb 4 to create a functional network switch. .Pp The @@ -42,7 +44,8 @@ driver supports version 1.0 of the vNet .Xr bridge 4 , .Xr cbus 4 , .Xr intro 4 , -.Xr netintro 4 +.Xr netintro 4 , +.Xr veb 4 .Sh HISTORY The .Nm
