Kapitel 1. Einführung in MPLS und SDN
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
In diesem Kapitel werden die grundlegenden Konzepte von Multiprotocol Label Switching (MPLS) und Software-Defined Networking (SDN) vorgestellt. Diese Technologien wurden nicht ohne Grund entwickelt, und ein guter Weg, sie in den richtigen Kontext zu stellen, ist, ihre Geschichte zu verstehen. Obwohl MPLS heute zahllose Anwendungen und Einsatzgebiete hat, wurde es ursprünglich entwickelt, um ein ganz bestimmtes Problem im Internet zu lösen.
Das Internet
Das Internet ist eine Sammlung von autonomen Systemen(AS). Jedes AS ist ein Netzwerk, das von einer einzelnen Organisation betrieben wird und über Routing-Verbindungen zu einem oder mehreren benachbarten AS verfügt.
AS-Nummern im Bereich von 64512 bis 65534 sind für den privaten Gebrauch reserviert. Obwohl die Beispiele in diesem Buch AS-Nummern aus diesem Bereich verwenden, nutzen Internet Service Provider (ISPs) in der Praxis öffentliche AS-Nummern, um mit ihren benachbarten AS zu kommunizieren.
Traditionell waren AS-Nummern 16 Bit (2 Byte) lang, aber neuere Protokollimplementierungen unterstützen auch AS-Nummern, die 32 Bit (4 Byte) lang sind.
Abbildung 1-1 zeigt einen sehr vereinfachten Blick auf das Internet. Hier sehen wir uns Annika an, eine beliebige Internetnutzerin. Sie lebt in Europa, hat zu Hause einen drahtgebundenen Internetanschluss und arbeitet in einem großen Unternehmen, das ebenfalls mit dem Internet verbunden ist. Das Unternehmen, in dem Annika beschäftigt ist, hat zufällig eine eigene AS-Nummer (65001) - das ist keine Voraussetzung für den Internetzugang des Unternehmens. Zufälligerweise ist dieses Unternehmen über denselben Internetanbieter (AS 65000) mit dem Internet verbunden, den Annika für ihren privaten Zugang nutzt.
Abbildung 1-1. Das Internet - ein Tag im Leben von Annika
Wie in der Abbildung zu sehen ist, hat Annika zwei Freunde, die ebenfalls ISP-Abonnenten sind:
-
Ruijiao lebt in Ozeanien und verbindet sich mit ihrem Mobiltelefon mit AS 65100.
-
Luis lebt in Südamerika und verbindet sich mit seinem Laptop mit der AS 65005.
Annika nutzt auch die Public-Cloud-Dienste eines Anbieters in Afrika (65201) und konsumiert Inhalte von verschiedenen Anbietern in Asien (AS 65510), Europa (AS 65002) und Nordamerika (AS 64900).
Abbildung 1-1 zeigt verschiedene Arten von Anbietern. Die folgende Liste beschreibt sie:
- Inländische ISPs
- In diesem Beispiel laufen Annikas private und geschäftliche Internetverbindungen über einen inländischen ISP (AS 65000), der den Internetzugang in einem bestimmten Land, Staat oder einer Region anbietet. Auch Ruijiao und Luis sind über inländische Internetanbieter (AS 65100 bzw. AS 65005) mit dem Internet verbunden.
- Globale ISPs
- 101.230 Die inländischen ISP, mit denen Annika (AS 65000) und Luis (AS 65005) verbunden sind, gehören zu derselben globalen ISP-Gruppe, die in mehreren Ländern in Europa und Amerika vertreten ist. Dieser globale ISP nutzt ein bestimmtes Netzwerk (AS 65010), um alle inländischen ISP der Gruppe miteinander zu verbinden. Darüber hinaus verbinden globale ISPs auch ihre inländischen ISPs mit dem Rest der Welt.
- Content- und Cloud-Provider
- Diese Dienstanbieter (SPs) generieren keine Einnahmen, indem sie den Abonnenten den Internetzugang in Rechnung stellen. Stattdessen stellen sie den Nutzern auf der ganzen Welt andere Arten von Diensten zur Verfügung. Sie bieten zum Beispiel Multimedia-, Hosting- und Cloud-Dienste an.
- Transitanbieter
- Dies sind in der Regel große Tier-1-Netzwerke, die das Internet-Skelett bilden. Ihre Kunden sind andere SPs. Wenn zwei SPs nicht direkt miteinander verbunden sind, erreichen sie sich normalerweise über einen oder mehrere Transitanbieter.
In der Praxis ist diese Einteilung ein wenig unscharf. Die meisten SPs versuchen, ihre Portfolios zu diversifizieren, indem sie einen Anteil aus mehr als einem dieser Märkte erhalten.
Es gibt noch eine weitere wichtige Information in Abbildung 1-1: Die Links, die AS miteinander verbinden, haben Router an ihren Endpunkten. Achte auf die Symbole, die für Junos und IOS XR verwendet werden, denn diese Konvention wird in diesem Buch durchgängig verwendet.
Ein Router, der sich an der Grenze eines AS befindet und eine Verbindung zu einem oder mehreren externen AS herstellt, wird AS Border Router (ASBR) genannt. Internet-ASBRs kommunizieren miteinander über das Border Gateway Protocol (BGP), das in RFC 4271 beschrieben ist. BGP läuft auf dem Transmission Control Protocol (TCP); es wird externes BGP (eBGP) genannt, wenn die Endpunkte der Sitzung in verschiedenen AS liegen. Internet eBGP ist für die Verteilung der globalen IPv4- und IPv6-Routing-Tabellen zuständig. Erstere enthält bereits mehr als eine halbe Million Präfixe und wächst ständig weiter.
Und das ist das Internet einige Bausteine (ASs), Verbindungen und ein Protokoll (eBGP), das die Routing-Informationen weltweit verteilt. Abbildung 1-1 ist eine vereinfachte Darstellung des Internets; in Wirklichkeit sieht es eher wie Abbildung 1-2 aus.
Abbildung 1-2. Das Internet im Jahr 2011 - Topologie der autonomen Systeme (Copyright © Peer1 Hosting; verwendet mit Genehmigung)
Dieses großartige Bild, das von seinem Besitzer, Peer1 Hosting, zur Verfügung gestellt wurde, stellt ASs als Knotenpunkte dar. Die Beschreibung von Peer1 zu diesem Bild lautet wie folgt:
Dieses Bild zeigt einen Graphen mit 19.869 AS-Knoten, die durch 44.344 Verbindungen verbunden sind. Die Größe und Anordnung der AS basiert auf ihrer Eigenvektor-Zentralität, die ein Maß dafür ist, wie zentral jede AS im Netzwerk ist - eine AS ist zentral, wenn sie mit anderen AS verbunden ist, die zentral sind. Dies ist das gleiche graphentheoretische Konzept, das auch dem PageRank-Algorithmus von Google zugrunde liegt.
Das Layout des Graphen beginnt mit den zentralsten Knoten und geht weiter zu den am wenigsten zentralen Knoten, die auf einem Raster platziert werden, das nach jeder Größenordnung der Zentralität unterteilt wird. Innerhalb der Beschränkungen der aktuellen Unterteilungsebene werden die Knoten so nah wie möglich an den zuvor platzierten Knoten platziert, mit denen sie verbunden sind.
Hinweis
Bis jetzt hat diese Beschreibung des Internets noch nichts mit MPLS zu tun. Um die ursprüngliche Motivation für MPLS zu verstehen, musst du einen Blick in ein AS werfen.
Nimm dir die Zeit, um die Topologie zu verstehen, die in den ersten acht Kapiteln dieses Buches verwendet wird. Es ist eine lohnende Investition von Zeit.
ISP Beispiel Topologie
Diese Topologie baut auf dem vorherigen Beispiel auf. Annika arbeitet und ihr Laptop ist H1. Irgendwann stellt sie fest, dass sie einige Daten vom Anbieter (genauer gesagt von H3) abrufen muss.
Hinweis
Vergessen wir für den Moment die Network Address Translation (NAT) und stellen wir uns vor, dass alle Adressen tatsächlich öffentlich sind.
Abbildung 1-3. Grundlegende ISP-Topologie
Mehr als die Hälfte der für dieses Buch erstellten Laborszenarien laufen auf einem einzigen Server. Der Hypervisor erzeugte virtuelle Maschinen (VMs) mit Junos oder IOS XR, die intern über einen vSwitch/vRouter verbunden waren.
Um jeden Router herum siehst du Zahlen in Kreisen. Dies sind die Nummern der Netzwerkschnittstellen. Wenn die Zahl innerhalb des Kreises zum Beispiel <#> ist, lautet die tatsächliche Portnummer wie folgt:
-
Auf Geräten mit Junos, ge-2/0/<#>
-
Auf Geräten mit IOS XR, Gi 0/0/0/<#>
Diese Konvention wird im ganzen Buch verwendet.
Alle Inter-Router-Verbindungen sind Punkt-zu-Punkt (/31), mit Ausnahme der Mehrpunktverbindung 10.2.0.0/24. Obwohl die letztgenannte Topologie auch im WAN-Zugang zu finden ist, wird sie zunehmend als veraltet angesehen. Betrachten wir diese LANs vorerst als klassische /24 IPv4-Subnetze und ignorieren wir, wie sie tatsächlich eingerichtet sind.
Der ISP in diesem Beispiel betreibt eine einzelne Level 2 IS-IS-Domäne mit Punkt-zu-Punkt-Schnittstellen. Die Verbindungen PE1-PE2 und PE3-PE4 sind mit der symmetrischen IS-IS-Metrik 100 konfiguriert, während die übrigen Kernverbindungen (PE-P und P-P) mit der Standard-IS-IS-Metrik 10 belassen werden. Diese Metriken sind in eckigen Klammern in Abbildung 1-3 dargestellt.
Warnung
Stelle sicher, dass die RRs mit dem IS-IS-Überlastungsbit oder mit hohen Metriken für Open Shortest-Path First (OSPF) konfiguriert sind, damit sie keinen Transitverkehr anziehen.
Router-Typen bei einem Dienstanbieter
Obwohl sie auf den ersten Blick ähnlich aussehen, spielen das Unternehmen (AS 65001) und der Inhaltsanbieter (AS 65002) aus Sicht des ISP (AS 65000) eine andere Rolle:
-
Das Unternehmen ist ein Firmenkunde, der den ISP für den Internetzugang bezahlt. Es kann aus Gründen der Redundanz bei mehr als einem ISP untergebracht sein, aber im Großen und Ganzen ist die Beziehung zwischen dem Unternehmen und dem ISP die eines traditionellen Kunden und Anbieters.
-
Der Inhaltsanbieter hat eine Peering-Beziehung zu mehreren ISPs, darunter AS 65000, AS 64777 und andere. Das Geschäftsmodell ist komplexer und es gibt keine klare Kunden-Anbieter-Beziehung: Die SPs treffen Vereinbarungen darüber, wie sie den Datenverkehr abrechnen.
Die Geräte in Abbildung 1-3 spielen aus der Perspektive des AS 65000 unterschiedliche Rollen, die wir in den folgenden Abschnitten untersuchen werden.
Kundenausrüstung
CE1 und CE2 in Abbildung 1-3 sind Kundengeräte (Customer-Premises Equipment, CPE), die auch als Kundengeräte (CE) bezeichnet werden. Traditionell befinden sie sich physisch in den Anlagen des Kunden. In der SDN-Ära ist es auch möglich, einige ihrer Funktionen zu virtualisieren und sie im SP-Netzwerk zu betreiben: Diese Lösung wird als virtuelle CPE oder vCPE bezeichnet.
Denken wir zunächst an herkömmliche CEs, die sich im Netzwerk eines Kunden befinden. Für den Betrieb und die Verwaltung des CE ist entweder der ISP oder der Kunde oder beide zuständig. Wir können CEs wie folgt klassifizieren:
- Wohnen
- Das können DSL-Modems, FTTH ONTs und so weiter sein. Sie führen keine Routing-Protokolle aus und werden von der IP-Schicht des ISP als direkt verbunden angesehen.
- Mobil
- Das sind Smartphones, Tablets und so weiter. Sie führen auch keine Routing-Protokolle aus und werden von der IP-Schicht des ISP als direkt verbunden angesehen.
- Organisatorisches
- Dabei handelt es sich um dedizierte physische oder virtuelle Router, die eine Reihe zusätzlicher Netzwerkfunktionen implementieren können (oder auch nicht). Sie verfügen in der Regel über statisches oder dynamisches Routing zum ISP. eBGP ist das am häufigsten verwendete - und am besten skalierbare - dynamische Protokoll. Wenn das Unternehmen an mehrere ISPs angebunden ist, ist eBGP die einzig sinnvolle Option.
Hinweis
Bei der Organisation kann es sich um ein externes Unternehmen, eine interne ISP-Abteilung, eine staatliche Einrichtung, einen Campus, eine NGO und so weiter handeln.
Schauen wir uns nun die verschiedenen Funktionen an, die von den Core (Backbone) Routern des ISP (AS 65000) ausgeführt werden: PE1, PE2, P1, P2, PE3 und PE4.
Die Kante des Kernanbieters
Provider Edge (PE) ist eine Kantenfunktion, die von ISP-eigenen Kernnetzgeräten ausgeführt wird, die sowohl externe Verbindungen zu CEs als auch interne Verbindungen zu anderen Kernroutern haben. PE1 und PE2 in Abbildung 1-3 übernehmen die PE-Funktion, wenn sie den Verkehr zwischen CEs und anderen Core-Routern weiterleiten.
Der Core-Provider
Provider (P) ist eine Kernfunktion, die von ISP-eigenen Core-Routern ausgeführt wird, die interne Backbone-Verbindungen zu mehr als einem anderen Core-Router haben. P1 und P2 sind reine P-Router, da sie keine Verbindungen zu externen Providern oder zu Kunden haben. PE1, PE2, PE3 und PE4 können die P-Rolle übernehmen, wenn sie Verkehr zwischen zwei Core-Schnittstellen weiterleiten. Wenn PE1 zum Beispiel ein Paket auf ge-2/0/3 empfängt und es über ge-2/0/4 weiterleitet, agiert er als P-Router.
Die Grenz-ASBR
ASBR ist eine Kantenfunktion, die von ISP-eigenen Core-Routern ausgeführt wird, die externe eBGP-Peerings zu anderen SPs aufbauen. Obwohl PE1 und PE2 eBGP-Sitzungen zu CE1 und CE2 aufbauen können, werden sie nicht als ASBRs betrachtet, weil die Gegenstelle ein Kunde und kein SP ist.
PE3, PE4, BR1 und BR2 hingegen sind ASBRs und erfüllen diese Funktion, wenn sie Datenverkehr zwischen externen und internen Schnittstellen weiterleiten. Wenn PE3 zum Beispiel ein Paket auf ge-2/0/1 empfängt und es an ge-2/0/3 weiterleitet, verhält er sich wie ein ASBR.
Der Inhaltsanbieter (AS 65002) in Abbildung 1-3 verfügt über ein stark vereinfachtes Netzwerk. Das ist in Ordnung, da der Schwerpunkt hier auf dem ISP (AS 65000) liegt.
Hosts
Der Zweck der Hosts (H) H1 und H3 in diesem Beispiel ist es, Ping und Traceroute auszuführen, daher ist ihr Betriebssystem nicht sehr wichtig. In diesem Beispiel sind diese Hosts VMs, auf denen zufällig IOS XR läuft; daher das Router-Symbol für einen Host.
H1 gehört zum Intranet des Kunden, und H3 ist mit dem Kern des Content Providers verbunden. Weder H1 noch H3 verwenden Routing-Protokolle.
BGP-Konfiguration
Intermediate System-to-Intermediate System (IS-IS) bietet eine Loopback-to-Loopback-Verbindung innerhalb des ISP, die für den Aufbau der internen Multihop-BGP-Sitzungen (iBGP) erforderlich ist.
Abbildung 1-4 zeigt die BGP-Sitzungen und ihre Endpunkte: Loopback-Adressen für iBGP und Link-Adressen an der Grenze (eBGP).
Abbildung 1-4. Internet eBGP- und iBGP-Sitzungen
BGP-Konfiguration - PEs und ASBRs mit Junos
Beispiel 1-1 zeigt die BGP-Konfiguration auf PE1.
Beispiel 1-1. BGP-Konfiguration auf PE1 (Junos)
1 routing-options {
2 autonomous-system 65000;
3 }
4 protocols {
5 bgp {
6 group iBGP-RR {
7 type internal;
8 local-address 172.16.0.11;
9 family inet {
10 unicast {
11 add-path {
12 receive;
13 send {
14 path-count 6;
15 }
16 }
17 }
18 }
19 export PL-iBGP-RR-OUT;
20 neighbor 172.16.0.201;
21 neighbor 172.16.0.202;
22 }
23 group eBGP-65001 {
24 family inet {
25 unicast;
26 }
27 peer-as 65001;
28 neighbor 10.1.0.0 {
29 export PL-eBGP-65001-CE1-OUT;
30 }
31 neighbor 10.1.0.6 {
32 export PL-eBGP-65001-CE2-OUT;
33 }
34 }
35 }
36 }
37 policy-options {
38 policy-statement PL-iBGP-RR-OUT {
39 term NHS {
40 from family inet;
41 then {
42 next-hop self;
43 }
44 }
45 }
46 policy-statement PL-eBGP-65001-CE1-OUT {
47 term BGP {
48 then {
49 metric 100;
50 }
51 }
52 }
53 policy-statement PL-eBGP-65001-CE2-OUT {
54 term BGP {
55 then {
56 metric 200;
57 }
58 }
59 }
60 }
PE1 und PE3 haben eine ähnliche Konfiguration. Die unterschiedlichen Geschäftsbeziehungen zu den Peering-Anbietern ändern nichts an der Tatsache, dass das Protokoll dasselbe ist: eBGP.
Die Zeilen 6 bis 22 enthalten die Loopback-to-Loopback-Konfiguration für die iBGP-Sitzungen von PE1-RR1 und PE1-RR2. Die Add-Path-Funktionalität (Zeilen 11 bis 16) wird später erklärt.
Wenn ein Router ein Präfix in iBGP neu ankündigt, ändert er das ursprüngliche BGP-Nächster-Hop-Attribut standardmäßig nicht. Wenn PE1 also die Route 10.1.12.0/24 an die RRs weiterleitet, lautet der BGP-Nächste-Hop der Route 10.1.0.0. Dieser Nächste-Hop ist von innerhalb des ISP nicht erreichbar, z. B. von PE3 und PE4, was die BGP-Route nutzlos macht. Die sauberste Lösung besteht darin, PE1 zu veranlassen, das BGP-Nächster-Hop-Attribut auf seinen eigenen Loopback umzuschreiben (Zeile 19 und Zeilen 38 bis 45), bevor die Route über iBGP bekannt gegeben wird.
Die Zeilen 23 bis 34 enthalten die eBGP-Konfiguration für die Single-Hop-Verbindungen PE1-CE1 und PE1-CE2. Die eBGP-Routenrichtlinien (Zeilen 29, 32 und 46 bis 59) werden gleich erklärt.
BGP-Konfiguration - RRs mit Junos
Diese BGP-Konfiguration an RR1 ist der von PE1 sehr ähnlich, hat aber einen entscheidenden Unterschied, wie in Beispiel 1-2 gezeigt wird, bei dem die Nachbarn der Kürze halber weggelassen werden.
Beispiel 1-2. BGP-Konfiguration an RR1 (Junos)
1 protocols {
2 bgp {
3 group iBGP-CLIENTS {
4 cluster 172.16.0.201;
5 }}}
Was RR1 zu einem Route Reflector macht, ist Zeile 4. Ohne sie würde die Standard-iBGP-Regel - iBGP-Routen dürfen nicht über iBGP revertiert werden - gelten.
Das Peering mit dem anderen RR (RR2) ist als neighbor auf einer anderen group konfiguriert, die nicht die Anweisung cluster enthält.
BGP-Konfiguration - PEs und ASBRs unter IOS XR
PE2 und PE4 haben eine ähnliche Konfiguration. Beispiel 1-3 zeigt die Konfiguration von PE2.
Beispiel 1-3. BGP-Konfiguration auf PE2 (IOS XR)
1 router bgp 65000 2 address-family ipv4 unicast 3 additional-paths receive 4 additional-paths send 5 ! 6 neighbor-group RR 7 remote-as 65000 8 update-source Loopback0 9 address-family ipv4 unicast 10 route-policy PL-iBGP-RR-OUT out 11 ! 12 neighbor 10.1.0.2 13 remote-as 65001 14 address-family ipv4 unicast 15 route-policy PL-eBGP-65001-IN in 16 route-policy PL-eBGP-CE2-OUT out 17 ! 18 neighbor 10.1.0.4 19 remote-as 65001 20 address-family ipv4 unicast 21 route-policy PL-eBGP-65001-IN in 22 route-policy PL-eBGP-CE1-OUT out 23 ! 24 neighbor 172.16.0.201 25 use neighbor-group RR 26 ! 27 neighbor 172.16.0.202 28 use neighbor-group RR 29 ! 30 ! 31 route-policy PL-iBGP-RR-OUT 32 set next-hop self 33 end-policy 34 ! 35 route-policy PL-eBGP-CE1-OUT 36 set med 200 37 pass 38 end-policy 39 ! 40 route-policy PL-eBGP-CE2-OUT 41 set med 100 42 pass 43 end-policy 44 ! 45 route-policy PL-eBGP-65001-IN 46 pass 47 end-policy
Die Syntax ist anders, aber die Prinzipien sind denen von Junos sehr ähnlich. Die Add-Path-Funktionalität (Zeilen 3 bis 4) wird später erklärt.
Ein bemerkenswerter Unterschied zwischen der BGP-Implementierung von Junos und IOS XR ist, dass IOS XR standardmäßig den Empfang und die Bekanntgabe von Routen über eBGP blockiert. Es gibt zwei alternative Möglichkeiten, dieses Standardverhalten zu ändern:
-
Konfiguriere explizit Eingangs- und Ausgangsrichtlinien (Zeilen 15 bis 16, 21 bis 22 und 35 bis 47), damit IOS XR eBGP-Routen signalisieren kann.
-
router bgp 65000 bgp unsafe-ebgp-policykonfigurieren. Dies ist eine Abkürzung, die du für eine schnelle Konfiguration verwenden kannst, was besonders im Labor nützlich ist. Dieser Befehl erstellt automatisch die Richtlinien "pass all" und fügt sie hinzu
Hinweis
Aus Platzgründen werden Junos- und IOS XR-Konfigurationsbeispiele ab diesem Punkt mit zusammengeführten Zeilen dargestellt.
BGP-Konfigurations-RRs unter IOS XR
Die in Beispiel 1-4 gezeigte BGP-Konfiguration an RR2 ist der von PE2 sehr ähnlich, weist aber einige Unterschiede auf.
Beispiel 1-4. BGP-Konfiguration an RR2 (IOS XR)
1 router bgp 65000 2 address-family ipv4 unicast 3 additional-paths receive 4 additional-paths send 5 ! 6 neighbor-group iBGP-CLIENTS 7 cluster-id 172.16.0.202 8 address-family ipv4 unicast 9 route-reflector-client 10 !
Was RR2 zu einem Route Reflector macht, sind die Zeilen 7 und 9. Ohne sie würde die Standard-iBGP-Regel - iBGP-Routen dürfen nicht über iBGP revertiert werden - gelten.
Das Peering mit dem anderen RR (RR1) wird nicht über diese neighbor-group konfiguriert.
BGP-Routensignalisierung und Redundanz
In diesem Buch werden drei BGP-Redundanzmodelle betrachtet - nicht redundant, aktiv-backup und aktiv-aktiv - und sie werden alle von der Topologie in Abbildung 1-3 unterstützt.
Nicht-redundante BGP-Routen
In diesem Beispiel werben CEs und BRs ihre eigenen Loopacks bei einem einzigen eBGP-Peer:
-
CE1 bewirbt 192.168.10.1/32 nur bei PE1.
-
CE2 bewirbt 192.168.10.2/32 nur bei PE2.
-
BR3 bewirbt 192.168.20.3/32 nur bei PE3.
-
BR4 bewirbt 192.168.20.4/32 nur bei PE4.
Wenn eine eBGP-Sitzung fehlschlägt, ist der Loopback des betroffenen CE oder BR nicht mehr über AS 65000 erreichbar. Dieses Szenario tritt häufig in Single-Homed-Access-Topologien auf. In diesem Beispiel wird es simuliert, indem die lokale Loopback-Ankündigung von CE1 und CE2 selektiv blockiert wird (eBGP-Exportrichtlinien) und indem nur eine eBGP-Sitzung an jedem BR konfiguriert wird.
Abbildung 1-5 zeigt den Prozess der Loopback-Routen-Signalisierung von CE1.
Abbildung 1-5. Internet eBGP und iBGP Routensignalisierung - CE1 Loopback
Der Loopback von CE1 ist mit PE1 verbunden, sodass ein Paket, das ein Gerät in AS 65002 an den Loopback von CE1 sendet, irgendwann über PE1 gehen sollte.
Die RRs ändern den Wert der Attribute BGP next hop und AS path nicht, wenn sie die Route zu PE2, PE3 und PE4 reflektieren.
Auf der anderen Seite gibt PE2 die Route nicht an CE2 weiter, da dies zu einer AS-Schleife führen würde. Dieses Verhalten, das du mit dem Konfigurationsbefehl as-override ändern kannst, wird in Kapitel 3 näher erläutert.
Abbildung 1-6 zeigt den Prozess der Loopback-Routen-Signalisierung von BR4.
Abbildung 1-6. Internet eBGP und iBGP Routensignalisierung-BR4 Loopback
Der Loopback von BR4 ist mit PE4 verbunden, so dass ein Paket, das ein Gerät in AS 65001 an den Loopback von BR4 sendet, irgendwann über PE4 gehen sollte.
Auf der linken Seite von Abbildung 1-6 gibt es eine zusätzliche Redundanzstufe. CE1 zieht es vor, BR4 über PE1 zu erreichen (Multi Exit Discriminator [MED] 100 ist besser als MED 200), aber wenn die eBGP-Sitzung zwischen CE1 und PE1 fehlschlägt, kann es immer noch auf PE2 umschalten.
In Abwesenheit von Ausfällen der Zugangsverbindung:
Active-Backup BGP-Routen
Wie du in Abbildung 1-7 sehen kannst, werben BR3 und BR4 beide für die Route 10.2.34.0/24, aber sie tun dies mit einem anderen MED. Daher ziehen es PE1 und PE2 vor, BR4 über PE4 zu erreichen. Wenn PE4 aus irgendeinem Grund die Route 10.2.34.0/24 nicht mehr bewirbt (oder wenn die Route ungültig ist), können PE1 und PE2 auf PE3 fehlschlagen.
Abbildung 1-7. Internet eBGP und iBGP Routensignalisierung - Subnetz von H3
H1 hat eine Standardroute, die auf die virtuelle IPv4-Adresse 10.1.12.100 zeigt. CE1 und CE2 führen das Virtual Router Redundancy Protocol (VRRP) im Host-LAN aus, und wenn es keine Ausfälle gibt, ist CE1 der VRRP-Master, der die Adresse 10.1.12.100 hält. Andererseits ist die VRRP-Routenverfolgung so konfiguriert, dass CE2 zum VRRP-Master wird, wenn CE1 keine Route hat, um H3 zu erreichen, CE2 aber schon. Der Mechanismus ist zwischen BR3 und BR4 sehr ähnlich, nur dass in diesem Fall BR4 der nominelle VRRP-Master ist.
Schließlich ist das MED-Schema in den eBGP-Exportrichtlinien von PE1 und PE2 so konfiguriert, dass CE1 H3 lieber über PE1 als über PE2 erreicht. Wenn alle Verbindungen und Sitzungen aufgebaut sind, ist der Pfad, dem die Pakete H1→H3 (10.1.12.10→10.2.34.30) folgen, CE1-PE1-PE4-BR4. Das VRRP-Mastership auf dem ersten Hop und MED auf den verbleibenden Hops sind die Mechanismen, um den besten Pfad zu wählen.
Aktiv-Aktiv BGP-Routen
PE1 und PE2 haben beide eine eBGP-Route nach 10.1.12.0/24 mit MED 100, also werben beide die Route mit MED 100 bei den RRs, wie du in Abbildung 1-8 sehen kannst.
Abbildung 1-8. Internet eBGP und iBGP Routensignalisierung-H1's Subnetz
Der Pfad, dem die Pakete H3→H1 folgen, ist BR4-PE4-PE2-CE2. PE4 bevorzugt PE2, weil der MED-Wert für beide BGP Next Hops (PE1 und PE2) 100 beträgt und die IGP-Metrik des kürzesten internen Pfads PE4→PE2 niedriger ist als die IGP-Metrik von PE4→PE1. Ebenso bevorzugt PE3 PE1, aber BR4 ist der VRRP-Master, also befindet sich PE3 nicht im nominalen H3→H1-Pfad.
Das Endergebnis ist eine asymmetrische, aber optimale Weiterleitung der Ströme H1→H3 und H3→H1. Es ist optimal, weil die RRs alle Routen berücksichtigen, nicht nur die, die sie für die besten halten, wie in Beispiel 1-5 gezeigt.
Beispiel 1-5. iBGP Route Reflection mit Add-Path-RR1 (Junos)
1 juniper@RR1> show route advertising-protocol bgp 172.16.0.44 2 10.1.12.10 3 4 inet.0: 33 destinations, 38 routes (33 active, ...) 5 Prefix Nexthop MED Lclpref AS path 6 * 10.1.12.0/24 172.16.0.11 100 100 65001 I 7 172.16.0.22 100 100 65001 I 8 9 juniper@RR1> show route advertising-protocol bgp 172.16.0.44 10 10.1.12.0/24 detail 11 12 inet.0: 33 destinations, 38 routes (33 active, ...) 13 * 10.1.12.0/24 (3 entries, 2 announced) 14 BGP group CLIENTS type Internal 15 Nexthop: 172.16.0.11 16 MED: 100 17 Localpref: 100 18 AS path: [65000] 65001 I 19 Cluster ID: 172.16.0.201 20 Originator ID: 172.16.0.11 21 Addpath Path ID: 1 22 BGP group CLIENTS type Internal 23 Nexthop: 172.16.0.22 24 MED: 100 25 Localpref: 100 26 AS path: [65000] 65001 I 27 Cluster ID: 172.16.0.201 28 Originator ID: 172.16.0.22 29 Addpath Path ID: 2
Dies ist dank der Add-Path-Erweiterungen (Zeilen 21 und 29) möglich. Ohne diese Erweiterungen würde RR1 die Route mit der besten IGP-Metrik aus seiner eigenen Perspektive wählen - vom RR zum nächsten BGP-Hop -, was nicht unbedingt mit der Perspektive von PE4 übereinstimmt.
Zusammenfassend lässt sich sagen, dass die Richtlinien so konfiguriert sind, dass die MED- oder BGP-Metrik symmetrisch festgelegt ist. Im Folgenden sind die Ergebnisse aufgeführt:
-
CE1 zieht es vor, H3 über PE1 zu erreichen, anstatt über PE2.
-
CE2 zieht es vor, H3 über PE2 zu erreichen, anstatt über PE1.
-
PE1 zieht es vor, H1 über CE1 zu erreichen, anstatt über CE2.
-
PE2 zieht es vor, H1 über CE2 zu erreichen, anstatt über CE1.
-
PE1 und PE2 erreichen H3 lieber über PE4 als über PE3.
-
PE3 und PE4 erreichen H1 bevorzugt über PE1 bzw. PE2.
Weiterleitung von Paketen in einem BGP-losen Kern
Bis jetzt ist alles in Ordnung, bis auf ein wichtiges Detail: H1 und H3 können nicht miteinander kommunizieren. Nehmen wir das Beispiel eines IPv4-Pakets mit Quelle H1 und Ziel H3. PE1 beschließt, das Paket über PE4 weiterzuleiten, aber PE1 und PE4 sind nicht direkt miteinander verbunden. Der kürzeste Weg von PE1 zu PE4 ist PE1-P1-P2-PE4. Daher sendet PE1 das Paket an seinen nächsten Hop, P1. Hier liegt das Problem: P1 spricht kein BGP und hat daher keine Route zum Ziel H3. Infolgedessen verwirft P1 das Paket.
Wie wäre es mit der Einrichtung von iBGP-Sitzungen zwischen P1 und den RRs? Das ist eine relativ gängige Praxis in großen SPs mit High-End-Kerngeräten. Im echten Internet gibt es mehr als eine halbe Million Routen, und es werden immer mehr. Auch wenn eine Routenzusammenfassung möglich ist, bedeutet es für P1 eine erhebliche Belastung der Control-Plane, alle notwendigen BGP-Routen zu programmieren. Außerdem würde P1 bei Änderungen der Netzwerktopologie an Agilität verlieren, weil es viele Routen auf der Forwarding-Plane neu programmieren müsste.
P1 und P2 sind interne Core-Router (sie haben keine eBGP-Peerings), und ihre Aufgabe ist es, Pakete so schnell und zuverlässig wie möglich zwischen Kanten-Routern wie PE1, PE2, PE3 und PE4 zu übertragen. Dies ist möglich, wenn PE1 dem IPv4-Paket H1→H3 einen zusätzlichen Header - oder eine Reihe von Headern - mit der folgenden Anweisung hinzufügt: take me to PE4.
Eine Möglichkeit ist die Verwendung von IP-Tunneling. Indem das H1→H3 IPv4-Paket in einen anderen IPv4-Header mit Quelle und Ziel PE1→PE4 eingekapselt wird, erreicht das Paket PE4. Dann entfernt PE4 die Tunneling-Header und führt erfolgreich einen IPv4-Lookup für das ursprüngliche H1→H3-Paket durch. Es gibt verschiedene IP-Tunneling-Technologien wie GRE, IP-in-IP und VXLAN. Dieser Ansatz hat jedoch einige Probleme, wenn es um die Weiterleitung von Terabit pro Sekunde oder Petabit pro Sekunde oder mehr geht.
Das unmittelbarste Problem waren die Kosten, denn IP-Tunneling war früher teuer:
-
Erstens umfasst ein IPv4-Header allein 20 Bytes. Nimmt man die zusätzlichen Anpassungs-Header hinzu, wird der Overhead beträchtlich, ganz zu schweigen von dem Aufwand, der nötig ist, um Header mit vielen dynamischen Feldern zu erstellen und zu löschen.
-
Zweitens war die Durchführung eines IPv4-Lookups traditionell teuer. Obwohl moderne Plattformen die Differenzkosten drastisch gesenkt haben, war die Leistung der IPv4-Weiterleitung in den 1990er Jahren deutlich schlechter als beim Label Switching.
Es gibt eine andere Technologie, die in Bezug auf den Overhead (4 Byte pro Header) und die Weiterleitungseffizienz besser ist. Diese Technologie ist von Haus aus in BGP integriert und bietet ein großes Portfolio an Funktionen, die für SPs von größter Bedeutung sind. Du hast vielleicht schon erraten, dass der Name MPLS für Multiprotocol Label Switching steht. In der SDN-Ära sind die Weiterleitungskosten nicht mehr der Hauptgrund für den Einsatz von MPLS, sondern seine Architektur und Flexibilität.
MPLS
MPLS wurde in den späten 1990er Jahren erfunden, zu einer Zeit, als Asynchronous Transfer Mode (ATM) eine weit verbreitete WAN-Technologie war.
ATM hatte einige Vorzüge: Multiservice, asynchroner Transport, Class of Service, reduzierter Weiterleitungsstatus, Vorhersagbarkeit und so weiter. Aber es hatte mindestens genauso viele Mängel: keine Toleranz gegenüber Datenverlusten oder Neuordnung, ein Weiterleitungs-Overhead, der es für hohe Geschwindigkeiten ungeeignet machte, kein vernünftiges Multipoint, keine native Integration mit IP und so weiter.
MPLS hat aus den lehrreichen Erfahrungen mit ATM gelernt, indem es dessen Vorzüge nutzt und gleichzeitig seine Mängel behebt. Das moderne MPLS ist eine asynchrone, paketbasierte Weiterleitungstechnologie. In diesem Sinne ähnelt sie IP, aber MPLS hat eine viel leichtere Weiterleitungsebene und reduziert die Menge an Zuständen, die auf den Geräten signalisiert und programmiert werden müssen, erheblich.
MPLS in Aktion
Der wahrscheinlich beste Weg, MPLS zu verstehen, ist, sich ein reales Beispiel anzusehen, wie in Abbildung 1-9 gezeigt.
Abbildung 1-9. MPLS in Aktion
Abbildung 1-9 zeigt zwei unidirektionale MPLS Label-Switched Paths (LSPs) namens PE1→PE4 und PE4→PE2. Beginnen wir mit dem ersten. Ein IPv4-Paket H1→H3 (10.1.12.10→10.2.34.30) kommt bei PE1 an, was zu folgendem Ergebnis führt:
-
H3 ist über PE4 erreichbar, also platziert PE1 das Paket im LSP PE1→PE4. Dazu fügt er einen neuen MPLS-Header zwischen den IPv4- und den Ethernet-Header des H1→H3-Pakets ein. Dieser Header enthält das MPLS-Label 1000001, das für P1 eine lokale Bedeutung hat. In der MPLS-Terminologie ist dieser Vorgang ein Label-Push. Schließlich sendet PE1 das Paket an P1.
-
P1 empfängt das Paket, prüft und entfernt den ursprünglichen MPLS-Header. Dann fügt P1 einen neuen MPLS-Header mit dem Label 1000002 hinzu, der für P2 von lokaler Bedeutung ist, und sendet das Paket an P2. Dieser MPLS-Vorgang wird als Label-Swap bezeichnet.
-
P2 empfängt das Paket, prüft und entfernt den MPLS-Header und sendet dann das reine IPv4-Paket an PE4. Dieser MPLS-Vorgang wird als Label-Pop bezeichnet.
-
PE4 empfängt das IPv4-Paket ohne MPLS-Header. Das ist in Ordnung, denn PE4 spricht BGP und kennt alle IPv4-Routen, sodass er weiß, wie er das Paket an sein Ziel weiterleiten kann.
Das H3→H1-Paket reist von PE4 zu PE2 in einem kürzeren LSP, in dem nur zwei MPLS-Operationen stattfinden: Label Push bei PE4 und Label Pop bei P2. Es findet kein Label-Swap statt.
Hinweis
Diese LSPs folgen zufällig dem kürzesten IGP-Pfad zwischen ihren Endpunkten. Dies ist nicht zwingend erforderlich und oft auch nicht der Fall.
Router-Rollen in einem LSP
Wenn du dir Abbildung 1-9 ansiehst, beginnt das LSP PE1→PE4 bei PE1, durchquert P1 und P2 und endet... bei P2 oder bei PE4? Schauen wir mal. Indem PE1 das Paket in den LSP einfügt, schickt er es im Grunde an PE4. Wenn P2 ein Paket mit dem Label 1000002 empfängt, ist die Weiterleitungsanweisung klar: Löse das Label und schicke das Paket über die Schnittstelle Gi 0/0/0/5. Die LSP endet also bei PE4.
Hinweis
Das H1→H3-Paket kommt durch einen Mechanismus namens Penultimate Hop Popping (PHP), der von P2 ausgeführt wird, ohne Kennzeichnung bei PE4 an.
Im Folgenden werden die verschiedenen Router-Rollen aus der Sicht des PE1→PE4 LSP beschrieben. Für jede dieser Rollen gibt es viele Begriffe und Akronyme:
-
PE1Ingress PE, Ingress Label Edge Router (LER), LSP Head-End, LSP Upstream Endpoint. Der Begriff Ingress leitet sich von der Tatsache ab, dass Nutzerpakete wie H1→H3 am PE1 in das LSP eintreten, der als Eingangs- oder Ingress-Punkt fungiert.
-
P1 (oder P2)Transit P, P-Router, Label Switching Router (LSR), oder einfach P.
-
PE4 EgressPE, Egress Label Edge Router (LER), LSP Tail-End, LSP Downstream Endpoint. Der Begriff Egress kommt daher, dass Benutzerpakete wie H1→H3 das LSP an diesem PE verlassen.
Der MPLS-Header
Um es mit den Worten von Ivan Pepelnjak, dem technischen Direktor von NIL Data Communications, in seinem Blog www.ipspace.net zu sagen:
MPLS ist kein Tunneling, sondern eine auf virtuellen Leitungen basierende Technologie, und der Unterschied zwischen den beiden ist sehr groß. Von Tunneling kann man sprechen, wenn ein Protokoll, das eigentlich weiter unten im Protokollstapel stehen sollte, in ein Protokoll eingekapselt wird, das normalerweise darüber oder daneben liegt. MAC-in-IP, IPv6-in-IPv4, IP-over-GRE-over-IP... das sind Tunnels. IP-over-MPLS-over-Ethernet ist kein Tunneling.
Es stimmt zwar, dass MPLS virtuelle Leitungen verwendet, aber sie sind nicht mit Tunneln identisch. Nur weil alle Pakete zwischen zwei Endpunkten denselben Weg nehmen und die Switches in der Mitte ihre IP-Header nicht überprüfen, heißt das noch lange nicht, dass du eine Tunneltechnologie verwendest.
MPLS-Header werden auf elegante Weise in die Pakete eingefügt. Ihre Größe beträgt nur 4 Byte. Beispiel 1-6 zeigt eine Aufnahme des H1→H3-Pakets, während es die P1-P2-Verbindung durchläuft.
Beispiel 1-6. MPLS-Paket on-the-wire
1 Ethernet II, Src: MAC_P1_ge-2/0/3, Dst: MAC_P2_gi0/0/0/2 2 Type: MPLS label switched packet (0x8847) 3 MultiProtocol Label Switching Header 4 1111 0100 0010 0100 0010 .... .... .... = Label: 1000002 5 .... .... .... .... .... 000. .... .... = Traffic Class: 0 6 .... .... .... .... .... ...0 .... .... = Bottom of Stack: 1 7 .... .... .... .... .... .... 1111 1100 = MPLS TTL: 252 8 Internet Protocol Version 4, Src: 10.1.12.10, Dst: 10.2.34.30 9 Version: 4 10 Header Length: 20 bytes 11 Differentiated Services Field: 0x00 12 # IPv4 Packet Header Details and IPv4 Packet Payload
Hier ist eine Beschreibung der 32 Bits, aus denen ein MPLS-Header besteht:
-
Die ersten 20 Bits (Zeile 4) sind das MPLS-Label.
-
Die nächsten 3 Bits (Zeile 5) sind die Verkehrsklasse. In der Vergangenheit wurden sie als experimentelle Bits bezeichnet. Dieses Feld ist semantisch ähnlich wie die ersten 3 Bits des DSCP-Feldes (Differentiated Services Code Point) im IPv4-Header (Zeile 11).
-
Das nächste 1 Bit (Zeile 6) ist das Bottom of Stack (BoS) Bit. Es wird nur dann auf den Wert 1 gesetzt, wenn dies der MPLS-Header ist, der mit dem nächsten Protokoll-Header (in diesem Fall IPv4) in Kontakt steht. Andernfalls wird es auf Null gesetzt. Dieses Bit ist wichtig, weil der MPLS-Header kein Typ-Feld hat. Daher braucht er das BoS-Bit, um anzuzeigen, dass er der letzte Header vor der MPLS-Nutzlast ist.
-
Die nächsten 8 Bits (Zeile 7) sind die MPLS Time-to-Live (TTL). Wie die IP-TTL implementiert auch die MPLS-TTL einen Mechanismus, um Pakete im Falle einer Weiterleitungsschleife zu verwerfen. Normalerweise dekrementiert der Ingress PE die IP TTL um eins und kopiert diesen Wert dann in die MPLS TTL. Transit-P-Router dekrementieren die MPLS-TTL bei jedem Hop um eins. Schließlich kopiert der Egress-PE die MPLS-TTL in die IP-TTL und verringert dann deren Wert um eins. Du kannst diese Standardimplementierung sowohl in Junos als auch in IOS XR anpassen.
Abbildung 1-10 zeigt zwei weitere Etikettenoperationen, die bisher noch nicht beschrieben wurden:
-
Das erste eingehende Paket hat einen Zwei-Label-Stack. Du kannst die Verwendung des BoS-Bits sehen. Der Tauschvorgang betrifft nur das oberste (äußerste) Etikett.
-
Das zweite eingehende Paket hat zunächst einen Stapel mit einem Label und wird mit einer zusammengesetzten Label-Operation verarbeitet: Swap und Push. Das Ergebnis ist ein Zwei-Etiketten-Stapel.
Abbildung 1-10. Andere MPLS-Vorgänge
MPLS-Konfiguration und Weiterleitungsebene
MPLS-Schnittstellen-Konfiguration
Der erste Schritt besteht darin, MPLS auf den Schnittstellen zu aktivieren, auf denen du MPLS-Pakete weiterleiten möchtest. Beispiel 1-7 zeigt die Junos-Konfiguration für eine Schnittstelle an PE1.
Beispiel 1-7. MPLS-Schnittstellenkonfiguration-PE1 (Junos)
1 interfaces {
2 ge-2/0/4 {
3 unit 0 {
4 family mpls;
5 }}}
6 protocols {
7 mpls {
8 interface ge-2/0/4.0;
9 }}
Die Zeilen 1 bis 4 aktivieren die MPLS-Kapselung an der Schnittstelle, und die Zeilen 6 bis 8 aktivieren die Schnittstelle für MPLS-Protokolle. Streng genommen wird der letzte Konfigurationsblock nicht immer benötigt, aber es ist eine gute Praxis, ihn systematisch hinzuzufügen.
Hinweis
In diesem Buch wird davon ausgegangen, dass jede MPLS-aktivierte Schnittstelle in Junos mindestens die Konfiguration aus Beispiel 1-7 hat.
In IOS XR gibt es keine generische MPLS-Konfiguration. Du musst die Schnittstelle für jede der MPLS-Varianten aktivieren, die du verwenden möchtest. In diesem Kapitel wird die einfachste aller MPLS-Varianten vorgestellt: statisches MPLS. Beispiel 1-8 zeigt die Konfiguration einer Schnittstelle an PE4.
Beispiel 1-8. MPLS-Schnittstellenkonfiguration-PE4 (IOS XR)
mpls static interface GigabitEthernet0/0/0/0 !
Label-switched Pfad PE1→PE4-Konfiguration
Erinnere dich daran, dass die Pakete H1→H3 durch PE1 und PE4 gehen. Du brauchst ein LSP, das diese Pakete von PE1 zu PE4 bringt. Das LSP soll dem Pfad PE1-P1-P2-PE4 folgen, den wir in Abbildung 1-9 gesehen haben.
Hinweis
Dieses Beispiel basiert auf statischen LSPs, die nicht skalierbar sind, weil sie manuelle Labelzuweisungen an jedem Hop des Pfades erfordern. Ab Kapitel 2 liegt der Schwerpunkt auf den viel besser skalierbaren dynamischen LSPs.
Beispiel 1-9 zeigt die vollständige Konfiguration entlang des Pfades.
Beispiel 1-9. LSP PE1→PE4 Konfiguration-Junos und IOS XR
#PE1 (Junos)
protocols {
mpls {
static-label-switched-path PE1--->PE4 {
ingress {
next-hop 10.0.0.3;
to 172.16.0.44;
push 1000001;
}}}}
#P1 (Junos)
protocols {
mpls {
icmp-tunneling;
static-label-switched-path PE1--->PE4 {
transit 1000001 {
next-hop 10.0.0.7;
swap 1000002;
}}}}
#P2 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000002 allocate
forward
path 1 nexthop GigabitEthernet0/0/0/5 10.0.0.11 out-label pop
!
PE4 empfängt einfache IPv4-Pakete von P2 und benötigt daher keine LSP-spezifische Konfiguration.
Die Labels 1000001 und 1000002 sind für P1 bzw. P2 lokal signifikant. Ihre numerischen Werte könnten identisch sein und würden trotzdem unterschiedlichen Anweisungen entsprechen, weil sie nicht vom gleichen LSR interpretiert werden.
LSP PE1→PE4-Weiterleitungsebene
Nun ist es an der Zeit, die Weiterleitungsanweisungen zu untersuchen, die das H1→H3 IPv4-Paket durch das PE1→PE4 LSP leiten. Beginnen wir bei PE1, das in Beispiel 1-10 dargestellt ist.
Beispiel 1-10. Routing- und Weiterleitungsstatus am Ingress PE-PE1 (Junos)
1 juniper@PE1> show route receive-protocol bgp 172.16.0.201 2 10.2.34.30 active-path 3 4 inet.0: 36 destinations, 45 routes (36 active, ...) 5 Prefix Nexthop MED Lclpref AS path 6 * 10.2.34.0/24 172.16.0.44 100 100 65002 I 7 8 juniper@PE1> show route 172.16.0.44 9 10 inet.0: 36 destinations, 45 routes (36 active, ...) 11 + = Active Route, - = Last Active, * = Both 12 13 172.16.0.44/32 *[IS-IS/18] 1d 11:22:00, metric 30 14 > to 10.0.0.3 via ge-2/0/4.0 15 16 inet.3: 1 destinations, 1 routes (1 active, ...) 17 + = Active Route, - = Last Active, * = Both 18 19 172.16.0.44/32 *[MPLS/6/1] 05:00:00, metric 0 20 > to 10.0.0.3 via ge-2/0/4.0, Push 1000001 21 22 juniper@PE1> show route 10.2.34.30 active-path 23 24 inet.0: 36 destinations, 45 routes (36 active...) 25 + = Active Route, - = Last Active, * = Both 26 27 10.2.34.0/24 *[BGP/170] 06:37:28, MED 100, localpref 100, 28 from 172.16.0.201, AS path: 65002 I 29 > to 10.0.0.3 via ge-2/0/4.0, Push 1000001 30 31 juniper@PE1> show route forwarding-table destination 10.2.34.30 32 Routing table: default.inet 33 Internet: 34 Destination Next hop Type Index NhRef Netif 35 10.2.34.0/24 indr 1048575 3 36 10.0.0.3 Push 1000001 513 2 ge-2/0/4.0 37 38 juniper@PE1> show mpls static-lsp statistics name PE1--->PE4 39 Ingress LSPs: 40 LSPname To State Packets Bytes 41 PE1--->PE4 172.16.0.44 Up 27694 2768320
Die beste BGP-Route zum Ziel 10.2.34.30 (H3) hat ein BGP Next-Hop-Attribut (Zeile 6) gleich 172.16.0.44. Es gibt zwei Routen in Richtung 172.16.0.44 (PE4s Loopback):
-
Eine IS-IS-Route in der globalen IPv4-Routing-Tabelle
inet.0(Zeilen 10 bis 14). -
Eine MPLS-Route in der Hilfstabelle
inet.3(Zeilen 16 bis 20). Das in Beispiel 1-9 konfigurierte statische LSP installiert diese MPLS-Route automatisch.
Das Ziel der Hilfstabelle inet.3 ist es, BGP Next Hops (Zeile 6) in Forwarding Next Hops (Zeile 20) aufzulösen. Tatsächlich wird die BGP-Route 10.2.34.0/24 in inet.0 mit einem beschrifteten Forwarding Next Hop (Zeile 29) installiert, der von inet.3 (Zeile 20) kopiert wurde. Schließlich wird die BGP-Route in der Forwarding-Tabelle (Zeilen 31 bis 36) installiert und an die Forwarding-Engines weitergeleitet.
Die Tatsache, dass Junos eine Hilfstabelle (inet.3) hat, um BGP Next Hops aufzulösen, ist ziemlich relevant. Beachte, dass Junos inet.0 und nicht inet.3 zur Programmierung der Forwarding-Tabelle verwendet. Aus diesem Grund versieht PE1 standardmäßig die Pakete, die er an interne (Nicht-BGP-)Ziele wie den Loopback von PE4 sendet, nicht mit Labels, wie in Beispiel 1-11 gezeigt.
Beispiel 1-11. Ungelabelter Traceroute zu einem Nicht-BGP-Ziel-PE1 (Junos)
juniper@PE1> traceroute 172.16.0.44 traceroute to 172.16.0.44 1 P1 (10.0.0.3) 42.820 ms 11.081 ms 4.016 ms 2 P2 (10.0.0.25) 6.440 ms P2 (10.0.0.7) 3.426 ms * 3 PE4 (10.0.0.11) 9.139 ms * 78.770 ms
Wir kommen zurück zum LSP PE1→PE4 und gehen weiter zu P1, dem ersten LSR auf dem Pfad.
Beispiel 1-12. Routing- und Weiterleitungsstatus an einem Transit P-P1 (Junos)
juniper@P1> show route table mpls.0 label 1000001
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1000001 *[MPLS/6] 07:23:19, metric 1
> to 10.0.0.7 via ge-2/0/3.0, Swap 1000002
In der Tabelle mpls.0 werden die Anweisungen für das Label gespeichert. Wenn P1 zum Beispiel ein Paket mit dem Label 1000001 erhält, lautet die Anweisung: Tausche das Label gegen 1000002 aus und sende das Paket aus ge-2/0/3 an P2. Dieser Befehlssatz wird als Label Forwarding Information Base (LFIB) bezeichnet. Die Tabelle mpls.0 ist kein Hilfsmittel: Sie füllt die Weiterleitungstabelle auf.
Schauen wir uns zum Schluss noch das LFIB von P2 in Beispiel 1-13 an.
Beispiel 1-13. Routing- und Weiterleitungsstatus an einem Transit P-P2 (IOS XR)
RP/0/0/CPU0:P2#show mpls forwarding labels 1000002 Local Outgoing Outgoing Next Hop Bytes Label Label Interface Switched ------ ----------- ------------ --------------- ------------ 1000002 Pop Gi0/0/0/5 10.0.0.11 8212650
Es macht keinen Sinn, PE4 zu betrachten, der sich in Bezug auf die H1→H3-Pakete wie ein reiner IP-Router verhält.
LSP PE4→PE2-Konfiguration
Der Vollständigkeit halber wird in Beispiel 1-14 die vollständige Konfiguration des PE4→PE2 LSP dargestellt.
Beispiel 1-14. LSP PE4→PE2 Konfiguration-IOS XR
#PE4 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000200 allocate per-prefix 172.16.0.22/32
forward
path 1 nexthop GigabitEthernet0/0/0/0 10.0.0.10 out-label 1000110
!
#P2 (IOS XR)
mpls static
address-family ipv4 unicast
local-label 1000110 allocate
forward
path 1 nexthop GigabitEthernet0/0/0/0 10.0.0.4 out-label pop
!
Die Schlüsselsyntax bei PE4 ist per-prefix: Sie besagt, dass du ein Paket auf einem LSP, dessen Ende PE2 (172.16.0.22) ist, mit dem Label 1000110 versehen und an P2 senden sollst.
Der erste Label-Wert (1000200) aus Beispiel 1-14 ist nicht wirklich Teil des PE4→PE2 LSP. Das bedeutet, dass PE4, wenn es ein MPLS-Paket mit dem äußersten Label 1000200 empfängt, das Paket in das PE4→PE2 LSP einfügt, indem es das Label mit 1000110 vertauscht. Diese Logik ist für das aktuelle Beispiel, in dem H3→H1-Pakete ohne Label bei PE4 ankommen, nicht sehr relevant.
Beispiel 1-15 zeigt den Routing- und Weiterleitungsstatus am Ingress PE (PE4).
Beispiel 1-15. Routing- und Weiterleitungsstatus am Ingress PE-PE4 (IOS XR)
RP/0/0/CPU0:PE4#show bgp 10.1.12.0/24 brief
[...]
Network Next Hop Metric LocPrf Weight Path
* i10.1.12.0/24 172.16.0.11 100 100 0 65001 i
*>i 172.16.0.22 100 100 0 65001 i
RP/0/0/CPU0:PE4#show cef 10.1.12.10
[...]
local adjacency 10.0.0.10
via 172.16.0.22, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa137dd74 0x0]
next hop 172.16.0.22 via 172.16.0.22/32
RP/0/0/CPU0:PE4#show cef 172.16.0.22
[...]
local adjacency 10.0.0.10
via 10.0.0.10, GigabitEthernet0/0/0/0, 4 dependencies, [...]
next hop 10.0.0.10
local adjacency
local label 1000200 labels imposed {1000110}
RP/0/0/CPU0:PE4#show mpls forwarding labels 1000200
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ -------- -------------- ---------- --------- --------
1000200 1000110 172.16.0.22/32 Gi0/0/0/0 10.0.0.10 10410052
Die Logik in IOS XR ist sehr ähnlich, nur dass es in diesem Fall keine Hilfstabellen gibt. Daher ist das Standardverhalten von PE4, dass er den Paketen, die er an interne (Nicht-BGP-) Ziele sendet, die mehr als einen Hop entfernt sind, Labels hinzufügt, wie der Loopback von PE2 in Beispiel 1-16 zeigt.
Beispiel 1-16. Labeled traceroute zu einem nicht-BGP Ziel-PE4 (IOS XR)
RP/0/0/CPU0:PE4#traceroute 172.16.0.22 1 p2 (10.0.0.10) [MPLS: Label 1000110 Exp 0] 9 msec ... 2 pe2 (10.0.0.4) 0 msec ...
End-to-End-Nutzerverkehr
Nachdem die LSPs PE1→PE4 und PE4→PE2 aufgebaut sind, ist die End-to-End-Konnektivität in Ordnung.
Beispiel 1-17. End-to-End-Benutzer-Traceroute durch ein MPLS-Netzwerk
RP/0/0/CPU0:H1#traceroute vrf H1 10.2.34.30 1 ce1 (10.1.12.1) 0 msec ... 2 pe1 (10.1.0.1) 0 msec ... 3 p1 (10.0.0.3) [MPLS: Label 1000001 Exp 0] 9 msec ... 4 p2 (10.0.0.7) [MPLS: Label 1000002 Exp 0] 9 msec ... 5 pe4 (10.0.0.11) 9 msec ... 6 br4 (10.2.0.4) 9 msec ... 7 h3 (10.2.34.30) 9 msec ...
Wie erwartet, zeigt Traceroute den Vorwärtspfad mit den Labels von PE1→PE4.
Du fragst dich vielleicht, wie P1 eine ICMP-Nachricht (Internet Control Message Protocol) Time Exceeded an H1 senden kann, wenn es nicht einmal eine Route hat, um H1 zu erreichen. Was passiert, ist Folgendes:
-
P1 empfängt ein UDP-Paket mit MPLS-Label 1000001 und MPLS-TTL =1.
-
P1 verringert die TTL, stellt fest, dass sie abgelaufen ist, und kapselt das ursprüngliche UDP-Paket mit dem MPLS-Label 1000001 in ein ICMP Time Exceeded-Paket ein, das wiederum mit dem MPLS-Label 1000002 gekapselt wird. Dieses Paket hat TTL=255.
-
P1 sendet das MPLS-gekapselte ICMP Time Exceeded-Paket an P2, der das Label aufhebt und das Paket an PE4 sendet.
-
PE4 schaut sich das Ziel des ICMP Time Exceeded-Pakets an, das H1 ist. Gemäß einem regulären IPv4-Lookup sendet PE4 dieses Paket durch das PE4→PE2 LSP und erreicht so H1.
Tipp
Dieser Mechanismus funktioniert standardmäßig in IOS XR, aber du musst ihn in Junos explizit aktivieren, indem du den Befehl set protocols mpls icmp-tunneling verwendest.
Äquivalenzklasse der Weiterleitung
Im vorherigen Beispiel ging es um die Kommunikation zwischen zwei Hosts, H1 und H3. Gehen wir einen Schritt zurück und denken wir an das globale Internet. Stell dir vor, PE1 wählt PE4 als nächsten BGP-Hop für 100.000 Routen aus. Überleg mal: Alle diese 100.000 Routen haben denselben BGP Next Hop. Das bedeutet, dass PE1 alle Pakete zu jedem dieser 100.000 Präfixe über denselben LSP senden kann. Das kann natürlich zu Problemen in Bezug auf Lastverteilung und Redundanz führen, aber diese Themen werden in diesem Buch ausführlich behandelt.
Jedes Paket, das PE1 dem PE1→PE4 LSP zuordnet, gehört zu einer einzigen Forwarding Equivalence Class (FEC). Die Transit-LSRs müssen nur wissen, wie sie im Kontext dieser FEC weiterleiten müssen: im Grunde nur ein Eintrag in der LFIB. So können Billionen von Flüssen mit nur einem Weiterleitungseintrag erfolgreich weitergeleitet werden.
Hinweis
Die Aggregation des Weiterleitungsstatus ist einer der ersten unmittelbaren Vorteile von MPLS.
Noch einmal: Was ist MPLS?
MPLS ist keine Verkapselung. Es ist ein architektonischer Rahmen, der den Transport von den Diensten entkoppelt. In diesem Fall ist der Dienst der Internetzugang (IPv4 Unicast) und der Transport wird über MPLS LSPs abgewickelt.
Diese Entkopplung wird durch die Kodierung von Anweisungen in Paketköpfen erreicht. Unabhängig davon, ob es sich bei der Verkapselung um MPLS oder etwas anderes handelt, bleibt das MPLS-Paradigma bestehen.
Das Internet ist der lebende Beweis dafür, dass MPLS ein Eckpfeiler der Skalierbarkeit von Netzwerkdiensten ist. In jeder Sekunde, in der sich unsere Nutzerin Annika in einer Videokonferenz mit ihrem Freund Ruijiao befindet, werden mehr als 1.000 MPLS-Labels verschoben, ausgetauscht oder geknackt, um dies zu ermöglichen. Die Kerngeräte, die diese Label-Operationen durchführen, haben keinen Einblick in die öffentlichen IP-Adressen, die Annikas und Ruijiaos Endgeräte für die Verbindung zum Internet nutzen.
Ein weiterer wichtiger Aspekt von MPLS ist das Stapeln von Befehlen. Unabhängig davon, ob diese Anweisungen in Form von Etiketten oder in anderer Form vorliegen, ist die Möglichkeit, sie zu stapeln, gleichbedeutend mit der Bereitstellung einer Folge von Anweisungen. Für Netzwerkdienste, die über die einfache Konnektivität hinausgehen, ist dies eine wichtige Voraussetzung.
Wie später in Kapitel 10 erläutert, haben skalierbare Netzwerkarchitekturen eine Nord-Süd- und eine Ost-West-Richtung. Das Stapeln von Befehlen führt eine weitere Dimension ein: Up-Down.
Hinweis
MPLS eignet sich hervorragend für Architekturen mit einem funktionsreichen Netzwerkrand in Kombination mit einem schnellen und stabilen Backbone.
MPLS wurde für das Internet geboren. Es hat klein angefangen und wächst weiter. Das ursprüngliche Ziel von MPLS war es, eine ganz bestimmte Herausforderung zu lösen, aber jetzt entwickelt es sich weiter, um viele andere Anforderungen in Bezug auf Service, Transport, Serviceklasse, Leistung, Ausfallsicherheit usw. zu erfüllen.
OpenFlow
Die SDN-Ära begann mit einem experimentellen Protokoll, das hohe Erwartungen weckte: OpenFlow.
OpenFlow ermöglicht die flussbasierte Programmierbarkeit einer Forwarding Engine. Die erste Version (v1.0) ist im Wesentlichen eine Abstraktion für Netzwerk-Switches. Im Laufe der Zeit wurden in die verschiedenen Versionen von OpenFlow weitere Funktionen integriert, deren Einzelheiten den Rahmen dieses Buches sprengen würden. Alle Definitionen und Spezifikationen findest du auf dem Open Networking Forum(https://www.opennetworking.org/sdn-resources/openflow).
Abbildung 1-11 zeigt OpenFlow v1.0 bei der Arbeit. OpenFlow setzt voraus, dass es eine zentrale Controller-Software gibt, die als virtuelle Maschine (VM), als Container oder direkt auf dem Host-Betriebssystem eines Servers läuft. Der Controller muss eine IP-Verbindung zu den Switches haben, indem er eine der folgenden Möglichkeiten nutzt:
-
Ein Out-of-Band-Netzwerk, das nicht unter dem Kommando des Controllers steht
-
Eine In-Band-Netzwerkverbindung, die sich auf einen bereits bestehenden Weiterleitungsstatus stützt
Abbildung 1-11. Openflow in Aktion
Switches haben eine leichtgewichtige Steuerungsebene und eine vergleichsweise leistungsfähigere Forwarding Engine. Der wichtigste Status eines OpenFlow-gesteuerten Switches ist seine Flow-Tabelle. Die Steuerungsebene der Switches ist über eine OpenFlow-TCP-Sitzung mit dem zentralen Controller verbunden, um OpenFlow-Nachrichten auszutauschen.
Abbildung 1-11 zeigt, wie Host A das erste Paket eines Benutzer-TCP-Datenflusses an Host B sendet. Als das Paket an Port 1 ankommt, stellt Switch 1 fest, dass dieser Datenfluss nicht in seiner Datenflusstabelle programmiert ist, und leitet das Paket an den Controller weiter. Der Controller hatte zuvor erfahren, wo sich Host B befindet, und mit dieser Information kann er den neuen Datenfluss auf den Switches programmieren. Die Switches sind nun in der Lage, die Pakete dieses Flusses an das Ziel weiterzuleiten.
OpenFlow-Flow-basierte Weiterleitung
Ein grundlegendes architektonisches Merkmal von OpenFlow ist die Programmierbarkeit pro Fluss, die eine feine Granularität bei der Definition von Flüssen und den damit verbundenen Aktionen bietet. Das Ergebnis ist ein flussbasiertes Weiterleitungsmodell. Seit Jahrzehnten gibt es in der Branche eine Vielzahl von Lösungen, die sowohl auf Flows als auch auf Paketen basieren. Welches Modell ist besser? Weder noch - beide sind es. Es kommt wirklich auf den Anwendungsfall an.
Es gibt Teile des Netzes, in denen eine flussbasierte Weiterleitung nicht in Frage kommt, wie z. B. im Kernbereich und bei den meisten Breitband-Kantenfunktionen, weil sie nicht skalierbar wäre und kein Bedarf dafür besteht. Das Internet erfordert die Aggregation von Zuständen (FECs) anstelle von Zustandserweiterungen (Flows). Die Aufbewahrung von Zuständen für Flows ist von Natur aus teurer und komplexer als die paketbasierte Weiterleitung. Es gibt jedoch andere Netzwerkfunktionen wie Firewalling, DPI und CGNAT, die aufgrund der Art der Funktion, die sie ausführen, flussbasiert sein müssen.
Die gleichen Prinzipien, nach denen die Industrie natürlich ausgewählt hat, welche Teile des Netzwerks flussbasiert sein sollten und welche nicht, sind immer noch völlig gültig. Die Tatsache, dass es ein neues Protokoll zur Programmierung von Flows in einem Netzwerk gibt, macht die flussbasierte Weiterleitung weder zu einer besseren noch zu einer schlechteren Idee.
Neue Entwicklungen bei der Weiterleitungstechnologie, dem Speicher und den Kosten könnten die Dinge in die eine oder andere Richtung verschieben. Aus diesem Grund ist es ratsam, die Existenz des OpenFlow-Protokolls von der Debatte zu entkoppeln, ob eine flussbasierte Weiterleitung eine gute Idee ist oder nicht. OpenFlow als solches schreibt die Granularität der zu programmierenden Flows weder vor noch legt es sie fest.
Wenn du dich für das eine oder das andere Modell entscheidest, musst du zuerst die Frage beantworten, ob du eine flussbasierte Weiterleitung brauchst. Wenn nicht, ist es besser, paketbasierte Weiterleitung zu verwenden. Fabrics in Rechenzentren (beschrieben in Kapitel 10) sind ein gutes Beispiel für die Risiken, die mit einer blinden Umstellung auf ein flussbasiertes Weiterleitungsparadigma verbunden sind. Auf den ersten Blick sieht es so aus, als würde es gut passen, aber eine genauere Analyse zeigt, dass es wirklich auf den Haupteinsatzzweck des Rechenzentrums ankommt.
Ivan Pepelnjak hat einen aufschlussreichen Artikel mit dem Titel "OpenFlow and Fermi Estimates" geschrieben, der in seinem Buch SDN and OpenFlow-The Hype and the Harsh Reality (Selbstverlag, 2014, http://www.ipspace.net/Books) enthalten ist. Vielleicht ist dir schon aufgefallen, dass dein Webbrowser automatisch Verbindungen zu vielen URLs herstellt, die du gar nicht besuchen wolltest. Wenn du zum Beispiel deine Lieblings-Online-Zeitung liest, wird eine Vielzahl von Inhalten wie Werbung, Multimedia und Statistiken automatisch von externen Websites geladen. Jeder Inhalt wird über eine individuelle, kurzlebige Verbindung abgerufen. Diese kurzlebige Eigenschaft vieler Internetströme macht die Flow-Programmierung zu einer sehr intensiven Aufgabe. Das gilt besonders für Hochgeschwindigkeits-Switches in Rechenzentren, die eine vergleichsweise schwache Steuerungsebene haben. Die Fermi-Schätzung von Pepelnjak zeigt, dass die Weiterleitungskapazität eines typischen Rechenzentrums-Switches um mehrere Größenordnungen sinkt, wenn er die flussbasierte Weiterleitung von HTTP-Flüssen durchführen muss. Die Steuerebene wird in diesem Fall zum Engpass, sodass ein Großteil der Bandbreite nicht genutzt werden kann. Wenn dein Netzwerk kurzlebige Datenströme transportiert, solltest du OpenFlow mit Bedacht einsetzen.
OpenFlow-Offenheit und P4
OpenFlow ist ein offenes Protokoll und P4 (eine neuere Hochsprache, dieprotokollunabhängige Paketprozessorenprogrammiert- daherdie vier Ps) geht noch einen Schritt weiter, von einem Protokoll zu einer Programmiersprache. Trotz der Definitionen sind sich nicht alle einig, ob OpenFlow und P4 tatsächlich High Level oder Low Level sind.
Kein Wunder, Offenheit ist cool. Auf der anderen Seite ist die Implementierung feinkörniger Kanten-Features komplex. Daran führt kein Weg vorbei. Egal, ob die Komplexität auf den anwendungsspezifischen integrierten Schaltkreisen (ASICs), im Low-Level-Mikrocode oder in den High-Level-Befehlen liegt, sie muss irgendwo sein, und nicht jeder Ansatz ist gleich effizient oder flexibel. Die Standardisierung einer Hochsprache verbirgt die Komplexität, was großartig ist, aber für viele Funktionen müssen die Entwickler/innen auf die unteren Ebenen heruntergehen.
Low-Level-Sprachen sind deshalb so wertvoll, weil sie aufgrund ihrer Nähe zur tatsächlichen Hardware Flexibilität bieten. Sie sind von Natur aus spezifisch und müssen es auch sein, und wenn sie generisch sein wollen, verlieren sie genau diese Spezifität. Die Hardware weist Unterschiede auf, die offengelegt werden müssen, denn die Hersteller fügen ihren ASICs eine Menge Innovationen hinzu, um sie voneinander zu unterscheiden. Wenn sie offengelegt werden, wird die Sprache spezifisch. Wenn sie nicht offengelegt werden, geht die Innovation verloren und das System wird zu einem Hemmschuh für Innovationen.
Die Beziehung zwischen der Hardware und der Software, mit der sie programmiert wird, ist auf einer bestimmten Ebene sehr eng. Der Versuch, eine Zwischenschicht einzufügen, selbst wenn es sich um eine von der Industrie definierte Schicht handelt, ist nicht gerade innovationsfördernd. Nur die Zeit wird zeigen, ob die Standardisierung der Programmierung eines Netzwerkgeräts zu Innovationen führt oder die Einführung neuer Funktionen verlangsamt. Es wird auf jeden Fall eine interessante Geschichte sein, die man beobachten kann oder bei der man zumindest eine Rolle spielt.
Ein weiteres wichtiges Merkmal des OpenFlow-Modells ist die Entkopplung der Kontroll- und Weiterleitungsebene. Lass uns dieses Thema im weiteren Kontext von SDN diskutieren.
SDN
In diesem Buch wird nicht versucht, das SDN-Konzept selbst neu zu definieren: Das ist Sache der Erfinder des Akronyms. Was sich dieses Buch erlaubt, ist die SDN-Ära zu beschreiben. Wir werden zunächst die offizielle Definition von SDN erörtern und uns dann der SDN-Ära zuwenden.
SDN wurde vom Open Networking Forum(https://www.opennetworking.org) wie folgt definiert:
Die physische Trennung der Netzwerk-Kontrollebene von der Weiterleitungsebene, wobei eine Kontrollebene mehrere Geräte steuert.
Nach dieser Definition heißt es:
Software-Defined Networking (SDN) ist eine aufstrebende Architektur, die dynamisch, verwaltbar, kosteneffizient und anpassungsfähig ist und sich damit ideal für die dynamischen Anwendungen mit hohen Bandbreiten von heute eignet. Diese Architektur entkoppelt die Netzwerksteuerung von den Weiterleitungsfunktionen, so dass die Netzwerksteuerung direkt programmierbar wird und die zugrunde liegende Infrastruktur für Anwendungen und Netzwerkdienste abstrahiert werden kann. Das OpenFlow™-Protokoll ist ein grundlegendes Element für den Aufbau von SDN-Lösungen.
Trennung der Kontroll- und Weiterleitungsebenen
Der Prozess der Entkopplung der Kontroll- und Weiterleitungsebene wird als Schlüsselelement für die Einführung von SDN dargestellt; einige Ingenieure behaupten jedoch, dass diese Trennung in ihren eigenen Netzwerken schon seit vielen Jahren besteht. So haben beispielsweise sowohl Juniper- als auch Cisco-Router in den 1990er Jahren die Kontroll- und Weiterleitungsebenen klar voneinander getrennt. Die Tatsache, dass sie auf demselben physikalischen Chassis liefen, tat dieser Trennung keinen Abbruch, denn sie war für das Wachstum des Internets von grundlegender Bedeutung. Als Juniper diese Trennung zusammen mit der ASIC-basierten Weiterleitung einführte, löste dies eine Ära beispiellosen Kapazitätswachstums aus. Und im Nachhinein betrachtet war dies notwendig, um das beispiellose Wachstum des Datenverkehrs aufrechtzuerhalten, das vor uns lag.
Seit Anfang der 2000er Jahre - ein paar Jahre bevor OpenFlow vorgeschlagen wurde - haben Netzwerkanbieter Lösungen implementiert und ausgeliefert, die die Steuerungsebene auf einem externen physischen Gerät einrichten. Dabei handelt es sich im Wesentlichen um einen Controller, der das sogenannte "Line Card Chassis" programmiert.
Daher ist es nur fair, darauf hinzuweisen, dass das grundlegende architektonische Attribut von SDN, die Trennung von Kontroll- und Weiterleitungsebene, im Grunde nicht neu ist und in den Netzwerken bereits weit verbreitet ist. Egal, ob neu oder nicht, dieses Attribut ist wertvoll.
Ein weiterer grundlegender Bestandteil der SDN-Architektur ist die Zentralisierung. Manchmal handelt es sich dabei um eine logische Zentralisierung, denn eine physische Zentralisierung ist nicht immer möglich. Wenn du davon ausgehst, dass die Steuerungsebene deines Netzwerks physisch von der Weiterleitungsebene entkoppelt ist, führt das zu einer Reihe interessanter Herausforderungen:
-
Du brauchst ein Netzwerk, um beide Funktionen (die Kontroll- und die Weiterleitungsebene) zu verbinden. Wenn ein solches Netzwerk fehlschlägt, wie funktioniert die Lösung?
-
Für ein ordnungsgemäßes Zusammenspiel zwischen der Kontroll- und der Weiterleitungsebene sind Latenzzeiten vorgeschrieben. Die Latenz ist wichtig für die Ausfallsicherheit, die Reaktion auf Netzwerkereignisse, die Telemetrie und so weiter. Wie weit darf der Controller von den Weiterleitungselementen entfernt sein?
Es ist nicht trivial, für jedes Netzwerk zu verallgemeinern, wie diese Prinzipien angewendet werden können. Die SDN-Prinzipien lassen sich besser im Zusammenhang mit konkreten Anwendungsfällen analysieren. Dann kannst du sehen, ob eine Architektur, die diese Prinzipien befolgt, machbar ist oder nicht.
Trennung von Kontroll- und Weiterleitungsebene - Overlays im Rechenzentrum
Ein paradigmatischer Anwendungsfall, für den die SDN-Prinzipien gut geeignet sind, ist die Overlay-Architektur in Rechenzentren, die Folgendes voraussetzt:
-
Es gibt eine Underlay-Fabric, die eine belastbare Verbindung zwischen der Weiterleitungsebene des Overlay (in der Regel ein vRouter oder ein vSwitch auf einem Server) und der Steuerungsebene (zentraler Controller) herstellt.
-
Die Latenzzeit hält sich innerhalb bestimmter Arbeitsgrenzen.
Trennung der Kontroll- und Weiterleitungsebenen - WAN IP/MPLS
Untersuchen wir nun die Anwendbarkeit der SDN-Architekturprinzipien auf das WAN-IP/MPLS-Netzwerk eines ISP. Obwohl wir bestimmte Funktionen der Steuerungsebene zentralisieren können, ist eine vollständige Zentralisierung nicht machbar. Wenn die gesamte Steuerungsebene Hunderte oder Tausende von Kilometern (und N Netzwerksprünge) von der Weiterleitungsebene entfernt ist, ist es nicht möglich, die Interaktion zwischen beiden Ebenen zuverlässig und reaktionsschnell zu gewährleisten. Aus diesem Grund kann das SDN-Konzept nur taktisch auf die WAN-Umgebung angewendet werden.
Eine zentralisierte netzwerkweite Kontrollintelligenz kann zu genaueren Berechnungen führen, was z. B. bei der Verkehrsplanung sehr nützlich ist. In diesem Fall wird die verteilte Kontrollebene durch eine zusätzliche zentrale Intelligenz erweitert. Dies wird in Kapitel 15 ausführlich erklärt.
Diese Beispiele zeigen, dass SDN für jedes Szenario unterschiedlich gut geeignet sein kann (es gibt keine Einheitslösung). Netzwerkanbieter haben diesen Grundsatz über die Jahre hinweg auf viele Technologien und Architekturen angewandt: Zentralisiere, was du kannst, verteile, was du musst. Wenn etwas zentralisiert werden kann und es keine physischen oder funktionalen Einschränkungen gibt, sollte es zentralisiert werden; andernfalls sollte es verteilt bleiben.
SDN und die Protokolle
Man kann mit Fug und Recht behaupten, dass OpenFlow der Funke war, der einen Bewusstseinswandel in der Branche ausgelöst und eine gesunde Debatte angestoßen hat, die als Katalysator für die SDN-Ära fungiert hat.
Dennoch ist die technische Relevanz von OpenFlow umstritten. Während einige Ingenieure glauben, dass OpenFlow der Eckpfeiler von SDN ist, sind andere der Meinung, dass es nichts grundlegend Neues vorschlägt. Fairerweise muss man sagen, dass sich OpenFlow, wie jedes andere Protokoll oder jede andere Technologie, in seinen verschiedenen Versionen weiterentwickelt. Ob es in Zukunft wirklich einen grundlegenden Vorteil bringen wird oder nicht, wird nur die Zeit zeigen.
Parallel zur kontinuierlichen Entwicklung von OpenFlow haben auch andere Branchenforen wie die IETF ähnliche Konzepte entwickelt. Tatsächlich gewinnen zwei der Kronjuwelen der IETF, BGP und MPLS, als SDN-fähige Protokolle an Bedeutung.
Es ist nicht überraschend, dass BGP in der SDN-Ära auftaucht, denn es ist das skalierbarste Netzwerkprotokoll, das jemals entwickelt und implementiert wurde. Andererseits gewinnt das MPLS-Paradigma (Entkopplung von Dienst und Transport, Platzierung von Anweisungen in den Paketköpfen) immer mehr an Bedeutung für die Entwicklung und den Einsatz von skalierbaren SDN-Lösungen. Dieses Paradigma wurde von der OpenFlow-Community in SDN 2.0 umbenannt.
Hinweis
Erinnere dich daran, dass das MPLS-Paradigma keine Verkapselung ist.
Kapitel 11 und 12 beschreiben produktionsreife SDN-Lösungen, die hauptsächlich auf BGP und seinen Derivaten in Kombination mit dem MPLS-Paradigma basieren.
In der Praxis ist OpenFlow ein optionales Element der SDN-ähnlichen Architekturen. Viele moderne SDN-ähnliche Lösungen setzen nicht auf OpenFlow und sind nicht einmal davon inspiriert. Andere schon: Natürlich gehört OpenFlow in die SDN-Ära.
Einige parallele IETF-Projekte konzentrieren sich auf die Standardisierung der Art und Weise, wie das Verhalten der Netzwerkelemente programmiert und konfiguriert wird (z. B. PCEP, BGP Flowspec, NETCONF/YANG/OpenConfig, I2RS, und ForCES). Obwohl einige davon noch nicht weit verbreitet sind, gewinnen andere zunehmend an Bedeutung und gehören ebenfalls zum SDN-Zeitalter. Kapitel 15 behandelt PCEP im Detail.
Unabhängig von der Terminologiedebatte und der Wahl des Protokolls ist eines sicher: Die Branche wird weiterhin neue Architekturen erforschen und implementieren, die die Art und Weise, wie wir Netzwerke sehen und nutzen, mit Sicherheit verändern werden.
Das SDN-Zeitalter
Wenn du dir alle SDN-ähnlichen Implementierungen und Technologien ansiehst, wirst du zwei gemeinsame Elemente finden, die zeigen, was zu Beginn des Jahrhunderts in unserer Branche fehlte:
- Automatisierung
- Schaffung der Voraussetzungen für die Automatisierung von Aktionen in den Netzwerken (Konfiguration, Bereitstellung, Betrieb, Fehlerbehebung usw.)
- Abstraktion
- Nord-Süd-Kommunikation durch Überwindung der anbieterspezifischen Barrieren und Komplexitäten, an die sich die Kunden anpassen oder die sie vermeiden mussten
Wenn du dir ansiehst, wie die Branche zwei Protokolle wie OpenFlow oder Netconf angenommen hat, lag der Schwerpunkt in der Regel auf dem "Wie": wie man Low-Level-Flows programmiert oder wie man ein Gerät konfiguriert. Was die Branche jedoch wirklich braucht, ist ein Fokus auf das "Was": was die Absicht ist. Es geht darum, auf einer höheren Ebene abstrakt zu werden, um Absichten zu definieren und Aktionen rund um diese Absichten zu automatisieren. Mit anderen Worten: "Sag, was du willst, nicht wie du es willst." Dann mach das Netzwerk intelligent genug, um das bestmögliche "Wie" zu entscheiden.
Zusammenfassend lässt sich sagen, dass die unzähligen SDN-Begriffe und -Initiativen in der gesamten Branche die Automatisierung und Abstraktion gemeinsam haben. Das ist die eigentliche Essenz dessen, was in diesem Buch als SDN-Ära bezeichnet wird und worum wir uns als Branche wahrscheinlich kümmern sollten. Schauen wir uns kurz ein paar konkrete Anwendungsfälle neuer Technologien an, die durch Automatisierung und Abstraktion einen konkreten Mehrwert für echte Kundenherausforderungen zu bieten scheinen.
SDN-Ära Anwendungsfälle
Wenn wir uns von dem Begriff SDN und seinen vielen Interpretationen lösen, gibt es tatsächlich neue Lösungen und Technologien, die für bestimmte Anwendungsfälle entwickelt wurden, die sowohl eine architektonische Veränderung als auch eine Antwort auf ein reales Problem darstellen. Im Folgenden findest du eine Liste repräsentativer Szenarien, die Teil des neuen Denkens in der SDN-Ära sind. Einige nutzen erprobte Technologien auf praktische, oft geniale Weise.
Rechenzentrum
Die Anforderungen an Rechenzentren sind in vielen Bereichen um Größenordnungen gestiegen, und das sehr schnell. Rechenzentren haben einen rasanten Wandel von einfachen dichten LANs zu Hyperscale-Infrastrukturen mit sehr strengen Anforderungen nicht nur an die Leistung, sondern auch an die Latenz, den Umfang, die Mandantenfähigkeit und die Sicherheit erlebt. Damit verbunden ist auch die Notwendigkeit einer besseren Verwaltbarkeit.
Einige der vorgeschlagenen Switching-Infrastrukturen für Rechenzentren basieren auf OpenFlow mit einem zentralen Controller, der die Datenströme entlang des Pfads programmiert. Die Branche hat sich aber auch mit anderen Architekturen und Technologien befasst, die nachweislich dieselben Anforderungen in großem Maßstab erfüllen können. Du musst nicht lange suchen, um sie zu finden: das Internet selbst. Die Protokolle und Architekturen, mit denen das Internet und die IP-Netzwerke der ISPs aufgebaut wurden, sind der beste Spiegel für den Aufbau der nächsten Generation von Rechenzentren, die Folgendes leisten:
-
Entkopplung von Transport und Diensten (das Architekturprinzip von MPLS)
-
Aufbau einer stabilen, dienstunabhängigen Transportinfrastruktur (Fabrics)
-
Bereitstellung von Diensten nur an den Kanten und Verwendung von skalierbaren Protokollen für die Kontrollebene (BGP)
Diese ISP-Architektur wurde in mehrfacher Hinsicht an Rechenzentren angepasst. Erstens ist die Weiterleitungsebene des Underlay für die spezifischen Anforderungen von Rechenzentren optimiert, zu denen eine sehr niedrige Latenzzeit zwischen den Endsystemen (Servern) und eine sehr hohe Transportkapazität fast ohne Einschränkungen gehören.
Die Kanten des ISP werden durch die Overlay-fähigen Edge-Forwarder des Rechenzentrums ersetzt, die in der Regel durch den vRouter/vSwitch auf den Server-Hypervisoren oder den Top-of-Rack (ToR)-Switch instanziiert werden.
Dies bietet eine gute Gelegenheit, einen zentralen Controller zu verwenden, der die Kanten-Forwarder so programmieren kann, als wären sie die Paketweiterleitungs-Engines oder die Linecards eines physischen Mehrkomponenten-Netzwerkgeräts. Du kannst dieses Modell in Kapitel 11 im Detail sehen.
WAN
Das ISP-WAN - das interne ISP-Backbone - ist ein weiterer spezieller Anwendungsfall, für den es neue Herausforderungen gibt, die es zu bewältigen gilt. Die Bandbreitenressourcen sind knapper denn je, und die CAPEX-Kontrollen machen es unmöglich, so viel Kapazität wie in der Vergangenheit bereitzustellen. Der Datenverkehr nimmt jedoch weiter zu, und eine wachsende Vielfalt von Diensten fließt über die WAN-Infrastruktur, so dass Mechanismen benötigt werden, die diese Ressourcen effizienter und dynamischer verwalten können. MPLS Traffic Engineering gibt es schon seit vielen Jahren, aber die verteilte Natur der Traffic-Engineering-Entscheidungen führte zu Ineffizienzen.
Mit der breiteren Verfügbarkeit und den Implementierungen von Protokollen wie PCEP ist es nun möglich, zentrale intelligente Controller einzusetzen, die die verteilte Steuerungsebene des Netzwerks ergänzen, indem sie eine netzwerkweite Vision und einen Entscheidungsprozess hinzufügen. Das ISP-WAN kann nun die Vorteile von Implementierungen nutzen, die eine intelligente Verwaltung von Ressourcen und die Automatisierung von Aufgaben bieten, die früher nur begrenzt und teilweise manuell erledigt werden konnten oder einfach nicht erledigt wurden, weil die Kapazitäten ausreichten. Die Ressourcenknappheit und die geschäftlichen Anforderungen erfordern nun eine andere Vorgehensweise. Dies ist ein weiteres Beispiel und ein Anwendungsfall für neue Implementierungen, die auf altbewährte Konzepte zurückgreifen, wie z. B. die PCE Client-Server-Architektur. Dieses Modell wird in Kapitel 15 ausführlich beschrieben.
Packet-optische Konvergenz
Die paketbasierte und die leitungsbasierte Vermittlung sind zwei grundverschiedene Paradigmen, und beide haben ihre Daseinsberechtigung. Traditionell sind sie getrennte Schichten, wobei das leitungsvermittelnde Netz meist die Serverschicht für das paketvermittelnde Netz (den Client) darstellt. Diese Rolle wird manchmal umgekehrt, z. B. bei emulierten TDM-Leitungen über MPLS in Mobile Backhaul-Szenarien, die in Kapitel 6 kurz erläutert werden.
Optische Netze sind die am weitesten verbreitete leitungsvermittelte Technologie. Sie bieten optische Schaltungen, die paketbasierte Netze für die Punkt-zu-Punkt-Kommunikation zwischen den verschiedenen paketvermittelnden Knotenpunkten (Router, Switches usw.) nutzen.
In der SDN-Ära wird der Großteil des Datenverkehrs über IP abgewickelt - sogar der mobile Sprachverkehr mit Technologien wie VoLTE. Es ist bereits eine Tatsache, dass der Hauptzweck (wenn nicht sogar der einzige) des optischen Netzes darin besteht, das IP-Netz zu transportieren. Aus diesem Grund wird die enge Koordination und Optimierung des optischen und des IP-Netzes geschäftskritisch. Jede Ineffizienz bei dieser Integration wird sofort zu einer großen Quelle für zusätzliche CAPEX und OPEX.
Daher ist dies ein weiterer Bereich, in dem ISPs vor einer großen Herausforderung stehen, die spezifische Lösungen erfordert. Der Bedarf an Ressourcenkoordination, Automatisierung und Optimierung wird durch folgende Maßnahmen gedeckt:
-
Ressourcen auf eine normalisierte Weise freilegen (Abstraktion)
-
Die Fähigkeit, die richtigen Entscheidungen über die Ressourcenzuweisung zu automatisieren (Pfade einrichten, Pfade optimieren, nach Ersatzressourcen suchen usw.) und dabei sowohl die optische Ebene als auch die Paketebene zu berücksichtigen
Auch hier ist die Rolle eines zentralen Controllers von entscheidender Bedeutung. Das in Kapitel 15 beschriebene Modell zielt auch auf diesen Anwendungsfall ab.
IP-Peering
IP-Peering bietet eine weitere Möglichkeit, die bestehenden Mechanismen zu verbessern und zu optimieren. Bislang wurde das Verhalten der IP-Peering-Punkte ausschließlich durch die Regeln des BGP-Protokolls bestimmt. BGP implementiert einen Entscheidungsalgorithmus, der nach dem besten schleifenfreien Pfad sucht - schleifenfrei in dem Sinne, dass der AS-Pfad nicht zweimal denselben AS enthält. Obwohl viele Hilfsmittel wie BGP-Attribute verwendet werden können, um den Entscheidungsprozess zu beeinflussen, bleibt es doch ein eingebauter Algorithmus, der auf bestimmten vordefinierten Regeln basiert. Solche Regeln berücksichtigen möglicherweise keine geschäftsbezogenen Aspekte, die ein Anbieter berücksichtigen muss, um die besten Routing-Entscheidungen zu treffen.
Einige dieser geschäftlichen Aspekte sind der Preis der Peering-Verbindung (es könnte sich um eine Transitverbindung handeln), die tatsächliche Latenzzeit zum Ziel (kürzere AS-Pfade bedeuten nicht unbedingt eine geringere Latenzzeit), die Auslastung der Verbindung und vielleicht noch andere. Da die Geschäftsbedingungen in unserer Branche immer strenger werden, müssen bei Netzwerkentscheidungen mehr Variablen berücksichtigt werden.
ISPs verwenden oft Ad-hoc-Tunneling-Overlays (basierend auf IP oder MPLS), um die standardmäßigen Weiterleitungsentscheidungen zu umgehen, aber dieser Ansatz ist nicht skalierbar: ISPs verdienen eine bessere Lösung.
Eine Controller-basierte Lösung, die diese Möglichkeit nutzt, muss einen detaillierten Überblick über den gesamten BGP-Routing-Status im SP haben. Das BGP Monitoring Protocol (BMP), das sowohl in Junos als auch in IOS XR implementiert ist, ermöglicht die Abfrage von einem bestimmten Router:
- Die Adj-RIB-in
- Dies sind die Präfixe, die der abgefragte Router von einem Peer erhalten hat, bevor er die Import-Routing-Richtlinien angewendet hat.
- Das Adj-RIB-out
- Dies sind die Präfixe, die der abgefragte Router nach der Anwendung von Export-Routing-Richtlinien an einen Peer bekannt gegeben hat.
Außerdem werden verbesserte Telemetrie-Mechanismen implementiert, um wichtige Verkehrsstatistiken zu erhalten. Alles in allem ist eine solche Lösung mittelfristig durchaus realisierbar.
Dies ist ein weiteres Beispiel für eine echte Kundenherausforderung, die in der SDN-Ära durch eine teilweise Zentralisierung des Entscheidungsprozesses durch inkrementelle Intelligenz gelöst werden kann. Und es ist ein weiterer Fall von Automatisierung und Abstraktion.
Die Zweigstelle
Die in der Zweigstelle angebotenen Dienste waren bisher im Wesentlichen statisch. SPs suchen nach Möglichkeiten, dynamischere Dienste anzubieten, die der Kunde sogar selbst erbringen kann. Diese Dienste können die Betriebskosten senken, indem sie einige Aufgaben an den Kunden delegieren, und gleichzeitig dazu beitragen, den Umsatz durch eine schnellere Annahme der Dienste (Point-and-Click-Provisioning) und neue Geschäftsmodelle (Try-and-Buy) zu steigern.
Dies ist ein altes Bestreben von SPs und war das Ziel traditioneller Technologien wie Policy Server, PCRF, Radius/CoA und dergleichen. Der sogenannte Turbo Button, mit dem der Kunde die Bandbreite seines Breitbandanschlusses vorübergehend erhöhen kann, oder die Self-Provisioning-Portale, die dies ermöglichen, gibt es in der Branche schon seit vielen Jahren. Der Markt und das Geschäft sind jetzt jedoch im Aufwind und immer mehr Anbieter sind daran interessiert, diese Optionen aktiv anzubieten.
Heute, im SDN-Zeitalter, bedroht der wirtschaftliche Druck die Nachhaltigkeit, so dass die Steigerung des Umsatzes durch das Angebot flexiblerer Dienste zu einem Muss wird. Dies ist eine Chance für neu entstehende Lösungen, die auf zentralisierten Controllern basieren und eine flexible und automatisierte Konfiguration der Dienste ermöglichen.
Obwohl diese Szenarien bestehende Technologien nutzen und keine radikale architektonische Veränderung bedeuten, stellen alle diese Anwendungsfälle eine geschickte Kombination aus einem oder mehreren der folgenden Merkmale dar:
-
Automatisierung und Abstraktion
-
Ergänzung der Intelligenz der bestehenden Infrastruktur
-
Dynamisierung der Netzwerkentscheidungen
-
Entkopplung von Overlay und Underlay, um zu skalieren
Diese Eigenschaften wollen die Autoren in den vielen Kapiteln des Buches auf MPLS anwenden und es so zu einem grundlegenden Werkzeug im SDN-Zeitalter machen.
Get MPLS in der SDN-Ära now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
