IT-Administrator startet mit einem Blick in die Zukunft in das neue Jahr. So dreht sich der Heftschwerpunkt der Januar-Ausgabe um das Thema 'Future Networks'. ... (mehr)

Tunnel zwischen virtuellen Switchen

Der springende Punkt bei Virtualisierungslösungen für größere Umgebungen wie OpenStack oder VMware vCenter ist die Tatsache, dass der Admin der Verwaltungssoftware die Aufgabe gibt, eine neue VM auszurollen, die Verwaltungssoftware aber selber aufgrund der freien Ressourcen heraussucht, auf welchem Host diese gestartet wird. Die Netze, an denen die VM hängt, müssen dann aber auf allen VM-Hosts zur Verfügung stehen, was auch bedeutet, dass das LAN-Segment auf Layer-2-Ebene bereitsteht. In der Vergangenheit mussten dann zwischen den Host-Systemen VLANs geschaltet werden, damit dies funktioniert. Da dies aber in der Verwaltung umständlich wurde und die 4094 möglichen VLANs bei wirklich großen Umgebungen auch schnell an ihre Grenzen stoßen, wurden Overlaynetzwerke eingeführt. Dabei werden die Ethernetpakete in IP-Pakete eingepackt und so auf IP-Ebene durch das Rechenzentrum (oder sogar über dessen Grenzen hinaus) getunnelt. So müssen nur zwischen den virtuellen Switchen entsprechende Tunnel geschaltet werden. Auch diese Verschaltung wird von OpenStack automatisch vorgenommen – wenn auch nicht unbedingt immer sehr effizient.

Bild 1: Netzwerke mit Inseln, die über einen Tunnel verbunden werden.

Open vSwitch beherrscht dabei alle gängigen Tunnel-Protokolle (abhängig davon, ob der Kernel des Hostsystems die entsprechenden Module kennt). Am Anfang wurden nur GRE-Tunnel verwendet, mittlerweile werden aber auch VXLAN und das ganz neue GENEVE-Protokoll unterstützt. Die IP-Protokolle lassen sich wiederum in IPSEC einpacken, wenn die Leitung zwischen zwei VM-Hosts nicht vertrauenswürdig ist. Bild 1 zeigt ein Beispiel für ein Netz, in dem getunnelt werden muss.

Auf den beiden Hosts in Bild 1 existiert jeweils eine Insel eines LANs für virtuelle Hosts. Die Hosts, die diese Gäste beherbergen, sind im Netz getrennt, sodass die Pakete geroutet werden müssen. Die Adressen des aufgeteilten LANs werden im Netz nicht geroutet. Auf beiden Seiten muss es einen virtuellen Switch geben, der einen Port und eine Adresse im LAN hat, über den geroutet wird. Auf Host A ist dies 172.18.1.1 und auf Host B 172.19.1.1. Beide Seiten haben eth0 in diesem Switch als Port und die Routingtabelle ist so konfiguriert, dass die Hosts A und B erreichen.

Die "Insel-Switche" heißen islandswA und islandswB und verbinden das LAN 10.1.1.0/24. Zum Tunneln wird im Beispiel GRE verwendet. Das ist die Konfiguration für Host A:

# ovs-vsctl set-controller islandswA tcp:172.18.1.1
# ovs-vsctl add-port islandswA add-port gre1 -- set Interface gre1 type=gre options:remote_ip=172.19.1.1

Auf Host B konfiguriert der Administrator das Ganze spiegelverkehrt:

# ovs-vsctl set-controller islandswB tcp:172.19.1.1
# ovs-vsctl add-port islandswA add-port gre1 -- set Interface gre1 type=gre options:remote_ip=172.18.1.1

Das Kommando »ovs-vsctl show« zeigt die vollständige Konfiguration. Dabei ist darauf zu achten, dass beim Switch (in der Open vSwitch-Terminologie steht dort 'Bridge') islandsw[AB] unter dem Controller Eintrag das Flag "is_connected: true" vorhanden ist, womit bestätigt wird, dass die Konfiguration stimmt.

Um ein anderes Protokoll zu verwenden, sollten Sie erstens den Port anders nennen, um Verwirrung auszuschließen, und zweitens bei »type« "vxlan" oder "geneve" angeben. Diese Protokolle benötigen allerdings weitere Parameter. VXLAN packt die Pakete in UDP ein, sodass ein Port angegeben werden muss und benutzt außerdem auch noch Tunnel-IDs (ähnlich VLAN IDs, aber mit einem Bereich von 24 Bit statt der 12 bei VLANs). Die Tunnel-IDs heißen Virtual Network Identifier (VNI). GENEVE benimmt sich ähnlich und verwendet auch einen 24-Bit-VNI. VXLAN kann entweder Punkt-zu-Punkt-Tunnel bauen oder aber auch Multicast benutzen, sodass sich alle Switche, die an einem LAN-Segment teilnehmen wollen, per Multicast daran beteiligen. Um die IDs zu vergeben, fügt der Admin diese über options-Felder hinzu. »option:key=10000« setzt die VXLAN-ID 10000 für diesen Tunnel. Diese Art der Overlay-Netze erlaubt es auch, einzelne Hosts an ein solches Overlay anzuschließen, ohne dass dort Open vSwitch laufen muss. Mittels »ip link add vxlan0 type vxlan id 10000 remote 172.19.1.1« wird auf dem Linux-Host ein Interface definiert, das dann mit einer IP-Adresse versehen werden kann. Der VXLAN-Tunnel funktioniert dann als virtueller Access Port. Die Tatsache, dass reguläre UDP-Verbindungen genutzt werden, macht das Ganze auch etwas firewallfreundlicher und die Pakete lassen sich sogar NATen.

Portbündelung und LACP

In der Netzwerkwelt wird Kanalbündelung aus zwei Gründen verwendet: Performancesteigerung (2 x 1 GBit ist mehr als 1 x 1 GBit) und (wesentlich wichtiger) redundante Anbindung. Auch dies ist für den erfahrenen Linux-Netzwerkadmin nichts Neues, da der Kernel dies nativ unterstützt. Auch das Link Aggregation Control Protocol, das die Aushandlung und Steuerung (inklusive dem Erkennen des Ausfalls eines Links) übernimmt, beherrscht Linux für den Hostanschluss. Wie schon bei VLANs könnte der Admin auch das Bond-Interface als Port zum vswitch hinzufügen.

Bei Open vSwitch erzeugen Sie ein Bond-Interface mit dem Kommando »ovs-vsctl add-bond switch0 bond0 eth0 eth1« . Dies fügt das Bond Interface auf dem virtuellen Switch "switch0" hinzu. Folgt dem Kommando noch "lacp=active", so ist auch LACP auf den Ports aktiv (dies müssen Sie natürlich auf den angeschlossenen Switchen auch aktivieren). Der Zustand des angelegten Interfaces lässt sich mit dem Kommando »ovs-appctl lacp/show« kontrollieren. Parameter wie die ID oder Prioritäten konfigurieren Sie in der OVSDB mittels »ovs-vsctl set« . Der Hash-Algorithmus (nach dem die Pakete verteilt werden) wird ebenfalls so gesetzt, allerdings unter dem Parameter "bond_mode", der nichts mit LACP zu tun hat.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023