Default-Route auf System mit virt. Interface

Hallo,

es geht um einen UCS DC Master (UCS 3.2-2, UCS@school 3.2 R2 v1) mit einer virtuellen Netzwerkschnittstelle.

Die Schnittstellen sind wie folgt definiert:
eth0 Adresse:10.10.1.2
eth0:0 Adresse:192.168.0.3
eth1 Adresse:169.254.78.94
lo Adresse:127.0.0.1
peth0 Parameter wie eth0 (nur ohne IP)

Problemstellung:
Nach einem Neustart des Systems wird die default Route nicht automatisch gesetzt. In diesem Fall besitzt das System dann keine Verbindung zum Gateway (192.168.0.253).
Durch das manuelle Setzen per “route add default gw 192.168.0.253” in der Kommandozeile wird die Route für eth0 gesetzt und die Verbindung zum Gateway besteht.

Das Eintragen der Route in der UCR gemäß sdb.univention.de/content/21/56/ … outen.html wird nach einem Neustart des Systems nicht übernommen. Initialisiert man das Netzwerk mit “/etc/init.d/networking restart” neu, wird die in
UCR gesetzte Route übernommen und funktioniert.

Gibt es da Erfahrungen (oder einen Workaround), warum die default-Route in Verwendung mit einem virtuellen Interface nicht
automatisch bei Systemstart gesetzt wird?

Ich hoffe, dass Sie mir weiterhelfen können und freue mich auf Ihre Rückmeldung.

Hallo,

eine default route können Sie in der UCR Variable “gateway” definieren.

Mit freundlichen Grüßen
Janis Meybohm

Danke für die Rückmeldung.

In dieser UCR Variable ist der korrekte Gateway eingetragen.
Wird leider nicht beim Neustart gesetzt.

Hallo,

könnten Sie bitte einmal den Inhalt von /etc/network/interfaces posten? Generell wird das Gateaway dort einfach eingetragen - außer natürlich das System bezieht die Adressen per DHCP.

Mit freundlichen Grüßen
Janis Meybohm

Danke für Ihre Antwort.
Anbei die /etc/network/interfaces

[code][…]
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.10.1.2
netmask 255.255.0.0
network 10.10.0.0
broadcast 10.10.255.255

auto eth0:0
iface eth0:0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.253

auto eth1
iface eth1 inet static
address 169.254.78.94
netmask 255.255.0.0
network 169.254.0.0
broadcast 169.254.255.255[/code]
Generell sollen ja die Konfigurationsdateien nicht direkt bearbeitet werden, oder? (Entsprechender Vermerk befindet sich ja in jeder Konfigurationsdatei in UCS).

Hallo,

das kann ich so nicht nachvollziehen. Wenn ich die von Ihnen gepostete Konfiguration verwende wird das default gateway auch nach einem Reboot normal gesetzt.
Könnten Sie posten wie die Konfiguration nach dem Boot aussieht und wie sie aussieht wenn Sie sie korrigiert haben?ip addr rounte -n

Mit freundlichen Grüßen
Janis Meybohm

Konfiguration direkt nach dem Boot:

[code]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
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: peth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master eth0 state UP qlen 1000
link/ether 00:30:48:35:cf:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::230:48ff:fe35:cf52/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:30:48:35:cf:53 brd ff:ff:ff:ff:ff:ff
inet 169.254.78.94/16 brd 169.254.255.255 scope global eth1
valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:30:48:35:cf:52 brd ff:ff:ff:ff:ff:ff
inet 10.10.1.2/16 brd 10.10.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0:0
valid_lft forever preferred_lft forever
inet6 fe80::230:48ff:fe35:cf52/64 scope link
valid_lft forever preferred_lft forever

route -n

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0[/code]

Manuelles Hinzufügen der Route:

# route add default gw 192.168.0.253

Konfiguration nach dem Hinzufügen:

[code]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
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: peth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master eth0 state UP qlen 1000
link/ether 00:30:48:35:cf:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::230:48ff:fe35:cf52/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:30:48:35:cf:53 brd ff:ff:ff:ff:ff:ff
inet 169.254.78.94/16 brd 169.254.255.255 scope global eth1
valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:30:48:35:cf:52 brd ff:ff:ff:ff:ff:ff
inet 10.10.1.2/16 brd 10.10.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0:0
valid_lft forever preferred_lft forever
inet6 fe80::230:48ff:fe35:cf52/64 scope link
valid_lft forever preferred_lft forever

