Sporadische Routingprobleme

Hallo,

ich kämpfe bei uns seit einigen Tagen mit einem sehr merkwürdigen Phänomen. Vielleicht hat ja jemand ein Idee…

Es geht um einen via UVMM virtualisierten UCS 4.0-1 Master, welcher aus heiterem Himmel nicht mehr in ein über eine zusätzliche Netzroute angebundenes Netz kommunizieren mag. Der Effekt betrifft bislang nur dieses System. Andere virtualisierte Server auf demselben Virtualisierungshost sind bislang nicht betroffen. Die Netzwerkadapter sind überall paravirtualisiert (virtio).

[code]root@master:~# ping -q -c 3 172.25.10.2
PING 172.25.10.2 (172.25.10.2) 56(84) bytes of data.

— 172.25.10.2 ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2010ms

root@master:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.25.25.254 0.0.0.0 UG 0 0 0 eth0
172.25.10.0 172.25.25.36 255.255.255.0 UG 0 0 0 eth0
172.25.25.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@master:~# ucr get interfaces/eth0/route/netzroute1
net 172.25.10.0 netmask 255.255.255.0 gw 172.25.25.36
root@master:~# ping -q -c 3 172.25.25.36
PING 172.25.25.36 (172.25.25.36) 56(84) bytes of data.

— 172.25.25.36 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.210/0.277/0.392/0.083 ms
root@master:~# traceroute 172.25.10.2
traceroute to 172.25.10.2 (172.25.10.2), 30 hops max, 60 byte packets
1 * * *
2 * * *
usw
[/code]

Man sieht, dass das betreffende Gateway grundsätzlich erreichbar ist, aber überhaupt nicht kontaktiert wird. Über das Default-Gateway ist alles ok.
Abhilfe bringt immer ein Neustart des Netzwerkes:

root@master:~# invoke-rc.d networking restart
...
root@master:~# ping -q -c 3 172.25.10.2
PING 172.25.10.2 (172.25.10.2) 56(84) bytes of data.

--- 172.25.10.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 26.745/26.884/27.005/0.217 ms

root@master:~# traceroute -n 172.25.10.2
traceroute to 172.25.10.2 (172.25.10.2), 30 hops max, 60 byte packets
 1  172.25.25.36  0.477 ms  0.500 ms  0.692 ms
 2  10.0.0.2  26.796 ms  28.024 ms  28.191 ms
 3  172.25.10.2  28.401 ms  28.946 ms  29.025 ms
root@master:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.25.25.254   0.0.0.0         UG        0 0          0 eth0
172.25.10.0     172.25.25.36    255.255.255.0   UG        0 0          0 eth0
172.25.25.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

dmesg und kern.log haben nichts dazu zu sagen.

Vielen Dank fürs Lesen,

Dirk Ahrnke

Hallo!

das habe ich so nicht nicht gehört/gelesen - wie “oft” passiert das ca.?
Gibt es die Möglichkeit das emulierte Netzwerkdevice für einen kontrollierten Zeitraum zu ändern (sprich: ohne virtio) um das weiter eingrenzen zu können?

Viele Grüße,
Tim Petersen

Hallo Tim,

Im Moment funktioniert das Routiing nach einem (Netzwerk)-Neustart für ein paar Stunden bis zu wenigen Tagen.
Ich beobachte das betreffende Netz mit Nagios seit Anfang April. Die Probleme begannen um den 24. April. Updates wurden am 8.4. und 27.4 eingespielt, also eher wenig Chance auf einen Zusammenhang.

Es wird ja noch merkwürdiger: Andere Hosts im Zielnetz bleiben erreichbar. Zumeist jedenfalls. Heute war wieder nur der".2" betroffen. Normalerweise würde ich da ja eher auf das Routing auf der Gegenseite tippen. Wenn eben nicht der Neustart auf der Quelle alles wieder auflöst.

Ich hab jetzt mal von virtio auf e1000 gestellt. Mal sehen…

Viele Grüße,
Dirk Ahrnke

Update: Die e1000 hat nichts geändert.

Ich taste mich gerade durch /proc/net. “rt_cache” zeigt mir während der Zeit, in der das Routing nicht wie erwartet funktioniert, dass die betroffenen IP-Adressen über das Standardgateway erreichbar sein sollen. Was sie natürlich nicht sind. Dummerweise hab ich vergessen, mal einen üblicherweise noch erreichbaren Host zu pingen, da hätte man sicher gesehen, dass dort das richtige Gateway steht.

Die Frage ist jetzt, welche vorgeblich intelligenten Dämonen zur Laufzeit das Routing eines Servers manipulieren könnten.

Wenn ich schon mal angefangen habe, schreib ich auch weiter…

Der Routingcache zeigte in der Tat für Ziele im selben Netz auf unterschiedliche Gateways. Beim Suchen bin ich dann über den Hinweis gestolpert, dass der Routingcache ab Kernel 3.6 so nicht mehr existiert.
Wie sich herausstellte, war doch wirklich auf dieser Maschine noch ein prähistorischer Kernel 3.2.0-ucs31-amd64 (von 2013) am Werkeln. Ich glaube nicht, dass ich noch herausfinden kann, warum und wann das schief gegangen ist. Ohne Anlass schaut man sich ja auch nicht unbedingt an, welche Kernelversion läuft. Sollte man aber vielleicht doch.

Mal schauen, was 3.16-ucs109-amd64 zur Lösung beiträgt.

Sehr interessant bis hierhin - danke fürs aufschreiben!
Bzgl. Kernel: Ist univention-kernel-image installiert?

Seit gestern. Das war für mich der aus meiner Sicht normale Weg, die aktuellen Kernel zu bekommen und vermutlich ist das Fehlen dieses Paketes auch der Grund, das der Kernel nicht aktualisiert wurde.

EDIT: Nicht ganz dieselben Ursachen und Auswirkungen aber vermutlich der Weg, so etwas zu verhindern: [bug]38120[/bug]

Höchstwahrscheinlich kein UCS-spezifisches Problem, daher abschließender Post zum Thema:

Mit “ip route get ip.des.entfernten.zieles” habe ich festgestellt, dass die Route auf "cache " steht. Das Gateway zum Zielnetz routet OpenVPN auf einem normalen Wheezy. In dessen Logs sehe ich kurz vor dem ersten Ausfall einen Neustart des VPNs. Damit wird die Route gelöscht. Wenn während der Zeit des Neustarts jemand nach diesem Ziel fragt, wird er wegen technischer Nichtzuständigkeit an das Standardgateway verwiesen. Der Host, der das Problem hat, macht u.a. das Monitoring, kontaktiert die Ziele also häufiger als alle anderen.

Wir schrauben jetzt an anderer Stelle weiter.