CVS commit: src/sys/net

[Robert Elz]

Date: Sun, 27 Sep 2020 19:16:28 +0000
From: "Roy Marples" <***@netbsd.org>
Message-ID: <***@cvs.NetBSD.org>

| This ensures that Duplicate Address Detection for the joining interface
| are performed across all members of the bridge.

This sounds like a good idea, but I believe it is breaking (or ignoring)
the oft stated design aim of the bridge interface, which is to emulate an
external bridge - not to emulate being one.

That's the justification for not allowing the local address for the
(combined) network to be configured on the bridge interface itself,
but to require that it be on one of the connected interfaces (or on a
tap or vether interface instead, so it remains if the selected real
interface goes down).

With an external bridge, unless the connection to the bridge is making
the link come up (ie: there was no carrier before), the interface will
not redo DAD just because its link has become attached to a bridge,
however appealing it might be if that were to happen. (If the interface
had no carrier, was down, before being attached to the bridge, then when
it comes up it will do DAD in the normal way).

If we're giving up on the "external bridge" model (even partially) then
we should give up on the "no addresses on the bridge interface" as well,
and so remove the need for a tap/vether interface to be connected to the
bridge fpr the sole purpose of holding a stable address.

kre

ps: Was the change to the tap interface, which makes it no longer work as
the bridge address holder discussed anywhere? That one sounds like it
is likely to break people's configurations.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Robert Elz
Date: Sun, 27 Sep 2020 19:16:28 +0000
| This ensures that Duplicate Address Detection for the joining interface
| are performed across all members of the bridge.
This sounds like a good idea, but I believe it is breaking (or ignoring)
the oft stated design aim of the bridge interface, which is to emulate an
external bridge - not to emulate being one.

I have no idea what this "oft stated design aim of the bridge interface" is.
Where is this documented?
Our bridge(4) has zero hits for the word external.
Also, what is this difference between an external bridge vs being one?

A bridge is a bridge, virtual or otherwise.

Post by Robert Elz
That's the justification for not allowing the local address for the
(combined) network to be configured on the bridge interface itself,
but to require that it be on one of the connected interfaces (or on a
tap or vether interface instead, so it remains if the selected real
interface goes down).
With an external bridge, unless the connection to the bridge is making
the link come up (ie: there was no carrier before), the interface will
not redo DAD just because its link has become attached to a bridge,
however appealing it might be if that were to happen. (If the interface
had no carrier, was down, before being attached to the bridge, then when
it comes up it will do DAD in the normal way).
If we're giving up on the "external bridge" model (even partially) then
we should give up on the "no addresses on the bridge interface" as well,
and so remove the need for a tap/vether interface to be connected to the
bridge fpr the sole purpose of holding a stable address.
kre

You're reading far too much into this.
Let's break it down to brass tacks.

The bridge is a glory hole.
Should it try to protect it's members identities (local addresses) or not?

Now that you mention it though, the whole link should be taken down on bridge
join (and then link state restored). It's the only way to be sure.
Some might view as too agressive.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Mon, 28 Sep 2020 03:12:00 +0100
From: Roy Marples <***@marples.name>
Message-ID: <6ab8c52e-9524-c777-d0fa-***@marples.name>

| I have no idea what this "oft stated design aim of the bridge interface" is.
| Where is this documented?

Hunt the mailing lists for queries about bridge config, where people have
tried to config an IP addr on bridge0 and had it not work, and asked why.

That's the answer that's always given.

| Also, what is this difference between an external bridge vs being one?
| A bridge is a bridge, virtual or otherwise.

I think I agree, but then I've always believed that it should be
possible to config addrs on bridge interfaces, rather than the
nonsense of requiring a tap (or now vether) interface in addition
to whatever other (packet transmitting) interfaces are actually
attached.

What would you think about making a vbridge interface (or some name
like that) that would be a combined bridge and vether in one driver?
And simply not giving the vether a name (or an actual attachment) ...


| You're reading far too much into this.
| Let's break it down to brass tacks.
|
| The bridge is a glory hole.
| Should it try to protect it's members identities (local addresses) or not?

No. How can it? It is the member's job to protect their identities,
not the network infrastructure. That's all it can possibly be, bridges
and hubs ae (supposedly) dumb L2 devices that know nothing about the
network layer protocols that sit above them. Some bridges know that
most traffic they see is IP, and attempt to optomise that (sending
frames only to the link where the destination is known to be ...) but
that's always done in the failsafe way, where packets for unknown
destinations are sent everywhere, so the presence of the bridge is
undetectable.

