Equal Cost Multipath (ECMP) mit JunOS konfigurieren

Heute wollen wir wie versprochen über die Konfiguration von ECMP (Equal Cost Multipath) mit JunOS berichten. Nach ein paar Worten zu den Grundlagen holen wir uns zur Demonstration zwei bzw. drei vSRX (aka Firefly Perimeter) ins Labor und schauen uns die Praxis und die entsprechende JunOS-Syntax an.

Grundlagen:

Über den Unterschied zwischen RIB und FIB

Bei Routingtabellen muss man grundsätzlich zwischen RIB (Routing Information Base) und FIB (Forwarding Information Base bzw. Forwarding Table) unterscheiden.
Die RIB wird aus verschiedenen Routingprotokollen generiert (Static, OSPF, IS/IS, BGP) und daraus die FIB berechnet und in die PFE (Packet Forwarding Engine) gepusht, welche dann das eigentliche Routing der Pakete übernimmt.

Welche Routen aus der RIB kommen in die FIB?

Beim Berechnen der FIB muss es eine sinnvolle Entscheidung geben welche Routen aus der RIB in die FIB exportiert werden.

Hierzu gibt es einige Entscheidungskritierien (garantiert unvollständige Liste):

1. Das verwendete Routingprotokoll bzw. dessen Priorität (aka Preference). Link für Details bei JunOS.
2. Etwaig installierte Export-Filter (z.B. sollen „falsche“ Routen sollten niemals ihren Weg in die FIB finden).
3. Erreichbarkeit des Nachbarrouters (aka Next-Hop).

Weiterhin kann es vorkommen dass zm selben Ziel (Prefix) mehrere unterschiedliche Routen existieren, dann wird in der Regel eine der beiden genommen (z.B. die mit dem kleineren Interfaceindex oder Next-Hop IP).
Welche Route in RIB und FIB installiert ist sieht man bei JunOS wie folgt:

Bei der letzten Route sieht man zwei Next-Hops (192.168.20.3 und 192.168.21.4) für das Ziel 192.168.3.0/24 in der RIB vorhanden sind.

Die oben durchgeführte Kontrolle in der Forwarding-Table ergibt, daß der mit „>“ marktierte Eintrag aus „show route“  in der FIB installiert wurde.

 

Wie aktiviere ich ECMP auf JunOS?

Nachdem klar ist wie es ohne ECMP funktioniert, können wir unser JunOS jetzt dazu bringen mehr als eine Route pro Destination in die FIB zu installieren. Hier müssen wir leider ein bischen unterscheiden zwischen den Geräteklassen „EX und SRX“ und „MX, M, T und PTX“.

„EX und SRX“ (Link zur Herstellerdokumentation)

Leider kann diese Geräteklasse nur „per-flow“ ECMP, was in der Praxis jedoch sowieso die sinnvollste Variante ist:

