Ein Beispiel, wie man in NSX-T eine Edge konfiguriert, die via BGP routen austauscht in OPNsense.
Wie in einem vorderen Blog beschrieben, habe ich meine ESXi Server ein wenig neu gestaltet. Die BaseInfra ist so einfach wie möglich gehalten.
Die Firewall ist direkt auf der BaseInfra und ist verbunden mit dem normalen Heimnetzwerk und mit einem Trunk. Über den Trunk erstelle ich direkt auf der Firewall DirectOut’s von den VLANs. Warum? Wenn ich ein neues L2 Netz erstellen möchte, kann einfach das Netz auf dem Switch generiert, auf die Ports der ESXi getagged und dann direkt auf der Firewall der DirectOut erstellt werden.
Was wäre die alternative? Auf dem Switch das Netz erstellen, taggen auf den ESXi Ports, Portgruppe erstellen auf dem ESXi, Netzwerkkarte an die VM hängen, Netzwerk konfigurieren.
Die Details zur BaseInfra werden aber noch folgen.
Nun zum Lab habe ich mir auf der BaseInfra 4 ESXi Hosts installiert, die beziehen den Storage direkt vom NAS aus der BaseInfra, einzig das Management Netz liegt im Management vom Lab01 in einem dedizierten VLAN. Dazu ein vCenter und ein NSX-T Manager.
Für das Overlay ist ein separates VLAN 601 vorhanden. Die Infos sind dann wichtig, wenn man später die Einstellungen verstehen möchte.
opnSense
Fangen wir mal mit der Vorbereitung der OPNsense an.
Aktuell sind 2 VLANs im DirectOut, eines für die BaseInfra, das andere für das Lab01. Das Interface ist auch entsprechend mit dem Subnet für das Lab eingerichtet und betreibt auch DNS und DHCP für das entsprechende.
Für die späteren BGP Sessions packe ich einfach zwei /31er Netze direkt ins VLAN 501. Wer in der Schule gut aufgepasst hat, sagt jetzt sicher: jaaa aber ein /31 hat ja nur 2 Adressen eine fürs Netzwerk, eine fürs Broadcast. Mit einem /31 ist das aber nicht der Fall, die verfügen nur über 2 Hostadressen. Für den Zweck einer P2P Verbindung ist das perfekt. Also nicht verwirrt sein, wenn plötzlich die Adresse .0 genutzt wird.
Wenn man mit Routing arbeiten möchte, muss auf der OPNsense zuerst das FRR Paket installieren. Das kann einfach via Plugins hinzugefügt werden. Danach muss man den Routingkontext zuerst einmal aktivieren.
Dann kann bereits BGP vorbereitet werden. Die Firewall ist bei mir die äusserte ASN, darum lasse ich die auch bei 65000 stehen. Wichtig hierbei ist, dass man sich aufzeichnet, welche ASN man wo verwendet, damit man später kein Chaos erhält bei den Neighbors. Du kannst natürlich auch alles in die gleiche ASN packen, damit fehlt dir aber später die Möglichkeit, spezifisch zwischen den ASNs Filter erstellen zu können.
Die Option Route Redistribution definiert nun, welche Netze er automatisch an seine Neighbors verschicken soll. In meinem Fall bevorzuge ich aktuell ein Routing über die 3 Netze, die angeschlossen sind. Also WAN in Richtung Internet, 0101mgmt in Richtung BaseInfra und sich selber.
Damit ein Peering eingegangen werden kann, muss entsprechend seine Nachbarn definiert werden, wie auch in welcher ASN sich diese befinden. Wenn du hier z.B. die falsche ASN einfügst, wird das Peering fehlschlagen.
Der Tier-0-Router wird später die ASN 65001 bekommen, die 1. Adresse aus dem /31 liegt auf der Firewall und die 2. Adresse auf dem Tier-0. Zusätzlich aktiviere ich noch BFD, was für Bidirectional Forwarding Detection steht. In meinem Fall habe ich zwei Edge Nodes, die später je ein Peering zur Firewall erstellen. Sollte ein Edge ausfallen, so übernimmt automatisch der zweite Edge.
Damit BFD auch genutzt werden kann, muss dies in den Einstellungen aktiviert werden.
Das NAT wird umgestellt auf Hybrid, da nicht nur die bekannten Adressen umgewandelt werden sollen, sondern alles, was Richtung WAN Interface geht. Der Router an der WAN Schnittstelle hat keine Ahnung von den Netzen im NSX-T oder and der Firewall und wäre so auch nicht in der Lage, damit zu kommunizieren.
Nun ist die Firewall soweit vorbereitet und es kann an den NSX-T gehen.
NSX-T Hosts
Die Zuweisung der Tunnel Endpoint (TEP) Adresse erfolgt über einen angelegten Adressenpool im NSX-T
Dieser Schritt ist sehr stark davon abhängig, wie der VDS darunter eingerichtet ist. Ich gehe bei meinem auf einen Trunk, entsprechend muss ich ein Uplinkprofil haben, welches das oben erwähnte VLAN enthält. So springt später der TEP Adapter genau in das VLAN 601.
Damit nun die Hosts vorbereitet werden können, muss den Hosts mitgeteilt werden können, in welchen Transportzonen gearbeitet werden soll, mit welchem Uplinkprofil gearbeitet werden soll, woher die TEP-Adapter die IP beziehen und in welchem Zusammenhang die VDS Uplinks mit den NSX-T Uplinks stehen.
Nun kann der entsprechende Cluster gewählt werden und die Hosts konfiguriert gemäss Profil, dabei kann man einzelne Hosts konfigurieren, oder gleich einen ganzen Cluster, was später den Vorteil hat, dass wenn ein Host in den Cluster aufgenommen wird, dieser automatisch gleich vorbereitet wird.
Das sieht dann gegen Ende so aus. Das vCLM steht für vSphere Cluster Lifecycle Management. Das bedeutet, das der Cluster mit einem Cluster Based Image verwaltet ist und das deployen von den entsprechenden VIBs für NSX-T vom Lifecycle Manager übernommen wird.
NSX-T Edges
Bisher mussten noch keine Segmente genutzt werden, jetzt kommt aber die erste virtuelle Maschine, die nun wissen sollte, wo sie denn genau arbeiten soll.
Für meinen Zweck habe ich mir zwei Edges erstellt, die von der Konfiguration genau gleich bestückt sind, wie die Transportnodes. Der Edgenode wird auch als Übergang von virtuell zu physisch betrachtet. Entsprechend brauchen wir eine Definition, in welchem Overlay er mitwirkt, aber auch auf welcher Physik er später agieren soll. Dabei handelt es sich aber nur um die Hülle, ein Dienst läuft deswegen darauf noch lange nicht.
Der Node könnte auch auf einem Baremetalhost liegen, sprich es würde keine VM deployed, sondern der Tier-0-Router läge dann schlussendlich auf einem echten Server.
Ein Tier-0-Router braucht einen Cluster, also packe ich die beiden Edgenodes zusammen.
So sollte dann das Endergebnis ungefähr aussehen.
Meine CPU Generation ist nicht mehr die jüngste und die Hardware schickt auch nicht das Hugepage Flag mit. Das kann beim NSX-T Edge zu einem Problem führen, dass die virtuelle Maschine als nicht kompatibel gilt und der Edge nicht startet.
In einem nested ESXi kann man das direkt auf der VM vom ESXi machen, ansonsten muss das folgende Advanced Setting direkt auf der VM vom Edge eingetragen werden. Die VM muss dafür aber abgeschaltet sein.
| Name | Value |
|---|---|
| featMask.vm.cpuid.pdpe1gb | Val:1 |
Danach sollte die VM ohne Probleme starten und im NSX-T registriert werden.
NSX-T Tier-0
Fangen wir an mit dem Tier-0 Router, dabei wird auf dem Edgenode ein Kontext eingerichtet, der die ganzen Services betreiben kann.
Danach richten wir die ASN Nummer ein auf 65001, erinnere dich an die Konfig auf der opnSense.
Im nächsten Schritt konfigurieren wir die beiden Interfaces für das BGP-Peering. So hat der Tier-0 die Möglichkeit, mit der Firewall zu kommunizieren.
Nun wird ie Firewall als Neighbor eingerichtet, in diesem Fall zweimal, jedoch liegt die erste Adresse auf dem ersten Edgenode, die zweite Adresse auf dem zweiten Edgenode.
Jetzt definieren wir noch, welche Routen an die Firewall geschickt werden soll.
Auch hier ist die Konfiguration ähnlich oder gleich wie auf der Firewall, sprich zwischen Firewall und Tier-0 besteht nun ein kompletter Austauch der Routen.
NSX-T Test
Was ist nun das Ergebnis davon?
Nach dem erstellen eines Segments in der Overlayzone wird eine CIDR definiert. Das Segment wird angeschlossen an den bgp-01 Tier-0 Router.
Ein kurzer Blick in die Routingtabelle von der OPNsense zeigt, die Route wird direkt mitgeschickt und die beiden möglichen Pfade sind eingetragen. Auch woher die Route gelernt wurde.
Eine VM dahinter kann nun an das Segment angeschlossen werden, IP Einstellungen vornehmen und schon kann diese alle Netze erreichen und hat sogar die Möglichkeit, mit dem Internet zu kommunizieren.
So sieht das dann entsprechend im NSX-T Umfeld aus.