route -n

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.253 0.0.0.0 UG 0 0 0 eth0
10.10.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0[/code]

Ich freue mich auf Ihre Rückmeldung.

Hallo,

ich kann das leider weiterhin nicht nachvollziehen, das Gateway wird in meinen Tests zuverlässig gesetzt. Da das Verhalten so auch von keinem anderen Kunden gemeldet wurde, halte ich es für höchst wahrscheinlich dass es sich hier um ein Konfigurationsproblem handelt.

Evtl. helfen noch die Ausgaben der aktuellen UCR Konfiguration bei der Fehlersuche:

ucr search --brief interfaces
ucr search --brief bridge
ucr search --brief gateway

Haben Sie darüber hinaus spezielle Netzwerk-Konfiguration vorgenommen (und evtl. wieder rückgängig gemacht)? Welche Virtualisierungstechnik haben Sie installiert?

Mit freundlichen Grüßen
Janis Meybohm

Danke für Ihre Rückmeldung.
Also über rückgängig gemachte Netzwerkkonfigurationen ist mir nichts bekannt.
Anbei die Auszüge aus der UCR:

interfaces/.*/address: <empty> interfaces/.*/broadcast: <empty> interfaces/.*/ipv6/.*/address: <empty> interfaces/.*/ipv6/.*/prefix: <empty> interfaces/.*/ipv6/acceptRA: <empty> interfaces/.*/mac: <empty> interfaces/.*/netmask: <empty> interfaces/.*/network: <empty> interfaces/.*/options/.*: <empty> interfaces/.*/order: <empty> interfaces/.*/route/.*: <empty> interfaces/.*/start: <empty> interfaces/.*/type: <empty> interfaces/eth0/address: 10.10.1.2 interfaces/eth0/broadcast: 10.10.255.255 interfaces/eth0/ipv6/acceptRA: false interfaces/eth0/netmask: 255.255.0.0 interfaces/eth0/network: 10.10.0.0 interfaces/eth0_0/address: 192.168.0.3 interfaces/eth0_0/broadcast: 192.168.0.255 interfaces/eth0_0/netmask: 255.255.255.0 interfaces/eth0_0/network: 192.168.0.0 interfaces/eth1/address: 169.254.78.94 interfaces/eth1/broadcast: 169.254.255.255 interfaces/eth1/fallback/address: 169.254.78.94 interfaces/eth1/fallback/broadcast: 169.254.255.255 interfaces/eth1/fallback/netmask: 255.255.0.0 interfaces/eth1/fallback/network: 169.254.0.0 interfaces/eth1/fallback/type: dhcp interfaces/eth1/ipv6/acceptRA: false interfaces/eth1/netmask: 255.255.0.0 interfaces/eth1/network: 169.254.0.0 interfaces/handler: ifplugd interfaces/primary: eth0 interfaces/restart/auto: true mail/postfix/inet/interfaces: all samba/interfaces/bindonly: <empty> samba/interfaces: <empty>

uvmm/kvm/bridge/autostart: yes uvmm/kvm/bridge/interface: <empty>

gateway: 192.168.0.253 ipv6/gateway: <empty>

Installiert ist die KVM Virtualisierung.
Ich freue mich auf Ihre Rückmeldung.

Hallo und vielen Dank für Ihre Geduld. :slight_smile:

Ich habe es jetzt geschafft das Verhalten zu reproduzieren. Ursache ist wohl dass das Gateway beim automatischen Anlegen der Netzwerk-Bridge für die Virtualisierung (dabei wird eth0 nach peth0 umbenannt was vermutlich das Problem verursacht) “verloren” geht. Der Einfachste Workaround ist hier das automatische Anlegen der Bridge zu deaktivieren und manuell eine Bridge für die Virtuellen Instanzen anzulegen:
Advanced networking configuration setup for UCS Virtual Machine Manager
UCS Handbuch: Netz-Konfiguration

Mit freundlichen Grüßen
Janis Meybohm

Vielen Dank für Ihre Rückmeldung!

Ich werde den Hinweis verfolgen und das auf dem System testen.
Ich gebe anschließend Rückmeldung.

Mastodon