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


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

Re: networking.service fails

Started byDavid Wright <deblis@lionunicorn.co.uk>
First post2022-04-04 05:50 +0200
Last post2022-04-12 23:30 +0200
Articles 4 — 4 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: networking.service fails David Wright <deblis@lionunicorn.co.uk> - 2022-04-04 05:50 +0200
    Re: networking.service fails Greg Wooledge <greg@wooledge.org> - 2022-04-04 06:00 +0200
      Re: networking.service fails Reco <recoverym4n@enotuniq.net> - 2022-04-11 08:20 +0200
        Re: networking.service fails Dmitry Katsubo <dma_k@mail.ru> - 2022-04-12 23:30 +0200

#246900 — Re: networking.service fails

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2022-04-04 05:50 +0200
SubjectRe: networking.service fails
Message-ID<E8lT3-6jTo-1@gated-at.bofh.it>
On Mon 04 Apr 2022 at 02:38:39 (+0200), Dmitry Katsubo wrote:
> On 2021-02-17 14:21, Henning Follmann wrote:
> 
> > Are you using eth0, eth1?
> > Or are you using predictable network names?
> > https://wiki.debian.org/NetworkInterfaceNames
> Well, I use eth0/eth1 as I have renamed them from predictable network names via /etc/udev/rules.d/70-persistent-net.rules:
> 
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:e8:92:b7:77", KERNEL=="eth*", NAME="eth0"
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:20:53:44:58", KERNEL=="eth*", NAME="eth1"

That is a really bad idea. If you're going to rename interfaces
yourself, then choose different names from anything that's already
used or could potentially be used.

Cheers,
David.

[toc] | [next] | [standalone]


#246901

FromGreg Wooledge <greg@wooledge.org>
Date2022-04-04 06:00 +0200
Message-ID<E8m2J-6jWt-1@gated-at.bofh.it>
In reply to#246900
On Sun, Apr 03, 2022 at 10:48:31PM -0500, David Wright wrote:
> On Mon 04 Apr 2022 at 02:38:39 (+0200), Dmitry Katsubo wrote:
> > On 2021-02-17 14:21, Henning Follmann wrote:
> > 
> > > Are you using eth0, eth1?
> > > Or are you using predictable network names?
> > > https://wiki.debian.org/NetworkInterfaceNames
> > Well, I use eth0/eth1 as I have renamed them from predictable network names via /etc/udev/rules.d/70-persistent-net.rules:
> > 
> > ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:e8:92:b7:77", KERNEL=="eth*", NAME="eth0"
> > ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:20:53:44:58", KERNEL=="eth*", NAME="eth1"
> 
> That is a really bad idea. If you're going to rename interfaces
> yourself, then choose different names from anything that's already
> used or could potentially be used.

It's also worth pointing out that /etc/udev/rules.d/70-persistent-net.rules
was deprecated in buster (Debian 10).  According to the release notes,
it *may* work, or it may not.  Users were instructed to migrate away
from it.

It would not surprise me one bit if there's a race condition which causes
the renaming done by 70-persistent-net.rules to occur at the wrong time,
if it even happens at all.

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


#247186

FromReco <recoverym4n@enotuniq.net>
Date2022-04-11 08:20 +0200
Message-ID<EaVz3-7XXO-3@gated-at.bofh.it>
In reply to#246901
    Hi.

On Mon, Apr 11, 2022 at 01:48:35AM +0200, Dmitry Katsubo wrote:
> The configuration is trivial: it adds both eth0 eth1 to the bridge
> br0.
>
> === cut /etc/network/interfaces ===
> auto lo
> auto eth0
> auto eth1
>
> iface lo inet loopback
>
> auto br0
> iface br0 inet static
>         address 10.0.1.100
>         gateway 10.0.1.1
>         netmask 255.0.0.0
>         bridge_ports eth0 eth1
>         bridge_maxwait 60
> === cut ===

Good news - it explains "ifup: unknown interface eth0" messages.
Bad news - this /e/n/i is not valid.

The reason being - both eth0 and eth1 lack interface definitions, i.e.
have no "iface" stanzas.

If you absolutely need both eth0 and eth1 in the UP state by the time
you create and bring up br0 you should either:

1) Define both eth0 and eth1 in /e/n/i like this:

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto br0
iface br0 inet static
    address 10.0.1.100
    gateway 10.0.1.1
    netmask 255.0.0.0
    bridge_ports eth0 eth1
    bridge_maxwait 60

2) Use pre-up and post-down hooks for br0, and remove both "auto eth0"
and "auto eth1":

auto br0
iface br0 inet static
    address 10.0.1.100
    gateway 10.0.1.1
    netmask 255.0.0.0
    bridge_ports eth0 eth1
    bridge_maxwait 60
    pre-up /sbin/ip link set eth0 up
    pre-up /sbin/ip link set eth1 up
    post-down /sbin/ip link set eth0 down
    post-down /sbin/ip link set eth1 down

Reco

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


#247204

FromDmitry Katsubo <dma_k@mail.ru>
Date2022-04-12 23:30 +0200
Message-ID<Ebwff-8kic-3@gated-at.bofh.it>
In reply to#247186
On 2022-04-11 07:56, Reco wrote:
> Good news - it explains "ifup: unknown interface eth0" messages.
> Bad news - this /e/n/i is not valid.
> 
> The reason being - both eth0 and eth1 lack interface definitions, i.e.
> have no "iface" stanzas.
> 
> If you absolutely need both eth0 and eth1 in the UP state by the time
> you create and bring up br0 you should either:
> 
> 1) Define both eth0 and eth1 in /e/n/i like this:
> 
> auto eth0
> iface eth0 inet manual
> 
> auto eth1
> iface eth1 inet manual
> 
> auto br0
> iface br0 inet static
>     address 10.0.1.100
>     gateway 10.0.1.1
>     netmask 255.0.0.0
>     bridge_ports eth0 eth1
>     bridge_maxwait 60
> 
> 2) Use pre-up and post-down hooks for br0, and remove both "auto eth0"
> and "auto eth1":
> 
> auto br0
> iface br0 inet static
>     address 10.0.1.100
>     gateway 10.0.1.1
>     netmask 255.0.0.0
>     bridge_ports eth0 eth1
>     bridge_maxwait 60
>     pre-up /sbin/ip link set eth0 up
>     pre-up /sbin/ip link set eth1 up
>     post-down /sbin/ip link set eth0 down
>     post-down /sbin/ip link set eth1 down
> 
> Reco

Hooray, it worked! Thanks for pointing out the configuration error.
After fixing it everything worked like a charm. Would be very tricky
for me to locate the issue...

If the configuration is invalid, networking.service could probably
complain about that? I would be able then to resolve the issue myself.

Just for my record the reference to documentation:

https://wiki.debian.org/BridgeNetworkConnections#Configuring_bridging_in_.2Fetc.2Fnetwork.2Finterfaces

-- 
With best regards,
Dmitry

[toc] | [prev] | [standalone]


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


csiph-web