tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Simplify bridge(4)



On Sat, Feb 13, 2016 at 7:19 AM, Mouse <mouse%rodents-montreal.org@localhost> wrote:
>> tap(4) is a direct interface between userland and the network.
>
> Well, where "the network" refers to the Ethernet stack and higher
> layers within the kernel, not to any real networking medium.
>
>> vether(4) would not be (although you could use BPF, etc.).  It would
>> be an ethernet device that represents the host.
>
> I'm not even sure what that could mean.
>
>> If you know how to configure Cisco devices, think BVI.
>
> I did not know the term; from what little I found in a few minutes'
> searching, it sounds like something that exists solely to be a bridge
> member, to make up for their bridges' inability to have an address or
> otherwise be a destination for IP-layer (or, more generally,
> above-Ethernet-layer) routes.
>
>> The problem with bridge(4) is that you put addresses on one of the
>> interfaces included in the bridge.
>
> Why is that a problem?
>
>> The addresses belong to the host as a whole, not to the particular
>> part represented by an interface to part of the outside world.
>
> Sounds to me as though the most sensible way to model that would be to
> give the address to the bridge interface itself.
>
> I don't think I've tried that.  If it does not work, is there any
> particular reason to add vether(4) rather than making it work?  If it
> does work, what functionality would vether(4) provide over it?

It's a design choice. FreeBSD adopts extending bridge(4) to assign
IP addresses and OpenBSD adopts vether(4). Both work and neither
is wrong.

I prefer vether's approach because it keeps bridge(4) simple still
providing the same functionality of extending bridge itself.

  ozaki-r

>
>> A bridge is really network infrastructure, not part of a host.
>
> Normally true, but it can of course be implemented on a host.  Indeed,
> I would say that bridge should not, conceptually, be a network
> interface at all; I suspect it was done as a network interface simply
> because that got a lot of infrastructure for free - and, if it works to
> put an address on the bridge interface itself, because that part of it
> _should_ be a network interface.
>
> /~\ The ASCII                             Mouse
> \ / Ribbon Campaign
>  X  Against HTML                mouse%rodents-montreal.org@localhost
> / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index