Nein, dieses Snippet hat keinen Fehler, hier steht wirklich „load-balance per-packet“ obwohl eigentlich „load-balance per-flow“ gemeint ist.
Juniper hat hier wohl versucht gleiche Syntax bei kleinerem Featuresset (im Vergleich zu „echten Routern“ (siehe unten) zu etablieren, was auf das erste Lesen ohne Hintergrundwissen ziemlich komisch erscheint.

 

„MX, M, T und PTX“ (Link1 und Link2 zur Herstellerdokumentation)

Auf den größeren Systemen von Juniper hat man dann neben der Qual der Wahl auch noch ein bischen die Qual der Dokumentationen:

Dieses Config Snippet aktiviert erst mal „per-packet“ Loadbalancing, genau so wie man das auch erwartet.

Mit diesem zusätzlichen Statement wird dann „per-flow“ Loadbalancing aktiviert. Zumindest interpretiere ich die Dokumentation so.

Vorsicht: Ungetestete Config! Ein Test mit unseren Labor-MXen steht noch aus, die werden gerade von anderen Setups gebunden (Ach, so eine MX-Series als VM wäre doch wirklich was Tolles! *Wunschdenk*).

Wie kontrolliert man ob ECMP aktiviert ist?

Idealerweise kann man sich natürlich die Config anschauen und kontrollieren ob o.g. Einstellungen gesetzt sind.
Alternativ dazu kann man natürlich auch die FIB befragen:

Beispiel 1: „Dr. Trivialo“

Als Grundlagenbeispiel nehmen wir zwei Router A1 und A2 welche nach folgendem Schaubild verbunden sind:

Als Routing Protokoll nutzen wir OSPF mit einer Area 0 und ohne Real World Schnickschnack wie Kosten, Loop-Back-IPs, RouterIDs, MD5 oder gar BFD – bitte nicht im wirklichen Leben nachmachen!

Konfiguration Router A1 (in „set-Notation“, weil kompakter):

 

Konfiguration Router A2 (in „set-Notation“, weil kompakter):

Hinweis: mit den „security forwarding-options […]“ wird die vSRX komplett auf den Packet-Mode umgestellt, d.h. Stateful Firewall bzw. Flow-Mode ist deaktiviert und das Ding ist ein reiner Router. 😉

Nach erfolgreichem commit auf beiden Routern schauen RIB und FIB auf A1 so aus:

TaDa!!! Die ECMP-Route ist installiert. Na das war ja einfach. 🙂

Beispiel 2: „Das Magische Dreieck“

Dass das Leben in Wirklichkeit nicht immer ganz so einfach ist zeigt folgendes Beispiel aus der Praxis.

Die hier dargestelle Herausforderung ist, dass die Router B1 und B2 ein Subnetz an „normalen Clients“ über VRRP bereitstellen und gleichzeitig aber die Verbindungen „A1-B1“ und „A1-B2“ per ECMP genutzt werden sollen. B1 wäre in unserem Beispiel der VRRP-Master.
Um das Ziel zu erreichen kann man sich behelfen in dem man die Kosten der Interfaces an den jeweilgen Routern entsprechend so einstellt, dass in Summe immer das selbe Gewicht rauskommt.

Auch hier gibt es keinen Real World Schnick Schnack um das Auge auf dem Wesentlichen zu haben. Auch verzichten wir auf die VRRP-Config. 🙂

Konfiguration Router A1 (in „set-Notation“, weil kompakter):

 

Konfiguration Router B1:

 

Konfigurtion Router B2:

Neben den eingestellten Kosten (metric) für die Interfaces wurden noch die User-Interfaces mit „passive“ versehen. Damit erreicht man, dass auf den Interfaces keine OSPF-Pakete versendet werden, um OSPF-Kommunikation der Router über diese Interfaces zu vermeiden.

Die RIBs der Router sind dann so wie gewünscht installiert:

• 192.168.1.0/24 und 192.168.2.0/24 sind auf A1 und B1 gemultipathed.
• Auf B2 sind alle Routen auschliesslich gesinglepathed.

Die Tatsache, dass B2 nur single-path Routen hat ist nicht weiter tragisch, da dieser Router in der Regel der Backup Router ist.

Wäre man theoretisch in der Lage auch auf B2 ECMP-Routen via B1 und A1 installieren zu lassen, werden 50% der Flows wieder von B2 auf B1 zurückreflektiert, was eine lustige Loop zur Folge hätte. Ein Sachverhalt den OSPF zum Glück in der Praxis verhindert.

 

Wie schon beim letzten Artikel über die vSRX zum Ende noch eine kleine Knobelaufgabe:

Wie könnte man „rein theoretisch“ in unserem Beispiel OSPF dazu bringen auf den Routern B1 und B2 das Netz 192.168.1.0/24 doch „zu multipathen“ und wie verhindert OSPF das in der Praxis?

 

Die ersten beiden Antworten bekommen wie immer ein kleines Dankeschön von uns.