Een statische route kan na een NetworkManager-upgrade verdwijnen wanneer de route deel uitmaakte van een profiel of configuratiepad dat niet langer de actieve verbinding is.
Op een ZimaSpace of Linux-thuisserver kan een route naar een IoT-VLAN, back-upsubnet of secundaire router handmatig zijn toegevoegd met ip route, zijn opgeslagen in een oud verbindingsprofiel of zijn gekoppeld aan een profiel dat NetworkManager na een upgrade vervangt. De juiste test vergelijkt de actieve route met het actieve persistente profiel, in plaats van de opdracht na elke herstart opnieuw uit te voeren.
Controleer of de route ooit persistent was
Vergelijk een route die met ip route is toegevoegd met het NetworkManager-verbindingsprofiel dat deze route opnieuw zou moeten aanmaken.
Een gerichte praktische networkmanager-gids over persistente statische routes horen in het verbindingsprofiel helpt deze mogelijkheid te isoleren, omdat de gids hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Als de route alleen in de kernel-routingtabel bestaat, verplaats deze dan naar het beheerde profiel voordat je de upgrade de schuld geeft.
Controleer profielwijzigingen die door de upgrade zijn veroorzaakt
Vergelijk profielnamen, UUID's, de status van autoconnect en route-items vóór en na de pakketupgrade.
Een gericht artikel over probleemoplossing rond statische routes kunnen verdwijnen wanneer de NetworkManager-status verandert helpt deze mogelijkheid te isoleren, omdat het hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Herstel de route in het actieve persistente profiel en bewaar een kopie van het vorige profiel ter vergelijking.
Houd er rekening mee dat NetworkManager profielgericht werkt
Een interface kan meerdere opgeslagen profielen hebben, maar alleen het geactiveerde profiel draagt zijn route-instellingen bij.
Een gerichte engineeringblog over NetworkManager over NetworkManager-configuratie draait om verbindingsprofielen helpt deze mogelijkheid te isoleren, omdat de blog hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Identificeer het actieve profiel aan de hand van de UUID in plaats van een willekeurige bekende bestandsnaam te bewerken.
Controleer de routingtabel en beleidsregels samen
Een route kan nog steeds in een niet-hoofdtabel bestaan, terwijl de regel die deze tabel selecteerde is gewijzigd.
Een gerichte uitleg over Linux-routing op beleidsrouting gebruikt zowel tabellen als regels helpt deze mogelijkheid te isoleren, omdat de uitleg hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Geef ip rule en elke relevante tabel weer voordat je een dubbele route aan main toevoegt.
Controleer of routemetrieken de voorkeursroute hebben gewijzigd
Wanneer twee routes dezelfde bestemming omvatten, kan de route met de laagste effectieve metriek of de meest specifieke route het verwachte pad vervangen.
Een gerichte Linux-netwerktutorial over routemetrieken bepalen welk pad wordt gekozen helpt deze mogelijkheid te isoleren, omdat de tutorial hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Vergelijk het bestemmingsprefix, de metriek en de interface na de update. Ga niet alleen vanwege het gebruik van een andere route ervan uit dat de oorspronkelijke route is verwijderd.
Houd de netwerkconfiguratie van de server bij één beheerder
Het combineren van verouderde scripts, handmatige opdrachten, Netplan en NetworkManager-profielen maakt het waarschijnlijker dat upgrades conflicterend eigenaarschap aan het licht brengen.
Een gerichte praktische Linux-netwerkgids over één NetworkManager-profiel moet het serverpad beheren helpt deze mogelijkheid te isoleren, omdat de gids hetzelfde deelprobleem behandelt in plaats van alleen het onderliggende protocol te definiëren.
Standaardiseer de route in één beheerd profiel, start de server tweemaal opnieuw op en controleer telkens of dezelfde route en metriek terugkeren.
Test het exacte pad naar de thuisserver opnieuw
Herhaal na het wijzigen van één variabele dezelfde NAS- of self-hosted-workflow vanaf dezelfde client, in plaats van over te schakelen naar een andere test die mogelijk een ander pad gebruikt.
De gerelateerde ZimaSpace-gids over het aangrenzende netwerkpad naar de thuisserver helpt de uiteindelijke verificatie gekoppeld te houden aan dezelfde self-hosted-omgeving.
De oplossing is pas compleet wanneer het oorspronkelijke symptoom opgelost blijft na opnieuw verbinden, het herstarten van de service en een tweede gecontroleerde overdracht of aanvraag.
Veelgestelde vragen
Waarom werkt ip route add tot het opnieuw opstarten?
De opdracht wijzigt de actieve kernel-routingtabel, maar maakt niet automatisch persistente NetworkManager-configuratie aan.
Kan de route nog bestaan, maar de verkeerde tabel gebruiken?
Ja. Beleidsrouting kan routes in alternatieve tabellen plaatsen waarvoor bijbehorende regels nodig zijn.
Moet ik verbindingsbestanden na een upgrade handmatig bewerken?
Gebruik bij voorkeur nmcli of de door het platform ondersteunde beheerder, tenzij je een gecontroleerde reden hebt om keyfiles rechtstreeks te beheren.
Ondersteuning & Tips
Meer om te lezen

Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...

Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.

Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...

