Massenweise Kunden aussperren
Es kommt der Tag, da muss man aufräumen. Und das war nun bei IPTV der Fall. Einige tausend noch Karteileichen sollten nicht mehr versorgt werden. Die Idee dazu ist ganz einfach, nur noch authentisierte Clients bekommen eine IP. Ohne IP kein IGMP, ohne IGMP kein Multicast und ohne Multicast kein Fernsehen. Aber das hat fatale Nebenwirkungen.
Ausgangslage
Es sind knapp 12000 Nutzer im IPTV-Netz eingebucht, bekommen also eine IP Adresse. Die Verteilung der Sender erfolgt dezentral über Multicast-Replikation. Damit sind die Datenleitungen bis runter zum DSLAM nur minimal belastet. Das funktioniert sehr gut.
Die Liste der Kunden, die IPTV vertragsmäßig nutzen dürfen, liegt mittlerweile vor und kann auch von der Hotline/Vertrieb aktualisiert werden. Ein Abgleich der Datenbestände mit der Produktivumgebung erfolgt automatisch. Soweit so einfach.
Die Kunden bekommen aktuelle aus einem großen Pool privater IPs eine DHCP-Lease. Eine Authentisierung erfolgt nicht, weil das der bisherige gewünschte Operationsmodus ist.
Umsetzung
Zur Änderung des Operationsmodus sind einige Vorüberlegungen notwendig:
- Es dürfen nicht alle Kunden mit einmal gesperrt werden, sondern nur ein Teil, damit die Hotline auf evtl. Fehlsperrungen reagieren kann.
- Authentisierte und nicht authentisierte Kunden sollten technisch unterscheidbar bleiben, damit der Netzbetrieb Kenntnis von der Vertragslage hat.
- Der Abgleich der Datenbanken zwischen Vertrieb und Produktion darf nicht angefasst werden, in den Datenbanken des Produktivsystem darf kein Kunde virtuell zugeteilte MAC-Adressen haben, die dem Vertriebssystem fremd sind. Andernfalls ist die Hotline nicht zur Störungsdiagnose und -behebung in der Lage und alle diese Fälle eskalieren in den Netzbetrieb.
Als Lösung werden zwei Pools eingerichtet:
- ein großer Pool für die authentisierten Kunden und
- ein kleinerer Pool für die nicht authentisierten Kunden.
Der unauthentisierte Pool kann dann schrittweise verkleinert werden, um für immer mehr Kunden den Zugang zu sperren. Bei Bedarf kann er auch schlagartig wieder vergrößert werden. Dies gestattet die Anzahl der ausgesperrten Kunden rein im operativen Betrieb einzustellen, die Datenbanken bleiben davon unberührt.
Da sich beide Pools hinsichtlich der verwendeten Adressbereiche unterscheiden ist die Diagnose, ob eine fehlende Authentisierung vorliegt auch der Hotline direkt möglich. Diese kann bei Bedarf die Daten auslesen und direkt zur Freischaltung verwenden.
Soweit der Plan.
Überraschungen
Ich müsste nicht darüber schreiben, wenn es so einfach gegangen wäre. Also zuerst einmal die Wirkung der Umschaltung.
Nach einem Testlauf kurz vor Mitternacht (bei dem sich herausstellte, dass die Auswertung der Authentisierung gar nicht aktiviert wurde), erfolgte dann wie geplant die Umschaltung und die erste Limitierung der Kunden auf ca. 5000 unauthentisierte Teilnehmer.
Wie leicht zu sehen, hat das dann nach Ablauf der Lease-Zeiten auch funktioniert. Sobald der Pool voll war, sank die Anzahl der IPTV-Teilnehmer ab, bis alle authentisierten plus die glücklichen 5000 Pool-Teilnehmer. In Summe um die 6000 Kunden.
Auch zu sehen ist aber auch, dass diese Reglung wieder aufgehoben wurde. Und das kam so:
In bestimmten Gegenden fiel am nächsten Morgen regelmäßig der komplette Anschluss aus. Einige Switche stellte kurzzeitig, aber effektiv, die Arbeit ein. Zwar erholten sie sich wieder, jedoch blieb ein konstanter Betrieb aus. Stattdessen wiederholte sich der Ausfall in kurzen aber unregelmäßigen Abständen.
Es stellte sich heraus, dass diese Switche mit Bursts von Broadcasts nicht klar kamen, wenn in diesen Burst zu viele unbekannte Quell-MAC-Adressen auftauchten. Offenbar geraten diese Geräte dann an Limits hinsichtlich der Verwaltung von MAC-Adressen. Diese Bursts kommen aus dem DHCP:
Als Notlösung wurde erst einmal wieder für alle der Zugang freigegeben. Damit hören die Bursts auf und das System funktioniert wieder.
Diese Bursts bestehen aus den DHCPDISOVER Anfragen der CPEs, für die keine Adressen mehr zur Verfügung stehen. Und die fragen eben alle paar Sekunden per Broadcast rum, ob irgendjemand evtl. doch eine IP für sie übrig hat.
Broadcast heißt aber auch, dass die Anfragen auch die hintersten Winkel des Netzes erreichen, insbesondere diese empfindlichen Switche. Im Normalbetrieb haben diese Switche kein Problem, aber so war's doch etwas zu heftig.
Die Lösung besteht nun darin, die betreffenden Segmente in getrennte Broadcast-Domains zu verfrachten und die Multicast-Streams in alle diese VLANs einzuspeisen. Aber dazu später mal mehr.