BSI-IT-Grundschutz für Gebäudeinfrastrukturen – wie soll man das denn umsetzen?
von Thomas Steil
Im letzten Insider habe ich über die neuen Grundschutzbausteine INF.13 Technisches Gebäudemanagement und INF.14 Gebäudeautomation berichtet, welche im kommenden BSI-IT-Grundschutz-Kompendium erscheinen werden und bereits als Final Draft vorliegen. Mit den Grundschutz-Bausteinen werden zeitgleich Umsetzungshinweise veröffentlicht, die Hilfe bei der konkreten Umsetzung bieten sollen. Dabei haben wir uns stark an den praktischen Erfahrungen der letzten Jahre orientiert, die wir bei der Realisierung unterschiedlichster „Smart Commercial Buildings“ gesammelt haben. Die Maßnahmen der Umsetzungshinweise orientieren sich an den Bausteinen und geben für jeden einzelnen Baustein praxisnahe Hinweise, die bei der Umsetzung helfen und damit letztendlich nicht nur das (smarte) Gebäude gegenüber Hackerangriffen sicherer machen sollen, sondern auch gegen versehentlich herbeigeführte Probleme.
Technischer Überblick über Open RAN
von David Feuser
Open RAN hat das Potenzial, das Radio Access Network (RAN) in Mobilfunknetzen zu revolutionieren. Bis zur Einführung von 5G waren die Netzbetreiber gezwungen, die Netzwerkausrüstung im RAN von ein und demselben Hersteller wie Huawei, Nokia oder Ericsson zu beziehen, da diese ein eigenes technisches „Ökosystem“ haben und nicht untereinander kommunizieren können. Die Open-RAN-Initiative versucht, dieses Ökosystem aufzubrechen, indem Standards für offene Schnittstellen und eine Abstrahierung des Hardware- und Softwarelevels definiert werden. Dadurch soll die Möglichkeit entstehen, im RAN die Netzwerkausrüstung unterschiedlicher Hersteller zu nutzen. Bevor wir mit den technischen Details beginnen, ist es wichtig zu erwähnen, dass Open RAN als eine Entwicklung begann, die für alle Mobilfunkgenerationen gelten soll, d.h. Open RAN soll für 2G, 3G, 4G, 5G und alle zukünftigen Gs genutzt werden können.
Layer-2-Netze überdenken
von Dr. Behrooz Moayeri
Vor gut zwei Jahren bin ich an dieser Stelle der Frage nachgegangen, wie groß die Ausdehnung von Layer-2-Netzen sein muss. Es wird Zeit, diese für das Design von Netzen wichtige Frage neu zu stellen.
Wettbewerb der Funktechniken ums IoT-Endgerät
von Dr. Joachim Wetzlar
Schon wieder gibt es einen neuen WLAN-Standard, so scheint es. Nach „Wi-Fi 6“ und „Wi-Fi 6E“ hat die Wi-Fi Alliance medienwirksam auf der Consumer Electronics Show (CES) in Las Vegas nun „Wi-Fi 6 Release 2“ vorgestellt. Auf ihrer Website findet sich die Ankündigung [1]. Was verbirgt sich dahinter? Können wir unsere bereits getätigten Investitionen in Wi-Fi-6-Equiment nun schon wieder abschreiben?
Angriff auf Netzneutralität, diesmal unter dem Deckmantel der Digitalen Souveränität
von Dr. Behrooz Moayeri
Vor fünf Jahren wurde seitens der damaligen US-Administration ein Angriff auf die Netzneutralität gestartet. Es ging darum, dass die US-Behörden aufhören sollten, Beschwerden über die Verletzung der Netzneutralität durch Internet Service Provider (ISP) nachzugehen. Beispiel: Wenn ein Provider, der selbst Streaming anbietet, für schlechte Streaming-Qualität anderer Anbieter sorgt, wäre das ein Verstoß gegen das Gebot der Netzneutralität. In der EU gibt es dieses Gebot. Auch in den USA rüttelte bis 2017 niemand ernsthaft daran. Vermutlich unter dem Lobby-Einfluss einiger klassischer Provider unternahm die Trump-Administration einen letztlich gescheiterten Versuch, den klassischen Providern freie Hand in der Besser- und Schlechterstellung von Internetverkehr zu lassen.
Einführung smarter Videogeräte – Tests im Vorfeld schützen vor bösen Überraschungen
mit Tanja Ulmen sprach Christiane Zweipfennig
Moderne Unternehmensgebäude werden zunehmend smarter. Immer neue Produkte brechen alte Denkweisen und Betriebsabläufe auf. Geräte, egal ob Telefon, Fernseher, Glühbirne, Stromzähler, Autos oder sogar Teppiche sind mittlerweile smart. Doch worauf ist bei der Neuanschaffung und dem Einsatz eines smarten Gerätes zu achten?
Layer-2-Netze überdenken
Fortsetzung
Neue Umgebungen, alte Probleme
Wie ich bereits im Januar 2020 geschrieben habe, ist der häufigste Fall der Nutzung ausgedehnter Layer-2-Netze in Rechenzentren von Unternehmen zu finden. Verschiedene Cluster bzw. virtualisierte Umgebungen erfordern die Layer-2-Kommunikation. Dabei werden sogenannte virtuelle IP-Adressen (VIP) für Server, Firewalls, Load Balancer, Storage-Systeme usw. genutzt. Eine VIP ist von einzelnen physischen Instanzen unabhängig. Hochverfügbarkeitsmechanismen sorgen dafür, dass eine VIP von Hardware zu Hardware „wandern“ kann. Mit der „VIP-Mobilität“ ist die Erwartung verbunden, dass Anwendungen weiter funktionieren, selbst wenn eine zentrale physische Komponente nicht mehr erreichbar ist.
Eine virtuelle IP-Adresse ist nur im selben Layer-2-Netz „beweglich“. Dies bedeutet, dass Hardware-Komponenten, denen dieselbe VIP zugeordnet werden kann, an dasselbe Layer-2-Netz angeschlossen werden müssen.
Layer-2 bedeutet an dieser Stelle immer Ethernet. Die Weiterleitung von Ethernet-Rahmen (auch Pakete genannt) erfolgt in einem Layer-2-Netz anhand von Layer-2-Adressen gemäß der Protokollschicht Media Access Control (MAC). MAC-Adressen nutzen anders als IP-Adressen einen „flachen“, also nicht strukturierten, Adressraum. Dies bedeutet, dass Switches alle in einem Layer-2-Netz kommunizierenden Geräte in ihren MAC-Adresstabellen führen müssen. Die Größenordnung solcher Tabellen entspricht der Anzahl der Endgeräte einschließlich der virtuellen Maschinen.
In den letzten Jahren haben die Netzkomponenten wesentlich an Skalierbarkeit zugelegt, was ihre Ausstattung mit schnellen Speichern für Adresstabellen sowie mit schnellen Prozessoren für die Suche in solchen Tabellen betrifft. Das hat die Illusion genährt, dass mit modernen Netzkomponenten beliebig große Layer-2-Netze realisiert werden können. Was bei dieser Illusion vergessen wird, ist das Maß der Vermehrung von Endgeräten durch die Virtualisierung. Dadurch können mehr MAC-Adressen im Netz auftreten als die leistungsfähigsten Netzkomponenten verkraften.
So nimmt es mich nicht wunder, dass Hersteller Skalierbarkeitsgrenzen für Layer-2-Netze auch für die leistungsfähigsten Netzkomponenten angeben. Das ist unabhängig davon, ob uralte Switching-Verfahren wie „Flooding and Learning“ angewandt werden oder moderne Mechanismen wie Ethernet Virtual Private Network (EVPN).
Layer-Netze sind chaotisch
Selbst wenn die Skalierbarkeitsgrenzen von Netzkomponenten nicht erreicht werden, bleiben wesentliche Probleme großer Layer-2-Netze. Diese sind per se chaotisch. Sie folgen dem Prinzip „jeder mit jedem“. Jedes Endgerät muss in einem Layer-2-Netz jedes andere Gerät darin direkt erreichen können. Sendet ein Endgerät ein Paket an eine unbekannte MAC-Adresse, müssen alle Switches im betreffenden Layer-2-Netz das Paket „fluten“, d.h. an alle Ports weiterleiten. Gleiches gilt für Broadcasts. Und auch für Multicasts, wenn sie nicht mittels Internet Group Management Protocol (IGMP) etwas selektiver verbreitet werden.
Das Flutungsprinzip macht die Layer-2-Netze fehleranfällig. Ein defekter oder fehlkonfigurierter Rechner oder Switch kann ein ganzes Layer-2-Netz lahmlegen. In Phasen von Änderungen, wie zum Beispiel beim Booten von Switches, kann es zur Flutung kommen. Selbst kleine Ursachen wie ein defekter Transceiver mit häufigem Statuswechsel können die Funktion eines ganzen Layer-2-Netzes beeinträchtigen.
So kann es passieren, dass ein Layer-2-Design zur Erhöhung der Verfügbarkeit genau diese verschlechtert.
Jedes ausgedehnte Layer-2-Netz ist zu hinterfragen
Bereits vor zwei Jahren habe ich darauf hingewiesen, dass die Betreiber großer Cloud-Umgebungen die Ausdehnung von Layer-2-Netzen in der Regel auf ein Rechenzentrum begrenzen. Das hat den Clouds nicht geschadet, was Ausfallsicherheit und Hochverfügbarkeit betrifft.
Wozu die großen Cloud-Betreiber in der Lage sind, sollten die Designer von RZ-Netzen von Unternehmen auch können. Jedes ausgedehnte Layer-2-Netz ist zu hinterfragen. Für viele Mechanismen, die jahrelang Layer-2-Konnektivität benötigt haben, gibt es mittlerweile Alternativen.
Ich nenne an dieser Stelle nur ein Beispiel:
Der Storage-Hersteller NetApp bietet die Lösung MetroCluster für hochverfügbare Anordnungen von Speichersystemen. Zwei Systeme können sich in verschiedenen Rechenzentren befinden und einen MetroCluster bilden. Der Cluster funktioniert, auch wenn nur eines der beiden Systeme arbeitet und erreichbar ist. Jahrelang erforderte dies den Anschluss beider Systeme an dasselbe Layer-2-Netz. Seit der Einführung der Version 9.5 des NetApp-Betriebssystems ONTAP wird der Mechanismus Virtual IP (VIP) unterstützt. Die VIP kann einem virtuellen Netz zugeordnet werden, das sich hinter einer NetApp-internen Routing-Instanz befindet. Diese Instanz unterstützt das Border Gateway Protocol (BGP). Verschiedene, ausfallsichere Routen zur VIP können per BGP im Netz propagiert werden.
Weniger Layer-2 ist mehr
Nicht jeder auf Layer-2-Konnektivität basierende Mechanismus wird über Nacht verschwinden. Dafür haben zu viele Hersteller in den letzten zwei Jahrzehnten den bequemen Weg über flache Layer-2-Netze gewählt. Doch viele flache Layer-2-Netze sind mittlerweile obsolet. Es gibt zum Beispiel keinen Grund, Layer-2-Netze hinter Load-Balancern auf verschiedene Rechenzentren auszudehnen. Load Balancer verteilen die Last auch auf reelle Server in verschiedenen IP-Subnetzen. Es kann sein, dass der Load Balancer selbst nur einen Hochverfügbarkeitsmechanismus unterstützt, der den Anschluss von zwei physischen Systemen an dasselbe Layer-2-Netz erfordert. Gleiches gilt für manche Firewall-Systeme. Allerdings macht es einen Unterschied, ob man jedes standortübergreifende RZ-Netz als Layer-2-Netz ausführt oder nur wenige Netze für Firewalls, Load Balancer und ggf. Server, die nichts anderes unterstützen. Weniger Layer-2 ist mehr. Das kann mehr Stabilität und Robustheit der Netze bringen.
Fazit
Es wird Zeit, sich an den Betreibern einiger der skalierbarsten und robustesten Umgebungen, die es gibt, nämlich großer Clouds, ein Beispiel zu nehmen und Layer-2-Netze zu überdenken. Ich freue mich auf die Diskussion darüber auf unserer Sonderveranstaltung Netze im April 2022.
Kontakt
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
Hallo,
Wie sieht es bei Hochschulen, wenn ein Standort mehre Gebäude in der Stadt verwaltet.
Und ich denke wenn man langsam von L2 weg möchte wird man nicht drum rum kommen mehr Zeit für die Routen zu opfern.
Und wenn dann eine Fakultät ein Netz im Gebäude X braucht und ein Netz in Gebäude Z obwohl da schon ein andere Netz herrscht und Spezialitäten kommen wird es mit Routing eng, eine optimale Lösung gibt es da noch nicht.
Was halten Sie von SDN ein Zentraler Punkt für alles. ?
BGP wird auch in VXLAN eingesetzt was halten Sie davon. ?
Das Thema ist sehr interessant und früher oder später wird es jeden treffen.
Mit freundlichen Grüßen
Joachim Weißenberger
Danke, Herr Weißenberger, für Ihre Anmerkung.
Ich versuche knapp darauf zu antworten, um im Rahmen dieses Kommentarfeldes zu bleiben:
In der Tat ist eines der Szenarien, die ich im Artikel nicht erwähnt habe, ein organisatorisches Umfeld, in dem A) die Verwaltung eines ganzen IP-Blocks an eine Orga-Einheit delegiert wird und B) diese Einheit diesen Block auf eine ortsübergreifende Layer-2-Domäne abbildet, so wie in Hochschulen üblich.
Natürlich gibt es Lösungen wie Controller-basierendes SDN (Beispiel Cisco SDA) bzw. Distributed Control Plane (Beispiel EVPN mit BGP und VXLAN oder Shortest Path Bridging), die jedes Layer-2-Netz an jeder Stelle im Netz bereitstellen. Aber alle solche Lösungen stoßen ab einer bestimmten Größe des Netzes an die im Artikel genannten Skalierbarkeitsgrenzen von Layer 2.
Der zentrale Netzbetreiber der Hochschule kann auch so agieren wie ein MPLS-WAN-Provider: Er könnte den Fakultäten sagen, dass im Stadtnetz nur Routing unterstützt wird. Oft erweisen sich „zwingende“ Gründe für Layer 2 als solche, die auf Bequemlichkeit zurückzuführen sind.
Viele Grüße
Moayeri