Selbstbau eines A10NSP Gateways
Ein Kunde wünscht eine bezahlbare, skalierbare Lösung für den Anschluss von xDSL-Kunden, die per L2-BSA von der DTAG zugeführt werden. Natürlich sollen die eigenen Produkte erhalten bleiben, die Kunden in ihrem Router - wie gewohnt - den richtigen Provider auswählen, kurz gesagt, ein Telekom-Anschluss soll so funktionieren wie ein direkt durch den Kunden betriebener DSL Zugang.
Aufgabenstellung
Der Anschluss beim Endkunden wird als Ethernet-Übergabe mit mehreren (einfach getaggten) VLANs ausgeführt. Der Kunde soll dort alle VLANs nutzen können, die auch sonst an einem direkt versorgten Anschluss zur Verfügung stehen.
Es soll Triple-Play möglich sein, also nennen wir die benötigten VLANs mal 140 für Internet, 141 für IPTV und 142 für VoIP. Die Nummern sind egal, es können auch 7, 18 und 4012 benutzt werden. Wichtig ist nur, dass alle Pakete am Anschluss nach einem festen Schema getaggt übergeben werden. Dieses Schema wird durch die Auswahl des Providers in der CPE (z.B. Fritzbox) des Endkunden festgelegt.
| Payload (z.B. IP) |
| C-VLAN Tag |
| Source-MAC |
| Destination-MAC |
Ein L2-BSA Zugang durch die DTAG sammelt nun die einfach getaggten Pakete (C(ustomer)-Tag) ein, versieht sie mit einem zusätzlichen VLAN-Tag (S(erviceprovider)-Tag), anhand dessen die Transporttechnik der DTAG den Endkundenport wieder identifizieren kann und übergibt die Pakete dann doppelt getaggt an uns. Umgekehrt erkennt die DTAG anhand des äußeren S-Tags, an welchen Kundenanschluss die Pakete raus fallen sollen. Das S-Tag wird entfernt und das C-Tag ist beim Kunden sichtbar.
| Payload (z.B. IP) |
| C-VLAN Tag |
| S-VLAN Tag |
| Source-MAC |
| Destination-MAC |
Dieses Verfahren hat mehrere Konsequenzen:
- Das S-Tag charakterisiert die Verbindung zwischen Kundenanschluss und Provider.
- Hinter dem S-Tag stehende C-Tags, Protokolle oder gar MAC-Adressen sind dem Transportweg komplett egal.
- Auf diese Weise können beliebig viele Endgeräte hinter einem Anschluss versorgt werden.
- Es können auch beliebige Produkte (IPv4, IPv6, ...) angeboten werden.
- Da sich die DTAG für die Inhalte der Pakete nicht interessiert, übernimmt sie auch keine Multicast-Replikation z.B. für IPTV. Wenn also fünf Teilnehmer einen Sender schauen, müssen die Pakete fünf mal (mit unterschiedlichen S-Tags) gesendet werden.
- Pro Kundenanschluss benötigt man ein anderes, eindeutiges Tag. Dieses muss von dem Transportprovider, der DTAG, verwaltet werden.
- Somit sind pro Übergabeanschluss (BNG) nur ca. 4000 Kundenanschlüsse möglich (Wertebereich von VLAN Tags)
Die DTAG behält sich vor, dass sie das S-Tag pro neuem Verbindungsaufbau (DSL-Sync) neu vergibt. Ist der Kunde also bisher unter dem S-Tag 432 sichtbar gewesen, so kann er nach einem Reset seines Routers oder einer Leitungsstörung spontan unter dem neuen S-VLAN 874 auftauchen. Pakete, die in Richtung Kunden mit dem S-Tag 432 geschickt werden, kommen also von jetzt auf gleich nicht mehr an.
| Payload (z.B. IP) | Daten | Daten |
| C-VLAN Tag | 140 | 140 |
| S-VLAN Tag | 432 | 874 |
| Source-MAC | 01:02:03:04:05:06 | 01:02:03:04:05:06 |
| Destination-MAC | 01:02:03:07:08:09 | 01:02:03:07:08:09 |
| vorher | nachher |
Interessanterweise besteht die DTAG bei einer umgekehrten Versorgung mit L2-BSA durch ein Netz eines anderen Providers darauf, dass die S-Tags pro Kunde fix bleiben und sich nicht ändern dürfen.
Da bisher das Netz wie eine große L2-Wolke betrachtet wurde, sollen die neuen Anschlüsse ebenso funktionieren.
Darüber hinaus gibt es ein Problem durch die unterschiedlichen Anschlussbandbreiten. Die DTAG möchte keinesfalls bei Produktwechseln (andere Anschlussbandbreite) involviert sein, also:
- handelt sie selbst in Richtung Endkunden die höchstmögliche Geschwindigkeit aus, die die Technik her gibt.
- verpflichtet sie den Provider, nicht mehr Bandbreite dem Endkunden zur Verfügung zu stellen, wie dieser lt. Produktbeschreibung verkauft hat, auch wenn der Anschluss schneller synchronisierte.
- verpflichtet die den Provider, nicht mehr Bandbreite zum Endkunden zu schicken, als dessen Anschluss auch real her gibt, selbst dann, wenn die verkaufte Bandbreite höher ist.
- bietet sie dem Provider gewisse reservierte Bandbreiten mit besonderen QoS-Zusagen, z.B. geringer Jitter (für VoIP) oder minimaler Paketverlust (für IPTV).
Um den Provider zur Einhaltung dieser Regeln zu zwingen (und damit der Überlastung des eigenen Netzes entgegen zu wirken), sind Verletzungen dieser Regeln vertraglich strafbewehrt.
Von der Idee zur Umsetzung
Konzentriert man sich allein auf das S-Vlan Problem, so genügt es anhand der MAC Adresse herauszufinden auf welchem Weg das Paket ursprünglich herein gekommen war. Stellt man sich jedes S-Vlan als eigene Leitung vor, so würde ein Switch mit 4096 Ports die Aufteilung bestens erfüllen: Er lernt anhand der Source-MAC, auf welchem Interface das Paket rein kam, und schickt die Antworten (mit der Ziel-MAC) auch dahin zurück. Kommt die MAC mal von einem anderen Interface (geändertes S-Tag), lernt er um.
Natürlich stellt man sich nicht einen Switch mit derartig vielen Interfaces real hin. Schließlich kommen diese 4000 "Leitungen" pro Anschluss an einen BNG. Für ein kleines Bundesland wie Thüringen, sind das einige Hundert Zuleitungen, die wir aber nicht alle brauchen, weil wir ja selbst ein Netz haben. Die Überschlagsrechnung ergibt: 2,3 Mio Einwohner = 600k Haushalte = 150 BNGs (Minimum)
Anderseits sind sicher nicht alle Haushalte fest als Kunden zu planen, sondern nur ein kleiner Teil wird wechseln wollen. Von den potentiell 4000 "Leitungen" werden nur wenige belegt sein. Es wäre also völlig abstrus, hier dauerhaft alle möglichen Verbindungen offen zu halten. Dazu kommt, dass Broadcast-Traffic (z.B. ARP) an alle potentiellen Teilnehmer gesendet werden müssen. Hält man also alle potentiellen "Leitungen" offen verviertausendfacht man den Traffic. Unnötigerweise.
- Der erste Schritt war die Erstellung eines Testbeds, dass die verwendete Anschlusstechnik simulieren kann. Dies wird ausführlich in einem eigenen Artikel dargestellt.
Da zur Terminierung keine realen Switche verwendet werden, sondern preisgünstige Server, landen mehrere BNG-Zuleitungen auf einem Server. Es ist sinnvoll, diese Zuleitungen zu aggregieren, um nicht für jede Zuleitung ein eigenes Terminierungsnetz verwalten zu müssen. Damit werden aus doppelt getaggten Paketen - dreifach getaggte. das zusätzliche A-Tag gibt an, welches Zuleitungs-Interface gerade angesprochen werden soll. Auch das wird in einem eigenen Artikel ausgeführt.
VLANs nach Aggregation Payload (z.B. IP) C-VLAN Tag S-VLAN Tag A-VLAN Tag Source-MAC Destination-MAC Da in jedem C-Vlan die MAC-Adressen des Kunden gleich sein dürfen, ist für die weitere Verarbeitung eine Trennung nach C-Vlans nötig. Auch QoS-Einstellungen sind dienstabhängig. Die C-Vlans stehen aber ganz innen im VLAN-Stapel. Es war notwendig, den Stapel zur rotieren, so dass aus der Abfolge C/S/A-Vlan die Abfolge S/A/C-Vlan wird. Nach dieser Rotation steht das C-Vlan direkt zur Verfügung und es kann je nach Dienst getrennt verarbeitet werden. Ein entsprechendes Netgraph-Modul ng_vlan_rotate wurde erstellt.
VLANs nach Rotation Payload (z.B. IP) S-VLAN Tag A-VLAN Tag C-VLAN Tag Source-MAC Destination-MAC Was nun noch bleibt, sollte eigentlich leicht sein: Die doppelt getaggten VLANs (außen A, innen S) müssen wieder auseinander genommen, und über ein Netgraph-Modul ng_bridge mit dem Ausgang zum Providernetz verbunden werden. Unglücklicherweise kann das Modul aber nur 32 Links verbinden, viel zu wenig! Aber wie verbindet man die Links nur bei Bedarf? Auch das wird in einem eigenen Artikel ausgeführt.
VLANs pro Dienst Payload (z.B. IP) S-VLAN Tag A-VLAN Tag Source-MAC Destination-MAC - Und woher kommen die QoS-Parameter, damit die Leitungen nicht überlastet werden? Die stehen in den DHCP-Paketen: Die DTAG schreibt in die Option82/9 die aktuelle Bandbreite rein. Das muss natürlich ausgewertet werden. Wenn man schon mal an der Stelle ist, kann man mit der Antwort vom DHCP-Server auf die gleiche Weise auch die verkaufte Produkt-Bandbreite übermitteln. Auch das wird in einem eigenen Artikel ausgeführt.
Alles zusammen genommen besteht das Netgraph Netzwerk aus folgenden Komponenten:
In den Tests zeigten sich dann weitere Probleme:
- Die MAC-Adress-Tabelle der ng_bridge und die Anzahl der VLANs an einem ng_vlan wird schnell so groß, dass die Daten nicht mehr ausgewertet werden können.
- Noch ein paar Daten mehr und sie passen nicht mal mehr durch die Kernel-API.
- Natürlich ist es komplett sinnfrei, auf dem Uplink zum ISP hin die MAC Adressen zu lernen. Das entschärft einen Großteil der Probleme.
Und tut's?