Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #176319 > unrolled thread

hotpluggable member of a bridge

Back to article view | Back to linux.debian.user

Contents

  hotpluggable member of a bridge Stefan Monnier <monnier@iro.umontreal.ca> - 2017-01-05 04:40 +0100
    Re: hotpluggable member of a bridge Nicolas George <george@nsup.org> - 2017-01-05 10:10 +0100
      Re: hotpluggable member of a bridge <tomas@tuxteam.de> - 2017-01-05 10:30 +0100
        Re: hotpluggable member of a bridge Michael Biebl <biebl@debian.org> - 2017-01-05 16:30 +0100
          Re: hotpluggable member of a bridge Sven Hartge <sven@svenhartge.de> - 2017-01-06 03:00 +0100
            Re: hotpluggable member of a bridge <tomas@tuxteam.de> - 2017-01-06 09:40 +0100
      Re: hotpluggable member of a bridge Stefan Monnier <monnier@iro.umontreal.ca> - 2017-01-05 16:30 +0100
        Re: hotpluggable member of a bridge Nicolas George <george@nsup.org> - 2017-01-05 16:40 +0100
          Re: hotpluggable member of a bridge Stefan Monnier <monnier@IRO.UMontreal.CA> - 2017-01-05 18:30 +0100
          Re: Congratulations Danielle , Your Roof is Covered - FREE!GYfb Danielle Gregory <danielle.k.gregory@gmail.com> - 2017-01-05 22:10 +0100
          Re: Congratulations Aileen , Your Roof is Covered - FREE!PHYi tazzygirl tazzygirl <saratazmtz77@gmail.com> - 2017-01-05 22:10 +0100
          RE: Congratulations Emmanuel , Your Roof is Covered - FREE!44OO Jennyetta Washington <manolofimbres@gmail.com> - 2017-01-05 22:20 +0100
    Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-05 17:10 +0100
      Re: hotpluggable member of a bridge Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-01-05 17:20 +0100
        Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-05 17:40 +0100
          Re: hotpluggable member of a bridge Joshua Schaeffer <jschaeffer0922@gmail.com> - 2017-01-05 18:10 +0100
          Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-05 22:20 +0100
            Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-05 22:30 +0100
            Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-05 22:40 +0100
              Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-08 16:50 +0100
                Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-08 17:20 +0100
                  Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-08 18:00 +0100
      Re: hotpluggable member of a bridge Stefan Monnier <monnier@iro.umontreal.ca> - 2017-01-06 02:20 +0100
        Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-06 12:40 +0100
          Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-06 13:20 +0100
            Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-08 17:00 +0100
              Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-08 17:20 +0100
                Re: hotpluggable member of a bridge Reco <recoverym4n@gmail.com> - 2017-01-08 17:30 +0100
                Re: hotpluggable member of a bridge Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-01-08 17:30 +0100
          Re: hotpluggable member of a bridge Stefan Monnier <monnier@iro.umontreal.ca> - 2017-01-06 22:50 +0100
    Re: hotpluggable member of a bridge Jonathan Dowland <jmtd@debian.org> - 2017-01-06 18:20 +0100

Page 1 of 2  [1] 2  Next page →

#176319 — hotpluggable member of a bridge

I have a bridge interface `br0` which usually contains jut `eth0` but
occasionally also needs to contain `usb0`, which is an ethernet-dongle
kind of thing.

How do I setup /etc/network/interfaces for that?

Currently, I just setup everything "manually": `br0` is setup `static`,
and `usb0` is setup as `manual` with post-up scripts that add it to
the bridge.