| Now that you mention it though, the whole link should be taken down
| on bridge join (and then link state restored). It's the only way to be sure.
| Some might view as too agressive.

Some might, probably most might, but even if not, that is not enough.

I quite often use a dumb hub for link splitting - those things tend not
to pass on lost carrier on one link to other links (if they did they'd
never work when not all ports were connected to powered up devices).

It is simply impossible to actually achieve what you'd like to do,
there never has been a way to ensure that there's no address duplication
(even doing DAD on a fully connected link does not promise that, as a
reply packet might be lost/corrupted - even perhaps several times if the
owner of the about to be duplicated addr is on the wrong side of a
poor physical connection).

kre



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Olaf Seibert]

Post by Robert Elz
I think I agree, but then I've always believed that it should be
possible to config addrs on bridge interfaces,

Linux has something like that, but the way they do it is in my view
totally confusing and undesirable.

When I run some emulator that requires network access via a tap device,
I typically bridge it to the outside ethernet. This way it can
communicate with the local host and the outside world (contrary to the
"traditional" way using BPF).

However as soon as you do this on Linux, the ethernet interface
immediately loses its connectivity. You're supposed to move over the IP
address to the bridge, and use the bridge in all configurations where
you used the ethernet before. And when you have no need for the bridge
anymore, move everything back. (The GUI tools know nothing of this,
of course)

That is of course totally impractical and wrong. Besides, bridges should
not have addresses anyway, they are just virtual wires soldered
together, at most as complicated as switches (which don't have addresses
either).

-Olaf.

[Robert Elz]

Date: Tue, 29 Sep 2020 22:18:16 +0200
From: Olaf Seibert <***@NetBSD.org>
Message-ID: <***@falu.nl>

| However as soon as you do this on Linux, the ethernet interface
| immediately loses its connectivity. You're supposed to move over the IP
| address to the bridge, and use the bridge in all configurations where
| you used the ethernet before.

I wouldn't want that either, anything connected to the bridge, and the
bridge itself, should be able to hold an address, and they should all
work (and addresses on links should work the same as they do now, going
deprecated when the link they're assigned to goes down).

That is, to extend your example, if I have two (IPv4 for this example)
/25 networks, say

192.168.1.1/25 and 192.168.1.129/25

I should be able to bridge them together, change the netmasks to /24
and now have two interfaces that are 192.168.1.1/24 and 192.168.1.129/24
connected to the same bridged network. I want both addresses as those
have been published (and are used) as addresses for my host. If I decide
to, I should also be able to add 192.168.1.250 to the bridge itself, so I
have a stable address for my host that will always work, even if one of the
two physical interfaces goes down.

Please don't assume I want to copy Linux, that's almost never going to be true.

Using a tap connected to a bridge, when there is something using the
tap for passing packets is just fine - that's why the interface type exists.
Requiring one (or a vether in recent HEAD) to be added, when nothing is using
it, just to proivide a stable point on which to hang an address, is dumb.

| That is of course totally impractical and wrong. Besides, bridges should
| not have addresses anyway, they are just virtual wires soldered
| together, at most as complicated as switches (which don't have addresses
| either).

The bridge doesn't have the address, the host connected to it does.

The question is whether we should require an extra interface to be
added (more ifconfig -a output) for no reason other than to show that
the host is connected to the bridge. We would be just calling the host's
interface to the bridge bridgeN instead of tapN - which do you believe
to be clearer?

If you want a bridge, without the host it is running on being connected,
then simply don't configure any addresses, for any L3 protocols, on any
of the connected interfaces.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rob Newberry]

Post by Robert Elz
What would you think about making a vbridge interface (or some name
like that) that would be a combined bridge and vether in one driver?
And simply not giving the vether a name (or an actual attachment) ...

I'd welcome something like that.

