Hallo zusammen,
heute morgen gab es bei uns einen kurzen aber praktisch kompletten Netzwerkausfall. Nach dessen Behebung blieben diverse CentOS-Maschinen offline, weil sie offenbar nach einem (einzigen) erfolglosen DHCPDISCOVER Versuch aufgegeben haben:
Host 1 [...] Mar 28 12:20:16 host1 kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex. Mar 28 12:20:16 host1 kernel: tg3: eth1: Flow control is on for TX and on for RX. Mar 28 12:20:16 host1 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Mar 28 12:20:20 host1 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 10 Mar 28 12:20:21 host1 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:20:22 host1 dhclient: No DHCPOFFERS received. Mar 28 12:20:30 host1 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 14 Mar 28 12:20:44 host1 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 11 Mar 28 12:20:55 host1 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 12 Mar 28 12:21:06 host1 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Mar 28 12:21:13 host1 dhclient: No DHCPOFFERS received. [...danach aber kein DHCPDISCOVER oder DHCPREQUEST bis zum Reboot...]
Host 2 [...] Mar 28 12:15:28 host2 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Mar 28 12:15:31 host2 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex. Mar 28 12:15:31 host2 kernel: tg3: eth0: Flow control is on for TX and on for RX. Mar 28 12:15:31 host2 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Mar 28 12:15:33 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 Mar 28 12:15:44 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 Mar 28 12:15:59 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 Mar 28 12:16:09 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 Mar 28 12:16:28 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:16:29 host2 dhclient: No DHCPOFFERS received. [...danach aber kein DHCPDISCOVER oder DHCPREQUEST bis zum Reboot...]
Ist es Teil des DHCP-Protokolles, dass ein DHCPDISCOVER nur einmal probiert wird oder lassen sich die Rechner so konfigurieren, dass der Prozess bis zum Erfolg regelmaessig ablaeuft, so wie auch der DHCPDISCOVER alle 15 Minuten wiederholt wird?
Auf den Rechnern laeuft CentOS 5.5, komplett aktualisiert.
Gruss
frank
Am 28.03.11 13:57, schrieb Frank Thommen:
Hallo zusammen,
heute morgen gab es bei uns einen kurzen aber praktisch kompletten Netzwerkausfall. Nach dessen Behebung blieben diverse CentOS-Maschinen offline, weil sie offenbar nach einem (einzigen) erfolglosen DHCPDISCOVER Versuch aufgegeben haben:
Mar 28 12:20:21 host1 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:20:22 host1 dhclient: No DHCPOFFERS received.
Hmmm. Davor auch nix für eth0? Ich denke mal, die beiden gehören zusammen, für eth1 hat er es ja noch ein paar mal versucht.
Mar 28 12:15:33 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 Mar 28 12:15:44 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 Mar 28 12:15:59 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 Mar 28 12:16:09 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 Mar 28 12:16:28 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:16:29 host2 dhclient: No DHCPOFFERS received. [...danach aber kein DHCPDISCOVER oder DHCPREQUEST bis zum Reboot...]
Und hier hat er es ja ein paar Mal versucht. Ich tippe darauf, dass da eventuell auch am Switch nach dem Reboot "Murks" war, dass er zwar einen Link erkannt hat, die Pakete aber nicht durchgegangen sind.
Ralph
Ralph Angenendt wrote:
Am 28.03.11 13:57, schrieb Frank Thommen:
Hallo zusammen,
heute morgen gab es bei uns einen kurzen aber praktisch kompletten Netzwerkausfall. Nach dessen Behebung blieben diverse CentOS-Maschinen offline, weil sie offenbar nach einem (einzigen) erfolglosen DHCPDISCOVER Versuch aufgegeben haben:
Mar 28 12:20:21 host1 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:20:22 host1 dhclient: No DHCPOFFERS received.
Hmmm. Davor auch nix für eth0? Ich denke mal, die beiden gehören zusammen, für eth1 hat er es ja noch ein paar mal versucht.
eth0 wird an diesem Rechner nicht automatisch hochgefahren.
Mar 28 12:15:33 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 Mar 28 12:15:44 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 Mar 28 12:15:59 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 Mar 28 12:16:09 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19 Mar 28 12:16:28 host2 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1 Mar 28 12:16:29 host2 dhclient: No DHCPOFFERS received. [...danach aber kein DHCPDISCOVER oder DHCPREQUEST bis zum Reboot...]
Und hier hat er es ja ein paar Mal versucht. Ich tippe darauf, dass da eventuell auch am Switch nach dem Reboot "Murks" war, dass er zwar einen Link erkannt hat, die Pakete aber nicht durchgegangen sind.
Ich denke, dass, nachdem unsere Netzwerk-Jungs den Switch repariert hatten, der DHCP-Server noch nicht funktionierte. Deswegen moechte ich, dass die Rechner nicht nur alle 15 Minuten den ueblichen DHCPREQUEST machen (wenn sie schon eine IP-Nummer haben), sondern auch den DHCPDISCOVER (wenn sie noch keine IP-Nummer haben). Das scheint aber nicht der Falls zu sein und ich habe bisher keinen Weg gefunden, den dhclient entsprechend zu konfigurieren.
frank
Am 29.03.2011 09:32, schrieb Frank Thommen:
Ich denke, dass, nachdem unsere Netzwerk-Jungs den Switch repariert hatten, der DHCP-Server noch nicht funktionierte. Deswegen moechte ich, dass die Rechner nicht nur alle 15 Minuten den ueblichen DHCPREQUEST machen (wenn sie schon eine IP-Nummer haben), sondern auch den DHCPDISCOVER (wenn sie noch keine IP-Nummer haben). Das scheint aber nicht der Falls zu sein und ich habe bisher keinen Weg gefunden, den dhclient entsprechend zu konfigurieren.
Ich wüsste auch nicht wie das geht.
Aber wir machen bei sowas im Zweifelsfall auf allen Ports zu denen der Switch keine ARP-Einträge hat shutdown/2 sekunden warten/no shutdown. Dann sieht der Host einen Link-Down und einen Link-Up und macht danach ein neues Discover.
Grüße, Andreas
Andreas Rogge wrote:
Am 29.03.2011 09:32, schrieb Frank Thommen:
Ich denke, dass, nachdem unsere Netzwerk-Jungs den Switch repariert hatten, der DHCP-Server noch nicht funktionierte. Deswegen moechte ich, dass die Rechner nicht nur alle 15 Minuten den ueblichen DHCPREQUEST machen (wenn sie schon eine IP-Nummer haben), sondern auch den DHCPDISCOVER (wenn sie noch keine IP-Nummer haben). Das scheint aber nicht der Falls zu sein und ich habe bisher keinen Weg gefunden, den dhclient entsprechend zu konfigurieren.
Ich wüsste auch nicht wie das geht.
Aber wir machen bei sowas im Zweifelsfall auf allen Ports zu denen der Switch keine ARP-Einträge hat shutdown/2 sekunden warten/no shutdown. Dann sieht der Host einen Link-Down und einen Link-Up und macht danach ein neues Discover.
Im Prinzip keine schlechte Idee. In meinem spezifischen Fall braeuchte ich aber eine Loesung, die ohne Eingreifen der Netzwerker funktionert. Ich selber habe keinen Zugriff auf die Switches.
frank
Am 29.03.2011 18:39, schrieb Frank Thommen:
Im Prinzip keine schlechte Idee. In meinem spezifischen Fall braeuchte ich aber eine Loesung, die ohne Eingreifen der Netzwerker funktionert. Ich selber habe keinen Zugriff auf die Switches.
frank
Naja... das riecht irgendwie nach sowas wie
ip a s eth1 | grep -q 'inet .*scope global' || ifdown ethX && ifup ethX
in der crontab (etwas ausgefeilter darf es aber auch gern sein).
Das Problem ist allerdings nicht CentOS-spezifisch. Wir haben den selben Effekt bei Windows XP, Windows 2000, Druckern von HP und Brother, IP-Telefonen, etc. auch schon gehabt. Daher die Variante mit den Switchen - die ist plattformunabhängig und startet bei Geräten mit PoE auch direkt die Geräte (z.B. Telefone) durch :)
Grüße, Andreas
-
Andreas Rogge -
Frank Thommen -
Ralph Angenendt