KUbuntu bridge "verliest" ip adres.

[Sandor_Clegane]

Hoi,

Ik heb een stom probleem, maar het begint nu wel een beetje irritant te worden en ik heb geen idee waar het aan kan liggen.

Ik heb een bridge op mijn machine aangemaakt voor KVM, dit heb ik gedaan met NMCLI omdat Kubuntu blijkbaar geen GUI heeft voor het aanmaken van een bridge in de NetworkManager, dit lijkt allemaal prima te werken. Via NMCLI een device aangemaakt en mijn fysieke netwerkkaart is de slave van deze, alles lijkt naar behoren te werken en mijn bridge heeft dan ook netjes een IP adres.

Ik heb een Windows VM en deze praat via deze bridge met het netwerk en dat gaat ook allemaal mooi ware het niet dat op een gegeven moment de bridge zijn ip adres lijkt te vergeten en mijn host dus niet meer met de buitenwereld praat. De Windows VM praat lekker door en heeft geen problemen.

De br0 interface is dan gewoon nog "UP" maar ik moet hem wel een nmcli con up br0 geven wil hij weer een ip adres krijgen, het probleem is dan dat mijn Windows VM een netwerk probleem heeft en ik het hele zwikkie moet rebooten wil het weer functioneren.

Enig idee waarom dit zou kunnen gebeuren?

Edit: normaal gebruik ik ifupdown en de interfaces file, maar ja progress enzo ( netplan ) en als ik dus de "oude" manier gebruik gaat mijn boot tijd van < 10 sec naar dik twee minuten.

[ Voor 7% gewijzigd door Sandor_Clegane op 27-03-2018 12:51 ]

[Lethalis]

Sandor_Clegane schreef op dinsdag 27 maart 2018 @ 12:50:
Edit: normaal gebruik ik ifupdown en de interfaces file, maar ja progress enzo ( netplan ) en als ik dus de "oude" manier gebruik gaat mijn boot tijd van < 10 sec naar dik twee minuten.

Vreemd, ik gebruik een bridge op mijn Ubuntu server en die heb ik gewoon met de interfaces file geconfigureerd. Boot time is ook hartstikke snel.

Dus ben erg benieuwd wat hij dan in die 2 minuten bij jou aan het doen is...

[update]
Aantal opties die ik overigens wel in gebruik heb:

auto br0
iface br0 inet dhcp
bridge_ports enp4s0
bridge_stp on
bridge_maxwait 0
bridge_fd 0

Dus heb destijds wel het e.e.a. moeten tweaken (voor KVM).

[ Voor 16% gewijzigd door Lethalis op 27-03-2018 16:21 ]

[Hero of Time]

Ik mis vooral de logentries waarin staat wat er met je netwerk gebeurt. Als je DHCP gebruikt, verliest het blijkbaar z'n lease. Welke reden zou het daarvoor hebben?

En met bovenstaande, het zou echt geen twee minuten moeten duren als je de 'oude' methode gebruikt. Want dat moet je wel gebruiken als je geen NM hebt.

[Sandor_Clegane]

Ik heb nog even met journalctl -u NetworkManager.service gekeken en daar lijkt het erop dat hij een DHCPREQUEST doet maar geen OFFER krijgt, wat vreemd is want de rest van het netwerk loopt prima. Mijn PFSense machine geeft DHCP uit en deze draait op een andere machine. Maar dan nog, DHCP zou dan gewoon met een steeds kleinere tijdswindow een aanvraag moeten doen lijkt me, en niet ineens de gehele configuratie maar vergeten.

Bij mij staan STP off, heb geen spanningtree, en forwarddelay op 0.

Om het te fiksen heb ik de bridge nu maar gewoon een vast ip adres gegeven. Het kan ook te maken hebben dat de machine uit suspend komt, maar zelfs dat lijkt me onwaarschijnlijk.

En voor zover de "oude'' methode, zou gauw als ik een bridge configureer op deze machine duurt het echt lang om te booten, zo lang zelfs dat ik dus maar met nmcli aan de slag ben gegaan.
Nou ja niet echt een bridge configureer, maar iets met ifupdown doe, blijkbaar bijten NetworkManager en ifupdown elkaar? Wat raar is want ik heb in de log Systemd nog zien checken of er een bestaande ifupdown omgeving was.

Misschien dat netplan dat lastig vindt? Daarin staat wel managed by NetworkManager en niet NetworkD. Ik moet zeggen dat het er niet overzichtelijker van wordt, ik vond de interfaces file redelijk vanzelfsrpekend.

Nu is alles weer vlot qua booten, maar dit is even funky. DHCP is best handig namelijk, en de rest loopt wel prima, de Windows VM krijgt een ip adres van dezelfde DHCP server.

Ik kan die maxwait nog wel eens proberen, er staat me zoiets bij dat ik die ook altijd in mijn interfaces file had staan op Ubuntu.

Dit is van mijn andere Ubuntu machine, deze heeft net een release-upgrade gehad van 17.04 naar 17.10 en hier wordt de interfaces file gebruikt:

code:

auto br0
iface br0 inet static
        address 192.168.1.10
        network 192.168.0.0
        netmask 255.255.255.0
        gateway 192.168.1.1
        broadcast 192.168.0.255
        dns-nameservers 192.168.1.8
        dns-search domain.bla.com
        bridge_ports eno1
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

Dus dat zou een extra nmcli con mod br0 moeten zijn. Best grappig dat nmcli, doet me beetje denken aan Solaris.

[ Voor 42% gewijzigd door Sandor_Clegane op 27-03-2018 20:12 ]

[Hero of Time]

