routing wird (nach einiger Zeit) ignoriert

**hifigraz** · 23.02.16, 18:41

Debian 8.0 (raspbian)

Ueber DHCP bekomme ich folgende Config funktioniert auf meinen nicht Linux Boxen gut.

Auch auf Raspbian geht es ein paar minuten nach dem Booten, aber dann

Code:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:9a:74:ef  
          inet addr:192.168.1.150  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::59fd:d981:a6b0:5d8a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12846 errors:0 dropped:122 overruns:0 frame:0
          TX packets:9944 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1184537 (1.1 MiB)  TX bytes:1474565 (1.4 MiB)

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
172.31.1.100    192.168.1.3     255.255.255.255 UGH       0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Das ganze funktioniert eine Zeit lang ganz gut aber auf einmal ist 172.31.1.100 nicht mehr erreichbar.

Und das ganze weil er versucht den traffic ueber das default gw zu schicken, anstatt ueber die eigene route.

Wenn ich die route mit route del und route add wieder loesche und anlege beginnt das ganze von neuem und geht wieder nur ein paar minuten gut.

dmesg sieht unspannend aus.

Best
Robert

**fork** · 23.02.16, 21:39

Hast Du schon das syslog(journalctl --lines=10000 --no-pager -o short-iso) durchgegraben, ob da irgendwas kommt, was auf den Fehler hindeutet?

Du kannst ja mal auf dem Pi ein Script im Screen laufen lassen, dass einen Dauerping auf .1.100 sendet, und dabei die Zeit protokolliert. Wenn Du die Zeit hast, kannst Du gezielt zu der Zeit im Log schauen.

Code:

#!/bin/bash
{
while :; do
   ping -c1 -w2 172.31.1.100 >/dev/null 2>&1 && echo OK || echo Fehler 
   sleep 1
done | while read line ; do
   echo "$(date) : $line"
done
} >/tmp/ping.log 2>&1  &

**hifigraz** · 24.02.16, 09:37

Nagios verliert zu der Zeit den Zugriff auf den Host, was hier aber nun Ursache und was Wirkung ist ist nicht ganz klar.

**hifigraz** · 24.02.16, 13:33

es ist sogar noch aerger. selbst wenn es kein spezielles routing gibt, wird nach einiger zeit dennoch ueber 192.168.1.1 geroutet, obwohl offiziell der host nichts von dem gateway weiss.

Code:

root@raspiheat:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.3     0.0.0.0         UG        0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
root@raspiheat:~# traceroute -n 172.31.1.100
traceroute to 172.31.1.100 (172.31.1.100), 30 hops max, 60 byte packets
 1  192.168.1.3  0.588 ms  0.392 ms  0.522 ms
 2  172.31.1.100  47.993 ms  48.066 ms  47.987 ms
root@raspiheat:~# traceroute -n 172.31.1.100
traceroute to 172.31.1.100 (172.31.1.100), 30 hops max, 60 byte packets
 1  192.168.1.3  5.607 ms  6.570 ms  6.516 ms
 2  172.31.1.100  455.974 ms  455.915 ms  455.852 ms
root@raspiheat:~# traceroute -n 172.31.1.100
traceroute to 172.31.1.100 (172.31.1.100), 30 hops max, 60 byte packets
 1  192.168.1.1  0.584 ms  0.692 ms  0.870 ms
 2  * * *
 3  10.74.139.22  34.818 ms  34.920 ms  35.886 ms
 4  * * *
 5  10.126.5.28  38.822 ms  39.697 ms  39.776 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * *^C

**hifigraz** · 24.02.16, 13:34

weiss irgend wer, wie ich dem Kern sagen kann, er soll gefaelligst nicht versuchen schlau zu sein und selber sein routing aussuchen?

**fork** · 24.02.16, 13:47

Hast Du den genauen Zeitpunkt herausgefunden, zu dem das Routing beginnt nicht mehr zu funktionieren?
Hast Du die Systemmeldungen wie empfohlen zu diesem Zeitpunkt (und etwas davor und danach) geprüft?

**hifigraz** · 24.02.16, 13:49

wie ich geschrieben habe ja. und nein es gibt gar nichts im log.

Allerdings kann ich das problem auch unter linux mint lmde und nicht nur unter raspbian nachvollziehen.

