CNR-Parameteränderungen bei mehreren Kabelmodems in einem Netzwerk

Einführung

Der Cisco Network Registrar - Dynamic Host Configuration Protocol (CNR - DHCP)-Server kann bei einem Neustart am Headend wie nach einem Stromausfall und einer Wiederherstellung mit Anfragen überlastet werden. Diese Änderungen ermöglichen es dem DHCP-Server, Anfragen schneller und effizienter zu bearbeiten.

In diesem Beispiel wird max-dhcp-request auf 50 geändert. Der Wert von 50 ist möglicherweise nicht der beste. Wenn beispielsweise die CPU Ihres Systems niedrig ist, kann der Wert von 50 hoch sein. Es gibt keine mathematische Formel, um den besten Wert zu berechnen. Verwenden Sie 50, um festzustellen, ob dies für Ihr System gut ist, und nehmen Sie von dort aus Anpassungen vor.

Voraussetzungen

Anforderungen

Der Leser sollte über grundlegende Kenntnisse des DOCSIS-Protokolls und der Cisco IOS-Befehlszeile auf Routern der Serie uBR verfügen.

Verwendete Komponenten

Die in diesem Dokument verwendete Hardware stammt von den Cisco uBR7200-, uBR7100- oder uBR10k CMTS- und DOCSIS-kompatiblen Kabelmodems.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Änderungen an DHCP

Nehmen Sie folgende Änderungen an der DHCP-Konfiguration vor:

nrcmd> dhcp set max-dhcp-requests=50

Speichern Sie diese Konfigurationsänderung:

nrcmd> save

Starten Sie den Server erneut mit:

nrcmd> dhcp reload

Vorsicht: Seien Sie vorsichtig, um Serverparameter im Feld anzupassen. Siehe DHCP.

Erläuterung

In den meisten Umgebungen ist die Reduzierung des Werts für max-dhcp-anforderungen von 500 auf 50 die beste Methode, um den Server bei der Reaktion auf langfristige DHCP-Nachrichten-Bursts zu unterstützen, z. B. beim gleichzeitigen Neustart vieler uBRs.

Bei einem Neustart am Headend kann der Server mit Anfragen überlastet werden. Wenn Sie den Wert der max-dhcp-Requests reduzieren, können Sie verhindern, dass der Server zu viele Nachrichten in seiner Empfangswarteschlange speichert, insbesondere veraltete DHCP-Meldungen. Wenn der Server zu viele Nachrichten in der Empfangswarteschlange hält, verbringt er mehr Zeit mit der Verarbeitung veralteter DHCP-Nachrichten (die einige Clients verwerfen und erneut versuchen) als mit aktuellen DHCP-Nachrichten (die alle Clients akzeptieren würden). Der optimale Wert hängt von folgenden Faktoren ab:

• Serverhardware

• CPU

• Plattengeschwindigkeit

• Netzwerkmerkmale

Der Parameter max-dhcp-request steuert die Anzahl der Puffer, die der DHCP-Server für eingehende Anfragen zuweist. Nach einem Neustart am Headend füllen sich alle zugewiesenen Puffer schnell aus. Nachdem die Puffer gefüllt sind, verwirft der DHCP-Server zusätzliche Anfragen und akzeptiert neue nur, wenn er Anfragen verarbeitet und Puffer freigibt. Der Server reagiert schnell auf die ersten Anfragen, die eintreffen. Die nächsten bleiben mehrere Sekunden in der Pufferwarteschlange. Wenn der DHCP-Server Prozesse durchführt und darauf reagiert, hat der Client, der die Anfrage gesendet hat, ein Timeout erreicht. Daher werden die Ressourcen des DHCP-Servers verschwendet.

Nachdem ein Client das Timeout erreicht hat, versucht er es erneut, die eingehende Pufferwarteschlange des DHCP-Servers jedoch schnell zu füllen. Wenn die Anzahl der Puffer so festgelegt ist, dass mehr als die vier zweiten Client-Timeouts erforderlich sind, um die Warteschlange zu durchlaufen und eine Anfrage zu erhalten, kommt die Antwort auf die Anfrage zu spät. Wenn die Warteschlange voll ist, versuchen Sie es erneut mit den Clients, deren Anforderungen verworfen werden.

Zugehörige Informationen

• Technischer Support - Cisco Systems