networkd meglepetések

Linux-haladó

Adott egy Debian Buster, több hálókártyával, hálókártyánként több vlannal, és esetenként vlan-onként több IP címmel.
Az egész a /etc/systemd/network -ben felkonfigurálva.

Időnként szeretnék ideiglenesen módosítani rajta, és használom a szokásos parancsokat:
ip addr add ...
ip route add ...

Szépen működnek is első ránézésre, de 1-2 nap után ezek a módosítások egyszerűen eltűnnek!
Gondolom, valami újra tölti az /etc/systemd/network alatti konfigokat. De miért, és mikor, és miért pont akkor? És hogy csináljak úgy változtatást, hogy azt csak én állítsam vissza?

Írjam bele mindig a konfigokba, aztán networkctl reload? Nincs valami "tisztább" módja?

  • 270 megtekintés

( godot v | 2021. 07. 21., sze – 11:39 )

Szerkesztve: 2021. 07. 21., sze – 11:44

Ha azt szeretnéd, hogy a systemd-networkd ne törölje az "idegen" "kézi" beállításokat akkor ezt meg kell adni a konfigban:

KeepConfiguration=yes

https://github.com/systemd/systemd/issues/13555

https://github.com/systemd/systemd/pull/12511

Meg kell fontolni a használatát mert elég érdekes dolgokat okozhat. A normális az, hogy ha beleírod a konfigba a módosításokat.

Csak ezt nem mindig lehet megtenni, pl HA szoftver maga kezeli az secondary IP címeket, vagy egy dinamikus routing démon pl a routokat. Mert a kézzel felvett routekat is törli a networkd rrload :(.

Egyébként nem jellemző, hogy csak úgy magától újratölse a konfigot a networkd periodikusan, annak valami oka van, pl nincs ilyenkor link up/down?

Ezen segít az

IgnoreCarrierLoss=true

paraméter, mivel sajnos a networkd törli az ip-ket az interfészről ha lemegy downba alapból.

Köszi, ez valószínűleg segíteni fog.

A fizikai interfészen tuti nem volt up/down, azt jelezte volna a switch.
A log-ban összesen ennyi van a networkd-ről az utóbbi napokra vonatkozóan. Kb. ekkor állt vissza a konfigokban szereplő beállításokra.


Jul 20 15:01:08 **** systemd[1]: systemd-networkd-wait-online.service: Succeeded.
Jul 20 15:01:08 **** systemd[1]: systemd-networkd.service: Succeeded.
Jul 20 15:01:08 **** systemd-networkd[32499]: br-88aa2d484995: Gained IPv6LL
Jul 20 15:01:08 **** systemd-networkd[32499]: tun0: Gained IPv6LL
Jul 20 15:01:08 **** systemd-networkd[32499]: enp4s0.503: Gained IPv6LL
Jul 20 15:01:08 **** systemd-networkd[32499]: enp4s0.500: Gained IPv6LL
Jul 20 15:01:08 **** systemd-networkd[32499]: enp4s0: Gained IPv6LL
Jul 20 15:01:08 **** systemd-networkd[32499]: Enumeration completed
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:08 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:20 **** systemd-networkd[32499]: enp4s0.503: Configured
Jul 20 15:01:20 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:01:20 **** systemd-networkd[32499]: enp4s0.500: Configured
Jul 20 15:01:20 **** systemd-networkd[32499]: enp4s0: Configured
Jul 20 15:01:20 **** systemd-networkd-wait-online[32503]: ignoring: lo
Jul 20 15:02:41 **** systemd-networkd[32499]: br-88aa2d484995: Lost carrier
Jul 20 15:02:42 **** systemd-networkd[32499]: br-88aa2d484995: Gained carrier
Jul 20 15:02:42 **** systemd-networkd[32499]: br-88aa2d484995: Lost carrier
Jul 20 15:02:42 **** systemd-networkd[32499]: br-88aa2d484995: Gained carrie

Nem tudom, számít-e bármit, a br-88aa.. az egyik docker konténerhez tartozik.

( miq | 2021. 10. 22., p – 22:20 )

Miután véglegessé váltak a dolgok, és az alábbi konfig fájlt használtam hónapok óta (/etc/systemd/network/enp4s0.200.network)

[Match]
Name=enp4s0.200

[Network]
DHCP=no
Address=xxx.xx.xx.6/24
Address=192.168.150.7/24
Address=172.17.13.7/24
Address=172.17.130.7/24
Address=172.17.156.7/24
Address=172.17.172.7/24
Gateway=xxx.xx.xx.254
DNS=xxx.xx.xx.1
Domains=xxxx.xxxx.xx

[Route]
Table=second
Gateway=xxx.xx.xx.240

[RoutingPolicyRule]
DestinationPort=4444
Table=second

Ez működöt is szépen, a "second" táblában létrehozta a kívánt default route-ot, és a 4444-es portra menő kéréseket arrafelé küldte el.
Egészen a tegnapi újraindításig, mióta:

$ ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

$ ip route show table second

$ ip route show table main
default via xxx.xx.xx.254 dev enp4s0.200 proto static
default via xxx.xx.xx.240 dev enp4s0.200 proto static
xxx.xx.xx.0/24 dev enp4s0.200 proto kernel scope link src xxx.xx.xx.6
172.17.13.0/24 dev enp4s0.200 proto kernel scope link src 172.17.13.7
172.17.130.0/24 dev enp4s0.200 proto kernel scope link src 172.17.130.7
...

Vagyis a "second" nevű tábla helyett a "main" táblához ad hozzá egy extra default route-ot!! 
Az routing policy meg szőrén szálán eltűnt.

Exra infó: A buster kernele helyett a backports-ból szedett 5.10-es kernelt használom, mert valami hardware-t nem kezelt le a busterben levő kernel.
De ez nem újdonság, már legalább egy éve backports-os kernel van rajta.