Apstra DC-Fabric Unter der Haube - Teil 2: Overlay

Teil 2 - Overlay Services

Dieser Post ist der zweite Teil der Serie “Apstra unter der Haube”, die zum Thema hat Apstra als Lösung und die darüber verwalteten DC-Fabrics aus Sicht eines Network Engineers besser zu verstehen.

Während ich im ersten Teil dieser Serie auf das Underlay-Netzwerk als stabiles und performantes Fundament eingegangen bin, möchte ich in diesem Post auf Design und Implementierung der Overlay-Services eingehen.

Zieldesign

Um die Overlay-Funktionsweise zu veranschaulichen und dabei möglichst verschiedene Aspekte und Anwendungsfälle zu berücksichtigen, werde ich folgendes Zieldesign auf Basis zwei verschiedener Tenants (Routing Zones) mit unterschiedlicher Routing-Konfiguration in Apstra umsetzen:

• TenantA:
  • Asymmetric IRB
  • VNI 10000
• TenantB
  • Symmetric IRB
  • VNI 20000

Insgesamt lege ich je Tenant zwei Layer-3 Virtual Networks inkl. Anycast-Gateway an, um später auch die Unterschiede im Inter-VNI-Routing veranschaulichen zu können:

Blueprint-Anpassungen

Die Demo Topologie aus dem ersten Teil bleibt aus physischer Sicht hierbei unverändert. Allerdings wurden im Blueprint die folgenden Anpassungen im Tab Virtual gemacht: Routing Zones Virtual Networks

Zudem wurde ein Connectivity Template angelegt, welches alle der o.g. Virtual Networks als Tagged Virtual Networks hinterlegt hat. Dieses Connectivity Template wurde auf allen Host-Ports gleichermaßen zugewiesen, sodass die konkreten VNs/VLANs Host-seitig flexibel angesprochen werden können.

EVPN-eBGP als Control-Plane

Apstra setzt bei der Umsetzung der EVPN Control Plane analog zum Underlay-Routing ebenfalls auf external BGP (eBGP) unter Verwendung der gleichen ASN und Router-IDs. Im Gegensatz zum Underlay- werden aber beim Overlay-Routing die eBGP-Peerings jeweils zwischen den lo0.0 Loopback-IPs der Spine- und Leaf-Switches etabliert. Die dafür benötigten Erreichbarkeiten werden durch das Underlay-Routing sichergestellt.

Sämtliche Overlay- bzw. Control-Plane-relevanten BGP-Konfigurationen sind dabei unter der Gruppe l3clos-l-evpn (bei allen Leaf-Switches), respektive l3clos-s-evpn (bei allen Spine-Switches) zu finden.

Am Beispiel des Leaf1 sieht man, dass auf Gruppenebene analog zum Underlay-Routing ebenfalls BGP multipath und multiple-as für ein optimales Loadbalancing über alle verfügbaren Pfade aktiviert ist.

