Bridge interface and IP address

[Lukasz Wojcik]

Hi,

I'm looking for the answer for a question, if it is allowed somehow to
assign an IP address to the virtual bridge interface ? As far as i know
it is possible in Linux. I believe it can also be done in FreeBSD using
just ifconfig. It seems impossible in NetBSD. I could not find any
information about that, and man page does not specify it either. Thanks
in advance for your response.


LW.

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

[Manuel Bouyer]

Post by Lukasz Wojcik
Hi,
I'm looking for the answer for a question, if it is allowed somehow
to assign an IP address to the virtual bridge interface ? As far as
i know it is possible in Linux. I believe it can also be done in
FreeBSD using just ifconfig. It seems impossible in NetBSD. I could
not find any information about that, and man page does not specify
it either. Thanks in advance for your response.

No, you can't assign an IP address to a bridge in NetBSD.
Just assign the IP to one of the interfaces member of the bridge,
it will have the same effect as assigning the IP to the bridge itself
on linux.

[Robert Elz]

Date: Mon, 30 Aug 2010 12:38:51 +0200
From: Manuel Bouyer <***@antioche.eu.org>
Message-ID: <***@asim.lip6.fr>

| No, you can't assign an IP address to a bridge in NetBSD.
| Just assign the IP to one of the interfaces member of the bridge,

Is there a good reason it is done this way, or is this just one of those
things that would be better fixed, but no-one has considered important
enough to do anything about (yet at least) ?

I ask because it always seemed backwards to me - the bridge ouught to be
the "higher level" interface, with the underlying hardware being just the
components used to build it - kind of like we build a raidframe "device"
out of real hardware (or anything that looks like real hardware).

The way bridges are configured is kind of equivalent to building a raid5
out of wd0a wd1a and wd2a and then saying "you can't mount a filesystem from
the raid5 device, just mount it one of the underlying hardware devices,
say wd0a, and everything just works" Fortunately, that is not how raidframe
works, and (IMO) it isn't how bridges should work either.

In particular, with the current scheme, if I'm bridging (say) 3 interfaces,
and I want to remove one, and add a different one, the steps to do that
vary wildly depending upon whether the one I need to remove happens to be
the blessed one that has had the address assigned to it. That's poor.

kre


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

[Manuel Bouyer]

Post by Robert Elz
Date: Mon, 30 Aug 2010 12:38:51 +0200
| No, you can't assign an IP address to a bridge in NetBSD.
| Just assign the IP to one of the interfaces member of the bridge,
Is there a good reason it is done this way, or is this just one of those
things that would be better fixed, but no-one has considered important
enough to do anything about (yet at least) ?
I ask because it always seemed backwards to me - the bridge ouught to be
the "higher level" interface, with the underlying hardware being just the
components used to build it - kind of like we build a raidframe "device"
out of real hardware (or anything that looks like real hardware).

To me is looks the right way to do it: a bridge is not a host interface,
it's just a tool connecting host interfaces.
I'm not sure what we'd gain by turning it in a host interface (not mentioning
administrative issues like e.g. what ethernet address should be used
by the bridge as a host interface ?)

[der Mouse]

Post by Robert Elz
I ask because it always seemed backwards to me - the bridge ouught
to be the "higher level" interface,

Actually, I would say the bridge ought not to be an interface at all.
It's an in-host implementation of what would be done externally with a
switch, and they aren't interfaces. (Some (real-hardware) switches can
reasonably be said to have addresses, but it's not the switch itself
that has the address; it's the management computer housed in the same
box that has the address.)

I'm not sure why bridges were implemented as interfaces in NetBSD.
Convenience of some sort, I suppose.

/~\ 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

[David Young]

Post by der Mouse

Post by Robert Elz
I ask because it always seemed backwards to me - the bridge ouught
to be the "higher level" interface,

Actually, I would say the bridge ought not to be an interface at all.
It's an in-host implementation of what would be done externally with a
switch, and they aren't interfaces. (Some (real-hardware) switches can
reasonably be said to have addresses, but it's not the switch itself
that has the address; it's the management computer housed in the same
box that has the address.)
I'm not sure why bridges were implemented as interfaces in NetBSD.
Convenience of some sort, I suppose.

der Mouse is right, bridges should never have been an interface at all.
Each bridge should be a routing domain, and IEEE-802 interfaces should
be bridged together by adding them to the same domain.

Adding IP addresses to bridges is a step in the wrong direction.

The way that protocols and pseudo-interfaces like IP, AppleTalk, agr(4),
bridge(4), pppoe(4), and vlan(4) hook (more like hijack) ether_input()
and ether_output() leads to bugs and awkward workarounds, and it defeats
modularity. We should decompose ethernet (pseudo-)interfaces into a few
layers with well-defined APIs in between.

Dave

[Mihai Chelaru]

Post by Robert Elz
In particular, with the current scheme, if I'm bridging (say) 3 interfaces,
and I want to remove one, and add a different one, the steps to do that
vary wildly depending upon whether the one I need to remove happens to be
the blessed one that has had the address assigned to it. That's poor.

Add a tap interface to bridge and set the needed address on tap.


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

[Michael Richardson]

Post by Robert Elz
I ask because it always seemed backwards to me - the bridge
ouught to be the "higher level" interface,

