  |
Cablecom THH 
Moderator
|
     
@allWie einige von euch bereits bemerkt und mit ihren Postings bestätigt haben, gehören die Probleme der letzten Tage endlich der Vergangenheit an. Hier nun eine kleine Zusammenfassung der Ereignisse und Hintergrundinformationen: Das Hauptproblem der lag vorwiegend beim DHCP-Protokoll. Zusammen mit weiteren kleinen Problemen kumulierte sich das Ganze zum eigentlichen, in diesem thread ausführlich dargestellten DCHP-Problem. Insgesamt haben uns ca. 30 Kunden die im thread beschriebenen Symptome geschildert.
1. Bei den DHCP-Servern wurde auf den DHCP-Renew nicht geantwortet
(welcher im Normalfall ein Unicast ist)
-> *DCHP-Server Problem*, gelöst am 25. Oktober 2002
2. Nach Behebung von Punkt 1 wurde der DHCP-Renew (Unicast) nicht zum DHCP-Client zurückgeleitet
-> *Netzwerk-Problem*, gelöst am 29. Oktober 2002
3. Beide Probleme - 1 und 2 - haben keinen Einfluss auf die Clients, sofern diese korrekt arbeiten. Kurz vor Ablauf der Lease (7/8 der Leasedauer) müsste ein Rebound stattfinden (welcher ein Broadcast ist), der auch von den andern DHCP-Servern korrekt verarbeitet und im Netz korrekt geroutet werden könnte.
Da aber offensichtlich bei vielen betroffenen Kunden Firewalls und/oder Router im Spiel waren, die wahrscheinlich nicht ganz RFC-konform arbeiten, führten die Punkte 1 und 2 trotzdem zu Ausfällen. Ferner gibt es auch DHCP-Clients, die nicht korrekt nach RFC arbeiten.
In diesen Fällen entzieht sich die Problembehebung dem Einfluss der Cablecom. Auch an dieser Stelle möchten wir all jenen, die sich aktiv an der Diskussion beteiligt und uns Informationen haben zukommen lassen, für ihre Mühe und Geduld danken. Euer
THH-Team (Geändert von Cablecom THH um 11:53 am am Okt. 30, 2002)
-----
Technischer Helpdesk Hispeed (THH) -> Infos unter Profil
0900 660 900 (10 Minuten Normaltarif, dann 2.13Fr./Min)
http://www.hispeed.ch
|
Beiträge gesamt: 414 | Mitglied seit: März 2002 | Erstellt: 11:51 am am Okt. 30, 2002 | IP
|
|
ThomasG
Newbie
|
2All,
Leider bin ich wohl zu unbewandert in diesem Gebiet, aber aus der Antwort vom THH werde ich nicht schlau ("Beide Probleme - 1 und 2 - haben keinen Einfluss auf die Clients, sofern diese korrekt arbeiten"):
- Wenn ich nichts verändert habe, warum läufts dann?
- Wenn mein Win98 in diesem Fall nicht ganz "RFC-konform" arbeitet, was muss ich verändern, damit das der Fall ist?
BTW: Der Effekt war auch ohne Firewall oder Router da, also kann es nur noch am OS liegen. Oder kann man was (ver-)konfigurieren?
- Dieser Rebound, kann man den forcieren/unterdrücken?
TIA(Geändert von ThomasG um 2:02 pm am Okt. 30, 2002)
|
Beiträge gesamt: 24 | Mitglied seit: Juli 2002 | Erstellt: 12:55 pm am Okt. 30, 2002 | IP
|
|
Zorg
Newbie
|
ich bin froh, dass es wieder läuft, DANKE
|
Beiträge gesamt: 19 | Mitglied seit: Okt. 2002 | Erstellt: 2:46 pm am Okt. 30, 2002 | IP
|
|
Rene
Advanced Member
|
ThomasG> Es gibt grundsätzlich mal 3 verschiedene Haupt-zustände in denen ein DHCP-Client sein kann.Je nachdem wie man seine Firewall einstellt, blockt man die weniger häufigen aus. Das ist mir persönlich auch passiert, meine Firewall ist extrem restriktiv, es ist alles geblockt bis auf das was ich erlaube und in einem ersten Versuch habe ich mir prompt auch einen DHCP-Zustand ausgeschlossen. 2 von diesen 3 Zuständen kannst Du problemlos simulieren und testen ob sie mit Deiner Firewall gehen. Folgende 3 Hauptzustände gibt es: - Startup, Client hat keine IP:
Der Client sendet mit einer Source IP von 0.0.0.0 einen Broadcast (Destination IP 255.255.255.255) raus. Simulieren kann man das indem man die IP releaset (NICHT renewt) und danach eine neue beziehen will. Klappt das nicht, ist die Firewall zu restriktiv eingestellt. Als Firewallregel muss hierzu also sowohl eine an und für sich ungültige IP Adresse als Quelle (0.0.0.0) erlaubt werden, wie auch der Broadcast als Ziel. Die Antwort welche zurück kommt hat als Zieladresse bereits die zukünftige IP Adresse, welche man bekommen wird. Sie kommt von Port 67 auf Port 68 udp. - Renew, Client hält IP, will verlängern. Der Client hat eine gültige IP Adresse und will sie verlängern. Dazu kontaktiert er den DHCP-Server, welcher ihm ursprünglich die IP zugeteilt hat (resp. denjenigen, welcher als letztes die Lease verlängert hat) via UDP direkt, also ein Packet von Port 68 -> Port 67 UDP. Der DHCP-Server antwortet 67 -> 68 UDP. Simulieren lässt sich das über ein winipcfg /renew resp. ipconfig /renew bei NT4, W2K, XP Als Firewall Regel muss der Client einen DHCP Server auf Port 67/udp erreichen können. Der Server muss den Client auf Port 68/udp erreichen können. Es macht hier keinen Sinn die Server IP fest einzugeben, denn dann wird es nicht mehr funktionieren wenn der DHCP-Server wechselt oder ein anderer einspringt. - Rebind Phase. Client hat IP und versucht lease zu erneuern bei "seinem" DHCP Server, erhält aber keine Antwort. Vor definitiver Ablaufzeit wenn der Client die IP loslassen muss. Diese Phase ist dann, wenn der Client praktisch "verzweifelt" versucht noch einen anderen DHCP Server zu finden, bevor die Zeit abläuft. Hierbei hat der Client seine IP Adresse, aber er sendet jetzt so einen Broadcast raus um evtl. einen anderen, zweiten Server zu finden. Simulieren lässt sich das schwerer. Man kann eine (temporäre) Firewallregel einbauen, welche den momentanen DHCP-Server blockt so dass der Client gezwungen ist, irgendwann in die Rebind Phase zu fallen. Kann er dann nicht von einem zweiten DHCP-Server seine Lease verlängern ist die Firewall zu restriktiv eingestellt. Die Firewall muss einen Broadcast erlauben. Also SourceIP <aktuelle IP> SourcePort 68 -> 255.255.255.255 Port 67. Die Antwort kann von einer beliebigen IP Adresse kommen, also <unbekannt>:67 -> <aktuelle IP> Port 68. Die beiden ersten Fälle lassen sich sehr leicht simulieren, für den letzten muss man sich quasi etwas selber sabotieren und das verhalten (möglichst per Netzwerksniffer) nach der hälfte der Leasetime beobachten. Die genaueren, harten Fakten finden sich in der RFC2131 (http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/21xx/2131) Was Windows98 und seinen eingebauten DHCP-Client betrifft - der ist schlichtweg schrott. Wenn ich mein Laptop an der ETH einsetze und eine Lease beziehe, danach herunterfahre (NICHT schlafen lege, wirklich herunterfahre) und danach bei mir zuhause anschliesse dann bootet Windows98SE hoch und bezieht KEINE neue IP Adresse. Es setzt einfach die alte ETH-IP Adresse. Mein eigener DHCP - Server wird nichtmal kontaktiert. Erst ein manuelles winipcfg /release , winipcfg /renew sorgt dafür, dass Windows98 überhaupt mal schaut ob ein DHCP Server da ist. Das Problem konnte ich auch mit langem pröbeln nicht lösen. Jetzt läuft halt auch W2K auf dem Laptop, damit ist das Problem weg.
-----
CU
René
|
Beiträge gesamt: 2468 | Mitglied seit: Mai 2001 | Erstellt: 3:22 pm am Okt. 30, 2002 | IP
|
|
jcfrick
Advanced Member
|
@rené: bein windows 9x würde ich nicht lange pröbeln, der tcp/ip stack ist da sowas von schlecht, ich sag immer : win9x ist einfach nichts fürs netzwerk, dafür braucht es ein richtiges os wie zb. 2000 xp oder linux oder mac oder....;-)
-----
----------------
Gruss JC
|
Beiträge gesamt: 327 | Mitglied seit: Dez. 2001 | Erstellt: 4:31 pm am Okt. 30, 2002 | IP
|
|
ThomasG
Newbie
|
2René,
vielen Dank für die ausführliche Antwort. Ich habe mir mal einen Sniffer besorgt, um das Verhalten gemäss Deinem Testscript zu studieren.
Anm.: Mein Win98 holt beim Hochfahren immer eine neue IP Adresse ab, da hatte ich nie Probleme (auf beiden Installationen nicht).
Umsteigen auf Win2000 würd' ich gerne, habe aber noch Hardware laufen, für die es keine Treiber gibt. Also eher langfristing.
Vielen Dank jedenfalls für die Antworten.
|
Beiträge gesamt: 24 | Mitglied seit: Juli 2002 | Erstellt: 10:30 am am Okt. 31, 2002 | IP
|
|
|
|
thokie
Advanced Member
|
Ja Rene, also das mit dem Win98 kannst Du in dem Fall vergessen. Ich hab kein Notebook, das ich an verschiedenen Orten anschliesse, sondern einen PC, der direkt am Kabelmodem hängt, und beim Neustart immer eine IP Adresse ordert. Daran lag das Problem sicher nicht.
Was die FW betrifft, so waren gemäss den Postings der Betroffen Zonealarm, Tiny und Norton im Spiel, was so ziemlich die gängisten sind. Und jetzt zu behaupten, sie alle halten sich nicht an die RFC, finde ich schon etwas gewagt. Ich weiss zwar nicht, wie die programmiert sind, aber in den Standardeinstellungen sollten sie sich schon so verhalten, dass wenn nach einem Client Broadcast ein ACK von einem anderen DHCP Server als der ursprünglich nach dem Discover gefundene eintrifft, das auch akzeptiert wird. Alles andere macht keinen Sinn.
Was mir bei den von Zonealarm geblockten Packets auffällt: Sie kamen eben von einem andern DHCP Server, im Ack Packet steht aber unter Server Identifiyer der alte Server, der auf die vorherigen Unicast Requests nicht geantwortet hat. Vielleicht liegt der Grund für das Blocken in diesem Widerspruch.
Dann wäre aber der Fehler Cablecom seitig, indem man mehr als zwei Wochen lang einen DHCP Server im Netz hält, der offenbar defekt ist...
-----
Greetz ...Troubles in Windows? Reboot!, Troubles in Linux? Be root!
|
Beiträge gesamt: 935 | Mitglied seit: Aug. 2001 | Erstellt: 12:18 pm am Okt. 31, 2002 | IP
|
|
|
|
|
|
| |
|
cablemodem.ch - Forum
DHCP-Störungen