NM negeert interfaces die in /etc/network/interfaces staan gedefinieerd. Als je met ifupdown gaat werken, neemt NM het alsnog over als het kan. Dat je boot tijd vergroot als je met ifupdown gaat werken is dus niet zo gek, NM bemoeit zich met zaken waar het eigenlijk vanaf moet blijven waardoor network.target en network-online.target pas veel later bereikt worden (die eerste rondt pas af, als alle services klaar zijn met hun werk, ifupdown eerst, maar NM zit ook nog te wachten om wat te kunnen doen).

Voor STP op je bridge, kijk even in de documentatie. Want misschien wil je juist wel Spanning Tree Protocol aan hebben. Je werkt immers met VMs in je bridge.

[Sandor_Clegane]

Hero of Time schreef op dinsdag 27 maart 2018 @ 20:44:

Voor STP op je bridge, kijk even in de documentatie. Want misschien wil je juist wel Spanning Tree Protocol aan hebben. Je werkt immers met VMs in je bridge.

Ok, zal wel iets mafs zijn in mijn configuratie dan.

Maar waarom zou ik STP willen gebruiken? Ik heb geen loops voor zover ik weet en mijn switch snapt het ook niet.

[Hero of Time]

Daarom ook even de documentatie lezen over bridge in Linux en de STP optie.

[Sandor_Clegane]

Hero of Time schreef op dinsdag 27 maart 2018 @ 21:10:
Daarom ook even de documentatie lezen over bridge in Linux en de STP optie.

Help me eens op weg, ik snap niet waar je heen wilt.

[ Voor 65% gewijzigd door Sandor_Clegane op 27-03-2018 21:20 ]

[Hero of Time]

STP is een switching protocol. Je draait VMs op je host. Met een bridge is je PC in feite een switch voor je host en VMs. Het kan daardoor beter zijn door STP aan te hebben op je bridge. Maar, zoals je zelf al zei, de fysieke switch waar je PC aan hangt ondersteunt blijkbaar geen STP. Daarom: lees even de documentatie om te zien of het echt zinvol is om STP aan of uit te hebben. Iets uitzetten omdat de rest van je netwerk het niet ondersteund is niet direct een goede reden.

[Sandor_Clegane]

Hero of Time schreef op dinsdag 27 maart 2018 @ 21:42:
STP is een switching protocol. Je draait VMs op je host. Met een bridge is je PC in feite een switch voor je host en VMs. Het kan daardoor beter zijn door STP aan te hebben op je bridge. Maar, zoals je zelf al zei, de fysieke switch waar je PC aan hangt ondersteunt blijkbaar geen STP. Daarom: lees even de documentatie om te zien of het echt zinvol is om STP aan of uit te hebben. Iets uitzetten omdat de rest van je netwerk het niet ondersteund is niet direct een goede reden.

Oh, ik dacht dat ik iets essentieels gemist had en dat je daarop doelde. Ik zat al te neuzen en te denken: snap ik het nu echt niet, waarom moet ik het aanzetten?

Ik heb in de basis nu 3 switches geuplinkt zou je kunnen zeggen, een fysieke en twee softwarematig, er is geen connectie (loop) van de een naar de ander dus daarom staat het uit.

[johnkeates]

Ik zou die hele NetworkManager gewoon de nek omdraaien en in /etc/network/interfaces de boel naar smaak inrichten.

[Sandor_Clegane]

johnkeates schreef op dinsdag 27 maart 2018 @ 21:57:
Ik zou die hele NetworkManager gewoon de nek omdraaien en in /etc/network/interfaces de boel naar smaak inrichten.

Eh, het lijkt nu te werken, en NetworkManager ziet eruit als de new shiny. Op Netplan na dan......
Als ik morgen weer wat hiccups heb, ga ik wel weer terug naar interfaces.

Bedankt voor de hulp allen.

[Hero of Time]

NM gebruik ik zelf niet op m'n systemen thuis, inclusief laptop (die heeft wicd) en zakelijk hebben we 't ook van alle machines gegooid. En voor de zekerheid hebben we bij alle CentOS machines nog eens NM_CONTROLLED=no ingesteld staan voor de zekerheid.

[Sandor_Clegane]

Is dat omdat het niet werkt of omdat het anders is?

[Hero of Time]

Geen van beide. Het is nog een service dat draait op de achtergrond wat uiteindelijk alleen maar als doel heeft om een vast IP adres te configureren. Maar ondertussen blijft NM wel gewoon draaien. En als we 'even snel' het IP adres willen aanpassen (wat we dus doen met een script die wat meer zaken aanpast) is het gewoon veel makkelijker om een consistent systeem te gebruiken. We draaien namelijk niet exclusief CentOS 7 (maar ook CentOS 6, en die doet geen nmcli zoals bij 7 kan).

En NM is een enorme bitch als je via een config management tool je resolv.conf beheert.

[Sandor_Clegane]

Hero of Time schreef op woensdag 28 maart 2018 @ 20:02:
Geen van beide. Het is nog een service dat draait op de achtergrond wat uiteindelijk alleen maar als doel heeft om een vast IP adres te configureren. Maar ondertussen blijft NM wel gewoon draaien. En als we 'even snel' het IP adres willen aanpassen (wat we dus doen met een script die wat meer zaken aanpast) is het gewoon veel makkelijker om een consistent systeem te gebruiken. We draaien namelijk niet exclusief CentOS 7 (maar ook CentOS 6, en die doet geen nmcli zoals bij 7 kan).

En NM is een enorme bitch als je via een config management tool je resolv.conf beheert.

Ok, snap ik.

Met een vast ip adres lijkt alles te werken. Nog geen issues meer gehad.

Nu nog problemen met suspend......