Back when we did AirPort work at Apple, one of the first things we did was heavily revise the bridge interface so that (a) you could install interfaces on it, and (b) it had most of the Ethernet features we wanted (like filtering out multicasts that weren't subscribed by the kernel).

Rob



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Robert Elz
I think I agree, but then I've always believed that it should be
possible to config addrs on bridge interfaces, rather than the
nonsense of requiring a tap (or now vether) interface in addition
to whatever other (packet transmitting) interfaces are actually
attached.
What would you think about making a vbridge interface (or some name
like that) that would be a combined bridge and vether in one driver?
And simply not giving the vether a name (or an actual attachment) ...

Then we loose the ability to have a virtual network yes?
server -> vether0 -> bridge0 -> vether1 -> client

If we change to the model
server -> bridge_ether0 -> client

Then the packets never actually leave the interface rendering diagnostic via
tcpdump useless or testing DHCP useless.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Thu, 1 Oct 2020 08:46:56 +0100
From: Roy Marples <***@marples.name>
Message-ID: <74c16ff9-ec57-410c-27b6-***@marples.name>

| Then we loose the ability to have a virtual network yes?
| server -> vether0 -> bridge0 -> vether1 -> client

No, why would you? If that's what you want to configure, then
configure it that way. The aim is flexibility, with minimum
restrictions.

Nothing of what I've been saying has anything to do with the addition
of the vether interface to the system, that's fine - the closest
comment to that was on the change to the way the tap interface works
once vether was able to replace it as a bridge address hanging interface.

You'd still be able to bridge together as many interfaces (real or virtual)
as the bridge code can handle (probably no real limit, other than what
performance dictates, but I have never been tempted to go beyond a few,
so I'm not sure). The only difference in what I'm suggesting is that
you'd be able to, if you desired, configure L3 addresses on the bridge
interface, as well as elsewhere - for the diagram above you probably
wouldn't need, or want, to do that.

| If we change to the model
| server -> bridge_ether0 -> client

I'm not sure how that would work, no matter what bridge allows.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Roy Marples
A bridge is a bridge, virtual or otherwise.

A bridge doesn't have an IP address, so you are talking about something else?

[Mouse]

Post by Michael van Elst

Post by Roy Marples
A bridge is a bridge, virtual or otherwise.

A bridge doesn't have an IP address, so you are talking about
something else?

Maybe "network interface" is not the right abstraction for bridges to
be instances of, then? (Though, at least in my experience, NetBSD's
"bridge" interfaces are more like switches than bridges.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Greg Troxel

(Though, at least in my experience, NetBSD's "bridge" interfaces are
more like switches than bridges.)

I am not sure how you draw the line between switch and bridge.

It's admittedly a somewhat fuzzy distinction - but then, `bridge' is a
somewhat fuzzy term too.

As I was using it in the double-quoted text above, a bridge is much
dumber, on the order of a hub or a media converter, just echoing out
what it receives in. A switch has more smarts - it knows enough about
packet formats to pick out source and destination addresses, learn what
addresses occur on which ports, and avoid sending unicast packets to
pointless ports. It also might speak a few protocols, such as spanning
tree, in its own right.

Post by Greg Troxel
I agree that "bridge0" being a "network interface" is not entirely
right. I see it as close enough that using config ioctls is sensible
and therefore it seems like a software writing optimization, compared
to creating a first-class switch type.

I'm not sure. The only parts of the "network interface" abstraction I
see bridges as really using are creation and destruction, naming
(including ifconfig -l), and IFF_UP/~IFF_UP. I'm not sure whether I
think that's justification enough for dragging along the rest of the
network interface baggage - perhaps I just haven't looked closely
enough at the bridge implementation.

Maybe it would help if bridges rejected all attempts to configure
addresses on them?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Mouse
As I was using it in the double-quoted text above, a bridge is much
dumber, on the order of a hub or a media converter, just echoing out
what it receives in. A switch has more smarts - it knows enough about
packet formats to pick out source and destination addresses, learn what
addresses occur on which ports, and avoid sending unicast packets to
pointless ports. It also might speak a few protocols, such as spanning
tree, in its own right.

AIUI NetBSD's bridge does L2 reception with CRC, and has tables of what
goes where, and can do the spanning tree protocol, plus can store
multiple packets in queues -- so it's a switch.

After some reading I conclude that bridge refers to early devices that
are like switches but don't have the buffering. What you would have
used in the 80s :-)

Post by Mouse

Post by Greg Troxel
I agree that "bridge0" being a "network interface" is not entirely
right. I see it as close enough that using config ioctls is sensible
and therefore it seems like a software writing optimization, compared
to creating a first-class switch type.

I'm not sure. The only parts of the "network interface" abstraction I
see bridges as really using are creation and destruction, naming
(including ifconfig -l), and IFF_UP/~IFF_UP. I'm not sure whether I
think that's justification enough for dragging along the rest of the
network interface baggage - perhaps I just haven't looked closely
enough at the bridge implementation.
Maybe it would help if bridges rejected all attempts to configure
addresses on them?

THat's basically what I meant. Disallow interface-only things.

Take the view that ifconfig works on network things, of which there are
interfaces and bridges.

[Mouse]

Post by Greg Troxel

As I was using it in the double-quoted text above, [...]

AIUI NetBSD's bridge does L2 reception with CRC, and has tables of
what goes where, and can do the spanning tree protocol, plus can
store multiple packets in queues -- so it's a switch.

As I was using the term, yes.

Post by Greg Troxel
After some reading I conclude that bridge refers to early devices
that are like switches but don't have the buffering. What you would
have used in the 80s :-)

What I did use in the '80s! :-) Still do, occasionally; I have a
10Mb-only hub - not switch - that I use when connecting certain older
hardware, hardware that has twisted-pair but is too impatient for
modern Ethernet autonegotiation and decides carrier is down. (Some of
them can be taught to be more forgiving, but I suspect some can't, and
it's easier and simpler in many cases to just use the hub. Most such
hardware can't do better than 10/half anyway, and I rarely want to run
significant levels of traffic from two such at once, so it doesn't
really impair anything in practice.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Mouse

Post by Michael van Elst

Post by Roy Marples
A bridge is a bridge, virtual or otherwise.

A bridge doesn't have an IP address, so you are talking about
something else?

Some bridges do have IP addresses for managemment, but it is more like
there is a bridge and in the same box there is a host.

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges to
be instances of, then? (Though, at least in my experience, NetBSD's
"bridge" interfaces are more like switches than bridges.)

I am not sure how you draw the line between switch and bridge.

I agree that "bridge0" being a "network interface" is not entirely
right. I see it as close enough that using config ioctls is sensible
and therefore it seems like a software writing optimization, compared to
creating a first-class switch type.

So perhaps bridges should have some flag that says they are bridges, and
most everything else normal should fail on them, except for the special
bridge ioctls.

[Michael van Elst]

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges to
be instances of, then? (Though, at least in my experience, NetBSD's
"bridge" interfaces are more like switches than bridges.)

A switch is a bridge with more than two ports.

bridge(4) just looks like a network interface because that's what the
network stack provides.

[Mouse]

Post by Michael van Elst

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges
to be instances of, then? (Though, at least in my experience,
NetBSD's "bridge" interfaces are more like switches than bridges.)

A switch is a bridge with more than two ports.

Then what is my 8-port 10Mb hub? Switch, bridge, neither? It has no
buffering and it always floods all traffic - traffic from port A to a
machine on port B at the same time as traffic from port C to a machine
on port D will produce a collision. This means it is not a switch as
I've used the term throughout my career (well, throughout after the
point when devices smart enough to send unicast traffic to only the
appropriate port appeared). But it has eight - more than two - ports.

I also own an AUI multiport transceiver box that's basically the same
thing, but AUI instead of twisted-pair - it has eight connectors which
present AUI transceiver interfaces (for connection to hosts) and one
which presents an AUI host interface (for connection to a transceiver).

Is it a bridge, a switch, neither, what? Why?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Mouse

Post by Michael van Elst

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges
to be instances of, then? (Though, at least in my experience,
NetBSD's "bridge" interfaces are more like switches than bridges.)

A switch is a bridge with more than two ports.

I can buy that definition.

Post by Mouse
Then what is my 8-port 10Mb hub? Switch, bridge, neither? It has no
buffering and it always floods all traffic - traffic from port A to a
machine on port B at the same time as traffic from port C to a machine
on port D will produce a collision. This means it is not a switch as
I've used the term throughout my career (well, throughout after the
point when devices smart enough to send unicast traffic to only the
appropriate port appeared). But it has eight - more than two - ports.

Neither. It's a hub, which retransmits L1 without decoding L2.

Post by Mouse
I also own an AUI multiport transceiver box that's basically the same
thing, but AUI instead of twisted-pair - it has eight connectors which
present AUI transceiver interfaces (for connection to hosts) and one
which presents an AUI host interface (for connection to a transceiver).
Is it a bridge, a switch, neither, what? Why?

basically a hub. Interesting - I never heard of that.

[Robert Elz]

Date: Mon, 28 Sep 2020 16:13:44 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Stone.Rodents-Montreal.ORG>

| Is it a bridge, a switch, neither, what? Why?

Typically (though the labels are largely marketing speak) a hub is
a multi-port repeater - basically just adds power to the incoming
signal, so it can be transmitted further, but subtracts preamble
bits (it has to recognise an incoming frame before it starts transmitting)
so there's a limit on how many can appear on one link (1 or 2, its
been so long). Both sides of the hub/repeater form parts of the
same collision domain (a collision on one side is repeated out the other).
They are L1 devices.

bridges/switches are L1 endpoints, and retransmit packets after some
delay (how much buffering, and how much delay in the best case varies).
Ports on bridges/switches are in separate collision domains. There's
no limit (except your bankbook, and how much transit delay you're
prepared to tolerate) on how many you can connect together in a single
L2 LAN.

None of this terminology discussion is important however, it really
doesn't matter in the slightest what it is called, and picking something
based just on some marketing label would by silly - what matters are
the performance characteristics and limits, not what the marketing dept
decided to write on the box.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Mouse

Post by Michael van Elst

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges
to be instances of, then? (Though, at least in my experience,
NetBSD's "bridge" interfaces are more like switches than bridges.)

A switch is a bridge with more than two ports.

Then what is my 8-port 10Mb hub? Switch, bridge, neither?

Neither, it's a repeater.

Repeater / Hub -> Layer 1. Incoming signal from one port at a time
is send out (after some amplification / regeneration) to all other
ports. Single collision domain.

Bridge / Switch -> Layer 2. Packets (or often just a few bits to reduce
latency) are buffered and transmitted to other ports, a forwarding
database is used to prune destinations. Separates multiple collision
domains.

The terms Hub and Switch came up when the devices got more than two ports,
but functionally these are not different from the earlier terms.

There are hybrid devices. I have a thingie that has some 10Mbit and some
100 Mbit ports. Technically it's two repeaters with a two port bridge
in between. Since repeaters work on layer 1, they cannot translate
different speeds. A bridge can.

[Paul Ripke]

Post by Michael van Elst

Post by Mouse

Post by Michael van Elst

Post by Mouse
Maybe "network interface" is not the right abstraction for bridges
to be instances of, then? (Though, at least in my experience,
NetBSD's "bridge" interfaces are more like switches than bridges.)

A switch is a bridge with more than two ports.

Then what is my 8-port 10Mb hub? Switch, bridge, neither?

Neither, it's a repeater.
Repeater / Hub -> Layer 1. Incoming signal from one port at a time
is send out (after some amplification / regeneration) to all other
ports. Single collision domain.
Bridge / Switch -> Layer 2. Packets (or often just a few bits to reduce
latency) are buffered and transmitted to other ports, a forwarding
database is used to prune destinations. Separates multiple collision
domains.

See "cut-through switching", where as soon as enough bits of the frame
is received to determine the destination port, it starts transmitting
on the destination port, if it is idle. If the port is busy, it reverts
to the other method, "store and forward". Made a measurable difference
to latency on 100Mbit networks, I don't know that anyone bothers on
modern 10+Gbit gear.

Post by Michael van Elst
The terms Hub and Switch came up when the devices got more than two ports,
but functionally these are not different from the earlier terms.

Yup, I always considered:
- a hub is a multi-port repeater.
- a switch is a multi-port bridge.

Post by Michael van Elst
There are hybrid devices. I have a thingie that has some 10Mbit and some
100 Mbit ports. Technically it's two repeaters with a two port bridge
in between. Since repeaters work on layer 1, they cannot translate
different speeds. A bridge can.

I had one of these - advertised as a "switching hub". 8 ports,
auto-negotiated 10Mbit or 100Mbit half duplex. I guess the auto-neg
somehow switched the ports between the two hubs, and, like you say,
the hubs were bridged together.

Reminiscing... should I mention 10BASE5 and vampire taps?

[Roy Marples]

Post by Robert Elz
ps: Was the change to the tap interface, which makes it no longer work as
the bridge address holder discussed anywhere? That one sounds like it
is likely to break people's configurations.

Yes.

thorpej | Agreed, that IFM_ACTIVE should be set when it's open
thorpej | link up, bruh!

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

Date: Mon, 28 Sep 2020 03:26:41 +0100
From: Roy Marples <***@marples.name>
Message-ID: <96b3c28c-842a-dc41-b3da-***@marples.name>

| thorpej | Agreed, that IFM_ACTIVE should be set when it's open
| thorpej | link up, bruh!

I assume by now you've seen that you broke the
net/if_tap/t_tap:tap_bridged
ATF test by making that change.

This isn't necessarily the wrong thing to do, but it needs to be
phased in, people need time to adjust their configs, rather than
having vether introduced one day and the same, or next day, their
bridge+tap (the way it has always been explained to config things
to avoid the local connection to the bridge losing its addr if the
addr is config'd on a physical link, and that link goes down).

kre

ps: I really don't believe that the occasional chat with whoever
happens to be paying attention of irc/icb at the time counts as
any kind of real discussion - send proposed changes that will
affect people to the mailing lists.




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de