Netzwerkproblem nach Update von 18.12 -> 19.09

Hallo,

beim Update einer on-premise Installation geht irgendwas mit der Netzwerkkonfiguration schief. Die Installation hat eine statische IP-Adresse. Nachdem die neue Version 19.09 nach dem Update startet, ist die gesetzte statische IP kurz aktiv und kann von außen angepingt werden. Kurze Zeit später stellt das System aber automatisch auf DHCP um und das Interface bekommt eine andere IP-Adresse zugewiesen.

Im Webinterface ist die Option Enable DHCP weiterhin DEAKTIVIERT und die statische IP-Adresse auch noch eingetragen.
Wenn ich dann im Webinterface auf DHCP umstelle und dann wieder zurück auf statische IP, bleibt es trotzdem bei DHCP.
Was könnte ich noch probieren um wieder die statische IP-Adresse zu setzen?

Viele Grüße

Ich hatte das gleiche Problem. Ich habe das Problem so gelöst das ich im DHCP eine Adressreservierung für die PASCOM hinterlegt habe.
Danach konnte ich dann auch wieder die fixe IP Adress zuordnen.
Danach bliebt auch die IP Adresse fix, auch nach einem Neustart.

Grüße

Ich kann danach die fixe IP Adresse eben nicht mehr setzen, d.h. das Verhalt bleibt gleicht -> die gesetzte fixe IP Adresse ist kurz aktiv und dann schaltet das Interface wieder auf DHCP.

@pascom: Was könnte das sein? Kann ich die statische IP wenigstens irgendwo von Hand setzen, damit ich die neue Version ausrollen kann?

@maibua das Problem ist uns bisher nicht bekannt und lies sich auch nicht auf anhieb reproduzieren.

Bitte probier mal folgendes aus falls Du eine VM mit snapshot hast.
Bei Hardware kanns gut sein das Du dich permanent aussperrst!

  • ssh admin@deinsystem
  • sudo su
  • die Datei /var/lib/lxc/if…/vars.json bearbeiten (vi, nano etc. Korrekten Interfacenamen einsetzen z.B. ifens160, ifeth0 etc.)
  • speichern und direkt mit “reboot” neu starten

In der Datei folgende Dinge beachten:

  • PUBLIC_NIC_MODE : static
  • PUBLIC_IP, _NETMASK, _GATEWAY etc korrekt setzen

Bitte Feedback geben.

Gruss,

Thomas

Die vars.json sieht eigentlich in Ordnung aus.

{
"CERTIFICATE_KEY": "-----BEGIN RSA PRIVATE \n ... -----END RSA PRIVATE KEY-----\n",
"CERTIFICATE_MODE": "provided",
"CERTIFICATE_PEM": "-----BEGIN CERTIFICATE-----\n ... \n-----END CERTIFICATE-----\n",
"DEFAULT_REDIRECT": "https://mypbxhost.lan/mypbx",
"DHCP_DNS": null,
"DHCP_ENABLED": "off",
"DHCP_FROM": null,
"DHCP_GATEWAY": null,
"DHCP_MODE": "all",
"DHCP_PBX": "mypbx",
"DHCP_TO": null,
"DISPLAY_NAME": "ifeth0",
"EXTENDED_NETWORK_INTERFACE": "",
"INTERFACE_MODE": "management",
"LDAP_PROXY": "mixed",
"MDWEB_MODE": "full",
"MOBILE_PAIRING": "on",
"MONITORING_HOST": "localhost:5099",
"PROVISIONING_INSECURE": "on",
"PROVISIONING_KEY": "xxxxxxxxxxxx",
"PROVISIONING_SECURE": "off",
"PUBLIC_ADDRESS": "192.168.0.10",
"PUBLIC_GATEWAY": "192.168.0.1",
"PUBLIC_IP": "192.168.0.10",
"PUBLIC_NETMASK": "255.255.255.0",
"PUBLIC_NIC": "eth0",
"PUBLIC_NIC_MODE": "static",
"REST_LIMIT": "0",
"RTP_PORT_FROM": "30000",
"RTP_PORT_TO": "35000",
"SIP_ALG": "off",
"VOIP_MEDIA": "srtp",
"VOIP_SIP": "tls",
"VPN_PROXY": "off",
"XMPP_MODE": "on"}

Die Ausgabe von ip addr dazu sieht so aus:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 86:41:f1:c0:f6:43 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.177/24 brd 192.168.0.255 scope global dynamic eth0
   valid_lft 690815sec preferred_lft 690815sec
inet6 fe80::8441:f1ff:fec0:f643/64 scope link 
   valid_lft forever preferred_lft forever
3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 scope global lxcbr0
   valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe00:0/64 scope link 
   valid_lft forever preferred_lft forever
5: vethB9R202@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
link/ether fe:a2:8b:86:db:e8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::fca2:8bff:fe86:dbe8/64 scope link 
   valid_lft forever preferred_lft forever
7: veth0UKCQQ@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
link/ether fe:bd:bb:b4:c3:1a brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::fcbd:bbff:feb4:c31a/64 scope link 
   valid_lft forever preferred_lft forever
