Kapitel 1. Juniper MX Architektur
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
1998 brachte Juniper Networks seinen ersten Router heraus, den M40. Durch den Einsatz anwendungsspezifischer integrierter Schaltungen (ASICs) war der M40 in der Lage, jede andere Routerarchitektur zu übertreffen. Der M40 war auch der erste Router, der die Kontroll- und die Datenebene wirklich trennte - die M-Serie war geboren. Ursprünglich bezog sich der Modellname M40 auf seine Fähigkeit, 40 Millionen Pakete pro Sekunde (Mpps) zu verarbeiten. Mit der Erweiterung des Produktportfolios bezieht sich das "M" nun auf die verschiedenen Dienste, die auf dem Router verfügbar sind, wie z. B. MPLS mit einer Vielzahl von VPNs. Der Hauptanwendungsfall für die M-Serie war, dass Service Provider IP-basierte Dienste anbieten und gleichzeitig alte Frame Relay- und ATM-Netzwerke unterstützen konnten.
10 Jahre später ist die Zahl der Kunden, die von den Dienstanbietern betreut werden müssen, exponentiell gestiegen. Frame Relay und ATM wurden dezimiert, da die Kunden Hochgeschwindigkeitsdienste auf Layer-2- und Layer-3-Ethernet-Basis verlangen. Große Unternehmen werden immer mehr zu Service Providern und bieten IP-Dienste für Abteilungen und Tochtergesellschaften an.
Nahezu alle Netzwerkgeräte werden über Ethernet verbunden. Es ist eine der am besten verstandenen und am häufigsten eingesetzten Netzwerktechnologien von heute. Unternehmen stehen vor der Herausforderung, die Betriebskosten zu senken und gleichzeitig mehr Dienste anzubieten. Ethernet ermöglicht die Vereinfachung des Netzwerkbetriebs, der Verwaltung und der Wartung.
Die MX-Serie wurde 2007 eingeführt, um diese neuen Herausforderungen zu meistern. Sie ist für die Bereitstellung von Layer-2- und Layer-3-Ethernet-Diensten mit hoher Dichte und hoher Geschwindigkeit optimiert. Das "M" bezieht sich immer noch auf das Erbe der Mehrfachdienste, während das "X" auf die neuen Switching-Fähigkeiten und den Fokus auf 10G-Schnittstellen und darüber hinaus verweist; interessant ist auch, dass die römische Ziffer für die Zahl 10 "X" ist.
Es ist keine leichte Aufgabe, eine Plattform zu entwickeln, die diese neuen Herausforderungen bewältigen kann. Die MX-Serie hat einen starken Stammbaum: Obwohl sie sich mechanisch unterscheidet, nutzt sie die Technologie der M- und T-Serie für das Chassis-Management, die Switching Fabric und die Routing Engine.
Die Funktionen, die du von der M- und T-Serie kennst und liebst, sind natürlich auch in der MX-Serie vorhanden, da sie auf demselben Junos-Image läuft. Zusätzlich zu den "Oldies, but Goodies" gibt es eine ganze Reihe von Funktionen, die sich auf Service Provider Switching und Broadband Network Gateway (BNG) konzentrieren. Hier ist nur eine kleine Auswahl dessen, was auf der MX-Serie verfügbar ist:
- Hohe Verfügbarkeit
Non-Stop Routing (NSR), Non-Stop Bridging (NSB), Graceful Routing Engine Switchover (GRES), Graceful Restart (GR), und In-Service Software Upgrade (ISSU)
- Routenplanung
RIP, OSPF, IS-IS, BGP und Multicast
- Wechseln zu
Komplettes Paket von Spanning Tree Protokollen (STP), VLAN-Tag-Manipulation für Service Provider, QinQ und die Möglichkeit, über 4.094 Bridge-Domänen hinaus zu skalieren, indem virtuelle Switches genutzt werden
- Inline-Dienste
Network Address Translation (NAT), IP Flow Information Export (IPFIX), Tunneldienste und Port Mirroring
- MPLS
L3VPN, L2VPNs und VPLS
- Breitbanddienste
PPPoX, DHCP, Hierarchische QoS und IP-Adressen-Verfolgung
- Virtualisierung
Multi-Chassis Link Aggregation, virtuelle Chassis, logische Systeme, virtuelle Switches
Mit einem so großen Funktionsumfang ist der Einsatzbereich der MX-Serie sehr breit gefächert. Häufig findet man sie im Kern eines Service-Provider-Netzwerks, wo sie BNG bereitstellt, oder in Unternehmen, wo sie Kanten-Routing oder Core-Switching übernimmt.
In diesem Kapitel werden die MX-Plattform, die Funktionen und die Architektur vorgestellt. Wir gehen im Detail auf die Hardware, die Komponenten und die Redundanz ein.
Junos OS
Das Junos OS ist ein speziell entwickeltes Netzwerkbetriebssystem, das auf einem der stabilsten und sichersten Betriebssysteme der Welt basiert: FreeBSD. Die Junos-Software wurde als monolithische Kernel-Architektur entwickelt, bei der alle Betriebssystemdienste im Kernel-Bereich untergebracht sind. Die wichtigsten Komponenten von Junos sind als Daemons geschrieben, die eine vollständige Prozess- und Speichertrennung gewährleisten. Seit Junos 14.x wurde eine große Änderung eingeführt: die Modularität. Obwohl Junos immer noch auf FreeBSD basiert, wird es unabhängig vom "Gastbetriebssystem" und bietet eine Trennung zwischen dem Kernbetriebssystem und den HW-Treibern. In den nächsten Jahren sind viele Verbesserungen geplant.
Tatsächlich beginnt das Junos-Betriebssystem mit seiner großen Modernisierung, während die zweite Ausgabe dieses Buches geschrieben wird. Zu Skalierungszwecken wird es modularer, schneller und einfacher, um all die neuen virtuellen Funktionen zu unterstützen, die durch SDN entstehen. Junos migriert bereits zu den neuesten Software-Architekturen wie Kernel SMP und Multi-Core OS.
Ein Junos
Die Schaffung eines einzigen Netzwerkbetriebssystems, das für alle Router, Switches und Firewalls genutzt werden kann, vereinfacht den Netzwerkbetrieb, die Verwaltung und die Wartung. Netzwerkbetreiber müssen Junos nur einmal erlernen und können sofort mit anderen Juniper-Produkten arbeiten. Ein weiterer Vorteil einer einzigen Junos-Instanz ist, dass das Rad nicht neu erfunden werden muss und 10 verschiedene Implementierungen von BGP oder OSPF benötigt werden. Die Möglichkeit, diese Kernprotokolle einmal zu schreiben und sie dann in allen Produkten wiederzuverwenden, bietet ein hohes Maß an Stabilität, da der Code sehr ausgereift und praxiserprobt ist.
Software Releases
Lange Zeit (fast 15 Jahre) gab es in jedem Kalenderquartal ein konsistentes und vorhersehbares Release von Junos. In letzter Zeit hat Juniper seine Veröffentlichungsstrategie geändert, angefangen mit Junos 12.x und 13.x, die jeweils drei Hauptversionen boten, und dann Junos 14.x, das zwei Hauptversionen bot. Die Entwicklung des Kernbetriebssystems erfolgt nun in einem einzigen Release-Zug, so dass die Entwickler einmal neue Funktionen erstellen oder Fehler beheben und diese auf mehreren Plattformen gemeinsam nutzen können. Jede Junos-Softwareversion wird sowohl für 32-Bit- als auch für 64-Bit-Routing-Engines entwickelt.
Die Versionsnummern sind jetzt in einem Major- und Minor-Format. Die Major-Nummer ist die Version von Junos für ein bestimmtes Kalenderjahr und die Minor-Version gibt an, in welchem Semester dieses Jahres die Software veröffentlicht wurde. Wenn es mehrere Major- und Minor-Release-Nummern gibt, wird damit ein Major-Release bezeichnet, zum Beispiel 14.1, 14.2.
Seit Junos 14.x wird jede Version des Junos-Betriebssystems (die zwei Hauptversionen pro Jahr) für 36 Monate unterstützt. Mit anderen Worten: Jede Junos-Software hat ein bekanntes Extended End of Life (EEOL), wie in Abbildung 1-1 dargestellt.
Abbildung 1-1. Junos-Versionsmodell und -Rhythmus
Es gibt zwei verschiedene Arten von Junos-Versionen, die häufiger veröffentlicht werden, um Probleme zu beheben: Wartungs- und Service-Versionen. Wartungsversionen werden etwa alle acht Wochen veröffentlicht, um eine Reihe von Problemen zu beheben, und tragen das Präfix "R". Junos 14.2R2 wäre zum Beispiel das zweite Maintenance Release für Junos 14.2. Service-Releases werden bei Bedarf veröffentlicht, um ein kritisches Problem zu beheben, das noch nicht durch ein Maintenance-Release behoben wurde. Diesen Releases wird ein "S" vorangestellt. Ein Beispiel wäre Junos 14.2R3-S2.
Als Faustregel gilt, dass in jeder Nebenversion neue Funktionen und in jeder Wartungsversion Fehlerbehebungen hinzugefügt werden. Zum Beispiel werden mit Junos 14.1 bis 14.2 neue Funktionen eingeführt, während mit Junos 14.1R1 bis 14.1R2 Fehlerkorrekturen vorgenommen werden.
Mit dem nächsten Junos-Release "15" wird das Konzept der "Innovation"-Releases mit dem Präfix F eingeführt. Jedes Haupt-Release wird zwei Innovation-Releases anbieten, die den Kunden helfen sollen, innovative Funktionen schnell zu implementieren. Die innovativen Funktionen werden dann in die nächste Hauptversion aufgenommen. Zum Beispiel wird es für die Hauptversion 15.1 zwei "F"-Releases geben: 15.1F1 und 15.2F2. Und so wird es auch bei der zweiten Hauptversion, 15.2, sein. Die Neuerungen, die in 15.1F1 entwickelt wurden, werden dann nativ in die erste Wartungsversion der nächsten Hauptversion aufgenommen: 15.2R1
Junos Continuity-JAM
JAM steht für Junos Agile Deployment Methodology, ein neues Konzept, das auch unter seinem Marketingnamen Junos Continuity bekannt ist.
Die JAM-Funktion ist eine der neuen Modularitätsverbesserungen von Junos. In den Versionen vor 14.x waren die Hardwaretreiber in den größeren Junos-Software-Build eingebettet. Dadurch war es nicht möglich, neue Linecard-Modelle zu installieren (z. B. solche, die vor einer bestimmten Junos-Version noch nicht verfügbar waren), ohne eine komplett neue Junos-Installation durchzuführen.
Seit Junos 14.x wurde eine Trennung zwischen dem Junos-Kern und den Hardwaretreibern vorgenommen, sodass ein Betreiber neue Hardware auf bestehenden Junos-Versionen einsetzen kann (siehe Abbildung 1-2). Das ist ein bedeutender Fortschritt in Bezug auf den Zeitaufwand für das Testen, Validieren und Aufrüsten eines großen Netzwerks. In der Tat wird neue Hardware in der Regel häufiger von Kunden angefordert als eine neue Software, meist um die Bandbreitenkapazität zu erhöhen, die in Netzwerken von Internetdienstleistern oder Content-Providern sehr schnell wächst. Du brauchst nur mehr 10G- oder 100G-Schnittstellen pro Steckplatz, und zwar nur mit den eingestellten Paritätsfunktionen. Die Möglichkeit, neuere, schnellere und dichtere Hardware zu installieren und dabei die aktuelle stabile Junos-Version, die du konfiguriert hast, beizubehalten, ist ein großer Vorteil. JAM-Funktionen verhindern außerdem Ausfallzeiten, da die Installation neuer Hardware mit JAM keinen Neustart des Routers erfordert. Fantastisch, oder?
Das JAM-Modell besteht aus zwei Hauptkomponenten:
- Die JAM-Datenbank
Im Junos-Betriebssystem selbst enthalten (d.h. in einer JAM-fähigen Junos-Version), damit das Betriebssystem plattformspezifische Parameter und Attribute beibehält.
- Das JAM-Paket
Ein Satz von Linecard- und Chipsatztreibern (JFB-Datei).
Abbildung 1-2. Das JAM-Modell
Es gibt zwei Methoden, um JAM einzuführen und den größten Nutzen daraus zu ziehen:
Mit einem eigenständigen JAM-Paket, das für jede bestehende gewählte Version verfügbar ist (eine Version, die das JAM-Modell offiziell unterstützt). Die ersten gewählten Versionen für JAM sind 14.1R4 und 14.2R3. Ein eigenständiges JAM-Paket unterscheidet sich von einem jinstall-Paket, dem der Zusatz "jam-xxxx" vorangestellt ist
.Durch eine integrierte JAM-Freigabe. Bei dieser Konfiguration werden die JAM-Pakete direkt in das jinstall-Paket integriert.
Nehmen wir das Beispiel des ersten bereits verfügbaren JAM-Pakets(jam-mpc-2e-3e-ng64): JAM für NG-MPC2 und NG-MPC3 Karten. Dieses einzelne JAM-Paket enthält Hardwaretreiber für die folgenden neuen Karten:
MPC2E-3D-NG
MPC2E-3D-NG-Q
MPC3E-3D-NG
MPC3E-3D-NG-Q
Die gewählten Versionen für dieses Paket sind, wie bereits erwähnt, 14.1R4 und 14.2R3. Kunden, die diese Versionen verwenden, können die MPC-Karten der nächsten Generation ohne eine neue Junos-Installation installieren. Sie können das typische Installationsverfahren befolgen:
Füge einen neuen MPC ein (der MPC bleibt offline, da er nicht unterstützt wird).
Installiere das eigenständige JAM-Paket für die angegebene FRU.
Bring den MPC online.
MPC holt sich seinen Treiber aus der JAM-Datenbank (auf der RE).
Der MPC fährt dann hoch und ist voll funktionsfähig.
Benutzer, die ältere Versionen verwenden, sollten den integrierten Modus nutzen, indem sie die Junos-Versionen 14.1 oder 14.2 installieren, die ein JAM-Paket für diese Karten enthalten. Eine weitere Möglichkeit ist die Verwendung der nativen Version, die eine integrierte Unterstützung für die neuen MPCs bietet. Für NG-MPC 2- und NG-MPC3-Karten ist die native Version 15.1.R1.
Software Architektur
Junos wurde von Anfang an so konzipiert, dass eine Trennung von Kontroll- und Weiterleitungsebene möglich ist. Dies gilt auch für die MX-Serie, bei der alle Funktionen der Steuerebene von der Routing Engine ausgeführt werden, während die Weiterleitung von der Packet Forwarding Engine (PFE) übernommen wird. Die PFEs befinden sich auf der Leitungskarte, die auch über eine eigene CPU verfügt, um mit der RE zu kommunizieren und einige spezielle Inline-Funktionen zu verarbeiten.
Durch diese Trennung wird sichergestellt, dass die eine Ebene die andere nicht beeinträchtigt. Die Forwarding Plane kann zum Beispiel Datenverkehr mit hoher Geschwindigkeit weiterleiten und viele verschiedene Dienste ausführen, während die Routing Engine untätig ist und die Funktionen der Control Plane nicht beeinträchtigt werden. Es ist ein weit verbreiteter Irrglaube, dass die Kontrollebene nur Routing-Protokoll-Updates verarbeitet. Tatsächlich gibt es aber noch viele weitere Funktionen der Kontrollebene. Einige Beispiele sind:
Aktualisieren der Routing-Tabelle
Beantwortung von SNMP-Anfragen
Verarbeitung von SSH- oder HTTP-Datenverkehr zur Verwaltung des Routers
Ändern der Gebläsedrehzahl
Steuerung der Handwerksschnittstelle
Bereitstellung eines Junos Micro-Kernels für die PFEs
Aktualisieren der Weiterleitungstabelle auf den PFEs
Abbildung 1-3. Junos Software-Architektur
Auf einer hohen Ebene ist die Steuerungsebene in der Routing Engine implementiert, während die Weiterleitungsebene in jeder PFE mit einem kleinen, speziell entwickelten Kernel implementiert ist, der nur die erforderlichen Funktionen zum Routen und Vermitteln des Datenverkehrs enthält. Einige Aufgaben der Steuerungsebene werden an die CPU der Trio Linecards delegiert, um die Skalierbarkeit zu erhöhen. Dies gilt für den ppmd Prozess, auf den wir gleich noch eingehen werden.
Der Vorteil der Trennung von Steuerung und Weiterleitung besteht darin, dass jeglicher Datenverkehr, der durch den Router geroutet oder geschaltet wird, auf den PFEs und der Switch-Fabric immer mit der Leitungsrate verarbeitet wird; wenn ein Router zum Beispiel Datenverkehr zwischen Webservern und dem Internet verarbeitet, wird die gesamte Verarbeitung von der Weiterleitungsebene durchgeführt.
Der Junos-Kernel besteht aus fünf großen Daemons. Jeder dieser Daemons spielt eine wichtige Rolle innerhalb des MX und arbeitet über Interprocess Communication (IPC) und Routing-Sockets zusammen, um mit dem Junos-Kernel und anderen Daemons zu kommunizieren. Die folgenden Daemons stehen im Mittelpunkt und sind für den Betrieb von Junos erforderlich:
Verwaltungsdämon (
mgd)Routing-Protokoll-Daemon (
rpd)Periodischer Paketmanagement-Daemon (
ppmd)Gerätekontroll-Daemon (
dcd)Chassis Daemon (
chassisd)
Es gibt noch viele weitere Daemons für Aufgaben wie NTP, VRRP, DHCP und andere Technologien, aber sie spielen eine kleinere und spezifischere Rolle in der Software-Architektur.
Management Daemon
In der Junos-Benutzeroberfläche (UI) werden alle Daten in einer zentralen Datenbank gespeichert. Dadurch kann Junos Daten auf interessante Art und Weise verarbeiten und fortschrittliche Funktionen wie Konfigurations-Rollback, Anwendungsgruppen und das Aktivieren und Deaktivieren ganzer Teile der Konfiguration ermöglichen.
Die Benutzeroberfläche besteht aus vier Hauptkomponenten: der Konfigurationsdatenbank, dem Datenbankschema, dem Verwaltungsdämon (mgd) und der Befehlszeilenschnittstelle (cli).
Der Management-Daemon (mgd) ist der Klebstoff, der die gesamte Junos-Benutzeroberfläche (UI) zusammenhält. Auf einer hohen Ebene bietet mgd einen Mechanismus zur Verarbeitung von Informationen sowohl für Netzwerkbetreiber als auch für Daemons.
Die interaktive Komponente von mgd ist die Junos cli; dies ist eine terminalbasierte Anwendung, die dem Netzbetreiber eine Schnittstelle zu Junos bietet. Die andere Seite von mgd ist die XML-Schnittstelle (Extensible Markup Language) für Remote Procedure Calls (RPC). Diese bietet über Junoscript und Netconf eine API, die die Entwicklung von Automatisierungsanwendungen ermöglicht.
Die Aufgaben von cli sind:
Bearbeitung auf der Kommandozeile
Terminal-Emulation
Terminal Paging
Anzeige von Befehls- und Variablenvervollständigungen
Überwachung von Protokolldateien und Schnittstellen
Ausführen von Kindprozessen wie ping, traceroute und ssh
mgd Zu den Aufgaben gehören:
Übergabe von Befehlen von
clian den entsprechenden DaemonSuche nach Befehls- und Variablenvervollständigungen
Parsing-Befehle
Interessant ist, dass die meisten Junos-Befehle XML verwenden, um Daten zu übertragen. Um ein Beispiel dafür zu sehen, füge einfach den Pipe-Befehl display xml zu einem beliebigen Befehl hinzu. Werfen wir einen Blick auf einen einfachen Befehl wie show isis adjacency:
{master}
dhanks@R1-RE0> show isis adjacency
Interface System L State Hold (secs) SNPA
ae0.1 R2-RE0 2 Up 23
So weit sieht alles normal aus. Fügen wir die display xml hinzu, um einen genaueren Blick darauf zu werfen:
{master}dhanks@R1-RE0> show isis adjacency | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R1/junos">
<isis-adjacency-information xmlns="http://xml.juniper.net/junos/11.4R1/junos
-routing" junos:style="brief">
<isis-adjacency>
<interface-name>ae0.1</interface-name>
<system-name>R2-RE0</system-name>
<level>2</level>
<adjacency-state>Up</adjacency-state>
<holdtime>22</holdtime>
</isis-adjacency>
</isis-adjacency-information>
<cli>
<banner>{master}</banner>
</cli>
</rpc-reply>
Wie du siehst, werden die Daten in XML formatiert und von mgd über RPC empfangen.
Diese Funktion (die seit den Anfängen von Junos zur Verfügung steht) ist ein sehr cleverer Mechanismus zur Trennung zwischen dem Datenmodell und der Datenverarbeitung und erweist sich als großer Vorteil in unserem neu entdeckten Zeitalter der Netzwerkautomatisierung - zusätzlich zum netconf-Protokoll bietet Junos die Möglichkeit, den MX auf effiziente Weise aus der Ferne zu verwalten und zu konfigurieren.
Routing Protokoll Daemon
Der Routing Protocol Daemon (rpd) verwaltet alle in Junos konfigurierten Routing-Protokolle. Seine Aufgaben bestehen im Wesentlichen darin, Routing-Ankündigungen und -Updates zu empfangen, die Routing-Tabelle zu pflegen und aktive Routen in die Weiterleitungstabelle einzutragen. Um die Prozesstrennung aufrechtzuerhalten, wird jedes auf dem System konfigurierte Routing-Protokoll als separate Aufgabe innerhalb von rpd ausgeführt. Die andere Aufgabe von rpd ist der Informationsaustausch mit dem Junos-Kernel, um Schnittstellenänderungen zu empfangen, Routeninformationen zu senden und Schnittstellenänderungen zu versenden.
Werfen wir einen Blick auf rpd, um zu sehen, was da los ist. Der versteckte Befehl set task accounting schaltet die CPU-Abrechnung ein und aus:
{master}
dhanks@R1-RE0> set task accounting on
Task accounting enabled.
Jetzt sind wir startklar. Junos erstellt gerade ein Profil der Daemons und Tasks, um eine bessere Vorstellung davon zu bekommen, was die CPU der Routing Engine beansprucht. Lass uns ein paar Minuten warten, bis er Daten gesammelt hat.
Wir können jetzt show task accounting verwenden, um die Ergebnisse zu sehen:
{master}
dhanks@R1-RE0> show task accounting
Task accounting is enabled.
Task Started User Time System Time Longest Run
Scheduler 265 0.003 0.000 0.000
Memory 2 0.000 0.000 0.000
hakr 1 0.000 0 0.000
ES-IS I/O./var/run/ppmd_c 6 0.000 0 0.000
IS-IS I/O./var/run/ppmd_c 46 0.000 0.000 0.000
PIM I/O./var/run/ppmd_con 9 0.000 0.000 0.000
IS-IS 90 0.001 0.000 0.000
BFD I/O./var/run/bfdd_con 9 0.000 0 0.000
Mirror Task.128.0.0.6+598 33 0.000 0.000 0.000
KRT 25 0.000 0.000 0.000
Redirect 1 0.000 0.000 0.000
MGMT_Listen./var/run/rpd_ 7 0.000 0.000 0.000
SNMP Subagent./var/run/sn 15 0.000 0.000 0.000
Hier ist nicht allzu viel los, aber du verstehst schon. Derzeit sind alle laufenden Daemons und Tasks auf rpd vorhanden und werden berücksichtigt.
Wenn du mit der Fehlersuche fertig bist, solltest du die Buchhaltung ausschalten:
{master}
dhanks@R1-RE0> set task accounting off
Task accounting disabled.
Warnung
Der Befehl set task accounting ist aus einem bestimmten Grund versteckt. Es ist möglich, dass der Junos-Kernel zusätzlich belastet wird, wenn Accounting aktiviert ist. Es wird nicht empfohlen, diesen Befehl in einem produktiven Netzwerk auszuführen, es sei denn, der JTAC weist dich dazu an. Vergiss auch hier nicht, den Befehl nach dem Debugging mit set task accounting off wieder zu deaktivieren.
Periodischer Paketmanagement-Daemon
Das Periodic Packet Management (ppmd) ist ein spezieller Prozess, der für die Verarbeitung und Verwaltung von Hello-Paketen verschiedener Protokolle zuständig ist. In den ersten Junos-Versionen verwaltete RPD den Status der Adjacencies. Jede Aufgabe, wie z. B. OSPF und ISIS, war für den Empfang und das Senden periodischer Pakete und die Aufrechterhaltung der Zeit jeder Adjazenz zuständig. In einigen Konfigurationen, in großen Skalierungsumgebungen mit aggressiven Zeitplänen (nahe der Sekunde), konnte RPD Zeitplannungsprogramm SLIP-Ereignisse erleben, die die von den periodischen Hellos benötigte Echtzeit brachen.
Juniper beschloss, die Verwaltung der Hello-Pakete außerhalb von RPD zu verlagern, um die Stabilität und Zuverlässigkeit in skalierten Umgebungen zu verbessern. Ein weiteres Ziel war es, die Erkennung von Ausfällen im Subsekundenbereich zu ermöglichen, indem neue Protokolle wie BFD Haltezeiten im Millisekundenbereich vorschlagen können.
Zunächst einmal wurde ppmd für die Protokolle ISIS und OSPF entwickelt, und zwar als Teil des Routing-Daemon-Prozesses. Du kannst diesen Befehl anzeigen, um zu überprüfen, welche Aufgabe des RPD ihr Hallo-Management an ppmd delegiert hat:
jnpr@R1> show task | match ppmd_control 39 ES-IS I/O./var/run/ppmd_control 40 <> 39 IS-IS I/O./var/run/ppmd_control 39 <> 40 PIM I/O./var/run/ppmd_control 41 <> 40 LDP I/O./var/run/ppmd_control 16 <>
ppmd wurde später erweitert, um weitere Protokolle zu unterstützen, darunter LACP, BFD, VRRP und OAM LFM. Die letztgenannten Protokolle sind nicht in RPD kodiert, sondern haben einen eigenen Prozess mit entsprechendem Namen: lacpd, bfdd, vrrpd, lfmd usw.
Die Motivation von ppmd ist es, gegenüber seinen Clients (RPD, LACP, BFD...) so unauffällig wie möglich zu sein. Mit anderen Worten: Die Prozesse des Clients werden nur benachrichtigt, wenn sich die Adjazenz ändert oder um gesammelte Statistiken zurückzusenden.
Seit einigen Jahren ist ppmd nicht mehr ein einzelner Prozess, der auf der Routing Engine gehostet wird, sondern wurde so entwickelt, dass er verteilt arbeitet. Tatsächlich läuft ppmd auf der Routing Engine, aber auch auf jeder Trio Line Card, auf der CPU der Line Card, wo er PPM Manager, auch bekannt als ppm man, genannt wird. Der folgende PFE-Befehl zeigt den ppm man-Thread auf einer Linecard-CPU:
NPC11(R1 vty)# show threads [...] 54 M asleep PPM Manager 4664/8200 0/0/2441 ms 0%
Die Motivation, einen Teil der Steuerungsverarbeitung an die CPU der Line Card zu delegieren, entstand mit dem Aufkommen von Subsekundenprotokollen wie BFD. Seit Kurzem bietet die Trio Line Card eine dritte, verbesserte Version von ppm, die auch durch das BFD-Protokoll in skalierten Umgebungen angetrieben wird und als Inline ppm bezeichnet wird. In diesem Fall hat das Junos-Betriebssystem die Sitzungsverwaltung an die Packet Forwarding Engines selbst ausgelagert.
Um zu überprüfen, welche Adjazenz an die Hardware delegiert ist oder nicht, kannst du die folgenden versteckten Befehle verwenden:
/* all adjacencies manages by ppmd */ jnpr@R1> show ppm adjacencies Protocol Hold time (msec) VRRP 9609 LDP 15000 LDP 15000 ISIS 9000 ISIS 27000 PIM 105000 PIM 105000 LACP 3000 LACP 3000 LACP 3000 LACP 3000 Adjacencies: 11, Remote adjacencies: 4 /* all adjacencies manages by remote ppmd (ppm man or inline ppmd) */ jnpr@R1> show ppm adjacencies remote Protocol Hold time (msec) LACP 3000 LACP 3000 LACP 3000 LACP 3000 Adjacencies: 4, Remote adjacencies: 4
Die Funktionen ppm-Delegation und Inline ppm sind standardmäßig aktiviert, können aber auch ausgeschaltet werden. In der folgenden Konfiguration funktioniert nur die ppmd Instanz der Routing Engine.
set routing-options ppm no-delegate-processing set routing-options ppm no-inline-processing
Hinweis
Warum die ppm-Delegationsfunktionen deaktivieren?
Die Protokolldelegation ist nicht mit dem eingebetteten Tool tcpdump (Monitor Traffic Interface) kompatibel. Du kannst keine Control-Plane-Pakete erfassen, die von ppm man oder inline ppmd verwaltet werden. Für Labortests oder Wartungsfenster kann es daher hilfreich sein, die Delegations-/Inline-Modi vorübergehend zu deaktivieren, um Pakete über den Befehl monitor traffic interface zu erfassen.
Abbildung 1-4 veranschaulicht die Beziehung zwischen ppmd Instanzen und anderen Junos-Prozessen.
Abbildung 1-4. PPM-Architektur
Gerätekontroll-Daemon
Der Device Control Daemon (dcd) ist für die Konfiguration der Schnittstellen auf der Grundlage der aktuellen Konfiguration und der verfügbaren Hardware zuständig. Ein Merkmal von Junos ist die Möglichkeit, nicht vorhandene Hardware zu konfigurieren, da davon ausgegangen wird, dass die Hardware zu einem späteren Zeitpunkt hinzugefügt werden kann und "einfach funktioniert". Ein Beispiel dafür ist die Erwartung, dass du set interfaces ge-1/0/0.0 family inet address 192.168.1.1/24 konfigurieren und übertragen kannst. Angenommen, es gibt keine Hardware in FPC1, wird diese Konfiguration nichts bewirken. Sobald die Hardware in FPC1 installiert ist, wird der erste Port sofort mit der Adresse 192.168.1.1/24 konfiguriert.
Chassis Daemon (und Freunde)
Der Chassis-Daemon (chassisd) unterstützt alle Chassis-, Alarm- und Umgebungsprozesse. Dazu gehören die Überwachung des Zustands der Hardware, die Verwaltung einer Echtzeit-Datenbank mit dem Hardware-Inventar und die Koordination mit dem Alarm-Daemon (alarmd) und dem Craft-Daemon (craftd), um Alarme und LEDs zu verwalten.
Alles sollte selbsterklärend sein, bis auf craftd; die Craft-Schnittstelle, die die Vorderseite des Geräts ist, wie in Abbildung 1-5 gezeigt. Schauen wir uns das MX960 Craft Interface genauer an.
Abbildung 1-5. Juniper MX960 Craft Interface
Die Handwerkerschnittstelle besteht aus einer Reihe von Tasten und LED-Leuchten, die den aktuellen Status der Hardware und Alarme anzeigen. Außerdem können Informationen abgerufen werden:
dhanks@R1-RE0> show chassis craft-interface Front Panel System LEDs: Routing Engine 0 1 -------------------------- OK * * Fail . . Master * . Front Panel Alarm Indicators: ----------------------------- Red LED . Yellow LED . Major relay . Minor relay . Front Panel FPC LEDs: FPC 0 1 2 ------------------ Red . . . Green . * * CB LEDs: CB 0 1 -------------- Amber . . Green * * PS LEDs: PS 0 1 2 3 -------------------- Red . . . . Green * . . . Fan Tray LEDs: FT 0 ---------- Red . Green *
Eine letzte Aufgabe von chassisd ist die Überwachung der Strom- und Kühlungsumgebung. chassisd überwacht ständig die Spannungen aller Komponenten im Gehäuse und sendet Warnungen, wenn die Spannung einen bestimmten Schwellenwert überschreitet. Das Gleiche gilt für die Kühlung. Der Chassis-Daemon überwacht ständig die Temperatur der verschiedenen Komponenten und Chips sowie die Lüftergeschwindigkeit. Wenn irgendetwas ungewöhnlich ist, gibt chassisd eine Warnung aus. Unter extremen Temperaturbedingungen kann chassisd auch Komponenten abschalten, um Schäden zu vermeiden.
Routing-Steckdosen
Routing-Sockets sind ein UNIX-Mechanismus zur Steuerung der Routing-Tabelle. Der Junos-Kernel nutzt denselben Mechanismus und erweitert ihn um zusätzliche Informationen, um zusätzliche Attribute zu unterstützen und ein Netzwerkbetriebssystem der Carrier-Klasse zu schaffen.
Abbildung 1-6. Architektur der Routing-Buchse
Bei der Verwendung von Routing Sockets gibt es zwei Akteure: State Producer und State Consumer. Der rpd Daemon ist für die Verarbeitung von Routing-Updates zuständig und ist somit der State Producer. Andere Daemons werden als State-Consumer bezeichnet, da sie die von den Routing-Sockets empfangenen Informationen verarbeiten.
Werfen wir einen Blick in die Routing-Sockets und sehen, was passiert, wenn wir ge-1/0/0.0 mit der IP-Adresse 192.168.1.1/24 konfigurieren. Mit dem Befehl rtsockmon in der Shell können wir die Befehle sehen, die von den Junos-Daemons an den Kernel gesendet werden:
{master}
dhanks@R1-RE0> start shell
dhanks@R1-RE0% rtsockmon -st
sender flag type op
[16:37:52] dcd P iflogical add ge-1/0/0.0 flags=0x8000
[16:37:52] dcd P ifdev change ge-1/0/0 mtu=1514 dflags=0x3
[16:37:52] dcd P iffamily add inet mtu=1500 flags=0x8000000200000000
[16:37:52] dcd P nexthop add inet 192.168.1.255 nh=bcst
[16:37:52] dcd P nexthop add inet 192.168.1.0 nh=recv
[16:37:52] dcd P route add inet 192.168.1.255
[16:37:52] dcd P route add inet 192.168.1.0
[16:37:52] dcd P route add inet 192.168.1.1
[16:37:52] dcd P nexthop add inet 192.168.1.1 nh=locl
[16:37:52] dcd P ifaddr add inet local=192.168.1.1
[16:37:52] dcd P route add inet 192.168.1.1 tid=0
[16:37:52] dcd P nexthop add inet nh=rslv flags=0x0
[16:37:52] dcd P route add inet 192.168.1.0 tid=0
[16:37:52] dcd P nexthop change inet nh=rslv
[16:37:52] dcd P ifaddr add inet local=192.168.1.1 dest=192.168.1.0
[16:37:52] rpd P ifdest change ge-1/0/0.0, af 2, up, pfx 192.168.1.0/24
Hinweis
Wir haben die Schnittstelle ge-1/0/0 in einem anderen Terminalfenster konfiguriert und die Änderung bestätigt, während der Befehl rtstockmon ausgeführt wurde.
Der Befehl rtsockmon ist ein Junos-Shell-Befehl, der dem Benutzer Einblick in die vom Routing-Socket weitergeleiteten Nachrichten gibt. Die Routing-Sockets sind in vier Hauptkomponenten unterteilt: Absender, Typ, Operation und Argumente. Das Absenderfeld wird verwendet, um zu identifizieren, welcher Daemon in den Routing-Socket schreibt. Der Typ gibt an, welches Attribut geändert wird. Das Feld Operation zeigt an, was tatsächlich durchgeführt wird. Es gibt drei grundlegende Operationen: Hinzufügen, Ändern und Löschen. Das letzte Feld sind die Argumente, die an den Junos-Kernel übergeben werden. Dabei handelt es sich um Sätze von Schlüssel- und Wertepaaren, die geändert werden.
Im vorherigen Beispiel kannst du sehen, wie dcd mit dem Routing-Socket interagiert, um ge-1/0/0.0 zu konfigurieren und eine IPv4-Adresse zuzuweisen:
dcderstellt eine neue logische Schnittstelle (IFL).dcdändert das Schnittstellengerät (IFD), um die richtige MTU einzustellen.dcdfügt eine neue Schnittstellenfamilie (IFF) hinzu, um IPv4 zu unterstützen.dcdsetzt die Nexthop-, Broadcast- und andere Attribute, die für die RIB und FIB benötigt werden.dcdfügt die Schnittstellenadresse (IFA) von 192.168.1.1 hinzu.rpdfügt schließlich eine Route für 192.168.1.1 hinzu und bringt sie hoch.
Junos OS-Modernisierung
Mit Junos 14.2 hat Juniper sein Modernisierungsprogramm für das Junos-Betriebssystem gestartet. Ziel ist es, mehr Skalierbarkeit, schnellere Bootvorgänge und Commits, Konvergenzverbesserungen und so weiter zu bieten.
Dieses riesige Projekt wurde in mehrere Phasen unterteilt und die wichtigsten Schritte sind:
RPD 64-Bit: Obwohl Junos 64-Bit seit der Einführung der Routing Engine mit 64-Bit-Prozessoren verfügbar ist, war der RPD-Daemon immer noch ein 32-Bit-Prozess, der nicht mehr als 4 GB Speicher adressieren kann. Ab Junos 14.1 kannst du den RPD 64-Bit-Modus explizit einschalten, damit das Gerät mehr Speicher auf der 64-Bit-RE adressieren kann. Das ist sehr nützlich für Umgebungen, die große Mengen an Routen im RIB anfordern:
{master}[edit system] jnpr@R1# set processes routing force-64-bitFreeBSD-Upgrade und Junos-Unabhängigkeit: Mit der Version 15.1 wird Junos in Bezug auf das FreeBSD-Betriebssystem völlig unabhängig. Außerdem wurde FreeBSD mit der Version 10 aktualisiert, um die neuesten Betriebssystemerweiterungen (wie Kernel SMP) zu unterstützen. Junos und FreeBSD können unabhängig voneinander aktualisiert werden, was eine intelligentere Paketierung der Installation und eine bessere Reaktionsfähigkeit auf FreeBSD-Updates (Sicherheitspatches, neue Betriebssystemfunktionen usw.) ermöglicht.
Kernel SMP(Symmetric Multi-Processing) Unterstützung: kürzlich in Junos 15.1 eingeführt.
RPD Modularität: RPD wird nicht länger ein monolithischer Prozess sein, sondern in mehrere Prozesse aufgeteilt, um eine saubere Trennung zwischen E/A-Modulen und den Protokollen selbst einzuführen. Diese Trennung wird mit den Protokollen BGP und RSVP in Junos 16.x beginnen.
RPD Multi-Core: Die gesamte Multi-Core-Systeminfrastruktur wird nach Junos 16.x geplant.
Hinweis
Beachte, dass die Leistung des Junos-Betriebssystems ab Version 15.x deutlich verbessert wurde, vor allem in Bezug auf die Konvergenz.
Der Micro-Kernel des MPCs ist ebenfalls vom Junos-Modernisierungsprogramm vorgesehen. Die neuen MPCs, beginnend mit NG-MPC2 und NG-MPC-3, unterstützen einen neuen Multi-Core-Prozessor mit einem angepassten Linux-Betriebssystem, wie in Abbildung 1-7 dargestellt. (Der bisherige Mikrokernel wird zu einem Prozess über das Linux-Betriebssystem.) Diese neue Systemkonfiguration des MPC ermöglicht eine größere Modularität und erlaubt die Implementierung zukünftiger Prozesse in den MPC, wie z. B. den Telemetrieprozess.
Abbildung 1-7. Junos-Modernisierung
Juniper MX-Gehäuse
Abbildung 1-8. Juniper MX-Familie
Von der virtuellen MX (vMX) bis zur 45U gibt es die MX in vielen Formen und Konfigurationen. Von links nach rechts: vMX, MX5/10/40/80, MX104, MX240, MX480, MX960, MX2010 und MX2020. Die Modelle ab MX240 haben ein Gehäuse, in dem alle Komponenten wie Line Cards, Routing Engines und Switching Fabrics untergebracht sind. Die Modelle MX104 und darunter gelten als Mittelklasse und nehmen nur Schnittstellenmodule auf.
| Modell | DPC-Kapazität | MPC-Kapazität |
|---|---|---|
| vMX | N/A | 160 Gbit/s |
| MX5 | N/A | 20 Gbit/s |
| MX10 | N/A | 40 Gbit/s |
| MX40 | N/A | 60 Gbit/s |
| MX80 | N/A | 80 Gbit/s |
| MX104 | N/A | 80 Gbit/s |
| MX240 | 240 Gbit/s | 1,92 Tbps |
| MX480 | 480 Gbit/s | 5,12 Tbps |
| MX960 | 960 Gbit/s | Skalierung auf bis zu 9,92 Tbps |
| MX2010 | N/A | Skalierung auf bis zu 40 Tbps |
| MX2020 | N/A | 80 Tbps |
Hinweis
Beachte, dass die DPC- und MPC-Kapazität auf der aktuellen Hardware - 4x10GE DPC und MPC5e oder MPC6e - basiert und sich in Zukunft ändern kann, wenn neue Hardware auf den Markt kommt. Diese Informationen dienen nur als Beispiel. Informiere dich immer online unter www.juniper.net über die neuesten Spezifikationen.
vMX
Die MX-Reise in diesem Buch beginnt mit dem virtuellen MX oder vMX. Auch wenn vMX in diesem Buch ein eigenes Kapitel gewidmet wird, ist es wichtig, an dieser Stelle zu erwähnen, dass vMX nicht nur ein Klon der Control-Plane-Entität des klassischen Junos ist. vMX ist ein kompletter Software-Router mit einer vollständigen Trennung der Control-Plane und der Forwarding-Plane wie sein Hardware-"Vater". vMX besteht aus zwei virtuellen Maschinen (VM):
VCP VM: Virtual Control Plane
VFP VM: Virtual Forwarding Plane
Beide VMs laufen auf einem KVM-Hypervisor; außerdem läuft das Gastbetriebssystem der virtuellen VCP-Maschine auf FreeBSD und VFP auf Linux. Die beiden VMs kommunizieren miteinander über den virtuellen Switch des KVM-Host-Betriebssystems. Abbildung 1-9 veranschaulicht die Systemarchitektur des vMX. Kapitel 11 beschreibt jede Komponente und ihre Funktionsweise.
Abbildung 1-9. Die grundlegende Architektur des vMX-Systems
MX80
Der MX80 ist ein kleiner, kompakter 2U-Router, den es in zwei Modellen gibt: MX80 und MX80-48T. Der MX80 unterstützt zwei Modular Interface Cards (MICs), während der MX80-48T 48 10/100/1000BASE-T-Ports unterstützt. Aufgrund der geringen Größe der MX80 wird die gesamte Weiterleitung von einem einzigen Trio-Chip übernommen, so dass keine Switch-Fabric erforderlich ist. Ein zusätzlicher Vorteil ist, dass jede MX80 anstelle einer Switch Fabric mit vier festen 10GE-Ports ausgestattet ist.
Abbildung 1-10. Die Juniper MX80-48T unterstützt 48x1000BASE-T und 4x10GE-Ports
Jede MX80 wird mit vor Ort austauschbaren, redundanten Netzteilen und Lüftereinschüben geliefert. Die Netzteile sind sowohl als AC- als auch als DC-Netzteile erhältlich. Weil die MX80 so kompakt ist, bietet sie keine Steckplätze für Routing Engines, Switch Control Boards (SCBs) oder FPCs. Die Routing Engine ist in das Gehäuse eingebaut und kann nicht ausgetauscht werden. Die MX80 unterstützt nur MICs.
Hinweis
Die MX80 hat eine einzelne Routing Engine und unterstützt derzeit keine Funktionen wie NSR, NSB und ISSU.
Aber lass dich von der geringen Größe des MX80 nicht täuschen. Dies ist ein echter hardwarebasierter Router, der auf dem Juniper Trio Chipsatz basiert. Hier sind einige der Leistungs- und Skalierungsmerkmale auf einen Blick:
55 Mpps
1.000.000 IPv4-Präfixe in der Forwarding Information Base (FIB)
4.000.000 IPv4-Präfixe in der Routing Information Base (RIB)
16.000 logische Schnittstellen (IFLs)
512.000 MAC-Adressen
Nummerierung der MX80-Schnittstelle
Die MX80 hat zwei FPCs: FPC0 und FPC1. FPC0 sind immer die vier festen 10GE-Ports, die sich unten rechts befinden. Die FPC0-Ports sind von links nach rechts nummeriert, beginnend mit xe-0/0/0 und endend mit xe-0/0/3.
Abbildung 1-11. Juniper MX80 FPC- und PIC-Positionen
Hinweis
Die beiden Stromversorgungen werden als Power Entry Module (PEM) bezeichnet: PEM0 und PEM1.
Auf FPC1 werden die MICs installiert. MIC0 ist auf der linken Seite und MIC1 auf der rechten Seite installiert. Jedes MIC hat zwei Physical Interface Cards (PICs). Je nach MIC, z. B. 20x1GE oder 2x10GE, variiert die Gesamtzahl der Anschlüsse. Unabhängig von der Anzahl der Anschlüsse ist die Nummerierung der Anschlüsse von links nach rechts und beginnt immer mit 0.
MX80-48T Schnittstellennummerierung
Die Schnittstellennummerierung der MX80-48T ist der der MX80 sehr ähnlich. FPC0 bleibt gleich und bezieht sich auf die vier festen 10GE-Ports. Der einzige Unterschied ist, dass sich FPC1 auf die 48x1GE-Ports bezieht. FPC1 enthält vier PICs; die Nummerierung beginnt unten links, arbeitet sich nach oben und verschiebt sich dann wieder von unten nach rechts. Jedes PIC enthält 12x1GE-Ports mit den Nummern 0 bis 11.
Abbildung 1-12. Juniper MX80-48T FPC- und PIC-Positionen
| FPC | PIC | Interface Namen |
|---|---|---|
| FPC0 | PIC0 | xe-0/0/0 über xe-0/0/3 |
| FPC1 | PIC0 | ge-1/0/0 über ge-1/0/11 |
| FPC1 | PIC1 | ge-1/1/0 über ge-1/1/11 |
| FPC1 | PIC2 | ge-1/2/0 über ge-1/2/11 |
| FPC1 | PIC3 | ge-1/3/0 über ge-1/3/11 |
Da jeder PIC in FPC1 über 12x1GE-Ports verfügt und insgesamt vier PICs vorhanden sind, ergibt sich eine Gesamtzahl von 48x1GE-Ports.
Die MX80-48T hat 48x1GE und 4x10GE Ports und unterstützt keine MICs. Diese Ports sind direkt mit einem einzelnen Trio-Chip verbunden, da keine Switch-Fabric vorhanden ist.
Mittelklasse
Abbildung 1-13. Juniper MX5
Wenn der MX80 immer noch zu groß für einen Router ist, gibt es Lizenzierungsoptionen, um die Anzahl der Ports des MX80 zu begrenzen. Der Vorteil ist, dass du die gesamte Leistung und Skalierung des MX80 erhältst, aber zu einem Bruchteil der Kosten. Diese Lizenzierungsoptionen werden als MX Midrange bezeichnet: MX5, MX10, MX40 und MX80.
| Modell | MIC-Steckplatz 0 | MIC-Steckplatz 1 | Feste 10GE-Anschlüsse | Dienstleistungen MIC |
|---|---|---|---|---|
| MX5 | Verfügbar | Eingeschränkt | Eingeschränkt | Verfügbar |
| MX10 | Verfügbar | Verfügbar | Eingeschränkt | Verfügbar |
| MX40 | Verfügbar | Verfügbar | Zwei Ports verfügbar | Verfügbar |
| MX80 | Verfügbar | Verfügbar | Alle vier Ports verfügbar | Verfügbar |
Jeder Router ist über eine Lizenz softwaremäßig aufrüstbar. Zum Beispiel kann der MX5 auf den MX10 oder direkt auf den MX40 oder MX80 aufgerüstet werden.
Für den Abschluss einer kleinen Anzahl von Stromkreisen oder Ethernet-Übergaben sind die MX5 bis MX40 die perfekte Wahl. Obwohl die Anzahl der Ports begrenzt ist, sind alle Leistungs- und Skalierungswerte identisch mit denen des MX80. Wenn man zum Beispiel bedenkt, dass eine vollständige Internet-Routing-Tabelle derzeit etwa 420.000 IPv4-Präfixe umfasst, kann die MX5 mehr als neun vollständige Internet-Routing-Tabellen verarbeiten.
Vergiss nicht, dass die MX5, MX10 und MX40 eigentlich nur eine MX80 sind. Es gibt keinen Unterschied bei der Hardware, der Skalierung oder der Leistung. Der einzige Nachteil ist, dass die MX5, MX10 und MX40 eine andere Frontansicht auf der Vorderseite des Routers für das Branding verwenden.
Die einzige Einschränkung beim MX5, MX10 und MX40 sind die Ports, die konfiguriert werden dürfen. Die Software legt keinerlei Bandbreitenbeschränkungen für die Ports fest. Es ist ein weit verbreitetes Missverständnis, dass der MX5 ein "5-Gig-Router" ist, aber das ist nicht der Fall. Der MX5 wird zum Beispiel mit einem 20x1GE-MIC geliefert und ist in der Lage, jeden Port mit Leitungsgeschwindigkeit zu betreiben.
MX104
Der MX104 ist ein High-Density-Router für Voraggregation und Zugang. Er wurde so konzipiert, dass er kompakt und mit deckenhohen Racks kompatibel ist. Auch wenn er für die Aggregation von mobilem Datenverkehr optimiert wurde, ist der MX104 auch als PE für Unternehmens- und private Zugangsnetze geeignet.
Abbildung 1-14. Juniper MX104
Der MX104 bietet Redundanz für die Stromversorgung und die Routing Engine. Das Gehäuse bietet vier Steckplätze für MICs - diese MICs sind mit denen der MX5/MX10/MX40 und MX80 Router kompatibel. Die MX104 verfügt außerdem über vier integrierte 10-Gigabit-Ethernet-SFP+-Ports.
Nummerierung der Schnittstelle
Jeder MX104 Router hat drei eingebaute MPCs, die in der CLI als FPC 0 bis FPC 2 dargestellt werden. Die Nummerierung der MPCs erfolgt von unten nach oben. MPC 0 und 1 können jeweils zwei MICs aufnehmen. MPC 2 hostet ein eingebautes MIC mit vier 10GE-Ports. Abbildung 1-15 zeigt die Schnittstellennummerierung der MX104.
Hinweis
Jedes MIC kann die Ports unterschiedlich nummerieren. In Abbildung 1-15 sind zwei Arten von MICs als Beispiele dargestellt.
Abbildung 1-15. Juniper MX104 Schnittstellennummerierung
MX240
Der MX240 (siehe Abbildung 1-16) ist der erste Router der MX-Serie mit einem Gehäuse, das modulare Routing Engines, SCBs und FPCs unterstützt. Der MX240 ist 5 HE hoch und unterstützt vier horizontale Steckplätze. Es gibt Unterstützung für eine Routing Engine oder optional für zwei Routing Engines. Je nach Anzahl der Routing Engines unterstützt die MX240 entweder zwei oder drei FPCs.
Hinweis
Die Routing Engine wird in einer SCB installiert und wird später in diesem Kapitel genauer beschrieben.
Abbildung 1-16. Juniper MX240
Um volle Redundanz zu unterstützen, benötigt der MX240 zwei SCBs und Routing Engines. Wenn eine einzelne SCB fehlschlägt, verfügt die andere SCB über genügend Switch-Fabric-Kapazität, um den gesamten Router mit Leitungsgeschwindigkeit zu unterstützen. Dies wird als 1 + 1 SCB-Redundanz bezeichnet. In dieser Konfiguration werden nur zwei FPCs unterstützt.
Wenn keine Redundanz erforderlich ist, kann der MX240 auch so konfiguriert werden, dass er eine einzige SCB und Routing Engine verwendet. Diese Konfiguration ermöglicht drei statt zwei FPCs.
Nummerierung der Schnittstelle
Der MX240 ist von unten nach oben nummeriert, beginnend mit der SCB. Die erste SCB muss in den untersten Steckplatz eingebaut werden. Der nächsthöhere Steckplatz ist ein spezieller Steckplatz, der entweder eine SCB oder eine FPC unterstützt und daher mit der FPC-Nummerierung bei 0 beginnt. Von dort aus kannst du zwei weitere FPCs als FPC1 und FPC2 installieren.
Volle Redundanz
Die SCBs müssen in den untersten Steckplätzen installiert werden, um die 1 + 1 SCB-Redundanz zu unterstützen (siehe Abbildung 1-17). Diese Steckplätze werden als SCB0 und SCB1 bezeichnet. Wenn zwei SCBs installiert sind, unterstützt die MX240 nur zwei FPCs: FPC1 und FPC2.
Abbildung 1-17. Juniper MX240 Schnittstellennummerierung mit SCB-Redundanz
Keine Redundanz
Wenn eine einzelne SCB verwendet wird, muss sie im untersten Steckplatz installiert werden und bietet natürlich keine Redundanz; allerdings werden drei FPCs unterstützt. In dieser Konfiguration beginnt die Nummerierung der FPCs bei FPC0 und endet bei FPC2, wie in Abbildung 1-18 dargestellt.
Abbildung 1-18. Juniper MX240-Schnittstellennummerierung ohne SCB-Redundanz
MX480
Der MX480 ist der große Bruder des MX240. Er verfügt über insgesamt acht horizontale Steckplätze. Er unterstützt zwei SCBs und Routing Engines sowie sechs FPCs auf nur 8 HE. Die MX480 ist in der Regel die beliebteste MX-Serie in Unternehmen, da sechs Steckplätze der "Sweet Spot" für die Anzahl der Steckplätze sind (siehe Abbildung 1-19).
Abbildung 1-19. Juniper MX480
Wie sein kleiner Bruder benötigt auch der MX480 zwei SCBs und Routing Engines für volle Redundanz. Sollte eine einzelne SCB fehlschlagen, kann die andere SCB alle sechs FPCs mit Leitungsgeschwindigkeit unterstützen.
Alle Komponenten zwischen dem MX240 und dem MX480 sind austauschbar. Das macht die Sparing-Strategie kosteneffizient und bietet FPC Investitionsschutz.
Hinweis
Die SCB- und FPC-Steckplätze sind mit einem speziellen Schlüssel versehen, sodass eine SCB nicht in einen FPC-Steckplatz eingebaut werden kann und umgekehrt. Wenn das Gehäuse entweder eine SCB oder einen FPC im selben Steckplatz unterstützt, wie z. B. beim MX240 oder MX960, können beide Steckplätze genutzt werden.
Die MX480 unterscheidet sich ein wenig von der MX240 und der MX960, da sie zwei eigene SCB-Steckplätze hat, die nicht mit FPCs geteilt werden können.
Nummerierung der Schnittstelle
Der MX480 ist von unten nach oben nummeriert (siehe Abbildung 1-20). Die SCBs werden ganz unten im Gehäuse in SCB0 und SCB1 eingebaut. Von dort aus können die FPCs eingebaut werden, die ebenfalls von unten nach oben nummeriert sind.
Abbildung 1-20. Juniper MX480 Schnittstellennummerierung mit SCB-Redundanz
MX960
Manche Arten von Verkehr erfordern einen großen Hammer. Der MX960, der Vorschlaghammer der MX-Serie, erfüllt dieses Bedürfnis. Beim MX960 geht es vor allem um Größe und Leistung. Er ist 16U groß und wiegt 334 lbs. Die SCBs und FPCs sind vertikal in das Gehäuse eingebaut, so dass es 14 Steckplätze nebeneinander aufnehmen kann.
Abbildung 1-21. Juniper MX960
Aufgrund des großen Umfangs sind drei SCBs für eine vollständige Redundanz erforderlich. Dies wird als 2 + 1 SCB-Redundanz bezeichnet. Wenn eine der SCBs fehlschlägt, können die beiden anderen SCBs alle 11 FPCs mit Leitungsgeschwindigkeit unterstützen.
Wenn du gerne auf der Kante lebst und keine Redundanz brauchst, benötigt der MX960 mindestens zwei SCBs, um die verfügbaren 12 FPCs zu schalten.
Hinweis
Das MX960 benötigt spezielle Netzteile, die nicht mit dem MX240 oder MX480 austauschbar sind.
Nummerierung der Schnittstelle
Der MX960 ist von links nach rechts nummeriert. Die SCBs werden in der Mitte installiert, während die FPCs auf beiden Seiten installiert werden. Je nachdem, ob du eine SCB-Redundanz benötigst oder nicht, kann der MX960 11 oder 12 FPCs unterstützen.
Volle Redundanz
Die ersten sechs Steckplätze sind für FPCs reserviert und werden von links nach rechts nummeriert, beginnend mit 0 und endend mit 5, wie in Abbildung 1-22 dargestellt. Die nächsten beiden Steckplätze sind für SCBs reserviert und verschlüsselt. Der nächste Steckplatz ist entweder für eine SCB oder einen FPC reserviert. Im Falle einer vollständigen Redundanz muss SCB2 in diesen Steckplatz eingebaut werden. Die nächsten fünf Steckplätze sind für FPCs reserviert und beginnen mit der Nummerierung 7 und enden mit 11.
Abbildung 1-22. Juniper MX960-Schnittstellennummerierung mit voller 2 + 1 SCB-Redundanz
Keine Redundanz
Wenn du mit zwei SCBs arbeitest, hast du den Vorteil, dass du 12 FPCs mit Leitungsgeschwindigkeit umschalten kannst. Der einzige Nachteil ist, dass es keine SCB-Redundanz gibt. Wie zuvor sind die ersten sechs Steckplätze für FPC0 bis FPC5 reserviert. Der Unterschied besteht nun darin, dass SCB0 und SCB1 in die nächsten beiden Steckplätze eingebaut werden müssen. Anstelle von SCB2 installierst du FPC6 in diesen Steckplatz. Die restlichen fünf Steckplätze sind für FPC7 bis FPC11 reserviert.
Abbildung 1-23. Juniper MX960-Schnittstellennummerierung ohne SCB-Redundanz
MX2010 und MX2020
Die MX2K-Familie (MX2010 und MX2020) ist eine Router-Familie der MX-Serie, die für die 10G- und 100G-Anforderungen von Content Service Providern (CSP), Multisystem-Operatoren (MSO) und traditionellen Service Providern mit hoher Portdichte entwickelt wurde. Auf einen Blick: Der MX2010 unterstützt zehn Line Cards, acht Switch Fabric Boards und zwei Routing Engines, sein großer Bruder MX2020 unterstützt zwanzig Line Cards, acht Switch Fabric Boards und ebenfalls zwei Routing Engines.
Das Gehäuse belegt 34RU für MX2010 und 45RU für MX2020 und hat eine Front-to-Back-Kühlung.
MX2020 Architektur
Die MX2020 ist ein standardmäßiges Backplane-basiertes System, wenn auch in großem Maßstab. Es gibt zwei Backplanes, die über zentrale Switch Fabric Boards (SFB) miteinander verbunden sind. Die Routing Engine und die Steuerplatine sind eine einzige Einheit, die einen einzigen Steckplatz beansprucht, wie in Abbildung 1-24 ganz links und rechts dargestellt.
Abbildung 1-24. Illustration der MX2020 Architektur
Die Nummerierung der FPCs entspricht der Standardmethode von Juniper: Du beginnst unten und arbeitest dich von links nach rechts nach oben vor. Die SFBs sind ähnlich benannt, wobei die Null links beginnt und bis zur Sieben ganz rechts reicht. Die Routing Engine und die Steuerplatinen befinden sich in der Mitte des Gehäuses, ganz links und ganz rechts.
Switch Fabric Board
Jede Backplane hat 10 Steckplätze, die in acht SFBs in der Mitte des Gehäuses zusammengefasst sind. Aufgrund der hohen Anzahl von Linecards und PFEs, die die Switch Fabric unterstützen muss, wurde speziell für den MX2020 ein neuer SFB entwickelt. Die SFB kann mehr PFEs unterstützen und hat im Vergleich zu den vorherigen SCBs einen viel höheren Durchsatz. Die SCB und SCBE stellen ihre Chipsätze gegenüber Junos als Fabric Plane dar und können mit dem Befehl show chassis fabric summary angezeigt werden - die neue SFB hat ebenfalls mehrere Chipsätze, aber sie stellt sie gegenüber Junos als aggregierte Fabric Plane dar. Mit anderen Worten: Jeder SFB wird in Junos als eine einzige Fabric Plane angezeigt. Jeder SFB befindet sich standardmäßig im aktiven Zustand. Schauen wir uns zunächst die installierten SFBs an:
dhanks@MX2020> show chassis hardware | match SFB SFB 0 REV 01 711-032385 ZE5866 Switch Fabric Board SFB 1 REV 01 711-032385 ZE5853 Switch Fabric Board SFB 2 REV 01 711-032385 ZB7642 Switch Fabric Board SFB 3 REV 01 711-032385 ZJ3555 Switch Fabric Board SFB 4 REV 01 711-032385 ZE5850 Switch Fabric Board SFB 5 REV 01 711-032385 ZE5870 Switch Fabric Board SFB 6 REV 04 711-032385 ZV4182 Switch Fabric Board SFB 7 REV 01 711-032385 ZE5858 Switch Fabric Board
Es sind acht SFBs installiert; werfen wir nun einen Blick auf den Status der Switch Fabric:
dhanks@MX2020> show chassis fabric summary Plane State Uptime 0 Online 1 hour, 25 minutes, 59 seconds 1 Online 1 hour, 25 minutes, 59 seconds 2 Online 1 hour, 25 minutes, 59 seconds 3 Online 1 hour, 25 minutes, 59 seconds 4 Online 1 hour, 25 minutes, 59 seconds 5 Online 1 hour, 25 minutes, 59 seconds 6 Online 1 hour, 25 minutes, 59 seconds 7 Online 1 hour, 25 minutes, 59 seconds
Je nachdem, welche Linecards verwendet werden, muss nur eine Teilmenge der acht SFBs vorhanden sein, um eine Line-Rate-Switch-Fabric bereitzustellen, aber das kann sich mit den Linecards ändern.
Energieversorgung
Die Stromversorgung der MX2020 unterscheidet sich ein wenig von den vorherigen MX-Modellen, wie in Abbildung 1-25 dargestellt. Das Stromversorgungssystem der MX2020 ist in zwei Bereiche unterteilt: oben und unten. Die unteren Netzteile versorgen die unteren Backplane Line Cards, die unteren Lüftereinschübe, die SFBs und die CB-REs mit Strom. Die oberen Netzteile versorgen die oberen Backplane-Linecards und Lüftereinschübe mit Strom. Die MX2020 bietet N + 1 Redundanz bei den Netzteilen und N + N Redundanz bei den Einspeisungen. Es gibt zwei Hauptstromversorgungskomponenten, die den MX2K mit Strom versorgen:
- Stromversorgungsmodul
Die Stromversorgungsmodule (PSMs) sind die eigentlichen Netzteile, die eine bestimmte Backplane mit Strom versorgen. Es gibt neun PSMs pro Backplane, aber nur acht werden benötigt, um die Backplane vollständig mit Strom zu versorgen. Jede Backplane verfügt über 8 + 1 PSM-Redundanz.
- Stromverteilungsmodul
Es gibt zwei Power Distribution Modules (PDM) pro Backplane, die für 1 + 1 PDM-Redundanz für jede Backplane sorgen. Jedes PDM enthält neun PSMs, so dass für jede Backplane eine Redundanz von 8 + 1 PSM gegeben ist.
Abbildung 1-25. Illustration der MX2020-Stromversorgungsarchitektur
Luftstrom
In den meisten Rechenzentren gibt es heiße und kalte Gänge, die Geräte mit Front-to-Back-Kühlung erfordern, um den Luftstrom zu nutzen. Die MX2020 unterstützt die Front-to-Back-Kühlung, und zwar in zwei Teilen, wie in Abbildung 1-26 dargestellt. Der untere Einlassplenum liefert kühle Luft von der Vorderseite des Gehäuses und die unteren Lüftereinschübe drücken die kühle Luft durch die unteren Karten; die Luft wird dann durch einen diagonalen Luftstromteiler im mittleren Kartenkäfig aus der Rückseite des Gehäuses geleitet. Das gleiche Prinzip gilt für den oberen Bereich. Der mittlere Einlassplenum liefert kühle Luft von der Vorderseite des Gehäuses und die oberen Lüftereinschübe drücken die kühle Luft durch den oberen Kartenkäfig; die Luft wird dann an der Rückseite des Gehäuses herausgeleitet.
Abbildung 1-26. Illustration des MX2020 Luftstroms von vorne nach hinten
Kompatibilität mit Linecards
Die MX2020 ist mit allen Trio-basierten MPC-Linecards kompatibel; es gibt jedoch keine Abwärtskompatibilität mit den DPC-Linecards der ersten Generation. Für die Linecards MPC1E, MPC2E, MPC3E, MPC4E, MPC5E und MPC7E ist ein spezieller MX2020 Line Card Adapter erforderlich. Die MX2020 kann bis zu 20 Adapterkarten (ADC) unterstützen, um 20 MPC1E bis MPC7E Linecards aufzunehmen. Da die MX2020 eine neuere Generation der SFB mit höherer Bandbreite verwendet, müssen Linecards, die für die SCB und SCBE entwickelt wurden, den ADC in der MX2020 verwenden.
Der ADC ist lediglich ein Gehäuse, das die Linecards MPC1E bis MPC7E auf der Vorderseite aufnimmt und die Stromversorgung und den Switch Fabric auf der Rückseite umsetzt. Zukünftige Linecards, die speziell für die MX2020 gebaut werden, benötigen den ADC nicht. Schauen wir uns den ADC-Status mit dem Befehl show chassis adc an:
dhanks@MX2020> show chassis adc Slot State Uptime 3 Online 6 hours, 2 minutes, 52 seconds 4 Online 6 hours, 2 minutes, 46 seconds 8 Online 6 hours, 2 minutes, 39 seconds 9 Online 6 hours, 2 minutes, 32 seconds 11 Online 6 hours, 2 minutes, 26 seconds 16 Online 6 hours, 2 minutes, 19 seconds 17 Online 6 hours, 2 minutes, 12 seconds 18 Online 6 hours, 2 minutes, 5 seconds
In diesem Beispiel gibt es acht ADC-Karten im MX2020. Schauen wir uns FPC3 genauer an und sehen wir, welche Art von Linecard installiert ist:
dhanks@MX2020> show chassis hardware | find "FPC 3"
FPC 3 REV 22 750-028467 YE2679 MPC 3D 16x 10GE
CPU REV 09 711-029089 YE2832 AMPC PMB
PIC 0 BUILTIN BUILTIN 4x 10GE(LAN) SFP+
Xcvr 0 REV 01 740-031980 B10M00015 SFP+-10G-SR
Xcvr 1 REV 01 740-021308 19T511101037 SFP+-10G-SR
Xcvr 2 REV 01 740-031980 AHK01AS SFP+-10G-SR
PIC 1 BUILTIN BUILTIN 4x 10GE(LAN) SFP+
PIC 2 BUILTIN BUILTIN 4x 10GE(LAN) SFP+
Xcvr 0 REV 01 740-021308 19T511100867 SFP+-10G-SR
PIC 3 BUILTIN BUILTIN 4x 10GE(LAN) SFP+
Die MPC-3D-16X10GE-SFPP wird in FPC3 installiert, indem der ADC aus Kompatibilitätsgründen verwendet wird. Überprüfen wir den Umgebungsstatus des in der FPC3 installierten ADC:
dhanks@MX2020> show chassis environment adc | find "ADC 3" ADC 3 status: State Online Intake Temperature 34 degrees C / 93 degrees F Exhaust Temperature 46 degrees C / 114 degrees F ADC-XF1 Temperature 51 degrees C / 123 degrees F ADC-XF0 Temperature 61 degrees C / 141 degrees F
Jeder ADC hat zwei Chipsätze, wie in der Beispielausgabe gezeigt: ADC-XF1 und ADC-XF2. Diese Chipsätze setzen die Switch Fabric zwischen dem MX2020 SFB und den MPC1E bis MPC7E Linecards um.
Abgesehen von dem einfachen ADC-Träger zur Stromumwandlung und dem Switch Fabric funktioniert die MPC-3D-16X10GE-SFPP Line Card, die in FPC3 installiert ist, wie eine normale Line Card ohne Einschränkungen. Überprüfe zur Sicherheit noch einmal die Namen der Schnittstellen:
dhanks@MX2020> show interfaces terse | match xe-3 Interface Admin Link Proto Local Remote xe-3/0/0 up down xe-3/0/1 up down xe-3/0/2 up down xe-3/0/3 up down xe-3/1/0 up down xe-3/1/1 up down xe-3/1/2 up down xe-3/1/3 up down xe-3/2/0 up down xe-3/2/1 up down xe-3/2/2 up down xe-3/2/3 up down xe-3/3/0 up down xe-3/3/1 up down xe-3/3/2 up down xe-3/3/3 up down
Wie erwartet hat die MPC-3D-16X10GE-SFPP Linecard 16 Ports mit 10GE-Schnittstellen, die in vier PICs mit je vier Schnittstellen gruppiert sind.
Die MPC6e ist die erste MX2K-MPC, die keine ADC-Karte benötigt. Der MPC6e ist ein modularer MPC, der zwei High-Density-MICs aufnehmen kann. Jeder MIC-Steckplatz verfügt über eine 240Gbps Vollduplex-Bandbreite Kapazität.
Trio
Juniper Networks ist stolz darauf, maßgeschneidertes Silizium zu entwickeln und mit Silizium-Erstlingswerken Geschichte zu schreiben. Trio ist der neueste Meilenstein:
1998: Erste Trennung von Kontroll- und Datenebene
1998: Erste Implementierung von IPv4, IPv6 und MPLS in Silizium
2000: Erste Line-Rate 10 Gbps Forwarding Engine
2004: Erster Multi-Chassis-Router
2005: Erste 40-Gbit/s-Weiterleitungs-Engine mit Leitungsgeschwindigkeit
2007: Erste 160-Gbit/s-Firewall
2009: Silizium der nächsten Generation: Trio
2010: Erste 130 Gbps PFE; nächste Generation Trio
2013: Neue Generation des Lookup-ASICs; XL-Chip-Upgrades auf den PFE 260Gbps
2015: Erster "all-in-one" 480Gbps PFE ASIC: EAGLE (3. Generation von Trio)
Trio ist ein grundlegender technologischer Vorteil für Juniper, der drei Hauptkomponenten kombiniert: Skalierung der Bandbreite, Skalierung der Dienste und Skalierung der Teilnehmer (siehe Abbildung 1-27). Trio wurde von Grund auf für die Unterstützung von 10G- und 100G-Ports mit hoher Dichte und Leitungsrate entwickelt. Inline-Dienste wie IPFIX, NAT, GRE und BFD bieten ein höheres Maß an Erlebnisqualität, ohne dass eine zusätzliche Dienstkarte erforderlich ist. Trio bietet eine enorme Teilnehmerskala in Bezug auf logische Schnittstellen, IPv4- und IPv6-Routen und hierarchische Warteschlangen.
Abbildung 1-27. Juniper Trio Skala: Dienste, Bandbreite und Abonnenten
Trio basiert auf einem Network Instruction Set Processor (NISP). Das Hauptunterscheidungsmerkmal ist, dass Trio die Leistung eines traditionellen ASICs hat, aber die Flexibilität eines FPGAs (Field-Programmable Gate Array), indem es die Installation neuer Funktionen per Software ermöglicht. Hier ist nur ein Beispiel für die Inline-Dienste, die mit dem Trio-Chipsatz verfügbar sind:
Tunnelkapselung und -entkapselung
IP Flow Information Export
Netzwerkadressübersetzung
Erkennung von bidirektionaler Weiterleitung
Ethernet-Betrieb, -Verwaltung und -Management
Sofortige Konvergenz der Link Aggregation Group
Trio Architektur
Wie in Abbildung 1-28 dargestellt, besteht der Trio-Chipsatz aus vier Hauptbausteinen: Buffering, Lookup, Interfaces und Dense Queuing. Je nach Generation des Trio-Chipsatzes können diese Blöcke in mehrere Hardwarekomponenten aufgeteilt oder in einem Chipsatz zusammengefasst sein (dies ist bei der neuesten Generation der Trio-Chipsätze sowie bei zukünftigen Versionen der Fall).
Abbildung 1-28. Trio Funktionsblöcke: Pufferung, Lookup, Schnittstellen und Dense Queuing
Jede Funktion ist in einen eigenen Block unterteilt, so dass jede Funktion hochgradig optimiert und kosteneffizient ist. Je nach Größe und Umfang kann Trio aus diesen Bausteinen Linecards erstellen, die Spezialisierungen wie hierarchische Warteschlangen oder intelligente Überzeichnung bieten.
Trio Generationen
Der Trio-Chipsatz hat sich in Bezug auf Skalierung und Funktionen, aber auch in Bezug auf die Anzahl der ASICs weiterentwickelt (siehe Abbildung 1-29):
Die erste Generation von Trio wurde mit vier spezifischen ASICs geboren: IX (Schnittstellenmanagement für überlastete MIC), MQ (Buffering/Queuing Block), LU (Lookup Block) und QX (Dense Queuing Block). Diese erste Generation von Trio ist in MPC1, 2 und den 16x10GE MPCs zu finden.
Die Zwischengeneration, die sogenannte 1.5 Generation, aktualisierte und erhöhte die Kapazität des Puffer-ASICs mit der neuen Generation von XM-Chipsätzen. Dies war auch der Startschuss für die Multi-LU-MPCs wie MPC3e und MPC4e.
Die aktuelle zweite Generation von Trio verbesserte die Lookup- und Dense Queuing-Blöcke: Der LU-Chip wurde zum XL-Chip und der QX-Chip wurde zum XQ-Chip. Mit dieser zweiten Generation von Trio werden die MPC5e, MPC6e und die Linecards NG-MPC2e und NG-MPC3e ausgestattet.
Die dritte Generation von Trio ist eine Revolution. Sie vereint alle Funktionsblöcke in einem ASIC. Der Eagle-ASIC, auch bekannt als EA-Chipsatz, ist die erste 480Gbits/s-Option auf dem Markt und stattet die neuen MPC7e, MPC8e und MPC9e aus.
Abbildung 1-29. Trio-Chipsatz-Generationen
Pufferblock
Der Buffering Block ist Teil der MQ-, XM- und EA-ASICs und verbindet alle anderen funktionalen Trio-Blöcke miteinander. Er verwaltet in erster Linie Paketdaten, Fabric Queuing und Revenue Port Queuing. Das Interessante am Buffering Block ist, dass es möglich ist, Aufgaben an andere funktionale Trio-Blöcke zu delegieren. Zum Zeitpunkt der Erstellung dieses Buches gibt es zwei Hauptanwendungsfälle für die Delegierung von Zuständigkeiten: Prozessüberzeichnung und Revenue Port Queuing.
Wenn die Anzahl der Revenue Ports an einem MIC weniger als 24x1GE oder 2x10GE beträgt, ist es möglich, die Handhabung der Überzeichnung in den Interfaces Block zu verlagern. Dies ermöglicht es, Linecards mit Überbelegung zu einem attraktiven Preis zu entwickeln, die die Überbelegung intelligent handhaben, indem sie die Verarbeitung von Kontroll- und Sprachdaten bei Überlastung ermöglichen.
Der Buffering Block ist in der Lage, grundlegende Warteschlangen pro Port zu verarbeiten. Jeder Port verfügt standardmäßig über acht Hardware-Warteschlangen, große Verzögerungspuffer und Warteschlangen mit niedriger Latenz (LLQs). Wenn hierarchische Serviceklassen (H-QoS) und zusätzliche Skalierung erforderlich sind, können diese Funktionen an den Dense Queuing Block delegiert werden.
Nachschlagewerk
Der Lookup Block ist Teil der LU-, XL- und EA-ASICs. Der Lookup Block hat Multicore-Prozessoren, die parallele Aufgaben mit mehreren Threads unterstützen. Das ist das A und O von Trio. Der Lookup Block unterstützt auch die gesamte Verarbeitung der Paketköpfe, einschließlich:
Routenabfragen
Lastausgleich
MAC Nachforschungen
Klassifizierung der Dienstklasse (QoS)
Firewall-Filter
Polizisten
Buchhaltung
Verkapselung
Statistik
Periodisches Inline-Paketmanagement (z. B. Inline-BFD)
Eine wichtige Funktion des Lookup Blocks ist, dass er Deep Packet Inspection (DPI) unterstützt und in der Lage ist, über 256 Bytes in das Paket zu schauen. Dies ermöglicht interessante Funktionen wie den Schutz vor Distributed Denial-of-Service (DDoS), der in Kapitel 4 behandelt wird.
Wenn die Pakete vom Pufferungsblock empfangen werden, werden die Paketköpfe zur weiteren Verarbeitung an den Lookup-Block gesendet. Dieses Paket wird Parcel genannt. Die gesamte Verarbeitung wird in einem Durchgang durch den Lookup Block abgeschlossen, unabhängig von der Komplexität des Workflows. Sobald der Lookup Block die Verarbeitung abgeschlossen hat, sendet er die geänderten Paketköpfe zurück an den Buffering Block, um das Paket an sein endgültiges Ziel zu senden.
Um Daten mit Leitungsgeschwindigkeit zu verarbeiten, verfügt der Lookup-Block über einen großen Eimer mit dynamischem Direktzugriffsspeicher mit reduzierter Latenz (RLDRAM), der für die Paketverarbeitung unerlässlich ist.
Werfen wir einen kurzen Blick auf die aktuelle Arbeitsspeicherauslastung im Lookup Block:
{master}
dhanks@R1-RE0> request pfe execute target fpc2 command "show jnh 0 pool usage"
SENT: Ukern command: show jnh 0 pool usage
GOT:
GOT: EDMEM overall usage:
GOT: [NH///|FW///|CNTR//////|HASH//////|ENCAPS////|--------------]
GOT: 0 2.0 4.0 9.0 16.8 20.9 32.0M
GOT:
GOT: Next Hop
GOT: [*************|-------] 2.0M (65% | 35%)
GOT:
GOT: Firewall
GOT: [|--------------------] 2.0M (1% | 99%)
GOT:
GOT: Counters
GOT: [|----------------------------------------] 5.0M (<1% | >99%)
GOT:
GOT: HASH
GOT: [*********************************************] 7.8M (100% | 0%)
GOT:
GOT: ENCAPS
GOT: [*****************************************] 4.1M (100% | 0%)
GOT:
LOCAL: End of file
Der externe Datenspeicher (EDMEM) ist für die Speicherung aller Firewall-Filter, Zähler, Next-Hops, Verkapselungen und Hash-Daten zuständig. Diese Werte sehen vielleicht klein aus, aber lass dich nicht täuschen. In unserem Labor haben wir eine MPLS-Topologie mit über 2.000 L3VPNs einschließlich BGP-Routenreflexion. Innerhalb jeder VRF gibt es einen Firewall-Filter mit zwei Begriffen. Wie du sehen kannst, wird der Speicher der Firewall kaum genutzt. Diese Speicherzuweisungen sind nicht statisch und werden nach Bedarf zugewiesen. Es gibt einen großen Pool an Speicher und jedes EDMEM-Attribut kann nach Bedarf wachsen.
Hypermode-Funktion
Mit Junos 13.x führte Juniper ein Konzept namens Hypermode ein. Die MX-Linecards verfügen über eine Vielzahl von Funktionen - von grundlegenden Routing- und Warteschlangenfunktionen bis hin zu erweiterten BNG-Inline-Funktionen. Der Lookup-Chipsatz (LU/XL-Block) ist mit dem vollständigen Mikrocode geladen, der alle Funktionen unterstützt, von den grundlegenden bis zu den komplexen. Jede Funktion wird als Funktionsblock betrachtet und je nach den konfigurierten Merkmalen werden einige dieser Blöcke bei der Paketverarbeitung verwendet. Auch wenn nicht alle Blöcke zu einem bestimmten Zeitpunkt verwendet werden, gibt es zwischen ihnen einige Abhängigkeiten. Diese Abhängigkeiten erfordern mehr CPU-Anweisungen und damit mehr Zeit, auch wenn das Paket nur weitergeleitet werden muss.
Warnung
Tatsächlich kannst du eine Auswirkung auf die Leistung nur dann sehen, wenn du die Leitungsratengrenze des ASICs für sehr kleine Pakete (etwa 64 Byte) erreichst.
Um diese Art von Engpass zu überwinden und die Leistung bei kleinen Paketgrößen zu verbessern, wurde das Konzept des Hypermodus entwickelt. Es deaktiviert einige Funktionsblöcke und lädt sie nicht in den Mikrocode der Lookup-Engine, wodurch die Anzahl der Mikrocode-Anweisungen, die pro Paket ausgeführt werden müssen, reduziert wird. Dieser Modus ist besonders interessant für Core-Router oder einen einfachen PE mit klassisch konfigurierten Funktionen wie Routing, Filterung und einfachen Warteschlangenmodellen. Wenn der Hypermodus konfiguriert ist, werden die folgenden Funktionen nicht mehr unterstützt:
Erstellung eines virtuellen Fahrgestells
Interoperabilität mit älteren DPCs, einschließlich MS-DPCs (der MPC im Hypermodus akzeptiert und sendet nur Datenpakete von anderen bestehenden MPCs)
Interoperabilität mit Nicht-Ethernet-MICs und Nicht-Ethernet-Schnittstellen wie Channelized-Schnittstellen, Multilink-Schnittstellen und SONET-Schnittstellen
Padding von Ethernet-Frames mit VLAN
Senden von Internet Control Message Protocol (ICMP)-Umleitungsnachrichten
Beendigung oder Tunnelung aller teilnehmerbezogenen Dienste
Der Hypermodus erhöht die Leitungsgeschwindigkeit für Weiterleitungs- und Filterzwecke erheblich, wie in Abbildung 1-30 dargestellt.
Abbildung 1-30. Vergleich der Leistung im regulären Modus und im Hypermodus
Um den Hypermodus zu konfigurieren, muss die folgende Anweisung zu den Forwarding-Optionen hinzugefügt werden:
{master}[edit]
jnpr@R1# set forwarding-options hyper-mode
Das Committen dieser neuen Konfiguration erfordert einen Neustart des Knotens:
jnpr@R1# commit re0: warning: forwarding-options hyper-mode configuration changed. A system reboot is mandatory. Please reboot the system NOW. Continuing without a reboot might result in unexpected system behavior. configuration check succeeds
Nach dem Neustart des Routers kannst du mit diesem show-Befehl überprüfen, ob der Hypermode aktiviert ist:
{master}
jnpr@R1> show forwarding-options hyper-mode
Current mode: hyper mode
Configured mode: hyper mode
Wird der Hypermodus von allen Linecards unterstützt? Eigentlich lautet die Antwort "nein", aber "nicht unterstützt" bedeutet nicht "nicht kompatibel". Vor MPC4e galt der Hypermodus nämlich als kompatibel, was bedeutet, dass MPC1, 2 und 3 sowie 16x10GE MPCs das Vorhandensein des Knopfes in der Konfiguration zwar akzeptieren, aber nicht berücksichtigen. Mit anderen Worten: Der Lookup-Chipsatz dieser Karten ist mit allen Funktionen voll ausgelastet. Seit MPC4e wird der Hypermodus unterstützt und kann eingeschaltet werden, um kleineren Mikrocode mit besserer Leistung für Weiterleitungs- und Filterfunktionen auf LU/XL/EA ASICs zu laden. Tabelle 1-4 fasst zusammen, welche MPCs kompatibel sind und welche die Hypermode-Funktion unterstützen.
| Line Card Modell | Hypermode kompatibel? | Hypermode-Unterstützung? |
|---|---|---|
| DPC / MS-DPC | Nein | Nein |
| MPC1 / MPC1e | Ja | Nein |
| MPC2 / MPC2e | Ja | Nein |
| MPC3e | Ja | Nein |
| MPC4e | Ja | Ja |
| MPC5e | Ja | Ja |
| MPC6e | Ja | Ja |
| NG-MPC2e / NG-MPC3e | Ja | Ja |
Schnittstellen-Block
Eine der optionalen Komponenten ist der Interfaces Block (der Buffering Block ist Teil des IX-spezifischen ASIC). Seine Hauptaufgabe ist der intelligente Umgang mit Überzeichnung. Wenn du ein MIC verwendest, das weniger als 24x1GE oder 2x10GE MACs unterstützt, wird der Interfaces Block verwendet, um die Überzeichnung zu verwalten.
Hinweis
Wenn neue MICs auf den Markt kommen, kann es sein, dass sie je nach Leistungsbedarf und anderen Faktoren einen Interfaces Block haben oder nicht. Erinnere dich daran, dass die Trio-Funktionsblöcke wie Bausteine sind und einige Blöcke für den Betrieb nicht erforderlich sind.
Jedes Paket wird mit Leitungsgeschwindigkeit geprüft, und Attribute wie Ethernet Type Codes, Protokoll und andere Layer 4-Informationen werden verwendet, um zu bewerten, welche Puffer das Paket in den Buffering Block einreihen sollen. Die Vorklassifizierung ermöglicht es, überflüssige Pakete so nah wie möglich an der Quelle zu verwerfen, während kritische Pakete der Steuerungsebene zum Buffering Block durchgelassen werden.
Es gibt vier Warteschlangen zwischen den Schnittstellen und dem Buffering Block: Echtzeit, Kontrollverkehr, Best Effort und Packet Drop. Derzeit sind diese Warteschlangen und Vorklassifizierungen nicht konfigurierbar, aber es ist möglich, einen Blick auf sie zu werfen.
Schauen wir uns einen Router mit einem 20x1GE MIC an, der einen Interfaces Block hat:
dhanks@MX960> show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis JN10852F2AFA MX960 Midplane REV 02 710-013698 TR0019 MX960 Backplane FPM Board REV 02 710-014974 JY4626 Front Panel Display Routing Engine 0 REV 05 740-031116 9009066101 RE-S-1800x4 Routing Engine 1 REV 05 740-031116 9009066210 RE-S-1800x4 CB 0 REV 10 750-031391 ZB9999 Enhanced MX SCB CB 1 REV 10 750-031391 ZC0007 Enhanced MX SCB CB 2 REV 10 750-031391 ZC0001 Enhanced MX SCB FPC 1 REV 28 750-031090 YL1836 MPC Type 2 3D EQ CPU REV 06 711-030884 YL1418 MPC PMB 2G MIC 0 REV 05 750-028392 JG8529 3D 20x 1GE(LAN) SFP MIC 1 REV 05 750-028392 JG8524 3D 20x 1GE(LAN) SFP
Wir können sehen, dass FPC1 zwei 20x1GE MICs unterstützt. Werfen wir einen Blick auf die Vorklassifizierung von FPC1:
dhanks@MX960> request pfe execute target fpc1 command "show precl-eng summary" SENT: Ukern command: show precl-eng summary GOT: GOT: ID precl_eng name FPC PIC (ptr) GOT: --- -------------------- ---- --- -------- GOT: 1 IX_engine.1.0.20 1 0 442484d8 GOT: 2 IX_engine.1.1.22 1 1 44248378 LOCAL: End of file
Es ist interessant zu sehen, dass es zwei Vorklassifizierungs-Engines gibt. Das macht Sinn, da es pro MIC einen Schnittstellenblock gibt. Schauen wir uns nun die Vorklassifizierungs-Engine und die Statistik des ersten MIC genauer an:
usr@MX960> request pfe execute target fpc1 command "show precl-eng 1 statistics" SENT: Ukern command: show precl-eng 1 statistics GOT: GOT: stream Traffic GOT: port ID Class TX pkts RX pkts Dropped pkts GOT: ------ ------- ---------- --------- ------------ ------------ GOT: 00 1025 RT 000000000000 000000000000 000000000000 GOT: 00 1026 CTRL 000000000000 000000000000 000000000000 GOT: 00 1027 BE 000000000000 000000000000 000000000000
Jeder physische Port wird aufgeschlüsselt und nach Verkehrsklasse gruppiert. Die Anzahl der verworfenen Pakete wird in einem Zähler in der letzten Spalte festgehalten. Dies ist immer ein guter Ort, um zu sehen, ob der Router überlastet ist und Pakete verwirft.
Werfen wir einen Blick auf einen Router mit einem 4x10GE MIC, der keinen Interfaces Block hat:
{master}
dhanks@R1-RE0> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis JN111992BAFC MX240
Midplane REV 07 760-021404 TR5026 MX240 Backplane
FPM Board REV 03 760-021392 KE2411 Front Panel Display
Routing Engine 0 REV 07 740-013063 1000745244 RE-S-2000
Routing Engine 1 REV 06 740-013063 1000687971 RE-S-2000
CB 0 REV 03 710-021523 KH6172 MX SCB
CB 1 REV 10 710-021523 ABBM2781 MX SCB
FPC 2 REV 25 750-031090 YC5524 MPC Type 2 3D EQ
CPU REV 06 711-030884 YC5325 MPC PMB 2G
MIC 0 REV 24 750-028387 YH1230 3D 4x 10GE XFP
MIC 1 REV 24 750-028387 YG3527 3D 4x 10GE XFP
Hier können wir sehen, dass FPC2 zwei 4x10GE MICs hat. Werfen wir einen genaueren Blick auf die Preclassification Engines:
{master}
dhanks@R1-RE0> request pfe execute target fpc2 command "show precl-eng summary"
SENT: Ukern command: show precl-eng summary
GOT:
GOT: ID precl_eng name FPC PIC (ptr)
GOT: --- -------------------- ---- --- --------
GOT: 1 MQ_engine.2.0.16 2 0 435e2318
GOT: 2 MQ_engine.2.1.17 2 1 435e21b8
LOCAL: End of file
Der große Unterschied ist der Name der Preclassification Engine. Zuvor wurde sie bei MICs, die einen Interfaces Block unterstützen, als "IX_engine" aufgeführt. MICs wie die 4x10GE haben keinen Interfaces Block, daher wird die Vorklassifizierung im Buffering Block durchgeführt, oder, wie hier aufgeführt, in der "MQ_engine".
Hinweis
Die versteckten Befehle werden hier verwendet, um die Aufgaben und Verantwortlichkeiten des Schnittstellenblocks zu veranschaulichen. Bei der Verwendung dieser Befehle ist Vorsicht geboten, da sie von Juniper nicht unterstützt werden.
Die WAN-Schnittstelle des Buffering Blocks kann entweder im MAC-Modus oder im Universal Packet over HSL2 (UPOH)-Modus betrieben werden. Dadurch unterscheiden sich die MPC1- und MPC2-Linecards im Betrieb. Die MPC1 verfügt nur über einen einzigen Trio-Chipsatz, so dass die MPC2 nur mit MICs kompatibel ist, die im MAC-Modus arbeiten können. Die MPC2 hingegen hat zwei Trio-Chipsätze. Jedes MIC auf der MPC2 kann in beiden Modi betrieben werden und ist daher mit mehreren MICs kompatibel. Dies wird später in diesem Kapitel genauer erklärt.
Dense Queuing Block
Der Buffering Block ist Teil der QX, XQ und EA ASICs. Je nach Line Card bietet Trio einen optionalen Dense Queuing Block, der eine umfangreiche hierarchische QoS bietet, die mit der aktuellen Hardware-Generation bis zu 512.000 Warteschlangen unterstützt. Dies ermöglicht die Erstellung von Zeitplannungsprogrammen, die Drop-Charakteristika, Übertragungsraten und Pufferung definieren, die separat gesteuert und auf mehreren Hierarchieebenen angewendet werden können.
Der Dense Queuing Block ist ein optionaler funktionaler Trio-Block. Der Buffering Block unterstützt bereits grundlegende Warteschlangen pro Port. Der Dense Queuing Block wird nur in Linecards verwendet, die H-QoS oder zusätzliche Skalierung über den Buffering Block hinaus benötigen.
Line Cards und Module
Um High-Density- und High-Speed-Ethernet-Dienste anbieten zu können, musste ein neuer Typ von Flexible Port Concentrator (FPC) entwickelt werden, der Dense Port Concentrator (DPC). Diese Linecard der ersten Generation ermöglichte bis zu 80 Gbit/s pro Steckplatz.
Die DPC-Linecards nutzen einen früheren ASIC aus der M-Serie, den sogenannten I-Chip. So konnte Juniper schnell die ersten MX-Linecards und Software entwickeln.
Der Modular Port Concentrator (MPC) ist die zweite Generation von Linecards, die die Portdichte auf 160 Gbit/s pro Steckplatz erhöht. Diese Hardware-Generation wurde mit dem Trio-Chipsatz entwickelt. Der MPC unterstützt MICs, die es dir ermöglichen, verschiedene Module auf demselben MPC zu kombinieren.
| FPC Typ/Modul Typ | Beschreibung |
|---|---|
| Dense Port Concentrator (DPC) | High-Density- und High-Speed-Ethernet-Karten der ersten Generation |
| Modular Port Concentrator (MPC) | High-Density- und High-Speed-Ethernet-Linecards der zweiten Generation, die Module unterstützen |
| Modul-Schnittstellenkarte (MIC) | Ethernet- und optische Module der zweiten Generation, die in MPCs eingesetzt werden |
Es ist ein weit verbreiteter Irrglaube, dass der "modulare" Teil von MPC seinen Namen nur daher hat, dass er verschiedene Arten von MICs aufnehmen kann. Das ist aber nur die Hälfte der Geschichte. Der MPC verdankt seinen Namen auch der Flexibilität des Trio-Chipsatzes. Die MPC-3D-16x10GE-SFPP Line Card ist zum Beispiel eine feste Port-Konfiguration, verwendet aber nur den Buffering Block und den Lookup Block im PFE-Komplex. Wenn in Zukunft neue Linecards auf den Markt kommen, wird auch die Anzahl der grundlegenden Trio-Bausteine pro Karte variieren und damit dem Namen "modular" gerecht werden.
Dense Port Concentrator
Die DPC-Linecards gibt es in sechs verschiedenen Modellen, die unterschiedliche Port-Konfigurationen unterstützen. Es gibt eine Mischung aus 1G, 10G, Kupfer und optisch. Es gibt drei DPC-Typen: Routing und Switching (DPCE-R), Switching (DPCE-X) und Enhanced Queuing (DPCE-Q).
Der DPCE-R kann entweder auf Layer 3 oder als reiner Layer 2 Switch betrieben werden. Er ist in der Regel die kostengünstigste Lösung, wenn du eine Sparing-Strategie für den Support verwendest. Der DPCE-R ist die beliebteste Wahl, da er sehr große Routentabellen unterstützt und auch in einer reinen Switching-Konfiguration eingesetzt werden kann.
Die DPCE-X hat dieselben Funktionen und Dienste wie die DPCE-R; der Hauptunterschied besteht darin, dass die Routentabelle auf 32.000 Präfixe begrenzt ist und L3VPNs auf diesem DPC nicht verwendet werden können. Diese Linecards sind sinnvoll, wenn sie in einer sehr kleinen Umgebung oder in einem reinen Layer-2-Switching-Szenario eingesetzt werden.
DPCE-Q unterstützt dieselben Funktionen und Dienste wie DPCE-R und bietet zusätzlich eine Skalierung für H-QoS und die Anzahl der Warteschlangen.
| Modell | DPCE-R | DPCE-X | DPCE-Q |
|---|---|---|---|
| 40x1GE SFP | Ja | Ja | Ja |
| 40x1GE TX | Ja | Ja | Nein |
| 20x1GE SFP | Nein | Nein | Ja |
| 4x10GE XFP | Ja | Ja | Ja |
| 2x10GE XFP | Ja | Nein | Nein |
| 20x1GE und 2x10GE | Ja | Ja | Ja |
Hinweis
Die DPC-Linecards werden weiterhin unterstützt, aber es gibt keine aktive Entwicklung neuer Funktionen für diese Linecards. Für neue Implementierungen wird empfohlen, die neueren MPC-Linecards der zweiten Generation zu verwenden. Die MPC-Linecards verwenden den Trio-Chipsatz und sind der Schwerpunkt aller neuen Funktionen und Dienste von Juniper.
Modularer Port-Konzentrator
Die MPC Linecards sind die zweite Generation von Linecards für die MX. Beim Übergang vom DPC zum MPC gibt es zwei wesentliche Änderungen: Chipsatz und Modularität. Alle MPCs verwenden jetzt den Trio-Chipsatz, um mehr Umfang, Bandbreite und Dienste zu unterstützen. Die andere große Veränderung ist, dass die Leitungskarten jetzt modular mit MICs aufgebaut sind.
Der MPC kann als eine Art intelligente Hülle oder Träger für MICs betrachtet werden. Diese Änderung der Architektur ermöglicht die Trennung von physischen Ports, Überzeichnung, Funktionen und Diensten, wie in Abbildung 1-31 dargestellt. Alle Überzeichnungen, Funktionen und Dienste werden innerhalb des MPC verwaltet. Die Konfigurationen der physischen Ports werden vom MIC getrennt. Dadurch kann ein und dasselbe MIC in vielen verschiedenen Arten von MPCs eingesetzt werden, je nach Anzahl der Funktionen und dem erforderlichen Umfang.
Abbildung 1-31. High-Level-Architektur von MPCs und MICs
Ab Junos 14.2 gibt es zwölf verschiedene Kategorien von MPCs. Jedes Modell verfügt über eine unterschiedliche Anzahl von Trio-Chipsätzen, die verschiedene Skalierungs- und Bandbreitenoptionen bieten, wie in Tabelle 1-7 aufgeführt.
| Modell | # Der PFE-Komplex | Pro MPC-Bandbreite | Interface Unterstützung |
|---|---|---|---|
| MPC1 | 1 | 40 Gbit/s | 1GE und 10GE |
| MPC2 | 2 | 80 Gbit/s | 1GE und 10GE |
| MPC 16x10GE | 4 | 140 Gbit/s | 10GE |
| MPC3E | 1 | 130 Gbit/s | 1GE, 10GE, 40GE und 100GE |
| MPC4e | 2 | 260 Gbit/s | 10GE und 100GE |
| MPC5e | 1 | 240 Gbit/s | 10GE, 40GE, 100GE |
| MPC6e | 2 | 520 Gbit/s | 10GE und 100GE |
| NG-MPC2e | 1 | 80 Gbit/s | 1GE, 10GE |
| NG-MPC3e | 1 | 130 Gbit/s | 1GE, 10GE |
| MPC7e | 2 | 480 Gbit/s | 10GE 40GE und 100GE |
| MPC8e | 4 | 960 Gbit/s | 10GE 40GE und 100GE |
| MPC9e | 4 | 1600 Gbit/s | 10GE 40GE und 100GE |
Warnung
Die Karten der nächsten Generation (MPC7e, MPC8e und MPC9e) enthalten die dritte Generation des Trio ASIC (EA), der eine Bandbreite von 480 Gbps hat. Der EA ASIC wurde für diese Kartenmodelle entweder auf 80Gbps, 130Gbps oder 240Gbps "begrenzt".
Hinweis
Es ist wichtig zu wissen, dass die zuvor aufgelistete MPC-Bandbreite der aktuellen Hardware-Generation entspricht, die zum Zeitpunkt des Verfassens dieses Buches verfügbar war und sich mit neuen Software- und Hardwareversionen ändern kann.
Ähnlich wie die DPC-Linecards der ersten Generation unterstützen auch die MPC-Linecards die Möglichkeit, im Layer-2-, Layer-3- oder Enhanced Queuing-Modus zu arbeiten. So kannst du nur die Funktionen und Dienste auswählen, die du benötigst.
| Modell | Vollständige Schicht 2 | Vollständige Schicht 3 | Erweitertes Queuing |
|---|---|---|---|
| MX-3D | Ja | Nein | Nein |
| MX-3D-Q | Ja | Nein | Ja |
| MX-3D-R-B | Ja | Ja | Nein |
| MX-3D-Q-R-B | Ja | Ja | Ja |
Die meisten Unternehmenskunden entscheiden sich für das Modell MX-3D-R-B, da es sowohl Layer 2 als auch Layer 3 unterstützt. Normalerweise besteht beim Aufbau eines Rechenzentrums kein Bedarf an Enhanced Queuing oder Skalierung. Die meisten Service Provider bevorzugen das Modell MX-3D-Q-R-B, da es neben Enhanced Queuing auch Layer-2- und Layer-3-Dienste bietet. Ein typischer Anwendungsfall für einen Service Provider ist die Verwaltung großer Routing-Tabellen und vieler Kunden sowie die Bereitstellung von H-QoS, um die Service Level Agreements (SLAs) der Kunden durchzusetzen.
Der MX-3D-R-B ist die beliebteste Wahl, denn er bietet volle Layer-3- und Layer-2-Switching-Unterstützung.
Die MX-3D verfügt über dieselben Funktionen und Dienste wie die MX-3D-R-B, hat aber eine begrenzte Layer-3-Skalierung. Bei der Verwendung von BGP oder einem IGP ist die Routing-Tabelle auf 32.000 Routen begrenzt. Eine weitere Einschränkung besteht darin, dass MPLS L3VPNs auf diesen Linecards nicht verwendet werden können.
Der MX-3D-Q verfügt über dieselben Funktionen, Dienste und reduzierte Layer-3-Kapazität wie der MX-3D, bietet aber Enhanced Queuing. Damit ist es möglich, H-QoS zu konfigurieren und die Größe der Warteschlangen zu erhöhen.
Die MX-3D-Q-R-B vereint all diese Funktionen in einer einzigen Linecard und bietet somit Layer 2, Layer 3 und Enhanced Queuing.
MPC1
Schauen wir uns die MPC-Modelle noch einmal im Detail an. Die MPC beginnt mit der MPC1, die einen einzelnen Trio-Chipsatz (Single PFE) hat. Der Anwendungsfall für diesen MPC ist, eine intelligent überzeichnete Linecard zu einem attraktiven Preis anzubieten. Alle MICs, die mit dem MPC1 kompatibel sind, haben den Interfaces Block (IX Chip) in das MIC eingebaut, um die Überzeichnung zu handhaben, wie in Abbildung 1-32 dargestellt.
Abbildung 1-32. MPC1 Architektur
Bei der MPC1 verwaltet ein einziger Trio-Chipsatz beide MICs. Jedes MIC muss sich die Bandbreite teilen, die der einzelne Trio-Chipsatz bereitstellt. Daher wird der Interfaces Block an jedes MIC delegiert, um die Überzeichnung intelligent zu handhaben. Die Chipsätze kommunizieren untereinander mit High Link Speed (HSL2)
MPC2
Die MPC2 hat eine ähnliche Architektur wie die MPC1, fügt aber einen zusätzlichen Trio-Chipsatz (PFE) hinzu, so dass es insgesamt zwei sind.
Die MPC2 bietet einen eigenen Trio-Chipsatz pro MIC, wodurch sich die Bandbreite und Skalierung im Vergleich zur vorherigen MPC1 effektiv verdoppelt. In der MPC2-Architektur ist es möglich, MICs wie den 2x10GE und den 4x10GE zu kombinieren. Abbildung 1-33 zeigt antables und MPC2 im "Q"-Modus. Dieses Modell unterstützt den Dense Queuing ASIC (QX).
Abbildung 1-33. MPC2 Architektur
Das 2x10GE MIC ist sowohl für den Betrieb in der MPC1 als auch in der MPC2 konzipiert und verfügt daher über einen Interfaces Block, um die Überzeichnung zu bewältigen. Das 4x10GE MIC ist nur für den Betrieb im MPC2 vorgesehen und benötigt daher keinen Interfaces Block, da es direkt mit einem speziellen Buffering Block (MQ Chip) verbunden ist.
MPC-3D-16X10GE-SFPP
Die MPC-3D-16X10GE-SFPP ist eine Full-Width Line Card, die keine MICs unterstützt. Allerdings unterstützt sie 16 feste 10G-Ports. Diese MPC war aufgrund der hohen 10G-Port-Dichte eine der beliebtesten MPCs und bietet den niedrigsten Preis pro 10G-Port.
Der MPC-3D-16X10GE-SFPP hat vier Trio-Chipsätze (siehe Abbildung 1-34), die gleichmäßig auf die 16 Ports verteilt sind. So kann jede Gruppe von 4x10G-Schnittstellen einen eigenen Trio-Chipsatz haben.
Abbildung 1-34. High-Level-Architektur des MPC-3D-16x10GE-SFPP
Wenn du wissen willst, wie viele PFEs sich auf einem FPC befinden, kannst du den Befehl show chassis fabric map verwenden. Zuerst wollen wir herausfinden, in welchem FPC der MPC-3D-16X10GE-SFPP installiert ist:
dhanks@MX960> show chassis hardware | match 16x FPC 3 REV 23 750-028467 YJ2172 MPC 3D 16x 10GE
Der MPC-3D-16X10GE-SFPP ist in FPC3 installiert. Werfen wir nun einen Blick auf die Fabric Map und sehen wir, welche Links Up sind, um das Vorhandensein von PFEs in FPC3 zu erkennen:
dhanks@MX960> show chassis fabric map | match DPC3 DPC3PFE0->CB0F0_04_0 Up CB0F0_04_0->DPC3PFE0 Up DPC3PFE1->CB0F0_04_1 Up CB0F0_04_1->DPC3PFE1 Up DPC3PFE2->CB0F0_04_2 Up CB0F0_04_2->DPC3PFE2 Up DPC3PFE3->CB0F0_04_3 Up CB0F0_04_3->DPC3PFE3 Up DPC3PFE0->CB0F1_04_0 Up CB0F1_04_0->DPC3PFE0 Up DPC3PFE1->CB0F1_04_1 Up CB0F1_04_1->DPC3PFE1 Up DPC3PFE2->CB0F1_04_2 Up CB0F1_04_2->DPC3PFE2 Up DPC3PFE3->CB0F1_04_3 Up CB0F1_04_3->DPC3PFE3 Up DPC3PFE0->CB1F0_04_0 Up CB1F0_04_0->DPC3PFE0 Up DPC3PFE1->CB1F0_04_1 Up CB1F0_04_1->DPC3PFE1 Up DPC3PFE2->CB1F0_04_2 Up CB1F0_04_2->DPC3PFE2 Up DPC3PFE3->CB1F0_04_3 Up CB1F0_04_3->DPC3PFE3 Up DPC3PFE0->CB1F1_04_0 Up CB1F1_04_0->DPC3PFE0 Up DPC3PFE1->CB1F1_04_1 Up CB1F1_04_1->DPC3PFE1 Up DPC3PFE2->CB1F1_04_2 Up CB1F1_04_2->DPC3PFE2 Up DPC3PFE3->CB1F1_04_3 Up CB1F1_04_3->DPC3PFE3 Up
Das war gar nicht so schwer. Das einzige Problem ist, dass die Ausgabe von show chassis fabric command den MPC immer noch als DPC ausweist. Keine Sorge, wir können einen Abgleich für DPC3 durchführen. Wie wir sehen können, hat der MPC-3D-16X10GE-SFPP insgesamt vier PFEs, also vier Trio-Chipsätze. Beachte, dass DPC3PFE0 bis DPC3PFE3 vorhanden und als Up aufgeführt sind. Das bedeutet, dass die Linecard in FPC3 vier PFEs hat.
Der MPC-3D-16X10GE-SFPP unterstützt kein H-QoS, da es keinen Dense Queuing Block gibt. Damit bleiben nur zwei funktionale Trio-Blöcke pro PFE auf dem MPC-3D-16X10GE-SFPP: der Buffering Block und der Lookup Block.
Überprüfen wir das, indem wir einen Blick auf die Vorklassifizierungsmaschine werfen:
dhanks@MX960> request pfe execute target fpc3 command "show precl-eng summary" SENT: Ukern command: show prec sum GOT: GOT: ID precl_eng name FPC PIC (ptr) GOT: --- -------------------- ---- --- -------- GOT: 1 MQ_engine.3.0.16 3 0 4837d5b8 GOT: 2 MQ_engine.3.1.17 3 1 4837d458 GOT: 3 MQ_engine.3.2.18 3 2 4837d2f8 GOT: 4 MQ_engine.3.3.19 3 3 4837d198 LOCAL: End of file
Wie erwartet, übernimmt der Buffering Block die Vorklassifizierung. Interessanterweise ist dies eine weitere gute Möglichkeit, um zu sehen, wie viele Trio-Chipsätze sich in einem FPC befinden. Die Preclassification Engines sind mit den IDs 1 bis 4 aufgeführt und entsprechen unserer vorherigen Berechnung mit dem Befehl show chassis fabric map.
MPC3E
Die MPC3E war die erste modulare Linecard für die MX-Serie, die 100G- und 40G-MICs aufnehmen konnte. Sie wurde von Grund auf so konzipiert, dass sie Schnittstellen über 10GE hinaus unterstützt, aber auch mit einigen älteren MICs kompatibel bleibt.
Der MPC3E verfügt über mehrere neue und verbesserte Funktionen, wie in Abbildung 1-35 dargestellt. Am auffälligsten ist, dass der Buffering Block (XM-Chip) auf 130 Gbit/s erhöht wurde und die Anzahl der Lookup Blocks (LU-Chip) auf vier erhöht wurde, um 100GE-Schnittstellen zu unterstützen. Eine weitere wichtige Änderung ist, dass die Fabric-Switching-Funktionalität aus dem Buffering Block in einen neuen Fabric Functional Block (XF Chip) verlagert wurde.
Abbildung 1-35. MPC3E Architektur
Die MPC3E kann Line-Rate-Leistung für eine einzelne 100GE-Schnittstelle bereitstellen; andernfalls ist bekannt, dass diese Line Card 1,5:1 überzeichnet ist. Die MPC3E kann zum Beispiel 2x100GE-Schnittstellen unterstützen, aber der Buffering Block kann nur 130Gbps verarbeiten. Dies kann als 200:130 oder ungefähr 1,5:1 Überzeichnung geschrieben werden.
Enhanced Queuing wird von der MPC3E nicht unterstützt, da sie keinen Dense Queuing Block hat. Das bedeutet jedoch nicht, dass der MPC3E nicht in der Lage ist, Class of Service zu nutzen. Der Buffering Block ist genau wie der MPC-3D-16x10GE-SFPP in der Lage, Class of Service auf Port-Ebene zu unterstützen.
Architektur des Multiple Lookup Blocks
Alle MPC-Linecards vor der MPC3E hatten einen einzigen Lookup Block pro Trio-Chipsatz; daher war keine Synchronisierung der Lookup Blocks erforderlich. Die MPC3E ist die erste MPC, die mehrere Lookup-Blöcke einführt. Dies stellt eine interessante Herausforderung für die Synchronisierung der Lookup Blocks dar.
Im Allgemeinen verteilt der Buffering Block die Pakete nach dem Round-Robin-Prinzip auf alle Lookup Blocks. Das bedeutet, dass ein bestimmter Verkehrsfluss von mehreren Lookup-Blöcken verarbeitet wird.
Quelle MAC Lernen
Auf einer hohen Ebene erfährt der MPC3E die MAC-Quelladresse von den WAN-Ports. Einer der vier Lookup-Blöcke wird als Master bezeichnet und die drei übrigen Lookup-Blöcke als Slaves.
Der Master-Lookup-Block ist für die Aktualisierung der anderen Slave-Lookup-Blöcke verantwortlich. Abbildung 1-36 veranschaulicht die Schritte zur Synchronisierung aller Lookup-Blöcke:
Das Paket gelangt in den Buffering Block und wird zufällig an LU1 gesprüht, der als Slave Lookup Block bezeichnet wird.
LU1 aktualisiert seine eigene Tabelle mit der MAC-Quelladresse. Anschließend benachrichtigt er den Master Lookup Block LU0. Die Aktualisierung erfolgt über den Buffering Block, um LU0 zu erreichen.
Der Master Lookup Block LU0 empfängt die Aktualisierung der MAC-Quelladresse und aktualisiert seine lokale Tabelle entsprechend. LU0 sendet die Aktualisierung der MAC-Quelladresse an die MPC-CPU.
Die MPC-CPU empfängt die Aktualisierung der MAC-Quelladresse und aktualisiert ihrerseits alle Lookup-Blöcke parallel.
Abbildung 1-36. MPC3E Quell-MAC-Lernen
Ziel MAC Lernen
Der MPC3E lernt die Ziel-MAC-Adressen anhand der von anderen PFEs über die Switch-Fabric empfangenen Pakete. Anders als beim Lernen der Quell-MAC gibt es kein Konzept eines Master- oder Slave-Lookup-Blocks.
Der Lookup-Block, der das Paket von der Switch-Fabric empfängt, ist für die Aktualisierung der anderen Lookup-Blöcke verantwortlich. Abbildung 1-37 zeigt, wie die Ziel-MAC-Adressen synchronisiert werden:
Das Paket erreicht den Fabric Block und den Buffering Block. Das Paket wird zufällig an LU1 gesprüht. LU1 aktualisiert seine lokale Tabelle.
LU1 sendet dann über den Buffering Block Updates an alle anderen Lookup Blocks.
Der Buffering Block übernimmt die Aktualisierung von LU1 und aktualisiert dann parallel die anderen Lookup Blocks. Wenn jeder Lookup Block die Aktualisierung erhält, wird die lokale Tabelle entsprechend aktualisiert.
Abbildung 1-37. MPC3E Ziel-MAC-Lernen
Polizeiarbeit
Erinnere dich daran, dass der Buffering Block auf der MPC3E die Pakete gleichmäßig auf die Lookup Blocks verteilt, selbst bei gleichem Verkehrsfluss. Statistisch gesehen erhält jeder Lookup Block etwa 25% des gesamten Datenverkehrs. Bei der Definition und Konfiguration eines Policers muss der MPC3E die Bandbreite nehmen und sie gleichmäßig auf die Lookup-Blöcke verteilen. Jeder Lookup Block ist also so programmiert, dass er 25% der konfigurierten Policer-Rate überwacht. Schauen wir uns das mal genauer an:
firewall {
policer 100M {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 6250000;
}
then discard;
}
}
Der Beispiel-Policer 100M ist so konfiguriert, dass er einen bandwidth-limit von 100m durchsetzt. Im Falle des MPC3E wird jeder Lookup Block so konfiguriert, dass er 25m überwacht. Da die Pakete statistisch gesehen gleichmäßig auf alle vier Lookup-Blöcke verteilt werden, entspricht die Gesamtmenge dem ursprünglichen Policer bandwidth-limit von 100m. 25m * 4 (Lookup Blocks) = 100m.
MPC4E
Die MPC4e ist eine neue monolithische Karte mit zwei PFEs mit je 130 Gbps. Sie ist in zwei Modellen erhältlich:
32x10GE aufgeteilt in zwei Gruppen von 16xGE-Ports pro PFE
2x100GE + 8x10GE aufgeteilt in zwei Gruppen von 1x100GE + 4x10GE pro PFE
Jeder neue Puffer-ASIC (XM) ist mit zwei Lookup-Blöcken (LUs) verbunden. In Abbildung 1-38 siehst du, dass der MPC4e im Gegensatz zum MPC3e über seinen XM-Chip direkt mit der Fabric verbunden ist.
Abbildung 1-38. MPC4e Architektur
Der MPC4e unterstützt kein Dense Queuing und arbeitet im Oversubscription-Modus:
Für das 32x10GE-Modell stehen 160 Gbps an Link-Bandbreite für 130 Gbps an PFE-Kapazität zur Verfügung.
Für das Modell 2x100GE+8x10GE stehen 140 Gbps Link-Bandbreite für 130 Gbps PFE-Kapazität zur Verfügung.
MPC5E
Der MPC5e ist eine Weiterentwicklung des MPC4e. Er besteht aus einem PFE der zweiten Generation des Trio ASIC mit einer Kapazität von 240Gbps.
Es gibt vier Modelle der MPC5e und zwei Modelle unterstützen Dense Queuing mit dem neuen XQ ASIC.
MPC5E-40G10G / MPC5EQ-40G10G(Dense Queuing): sechs integrierte 40-Gigabit-Ethernet-Ports und 24 integrierte 10-Gigabit-Ethernet-Ports
MPC5E-100G10G / MPC5EQ-100G10G(Dense Queuing): zwei integrierte 100-Gigabit-Ethernet-Ports und vier integrierte 10-Gigabit-Ethernet-Ports
Das erste Modell der MPC5e (6x40GE + 24x10GE) ist eine 1:2 überzeichnete Karte, wie in Abbildung 1-39 dargestellt. Das zweite Modell ist voll leitungsfähig.
Abbildung 1-39. MPC5e Architektur
MPC6E
Die MPC6e ist die erste dedizierte MPC der MX2K-Serie. Er ist ein modularer MPC mit zwei PFEs mit je 260 Gbps, wie in Abbildung 1-40 dargestellt. Der MPC kann zwei MICs beherbergen - einige von ihnen sind überzeichnete MICs (wie das letzte in dieser Liste):
MIC6-10G: 10-Gigabit Ethernet MIC mit SFP+ (24 Anschlüsse)
MIC6-100G-CFP2: 100-Gigabit Ethernet MIC mit CFP2 (2 Anschlüsse)
MIC6-100G-CXP: 100-Gigabit Ethernet MIC mit CXP (4 Ports)
Die ersten beiden MICs, die am beliebtesten sind, sind nicht überzeichnet und laufen zum Linientarif.
Abbildung 1-40. MPC6e Architektur
NG-MPC2e und NG-MPC3e
Die nächste Generation der MPC2 und 3 basiert auf der XL/XM/XQ Reihe von ASICs. Die beiden Kartentypen haben genau die gleiche Hardware-Architektur. Der einzige Unterschied ist die "PFE-Taktung". Die PFE der NG-MPC2e hat eine Bandbreite von 80 Gbps, während die PFE der NG-MPC3e eine Bandbreite von 130 Gbits hat. Beide MPCs sind um eine PFE herum aufgebaut, die aus einem XL-Chip und einem XM-Chip besteht. Bei einigen Modellen (mit dem Zusatz "Q" für Enhanced Queuing) ist auch der XQ-Chip vorhanden (siehe Abbildung 1-41).
Abbildung 1-41. NG-MPC2e Architektur
MPC7e
Der MPC7e ist der erste MPC, der auf der neuesten Generation des Trio ASICs basiert: dem EA ASIC. Dieser MPC hat eine Gesamtbandbreite von 480 Gbps und besteht aus zwei PFEs, wobei jedes PFE eigentlich aus einem Eagle (EA) Chip besteht.
Hinweis
Der EA-Chip der MPC7e ist auf 240 Gbps begrenzt.
Es gibt 2 Modelle der MPC7e:
MPC7e multi-rate: feste Konfiguration mit 12 x QSFP-Ports (6 x QSFP-Ports pro eingebautem PIC). Alle Ports unterstützen 4 x 10GE, 40GE-Optik und 4 Ports unterstützen 100GE (QSFP 28).
MPC7e 10GE: Feste Konfiguration mit 40 x 10GE SFP+ Ports (2 x 20GE built-in PIC). Unterstützung für SR-, LR-, ER- und DWDM-Optik.
Abbildung 1-42 veranschaulicht die Hardware-Architektur des MPC7e Multi-Rate.
Abbildung 1-42. MPC7e Multi-Rate-Architektur
In Abbildung 1-43 ist die Architektur des MPC7e 10GE dargestellt.
Abbildung 1-43. MPC7e 10GE Architektur
MPC8e
Die MPC8e ist eine MX2K MPC. Sie basiert auf dem EA-Chip. Die MPC8e ist eine modulare Karte, die zwei MICs aufnehmen kann. Jedes MIC ist an zwei PFEs angeschlossen, die jeweils aus einem EA bestehen. Auf der MPC8e befinden sich vier EA-Chips. Dieser MPC ist für 10 und 40 GE-Schnittstellen optimiert. MPC8e unterstützt auch 12 x QSFP MIC-MRATE.
Hinweis
Der EA-Chip der MPC8e ist auf 240 Gbps begrenzt.
Abbildung 1-44. MPC8e Architektur
MPC9e
Wie die MPC8e ist auch die MPC9e eine modulare MX2K-MPC. Sie nimmt 2 MICs auf, die jeweils an 2 PFEs angeschlossen sind (die jeweils aus einem EA-Chip bestehen). In dieser Konfiguration arbeitet der EA-Chip mit 400Gbps. Mit dem MPC9e lässt sich die Anzahl der 100GE-Schnittstellen pro Steckplatz erhöhen. Mit der Leistung der neuen Generation des ASICs kann der MPC9e bis zu 16 x 100GE mit Leitungsgeschwindigkeit hosten. Der MIC-Steckplatz unterstützt außerdem 12 x QSFP MIC-MRATE.
Warnung
Um die volle Leistung der MPC8e und MPC9e auf der MX2K zu nutzen, wird die nächste Generation der Fabricplane für die MX2K benötigt. Diese nächste Generation der Fabric Card wird SFB2 genannt.
Abbildung 1-45 zeigt die Hardware-Architektur des MPC9e.
Abbildung 1-45. MPC9e Architektur
Paket-Durchgang
Nachdem du nun die verschiedenen Trio-Funktionsblöcke und den Aufbau der einzelnen Linecards verstanden hast, wollen wir uns ansehen, wie ein Paket durch jede der wichtigsten Linecards verarbeitet wird. Da es so viele verschiedene Variationen von Funktionsblöcken und Linecards gibt, sehen wir uns die anspruchsvollsten Konfigurationen an, die alle verfügbaren Funktionen nutzen.
MPC1 und MPC2 mit erweiterter Warteschlange
Der einzige Unterschied zwischen der MPC1 und der MPC2 ist die Anzahl der Trio-Chipsätze. Ansonsten sind sie funktional gleichwertig. Schauen wir uns an, wie sich ein Paket durch den Trio-Chipsatz bewegt. Es gibt zwei mögliche Szenarien: Ingress und Egress.
Ingress-Pakete werden von den WAN-Ports am MIC empfangen und sind für einen anderen PFE bestimmt:
Das Paket gelangt von den WAN-Ports in den Interfaces Block. Der Schnittstellenblock prüft jedes Paket und nimmt eine Vorklassifizierung vor. Je nach Art des Pakets wird es als hoch oder niedrig priorisiert markiert.
Das Paket gelangt in den Buffering Block. Der Pufferungsblock reiht das Paket entsprechend der Vorklassifizierung in die Warteschlange ein und bedient die Warteschlange mit der höchsten Priorität zuerst.
Das Paket gelangt in den Lookup-Block. Es wird ein Routensuchlauf durchgeführt und alle Dienste wie Firewall-Filter, Policing, Statistiken und QoS-Klassifizierung werden ausgeführt.
Das Paket wird an den Buffering Block zurückgeschickt und in die Switch Fabric eingereiht, wo es für einen anderen PFE bestimmt ist. Wenn das Paket für einen WAN-Port innerhalb des Switches bestimmt ist, wird es einfach in den Interfaces Block zurückgeschickt.
Abbildung 1-46. MPC1/MPC2-Paketdurchlauf: Ingress
Egress-Pakete werden etwas anders behandelt (der Hauptunterschied besteht darin, dass der Dense Queuing Block Class of Service auf Egress-Pakete anwendet, sofern konfiguriert):
Das Paket gelangt in den Buffering Block. Wenn eine Serviceklasse konfiguriert ist, sendet der Pufferungsblock das Paket an den Dense Queuing Block.
Das Paket gelangt in den Dense Queuing Block. Das Paket wird dann je nach Bedarf einem Scheduling, Shaping und einer anderen hierarchischen Serviceklasse unterzogen. Die Pakete werden in die Warteschlange gestellt, wie es die Konfiguration der Serviceklasse vorsieht. Der Dense Queuing Block nimmt die Pakete, die zur Übertragung bereit sind, aus der Warteschlange und schickt sie an den Buffering Block.
Der Buffering Block empfängt das Paket und sendet es an den Lookup Block. Dort werden eine Routensuche sowie alle Dienste wie Firewall-Filter, Überwachung, Statistiken und Abrechnung durchgeführt.
Das Paket wird dann zur Übertragung an die WAN-Schnittstellen gesendet.
Abbildung 1-47. MPC1/MPC2-Paketdurchlauf: Egress
MPC3E
Der Paketfluss des MPC3E ähnelt dem des MPC1 und MPC2, mit ein paar bemerkenswerten Unterschieden: Einführung des Fabric Blocks und mehrerer Lookup Blocks. Schauen wir uns zuerst das Ingress-Paket an:
Das Paket gelangt von den WAN-Ports in den Buffering Block und wird einer Vorklassifizierung unterzogen. Je nach Art des Pakets wird es als hoch oder niedrig priorisiert eingestuft. Der Buffering Block reiht das Paket entsprechend der Vorklassifizierung ein und bedient die Warteschlange mit hoher Priorität zuerst. Ein Lookup Block wird per Round-Robin-Verfahren ausgewählt und das Paket wird an diesen Lookup Block geschickt.
Das Paket gelangt in den Lookup-Block. Es wird eine Routensuche durchgeführt und alle Dienste wie Firewall-Filter, Policing, Statistiken und QoS-Klassifizierung werden ausgeführt. Der Lookup Block sendet das Paket zurück an den Buffering Block.
Das Paket wird an den Fabric Block zurückgeschickt und in die Switch Fabric eingereiht, wo es für einen anderen PFE bestimmt ist. Wenn das Paket für einen WAN-Port bestimmt ist, wird es einfach in die Warteschlange des Interfaces Blocks zurückgeschickt.
Das Paket wird an die Switch Fabric gesendet.
Abbildung 1-48. MPC3E Packet Walkthrough: Ingress
Egress-Pakete sind den Ingress-Paketen sehr ähnlich, aber die Richtung ist einfach umgekehrt (der einzige große Unterschied ist, dass der Buffering Block eine grundlegende Serviceklasse ausführt, da er aufgrund des Fehlens eines Dense Queuing Blocks kein Enhanced Queuing unterstützt):
Das Paket wird von der Switch Fabric empfangen und an den Fabric Block gesendet. Der Fabric Block sendet das Paket an den Buffering Block.
Das Paket gelangt in den Buffering Block. Das Paket unterliegt dann dem Scheduling, dem Shaping und jeder anderen Serviceklasse, die erforderlich ist. Die Pakete werden in die Warteschlange gestellt, wie in der Konfiguration der Serviceklasse festgelegt. Der Buffering Block nimmt dann die übertragungsbereiten Pakete aus der Warteschlange und sendet sie an einen Lookup Block, der per Round-Robin ausgewählt wird.
Das Paket gelangt in den Lookup Block. Es wird eine Routensuche durchgeführt sowie alle Dienste wie Firewall-Filter, Policing, Statistiken und QoS-Klassifizierung. Der Lookup Block sendet das Paket zurück an den Buffering Block.
Der Buffering Block empfängt das Paket und sendet es zur Übertragung an die WAN-Ports.
Abbildung 1-49. MPC3E Packet Walkthrough: Egress
Modulare Schnittstellenkarte
Wie bereits beschrieben, stellen die MICs die physischen Anschlüsse zur Verfügung und sind Module, die in verschiedene MPCs eingebaut werden können. Zwei MICs können in jeden MPC eingebaut werden. Es gibt eine Vielzahl von Konfigurationen der physischen Ports. Die Geschwindigkeiten reichen von 1G bis 100G und unterstützen verschiedene Medien wie Kupfer oder Glasfaser.
Hinweis
Das MIC-3D-40GE-TX ist ein wenig ungewöhnlich, denn es ist ein doppelt so breites MIC, das beide MIC-Steckplätze der MPC belegt.
Da die MICs modular aufgebaut sind, können sie von einem MPC zu einem anderen bewegt werden, mit Ausnahme des speziellen MPC6e MIC. Sie sind im laufenden Betrieb austauschbar und müssen nicht neu gestartet werden, um wirksam zu werden. MICs bieten den größten Investitionsschutz, da sie für alle MX-Plattformen und verschiedene MPCs verwendet werden können. Für die 4x10GE- und 1x100GE-MICs gibt es jedoch ein paar Besonderheiten.
Hinweis
Die aktuellste Kompatibilitätstabelle, um festzustellen, welche MICs wo verwendet werden können, findest du unter http://juni.pr/29wclEP.
Netzwerkdienste
Die MX240, MX480 und MX960 können gleichzeitig mit verschiedenen Arten von Linecards betrieben werden. So ist es zum Beispiel möglich, einen MX240 mit FPC1 mit einer DPCE-R Linecard zu betreiben, während FPC2 eine MX-MPC-R-B Linecard verwendet. Da es viele verschiedene Varianten von DPC-, MPC-, Ethernet- und Routing-Optionen gibt, kann das Chassis mit der Funktion "Netzwerkdienste" in einen bestimmten Kompatibilitätsmodus gezwungen werden.
Wenn die Netzwerkdienste nicht konfiguriert sind, wird beim Hochfahren eines MX-Chassis standardmäßig der Modus des Chassis durch den FPC bestimmt, der zuerst eingeschaltet wird. Wenn der erste FPC, der hochgefahren wird, ein DPC ist, können nur DPCs innerhalb des Chassis hochgefahren werden. Wenn der erste FPC, der eingeschaltet wird, ein MPC ist, können nur die MPCs innerhalb des Chassis eingeschaltet werden.
Die Netzwerkdienste des Chassis können mit dem set chassis network-services Knopf konfiguriert werden. Es gibt fünf verschiedene Optionen, auf die die Netzwerkdienste eingestellt werden können:
-
ip Erlaube allen Linecards, sich einzuschalten, außer der DPCE-X. Die
ipweist darauf hin, dass sie routen kann. Daher können Linecards wie die DPCE-X nicht eingeschaltet werden, da sie nur Bridging unterstützen.-
ethernet Erlaube allen Linecards, sich einzuschalten. Dazu gehören DPCE-X, DPCE-R und DPCE-Q.
-
enhanced-ip Erlaube allen Trio-basierten MPCs, eingeschaltet zu werden. Dies ist der Standardmodus des MX2K-Routers.
-
enhanced-ethernet Erlaube nur Trio-basierten MPC-3D-, MPC-3D-Q- und MPC-3D-EQ-Linecards, eingeschaltet zu werden.
-
all-ip Erlaube, dass sowohl DPC- als auch MPC-Linecards eingeschaltet werden können, außer DPCE-X-Linecards. Diese Option war in Junos 10.0 ausgeblendet und wurde für Produktionstests verwendet.
-
all-ethernet Erlaube, dass sowohl die DPC- als auch die MPC-Linecards eingeschaltet werden können. Dies gilt auch für DPCE-X und andere Linecards, die nur auf Layer 2 arbeiten. Diese Option war in Junos 10.0 ausgeblendet und wurde für Produktionstests verwendet.
Warnung
Die Modi
all-ipundall-ethernetsind veraltet und sollten nicht mehr verwendet werden. Diese Optionen wurden ausschließlich für Entwickler- und Produktionstests verwendet.
Es ist möglich, den Wert von network services zu ändern, während das Chassis läuft. Es gibt viele verschiedene Kombinationen; bei einigen ist ein Neustart erforderlich, bei anderen nicht:
-
Wechsel von
ipzuethernet Jeder DPCE-X wird hochgefahren. Kein Neustart erforderlich.
-
Wechsel von
ethernetzuip Diese Änderung führt zu einem Übertragungsfehler. Es ist erforderlich, dass alle DPCE-X Linecards ausgeschaltet sind, bevor die Änderung wirksam werden kann.
-
Ändern Sie
enhanced-ipinenhanced-ethernet Alle MPC-3D-, MPC-3D-Q- und MPC-3D-EQ-Linecards werden hochgefahren. Ein Neustart ist nicht erforderlich.
-
Ändern Sie
enhanced-ethernetinenhanced-ip Keine Veränderung.
-
Wechsel zwischen
ipoderethernetzuenhanced-ipoderenhanced-ethernet Die Übertragung wird abgeschlossen, erfordert aber einen Neustart des Chassis.
Um zu sehen, auf welchen Modus die Netzwerkdienste derzeit eingestellt sind, benutze den Befehl show chassis network-services :
dhanks@R1> show chassis network-services Network Services Mode: IP
Schalter und Steuerpult
Das Herzstück der MX-Serie ist das Switch and Control Board (SCB) bzw. das Control Board (CB) + Switch Fabric Board (SFB) für die MX2K-Serie. Es ist der Klebstoff, der alles zusammenhält.
Die SCB hat drei Hauptfunktionen: Sie vermittelt Daten zwischen den Linecards, steuert das Chassis und beherbergt die Routing Engine. Die SCB ist eine Single-Slot-Karte und hat auf der Vorderseite einen Träger für die Routing Engine. Eine SCB enthält die folgenden Komponenten:
Ein Ethernet-Switch für das Chassis-Management
Zwei Switch Fabrics
Steuerplatine (CB) und Routing-Engine-Zustandsmaschine für Mastership-Arbitration
Routing Engine Träger
Abbildung 1-50. Komponenten des Schalters und der Steuerplatine
Im Gegensatz zu anderen MX-Serien verfügen die MX2010 und MX2020 über getrennte Steuerkarten, auf denen zwar die Routing Engine, nicht aber die Fabric ASICs untergebracht sind. Eine neue Karte namens SFB (Switch Fabric Board) ist für die Weiterleitung zwischen den PFEs zuständig. Jedes SFB beherbergt eine Switch-Fabric-Ebene, die aus mehreren Fabric-Chipsätzen besteht.
Je nach MX-Gehäuse (außer bei der MX2K-Serie) und Redundanzgrad kann die Anzahl der SCBs variieren. Der MX240 und der MX480 benötigen zwei SCBs für 1 + 1 Redundanz, während der MX960 drei SCBs für 2 + 1 Redundanz benötigt. Bei einem MX-Router, der über eine Redundanz-SCB verfügt, kann der Bediener mit einem speziellen Knopf alle SCBs einschalten, um mehr Bandbreite zu erhalten. Das ist nützlich, wenn du die volle Leistung einer bestimmten MPC nutzen willst: also für MPC4e mit SCBE-Fabricplane.
Der Drehknopf heißt increased-bandwidth und ist wie folgt konfigurierbar:
{master}
droydavi@R1-RE0# set chassis fabric redundancy-mode increased-bandwidth
Und du kannst den aktuellen Redundanzmodus überprüfen:
{master}
droydavi@R1-RE0> show chassis fabric redundancy-mode
Fabric redundancy mode: Increased Bandwidth
Dann gehen die sechs Ebenen des MX960 online und werden für die Weiterleitung des Datenverkehrs genutzt (es gibt keine freie Ebene mehr):
{master}
droydavi@R1-RE0> show chassis fabric summary
Plane State Uptime
0 Online 449 days, 16 hours, 19 minutes, 4 seconds
1 Online 449 days, 16 hours, 18 minutes, 58 seconds
2 Online 449 days, 16 hours, 18 minutes, 53 seconds
3 Online 449 days, 16 hours, 18 minutes, 48 seconds
4 Online 449 days, 16 hours, 18 minutes, 43 seconds
5 Online 449 days, 16 hours, 18 minutes, 38 seconds
Diese MX2K-Serie hat acht SFB-Karten, die alle online sind und Datenverkehr übertragen. Es werden jedoch nur sieben benötigt, um die volle Chassis-Kapazität zu unterstützen.
Ethernet Switch
Jede SCB (bzw. CB bei der MX2000-Serie) enthält einen Gigabit-Ethernet-Switch. Dieser interne Switch verbindet die beiden Routing Engines und alle FPCs miteinander. Jede Routing Engine hat zwei Netzwerkkarten. Die erste Netzwerkkarte ist mit dem lokalen Onboard-Ethernet-Switch verbunden, während die zweite Netzwerkkarte mit dem Onboard-Ethernet-Switch auf der anderen SCB verbunden ist. So können die beiden Routing Engines intern miteinander kommunizieren und Funktionen wie NSR, NSB, ISSU und Verwaltungsfunktionen wie das Kopieren von Dateien zwischen den Routing Engines nutzen.
Jeder Ethernet-Switch ist mit jedem der FPCs verbunden, wie in Abbildung 1-51 dargestellt. Auf diese Weise können die Routing Engines mit dem Junos-Mikrokernel auf jedem der FPCs kommunizieren. Ein gutes Beispiel wäre, wenn ein Paket von der Routing Engine verarbeitet werden muss. Der FPC muss das Paket über den SCB-Ethernet-Switch an die Master-Routing-Engine senden. Ein weiteres gutes Beispiel ist, wenn die Routing Engine die Forwarding Information Base (FIB) ändert und alle PFEs mit den neuen Informationen aktualisiert.
Abbildung 1-51. MX-SCB Ethernet-Switch-Konnektivität
Es ist möglich, Informationen über den Ethernet-Switch innerhalb der SCB einzusehen. Der Befehl show chassis ethernet-switch zeigt an, welche Ports des Ethernet-Switches mit welchen Geräten auf hoher Ebene verbunden sind:
{master}
dhanks@R1-RE0> show chassis ethernet-switch
Displaying summary for switch 0
Link is good on GE port 1 connected to device: FPC1
Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled
Link is good on GE port 2 connected to device: FPC2
Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled
Link is good on GE port 12 connected to device: Other RE
Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled
Link is good on GE port 13 connected to device: RE-GigE
Speed is 1000Mb
Duplex is full
Autonegotiate is Enabled
Flow Control TX is Disabled
Flow Control RX is Disabled
Receive error count = 012032
Der Ethernet-Switch wird nur mit FPCs verbunden, die online sind, und mit Routing Engines. Wie du siehst, zeigt R1-RE0 an, dass sein Ethernet-Switch sowohl mit FPC1 als auch mit FPC2 verbunden ist. Überprüfe das Hardware-Inventar, um sicherzustellen, dass diese Informationen korrekt sind:
{master}
dhanks@R1-RE0> show chassis fpc
Temp CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt DRAM (MB) Heap Buffer
0 Empty
1 Online 35 21 0 2048 12 13
2 Online 34 22 0 2048 11 16
{master}
dhanks@R1-RE0>
Wie du sehen kannst, sind FPC1 und FPC2 beide online. Dies stimmt mit der vorherigen Ausgabe von show chassis ethernet-switch überein. Vielleicht ist dem aufmerksamen Leser aufgefallen, dass die Nummer des Ethernet-Switch-Ports mit dem Standort des FPCs gepaart ist. Zum Beispiel ist GE Port 1 mit FPC1 verbunden, GE Port 2 mit FPC2 und so weiter bis hin zu FPC11.
Obwohl jeder Ethernet-Switch über 24 Ports verfügt, werden nur 14 genutzt, wie in Tabelle 1-9 aufgeführt. Die GE-Ports 0 bis 11 sind für FPCs reserviert, während die GE-Ports 12 und 13 für Verbindungen zu den Routing Engines vorgesehen sind.
| GE-Anschluss | Beschreibung |
|---|---|
| 0 | FPC0 |
| 1 | FPC1 |
| 2 | FPC2 |
| 3 | FPC3 |
| 4 | FPC4 |
| 5 | FPC5 |
| 6 | FPC6 |
| 7 | FPC7 |
| 8 | FPC8 |
| 9 | FPC9 |
| 10 | FPC10 |
| 11 | FPC11 |
| 12 | Andere Routing Engine |
| 13 | Routing Engine GE |
Hinweis
Ein interessanter Hinweis ist, dass der Befehl show chassis ethernet-switch relativ zu dem Ort ist, an dem er ausgeführt wird. GE-Port 12 wird immer die andere Routing Engine sein. Wenn der Befehl zum Beispiel von re0 aus ausgeführt wird, wäre GE-Port 12 mit re1 und GE-Port 13 mit re0 verbunden.
Um genauere Informationen über einen bestimmten GE-Port am SCB-Ethernet-Switch zu erhalten, kannst du den Befehl show chassis ethernet-switch statistics verwenden. Schauen wir uns den GE-Port 13 genauer an, der mit der lokalen Routing Engine verbunden ist:
{master}
dhanks@R1-RE0> show chassis ethernet-switch statistics 13
Displaying port statistics for switch 0
Statistics for port 13 connected to device RE-GigE:
TX Packets 64 Octets 29023890
TX Packets 65-127 Octets 101202929
TX Packets 128-255 Octets 14534399
TX Packets 256-511 Octets 239283
TX Packets 512-1023 Octets 610582
TX Packets 1024-1518 Octets 1191196
TX Packets 1519-2047 Octets 0
TX Packets 2048-4095 Octets 0
TX Packets 4096-9216 Octets 0
TX 1519-1522 Good Vlan frms 0
TX Octets 146802279
TX Multicast Packets 4
TX Broadcast Packets 7676958
TX Single Collision frames 0
TX Mult. Collision frames 0
TX Late Collisions 0
TX Excessive Collisions 0
TX Collision frames 0
TX PAUSEMAC Ctrl Frames 0
TX MAC ctrl frames 0
TX Frame deferred Xmns 0
TX Frame excessive deferl 0
TX Oversize Packets 0
TX Jabbers 0
TX FCS Error Counter 0
TX Fragment Counter 0
TX Byte Counter 2858539809
<output truncated for brevity>
Obwohl der Großteil des Datenverkehrs zwischen den beiden Routing Engines abgewickelt wird, wird auch Ausnahmeverkehr durch den Ethernet Switch geleitet. Wenn ein Ingress PFE ein Paket empfängt, das weiterverarbeitet werden muss, z. B. ein BGP-Update oder SSH-Datenverkehr, der für den Router bestimmt ist, muss das Paket eingekapselt und an die Routing Engine gesendet werden. Dasselbe gilt, wenn die Routing Engine Datenverkehr empfängt, der an einen Egress-PFE gesendet werden muss.
Switch Fabric
Die Switch Fabric verbindet alle Ingress- und Egress-PFEs innerhalb des Chassis zu einem vollständigen Netz. Jede SCB und SFB besteht aus mehreren Switch Fabric ASICs. Die Anzahl der Switch Fabric-Chipsätze hängt vom Modell der SCB oder SFB ab.
Die MX240 und MX480 unterstützen zwei SCBs für insgesamt vier Switch Fabrics und acht Fabric Planes. Der MX960 unterstützt drei SCBs für insgesamt sechs Switch Fabrics und sechs Fabric Planes. Die MX2010 und MX2020 unterstützen acht Switch Fabrics/Ebenen.
Das wirft die Frage auf: Was ist eine Fabricplane? Stell dir die Switch-Fabric als eine feste Einheit vor, die N Verbindungen unterstützen kann. Wenn die MX960 48 PFEs unterstützt, sind alle diese Verbindungen in der Switch-Fabric vollständig verbraucht. Stell dir vor, was passiert, wenn du dieselbe Logik auf die MX480 anwendest. Jede Switch Fabric muss jetzt nur noch 24 PFEs unterstützen, also wird die Hälfte der Verbindungen nicht genutzt. Bei der MX240 und der MX480 werden diese ungenutzten Verbindungen gruppiert und eine weitere Ebene geschaffen, so dass die ungenutzten Verbindungen nun genutzt werden können (siehe Tabelle 1-10). Der Vorteil ist, dass der MX240 und der MX480 nur eine einzige SCB benötigen, um den Leitungsdurchsatz zu gewährleisten, und somit nur eine zusätzliche SCB für die 1 + 1 SCB-Redundanz benötigen.
| MX-SCB | MX240 | MX480 | MX960 | MX2K |
|---|---|---|---|---|
| PFEs | 12 | 24 | 48 | 80 |
| SCBs | 2 | 2 | 3 | 8 (SFB) |
| Switch Fabrics | 4 | 4 | 6 | 8 |
| Stoffhobel | 8 | 8 | 6 | 8 |
| Ersatzflugzeuge | 4 (1 + 1 SCB-Redundanz) | 4 (1 + 1 SCB-Redundanz) | 2 (2 + 1 SCB-Redundanz) | 8 (nur 7 benötigt-7+1 Modus SFB-Redundanz) |
Jede Ebene besteht aus einem oder mehreren Fabric ASICs, die ebenfalls von Juniper entwickelt wurden. Der Fabric ASIC ist mit allen PFEs über dedizierte Verbindungen (SERDES genannt) verbunden. Je nach Version der Fabric ASIC und dem Typ des angeschlossenen MPCs ist ein "Fabric Link" so programmiert, dass er mit einer bestimmten Rate arbeitet.
MX Switch Steuerplatine
Die MX SCB ist die Switch Fabric der ersten Generation für die MX240, MX480 und MX960. Diese MX SCB wurde für den Einsatz mit den DPC-Linecards der ersten Generation entwickelt. Wie bereits beschrieben, bietet die MX SCB Line-Rate-Leistung bei voller Redundanz.
Die MX240 und MX480 bieten 1 + 1 MX SCB-Redundanz, wenn sie mit den DPC-Linecards verwendet werden. Die MX960 bietet 2 + 1 MX SCB-Redundanz, wenn sie mit den DPC-Linecards verwendet wird.
Jede der Fabric Planes auf der SCB der ersten Generation kann eine Bandbreite von 20 Gbit/s verarbeiten. Die MX240 und MX480 verwenden acht Fabric Planes auf zwei SCBs, während die MX960 sechs Fabric Planes auf drei SCBs verwendet (siehe Tabelle 1-11). Aufgrund der Fabric-Plane-Virtualisierung ist die aggregierte Fabric-Bandbreite zwischen MX240, MX480 und MX960 unterschiedlich.
| Modell | SCBs | Stoffe wechseln | Stoffplanen | Fabric-Bandbreite pro Slot |
|---|---|---|---|---|
| MX240 | 2 | 4 | 8 | 160 Gbit/s |
| MX480 | 2 | 4 | 8 | 160 Gbit/s |
| MX960 | 3 | 6 | 6 | 120 Gbit/s |
MX SCB und MPC Vorbehalte
Der einzige Nachteil ist, dass die MX SCBs der ersten Generation nicht in der Lage sind, Leitungsredundanz mit einigen MPC-Linecards der neuen Generation zu bieten. Wenn die MX SCB mit den neueren MPC-Linecards verwendet wird, stellt sie zusätzliche Bandbreitenanforderungen an die Switch-Fabric. Die zusätzlichen Bandbreitenanforderungen gehen auf Kosten der Überbelegung und des Verlusts der Redundanz.
Hinweis
Die Enhanced MX SCB der neuen Generation wird benötigt, um die Fabric-Bandbreite mit voller Redundanz für MPC-Linecards mit hoher Dichte wie die MPC-3D-16x10GE-SFPP bereitzustellen.
MX240 und MX480
Wie bereits beschrieben, verfügen die MX240 und MX480 bei Verwendung von zwei MX SCBs über insgesamt acht Fabric Planes. Wenn die MX SCB und die MPCs auf der MX240 und MX480 verwendet werden, gibt es keine Leistungseinbußen und alle MPCs können mit Leitungsgeschwindigkeit arbeiten. Der einzige Nachteil ist, dass alle Fabric Planes in Gebrauch sind und online sind.
Werfen wir einen Blick auf eine MX240 mit den MX SCBs der ersten Generation und den MPC Line Cards der neuen Generation:
{master}
dhanks@R1-RE0> show chassis hardware | match FPC
FPC 1 REV 15 750-031088 ZB7956 MPC Type 2 3D Q
FPC 2 REV 25 750-031090 YC5524 MPC Type 2 3D EQ
{master}
dhanks@R1-RE0> show chassis hardware | match SCB
CB 0 REV 03 710-021523 KH6172 MX SCB
CB 1 REV 10 710-021523 ABBM2781 MX SCB
{master}
dhanks@R1-RE0> show chassis fabric summary
Plane State Uptime
0 Online 10 days, 4 hours, 47 minutes, 47 seconds
1 Online 10 days, 4 hours, 47 minutes, 47 seconds
2 Online 10 days, 4 hours, 47 minutes, 47 seconds
3 Online 10 days, 4 hours, 47 minutes, 47 seconds
4 Online 10 days, 4 hours, 47 minutes, 47 seconds
5 Online 10 days, 4 hours, 47 minutes, 46 seconds
6 Online 10 days, 4 hours, 47 minutes, 46 seconds
7 Online 10 days, 4 hours, 47 minutes, 46 seconds
Wie wir sehen können, hat R1 die MX SCBs der ersten Generation und MPC2 Linecards der neuen Generation. In dieser Konfiguration sind alle acht Fabric Planes Online und verarbeiten J-Cells.
Wenn eine MX SCB in einem MX240 oder MX480 mit den MPC-Linecards der neuen Generation fehlschlägt, sinkt die Leistung des Routers kontinuierlich. Der Ausfall einer der beiden MX SCBs würde zu einem Verlust der Hälfte der Routerleistung führen.
MX960
Der MX960 verfügt über sechs Fabric-Planes, wenn drei MX SCBs verwendet werden. Wenn die MX SCBs der ersten Generation in einem MX960-Router verwendet werden, reicht die Fabric-Bandbreite nicht aus, um Line-Rate-Leistung für die MPC-3D-16X10GE-SFPP- oder MPC3-3D-Linecards zu bieten. Bei den MPC1- und MPC2-Linecards reicht die Fabric-Kapazität jedoch aus, um mit Line-Rate zu arbeiten, es sei denn, sie werden mit dem 4x10G-MIC verwendet.
Werfen wir einen Blick auf eine MX960 mit einer MX SCB der ersten Generation und einer MPC-Karte der zweiten Generation:
dhanks@MX960> show chassis hardware | match SCB CB 0 REV 03.6 710-013385 JS9425 MX SCB CB 1 REV 02.6 710-013385 JP1731 MX SCB CB 2 REV 05 710-013385 JS9744 MX SCB dhanks@MX960> show chassis hardware | match FPC FPC 2 REV 14 750-031088 YH8454 MPC Type 2 3D Q FPC 5 REV 29 750-031090 YZ6139 MPC Type 2 3D EQ FPC 7 REV 29 750-031090 YR7174 MPC Type 2 3D EQ dhanks@MX960> show chassis fabric summary Plane State Uptime 0 Online 11 hours, 21 minutes, 30 seconds 1 Online 11 hours, 21 minutes, 29 seconds 2 Online 11 hours, 21 minutes, 29 seconds 3 Online 11 hours, 21 minutes, 29 seconds 4 Online 11 hours, 21 minutes, 28 seconds 5 Online 11 hours, 21 minutes, 28 seconds
Wie du siehst, verfügt die MX960 über drei MX SCB-Karten der ersten Generation. Außerdem gibt es drei MPC-Karten der zweiten Generation. Ein Blick auf die Fabric-Zusammenfassung lässt vermuten, dass alle sechs Fabric-Planes online sind. Bei der Verwendung von Hochgeschwindigkeits-MPCs und MICs beträgt die Überbelegung mit der MX SCB der ersten Generation ungefähr 4:3. Der Verlust einer MX SCB mit den MPC-Linecards der neuen Generation würde dazu führen, dass die Leistung der MX960 um ein Drittel sinkt.
MX240 und MX480 Stoffplanen
Da die MX240 und MX480 nur einen Bruchteil der PFEs der MX960 unterstützen müssen, können wir die ungenutzten Verbindungen in der Switch-Fabric zusammenfassen und eine zweite Fabric-Ebene pro Switch-Fabric erstellen. So können wir zwei Fabric Planes pro Switch Fabric haben, wie in Abbildung 1-52 dargestellt.
Abbildung 1-52. Juniper MX240 und MX480 Switch-Fabric-Ebenen
Wie du sehen kannst, hat jede Kontrolltafel zwei Schaltergewebe: SF0 und SF1. Jedes Switch Fabric hat zwei Fabric Planes. Somit haben die MX240 und MX480 acht verfügbare Fabric Planes. Das kannst du mit dem Befehl show chassis fabric plane-location überprüfen:
{master}
dhanks@R1-RE0> show chassis fabric plane-location
------------Fabric Plane Locations-------------
Plane 0 Control Board 0
Plane 1 Control Board 0
Plane 2 Control Board 0
Plane 3 Control Board 0
Plane 4 Control Board 1
Plane 5 Control Board 1
Plane 6 Control Board 1
Plane 7 Control Board 1
{master}
dhanks@R1-RE0>
Da die MX240 und MX480 nur zwei SCBs unterstützen, ist eine 1 + 1 SCB-Redundanz möglich. Standardmäßig befindet sich SCB0 im Online-Status und verarbeitet alle Weiterleitungen. SCB1 befindet sich im Ersatzzustand und wartet darauf, im Falle eines SCB-Ausfalls zu übernehmen. Dies kann mit dem Befehl show chassis fabric summary veranschaulicht werden:
{master}
dhanks@R1-RE0> show chassis fabric summary
Plane State Uptime
0 Online 18 hours, 24 minutes, 57 seconds
1 Online 18 hours, 24 minutes, 52 seconds
2 Online 18 hours, 24 minutes, 51 seconds
3 Online 18 hours, 24 minutes, 46 seconds
4 Spare 18 hours, 24 minutes, 46 seconds
5 Spare 18 hours, 24 minutes, 41 seconds
6 Spare 18 hours, 24 minutes, 41 seconds
7 Spare 18 hours, 24 minutes, 36 seconds
{master}
dhanks@R1-RE0>
Wie erwartet, sind die Ebenen 0 bis 3 online und die Ebenen 4 bis 7 sind Spare. Ein weiteres nützliches Tool dieses Befehls ist die Uptime. In der Spalte Uptime wird angezeigt, wie lange die SCB seit dem letzten Bootvorgang in Betrieb war. Normalerweise hat jede SCB die gleiche Betriebszeit wie das System selbst, aber es ist möglich, die SCBs während eines Wartungsfensters im laufenden Betrieb auszutauschen; die neue SCB würde dann eine geringere Betriebszeit aufweisen als die anderen.
MX960 Stoffflugzeuge
Der MX960 ist aufgrund der PFE-Skala ein ganz anderes Kaliber (siehe Abbildung 1-53). Er muss doppelt so viele PFEs unterstützen wie der MX480 und dabei die gleichen Anforderungen an die Leitungsgeschwindigkeit erfüllen. Um diese neuen Skalierungs- und Leistungsanforderungen zu erfüllen, ist eine zusätzliche SCB erforderlich.
Abbildung 1-53. Juniper MX960 Switch Fabric-Ebenen
Anders als die MX240 und MX480 unterstützen die Switch Fabric ASICs nur eine einzige Fabric Plane, da alle verfügbaren Links benötigt werden, um ein vollständiges Mesh zwischen allen 48 PFEs zu erstellen. Überprüfen wir dies mit dem Befehl show chassis fabric plane-location:
{master}
dhanks@MX960> show chassis fabric plane-location
------------Fabric Plane Locations-------------
Plane 0 Control Board 0
Plane 1 Control Board 0
Plane 2 Control Board 1
Plane 3 Control Board 1
Plane 4 Control Board 2
Plane 5 Control Board 2
{master}
dhanks@MX960>
Wie erwartet, scheinen die Dinge gut zu passen. Wir sehen, dass es zwei Switch Fabrics pro Steuerkarte gibt. Der MX960 unterstützt bis zu drei SCBs und bietet 2 + 1 SCB-Redundanz. Mindestens zwei SCBs sind für die grundlegende Weiterleitung der Leitungsrate erforderlich, und die dritte SCB bietet Redundanz im Falle eines SCB-Ausfalls. Werfen wir einen Blick auf den Befehl show chassis fabric summary:
{master}
dhanks@MX960> show chassis fabric summary
Plane State Uptime
0 Online 18 hours, 24 minutes, 22 seconds
1 Online 18 hours, 24 minutes, 17 seconds
2 Online 18 hours, 24 minutes, 12 seconds
3 Online 18 hours, 24 minutes, 6 seconds
4 Spare 18 hours, 24 minutes, 1 second
5 Spare 18 hours, 23 minutes, 56 seconds
{master}
dhanks@MX960>
Alles sieht gut aus. SCB0 und SCB1 sind online, während die redundante SCB2 im Zustand Spare in Bereitschaft ist. Wenn SCB0 oder SCB1 fehlschlagen, geht SCB2 sofort in den Online-Zustand über und ermöglicht es dem Router, den Verkehr mit der Leitungsrate weiterzuleiten.
Erweitertes MX Switch Control Board
Es gibt eigentlich drei Generationen von MX Switch Control Board: SCB, SCBE und SCBE2. Das SCBE wurde speziell für die MPC3e Linecards entwickelt, um die volle Line-Rate und Redundanz ohne Bandbreitenverlust zu gewährleisten. Auch wenn die MPC4e mit dem SCBE im Modus mit erhöhter Bandbreite gut funktionieren, wurde der SCBE2 entwickelt, um die Fabric-Redundanz für diese spezielle Linecard wiederherzustellen und mehr Kapazität für die MPC5e, die NG MPC2/3 Linecards und die MPC7e bereitzustellen.
Die SCB wird mit dem SF ASIC, die SCBE mit dem XF1 und die SCBE2 mit dem XF2 ASIC hergestellt. Der SFB wird auch mit dem XF2-ASIC hergestellt, wie in Tabelle 1-12 aufgeführt.
| Stoffkarte | ASIC verwendet | ASIC pro Flugzeug | MPC1 BW pro Ebene | MPC2 BW pro Ebene | MPC 16x10GE BW pro Ebene | MPC3 BW pro Ebene | MPC4 BW pro Ebene | MPC5 BW pro Ebene | MPC6 BW pro Ebene |
|---|---|---|---|---|---|---|---|---|---|
| SCB | SF | 1 | ~5Gbps | ~10Gbps | ~20Gbps | N/A | N/A | N/A | N/A |
| SCBE | XF1 | 1 | ~10Gbps | ~20Gbps | ~40Gbps | ~40Gbps | ~40Gbps | ~40Gbps | N/A |
| SCBE2 | XF2 | 1 | ~10Gbps | ~20Gbps | ~40Gbps | ~40Gbps | ~54 oder ~65Gbps |
~54 oder ~65Gbps |
N/A |
| SFB | XF2 | 3 | ~10Gbps | ~20Gbps | ~40Gbps | ~40Gbps | ~65Gbps | ~65Gbps | ~130Gbps |
Warum 54 oder 65Gbps? Um die maximale Kapazität von SCBE2 zu erreichen, muss die Kapazität der letzten Version der Chassis-Midplane erreicht werden. Mit der alten Midplane arbeitete SCBE2 mit 54 Gbps pro MPC, während die neue Midplane mit 65 Gbps arbeitet.
Hinweis
In der vorstehenden Tabelle bedeutet "BW pro Ebene" die verfügbare Fabric-Bandbreite zwischen dem MPC und einer Ebene. Um die gesamte verfügbare Fabric-Bandbreite eines bestimmten MPCs zu ermitteln, musst du diesen Wert mit der Anzahl der aktiven Ebenen multiplizieren.
Nehmen wir ein Beispiel, bei dem wir die MPC4e-Fabric-Bandbreite mit SCBE- oder SCBE2-Ebenen berechnen: Wenn die MPC4e zwei PFEs mit einer Kapazität von jeweils 130 Gbps hat, ergibt sich eine MPC4e-PFE-Kapazität von 260 Gbps.
Mit SCBE und aktiviertem Redundanzmodus
In dieser Fabric-Konfiguration sind vier Planes online. Aus Tabelle 1-12 geht hervor, dass die Fabric-Bandbreite pro Ebene für MPC4e etwa 40 Gbps beträgt. Die Gesamtbandbreite der Fabric beträgt also:
MPC4e Fab BW = 4 x 40 = 160Gbps
Beachte, dass in dieser Konfiguration die Fabric der Engpass ist: 260 Gbps PFE-BW für 160 Gbps auf dem Fabric-Pfad.
Aus diesem Grund wird empfohlen, die Redundanz mit dem increased-bandwidth Junos-Knopf zu deaktivieren und die sechs Ebenen online zu schalten. In dieser Konfiguration ist die verfügbare Fabric-Bandbreite:
MPC4e Fab BW = 6 * 40 = 240Gbps
Die Fabric ist zwar immer noch ein Engpass, aber die Fabric-Bandbreite ist jetzt fast so groß wie die PFE-Bandbreite.
Mit SCBE2 und aktiviertem Redundanzmodus
In dieser Konfiguration hängt die Fabric-Bandbreite von den Versionen der Chassis-Midplane ab. Betrachten wir zwei Fälle:
MPC4e Fab BW = 4 * 54 = 216Gbps mit der alten Midplane (in dieser Konfiguration ist
increased-bandwidthebenfalls sehr empfehlenswert).
Oder:
MPC4e Fab BW = 4 * 65 = 260Gbps mit der neuen Midplane-Version (in dieser Konfiguration, die auch den Vorteil der Fabric-Redundanz berücksichtigt, ist die Fabric kein Engpass mehr für die MPC4e).
J-Cell
Wenn Pakete durch die MX von einem PFE zum anderen wandern, müssen sie die Switch Fabric durchqueren. Bevor das Paket in der Switch Fabric platziert werden kann, muss es zunächst in J-Zellen unterteilt werden. Eine J-Zelle ist eine Einheit mit fester 64-Byte-Breite, wie in Abbildung 1-54 dargestellt.
Abbildung 1-54. Zellifizierung von Paketen mit variabler Länge
Der Vorteil von J-Cells ist, dass es für den Router viel einfacher ist, Daten mit fester Breite zu verarbeiten, zu puffern und zu übertragen. Bei Paketen mit variabler Länge und unterschiedlichen Kopfzeilen kommt es zu Inkonsistenzen bei der Speicherverwaltung, den Pufferslots und den Übertragungszeiten. Der einzige Nachteil bei der Segmentierung variabler Daten in eine Einheit mit fester Breite ist die Verschwendung, die als "Zellensteuer" bezeichnet wird. Wenn der Router beispielsweise ein 65-Byte-Paket segmentieren müsste, bräuchte er zwei J-Zellen: Die erste J-Zelle wäre voll ausgelastet, die zweite J-Zelle würde nur 1 Byte tragen und die anderen 63 Bytes der J-Zelle würden ungenutzt bleiben.
Hinweis
Diejenigen unter euch, die alt genug sind, um sich an den Geldautomaten zu erinnern, dürfen ruhig lachen.
J-Cell Format
Es gibt einige zusätzliche Felder in der J-Zelle, um die Übertragung und Verarbeitung zu optimieren:
Quell- und Zieladresse anfordern
Quell- und Zieladresse gewähren
Zelltyp
Laufende Nummer
Daten (64 Bytes)
Prüfsumme
Jedes PFE hat eine Adresse, mit der es innerhalb der Fabric eindeutig identifiziert werden kann. Wenn J-Zellen über die Fabric übertragen werden, ist eine Quell- und Zieladresse erforderlich, ähnlich wie beim IP-Protokoll. Die Sequenznummer und der Zellentyp werden nicht von der Fabric verwendet, sondern sind nur für die Ziel-PFE wichtig. Die Sequenznummer wird von der Ziel-PFE verwendet, um die Pakete in der richtigen Reihenfolge wieder zusammenzusetzen. Der Zellentyp identifiziert die Zelle als eine der folgenden: erste, mittlere, letzte oder einzelne Zelle. Diese Information hilft beim Zusammensetzen und Verarbeiten der Zelle in der Ziel-PFE.
J-Cell flow
Wenn das Paket den Ingress PFE verlässt, teilt der Trio-Chipsatz das Paket in J-Zellen auf. Jede J-Zelle wird über alle verfügbaren Fabric Links verteilt. Abbildung 1-55 zeigt eine MX960, die mit 48 PFEs und 3 SCBs voll ausgelastet ist. Der Beispiel-Paketfluss verläuft von links nach rechts.
Abbildung 1-55. Juniper MX960 Fabric Spray und Reordering über die MX-SCB
Die J-Zellen werden auf alle verfügbaren Stoffverbindungen gesprüht. Beachte, dass nur PLANE0 bis PLANE3 Online sind, während PLANE4 und PLANE5 Standby sind.
Antrag und Bewilligung
Bevor die J-Zelle an den Ziel-PFE übertragen werden kann, muss sie einen dreistufigen Antrags- und Bewilligungsprozess durchlaufen:
Der Quell-PFE sendet eine Anfrage an den Ziel-PFE.
Der Ziel-PFE antwortet dem Quell-PFE mit einem Grant.
Der Quell-PFE wird die J-Zelle übertragen.
Der Request- und Grant-Prozess garantiert die Zustellung der J-Zelle durch die Switch-Fabric. Ein zusätzlicher Vorteil dieses Mechanismus ist die Möglichkeit, unterbrochene Pfade innerhalb der Fabric schnell zu erkennen und eine Methode zur Flusskontrolle bereitzustellen (siehe Abbildung 1-55).
Abbildung 1-56. Juniper MX Fabric Anforderungs- und Bewilligungsprozess
Wenn die J-Zelle in der Switch-Fabric platziert wird, wird sie in eine von zwei Fabric-Warteschlangen eingereiht: hoch oder niedrig. Wenn mehrere Quell-PFEs versuchen, Daten an einen einzigen Ziel-PFE zu senden, führt dies zu einer Überlastung des Ziel-PFE. Ein Tool, das dem Netzbetreiber zur Verfügung steht, ist der Fabric Priority-Regler in der Class of Service-Konfiguration. Wenn du eine Weiterleitungsklasse definierst, kannst du die Fabric-Priorität einstellen. Wenn du die Fabric-Priorität für eine bestimmte Weiterleitungsklasse auf hoch einstellst, wird sichergestellt, dass der Verkehr mit hoher Priorität weitergeleitet wird, wenn ein Ziel-PFE überlastet ist. Dies wird in Kapitel 5 ausführlicher behandelt.
Zusammenfassung
In diesem Kapitel haben wir viele Themen behandelt, von der Software bis zur Hardware. Es ist wichtig zu verstehen, wie die Software und die Hardware zusammenarbeiten. Durch diese Kombination entstehen Router der Carrier-Klasse, die in der Lage sind, die schwierigen Herausforderungen zu meistern, mit denen Netzwerke angesichts der explosionsartigen Zunahme von Hochgeschwindigkeits- und High-Density-Ethernet-Diensten konfrontiert sind.
Junos hat ein sehr einfaches und elegantes Design, das eine klare und deutliche Trennung von Kontroll- und Datenebene ermöglicht. Juniper verfolgt den Grundsatz "Verteile, was du kannst, und zentralisiere, was du musst". Es gibt eine Handvoll Funktionen, die in die Datenebene verlagert werden können, um die Leistung zu erhöhen. Beispiele dafür sind die Verwaltung von regelmäßigen Paketen, wie Hello-Pakete von Routing-Protokollen, und Point of Local Repair (PLR)-Funktionen, wie MPLS Fast Reroute (FRR) oder Loop Free Alternate (LFA) Routen in Routing-Protokollen. Durch die Verlagerung dieser Funktionen auf die Datenebene wird die Steuerebene nicht zum Engpass und das System kann problemlos skalieren und den Dienst in weniger als 50 ms wiederherstellen.
Die MX-Serie reicht von einem kleinen 2U-Router bis hin zu einem riesigen 45U-Gehäuse, das 20 Linecards unterstützen kann. Der Trio-Chipsatz ist der ganze Stolz der MX-Familie. Der Chipsatz wurde für High-Density- und High-Speed-Ethernet-Switching und -Routing entwickelt. Trio hat die einzigartige Fähigkeit, Inline-Dienste direkt im Chipsatz bereitzustellen, ohne dass der Datenverkehr an ein spezielles Servicemodul weitergeleitet werden muss. Zu den Diensten gehören NAT, GRE, IP-Tunneling, Port Mirroring und IP Flow Information Export (IPFIX).
Die Juniper MX ist eine so vielseitige Plattform, dass sie viele Bereiche und Anwendungsfälle abdecken kann. Sowohl Unternehmensumgebungen (EE) als auch Service Provider haben Anwendungsfälle, die auf die Funktionen der Juniper MX abgestimmt sind:
- Rechenzentrumskern und Aggregation
Rechenzentren, die Dienste für mehrere Mieter bereitstellen müssen, benötigen mehrere Lerndomänen, Routing-Instanzen und Weiterleitungstrennungen. Jede Instanz ist in der Regel einem bestimmten Kunden zugeordnet, und eine wichtige Anforderung ist die Erfassung von Abrechnungs- und Rechnungsdaten.
- Rechenzentrum-Verbindung
Wenn die Zahl der Rechenzentren steigt, muss der Transport zwischen ihnen in der Lage sein, die vom Unternehmen geforderten Dienste bereitzustellen. Legacy-Anwendungen, Speicherreplikation und VM-Mobilität erfordern möglicherweise eine gemeinsame Broadcast-Domäne für mehrere Rechenzentren. MPLS bietet zwei Methoden, um eine Broadcast Domain über mehrere Standorte hinweg zu erweitern: Virtual Private LAN Service (VPLS) und Ethernet VPN (E-VPN).
- Enterprise Wide Area Network
Mit dem Wachstum der Unternehmenskunden steigt auch die Anzahl der Rechenzentren, Zweigstellen und Standorte und damit die Notwendigkeit, den Transport zwischen den einzelnen Einheiten zu gewährleisten. Die meisten Kunden kaufen den Transport von einem Dienstanbieter, und das gängigste Routingprotokoll zwischen den Kanten des Anbieters (PE) und des Kunden (CE) ist BGP.
- Service Provider Core und Aggregation
Der Kern eines Service-Provider-Netzes benötigt High-Density- und High-Speed-Schnittstellen für die Vermittlung von MPLS-Labels. Funktionen wie LFA in Routing-Protokollen und MPLS FRR sind eine Voraussetzung, um PLR innerhalb von 50 ms zu gewährleisten.
- Dienstanbieter-Kanten
Die Kanten von Service-Provider-Netzwerken erfordern eine hohe Skalierung in Bezug auf Routing-Instanzen, Anzahl der Routing-Präfixe und Port-Dichte, um eine große Anzahl von Kunden zu unterstützen. Um die Service Level Agreements (SLAs) der Kunden durchzusetzen, sind Funktionen wie Policing und hierarchische Class of Service (H-CoS) erforderlich.
- Verwaltung von Breitbandteilnehmern
Multiplay- und Triple-Play-Dienste erfordern eine hohe Teilnehmerzahl und umfangreiche Funktionen wie Authentifizierung, Autorisierung und Abrechnung (AAA), Änderung der Autorisierung (CoA) sowie dynamische Adressierung und Profile pro Teilnehmer.
- Mobile Backhaul
Die Zahl der Handys ist in den letzten 10 Jahren sprunghaft angestiegen und stellt hohe Anforderungen an das Netz. Die verschiedenen Arten von Diensten erfordern eine bestimmte Dienstklasse, um sicherzustellen, dass Sprachanrufe nicht in die Warteschlange gestellt oder verworfen werden, interaktive Anwendungen reaktionsschnell sind und das Surfen im Internet und die Datenübertragung nach bestem Bemühen erfolgen. Eine weitere wichtige Anforderung ist die Unterstützung paketbasierter Timing-Funktionen wie E-Sync und 1588v2.
Die Juniper MX unterstützt eine Vielzahl von Linecards mit Ethernet-Schnittstellen wie 1GE, 10GE, 40GE und 100GE. Die MPC-Leitungskarten unterstützen auch herkömmliche TDM-MICs (Time-Division Multiplexing) wie T1, DS3 und OC-3. Die Linecards machen den größten Teil der Investition in die MX-Familie aus. Ein schöner Investitionsschutz ist, dass die Linecards und MICs in jedem Juniper MX-Gehäuse verwendet werden können.
Jedes Chassis ist so konzipiert, dass es durch vollständige Hardware- und Software-Redundanz gegen Fehler geschützt ist. Alle Netzteile, Lüftereinschübe, Switch Fabric Boards, Steuerplatinen, Routing Engines und Line Cards können gegeneinander ausgetauscht werden und erfordern keine Ausfallzeiten. Funktionen der Software-Kontrollebene wie Graceful Routing Engine Switchover (GRES), Non-Stop Routing (NSR) und Non-Stop Bridging (NSB) sorgen dafür, dass Ausfälle der Routing Engine den Transitverkehr nicht beeinträchtigen, während die Backup-Routing Engine zum neuen Master wird. Das Juniper MX Chassis unterstützt außerdem In-Service Software Upgrades (ISSU), mit denen du die Software der Routing Engines aktualisieren kannst, ohne dass der Transitverkehr beeinträchtigt wird oder Ausfallzeiten entstehen. Die Hochverfügbarkeitsfunktionen von Junos werden in Kapitel 9 behandelt. Die Juniper MX ist ein phänomenales Stück Technik, das von Grund auf darauf ausgelegt ist, Pakete weiterzuleiten und Netzwerkdienste um jeden Preis bereitzustellen.
Fragen zur Kapitelüberprüfung
- 1. Welche Version von Junos wird drei Jahre lang unterstützt?
Die erste große Veröffentlichung des Jahres
Die letzte Wartungsversion des Jahres
Die letzte große Veröffentlichung des Jahres
Die letzte Dienstfreigabe des Jahres
- 2. Was ist keine Funktion der Steuerungsebene?
Verarbeitung von SSH-Verkehr, der für den Router bestimmt ist
Aktualisieren der RIB
Aktualisieren der FIB
Verarbeiten eines Firewall-Filters auf der Schnittstelle
xe-0/0/0.0
- 3. Wie viele Switch Control Boards benötigt der MX960 für die Redundanz?
1 + 1
2 + 1
1
2
- 4. Was ist ein Funktionsblock der Trio-Architektur?
Schnittstellen-Block
Routing-Block
BGP-Block
VLAN-Block
- 5. Welche MPC-Linecard bietet volle Layer-2- und begrenzte Layer-3-Funktionalität?
MX-3D-R-B
MX-3D-Q-R-B
MX-3D
MX-3D-X
- 6. Wie viele Trio-Chipsätze hat die MPC2 Linecard?
1
2
3
4
- 7. Wozu dient der Ethernet-Switch in der SCB?
Um zusätzliche SCB-Redundanz zu schaffen
Fernverwaltung
Kommunikation zwischen Linecards und Routing Engines bereitstellen
Zur Unterstützung zusätzlicher H-QoS-Skalierung
- 8. Welches J-Cell-Attribut wird vom Ziel-PFE verwendet, um die Pakete in der richtigen Reihenfolge wieder zusammenzusetzen?
Prüfsumme
Laufende Nummer
ID-Nummer
Zieladresse
Kapitel Wiederholung Antworten
- 1. Antwort: C.
- Die letzte Hauptversion von Junos in einem bestimmten Kalenderjahr wird als Extended End of Life (EEOL)-Version bezeichnet und drei Jahre lang unterstützt.
- 2. Antwort: D.
- Die Daten-/Weiterleitungsebene übernimmt die gesamte Paketverarbeitung, wie z. B. Firewall-Filter, Policers oder Zähler auf der Schnittstelle
xe-0/0/0.0. - 3. Antwort: B.
- Die MX960 benötigt drei SCBs für eine vollständige Redundanz. Dies wird als 2 + 1 SCB-Redundanz bezeichnet.
- 4. Antwort: A.
- Die wichtigsten Funktionsblöcke von Trio sind Schnittstellen, Pufferung, Dense Queuing und Lookup.
- 5. Antwort: C.
- Das MX-3D bietet volle Layer-2- und begrenzte Layer-3-Funktionalität. Die Routentabelle kann bis zu 32.000 Präfixe enthalten.
- 6. Antwort: B.
- Die MPC2 Linecard hat zwei Trio-Chipsätze. So kann jedes MIC einen eigenen Trio-Chipsatz haben.
- 7. Antwort: C.
- Der Ethernet-Switch auf der MX SCB wird verwendet, um ein vollständiges Netz zwischen allen Linecards und Routing Engines aufzubauen. Dieses Netzwerk verarbeitet Updates und Ausnahmepakete.
- 8. Antwort: B.
- Die Sequenznummer wird verwendet, um Pakete in falscher Reihenfolge auf dem Ziel-PFE wieder zusammenzusetzen.
Get Juniper MX-Serie, 2. Auflage 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.