Is there something better?  Like a predefined way to just say that when
`usb0` appears, it should be added to `br0` (and ideally, this would
also `ifup` the `br0` interface if it's not up yet).


        Stefan

[toc] | [next] | [standalone]

#176325

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 15 nivôse, an CCXXV, Stefan Monnier a écrit :
> Is there something better?  Like a predefined way to just say that when
> `usb0` appears, it should be added to `br0` (and ideally, this would
> also `ifup` the `br0` interface if it's not up yet).

Not with /etc/network/interfaces and ifupdown, but udev can do all that.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#176326

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 05, 2017 at 10:07:59AM +0100, Nicolas George wrote:
> Le quintidi 15 nivôse, an CCXXV, Stefan Monnier a écrit :
> > Is there something better?  Like a predefined way to just say that when
> > `usb0` appears, it should be added to `br0` (and ideally, this would
> > also `ifup` the `br0` interface if it's not up yet).
> 
> Not with /etc/network/interfaces and ifupdown, but udev can do all that.

I always thought this is a division of labor between udev (generating
a "hotplug event", like "eth0 link went just up" and ifupdown, declaring
what has to happen (cf. the "allow-hotplug" directive).

But I must admit I never looked to deeply into that to be authoritative.
The docs [1] seem to suggest that, though.

Of course, udev would be involved for other network management systems
too, like NM: ideally, udev just dispatches and normalizes kernel events
and delegates to specialized subsystems. In a pinch you can just sneak
a complete shell script in an udev rule (and I'm guilty of having done
such a thing [2]), but doing this as "system architecture" might lead to
madness :-)

[1] https://www.debian.org/doc/manuals/debian-reference/ch05.en.html
[2] Once, for a customer: inserting the right storage medium (with
   the right UUID) triggered a system backup.

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlhuEdwACgkQBcgs9XrR2kZtowCfb0Glm/fJD9ByArT9nkGMmh4L
7NkAn2L0r4w7NeYa4E7PgK1BguWM7oZK
=VqAG
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#176329

[Multipart message — attachments visible in raw view] — view raw

Am 05.01.2017 um 10:29 schrieb tomas@tuxteam.de:
> and delegates to specialized subsystems. In a pinch you can just sneak
> a complete shell script in an udev rule (and I'm guilty of having done
> such a thing [2]), but doing this as "system architecture" might lead to
> madness :-)

> [2] Once, for a customer: inserting the right storage medium (with
>    the right UUID) triggered a system backup.

Please don't do that. udev is a not a service manager and starting (long
running) tasks from a udev rule is bad.
See also the udev man page:

    Starting daemons or other long-running processes is not appropriate
    for udev; the forked processes, detached or not, will be
    unconditionally killed after the event handling has finished.

If you want to trigger the start of a service via udev, tag the device
with "systemd" and use SYSTEMD_WANTS [1] via a custom udev rule, like

<your matches>,TAG+="systemd",ENV{SYSTEMD_WANTS}="foo.service"



Regards,
Michael

[1]
https://www.freedesktop.org/software/systemd/man/systemd.device.html#SYSTEMD_WANTS=

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#176352

Michael Biebl <biebl@debian.org> wrote:

>> [2] Once, for a customer: inserting the right storage medium (with
>>    the right UUID) triggered a system backup.

> Please don't do that. udev is a not a service manager and starting (long
> running) tasks from a udev rule is bad.

I wish someone would clue in Dell into that.

> See also the udev man page:

>     Starting daemons or other long-running processes is not appropriate
>     for udev; the forked processes, detached or not, will be
>     unconditionally killed after the event handling has finished.

Dell includes a udev-rule in its ISM-Packages for iDRAC like this:

,----
| # Dell USBNIC Device
| SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="a102", ATTR{manufacturer}=="Dell(TM)", ACTION=="add", RUN+="/etc/init.d/dcismeng start &"
`----

The idea is to start the iSM-Daemon once the idrac-usb-network device is
detected. But because of the problem you mention this fails horribly and
causes a 30 second delay during boot if used with systemd.

Urgh.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#176359

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jan 06, 2017 at 02:47:32AM +0100, Sven Hartge wrote:
> Michael Biebl <biebl@debian.org> wrote:
> 
> >> [2] Once, for a customer: inserting the right storage medium (with
> >>    the right UUID) triggered a system backup.
> 
> > Please don't do that. udev is a not a service manager and starting (long
> > running) tasks from a udev rule is bad.

See below.

> I wish someone would clue in Dell into that.
> 
> > See also the udev man page:
> 
> >     Starting daemons or other long-running processes is not appropriate
> >     for udev; the forked processes, detached or not, will be
> >     unconditionally killed after the event handling has finished.
> 
> Dell includes a udev-rule in its ISM-Packages for iDRAC like this:

Well, yeah. I simplified. The usual machinery to make sure the thing isn't
running already and to sneak out of the process group applies: this ain't
really new stuff in the Unix world, after all.

> 
> ,----
> | # Dell USBNIC Device
> | SUBSYSTEM=="usb", ATTR{idVendor}=="413c", ATTR{idProduct}=="a102", ATTR{manufacturer}=="Dell(TM)", ACTION=="add", RUN+="/etc/init.d/dcismeng start &"
> `----
> 
> The idea is to start the iSM-Daemon once the idrac-usb-network device is
> detected. But because of the problem you mention this fails horribly and
> causes a 30 second delay during boot if used with systemd.

Had they written the "...start" as they should have, they wouldn't need
this funny "&" at the end anyway, right?

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlhvV30ACgkQBcgs9XrR2kbqmwCfYq0Jyd/S/JpywAasqQrTkneI
wWgAnAm0GOzdTIYUW0FOWD9MahrDGXu/
=6MJ7
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#176328