9: vethESH92J@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
link/ether fe:1c:f7:2e:83:66 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::fc1c:f7ff:fe2e:8366/64 scope link 
   valid_lft forever preferred_lft forever
11: vethYDTAJD@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
link/ether fe:79:69:d3:09:81 brd ff:ff:ff:ff:ff:ff link-netnsid 3
inet6 fe80::fc79:69ff:fed3:981/64 scope link 
   valid_lft forever preferred_lft forever

Liebes Pascom-Team,

wir kommen hier mit Update nicht weiter. Da wir noch weitere Anlagen auf Version 19 anheben müssen, wäre ich über eine Rückmeldung sehr dankbar! Soll ich dazu lieber ein Ticket erstellen?

Hier ist das Community Forum, wenn Du schnelle Hilfe brauchst und supportberechtigt bist, dann eröffne dort bitte ein Ticket.

Ich kann nur vermuten das Du ggf in /persistent/etc/network manuell erzeugte Dateien abgelegt hast. Ansonsten ist deine Konfiguration korrekt und ist durch Standardtests abgedeckt. Ohne weitere Informationen kommen wir hier nicht weiter. Läuft denn ein dhcpclient im interface?

In /persistent/etc/network wurde nichts manuell erzeugt.

Die dort vorhande interfaces Konfigurationsdatei sieht auch korrekt aus:
#
# DO NOT EDIT
#
# rendered from /container/templates/interfaces.tpl
#

# you can add additional custom network configuration into
# the /persistent/etc/network/interfaces.d folder
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.0.10
    netmask 255.255.255.0
    gateway 192.168.0.1

Es laufen drei dhclient Prozesse:

root@mypbxhost:/persistent/etc/network# ps -fe | grep dhclie
root      1917  1667  0 11:45 ?        00:00:00 /sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
root      2875  2402  0 11:45 ?        00:00:00 /sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0
root      4754  4503  0 11:46 ?        00:00:00 /sbin/dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0

Die /var/lib/dhcp/dhclient.eth0.leases sieht so aus:

lease {
  interface "eth0";
  fixed-address 10.0.3.184;
  option subnet-mask 255.255.255.0;
  option routers 10.0.3.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.3.1;
  option dhcp-server-identifier 10.0.3.1;
  option dhcp-renewal-time 1800;
  option broadcast-address 10.0.3.255;
  option dhcp-rebinding-time 3150;
  option host-name "cs-host_b6250885";
  renew 3 2020/09/16 09:02:35;
  rebind 3 2020/09/16 09:26:38;
  expire 3 2020/09/16 09:34:08;
}

Die Datei /run/dhclient.eth0.pid ist nicht vorhanden.

Jeder unserer container hat einen dhclient auf einem lxc eth0 - ausser das Management Interface falls es auf static konfiguriert wurde. Darum nochmals die Frage von oben: läuft denn ein dhcpclient im Interface ?

Dazu musst Du erst in den enstprechenden Container mit lxc-attach -n ifeth0 und dann dort mit “ps” schauen.

Nein, im Container ifeth0 läuft kein dhcpclient.

Hallo @maibua,
wir forschen das nochmal detaillierter in unserer Umgebung aus. Ich nehme an, es handelt sich um eine VM? Welcher Hypervisor ist in dem Fall im Einsatz?

Besten Gruß
Sebastian

Hallo @maibua,

wir können es nun reproduzieren.
Das Problem tritt nur auf wenn sich das Interface exakt “eth0” nennt. Das ist etwa auf der HyperV Platform und wohl bei Proxmox so, jedoch nicht bei vSphere/VMWare/AWS oder auf Hardware.

Es wird in den nächsten Tagen eine pascom 19.10 mit u.A. diesem Fix geben.

Danke für die Mithilfe!

Gruß,

Thomas

Hallo Thomas,

vielen Dank für die Rückmeldung!

Hallo zusammen,
unsere neue Beta-Version sollte das Problem bereits beheben und steht hier zum Download bereit. Es wäre nett, wenn ihr uns dazu Rückmeldung geben könntet.
Der obligatorische Hinweis: Da es sich um eine Beta-Version handelt können natürlich noch Komplikationen auftreten.

Die Änderungen auf einen Blick:

  • Defekte Netzwerkkonfiguration mit bestimmten Hypervisors behoben

  • Kleinere Migrationsprobleme repariert

  • Diverse Verbesserungen im UI

    [MD-12725] - Static management network configuration breaks with 19.09 and ifeth interfaces
    [MD-12581] - Instance wizard: Validators are not executed while typing
    [MD-12586] - Management UI: Mark currently shown jobs section
    [MD-12587] - Management UI: Change cursor on hovering Browse button
    [MD-12700] - Migration error with Labels while upgrading to 19.09
    [MD-12707] - Incomplete pbx startup after update or restore, instance not reachable
    [MD-12711] - Broken Migration due to wrongly parsed timezone in app_conf.inc.php

Besten Gruß
Sebastian

Sieht gut aus! Nach dem Upgrade von 18.01 auf die neue 19.10 bleibt die statische IPv4-Adresse unter XenServer aktiv.