**BetterWorld** · 24.02.16, 14:04

Code:

#!/bin/bash
{
while :; do
   printf "%s : " "$(date)"
   ping -c1 -w2 172.31.1.100 >/dev/null 2>&1 && echo OK || echo Fehler 
   sleep 1
done 
} >/tmp/ping.log 2>&1  &

schon wieder 10 Zeichen.
Kann man diesen Unsinn nicht abstellen?

**fork** · 24.02.16, 14:10

Weiss irgend wer, wie ich dem Kern sagen kann, er soll gefaelligst nicht versuchen schlau zu sein und selber sein routing aussuchen?

Ok. Bei so viel Freundlichkeit klinke ich mich dann mal aus.

**hifigraz** · 24.02.16, 14:16

Zitat von BetterWorld

[code]
schon wieder 10 Zeichen.
Kann man diesen Unsinn nicht abstellen?

Wie gesagt, ich habe den genauen Zeitpunkt und es ist nichts im Log, gar nichts, ausser danach die Meldung dass nagios den host nicht mehr erreicht.
Das ist aber logisch, weil ja genau fuer diesen host die falsche route genommen wird.

Code:

016-02-24T13:29:50+0100 raspiheat systemd[1362]: Starting Default.
2016-02-24T13:29:50+0100 raspiheat systemd[1362]: Reached target Default.
2016-02-24T13:29:50+0100 raspiheat systemd[1362]: Startup finished in 36ms.
2016-02-24T13:29:50+0100 raspiheat systemd[1]: Started User Manager for UID 1000.
2016-02-24T13:29:55+0100 raspiheat sudo[1394]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/su -
2016-02-24T13:29:55+0100 raspiheat sudo[1394]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
2016-02-24T13:29:55+0100 raspiheat su[1401]: Successful su for root by root
2016-02-24T13:29:55+0100 raspiheat su[1401]: + /dev/pts/0 root:root
2016-02-24T13:29:55+0100 raspiheat su[1401]: pam_unix(su:session): session opened for user root by pi(uid=0)
2016-02-24T13:30:27+0100 raspiheat systemd[1]: Starting Cleanup of Temporary Directories...
2016-02-24T13:30:27+0100 raspiheat systemd[1]: Started Cleanup of Temporary Directories.
2016-02-24T13:31:30+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;1;PING CRITICAL - Packet loss = 88%, RTA = 8965.54 ms
2016-02-24T13:31:30+0100 raspiheat nagios3[931]: HOST FLAPPING ALERT: mattscheibe.at;STARTED; Host appears to have started flapping (23.9% change > 20.0% threshold)
2016-02-24T13:32:36+0100 raspiheat sshd[1450]: Connection closed by 127.0.0.1 [preauth]
2016-02-24T13:32:50+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;2;PING CRITICAL - Packet loss = 100%
2016-02-24T13:33:27+0100 raspiheat systemd[1]: Starting A simple router watchdog...
2016-02-24T13:33:27+0100 raspiheat systemd[1]: Started A simple router watchdog.
2016-02-24T13:34:10+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;3;PING CRITICAL - Packet loss = 100%
2016-02-24T13:35:30+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;4;PING CRITICAL - Packet loss = 100%
2016-02-24T13:36:50+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;5;PING CRITICAL - Packet loss = 100%
2016-02-24T13:37:36+0100 raspiheat sshd[1583]: Connection closed by 127.0.0.1 [preauth]
2016-02-24T13:38:10+0100 raspiheat nagios3[931]: HOST ALERT: mattscheibe.at;DOWN;SOFT;6;PING CRITICAL - Packet loss = 100%

**hifigraz** · 24.02.16, 14:18

Zitat von fork

Ok. Bei so viel Freundlichkeit klinke ich mich dann mal aus.

Es tut mir leid, dass du dich ueber meinen Aerger ueber einen Betriebssystemkern der sein routing selbststaendig und noch dazu fehlerhaft aendert, anggegriffen fuehlst.

**fork** · 24.02.16, 20:48