>> Is there something better?  Like a predefined way to just say that when
>> `usb0` appears, it should be added to `br0` (and ideally, this would
>> also `ifup` the `br0` interface if it's not up yet).
> Not with /etc/network/interfaces and ifupdown, but udev can do all that.

Interesting.  Any hint how?


        Stefan

[toc] | [prev] | [next] | [standalone]

#176330

[Multipart message — attachments visible in raw view] — view raw

Le sextidi 16 nivôse, an CCXXV, Stefan Monnier a écrit :
> Interesting.  Any hint how?

It would be too long to explain here, but this page seems to cover the
basics of what you need:

http://packetpushers.net/udev/

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#176337

>> Interesting.  Any hint how?
> It would be too long to explain here, but this page seems to cover the
> basics of what you need:
> http://packetpushers.net/udev/

I don't see any mechanism in there that will bring up an interface or
add it to a bridge, nor bring up the bridge.

As I said, I already have something working using `manual`.  It looks
like:

    allow-hotplug usb0
    iface usb0 inet manual
            post-up brctl addif br0 $IFACE; ifconfig $IFACE up
            pre-down ifconfig $IFACE down; brctl delif br0 $IFACE

and I think I can fairly easily spice it up to bring `br0` up on demand
(tho creating `br0` eagerly is fine as well.  The "ondemand" part is
mostly about the need to re-start the DHCP client when `usb0` gets added
to `br0`).

But what I'm looking for is a way to do that without writing it as
a script (IOW a more declarative way to do it).


        Stefan

[toc] | [prev] | [next] | [standalone]

#176344 — Re: Congratulations Danielle , Your Roof is Covered - FREE!GYfb

[Multipart message — attachments visible in raw view] — view raw

stop

On Jan 5, 2017 1:45 PM, "Nicolas George" <george@nsup.org> wrote:

> sdeg CONGRATUIATlON__Danielle ,
>
> _The_Home_Warranty_Limited_time_event_
> _Never_pay_for_covered_home_repairs_again!_
>
> _Click_Here_
>
> t 0 u n 5 u b5
> optout
>
>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/links.php?u=10_2D19TS_761_1K3U9_8JFU-KV.1NRV>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/links.htm?n=10_2D19TS_761_1K3U9_8JFU-KV.1NRV>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/delete.asp?r=10_2D19TS_761_1K3U9_8JFU-KV.1NRV>
> asdf
> @#%@#%$#^%#$^#$
>
>

[toc] | [prev] | [next] | [standalone]

#176345 — Re: Congratulations Aileen , Your Roof is Covered - FREE!PHYi

[Multipart message — attachments visible in raw view] — view raw

You got the wrong person

On Jan 5, 2017 12:45 PM, "Nicolas George" <george@nsup.org> wrote:

> sdeg CONGRATUIATlON__Aileen ,
>
> _The_Home_Warranty_Limited_time_event_
> _Never_pay_for_covered_home_repairs_again!_
>
> _Click_Here_
>
> t 0 u n 5 u b5
> optout
>
>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/questions.html?u=10_N6C3M_761_1JTQF_8JFU-KV.1NRV>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/article.html?n=10_N6C3M_761_1JTQF_8JFU-KV.1NRV>
> <http://www.etracker.de/lnkcnt.php?et=lgKQQx&url=http://macrotry.com/about.php?r=10_N6C3M_761_1JTQF_8JFU-KV.1NRV>
> asdf
> @#%@#%$#^%#$^#$
>
>

[toc] | [prev] | [next] | [standalone]

#176346 — RE: Congratulations Emmanuel , Your Roof is Covered - FREE!44OO

[Multipart message — attachments visible in raw view] — view raw

Do not email me with your unwanted bullshit!!!

-----Original Message-----
From: "Nicolas George" <george@nsup.org>
Sent: ‎1/‎5/‎2017 1:45 PM
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: "debian-user@lists.debian.org" <debian-user@lists.debian.org>
Subject: Congratulations Emmanuel , Your Roof is Covered - FREE!44OO

sdeg 
CONGRATUIATlON__Emmanuel , 


_The_Home_Warranty_Limited_time_event_


_Never_pay_for_covered_home_repairs_again!_



_Click_Here_


t 0 u n 5 u b5 
optout

[toc] | [prev] | [next] | [standalone]

#176331

	Hi.

On Wed, 04 Jan 2017 22:34:16 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I have a bridge interface `br0` which usually contains jut `eth0` but
> occasionally also needs to contain `usb0`, which is an ethernet-dongle
> kind of thing.
> 
> How do I setup /etc/network/interfaces for that?
> 
> Currently, I just setup everything "manually": `br0` is setup `static`,
> and `usb0` is setup as `manual` with post-up scripts that add it to
> the bridge.
> 
> Is there something better?  Like a predefined way to just say that when
> `usb0` appears, it should be added to `br0` (and ideally, this would
> also `ifup` the `br0` interface if it's not up yet).

Conventional Linux bridge cannot do that. All those interfaces(5)
stanzas are merely a wrapper to 'brctl addbr' and 'brctl addif', which
are invoked by ifupdown.

But, it all changes if you replace conventional bridge with
openvswitch, which *can* add new interfaces (ports as they call it) to
its own bridges dynamically *and* it can be configured via interfaces(5).

A sample configuration would be:

allow-ovs br0
iface br0 inet4 static
	address …
	netmask …
	ovs_type OVSBridge

allow-br0 eth0
iface eth0 inet6 auto
	ovs_type OVSPort
	ovs_bridge br0

allow-hotplug usb0
iface usb0 inet6 auto
	ovs_type OVSPort
	ovs_bridge br0

Reco

[toc] | [prev] | [next] | [standalone]

#176332

[Multipart message — attachments visible in raw view] — view raw

>
>
> A sample configuration would be:
>
> allow-ovs br0
> iface br0 inet4 static
>         address …
>         netmask …
>         ovs_type OVSBridge
>
> allow-br0 eth0
> iface eth0 inet6 auto
>         ovs_type OVSPort
>         ovs_bridge br0
>
> allow-hotplug usb0
> iface usb0 inet6 auto
>         ovs_type OVSPort
>         ovs_bridge br0
>
> Reco
>
>
Pardon my ignorance, can you explain why you set an IPv4 address on your
bridge and an IPv6 address on your bridge interfaces? I've never seen this
before and would like to know what this accomplishes. Perhaps its a typo as
I thought IPv4 was just set with "inet" and IPv6 was set with "inet6".

Thanks,
Joshua Schaeffer

[toc] | [prev] | [next] | [standalone]

#176333

	Hi.

On Thu, 5 Jan 2017 09:19:35 -0700
Joshua Schaeffer <jschaeffer0922@gmail.com> wrote:

> >
> >
> > A sample configuration would be:
> >
> > allow-ovs br0
> > iface br0 inet4 static
> >         address …
> >         netmask …
> >         ovs_type OVSBridge
> >
> > allow-br0 eth0
> > iface eth0 inet6 auto
> >         ovs_type OVSPort
> >         ovs_bridge br0
> >
> > allow-hotplug usb0
> > iface usb0 inet6 auto
> >         ovs_type OVSPort
> >         ovs_bridge br0
> >
> > Reco
> >
> >
> Pardon my ignorance, can you explain why you set an IPv4 address on your
> bridge and an IPv6 address on your bridge interfaces? I've never seen this
> before and would like to know what this accomplishes. Perhaps its a typo as
> I thought IPv4 was just set with "inet" and IPv6 was set with "inet6".

It's simple, although isn't obvious from this abridged example.
I need a single IPv4 for both interfaces, so I set it on a bridge.
I don't need distinct IPv4 on ports, so I don't set it there.

Bridged interfaces retain their MACs, so they would get different IPv6
ULAs, which are provided by radvd from the different host.
And I don't need these IPv6 either.

So, I can do:

allow-br0 eth0
iface eth0 inet manual
         ovs_type OVSPort
         ovs_bridge br0

And get myself all kinds of unneeded trouble, or I can do:

allow-br0 eth0
iface eth0 inet6 auto
	autoconf 0
	accept_ra 0
        ovs_type OVSPort
        ovs_bridge br0

Barring this IPv4/IPv6 difference, there should be no noticeable
outcome between 'inet manual' and 'inet6 auto'.

Reco

[toc] | [prev] | [next] | [standalone]

#176334

[Multipart message — attachments visible in raw view] — view raw

Interesting, thanks for the explanation.

On Thu, Jan 5, 2017 at 9:32 AM, Reco <recoverym4n@gmail.com> wrote:

>         Hi.
>
> On Thu, 5 Jan 2017 09:19:35 -0700
> Joshua Schaeffer <jschaeffer0922@gmail.com> wrote:
>
> > >
> > >
> > > A sample configuration would be:
> > >
> > > allow-ovs br0
> > > iface br0 inet4 static
> > >         address …
> > >         netmask …
> > >         ovs_type OVSBridge
> > >
> > > allow-br0 eth0
> > > iface eth0 inet6 auto
> > >         ovs_type OVSPort
> > >         ovs_bridge br0
> > >
> > > allow-hotplug usb0
> > > iface usb0 inet6 auto
> > >         ovs_type OVSPort
> > >         ovs_bridge br0
> > >
> > > Reco
> > >
> > >
> > Pardon my ignorance, can you explain why you set an IPv4 address on your
> > bridge and an IPv6 address on your bridge interfaces? I've never seen
> this
> > before and would like to know what this accomplishes. Perhaps its a typo
> as
> > I thought IPv4 was just set with "inet" and IPv6 was set with "inet6".
>
> It's simple, although isn't obvious from this abridged example.
> I need a single IPv4 for both interfaces, so I set it on a bridge.
> I don't need distinct IPv4 on ports, so I don't set it there.
>
> Bridged interfaces retain their MACs, so they would get different IPv6
> ULAs, which are provided by radvd from the different host.
> And I don't need these IPv6 either.
>
> So, I can do:
>
> allow-br0 eth0
> iface eth0 inet manual
>          ovs_type OVSPort
>          ovs_bridge br0
>
> And get myself all kinds of unneeded trouble, or I can do:
>
> allow-br0 eth0
> iface eth0 inet6 auto
>         autoconf 0
>         accept_ra 0
>         ovs_type OVSPort
>         ovs_bridge br0
>
> Barring this IPv4/IPv6 difference, there should be no noticeable
> outcome between 'inet manual' and 'inet6 auto'.
>
> Reco
>
>

[toc] | [prev] | [next] | [standalone]

#176347

Le 05/01/2017 à 17:32, Reco a écrit :
>
> Joshua Schaeffer <jschaeffer0922@gmail.com> wrote:
>>>
>>> A sample configuration would be:
>>>
>>> allow-ovs br0
>>> iface br0 inet4 static
>>>         address …
>>>         netmask …
>>>         ovs_type OVSBridge
>>>
>>> allow-br0 eth0
>>> iface eth0 inet6 auto
>>>         ovs_type OVSPort
>>>         ovs_bridge br0
>>>
>>> allow-hotplug usb0
>>> iface usb0 inet6 auto
>>>         ovs_type OVSPort
>>>         ovs_bridge br0
>>>
>> Pardon my ignorance, can you explain why you set an IPv4 address on your
>> bridge and an IPv6 address on your bridge interfaces?

I wondered the same.

> It's simple, although isn't obvious from this abridged example.

No it's not.

> I need a single IPv4 for both interfaces, so I set it on a bridge.
> I don't need distinct IPv4 on ports, so I don't set it there.

This has nothing to do with IPv6 config.

> Bridged interfaces retain their MACs, so they would get different IPv6
> ULAs, which are provided by radvd from the different host.

Not if they are bridged before they are brought UP or accept_ra/autoconf 
is disabled.

> And get myself all kinds of unneeded trouble, or I can do:
>
> allow-br0 eth0
> iface eth0 inet6 auto
> 	autoconf 0
> 	accept_ra 0
>         ovs_type OVSPort
>         ovs_bridge br0

Ok, THIS, provides the missing info from your previous post : disable 
autoconf and accept_ra.

But according to man interfaces(5), the inet6 "auto" method ignores the 
"autoconf" option. This option is specific to the "static" method.

[toc] | [prev] | [next] | [standalone]

#176348

Le 05/01/2017 à 22:17, Pascal Hambourg a écrit :
>
> But according to man interfaces(5), the inet6 "auto" method ignores the
> "autoconf" option. This option is specific to the "static" method.

And "dhcp".

[toc] | [prev] | [next] | [standalone]

#176349

	Hi.

On Thu, 5 Jan 2017 22:17:23 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> > Bridged interfaces retain their MACs, so they would get different IPv6
> > ULAs, which are provided by radvd from the different host.
> 
> Not if they are bridged before they are brought UP 

I'm not that familiar with openvswitch to make claims about the order
in which an interface brought up and bridged.

If you have such knowledge then feel free to share it with the list
please.

> or accept_ra/autoconf is disabled.

Disabling it is the whole point.


> > And get myself all kinds of unneeded trouble, or I can do:
> >
> > allow-br0 eth0
> > iface eth0 inet6 auto
> > 	autoconf 0
> > 	accept_ra 0
> >         ovs_type OVSPort
> >         ovs_bridge br0
> 
> Ok, THIS, provides the missing info from your previous post : disable 
> autoconf and accept_ra.
> 
> But according to man interfaces(5), the inet6 "auto" method ignores the 
> "autoconf" option. This option is specific to the "static" method.

Indeed. Thanks for the correction.

Reco

[toc] | [prev] | [next] | [standalone]

#176452

Le 05/01/2017 à 22:36, Reco a écrit :
>
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
>>> Bridged interfaces retain their MACs, so they would get different IPv6
>>> ULAs, which are provided by radvd from the different host.
>>
>> Not if they are bridged before they are brought UP
>
> I'm not that familiar with openvswitch to make claims about the order
> in which an interface brought up and bridged.
>
> If you have such knowledge then feel free to share it with the list
> please.

Actually I had in mind the behaviour of Linux bridge, not openvswitch. I 
have no knowledge nor experience with openvswitch. However, I can see 
that the openvswitch package adds a script in /etc/network/if-pre-up.d, 
so it is likely that the interface is bridged before it is brought up.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web