Peering, dynamisches Routing, BGP4
Wir haben im Abschnitt Routing? in sehr vereinfachter Weise die Grundfunktion eines Routers kennengelernt.
Eine der besonderne Eigenschaften von IP ist es jedoch, dass die Router auf Veränderungen in der Netzsituation reagieren können und Pakete für dasselbe Ziel über verschiedene Wege senden können.
Dieses Feature hat zunächst einmal die Funktion, einen Mechanismus bereitzustellen, der es erlaubt, auf Totalausfälle eines Netzknoten (Router) oder einer Netzkante (Verbindung Router-Router) zu reagieren und "um den Ausfall herumzurouten".
Nehmen wir wieder den einfachen Router aus dem Beispiel, dessen Routingtabelle so aussieht:
| net | netmask | gateway | interface |
| 192.168.1.0 | 255.255.255.0 | K1 | |
| 192.168.2.0 | 255.255.255.0 | K2 | |
| 0.0.0.0 | 0.0.0.0 | 192.168.0.1 | BB |
Wir wollen annehmen, dass der Kunde-1 neben dieser Internet-Anbindung noch über eine zweite Anbindung verfügt, z.B. über einen anderen ISP. Dieser ISP sei über eine Peer-Schnittstelle P von unserem Backbone-Rotuer erreichbar. Der Kunden-Anbindungsrouter wird von unserem BB-Router über das Interface K erreicht.
Der Backbone-Router hätte dann eine Tabelle, die auszugsweise so aussähe:
| net | netmask | gateway | metric | interface |
| 192.168.1.0 | 255.255.255.0 | 1 | K | |
| 192.168.1.0 | 255.255.255.0 | Peering | 200 | P |
| 192.168.2.0 | 255.255.255.0 | 1 | K |
Wir sehen hier ein neues Element der Routing-Tabelle namens Metric. Dieser Wert beschreibt, welches Gewicht diese Route gegenüber anderen Routen hat. In der Regel stehen dabei niedrige Werte für ein hohes Gewicht, es hilft, diesen Wert als "cost factor" zu verstehen.
Die Metric gibt also die Präferenz einer Route an. Dennoch bleibt die Routing-Tabelle nach Spezifität der Routen geordnet und nur bei zwei Routen gleicher Spezifität entscheidet die Metric darüber, welches Interface letzlich gewählt wird.
Wir sehen also, dass der Backbone-Router zwei Wege kennt, über die er Kunde-1 erreichen kann: einmal über das Interface K, über das der Kunden-Access Router angebuinden ist, einmal über das Interface P, über das dieser BB-Router mit einem anderen ISP verbunden ist, zu dem Kunde-1 dann wohl auch eine Leitung hat.
Der Kunden-Access-Router kann nun die Leitung zum Kunden überwachen, die verschiedenen Layer-2 Protokolle wie FrameRelay, PPP oder dergl. bieten dafür entsprechende Möglichkeiten.
Fällt die Leitung aus, so wird der Router dies als Ausfall des entsprechenden Interface registrieren. Ein Router entfernt in diesen Fällen alle Routen, die das ausgefallene Interface als Ziel haben, aus seiner Routing-Tabelle.
Diese Tabelle sieht nach dem Ausfall also wie folgt aus:
| net | netmask | gateway | interface |
| 192.168.2.0 | 255.255.255.0 | K2 | |
| 0.0.0.0 | 0.0.0.0 | 192.168.0.1 | BB |
Aus der sicht dieses Routers ist also der Kunde-1 nicht mehr bekannt, Pakete, die ihn als Ziel haben, werden über die default-route zum Backbone-Router weitergegeben.
doch dieser muß nun über den Ausfall ebenfalls noch informiert werden, denn er muß ja die Route
| 192.168.1.0 | 255.255.255.0 | 1 | K |
aus seiner aktiven Tabelle ebenfalls entfernen.
Zu diesem Zweck kommunizieren die Router untereinander über die aktuellen Routing-Tabellen, jedenfalls seit der Zeit, wo entsprechende Protokolle für die Router-Router-Kommunikation erdacht wurden.
Diese "Routing-Protokolle" sind Anwendungen von TCP/IP genau wie http oder ftp. Genau wie andere Anwendungsprotokolle übertragen sie Daten zwischen zwei Kommunikationspartnern.
Nur dass hier die Partner die Router sind, die die Transportleistungen erbringen.
Was da übertragen wird sind Daten, die letzlich in die Routing-Tabellen der Router eingetragen werden und dann, wie wir beim Routing gesehen haben, die Arbeit der Router bestimmen. Diese Daten sind völlig zu unrecht etwas geheimnisumwittert.
Es gibt eine ganze Reihe von Routing-Protokollen, z.B.
- RIP (Routing Information Protocol)
- OSPF (Open Shortest Path First)
- BGP4 (Border Gateway Protocol, Version 4)
und jedes von ihnen verfolgt einen anderen Ansatz und dient einem anderen Zweck bei der Ordnung des komerziellen Internet.
Anfänge
Eines der älteren Protokolle ist RIP, es ist bestechend einfach und im Fehlerfall unendlich dümmlich. Im Wesentlichen besteht das Protokoll darin, dass jeder Router allen seinen Nachbarn periodisch seine komplete Routing-Tabelle übermittelt. Dieser Nachbar kann daraus dann ermitteln, welche Adressen er erreichen kann, indem er das Paket an den Sender der RIP-Tabelle weitergibt.
Rip hat eine Vielzahl von Problemen: so ist das periodische Übertragen von großen Tabellen, die sich ja relten im Inhalt ändern, Verschwendung von Übertragungsbandbreite. Ausserdem wird ein Ausfall eines Routers mit RIP erst sehr viel später erkannt und so lange liegt eine echte Störung im Verkehr vor.
Rip wird zum Teil noch da eingesetzt, wo sich überschaubare Routing-Tabellen ergeben und diese sich relativ häufig ändern, z.B. zwischen einem Modem-Server (der Dialup-Kunden einen Zugang per Modem oder ISDN ermöglicht) und dem nächstgelegenen Backbone-Router.
Um Routing-Informationen innerhalb einer Organisationseinheit, z.B. einem Unternehmensnetzwerk oder auch bei einem ISP, zu pflegen eignet sich teilweise OSPF recht gut. Der Ansatz ist hier, dass jeder Router zu allen seinen Nachbarn eine Verbindung hält (eine TCP-Verbindung wird benutzt). Über diese Verbindung werden periodisch so etwas wie Seriennummern der Routing-Infos ausgetauscht. Ändert sich der Zustand eines Routers - z.B. weil eines seiner Interfaces den Betreibszustand wechselt, z.B. von "betriebsbereit" auf "down" - dann ändert sich die Seriennummer der Tabelle und der Router sendet ein passendes Update an alle seine Nachbarn. Diese propagieren das Update innerhalb der gesamten OSPF-Zone.
Die Router halten damit permanent alle Tabellen aktuell, nur die notwendigen Updates werden übermittelt (damit können auch grosse Routing-Tabellen aktuell gehalten werden: was sich nicht ändert verbraucht keine Bandbreite) und Stlörungen werden sehr schenll erkannt und umgangen.
OSPF verfolgt dabei den Ansatz des "vollständigen Wissens": jeder Router in einer OSPF-Zone hat genau die gleichen Routing-Informationen wie jeder andere Router; die Informationen sind synchron. Aus diesen OSPF-Daten errechnet jeder Router dann seine lokale Routing-Tabelle, die wie in Routing beschrieben den Paketweg bestimmt.
Der "full knowledge" Ansatz von OSPF ist aber an einigen Stellen nicht erwünscht, und hier kommt BGP4 dann zum Einsatz. Es ist das definitive Standardprotokoll Für Peerings im Internet.
Das Kunstwort Peering bedarf der getrennten Erläuterung?, für jetzt wollen wir auf
- Verbindung (Interconnect) zwischen den Netzen zweier ISP
verkürzen.
Auf einer solchen Verbindung wäre der "full knowledge" Ansatz aus OSPF natürlich völlig falsch: jeder ISP möchte die Interna seines Netzes vor den Wettbewerbern eher verbergen denn offenlegen.
Der Ansatz hier ist ein anderer: die beiden Router die hier "peeren" (wie gesagt: idR. Router verschiedener ISP, aber auch intern kann man BGP4 oft einsetzen), die also untereinander eine Verbindung (z.B. einfach ein Kabel oder eine Standleitung) haben, bauen auf dieser Leitung eine TCP-Verbindung auf. Auf dieser TCP-Verbindung tauschen sie nun permanent ihre BGP-Statusinformatgion aus.
Ähnlich wie bei OSPF werden dabei Änderungen am Status sofort weitergeleitet.
Die TCP-Verbindung dient ausserdem zur Überwachung der Betriebsfähigkeit der Leitung.
Die Informationen, die die beiden Router untereinander austauschen, betrifft ausschließlich den Verkehr auf der Verbindung zwischen den beiden Routern. Jeder Router merkt sich zu den Daten, über welche Verbindung (welches Peering) sie empfangen wurden; fällt diese Leitung aus - was ja implizit durch das BGP4-Protokoll mit überwacht wird - dann werden alle über diese Leitung empfangenen Daten verworfen.
Welche Daten ein ISP tatsächlich über ein solches Peering sendet, bleibt ganz in seiner Kontrolle: er entscheidet (in der Konfiguration des Peering-Routers) darüber, welche Netze er annonciert.
So ein Announcement (das wie oben beschrieben auf diese Peering-Verbindung beschränkt ist) hat dann eine Bedeutung wie "Alle Pakete mit einer Zieladresse in diesem Netz kannst Du mir auf dieser Leitung zustellen: ich kümmere mich dann darum".
Man kann also alle "eigenen Netze"? annoncieren oder nur einen Teil und so steuern, welche Nutzdaten man über diese Verbindung empfangen möchte.
Beide Peers in einem solchen Peering tun das gegenseitig und können so den Verkehr über die Leitung steuern.
Der wichtigste Aspekt ist aber, dass ein ISP jedes Netz über mehrere Peerings annonciert. Auf diese Weise ist (weitgehend) sichergestellt, dass der Ausfall einer Peering-Leitung nicht dazu führt, dass andere ISPs keine gültige Route mehr für die betroffenen Zieladressen kennen.
Innerhalb eines ISP-Transportnetzes werden alle über die verschiedenen Peerings gesammelten Informationen idR. weiterverteilt, sie bleiben nicht auf den einen Peering-Router beschränkt.
So erhält dann z.B. jeder Backbone-Router Informationen über alle Peerings und kann daraus seine Routing-Tabelle errechnen. Diese enthält dann für ein Zielnetz idR. mehrere alternative Routen (wie wir oben gesehen haben). Die Metrik der Route wird dabei auch aus den per BGP4 empfangenen Informationen errechnet. Fällt eine dieser Routen weg, so wird dann eine alternative Route mit schlechterer Metrik verwendet.
Wirkungsweisen
Das Prinzip bei BGP4 ist, dass der annoncierende Router (also der Betreiber dieses Routers) selektiv nur die Informationen heruasgibt, die er herausgeben soll.
Gleichzeitig kann der empfangede Router diese Informationen nochmals bearbeiten, er kann z.B. Teile davon verwerfen.
Dabei haben die beiden Peers keinerlei Einfluß auf das, was die andere Seite tut, und müssen das auch nicht haben.
BGP4 ist wegen des Prinzips der selektierten Routing-Information ideal geeignet, ein Zusammenwirken von Wettbewerbern zu organisieren - und genau das ist das komerzielle Internet ja.
der Name Boarder Gateway Protocol kommt dann auch aus dieser Funktion: die Peering-Router bilden die Grenzübergänge zwischen den Netzen verschiedener Betreiber.
Teil dieser Selektivität ist die Aggregation von Routing-Informationen am Peering. Zum Aggregieren fühlte man sich in der alten Zeit per Gentleman Agreement verpflichtet, in der neuen Zeit (der Peering-Verträge) wird diese Verpflichtung vertraglich festgelegt.
Aggregation bedeutet hier z.B., dass man am Peering grössere Netze annonciert als man intern verwendet.
In unserem Routing-Beispiel hatten wir Netze mit je 255 Adressen (also /24-Netze nach der CIDR? Notation) für die Kunden angenommen.
Doch nicht diese Netze würde man am Peering annoncieren sondern einen grösseren Block, z.B. den 65536 Adresen umfassenden Block 192.168.0.0 bis 192.168.255.255 (oder einfach 192.168.0.0/16 ind CIDR Notation).
Die internen Details über die Verteilung deises Blockes auf einzelne ISP-Kunden verbirgt man - und verkleinert so die Routing-Tabelle beim Peer, denn statt rund 250 einzelner Routen (angenommen, der Block sei komplett mit /24er Kunden besetzt) wird dem Peer nur eine einzige Route annonciert, die alles abdeckt.
Selbst bei sachgerechter Aggregation umfassen die Route-Sets, die an einem Peering ausgetauscht werden, mehrere tausen Routen und die gesammelte Peering-Information über 100.000 Routen.
Bitte beachten Sie, dass ein Router immer alle Routen der Reihe nach auswerten muß um das Ziel für ein Paket zu finden. Dabei stehen in der Tabelle zunächst die Routen, die geringe Spezifität haben, also auch eine geringe Wahrscheinlichkeit, die Route eines Paketes zu bestimmen. Im Mittel sind daher 2/3 aller Routen oder mehr für jedes einzelne Paket auszuwerten.
Grössere Routing-Tabelle erzeugen damit eine grössere Last auf dem Router bei gleicher Verkehrslast - und der Rechenleistung ist immer eine Grenze gesetzt.