Dein Gemeckere geht mir eher auf den Keks und fördert eine Problemlösung nicht besonders. IT ist nunmal mitunter auch mal sehr komplex und wenn Du keine Lust, hast Dein Problem zu lösen, dann lass es doch einfach. Falls dem nicht so ist: Lass Deinen Ärger bitte draussen und habe doch einfach Spass daran, Dich beim lösen von Problemen weiter zu entwickeln. Da Probleme im Umgang mit IT leider unvermeidlich sind, wäre es auf Dauer ziehmlich selbstzerstörerisch, sich da immer wieder drüber zu ärgern. Ein Grossteil von Problemen ist übrigens meist in der Logikmaschine vor dem Bildschirm beheimatet(mangelndes Wissen/Erfahrung). Soll kein Vorwurf sein, ist jetzt nur eine Wiedergabe meiner eigenen Lernerfahrung mit meinem persönlichen Umgang mit dem Computer.

Zum Problem: Ich könnte mir vorstellen, dass da vielleicht der network-manager immer wieder in die Suppe spuckt. Da Du das Problem auch mit dem LMDE hast, würde ich vorschlagen, dass Du dort mit der Fehlersuche anfängst, denn ein Embedded-System ist vielleicht in manchen Sachen nochmal etwas speziell ist. Poste doch mal Deine /etc/network/interfaces vom LMDE-Rechner.

@Betterworld:

Dein Scriptschnipsel ist im konkreten Fall zwar kürzer und um ein Schleifenkonstrukt reduziert, jedoch ist meines mein üblicher generischer Ansatz. Im ersten Teil hau ich irgendwelche Ausgaben raus, die ich im zweiten Teil dann jeweils mit Zeitstempelpräfix versehe.

**ThorstenHirsch** · 24.02.16, 21:46

Ich hab' mal Spaßhalber die gleiche route auf meinem pi hinzugefügt. 30min sind rum und sie ist immer noch da. Den NetworkManager hab' ich nicht am laufen. Wifi baue ich über die /etc/network/interfaces auf, was wpa_supplicant nutzt. Da läuft dann noch der dhcp-client-daemon. Diese Kombination scheint schon mal keine Eingriffe an der Routingtabelle vorzunehmen.

Was läuft denn noch so auf Deinem pi?

**marce** · 25.02.16, 06:34

Erster Ansatz meinerseits wäre auch: mal alles automatische Geraffel weg und Netzwerk statisch konfigurieren.

**hifigraz** · 25.02.16, 07:45

Also kurz zum Setup:

Zitat von ThorstenHirsch

Ich hab' mal Spaßhalber die gleiche route auf meinem pi hinzugefügt. 30min sind rum und sie ist immer noch da. Den NetworkManager hab' ich nicht am laufen. Wifi baue ich über die /etc/network/interfaces auf, was wpa_supplicant nutzt. Da läuft dann noch der dhcp-client-daemon. Diese Kombination scheint schon mal keine Eingriffe an der Routingtabelle vorzunehmen.

Ich hab die Route ja nicht zum Spass

Auf 192.168.1.3 laeuft ein ipsec welches die einzig gueltige Verbindung zu 172.31.1.100 herstellt. Deswegen muss der Traffic zu 172.31.1.100 ueber die 1.3 geroutet werden.
192.168.1.1 ist ein proprietaerer Router ins internet deswegen geht der Rest ueber diesen.

Ich habe mittlerweile eine Vermutung. Das VPN auf dem OpenWrt router laeuft wohl nicht super stabil. Manchmal ist 172.31.1.100 nicht erreichbar. Der Pi mit seinem Jessie versucht dann ueber die 192.168.1.1 den 172.31.1.100 zu erreichen. Soweit so gut, auch wenn dieser Versuch nicht von Glueck gesegnet ist. Das VPN auf dem Openwrt erholt sich natuerlich nach einiger Zeit und 172.31.1.100 ist wieder ueber die 1.3 erreichbar. Leider ist es dann zu spaet, der Pi und zum Beispiel auch (MINT LMDE) bleiben dann bei dem nicht funktionierendem Versuch ueber die 1.1

Deswegen gibt es eine Moeglichkeit dem Kernel dieses "intelligente" Selbstrouting auszutreiben? Ich will, dass er die Routen verwendet die ich ihm sage und keine anderen.

Gruss
Robert

Was läuft denn noch so auf Deinem pi?

raspbian, aktuell.