der> Actually, I would say the bridge ought not to be an interface
der> at all. It's an in-host implementation of what would be done
der> externally with a switch, and they aren't interfaces. (Some
der> (real-hardware) switches can reasonably be said to have
der> addresses, but it's not the switch itself that has the address;
der> it's the management computer housed in the same box that has
der> the address.)

der> I'm not sure why bridges were implemented as interfaces in
der> NetBSD. Convenience of some sort, I suppose.

Well, we need some name for the plug on the side of the computer.

I would argue that it's not interfaces/bridges that is the problem, it's
the fact that "struct ifnet" is associated with an "interface", rather
than with a network (broadcast/ppp) domain (for which, we do not have
any names).
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video

then sign the petition.



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

[Michael Richardson]

Post by Lukasz Wojcik
I'm looking for the answer for a question, if it is allowed
somehow to assign an IP address to the virtual bridge interface ?
As far as i know it is possible in Linux. I believe it can also
be done in FreeBSD using just ifconfig. It seems impossible in
NetBSD. I could not find any information about that, and man page
does not specify it either. Thanks in advance for your response.

Manuel> No, you can't assign an IP address to a bridge in NetBSD.
Manuel> Just assign the IP to one of the interfaces member of the
Manuel> bridge, it will have the same effect as assigning the IP to
Manuel> the bridge itself on linux.

Or, to put it another way, Linux has to assign the IP to the bridge
device because the bridge code hijacks the normal packet processing from
the (physical) interface, so packets can never get in via the physical
interface. But, if the interface has an IP, then the routing code is
confused for outgoing packets, and basically nothing works.

This is often pathological for IPv6 on Linux, because the interface will
autoconfigure based upon RAs, and thus you are hosed without even
starting. Turning off ra_accept is hard on a lot of systems, because
there is no ra_accept until the ipv6 module loads, at which point it's
too late to turn it off if your interfaces are already "up".
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video http://youtu.be/kzx1ycLXQSE
then sign the petition.


--
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, 30 Aug 2010 19:36:23 -0400
From: Michael Richardson <***@sandelman.ca>
Message-ID: <***@marajade.sandelman.ca>

| I would argue that it's not interfaces/bridges that is the problem, it's
| the fact that "struct ifnet" is associated with an "interface", rather
| than with a network (broadcast/ppp) domain (for which, we do not have
| any names).

Well, that was a useful (to me anyway) short discussion, and clarifies
things a little - but this from Michael clarifies my issue mostly I think,
and I agree with that (but had never before considered it that way).

kre


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

[der Mouse]

Post by Michael Richardson
I would argue that it's not interfaces/bridges that is the problem,
it's the fact that "struct ifnet" is associated with an "interface",
rather than with a network (broadcast/ppp) domain (for which, we do
not have any names).

Perhaps I've just succumbed to the downside of Sapir-Whorf here, but
I'm not sure what this is talking about.

Could you give a concrete example?

/~\ 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

[Michael Richardson]

Post by Michael Richardson
I would argue that it's not interfaces/bridges that is the
problem, it's the fact that "struct ifnet" is associated with an
"interface", rather than with a network (broadcast/ppp) domain
(for which, we do not have any names).

der> Perhaps I've just succumbed to the downside of Sapir-Whorf
der> here, but I'm not sure what this is talking about.

der> Could you give a concrete example?

There are two kinds of things, which we call "interface", which are
connected together by history more than planning:

a) the connector on the computer (the "port")
b) the set of protocol things like the list of addresses, and the like.

I know that FreeBSD changed some of this with their netgraph stuff, and
this is related, but perhaps not exactly the same.

Here are three examples.
1) the desire to tcpdump on an interface without having any
addresses/protocols configured.
(related is IPv4 or IPv6, but not both)

Here you want a port, but no "ifnet" goo.

2) the desire to configure a bridge between two ports without
having IP connected.

Here you want two ports, and a special "ifnet" goo that implements
a learning bridge (or maybe, not). The resulting "thing" could
itself be a port (or you could include a virtual port in the
bridge), on which you can attach more things, such as "ifnet" goo.

3) the desire to bond two interfaces together, for 802 trunking
purposes, for instance.

In this case, you might want to associate "ifnet" goo with *TWO*
ports, with some rules as to how you load balance.

4) the desire to create new ports based upon vlan tags, some of
which you might want to attach "ifnet" goo, while others you
might want to "bridge" to something else (domU, another, untagged
port).

In this case, you want to associate "vlan" goo with the port,
and the vlan goo creates a bunch of new network domains (ports),
on which you can do things.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video http://youtu.be/kzx1ycLXQSE
then sign the petition.




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

[Brian A. Seklecki \(CFI NOC\)]

Post by Manuel Bouyer
ou can't assign an IP address to a bridge in NetBSD.
Just assign the IP to one of the interfaces member of the bridge

I'm way late to the conversation but I'd advocate for a
layer-3 capable bridge(4) interface, even if its a tap(4)-like
interface as suggested.

This can create confusion with subsystems like pf/ipf,
tcpdump. Cisco makes this really easy with BVI and VLAN
interfaces (depending on if its a layer2, layer3, or hybrid
IOS image)



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