protocols {
    [...]
    bgp {
        [...]
        group l3clos-l-evpn {
            type external;
            multihop {
                ttl 1;
                no-nexthop-change;
            }
            family evpn {
                signaling {
                    loops 2;
                }
            }
            multipath {
                multiple-as;
            }
            bfd-liveness-detection {
                minimum-interval 3000;
                multiplier 3;
            }
            neighbor 203.0.113.0 {
                description facing_spine1-evpn-overlay;
                local-address 203.0.113.2;
                family evpn {
                    signaling;
                }
                export ( LEAF_TO_SPINE_EVPN_OUT && EVPN_EXPORT );
                peer-as 64512;
            }
            neighbor 203.0.113.1 {
                description facing_spine2-evpn-overlay;
                local-address 203.0.113.2;
                family evpn {
                    signaling;
                }
                export ( LEAF_TO_SPINE_EVPN_OUT && EVPN_EXPORT );
                peer-as 64513;
            }
            vpn-apply-export;
        }
        log-updown;
        graceful-restart {
            dont-help-shared-fate-bfd-down;
        }
        multipath;
    }

• Die Option ttl 1 setzt das Time-to-Live Feld im IP-Header auf 1 (der Standardwert in Junos für Multihop eBGP-Sessions ist 64). Dies kann gewissermaßen als Sicherheits- bzw. Effizienzmaßnahme gesehen werden, da durch das Spine-/Leaf-Design immer davon ausgegangen werden kann, dass der jeweilige BGP-Peer immer nur einen Hop entfernt ist. Dadurch wird sichergestellt, dass die BGP-Session immer nur über die direkten Spine-Uplinks etabliert wird.
• Die Option no-nexthop-change ist für die Funktionalität der EVPN-Control Plane hingegen insbesondere bei den Spine-Switches von essentieller Bedeutung. Normalerweise wird der BGP-Nexthop unter Verwendung von eBGP bei der Weitergabe von Routen immer wieder vom jeweiligen Advertiser angepasst. EVPN-Routen im Besonderen müssen aber immer die IP-Adresse des Ursprungs-VTEP als Next-Hop verwenden, damit Remote-VTEPs die korrekten Tunnel-Endpunkte zu bestimmten Zielen (z.B: MAC-/IP-Adressen) in ihrer Forwarding-Logik hinterlegen können. Der Befehl no-nexthop-change stellt sicher, dass der Nexthop in den EVPN-Routen beim Weiterpropagieren nicht verändert wird.

Auf Gruppenebene wird auch die Address-Family EVPN durch das Statement family evpn signaling mit dem Zusatz loops 2 konfiguriert. Grundsätzlich basiert der Loop-Prevention Mechanismus bei eBGP darauf, dass der AS-Pfad von empfangenen Routen immer darauf geprüft wird, ob die eigene lokale ASN darin enthalten. Wenn dies nicht der Fall ist, wird die Route weiter propagiert, wenn das eigene ASN allerdings Teil des AS-Pfads ist, wird dies als Routing-Loop interpretiert und die Route wird verworfen. Die Option loops 2 hat allerdings zur Folge, dass der AS-Pfad noch als valide interpretiert wird, wenn er für empfangene Routen bis zu 2-mal das lokale ASN enthält.

Zusätzlich wird für die EVPN-Peerings BFD mit einer Erkennungszeit von 3x3000ms aktiviert, was auch grundsätzlich erforderlich ist, um die Multihop eBGP-Sessions zwischen den Loopback-IPs von Spine- und Leaf-Switches in angemessener Zeit zu terminieren (anstatt auf den Ablauf des Standard BGP Hold-Timers von 90s zu warten), sofern keine Erreichbarkeit mehr besteht.

Policies

Leaf-Switches

Analog zur Umsetzung des Underlay-Routings und wie im o.g. Config-Auszug zu sehen sind auch die folgenden beiden Export-Policies für die Overlay-eBGP Sessions auf sämtlichen Leaf-Switches aktiviert:

• LEAF_TO_SPINE_EVPN_OUT
• EVPN_EXPORT

Durch die logische UND-Verknüfung der Policies in der BGP-Config export ( LEAF_TO_SPINE_EVPN_OUT && EVPN_EXPORT ) werden nur Routen propagiert, die mit beiden Policies übereinstimmen - auch wenn die Policy EVPN_EXPORT nur ein simples accept aufweist.

Im Detail sehen die relevanten Policies wie folgt aus:

policy-options {
    [...]
    policy-statement EVPN_EXPORT {
        term EVPN_EXPORT-4095 {
            then accept;
        }
    }
    policy-statement LEAF_TO_SPINE_EVPN_OUT {
        term LEAF_TO_SPINE_EVPN_OUT-10 {
            from {
                protocol bgp;
                community FROM_SPINE_EVPN_TIER;
            }
            then reject;
        }
        term LEAF_TO_SPINE_EVPN_OUT-20 {
            then accept;
        }
    }
    [...]
    community FROM_SPINE_EVPN_TIER members 0:14;
}

Die Policy-Logik ist hier die gleiche, wie im Underlay, denn auch die EVPN Export-Policies stellen sicher, dass ein Leaf-Switch nur seine eigenen EVPN-Routen (Loopbacks / P2P-Links) an die Spines propagiert. Gleichzeitig wird verhindert wird, dass die gelernten Routen von einem Spine an den anderen Spine weiter propagiert werden, die mit der Community FROM_SPINE_EVPN_TIER mit dem Wert 0:14 markiert sind.

Spine-Switches

Bei den Spine-Switches sieht die Policy-Implementierung unterschiedlich aus. Hier wird nur eine Export-Policy für alle Leaf-Peers unter der Gruppe l3clos-s-evpn hinterlegt - SPINE_TO_LEAF_EVPN_OUT. Diese ist wie folgt strukturiert:

policy-options {
    [...]
    policy-statement SPINE_TO_LEAF_EVPN_OUT {
        term SPINE_TO_LEAF_EVPN_OUT-10 {
            then {
                community add FROM_SPINE_EVPN_TIER;
                accept;
            }
        }
    }
    [...]
    community FROM_SPINE_EVPN_TIER members 0:14;
    [...]
}

Die Spine-Policies sorgen dafür, dass der Spine sämtliche empfangenen EVPN-Routen von den einzelnen Leaf-Switches an andere Leafs weiterleitet, diese dabei aber mit der Community FROM_SPINE_EVPN_TIER mit dem Wert 0:14 kennzeichnet, sodass Leafs diese Routen nicht erneut zu den Spines zurück propagieren.

Modulare Overlay-Implementierung

Neben der zuvor beschriebenen EVPN-seitigen BGP-Konfiguration, setzt sich die übrige Overlay-Implementierung durch Apstra aus den folgenden Bausteinen zusammen, die ausschließlich auf den Leaf-Switches abgebildet werden:

• MAC-VRF “evpn-1”
• L3-VRFs
  • “TenantA”
  • “TenantB”
• Host-Anbindung (individuelle Port-Konfiguration)

MAC-VRF “evpn-1”

Die Routing-Instanz vom Typ mac-vrf mit dem Namen evpn-1 stellt die Fabric-weite L2 Overlay-Domain dar und fasst alle relevanten EVPN-Konfigurationen zusammen. Darunter sind neben den globalen EVPN-Parametern, auch alle VLAN- bzw. VNI-Definitionen zu finden, wie hier am Beispiel des Leaf1 zu sehen:

routing-instances {
    [...]
    evpn-1 {
        instance-type mac-vrf;
        protocols {
            evpn {
                encapsulation vxlan;
                default-gateway do-not-advertise;
                duplicate-mac-detection {
                    auto-recovery-time 9;
                }
                extended-vni-list all;
                vni-options {
                    vni 10101 {
                        vrf-target target:10101:1;
                    }
                    vni 10102 {
                        vrf-target target:10102:1;
                    }
                    vni 20201 {
                        vrf-target target:20201:1;
                    }
                    vni 20202 {
                        vrf-target target:20202:1;
                    }
                }
            }
        }
        vtep-source-interface lo0.0;
        service-type vlan-aware;
        interface ae1.0;
        route-distinguisher 203.0.113.2:65534;
        vrf-target target:100:100;
        vlans {
            vn101 {
                description "VN10101---TenantA VN10101";
                vlan-id 101;
                l3-interface irb.101;
                vxlan {
                    vni 10101;
                }
            }
            vn102 {
                description "VN10102---TenantA VN10102";
                vlan-id 102;
                l3-interface irb.102;
                vxlan {
                    vni 10102;
                }
            }
            vn201 {
                description "VN20201---TenantB VN20201";
                vlan-id 201;
                l3-interface irb.201;
                vxlan {
                    vni 20201;
                }
            }
            vn202 {
                description "VN20202---TenantB VN20202";
                vlan-id 202;
                l3-interface irb.202;
                vxlan {
                    vni 20202;
                }
            }
        }
    }
[...]
}

Die Nutzung und Ausgestaltung der MAC-VRF Instanz ist im Prinzip durch das Referenzdesign vorgegeben. Ebenso ist dadurch bereits vordefiniert, dass genau eine gemeinsame MAC-VRF Instanz für sämtliche Tenants (bzw. Routing Zones) verwendet wird. Es ist also nicht möglich je Tenant ein eigenes MAC-VRF zu verwenden, um bspw. sämtliche EVPN-Routen eines Tenants in einem Tenant-spezifischen MAC-VRF zu kapseln. Um unter diesen Voraussetzungen weiterhin zu gewährleisten, dass jedes individuelle VN/VLAN als eigenständige Bridge-Domain funktioniert, wurde der MAC-VRF Service-Type vlan-aware gewählt. (Vgl. dazu auch die Übersicht über verschiedende MAC-VRF Service-Types)

Zu den globalen EVPN-Parametern gehören u.a. die folgenden Einstellungen:

• Definition des VTEP-Source-Interfaces (lo0.0)
• Definition eines Leaf-spezifischen Route-Distinguishers (Format: <lo0.0-ip>:65534)
• Definition eins einheitlichen Domain-weiten VRF Route-Targets (target:100:100)
• Definition der VXLAN Data-Plane Enkapsulierung (encapsulation vxlan)
• Verhindern der Weitergabe von Anycast-Gateway MAC-Adressen via EVPN (default-gateway do-not-advertise)
• Aktivierung von Duplicate-MAC-Detection Auto-Recovery nach 9 Minuten (duplicate-mac-detection auto-recovery-time 9)

Je Virtual Network bzw. VNI wird zudem ein eigenes VRF Route-Target im Format target:<vni>:1 angelegt, um entsprechende VN-spezifische Type-2 bzw. Type-3 EVPN-Routen korrekt in die zugehörigen VNs zu exportieren bzw. importieren.

Je VLAN wird neben der Switch-lokalen VLAN-ID auch das zugehörige Fabric-weite VNI verknüpft. Zusätzlich erfolgt die Zuweisung des entsprechenden IRB-Interfaces für das Inter-VLAN/VNI-Routing im Overlay.

Sämtliche aktive L2-Switchports, die zur Anbindung von Endsystemen (Generic Devices) in Apstra definiert wurden, werden explizit der MAC-VRF Instanz zugeordnet (z.B.ae1.0 im o.g Beispiel).

L3 Tenant-VRFs

Für jeden Tenant bzw. jede Routing-Zone wird eine eigene Routing-Instanz vom Typ vrf angelegt, die jeweils sämtliche Overlay-spezifischen Layer-3 Konfigurationen bündelt. Zum einen gewährleisten diese VRFs die logische Trennung individueller Tenants auf L3-Ebene. Zum anderen ermöglichen sie innerhalb eines Tenants das Fabric-weite Inter-VLAN/VNI-Routing.

Apstra legt dazu standardmäßig je Tenant auf jedem Leaf ein eigenes Loopback-Interface an:

• TenantA: lo0.2
• TenantB: lo0.3

Diese Loopback-IPs haben nach meinem Verständnis vordergründig erst einmal keine konkrete Funktion, sondern sind eher als Best-Practise zu verstehen, um bspw. innerhalb der Tenants auch die E2E-Erreichbarkeit zwischen bestimmten Leaf-Switches verifizieren zu können (ggf. auch durch entsprechende Apstra Probes). Darüber hinaus können sie als Vorbereitung für die spätere Verwendung z.B. von externen L3-Kopplungen auf BGP-Basis verstanden werden.

Die Tenant-spezifischen Loopback-Interfaces werden bspw. auch nicht als Route-Distinguisher verwendet, denn für die Definition des VRF-eigenen Route Distinguishers verwendet Apstra eine Kombination aus Lo0.0 IP-Adresse und Tenant-spezifischer VLAN-ID: <lo0.0>:<vlan-id> (Beispiel Leaf1 - TenantA: 203.0.113.4:10)

Die von Apstra generierten Konfigurationen der Routing-Instanzen für TenantA und TenantB sind weitestgehend ähnlich, unterscheiden sich aber in einem Punkt - je nach verwendeter Routing-Konfiguration (Asymmetric / Symmtric IRB), wie hier am Beispiel des Leaf1 zu sehen:

routing-instances {
    TenantA {
        instance-type vrf;
        routing-options {
            graceful-restart;
            multipath;
            auto-export;
        }
        protocols {
            evpn {
                ip-prefix-routes {
                    advertise direct-nexthop;
                    encapsulation vxlan;
                    vni 10000;
                    export BGP-AOS-Policy-TenantA;
                }
            }
        }
        description "TenantA VRF with asymmetric routing RT10000:1 VLAN10";
        interface irb.101;
        interface irb.102;
        interface lo0.2;
        route-distinguisher 203.0.113.4:10;
        vrf-target target:10000:1;
    }
    TenantB {
        instance-type vrf;
        routing-options {
            graceful-restart;
            multipath;
            auto-export;
        }
        protocols {
            evpn {
                irb-symmetric-routing {
                    vni 20000;
                }
                ip-prefix-routes {
                    advertise direct-nexthop;
                    encapsulation vxlan;
                    vni 20000;
                    export BGP-AOS-Policy-TenantB;
                }
            }
        }
        description "TenantB VRF with symmetric routing RT20000:1 VLAN20";
        interface irb.201;
        interface irb.202;
        interface lo0.3;
        route-distinguisher 203.0.113.4:20;
        vrf-target target:20000:1;
    }
    [...]
}

Im TenantB wird Symmetric IRB unter Verwendung des L3-VNI 20000 aktiviert (irb-symmetric-routing vni 20000), sodass Inter-VNI-Routing immer über dieses L3-VNI erfolgt.

Im TenantA mit Asymmetric Routing erfolgt das Inter-VNI-Routing hingegen immer am Ingress-VTEP in das Ziel-VN, um Pakete dann VN-lokal zum Egress-VTEP weiterzuleiten.

Für beide Tenants wird das L3-VNI darüber hinaus für EVPN Type-5 Routen hinterlegt (ip-prefix-routes vni <l3-vni>). Daneben nutzt Apstra für diese Type-5 Routen zusätzlich die Option advertise direct-nexthop. Diese sorgt dafür, dass für entsprechende IP-Prefix Routen die Router MAC Extended Community angehängt wird, um Remote-VTEPs darüber die zu verwendende Ziel-MAC-Adresse des inneren Ethernet-Header zu signalisieren.

Zusätzlich sind für die L3-Routinginstanzen der einzelnen Tenants noch individuelle EVPN IP-Prefix-Route Export-Policies in den entsprechenden VRF-Configs hinterlegt:

• BGP-AOS-Policy-TenantA
• BGP-AOS-Policy-TenantB

Im Detail sehen die relevanten Policies wie folgt aus:

policy-options {
    [...]
    policy-statement AllPodNetworks-TenantA {
        term AllPodNetworks-TenantA-10 {
            from {
                family inet;
                protocol direct;
            }
            then {
                community add TENANTA_COMMUNITY_V4;
                accept;
            }
        }
        term AllPodNetworks-TenantA-100 {
            then reject;
        }
    }
    policy-statement AllPodNetworks-TenantB {
        term AllPodNetworks-TenantB-10 {
            from {
                family inet;
                protocol direct;
            }
            then {
                community add TENANTB_COMMUNITY_V4;
                accept;
            }
        }
        term AllPodNetworks-TenantB-100 {
            then reject;
        }
    }
    [...]
    policy-statement BGP-AOS-Policy-TenantA {
        term BGP-AOS-Policy-TenantA-10 {
            from policy AllPodNetworks-TenantA;
            then accept;
        }
        term BGP-AOS-Policy-TenantA-100 {
            then reject;
        }
    }
    policy-statement BGP-AOS-Policy-TenantB {
        term BGP-AOS-Policy-TenantB-10 {
            from policy AllPodNetworks-TenantB;
            then accept;
        }
        term BGP-AOS-Policy-TenantB-100 {
            then reject;
        }
    }
    [...]
    community TENANTA_COMMUNITY_V4 members [ 3:20007 21002:26000 ];
    community TENANTB_COMMUNITY_V4 members [ 3:20007 21003:26000 ];
}

Diese Policies sorgen dafür, dass alle direkt verbundenen IPv4-Netze (z.B.Tenant-spezifische Loopback-IPs der Leafs und die Subnets der IRB-Interfaces) der beiden VRFs auch als EVPN Type-5 Routen per eBGP innerhalb der Fabric propagiert werden. Dabei werden die EVPN-Routen mit den folgenden Communities markiert:

• TenantA: TENANTA_COMMUNITY_V4 mit den Werten 3:20007 und 21002:26000
• TenantB: TENANTV_COMMUNITY_V4 mit den Werten 3:20007 und 21003:26000

Während die o.g. Communities nicht aktiv in entsprechenden Routing Policies als Filterkriterium referenziert werden, vermute ich, dass Apstra diese Communities im Rahmen der Anomalie-Erkennung bzw. Telemetrie-Auswertung heranzieht, um die Ende-zu-Ende Funktionalität der Fabric zu verifizieren.

Host-Anbindung

Die individuelle Host-Anbindung ist eine Kombination aus den folgenden beiden Aspekten, die in Apstra an verschiedenen Stellen verwaltet werden:

• physische Anbindung - definiert durch die Abbildung der Generic Devices, sowie deren Verbindung zu den Leaf-Switches
• logische Anbindung - definiert durch die Connectivity Templates, die den einzelnen Host-facing Switch-Ports der Leaf-Switches zugeordnet sind

Bei der konkreten Umsetzung der Host-Anbindung durch Apstra kann man grundsätzlich zwischen zwei Anbindungsvarianten unterscheiden, die in unterschiedlichen Konfigurationen resultieren:

• standalone Ports (z.B. “Host2” und “Host3”)
• ESI-Multihoming (z.B. “Host1”)
  📝 Hinweis

  Für alle Host-facing Ports wird die MTU gleichermaßen auf 9192 Byte eingestellt
  Standalone-Ports werden durch Apstra im Prinzip wie auf jedem anderen Juniper L2-Switch umgesetzt, wie hier am Beispiel der Leaf3 mit den beiden Host-Ports ge-0/0/2 und ge-0/0/3 zu sehen ist:

interfaces {
    [...]
    ge-0/0/2 {
        description to.host2;
        mtu 9192;
        unit 0 {
            family ethernet-switching {
                interface-mode trunk;
                vlan {
                    members [ vn101 vn102 vn201 vn202 ];
                }
            }
        }
    }
    ge-0/0/3 {
        description to.host3;
        mtu 9192;
        unit 0 {
            family ethernet-switching {
                interface-mode trunk;
                vlan {
                    members [ vn101 vn102 vn201 vn202 ];
                }
            }
        }
    }
    [...]
}

Für redundant angebundene Hosts, in Kombination mit ESI-Multihoming wird die Sache etwas komplexer, wie hier am Beispiel des Leaf1 Port ge-0/0/2 zu entnehmen, welcher dem LAG-Interface ae1.0 zugeordnet ist:

interfaces {
    [...]
    ge-0/0/2 {
        description to.host1;
        ether-options {
            802.3ad ae1;
        }
    }
    [...]
    ae1 {
        description to.host1;
        mtu 9192;
        esi {
            00:02:00:00:00:00:01:00:00:01;
            all-active;
        }
        aggregated-ether-options {
            lacp {
                active;
                system-id 02:00:00:00:00:01;
            }
        }
        unit 0 {
            family ethernet-switching {
                interface-mode trunk;
                vlan {
                    members [ vn101 vn102 vn201 vn202 ];
                }
            }
        }
    }
    [...]
}

Auf dem LAG-Interface ae1.0 werden zusätzlich die folgenden Einstellungen von Apstra implementiert:

• Ethernet-Segment Identifier (ESI) - z.B. esi 00:02:00:00:00:00:01:00:00:01: Der ESI-Wert, der auf beiden anbindenden Leafs (Leaf1 und Leaf2 in diesem Fall) identisch sein muss und der in den verschiedenen EVPN-Routtypen für Multihomed-Hosts Verwendung findet, wird automatisch von Apstra festgelegt. Dieser muss Fabric-weit eindeutig sein, was durch Apstra durch einen Blueprint-internen Zähler sichergestellt wird. Der Zusatz all-active signalisiert, dass sämtliche aktiven Host-Ports zum Forwarding verwendet werden. (Standard-Konfiguration in Apstra und auch nicht anpassbar)
  💡 Tipp

  Damit die ESI-IDs auch Blueprint- bzw. Pod-übergreifend im Kontext einer Kopplung mittels DCI eindeutig bleiben, ist das sog. Most-significant-Byte ("msb") bzw. das zweite Oktett des ESI in den Blueprint-Einstellungen anpassbar (Default-Wert 02). In Apstra 6.1.2 ist dieser Parameter unter “Staged” > “DCI” > “Settings” zu finden. Das erste Oktett des ESI muss standardmäßig immer 00 lauten -> z.B. 00:02:[…]
• LACP System-ID (sofern aktiviert) - z.B. lacp system-id 02:00:00:00:00:01: Die LACP System-ID, die auf beiden anbindenden Leafs identisch sein muss und die in Richtung der Multi-Homed Hosts signalisiert wird, wird analog zum ESI automatisiert und gleichförmig von Apstra vergeben.

Fazit

Im Vergleich mit dem letzten Artikel zum Underlay-Netzwerk ist dieser Post wesentlich umfangreicher geworden. Ich habe trotz der Komplexität versucht alle relevanten Aspekte der Overlay-Implementierung vom BGP-Setup, über die verschiedenen Routing-Instanzen bis hin zu den Port-Konfigurationen möglichst anschaulich und trotzdem kompakt zu erläutern.

Ich hoffe, dass auch dieser zweite Teil der Serie “Apstra unter der Haube” dabei hilft Design und Implementierung der Overlay-Services - sowie die dafür verwendeten Bausteine in Apstra-managed DC-Fabrics mit Juniper Fabric-Switches besser zu verstehen. Man sieht hier aus meiner Sicht noch einmal deutlich, welche Komplexität hier von Apstra bis auf Implementierungsebene verwaltet wird und wie kleinteilig die komplette Umsetzung in Summe ist. Letzten Endes müssen alle Konfigurationen auf allen beteiligten Fabric-Switches ineinander greifen, um die Ende-zu-Ende Funktionalität sicherzustellen.

Aufgrund des ohnehin schon langen Artikels verzichte ich an dieser Stelle auf einen eigenen Abschnitt zur Verifikation der Overlay-Services. Diesen Aspekt werde ich im nächsten Teil der Serie aufgreifen und konkret beleuchten, wie sich die hier beschriebenen Implementierungen mit geeigneten Show-Commands im Detail überprüfen lassen.