Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 112
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "title" in /usr/local/www/dokuwiki/blogfeed.php on line 278
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1732 of 1733 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1428 of 1429 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 1721 of 1722 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 253
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: unserialize(): Extra data starting at offset 2357 of 2358 bytes in /usr/local/www/dokuwiki/inc/parserutils.php on line 459
Warning: Undefined array key "date" in /usr/local/www/dokuwiki/blogfeed.php on line 264
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 266
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 321
Warning: Undefined array key "media" in /usr/local/www/dokuwiki/blogfeed.php on line 416 RUB Network Operations Center Blog
https://noc.rub.de/web/
2026-04-20T15:44:30+00:00RUB Network Operations Center
https://noc.rub.de/web/
https://noc.rub.de/web/lib/tpl/RUBnew/images/favicon.icotext/html2025-12-02T10:47:29+00:00Frank Degenhardtblog:2025:erweiterung_speicherplatz_rub-mailsystem_01.12.2025
https://noc.rub.de/web/blog/2025/erweiterung_speicherplatz_rub-mailsystem_01.12.2025
<p>
Anfang Juni diesen Jahres hat der Postmaster des RUB-Mailsystems festgestellt, dass durch die starke Belegung des Festplattenspeichers im Mailsystem die Performanz sehr und die Zuverlässigkeit ein wenig eingeschränkt waren. Um die Auswirkungen für die Nutzer möglichst gering zu halten haben wir uns entschlossen den Festplattenplatz auf den beiden NFS-Systemen des Mailsystems zu verdoppeln. Wir haben 32 Festplatten aus unterschiedlichen Fertigungsserien beschafft damit mögliche Produktionsfehler einer Charge weitestgehend ausgeschlossen sind. Anfang Juli 2025 sind wir gestartet die Festplatten auszutauschen. Auf den NFS-Systemen läuft ein ZFS-Dateisystem mit dessen Funktionen wir einige Feature den Nutzern zur Verfügung stellen können (z.B. Selfcare).
</p>
<p>
Für die Datensicherheit auf den Festplatten haben wir uns bei der Inbetriebnahme der NFS-Systeme für ein RAID-System (redundant array of independent disks) entschieden, welches uns jetzt beim Austausch zugutegekommen ist. Das ganze System ist ohne Unterbrechung während des Austauschs durchgelaufen, da in einem RAID-System die Daten in Blöcken auf mehreren Festplatten redundant geschrieben werden. Die neu eingebauten Festplatten mussten „nur“ noch automatisiert in das RAID-System integriert werden (im ZFS-Dateisystem „resilvering“ genannt). Dieser Vorgang hat pro Festplatte ca. 5 Tage gedauert. Alle Festplatten sind nun ausgetauscht und „resilvert“, das RUB-Mailsystem hat einen doppelt so großen Speicherplatz. Einen Ausfall auf Grund des Festplattenaustauschs gab es nicht.
</p>
<p>
Wir haben uns gegen die Neubeschaffung der Speichersysteme entschieden, da die NFS-Systeme auch nach ca. 5 Jahren keine Beeinträchtigung in Bezug auf CPU oder RAM gegenüber neuen Servern haben. Im Vergleich zu aktuellen Server-Systeme ist auch beim Thema Nachhaltigkeit kein Unterschied festzustellen, da wir „damals“ schon auf die Verbräuche Wert gelegt haben.
Somit ist das RUB-Mailsystem für die nächsten Jahre gut aufgestellt.
</p>
text/html2025-05-21T13:05:13+00:00Robin DärmannNetzwerkausfall im Datacenter am 19.05.2025
https://noc.rub.de/web/blog/2025/netzwerkausfall_dc
<h2 class="sectionedit1" id="netzwerkausfall_im_datacenter_am_19052025">Netzwerkausfall im Datacenter am 19.05.2025</h2>
<div class="level2">
<p>
Am Montag, den 19.05.2025 kam es um kurz nach 13 Uhr zu einem großflächigen Ausfall des Datennetzes an der RUB. Betroffen war das Routingsystem des Datacenters. Da sich im Datacenter fast sämtliche für den Betrieb des Datennetzes relevanten zentralen Komponenten befinden - u.a. <abbr title="Domain Name System">DNS</abbr>-Server, Proxy-Server, WLAN-Controller, Authentifizierungssysteme - funktionierte für die Nutzer auf dem Campus und in den Wohnheimen praktisch nichts mehr.
</p>
<p>
Wir stellten zunächst fest, dass das betroffene Routingsystem, ein redundantes Pärchen vom Typ Cisco Catalyst 9500, hohe CPU-Last aufgrund von ARP-Traffic (Broadcast) und Neighbor-Discovery-Traffic (Multicast) hatte. Diese Art Traffic kann das System nicht wie beispielsweise <abbr title="Access Control List">ACL</abbr>-Regeln in speziell gefertigten Chips (sog. ASICs) verarbeiten, sondern muss dies in seiner CPU tun. Es handelt sich um eine vergleichsweise kleine 8-Core-CPU von Intel, in der jede Menge Informationen verarbeitet werden müssen.
</p>
<p>
Die hohe CPU-Last hat dazu geführt, dass der Router seine Kommunikation mit den Uplink-Systemen auf dem Campus-Ring verloren hat, denn das dazu benötigte Routingprotokoll OSPF („Open Shortest Path First“) wird in der CPU des Routers verarbeitet und benötigt zudem Multicast. Ohne Kommunikation mit den Uplink-Systemen weiß der Router nicht mehr wohin mit Daten, die das Datacenter verlassen sollen. Darüber hinaus ist der Router auch aus dem Rest des Campusnetzes (und der Welt) nicht mehr sichtbar und es kann auf Systeme hinter diesem Router nicht mehr zugegriffen werden. Das Datacenter war also abgeschnitten von der Aussenwelt und nur noch in sich selbst funktionsfähig.
</p>
<p>
Für diese Art Notfall haben wir Zugriff auf die relevanten Systeme im Datacenter über ein separat angebundenes Notfall-Managementsystem. Über dieses entfernten wir anfangs zunächst aus der Ferne die OSPF-Konfiguration und restaurierten sie von Hand. Dadurch wurde, wie sich später heraus stellte, ein Software-Bug ausgelöst, der dazu führen kann, dass die tatsächlich aktive Konfiguration des Routingsystems nicht mehr der eingestellten Konfiguration entspricht. Diese Art Software-Bug macht i.d.R. eine Neukonfiguration des Systems nötig (Reset auf Werkseinstellungen), was nur vor Ort ohne erhebliche Hürden gut klappt. Vor Ort im Datacenter gelang dies dann um kurz nach 19 Uhr, so dass ab ca. 19:20 Uhr die einzelnen Netze schrittweise wieder erreichbar wurden. Der eigentliche Auslöser für den Abbruch der Routing-Kommunikation fand sich während der Analyse der Situation in einem VLAN eines Datacenter-Nutzers, welches vorerst deaktiviert wurde. Hier war die Quelle des Broadcast- und Multicast-Sturms zu finden.
</p>
<p>
Die Cisco Catalyst 9500 Plattform setzt für die Redundanz auf das Prinzip des sogenannten Stackings (in diesem Fall vom Hersteller „Stackwise-Virtual“ genannt). Dabei werden zwei oder ggfs. mehr Systeme zu logisch einem einzigen System zusammen gefasst. Das bedeutet, dass es zwar redundante Hardware gibt, jedoch die Software auf beiden Geräten nicht unabhängig voneinander läuft sondern einem komplexen, immerwährenden Synchronisationsprozess unterliegt, bei dem Daten wie MAC-Adressen, IP-Adressen, Routing-Informationen, ACLs und vieles weitere zwischen den zusammen geschalteten Systemen innerhalb von Millisekunden ausgetauscht werden. Der Vorteil daran ist, dass man nur „ein System“ hat, was an einer einzigen Stelle konfiguriert werden muss. Auch beim Hardware-Ausfall vereinfacht das den Austauschprozess erheblich.
</p>
<p>
Es hat sich jedoch in der Vergangenheit inzwischen mehrfach heraus gestellt, dass das Prinzip des Stackings vor allem im Bereich der kritischeren Infrastruktur nicht optimal funktioniert. Aus diesem Grund verzichten wir u.a. auch in der neuen Infrastruktur im Gebäude ID komplett auf Stacking. Für unsere Routing-Plattform überlegen wir aktuell, ob und wie ein entsprechender Umbau zu einer Alternative ohne Stacking, hin zu unabhängig voneinander arbeitenden Systemen, sinnvoll ist.
</p>
</div>
text/html2025-04-10T11:24:25+00:00Robin DärmannRouting-Probleme durch DHCPv6-Relay
https://noc.rub.de/web/blog/2025/routingprobleme_durch_dhcpv6
<h2 class="sectionedit1" id="routing-probleme_durch_dhcpv6-relay">Routing-Probleme durch DHCPv6-Relay</h2>
<div class="level2">
<p>
Am Mittwoch, den 09.04.2025 kam es zwischen 11:09 Uhr und ca. 15:00 Uhr zu zahlreichen Erreichbarkeitsproblemen vieler IT-Systeme der RUB. Die Ursache ist nicht eine einzige sondern eine Verkettung mehrerer Umstände.
</p>
<p>
Alles begann vor einigen Tagen - genauer gesagt am 1. April - als wir auf Wunsch eines Netzbetreuers eine Konfigurationsänderung an einem VLAN auf einem der Datacenter-Router durchgeführt haben. Dabei haben wir ein wichtiges Detail übersehen: Diese Konfigurationsänderung war unnötig und problematisch. Was wir allerdings nicht geahnt haben ist, dass diese Konfigurationsänderung einige Tage später zu einem mehrstündigen Routingproblem mit zahlreichen Auswirkungen und einer umfangreichen Troubleshooting-Aktion unter erschwerten Bedingungen führen würde.
</p>
</div>
<!-- EDIT{"target":"section","name":"Routing-Probleme durch DHCPv6-Relay","hid":"routing-probleme_durch_dhcpv6-relay","codeblockOffset":0,"secid":1,"range":"1-836"} -->
<h3 class="sectionedit2" id="was_im_detail_geschah">Was im Detail geschah</h3>
<div class="level3">
<p>
Am 1. April haben wir das DHCPv6-Relay in einem VLAN auf Wunsch des Netzbetreuers so umgestellt, so dass es nicht mehr auf unseren zentralen DHCPv6-Server sondern auf die eigenen DHCPv6-Server des Netzbetreuers zeigt. Dabei hätte uns auffallen müssen, dass diese im selben VLAN stehen und man daher überhaupt keine spezielle Konfiguration auf dem Router dafür benötigt. Der Router macht an dieser Stelle auch keine Konsistenzprüfung und hat die Konfiguration anstandslos akzeptiert. Das sieht dann (auf unserem Cisco Catalyst 9500 System mit IOS-XE) beispielsweise so aus:
</p>
<pre class="code">interface Vlan999
ipv6 address 2001:DB8:123:456::1/64
ipv6 nd prefix default 900 300 no-autoconfig
ipv6 nd managed-config-flag
ipv6 dhcp relay destination 2001:DB8:123:456::DACB
ipv6 dhcp relay destination 2001:DB8:123:456::DACC
ipv6 verify unicast source reachable-via rx allow-default</pre>
<p>
Hier ist lediglich ein Auszug der VLAN-Konfiguration dargestellt und es handelt sich um fiktive Daten. Man kann aber erkennen, dass die beiden Relay-Destinations (zweit- und drittletzte Zeile) auf Adressen innerhalb des selben VLANs zeigen (vgl. IPv6-Adresse in der zweiten Zeile). Die Relay-Destinations sind DHCPv6-Server.
</p>
<p>
Diese Konfiguration geht genau so lange gut, bis man mindestens einen der DHCPv6-Server einschaltet. Und das ist neun Tage später, am 09.04.2025 um 11:09 Uhr passiert. Ab dann kam es zum sogenannten Packet Loop. Systeme aus dem VLAN versuchten, den DHCPv6-Server unter der Multicast-Adresse <code>ff02::1:2</code> zu erreichen. Der Router empfing das Paket, weil er auf der Multicast-Adresse mit hörte (wegen der konfigurierten Relays). Das Paket wurde dann an alle Relays weiter geleitet mit dem eingebetteten Hinweis, dass das Antwortpaket wieder zurück zum Router muss. Und dann ging es aufgrund eines Logikfehlers im Betriebssystem des Routers im Kreis: wieder an die DHCPv6-Server und zurück an den Router und wieder an die DHCPv6-Server und zurück an den Router und so weiter und so fort. Das ganze passierte natürlich nicht nur mit einem sondern mit zahlreichen Paketen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Was im Detail geschah","hid":"was_im_detail_geschah","codeblockOffset":0,"secid":2,"range":"837-2958"} -->
<h3 class="sectionedit3" id="wie_wir_dem_problem_auf_die_spur_kamen">Wie wir dem Problem auf die Spur kamen</h3>
<div class="level3">
<p>
Relativ schnell konnten wir heraus finden, dass einer unserer Datacenter-Router regelmäßig vom Netz ging. Seine OSPF-Anbindungen an das Campus-Routing brachen immer wieder zusammen. Auf diesen Router haben wir für den Notfall eine serielle Verbindung und können ihn auch erreichen wenn er seinen Dienst nicht mehr tut. So konnten wir heraus finden, dass der Router Probleme aufgrund seiner CPU-Last hatte. Auch den die Last verursachenden Prozess konnten wir identifizieren, wodurch schnell klar wurde, dass es sich um ein Problem im Zusammenhang mit DHCPv6-Relays handeln musste. Nur gab das Protokoll des Routers leider keine hilfreichen Informationen.
</p>
<p>
Wir gingen dann nach dem Prinzip der Intervallschachtelung vor und deaktivierten zunächst alle VLANs, die auch IPv6 konfiguriert haben. Das Problem verschwand. Nun schalteten wir so lange Teile der VLANs wieder ein bis das Problem erneut auftrat. Als das Problem wieder kam schalteten wir noch einmal Teile der VLANs ab und wiederholten das Prinzip so lange bis wir die Ursache in einem einzigen VLAN ausmachen konnten. Dort war der Konfigurationsfehler dann schnell erkannt und beseitigt.
</p>
</div>
<!-- EDIT{"target":"section","name":"Wie wir dem Problem auf die Spur kamen","hid":"wie_wir_dem_problem_auf_die_spur_kamen","codeblockOffset":1,"secid":3,"range":"2959-4160"} -->
<h3 class="sectionedit4" id="warum_die_auswirkungen_so_umfangreich_waren">Warum die Auswirkungen so umfangreich waren</h3>
<div class="level3">
<p>
Das ist ganz einfach: Wenn <abbr title="Domain Name System">DNS</abbr> nicht funktioniert, klappt nichts.
</p>
<p>
Das Routing für einen der beiden zentralen <abbr title="Domain Name System">DNS</abbr>-Caches der RUB, nämlich für <code>ns1.ruhr-uni-bochum.de</code> (<code>134.147.32.40</code> bzw. <code>2a05:3e00:1:1003::32:40</code>), befand sich auf dem betroffenen Router. Dieser <abbr title="Domain Name System">DNS</abbr>-Cache war meistens nicht erreichbar. Der weitere <abbr title="Domain Name System">DNS</abbr>-Cache <code>ns2.ruhr-uni-bochum.de</code> (<code>134.147.222.4</code> bzw. <code>2a05:3e00:9:1001::222:4</code>) wird aus guten Gründen über einen anderen Router ans Netz angebunden und war durchgehend erreichbar.
</p>
<p>
<abbr title="Domain Name System">DNS</abbr> hat jedoch die Eigenart, dass der Client entscheidet, welcher der konfigurierten <abbr title="Domain Name System">DNS</abbr>-Server verwendet wird. Und je nach Client-Implementierung und -Konfiguration werden entweder alle konfigurierten <abbr title="Domain Name System">DNS</abbr>-Server wechselweise gefragt (round-robin) oder - was im Allgemeinen die Standardeinstellung ist - es wird nur einer der konfigurierten <abbr title="Domain Name System">DNS</abbr>-Server und im Fehlerfall bzw. bei Timeout der zweite <abbr title="Domain Name System">DNS</abbr>-Server gefragt. Dadurch, dass <code>ns1.ruhr-uni-bochum.de</code> zwischenzeitlich immer wieder für einige Sekunden erreichbar war, wurde auf den Clients oft der Timer für's Umschwenken auf den alternativen <abbr title="Domain Name System">DNS</abbr>-Server zurück gesetzt, so dass nicht zuverlässig der alternativ konfigurierte <abbr title="Domain Name System">DNS</abbr>-Server benutzt wurde. Diese Problematik ist nur durch Anycast-<abbr title="Domain Name System">DNS</abbr> nachhaltig lösbar, was an der RUB allerdings nicht eingesetzt wird.
</p>
<p>
Auch Server benutzen <abbr title="Domain Name System">DNS</abbr> um mit anderen Systemen (z.B. Datenbanken, Speichersysteme etc.) zu kommunizieren. Diese Verbindungen funktionieren ohne <abbr title="Domain Name System">DNS</abbr> oft auch nicht lange, so dass es beispielsweise auch zu im Nachgang noch länger andauernden Zugriffsproblemen auf Mailaccounts kam. Viele weitere Systeme waren ebenfalls betroffen.
</p>
<p>
Wir haben während des Troubleshootings das Routing für <code>ns1.ruhr-uni-bochum.de</code> händisch auf einen anderen Router umgezogen, so dass die <abbr title="Domain Name System">DNS</abbr>-Caches beide wieder zuverlässig erreichbar wurden. Aber auch dies brauchte ein wenig Zeit, denn dabei wollten wir uns natürlich keine weiteren Konfigurationsfehler erzeugen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Warum die Auswirkungen so umfangreich waren","hid":"warum_die_auswirkungen_so_umfangreich_waren","codeblockOffset":1,"secid":4,"range":"4161-6217"} -->
<h3 class="sectionedit5" id="was_wir_daraus_mit_genommen_haben">Was wir daraus mit genommen haben</h3>
<div class="level3">
<p>
Es hat uns erstaunt, dass dieser vergleichsweise kleine Packet Loop zu so hoher Last und darüber hinaus auch noch zu Folgen im Routing führen konnte. Wir müssen prüfen, warum es diesen Zusammenhang gibt und wie er verhinderbar ist.
</p>
<p>
Man kann sich jetzt aussuchen auf wen man mit dem Finger zeigen will. Dem Netzbetreuer ist jedenfalls nichts vorzuwerfen, er hat sich korrekterweise an uns gewendet und um eine Änderung der Konfiguration seines VLANs gebeten. IT.SERVICES betreibt zwar das <abbr title="Domain Name System">DNS</abbr>-System der RUB, aber auch dieses ist nicht Ursache des Problems, es war lediglich mit betroffen. Wir können uns jedoch den Schuh anziehen, dass wir die Sinnhaftigkeit der Konfigurationsänderung nicht ordentlich geprüft haben. Letztendlich kam es aber hier zum Ausfall aller Anbindungen eines Routers aufgrund eines einzigen Prozesses, der hohe CPU-Last verursacht hat. Unserer Auffassung nach handelt es sich hier um ein Design-Problem im Betriebssystem des Routers.
</p>
</div>
<!-- EDIT{"target":"section","name":"Was wir daraus mit genommen haben","hid":"was_wir_daraus_mit_genommen_haben","codeblockOffset":1,"secid":5,"range":"6218-"} -->text/html2023-09-28T15:19:30+00:00Robin DärmannDetails zum Routerausfall des Vormittags
https://noc.rub.de/web/blog/2023/routerausfall_zentralachse
<h2 class="sectionedit1" id="details_zum_routerausfall_des_vormittags">Details zum Routerausfall des Vormittags</h2>
<div class="level2">
<p>
Heute (28.09.2023) gegen 10:20 Uhr kam es zum Umschwenken eines Routers für den Bereich Zentralachse und M-Reihe. Das eigentlich redundant ausgelegte System verhielt sich danach nicht so wie konfiguriert und es kam zum Ausfall einiger VLANs.
</p>
<p>
Die Analyse des Fehlers nahm zunächst einige Minuten in Anspruch und wir entschieden dann, den Router spontan durch das bereits vorkonfigurierte Gerät der neueren Generation zu ersetzen. Der Austausch wäre ansonsten ohnehin für die nächste Woche geplant worden und eine Fehlerbehebung im alten System hätte ähnlich viel Zeit benötigt.
</p>
<p>
Betroffen waren über eine Dauer von ca. 30 Minuten alle VLANs, die nicht ausschließlich am betroffenen Router anliegen sondern auch auf anderen Bereichen des Campus verfügbar sind. Seit einigen Jahren sind wir bestrebt, diese VLANs abzuschaffen bzw. für Alternativen zu sorgen. Weitere VLANs, welche nur im Bereich Zentralachse sowie M-Reihe eingesetzt werden, waren sekunden- oder minutenweise betroffen.
</p>
<p>
Gegen 10:45 Uhr haben wir dann also vor Ort im Gebäude MA alle ca. 30 Verbindungen des Systems auf den neuen Router umgesteckt, welcher seitdem wie erwartet funktioniert. Um ca. 10:50 Uhr hatte sich der Normalzustand wieder hergestellt.
</p>
<p>
Da wir in den letzten Monaten gehäuft umfangreichere technische Probleme mit unserer Routerplattform aus dem Jahr 2017/2018 beobachten, haben wir bereits für Ersatz gesorgt und sind momentan dabei, alle entsprechenden Geräte durch neue Hardware zu ersetzen. Die Router der N- und G-Reihe sind bereits seit einigen Wochen ersetzt, die Router der Zentralachse und M-Reihe seit heute auch und die Router der I-Reihe sowie weitere sind aktuell in Vorbereitung. Im Datacenter ist bereits seit dem letzten Jahr ein neues Routersystem im Einsatz.
</p>
</div>
text/html2022-12-02T08:55:58+00:00Robin DärmannAbschaltung des Datennetzes während der verlängerten Weihnachtsschließung
https://noc.rub.de/web/blog/2022/abschaltung_jahreswechsel
<h2 class="sectionedit1" id="abschaltung_des_datennetzes_waehrend_der_verlaengerten_weihnachtsschliessung">Abschaltung des Datennetzes während der verlängerten Weihnachtsschließung</h2>
<div class="level2">
<p>
Folgende Ankündigung wurde am 01.12.2022 an die Netzbetreuer gesendet:
</p>
<!-- EDIT{"target":"plugin_wrap_start","hid":"","secid":2,"range":"0-"} --><div class="wrap_info plugin_wrap">
<p>
Während der verlängerten Weihnachtsschließung der RUB vom 24.12.2022 bis einschließlich 08.01.2023 werden die Gebäude der RUB geschlossen sein, so dass auch das Arbeiten vor Ort nicht gestattet ist. Daher werden konsequenterweise große Teile des Datennetzes auf dem Campus abgeschaltet sein. Das bedeutet, in den abgeschalteten Bereichen wird weder kabelgebundenes <abbr title="Local Area Network">LAN</abbr> noch drahtloses WLAN (eduroam, RUB-Guests etc.) zur Verfügung stehen.
</p>
<p>
Folgende Bereiche werden am Freitag, den 23.12.2022 ab 17 Uhr flächendeckend abgeschaltet:
</p>
<ul>
<li class="level1"><div class="li"> Gebäude IA, IB, IC, ID inkl. angrenzender Flachbereiche IAFO, IABF, ICFW, ICFO</div>
</li>
<li class="level1"><div class="li"> Gebäude GA, <abbr title="Gigabyte">GB</abbr>, GD (ausgenommen Serverraum GD/06/640) inkl. angrenzender Flachbereiche (GAFO, GABF, GBCF)</div>
</li>
<li class="level1"><div class="li"> Gebäude NB, NC, ND inkl. angrenzender Flachbereiche (NABF, NBCF, NCDF, NDEF)</div>
</li>
<li class="level1"><div class="li"> Gebäude MC</div>
</li>
</ul>
<p>
Am Sonntag, den 08.01.2023 werden wir die genannten Bereiche wieder in Betrieb nehmen.
</p>
<p>
Mit der Abschaltung dieser Bereiche leisten wir einen signifikanten Beitrag zum Einsparziel der RUB von 20% Energie aufgrund der Energie- und Finanzkrise.
</p>
<p>
Sollte es in den genannten Bereichen Gebiete geben, in denen aus wichtigen Gründen von einer Abschaltung des Datennetzes über einen längeren Zeitraum abgesehen werden sollte, wenden Sie sich bitte bis spätestens Montag, den 12.12.2022 mit ausführlicher Begründung an die Leitung des Dezernats 5.I.
</p>
</div><!-- EDIT{"target":"plugin_wrap_end","hid":"","secid":3,"range":"0-"} -->
</div>
<h4 id="weitere_informationen">Weitere Informationen</h4>
<div class="level4">
<p>
Wir werden in den genannten Gebäuden und Bereichen größtenteils unsere Datennetzverteiler stromlos schalten, d.h. die Access-Switche werden komplett abgeschaltet, so dass an den Endgeräten auch kein Ethernet-Link mehr zustande kommt. Wir rechnen zwar mit vereinzelten Ausfällen beim Wiedereinschalten, jedoch sind wir zuversichtlich, diese zeitnah beheben zu können, so dass am Montag, den 09.01.2023 wieder wie gewohnt gearbeitet werden kann. Wir kennen das alle von den Notstromproben.
</p>
<p>
Teilweise ist es nicht hinreichend einfach möglich, einzelne Etagenverteiler stromlos zu schalten, so dass diese dann weiter laufen werden und auch Ethernet-Links zustande kommen. Allerdings werden die vorgeschalteten Komponenten (Aggregation-Switches etc.) teilweise abgeschaltet sein, so dass in einigen Fällen keine Netzwerkkommunikation möglich sein wird. Die vorgeschalteten Komponenten haben auch einen recht hohen Stromverbrauch, insofern ergibt das trotzdem durchaus Sinn.
</p>
<p>
Ein einzelner Access-Switch verbraucht im Betrieb je nach Alter und Beschaffenheit zwischen ca. 40 und 150 Watt, größere Geräte und PoE-Switche bis zu 450 Watt. In jedem Etagenverteiler (typischerweise zwei pro Etage, in den Gebäuden ID und GD vier pro Etage) sind bis zu 17 Access-Switche verbaut, Spitzenreiter ist hier das Gebäude IC mit insgesamt 433 Access-Switches. Dazu kommen pro Gebäude mehrere Aggregation-Switches, die alle Etagenverteiler miteinander verbinden. Diese verbrauchen mindestens 500 Watt pro Stück. Pro Gebäudereihe gibt es auch noch mindestens ein Router-Pärchen, dort liegt der Verbrauch bei bis zu 4.000 Watt. WLAN-Access-Points verbrauchen zwischen ca. 10 und 30 Watt, je nach Alter und Modell. In den genannten Bereichen sind insgesamt mehrere tausend Switche sowie über 2.200 WLAN-Access-Points verbaut. Es kommt hier also einiges zusammen.
</p>
<p>
Sollte es in einzelnen Bereichen nötig sein, einen Teil des Datennetzes eingeschaltet zu lassen, müssen wir auch die Infrastruktur davor (Aggregation-Switch des Gebäudes, Gebäudehauptverteiler, Gebäudereihen-Router etc.) eingeschaltet lassen. Das sind vergleichsweise große Verbraucher, wir wollen das also nur aus wichtigen Gründen tun. Und da fallen uns ehrlich gesagt nicht viele Gründe ein. Server bzw. Maschinen, auf die aus dem HomeOffice zugegriffen werden muss, sollten bereits in den Serverstellflächen der Gebäude oder im Datacenter untergebracht sein, insbesondere vor dem Hintergrund drohender Teilschließungen oder eines Blackouts. Diese Bereiche werden selbstverständlich nicht von der Abschaltung betroffen sein und auch im Krisenfall bevorzugt versorgt werden.
</p>
</div>
text/html2022-11-14T10:20:44+00:00Andreas JobsWebseiten veröffentlichen mit Gitlab
https://noc.rub.de/web/blog/2022/webseiten_mit_gitlab
<h2 class="sectionedit1" id="webseiten_veroeffentlichen_mit_gitlab">Webseiten veröffentlichen mit Gitlab</h2>
<div class="level2">
<p>
Gitlab kann u.a. auch dafür verwendet werden, Webauftritte mit eigenem Editor-Workflow zu erstellen bzw. zu managen. Dazu bietet Gitlab standardmäßig das <em>Pages</em> Feature an. Hierbei wird das Ergebnis, der fertige Webauftritt, unter der <em>Pages-<abbr title="Uniform Resource Locator">URL</abbr></em>
</p>
<pre class="code">https://BENUTZER.io.noc.ruhr-uni-bochum.de/PROJEKTNAME</pre>
<p>
bzw.
</p>
<pre class="code">https://GRUPPENNAME.io.noc.ruhr-uni-bochum.de/PROJEKTNAME</pre>
<p>
veröffentlicht. Mit einfachen Mitteln kann die verwendete CI/CD-Pipeline, die für die Erstellung der Webseiten sorgt, so erweitert werden, dass diese auf einem entfernten Server veröffentlicht werden.
</p>
</div>
<!-- EDIT{"target":"section","name":"Webseiten ver\u00f6ffentlichen mit Gitlab","hid":"webseiten_veroeffentlichen_mit_gitlab","codeblockOffset":0,"secid":1,"range":"11-646"} -->
<h3 class="sectionedit2" id="eckdaten_und_voraussetzungen">Eckdaten und Voraussetzungen</h3>
<div class="level3">
<p>
Um die fertigen Webseiten auf dem entfernten Server zu veröffentlichen wird ein SSH-Zugang zu diesem Server benötigt, da nicht die „normalen“ Zugangsdaten für diesen Server verwendet werden sollen (die Zugangsdaten müssen auf dem Gitlab-Server hinterlegt werden). Vollständiger Shell-Zugang mit installiertem rsync wäre optimal, in diesem Beispiel steht aber nur der minimale SFTP Zugang zur Verfügung.
</p>
<p>
Für das Beispiel wird mein Gitlab-Projekt <em>talks</em> verwendet, in dem ich viele meiner Vorträge archiviert habe, mit dem Ziel diese auf dem Homepage-Server der RUB zu veröffentlichen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Eckdaten und Voraussetzungen","hid":"eckdaten_und_voraussetzungen","codeblockOffset":0,"secid":2,"range":"647-1285"} -->
<h3 class="sectionedit3" id="zugang_ermoeglichen">Zugang ermöglichen</h3>
<div class="level3">
<p>
Damit nicht die normalen Zugangsdaten für den Hompepage-Server im Gitlab hinterlegt werden müssen, wird ein SSH-Schlüsselpaar für genau diesen Zweck erzeugt:
</p>
<pre class="code">user@work:~$ ssh-keygen -t ed25519 -C 'GitLab deployment key'
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519): gitlab-deployment
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in gitlab-deployment
Your public key has been saved in gitlab-deployment.pub
The key fingerprint is:
SHA256:FtulN3htxaX0VwaZixcYDOZ1nMT0q7xMH4iiL0x8rAc GitLab deployment key
The key's randomart image is:
+--[ED25519 256]--+
| oooB*=+|
| o .ooB*o|
| . . ...o*|
| + +..o.o|
| . S + +.o. |
| E o oooo |
| o +. . = . |
| +... o o .|
| .+. o . |
+----[SHA256]-----+</pre>
<p>
Der Public-Key wird in der Datei <code>authorized_keys</code> im <code>.ssh</code> Unterverzeichnis im Homeverzeichnis auf dem Homepage-Server hinterlegt. Ein Test soll zeigen, ob der Zugang funktioniert. Der Befehl
</p>
<p>
sftp -i gitlab-deployment <em>loginid</em>@homepage.ruhr-uni-bochum.de
</p>
<p>
sollte ohne Passwort-Abfrage direkt mit dem Homepage-Server verbinden.
</p>
</div>
<!-- EDIT{"target":"section","name":"Zugang erm\u00f6glichen","hid":"zugang_ermoeglichen","codeblockOffset":0,"secid":3,"range":"1286-2558"} -->
<h3 class="sectionedit4" id="gitlab_projekt_modifizieren">Gitlab Projekt modifizieren</h3>
<div class="level3">
<p>
Der Private-Key wird auf dem Gitlab-Server hinterlegt. Im Gitlab-Projekt wird dazu in <strong>Settings</strong> → <strong>CI/CD</strong> → <strong>Variables</strong> → <strong>Expand</strong> mittels <strong>Add Variable</strong> eine neue Variable mit dem Namen <code>SSH_PRIVATE_KEY</code> angelegt. In das Feld <em>Value</em> kann anschließend der Inhalt der vorhin erzeugten Datei <code>gitlab-deployment</code> kopiert werden. Zusätzlich werden noch drei weitere Variablen angelegt, um die Konfiguration vom Repository zu trennen:
</p>
<ul>
<li class="level1"><div class="li"> <strong>SSH_HOST</strong>: <code>homepage.ruhr-uni-bochum.de</code></div>
</li>
<li class="level1"><div class="li"> <strong>SSH_USER</strong>: <em>LoginID</em></div>
</li>
<li class="level1"><div class="li"> <strong>TARGET_DIR</strong>: Zielverzeichnis (in diesem Beispiel <code>talks</code>)</div>
</li>
</ul>
<p>
Die Steuerdatei für das CI/CD (<code>.gitlab-ci.yml</code>) wird jetzt wie folgt erweitert (alles innerhalb des <code>pages:</code> Blocks):
</p>
<p>
Ein <code>before-script:</code> Block wird erstellt oder der vorhandene um die folgenden Zeilen erweitert:
</p>
<pre class="code"> - eval $(ssh-agent -s)
- echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add -</pre>
<p>
und im <code>script:</code> Block wird ganz unten der Befehl für die Auslieferung hinzugefügt:
</p>
<pre class="code"> - lftp -u ${SSH_USER}, -e "mirror -R ${CI_PROJECT_DIR}/public/ ${TARGET_DIR}/; quit" sftp://${SSH_HOST}</pre>
<p>
Die komplette Steuerdatei sieht im Beispielprojekt dann wie folgt aus:
</p>
<pre class="code">pages:
stage: deploy
before_script:
- eval $(ssh-agent -s)
- echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add -
script:
- make -f rules pages
- lftp -u ${SSH_USER}, -e "mirror -R ${CI_PROJECT_DIR}/public/ ${TARGET_DIR}/; quit" sftp://${SSH_HOST}
artifacts:
paths:
- public
only:
refs:
- master
changes:
- public/*
- PDF/*
tags:
- pages</pre>
<p>
Sobald jetzt Änderungen übermittelt (<code>git commit</code> / <code>git push</code>) werden, wird auch die Zielseite immer aktualisiert.
</p>
</div>
<!-- EDIT{"target":"section","name":"Gitlab Projekt modifizieren","hid":"gitlab_projekt_modifizieren","codeblockOffset":1,"secid":4,"range":"2559-4342"} -->
<h3 class="sectionedit5" id="das_ergebnis">Das Ergebnis</h3>
<div class="level3">
<ul>
<li class="level1"><div class="li"> <a href="https://ajobs.io.noc.ruhr-uni-bochum.de/talks" class="urlextern" title="https://ajobs.io.noc.ruhr-uni-bochum.de/talks" rel="ugc nofollow">https://ajobs.io.noc.ruhr-uni-bochum.de/talks</a></div>
</li>
</ul>
<p>
sieht exakt aus wie
</p>
<ul>
<li class="level1"><div class="li"> <a href="https://homepage.ruhr-uni-bochum.de/andreas.jobs/talks" class="urlextern" title="https://homepage.ruhr-uni-bochum.de/andreas.jobs/talks" rel="ugc nofollow">https://homepage.ruhr-uni-bochum.de/andreas.jobs/talks</a></div>
</li>
</ul>
</div>
<!-- EDIT{"target":"section","name":"Das Ergebnis","hid":"das_ergebnis","codeblockOffset":4,"secid":5,"range":"4343-"} -->text/html2022-10-18T14:40:55+00:00Robin DärmannÜber das Umschiffen von Hardware-Klippen neuerer Netzkomponenten
https://noc.rub.de/web/blog/2022/hardware-klippen
<h2 class="sectionedit1" id="ueber_das_umschiffen_von_hardware-klippen_neuerer_netzkomponenten">Über das Umschiffen von Hardware-Klippen neuerer Netzkomponenten</h2>
<div class="level2">
<p>
Obwohl der meiste Datenverkehr im RUB-Netzwerk in den einzelnen Gebäuden entsteht, erfolgt doch das Routing der meisten Netze im Datacenter. Das hat teilweise historische Gründe, teilweise technische oder einfach praktische Gründe. Der Router im Datacenter ist wie fast alle unserer Router redundant ausgelegt, das heißt es gibt ihn doppelt. Das war schon früher im Interims-Datacenter so und ist auch im neuen Datacenter so umgesetzt. Beim Ausfall eines der beiden Systeme übernimmt das andere System fast unterbrechungsfrei, ohne, dass das im Allgemeinen von den Nutzern bemerkt wird.
</p>
<p>
Da unsere bisher eingesetzte Router-Plattform (Cisco Catalyst 6807-XL/SUP6T) inzwischen herstellerseitig abgekündigt ist, haben wir für das neue Datacenter zwei Maschinen der Nachfolge-Serie „Catalyst 9000“ angeschafft, und zwar zwei Geräte vom Typ C9500-48Y4C. Sie sind im Mai 2022 in Betrieb gegangen und haben schrittweise das Routing vom bisherigen Datacenter-Router übernommen. Dieser Prozess ist bis heute immernoch nicht vollständig abgeschlossen. Und zwar aus Gründen:
</p>
<p>
Neuere Geräte der Catalyst-9000-Serie arbeiten im Detail etwas anders als die bisher von uns eingesetzten Systeme. Das ist nicht weiter ungewöhnlich, äußert sich jedoch darin, dass der Hersteller inzwischen am teuren TCAM-Speicher spart, welcher unter anderem für den besonders effizienten Zugriff auf Routen und ACLs notwendig ist. Ohne diese Effizienz kann das System nicht performant arbeiten. Diese Sparmaßnahmen sind erst einmal kein grundsätzliches Problem, denn viele Dinge werden in den ASICs („Application Specific Integrated Circuit“ bzw. spezielle Hardware-Chips) der Geräte inzwischen anders abgebildet und verarbeitet, so dass grundsätzlich nicht mehr so viel TCAM-Speicher wie bisher benötigt wird.
</p>
<p>
So weit, so gut. Nun ist es aber so, dass man die neueren Systeme dahin gehend optimieren kann (und in unserem Fall auch muss), dass die Speicheraufteilung innerhalb des Systems zum Nutzungsprofil passt, da die Aufteilung starr ist. Das heißt, es muss Speicher für MAC-Adressen, IP-Adressen und einige weitere Dinge quasi fest zugewiesen werden. Die Standard-Aufteilung funktioniert in einem Szenario der Größenordnung RUB natürlich nicht.
</p>
<p>
Und dafür muss man leider das komplette System neu starten.
</p>
<p>
Punkt.
</p>
<p>
Das bedeutet: nicht umschwenken auf das redundante System, nicht nacheinander beide Systeme einmal durchstarten, sondern beide Systeme gleichzeitig neu starten.
</p>
<p>
Netzausfall: ca. 10 Minuten.
</p>
<p>
Und genau dieser Fall muss kommende Nacht bei uns eintreten. Es gibt nämlich seit gestern Nachmittag ein Kapazitätsproblem im Bereich des zugewiesenen Speichers für IP-Routen, was vergangene Nacht gegen 4 Uhr schon einmal zu Erreichbarkeitsproblemen im Netz geführt hat. Die Ursache ist uns prinzipiell klar, den genauen Grund dafür erforschen wir aktuell noch, aber wir müssen erst einmal Abhilfe schaffen, damit die Stabilität des Routings nicht weiter gefährdet ist. Denn läuft der Speicher voll, herrscht quasi Stillstand im Netz der RUB. Und das möchte niemand wirklich.
</p>
<p>
Ankündigung folgt…
</p>
</div>
text/html2022-09-19T08:41:32+00:00Robin DärmannVeränderungen im Wireless LAN
https://noc.rub.de/web/blog/2022/veraenderungen_im_wlan
<h2 class="sectionedit1" id="veraenderungen_im_wireless_lan">Veränderungen im Wireless LAN</h2>
<div class="level2">
<p>
<strong><abbr title="Too long; didn't read">TL;DR</abbr>:</strong> Es wird ab morgen Vormittag (20.09.2022) ein neues, zusätzliches WLAN <code>RUB-Guests</code> geben. Die SSIDs <code>RUB-WLAN</code> und <code>RUB-EVENT-WPA</code> werden mittelfristig weg fallen.
</p>
<p>
Wer sich schon länger an der RUB aufhält, kann sich vielleicht an die Anfänge des WLAN erinnern. Man nutzte das RUB-WLAN um sich drahtlos zu verbinden und im Netzwerk der RUB zu kommunizieren oder startete einen VPN-Tunnel. Dann kam Eduroam mit etwas komplizierterer Konfiguration der Endgeräte, verbunden jedoch mit dem Vorteil, das Gerät ohne Änderung der Konfiguration auch an anderen Universitäten nutzen zu können. Das geht mittlerweile weltweit. Die dahinter stehende Infrastruktur ist eher komplex, aber durchaus seine Vorteile wert.
</p>
<p>
Es kommen aber auch Gäste ohne eigenen Zugang zum Eduroam and die RUB. Ihnen drahtlosen Zugang zum Internet zu verschaffen ist aufwändig. Man kann dafür in einigen Bereichen der RUB die SSID <code>RUB-EVENT-WPA</code> benutzen, die praktisch ein drahtloser HIRN-Port ist. Auch dieses Verfahren funktioniert auf vielen Endgeräten nicht einwandfrei weil sich technisch viel getan hat in den letzten Jahren.
</p>
<p>
Wir werden daher in den nächsten Tagen damit beginnen, eine neue SSID namens <code>RUB-Guests</code> auszustrahlen, in der zwar immernoch eine Anmeldung mit LoginID nötig ist [1], jedoch technisch so konstruiert, dass moderne Endgeräte die Anmeldung auch automatisch anzeigen und so die Prozedur einfacher vonstatten geht. Das Stichwort ist hier „Captive Portal“, das heißt man bekommt im Regelfall automatisch die Login-Seite gezeigt, wenn man sich mit dem WLAN verbindet, und ist dann mit diesem Endgerät für eine bestimmte Zeit frei geschaltet. Man kennt das beispielsweise aus Hotels oder öffentlichen Hotspots.
</p>
<p>
Ein Betatest ist bisher erfolgreich verlaufen. <code>RUB-Guests</code> wird zunächst in den meisten Bereichen als zusätzliche SSID ausgestrahlt, später jedoch die beiden bekannten SSIDs <code>RUB-WLAN</code> und <code>RUB-EVENT-WPA</code> ersetzen. <code>eduroam</code> bleibt selbstverständlich unverändert bestehen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Ver\u00e4nderungen im Wireless LAN","hid":"veraenderungen_im_wireless_lan","codeblockOffset":0,"secid":1,"range":"1-2082"} -->
<h3 class="sectionedit2" id="ein_kurzer_blick_auf_die_technik">Ein kurzer Blick auf die Technik</h3>
<div class="level3">
<p>
Verbindet man sich über die WLAN-Infrastruktur der RUB mit der SSID <code>RUB-Guests</code>, so bekommt man vom WLAN-Controller ein sogenanntes „registration VLAN“ zugewiesen. Innerhalb dieses VLANs ist lediglich der Zugriff auf <a href="https://hirn.rub.de/" class="urlextern" title="https://hirn.rub.de/" rel="ugc nofollow">https://hirn.rub.de/</a> möglich. Unter dieser <abbr title="Uniform Resource Locator">URL</abbr> wird die Login-Seite angezeigt. Sie öffnet sich auch auf gängigen Geräten automatisch.
</p>
<p>
Nach dem Login wird vom RADIUS-Server mit einem Mechanismus namens CoA („Change of Authority“) an den WLAN-Controller signalisiert, dass dieser dem Client (mobiles Endgerät) ein anderes VLAN zuweisen soll. In diesem ist dann der Zugriff nicht mehr auf die Login-Seite beschränkt.
</p>
<p>
Der Client bekommt dank sehr kurzer Lease-Time innerhalb von ein paar Sekunden eine neue IPv4-Adresse und nach dem VLAN-Wechsel auch eine IPv6-Adresse zugewiesen.
</p>
<p>
Nach erfolgtem Login sind noch folgende URLs nützlich:
</p>
<ul>
<li class="level1"><div class="li"> <a href="https://hirn.rub.de/status" class="urlextern" title="https://hirn.rub.de/status" rel="ugc nofollow">https://hirn.rub.de/status</a>: Zeigt nach erneutem Login alle Geräte an, die mit der entsprechenden LoginID aktuell eingeloggt sind. Man hat hier auch die Möglichkeit, Geräte auszuloggen.</div>
</li>
<li class="level1"><div class="li"> <a href="https://hirn.rub.de/networklogoff" class="urlextern" title="https://hirn.rub.de/networklogoff" rel="ugc nofollow">https://hirn.rub.de/networklogoff</a>: Bietet die Möglichkeit, sich mit dem aktuellen Gerät auszuloggen.</div>
</li>
</ul>
<p>
Der IPv4-Zugriff ins Internet erfolgt nach dem Login so wie mittlerweile auch an HIRN-Ports via NAT. RUB-intern findet keine NAT statt.
</p>
<p>
[1]: Zugangsdaten für das RUB-Netzwerk kann man, auch als Gast, bei IT.SERVICES im Servicecenter (IA/0/150) bekommen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Ein kurzer Blick auf die Technik","hid":"ein_kurzer_blick_auf_die_technik","codeblockOffset":0,"secid":2,"range":"2083-"} -->text/html2022-08-13T18:34:07+00:00Andreas JobsNetzwerkanalyse im Hochschulinternen Rechnernetz
https://noc.rub.de/web/blog/2022/netzwerkanalyse_mit_erspan
<p>
Einer unserer Kunden machte uns darauf aufmerksam, dass es möglicherweise Paketverluste im Hochschulinternen Rechnernetz (HIRN) gibt. Das Szenario stellte sich wie folgt dar: Der Monitorserver des Kunden sendet ICMP echo requests an viele Zielrechner und wertet dann die Antworten aus. Das Fehlerbild ergab erst einmal kein Muster, da eine Vielzahl von Zielen mit unterschiedlichen Fehlerraten betroffen waren.
</p>
<p>
Wir mussten jetzt also die Frage klären wo, wann und warum diese Fehler auftreten. Da sich der Quellrechner im Datacenter befindet, sind wir in der Lage mittels ERSPAN den Datenverkehr direkt an einem Switchport zu analysieren.
</p>
<p>
ERSPAN steht für „Encapsulated Remote Switched Port Analyzer“ und man ist damit in der Lage den zu analysierenden Datenverkehr an eine beliebige Stelle zu transportieren und zentral zu analysieren.
</p>
<p>
Auf dem Analyserechner wird als erstes das packet-capture gestartet und alles eingesammelt, was GRE-gekapselt ist:
</p>
<pre class="code">tcpdump -i vtnet0 -n -C 2000 -w case-4711 "ip proto 0x2f"</pre>
<p>
Da auf der Quellseite wenig Filtermöglichkeiten bestehen, werden die gesammelten Daten in 2-Gigabyte-Blöcke aufgeteilt und später gefiltert.
</p>
<p>
Die Quelle ist ein physischer Server, der direkt an einen Switch des HIRN angeschlossen ist. Dort wird eine ERSPAN-Quelle eingerichtet:
</p>
<pre class="code">monitor session 1 type erspan-source
description analyze-case-4711
erspan-id 30
vrf default
destination ip 192.168.2.227
source interface port-channel51 both</pre>
<p>
Für einen der Tests wurde die Monitor-Session für 2 Stunden aktiviert. Aus den gesammelten Daten werden alle Pakete entfernt, die nicht ICMP oder ICMPv6 enthalten und dann in einem packet-capture zusammengefasst:
</p>
<pre class="code">for f in case-13* ; do tshark -r $f -w tmp_$f -Y "icmp or icmpv6"; done
mergecap -w case-13-icmp.pcap tmp_case-13*
rm tmp_case-13*</pre>
<p>
Aus dem resultierenden packet-capture sucht man sich jetzt alle ICMP echo requests heraus und ermittelt (via IP/ID/SEQ) zu jedem das passende echo reply. Die Nutzung von tshark hat hier zwei entscheidende Vorteile:
</p>
<p>
Zum einen entpackt tshark bei der Ausgabe auf STDOUT das GRE und das ERSPAN und zeigt direkt das Original-Paket von der Quelle an und zum anderen erledigt es auch gleich die Arbeit der o.g. Zuweisung von echo request zu echo reply. Eine Ausgabe sieht bspw. so aus:
</p>
<pre class="code">1229 1658404789.430723 2001:db8:e:edd1::34:133 → 2001:db8:9:edd0::232:204 ICMPv6 180 Echo (ping) request id=0xa669, seq=0, hop limit=64
1230 1658404789.430730 2001:db8:9:edd0::232:204 → 2001:db8:e:edd1::34:133 ICMPv6 180 Echo (ping) reply id=0xa669, seq=0, hop limit=63 (request in 1229)
7980 1658404802.744268 10.213.47.146 → 10.213.15.150 ICMP 160 Echo (ping) request id=0xa856, seq=0/0, ttl=64
7983 1658404802.744321 10.213.15.150 → 10.213.47.146 ICMP 160 Echo (ping) reply id=0xa856, seq=0/0, ttl=127 (request in 7980)</pre>
<p>
Diese Ausgabe wird per Script entsprechend ausgewertet. Damit die Ausgabe übersichtlich bleibt werden folgenden Regeln angewendet:
</p>
<ul>
<li class="level1"><div class="li"> Requests für Hosts die gar keine Replys senden werden ignoriert (da steht i.d.R. die Firewall des Ziels auf „DROP“)</div>
</li>
<li class="level1"><div class="li"> Ein einzelner fehlender Reply (pro Zielhost) wird ignoriert</div>
</li>
</ul>
<p>
Damit ergibt sich dann etwa folgendes Bild:
</p>
<pre class="code">ICMP stats Test 13:
Start time: Thu Jul 21 13:59:49 2022
Stop time: Thu Jul 21 15:59:59 2022
# target hosts: 833
# requests: 62152 (65276)
# replies: 61618
Ratio: 99.14% (94.40%)
Hosts with more than one dropped packet:
2001:db8:9:ed1f::ac8:4604 20/125 84.00%
2001:db8:9:ed1f::ac8:460d 41/125 67.20%
2001:db8:9:ed1f::ac8:4802 95/115 17.39%
2001:db8:9:ed1f::ac8:480b 107/120 10.83%
2001:db8:9:ed1f::ac8:480c 45/130 65.38%
2001:db8:9:ed10::a93:298b 15/125 88.00%
2001:db8:9:ed10::a93:298c 25/130 80.77%</pre>
<p>
Bis auf sehr wenige Ausnahmen (7 von 833 Hosts) gibt es keine Paketverluste. Die auf dem Monitorserver auftretenden Paketverluste müssen also auf dem Monitorserver selbst passieren. Die Auswertung hat allerdings bei sieben Zielen teilweise massive Paketverluste gezeigt. Hier gilt es jetzt zu ermitteln wo auf dem Weg diese Pakete verloren gehen.
</p>
<p>
Da es sich in diesem Fall um eine virtuelle Maschine in einer VMware-Umgebung handelt kommen wir nicht so „nah“ an das Ziel wie bei einer physischen Maschine. Ausserdem hat die VMware-Umgebung zwei Standorte und damit zwei Anbindungen an das HIRN. Auf den Switches mit den VMware-Anbindungen wird wie oben beschrieben auch jeweils eine ERSPAN-Session eingerichtet, diesmal mit den IDs 32 und 33 und dann der Sammler und alle drei Sessions gestartet. Das Ergebnis erhält man schlußendlich in case-14-icmp.pcap.
</p>
<p>
In dieser Datei sind jetzt noch alle drei Monitor-Sessions enthalten. Für eine Auswertung teilen wir diese auf. Da es aktuell irrelevant ist, in welchem Teil der VMware-Umgebung sich der Zielhost befindet, teilen wir unser pcap in zwei Teile auf:
</p>
<pre class="code">tshark -r case-14-icmp.pcap -w case-14-icmp_src.pcap -Y "erspan.spanid == 30"
tshark -r case-14-icmp.pcap -w case-14-icmp_dst.pcap -Y "erspan.spanid != 30"</pre>
<p>
Wirft man diese beiden Paketmitschnitte dem Auswertungsscript vor, erhält man folgendes Bild:
</p>
<pre class="code">ICMP stats (test 14: tap at source):
Start time: Sun Jul 24 12:56:37 2022
Stop time: Sun Jul 24 13:20:02 2022
# target hosts: 837
# requests: 27408 (28318)
# replies: 27342
Ratio: 99.76% (96.55%)
Hosts with more than one dropped packet:
10.160.233.249 28/32 12.50%
192.168.85.135 28/32 12.50%
2001:db8:9:ed1f::ac8:460d 13/25 48.00%
2001:db8:9:ed1f::ac8:4802 21/25 16.00%
2001:db8:9:ed1f::ac8:480b 16/20 20.00%
2001:db8:9:ed1f::ac8:480c 10/25 60.00%
2001:db8:9:ed10::a93:298b 5/25 80.00%
---------------------------------------------------
ICMP stats (test 14: tap at destination vlan):
Start time: Sun Jul 24 12:56:41 2022
Stop time: Sun Jul 24 13:19:59 2022
# target hosts: 64
# requests: 1029 (1900)
# replies: 1009
Ratio: 98.06% (53.11%)
Hosts with more than one dropped packet:
2001:db8:9:ed10::a93:298b 5/25 80.00%</pre>
<p>
Auch diese Auswertung bestätigt, dass der Paketverlust nicht im HIRN stattfindet, sondern entweder in der Netzwerkinfrastruktur der VMware-Umgebung oder im Zielhost selbst.
</p>
text/html2022-06-30T17:19:20+00:00Andreas JobsÄnderung der Klientenkonfiguration des zentralen VPN-Zugangs
https://noc.rub.de/web/blog/2022/openvpn
<p>
Beim jährlichen Zertifikatwechsel ist in diesem Jahr leider etwas passiert, was eine Änderung der Konfiguration am Klienten erforderlich machte. Hier einige Erläuterungen zu den häufigsten (teilweise auch sehr unhöflichen) Fragen „<em>Warum muss die Klientenkonfiguration geändert werden</em>“ und „<em>Warum wurde das nur so kurzfristig angekündigt</em>“.
</p>
<p>
Dazu muss man etwas über die internen Vorgänge des VPN und der Zertifikatswechel wissen:<br/>
Bei uns sind alle aktiv verwendeten Zertifikate im Monitoring bzgl. des Ablaufzeitpunktes. 21 Tage vor Erreichen dieses Zeitpunkts wechelt der Status auf <em>WARNING</em> (im Falle des OpenVPN-Dienstes war das am Samstag, den 11.06.2022). Innerhalb der darauf folgenden Woche werden dann die entsprechenden Vorbereitungen getroffen und der eigentliche Wechselzeitpunkt festgelegt. Zu den Vorbereitungen gehören bspw. die Erzeugung neuen Schlüsselmaterials (wir recyclen keine privaten Schlüssel) und auch die schriftliche Beantragung eine (neuen) Zertifikats. Am Montag, den 20.06.2022 wurde dann der eigentliche Wechsel vollzogen. Anschließende Tests zeigten allerdings schnell, dass die VPN-Klienten keine VPN-Verbindung mehr aufbauen konnten und das alte Zertfikat wurde ersteinmal wieder reaktiviert.
</p>
<p>
Die Fehlerursache war schnell gefunden: Das <em><code>subject</code></em> des Zertifikats war falsch:
</p>
<ul>
<li class="level1"><div class="li"> C=DE, ST=Nordrhein-Westfalen, L=Bochum, O=Ruhr-Universitaet Bochum, OU=Network Operation Center, CN=ovpn.noc.ruhr-uni-bochum.de</div>
</li>
</ul>
<p>
vs
</p>
<ul>
<li class="level1"><div class="li"> C=DE, ST=Nordrhein-Westfalen, L=Bochum, O=Ruhr-Universitaet Bochum, CN=ovpn.noc.ruhr-uni-bochum.de</div>
</li>
</ul>
<p>
Ganz klarer Fall: <em><code>OU</code></em> im Certificate-Request vergessen.
</p>
<p>
Leider nicht. Im verwendeten Request wurde die <em><code>OU</code></em> korrekt angegeben. Selbst in der Antragsdatei steht die korrekt <em><code>OU</code></em>. Auf dem Papier (bzw. PDF) fehlt diese Angabe allerdings, genau wie im dann ausgestellten Zertifikat.
</p>
<p>
Leider war es nach Rücksprache mit den Kolleginnen, die die Zertifkate ausstellen auch nicht mehr möglich diese Stelle im Antrag zu modifizieren. Nach etwas Recherche haben wir auch den Grund gefunden: Policy-Änderung der DFN-PKI Global
</p>
<blockquote><div class="no">
DFN-PKI Global, zum 15.12.: Abschaffung OU für Serverzertifikate … <br/>
<br/>
- Anträge für Serverzertifikate, die ab 15.12. eingereicht werden, werden von uns so modifiziert, dass ein evtl. vorhandenes OU-Attribut (Organizational Unit, Abteilung) entfernt wird. Die ausgestellten Serverzertifikate enthalten kein OU.<br/>
…</div></blockquote>
<p>
Da Ganze nur mäßig kommuniziert wurde, die <em><code>OU</code></em> im Zertifikat verwendet wird <strong>und</strong> diese auch noch vom Klienten geprüft wird musste
</p>
<ul>
<li class="level1"><div class="li"> eine neue Klientenkonfiguration erstellt werden</div>
</li>
<li class="level1"><div class="li"> die mit beiden Zertifikaten klar kommt</div>
</li>
<li class="level1"><div class="li"> und das Ganze <em>pronto</em> (Zur Erinnerung: Wir haben bereits den 22.06.)</div>
</li>
</ul>
<p>
Wenn sich aber schon Möglichkeit bietet, dann ändern wir natürlich nicht nur diese eine Stelle, sondern überlegen auch
</p>
<ul>
<li class="level1"><div class="li"> Was wollen wir an anderen Verbesserungen zum Klienten pushen?</div>
</li>
<li class="level1"><div class="li"> Was ist ggf. noch alles für den nächsten Zertifikatswechel nötig?</div>
</li>
</ul>
<p>
und klären wer wie über welche Kanäle informiert (wird).
</p>
<p>
Nach einigem Hin-und-Her, Dokumentation lesen (sowohl openvpn als auch TCS) hatten wir eine neue Konfiguration mit
</p>
<ul>
<li class="level1"><div class="li"> einer Versionierung (macht es dem First-Level-Support einfacher)</div>
</li>
<li class="level2"><div class="li"> aktualisierten Sicherheitseinstellungen</div>
</li>
<li class="level2"><div class="li"> geänderten Einstellungen um Warungen zu vermeiden (vermeidet Fragen im FLS)</div>
</li>
<li class="level2"><div class="li"> das aktuelle DFN-CA und das zukünftige TCS-CA Zertifikat</div>
</li>
<li class="level2"><div class="li"> und die geänderte Prüfung des Serverzertifikats (darum geht's ja eigentlich)</div>
</li>
</ul>
<p>
sowie die ersten Tests erfolgreich abgeschlossen (sowohl mit der aktuellen Server-Konfiguration als auch mit der zukünftigen Server-Konfiguration). Allerdings war die Woche da auch rum (wir haben jetzt den 26.06.2022). Eine Woche ist unserer Erfahrung nach auch ein guter Zeitrahmen für solche Ankündigungen: Lange genug um es nicht sofort machen zu müssen und kurz genug um es nicht zu vergessen.
</p>
<p>
Ursprünglich sollte die Änderung mit dem Neustart am Samstag den 02.07.2022 um 06:00 Uhr durchgeführt werden. Nach Rücksprache mit dem Servicecenter von IT.SERVICES (die für uns der First-Level-Support übernehmen) haben wir den Zeitpunkt dann aber auf Freitag (01.07.2022) Vormittag verlegt (⇐ Hier könnten wir noch erwähnen warum; wegen der Leute die es bis zum schluss rauszögern und dann probleme haben; später können wir dann auch noch Ticket-Stats dazu packen). Diese Klärung war u.a. auch der Grund warum die Informationsmail erst in der Nacht von Montag auf Dienstag versendet wurde.
</p>
<p>
Stats: 61 Ticketrückfragen bei ~15000 E-Mails
</p>
text/html2022-03-15T13:38:06+00:00Tristan LohdeWLAN Ausbau - von der Planung bis zum Betrieb
https://noc.rub.de/web/blog/2022/wlan_ausbau
<p>
Das Thema „flächendeckender WLAN-Empfang“ ist auf dem Campus und in den Außenliegenschaften momentan sicherlich eines der am meisten diskutierten Themen.
</p>
<p>
In diesem Blog Eintrag möchten wir einmal chronologisch erklären welche Schritte unternommen werden, um in den Gebäuden, wie Hochbauten und auch Flachbereichen, flächendeckend WLAN (eduroam & RUB-WLAN) anbieten zu können.
</p>
<p>
Am Anfang steht wie immer die Planung, je nach Gebäude und Etage gestaltet sich diese unterschiedlich aufwändig.
In primär geisteswissenschaftlich genutzen Gebäuden, wie z.B. dem Gebäude GB ist die Planung und der Ausbau vergleichsweise unkompliziert: solange Kapazitäten und Wege, z.B. Kabeltrassen für die Leitungen vorhanden sind, werden hier typischerweise die Montageorte für 12 bis 16 Accesspoints auf den Fluren, in einem Abstand von ca. 12 bis 15m, geplant.
Im Zuge dieser Planung werden auch die Kabelwege und eventuell zu öffnende Brandschotte auf dem Weg in die Netzwerkunterverteilung festgehalten.
Etwas aufwändiger wird die Planung in Gebäuden, in denen es viele Labore und/oder Sicherheitsbereiche gibt (Beispiel N- und M-Reihe).
Hier wird typischerweise vorher mit dem Dekanat und den Nutzern abgeklärt, in welchem Bereich WLAN in welchem Umfang benötigt wird. In manchen Gebäuden wurde noch vor ein paar Jahren die Möglichkeit einer WLAN-Installation aus Angst vor Interferenzen mit hochsensibler Messtechnik entschieden abgelehnt. Auch können bauliche Hindernisse wie Blechwände o.ä. eine genauere Planung hinsichtlich der Positionierung der Accesspoints erfordern.
</p>
<p>
Nach der Planung durch unsere Abteilung erfolgt die Ausschreibung der Installationsarbeiten der passiven Infrastruktur. Diese Arbeiten umfassen die Installation von Datennetzdosen an den Bestimmungsorten und das Verlegen der Leitungen von den Dosen in die Datennetz-Etagenverteiler auf Basis unserer Planungsunterlagen.
Das Elektrounternehmen welches den Zuschlag auf die Ausschreibung erhalten hat, beginnt anschließend zu einem vereinbarten Termin mit den Installationsarbeiten. Neben den Datennetzdosen und den Zuleitungen werden in diesem Schritt auch schon die Halteplatten für die Accesspoints montiert.
</p>
<p>
Nach Abschluss des Aufbaus der passiven Infrastruktur beginnt die Planung und der Einbau der aktiven Komponenten.
In die Datennetz-Etagenverteiler (In den Hochhäusern sind es meist zwei pro Ebene - Nord & Süd) müssen zusätzlich PoE-fähige Switche installiert werden, welche die Accesspoints mit Datennetz und Spannung versorgen können.
Die PoE-Switche werden mit Uplinks auf die bestehenden Access-Switche versehen und die Datennetzdosen auf die Switchports gepatcht.
Auch bei den aktiven Komponenten ist jedoch vorher eine gewisse Planungs- und Vorbereitungsphase von Nöten:
Gerade in den „alten“ Gebäuden der G-, M- und N-Reihe sind die Datennetz-Etagenverteiler schon gut mit Patchfeldern, Patchkabeln und den regulären Access-Switchen gefüllt, daher muss je nach Platzbedarf und Anzahl der benötigten Anschlüsse ein PoE-Switch gewählt werden, welcher auch in den Datennetzschrank passt und gleichzeitig über die benötigte Anzahl an Anschlüssen/Ports und genügend PoE-Leistung verfügt.
</p>
<p>
Vor der Montage werden die PoE-Switche und Accesspoints mit einem Hostnamen versehen, in unserer Management-Software eingetragen und dadurch automatisiert nach dem Einschalten am Bestimmungsort mit IP-Adressen und Standardkonfigurationen versorgt; dieser hohe Grad an Automatisierung nimmt uns einen großen Teil der ansonsten händischen Konfiguration ab.
Anschließend folgen individuelle Konfigurationsschritte, wie das Setzen der korrekten Portbeschriftungen und das Schalten der benötigten Netze auf die Ports der neu hinzugefügten Switche.
(Info: der ungerade Port der Datennetzdosen im Flurbereich wird zusätzlich oft für die Geräte der elektronischen Schließanlage genutzt, welche dadurch über die selben Switche versorgt werden).
</p>
<p>
Die letztendliche Installation der Accesspoints stellt in unserem momentanen Arbeitsablauf den letzten Arbeitsschritt dar; durch die vorausgehenden Schritte ist dieser durch das einfache in-die-Halterung-schieben und Einstecken in die Datennetzdose schnell erledigt.
Der Accesspoint meldet sich anschließend selbständig an einem unserer Wireless-Controller an, führt ggf. ein Firmware-Update durch und ist nach spätestens 30 Minuten einsatzbereit.
</p>
<p>
Der „operational status“ wird auch durch die LED gekennzeichnet:
</p>
<ul>
<li class="level1"><div class="li"> Grün: Standby - zur Zeit ist kein Client verbunden</div>
</li>
<li class="level1"><div class="li"> Blau: Mindestens ein Client ist mit dem Accesspoint verbunden</div>
</li>
<li class="level1"><div class="li"> Schnelles Blaues blinken: Der Accesspoint führt ein Softwareupdate aus</div>
</li>
<li class="level1"><div class="li"> Alternierend Rot-Aus-Grün: Fehler! (hält dieser Status mehrere Tage an, bitte an <a href="mailto:noc@rub.de" class="mail" title="noc@rub.de">noc@rub.de</a> melden)</div>
</li>
<li class="level1"><div class="li"> Aus: Die Stromversorgung ist unterbrochen bzw. noch nicht aktiv (ACHTUNG: an manchen Standorten haben wir die LED bewusst deaktiviert, der Accesspoint funktioniert trotzdem!)</div>
</li>
</ul>
<p>
Ein Wort noch speziell zu Neubauten (z.B. ZESS) oder frisch sanierten Gebäuden/Bereichen (z.B. MC Ebene 0 & 1):
In diesen Gebäuden/Bereichen ist die WLAN Infrastruktur bereits seit Beginn fest eingeplant d.h. dass PoE-Switche in den Datennetz-Unterverteilungen und Datennetzdosen auf den Fluren oder in Seminarräumen schon vorhanden sind.
Diese Bereiche „leiden“ momentan jedoch an der immer noch anhaltenden Materialknappheit im Bereich der aktiven Netzwerkkomponenten.
Die Lieferzeiten für Switche und Accesspoints liegen teilweise immer noch bei mehr als einem Jahr.
Bestellungen für Komponenten sind aufgegeben, bis zur Auslieferung wird es aber noch eine Weile dauern.
Momentan orientieren wir uns beim WLAN-Ausbau an einer von der Dezernatsleitung vorgegeben Prioritätsliste. Das langfrisitge Ziel ist jedoch alle Bereiche, in denen es sinnvoll ist, mit WLAN auszustatten.
</p>
<p>
Ich hoffe dieser Blogeintrag hat die Arbeitsschritte und Abläufe, welche notwendig sind um den Campus und die Außenliegenschaften mit flächendeckenden WLAN zu versorgen, etwas transparenter gemacht.
</p>
<p>
Die folgende Grafik zeigt schematisch am Beispiel NC die typische räumliche Aufteilung der Netzwerkanbindung mit aktiven (Router, Switche, Access Points) und passiven (Kabel, Netzwerkdosen, Patchfelder) Komponenten von den Hochgebäuden auf dem Campus bis hin zum Internetanschluss.
</p>
<p>
<a href="https://noc.rub.de/web/_media/blog/2022/skizze-datennetz-nc.png" class="media" title="blog:2022:skizze-datennetz-nc.png"><img src="https://noc.rub.de/web/_media/blog/2022/skizze-datennetz-nc.png?w=400&tok=464317" class="media" loading="lazy" alt="" width="400" /></a>
</p>
text/html2021-03-08T22:05:22+00:00Andreas JobsAnalyse der Probleme mit dem RUB-VPN-Dienst vom 05.03.2021
https://noc.rub.de/web/blog/2021/analyse_der_vpn_probleme
<h4 id="analyse_der_probleme_mit_dem_rub-vpn-dienst_vom_05032021">Analyse der Probleme mit dem RUB-VPN-Dienst vom 05.03.2021</h4>
<div class="level4">
</div>
<h5 id="die_situation">Die Situation:</h5>
<div class="level5">
<p>
Gegen 10:00 Uhr brachen viele VPN-Verbindungen ab. Dieses Vorkommnis wiederholte sich nach etwa 40 Minuten erneut und ab ca. 11:00 Uhr wurden die Abstände dieser Abbrüche immer kürzer. Bis ca. 13:30 Uhr brachen die Verbindungen teilweise alle 10 Minuten ab (siehe auch <a href="https://noc.rub.de/cgi-bin/status/show?time=2021-03-05_14:10:39" class="urlextern" title="https://noc.rub.de/cgi-bin/status/show?time=2021-03-05_14:10:39" rel="ugc nofollow">Statushinweis</a>)
</p>
</div>
<h5 id="die_fehlersuche">Die Fehlersuche:</h5>
<div class="level5">
<p>
Eine Analyse der VPN-Logfiles zeigte, dass zu den Zeitpunkten, an denen viele Verbindungen abbrachen, wenig bis keine Aktivität in den Logfiles zu sehen war.
Auffällig war, dass sich diese Lücken immer direkt vor einer erfolgreichen Authentifizierung einer neuen VPN-Verbindung befanden. Parallel fanden sich auch erheblich mehr Anmeldefehler als normal in den Logfiles des RADIUS-Dienstes <sup><a href="#fn__1" id="fnt__1" class="fn_top">1)</a></sup>.
</p>
<p>
Gemäß Konfiguration sollte der Timeout bei der Authentifizierung am VPN, genau wie beim RADIUS-Dienst 5 Sekunden sein. Die Logfiles zeigten allerdings bei den größeren Verbindungsabbrüchen, dass die Authentifzierung teilweise deutlich länger als 60 Sekunden benötigte. Dieser Effekt ist beim VPN-Dienst insofern problematisch, weil dieser „Single-Threaded“ arbeitet, d.h. Verzögerungen bei einzelnen Aufgaben beeinträchtigen direkt alle Aufgaben eines VPN-Knotens.
Dauert eine Authentifizierung eine Sekunde, werden in dieser einen Sekunde keine Datenpakete anderer VPN-Verbindungen verarbeitet. Durch die massiven Verzögerungen kamen dann auch die Keep-Alive-Pakete bestehender Verbindungen teilweise zu spät am VPN-Knoten an (bzw. wurden verworfen), so dass dieser die Verbindungen abbrach.
</p>
</div>
<h5 id="die_loesung">Die Lösung:</h5>
<div class="level5">
<p>
Damit die Authentifizierung bestehende Verbindungen so wenig wie möglich beeinträchtigt, haben wir den Authentifizierungsprozess dahingehend geändert, dass dieser aktuell nach spätestens 5 Sekunden <sup><a href="#fn__2" id="fnt__2" class="fn_top">2)</a></sup> mit einer Fehlermeldung abgebrochen wird <sup><a href="#fn__3" id="fnt__3" class="fn_top">3)</a></sup>. Weiterhin wird im Prozess bzw. beim Abbruch protokolliert, in welcher Phase <sup><a href="#fn__4" id="fnt__4" class="fn_top">4)</a></sup> sich der Prozess beim Abbruch befand. Mit diesen Daten konnte unsere Hypothese relativ schnell verifiziert werden.
</p>
<p>
Aus diesen Fehlermeldungsdaten werden jetzt Statistiken erstellt und an die Kollegen der zentralen Authentifzierungsdienste weitergeleitet.
</p>
</div>
<div class="footnotes">
<div class="fn"><sup><a href="#fnt__1" id="fn__1" class="fn_bot">1)</a></sup>
<div class="content">Der RADIUS-Dienst koordiniert die Anmeldung im eduroam und an den HIRN-Ports. Beide Dienste nutzen den zentralen LDAP-Service zur Authentifizierung der Benutzer.</div></div>
<div class="fn"><sup><a href="#fnt__2" id="fn__2" class="fn_bot">2)</a></sup>
<div class="content">Je nach Ausprägung des Fehlerbildes wird dieser Wert noch weiter reduziert um die Verbindungsqualität zu verbessern ohne zu viele Anmeldefehler zu produzieren.</div></div>
<div class="fn"><sup><a href="#fnt__3" id="fn__3" class="fn_bot">3)</a></sup>
<div class="content">Der konfigurierbare Timeout bezieht sich offensichtlich nur auf den initialen Verbindungsaufbau zum zentralen Authentifizierungsdienst.</div></div>
<div class="fn"><sup><a href="#fnt__4" id="fn__4" class="fn_bot">4)</a></sup>
<div class="content">Der Authentifizierungsprozess umfasst mehrere Phasen: Benutzer finden, Benutzer authentifizieren, Konfiguration zusammenstellen und Konfiguration an den Klienten übermitteln.</div></div>
</div>
text/html2021-03-05T12:24:57+00:00Andreas JobsZoom - "Ihre Internetverbindung ist instabil" - ... und nun?
https://noc.rub.de/web/blog/2021/zoom_selbsthilfe
<h4 id="zoom_-_ihre_internetverbindung_ist_instabil_-__und_nun">Zoom - "Ihre Internetverbindung ist instabil" - ... und nun?</h4>
<div class="level4">
<p>
Die Meldung „Verbindung instabil“ / „Unstable Connection“ in Zoom kann verschiedene zugrundeliegende Ursachen haben: zum einen kann es sich tatsächlich um ein Verbindungsproblem zwischen Ihrem System und dem Internet (WLAN, Provider), dem Internet und dem Zoom-Service (Provider, Zoom) oder um Leistungsengpässe Ihrer Systemausstattung handeln.
</p>
<!-- EDIT{"target":"plugin_wrap_start","hid":"","secid":1,"range":"0-"} --><div class="wrap_info wrap_collarge plugin_wrap">
<p>
Für die Verwendung von ZOOM benötigen Sie keine bestehende VPN-Verbindung!
</p>
</div><!-- EDIT{"target":"plugin_wrap_end","hid":"","secid":2,"range":"0-"} -->
</div>
<h5 id="eigenes_system_pruefen">Eigenes System prüfen:</h5>
<div class="level5">
<p>
Zoom überträgt Video und Ton in Form von sogenannten Streams. Dabei werden kontinuierlich Informationspakete an Ihr System und von Ihrem System weg übertragen. Fehlen einzelne Pakete in der Übertragung oder schafft Ihr System aufgrund von erreichten Leistungsgrenzen die Abarbeitung dieser Pakete nicht, äußert sich das in abgehaktem Ton, in pixeliger oder eingefrorenem Bild. Häufig wird auch die Meldung „Verbindung instabil“ eingeblendet.
</p>
<p>
Überprüfen Sie die Auslastung Ihres Systems über [Zoom > Einstellungen > Statistiken]: im Reiter [Allgemein] können Sie die Prozessor- und Speicherauslastung auf Engpässe hin untersuchen (je geringer, desto besser). Auch die bisher übertragene Bandbreite Ihrer Netzwerkverbindung kann hier kontrolliert werden. In den Reitern [Audio] und [Video] können Sie die Anzahl von verlorengegangenen Paketen überprüfen (je geringer, desto besser).
</p>
<p>
<img src="https://noc.rub.de/web/_media/blog/2021/zoom_ger.png?w=400&tok=287158" class="mediacenter" loading="lazy" title=" " alt=" " width="400" /> <em>Abbildung: Beispiel für eine sehr hohe Systemauslastung, welche unabhängig von der Netzwerkverbindung zu einer unbefriedigenden ZOOM-Performance führt.</em>
</p>
<p>
<strong>Halten Sie diese Informationen bereit, wenn Sie Kontakt mit IT.SERVICES aufnehmen</strong> (sh. unten, Abschnitt „Ich benötige persönliche Unterstützung“).
</p>
<p>
<em>(Für Profis: der Stream von Zoom verwendet UDP-Pakete. Diese erwarten im Gegensatz zu TCP-Paketen, welche zum „normalen Surfen“ üblicherweise genutzt werden, keine Empfangsbestätigung. Server und Client „wissen“ also nicht unmittelbar von verlorenen Paketen, weswegen diese nicht erneut versendet - quasi nachgereicht - werden.)</em>
</p>
</div>
<h5 id="an_meinem_system_liegt_es_nicht_wie_kann_ich_feststellen_woran_es_noch_liegt">An meinem System liegt es nicht, wie kann ich feststellen, woran es noch liegt?</h5>
<div class="level5">
<p>
Unter <a href="https://noc.rub.de/ampel" class="urlextern" title="https://noc.rub.de/ampel" rel="ugc nofollow">https://noc.rub.de/ampel</a> können Sie den Status der NOC-Services überprüfen. Dies sind die Dienste, die RUB-eigen zur Verfügung gestellt werden. Hierzu zählen u.a. die Campus-Internetanbindung, die Anmeldedienste, WLAN,…
</p>
<p>
Unter <a href="https://status.zoom.us" class="urlextern" title="https://status.zoom.us" rel="ugc nofollow">https://status.zoom.us</a> können Sie den Status des Zoom-Services überprüfen. Der Zoom Service wird durch Zoom Video Communications, Inc. zur Verfügung gestellt.
</p>
<p>
Überprüfen Sie unbedingt auch die Statusinformationsseiten Ihres Internetanbieters (Telekom, Vodafone, Unitymedia,…), ob eventuell infrastruktuelle Probleme vorliegen. Solche Statusinformationsseiten können Sie für gewöhnlich leicht über eine Suchmaschine finden oder aber direkt bei Ihrem Internetanbieter erfragen.
</p>
</div>
<h5 id="alles_ist_in_ordnung_was_kann_ich_tun_wenn_die_probleme_fortbestehen">Alles ist in Ordnung, was kann ich tun, wenn die Probleme fortbestehen?</h5>
<div class="level5">
</div>
<h5 id="allgemein">Allgemein:</h5>
<div class="level5">
<ul>
<li class="level1"><div class="li"> Überprüfen Sie, ob neue Systemupdates für Ihr System vorhanden sind und installieren Sie diese.</div>
</li>
<li class="level1"><div class="li"> Trennen Sie nicht benötigte VPN-Verbindungen. Diese bremsen die Geschwindigkeit der Internetverbindung teils stark aus. Infos finden Sie auch unter <a href="https://noc.rub.de/vpn" class="urlextern" title="https://noc.rub.de/vpn" rel="ugc nofollow">https://noc.rub.de/vpn</a>.</div>
</li>
<li class="level1"><div class="li"> Beenden Sie nicht benötigte Programme im Hintergrund, um Systemressourcen freizugeben.</div>
</li>
<li class="level1"><div class="li"> Starten Sie ihr System regelmäßig neu.</div>
</li>
</ul>
</div>
<h5 id="auf_dem_campusin_den_aussenliegenschaften_der_rub">Auf dem Campus / in den Außenliegenschaften der RUB:</h5>
<div class="level5">
<ul>
<li class="level1"><div class="li"> Verwenden Sie, wann immer möglich, bevorzugt eine Kabelverbindung über die Netzwerkanschlüsse (HIRN-Ports) in Ihrem Bereich. Wenn Sie hierbei Unterstützung benötigen, wenden Sie sich an den für Sie zuständigen Netzbetreuer.</div>
</li>
<li class="level1"><div class="li"> Überprüfen Sie den WLAN- oder Mobilfunkempfang an Ihrem System. Bewegen Sie sich, falls möglich, näher an den WLAN-Access-Point. Oft verhilft schon ein kleiner Ortswechsel zu besserem Empfang.</div>
</li>
</ul>
<p>
Sollte der Empfang in Ihrem Bereich dauerhaft schlecht sein, so melden Sie sich bitte unter wlan@rub.de bei uns, damit wir Ihrem Bereich für zukünftige Ausbaumaßnahmen berücksichtigen können oder eine kurzfristige Entstörung veranlassen können.
</p>
<p>
Beachten Sie jedoch bitte auch den aktuellen WLAN-Ausbaustatus in Ihrem Bereich. Diesen können Sie unter: <a href="https://noc.rub.de/web/wlan/ausbau-status" class="urlextern" title="https://noc.rub.de/web/wlan/ausbau-status" rel="ugc nofollow">https://noc.rub.de/web/wlan/ausbau-status</a> einsehen.
</p>
</div>
<h5 id="im_home_office">Im Home Office:</h5>
<div class="level5">
<ul>
<li class="level1"><div class="li"> Überprüfen Sie den WLAN- oder Mobilfunkempfang an Ihrem System. Bewegen Sie sich, falls möglich, näher an den WLAN-Access-Point. Oft verhilft schon ein kleiner Ortswechsel zu besserem Empfang.</div>
</li>
<li class="level1"><div class="li"> Verwendet Sie, wenn möglich, bevorzugt eine Kabelverbindung zu Ihrem Internetrouter.</div>
</li>
<li class="level1"><div class="li"> Starten Sie Ihr System und auch Ihren Internetrouter regelmäßig neu und überprüfen Sie, ob Updates zur Verfügung stehen.</div>
</li>
<li class="level1"><div class="li"> Überprüfen Sie, ob eine lokale Störung bei Ihrem Internetanbieter vorliegt.</div>
</li>
<li class="level1"><div class="li"> Überprüfen Sie, ob die bei Ihrem Internetanbieter gebuchte Bandbreite ausreichend dimensioniert ist.</div>
</li>
</ul>
</div>
<h5 id="ich_benoetige_persoenliche_unterstuetzung">Ich benötige persönliche Unterstützung:</h5>
<div class="level5">
<p>
Gerne helfen wir Ihnen auch individuell und persönlich!
</p>
<p>
Bitte halten Sie die Informationen über Ihr System bereit. Diese finden Sie unter den Menüpunkten [Zoom > Einstellungen > Statistiken].
</p>
<p>
Wenden Sie sich bitte an das Servicecenter von IT.SERVICES:
</p>
<ul>
<li class="level1"><div class="li"> persönlich im Servicecenter in IA E095/150</div>
</li>
<li class="level1"><div class="li"> telefonisch unter +49 (0)234 32-24025</div>
</li>
<li class="level1"><div class="li"> Fax: +49 (0)234 32-14349</div>
</li>
<li class="level1"><div class="li"> E-Mail: <a href="mailto:mailto:its-helpdesk@ruhr-uni-bochum.de" class="mail" title="mailto:its-helpdesk@ruhr-uni-bochum.de">its-helpdesk@ruhr-uni-bochum.de</a></div>
</li>
</ul>
<p>
Generelle Probleme mit unserem <abbr title="Local Area Network">LAN</abbr> oder WLAN können Sie uns über unser Ticketsystem mitteilen: <a href="https://www.it-services.ruhr-uni-bochum.de/support/online.html.de" class="urlextern" title="https://www.it-services.ruhr-uni-bochum.de/support/online.html.de" rel="ugc nofollow">https://www.it-services.ruhr-uni-bochum.de/support/online.html.de</a> oder einer Email an wlan@rub.de.
</p>
<p>
— <em><a href="mailto:stefan.unrein@ruhr-uni-bochum.de" class="mail" title="stefan.unrein@ruhr-uni-bochum.de">Stefan Unrein</a> 2021/03/05 10:15</em>
</p>
</div>
text/html2020-12-21T13:12:33+00:00Robin DärmannWartungsarbeiten zwischen Weihnachten und Neujahr 2020/2021
https://noc.rub.de/web/blog/2020/wartungsarbeiten_zwischen_den_feiertagen
<h2 class="sectionedit1" id="wartungsarbeiten_zwischen_weihnachten_und_neujahr_20202021">Wartungsarbeiten zwischen Weihnachten und Neujahr 2020/2021</h2>
<div class="level2">
<p>
Auch in diesem Jahr werden wir zwischen den Feiertagen wieder Wartungsarbeiten an Komponenten des Datennetzes durchführen. Dieses Mal rücken wieder die Router in den Vordergrund: es werden Software-Updates auf den Gebäudereihen-Routern sowie dem Datacenter-Router installiert.
</p>
<p>
Die Gebäudereihen-Router der G-Reihe, I-Reihe, Zentralachse/M-Reihe und ProDi bekommen im laufenden Betrieb neue Software. Sie sind redundant ausgelegt. Das bedeutet, dass es jeweils zwei identische Geräte gibt, die sich im Fehlerfall gegenseitig aushelfen. Wir können die Geräte mit neuer Software versorgen und dann nacheinander neu starten, ohne, dass es einen spürbaren Netzwerkausfall gibt. In der Regel funktioniert das Verfahren gut, Ausfälle sind aber natürlich nicht hundertprozentig auszuschließen, weshalb wir die Arbeiten auch jeweils separat ankündigen.
</p>
<p>
Die meisten Router unserer externen Liegenschaften inklusive des zentralen Systems auf dem Campus, über das die externen Liegenschaften angeschlossen sind, haben wir bereits gestern Abend (20.12.2020, ab 20 Uhr) aktualisiert.
</p>
</div>
<!-- EDIT{"target":"section","name":"Wartungsarbeiten zwischen Weihnachten und Neujahr 2020\/2021","hid":"wartungsarbeiten_zwischen_weihnachten_und_neujahr_20202021","codeblockOffset":0,"secid":1,"range":"1-1157"} -->
<h3 class="sectionedit2" id="und_was_ist_mit_der_n-reihe">Und was ist mit der N-Reihe?</h3>
<div class="level3">
<p>
Die N-Reihe ist sozusagen ein spezialgelagerter Sonderfall: Der N-Reihenrouter ist in seiner endgültigen Form aufgrund diverser infrastruktureller Hürden immernoch nicht in Betrieb. Die Geräte laufen zwar inzwischen schon parallel zu den alten Gebäude-Routern, sind jedoch noch nicht in den aktiven Routing-Betrieb eingebunden, sprich: wir haben noch nicht umgestöpselt auf die neuen Router. Der N-Reihen-Router hat die aktuell anstehenden Software-Updates bereits erhalten und muss daher zwischen den Feiertagen nicht aktualisiert werden.
</p>
<p>
Im Anschluss an die Router-Aktualisierungen werden wir uns Anfang des Jahres 2021 mit dem Umschwenken der alten Gebäude-Router der N-Reihe auf den neuen N-Reihenrouter beschäftigen. Dies wird im laufenden Betrieb erfolgen und im Normalfall keine deutlich spürbaren Netzwerk-Ausfälle verursachen (nur ca. 2-5 Sekunden pro VLAN). Wir werden das zu gegebener Zeit entsprechend ankündigen. Im Vorfeld sind eigentlich nur noch ein paar LWL-Kabel zu stöpseln.
</p>
</div>
<!-- EDIT{"target":"section","name":"Und was ist mit der N-Reihe?","hid":"und_was_ist_mit_der_n-reihe","codeblockOffset":0,"secid":2,"range":"1158-"} -->text/html2020-11-27T09:13:50+00:00Robin DärmannAustausch unserer Border-Router am 30.06.2020
https://noc.rub.de/web/blog/2020/border-router-upgrade
<h2 class="sectionedit1" id="austausch_unserer_border-router_am_30062020">Austausch unserer Border-Router am 30.06.2020</h2>
<div class="level2">
</div>
<!-- EDIT{"target":"section","name":"Austausch unserer Border-Router am 30.06.2020","hid":"austausch_unserer_border-router_am_30062020","codeblockOffset":0,"secid":1,"range":"1-56"} -->
<h3 class="sectionedit2" id="unser_setup_im_detail">Unser Setup im Detail</h3>
<div class="level3">
<p>
Wir betreiben für die Internet-Anbindung der Ruhr-Universität zwei sogenannte AS-Border-Router, als eigenständige Systeme arbeiten. Mehr zur Anbindung der Ruhr-Universität ans Internet kann man <a href="https://noc.rub.de/web/blog/2020/internetanbindung" class="wikilink1" title="blog:2020:internetanbindung" data-wiki-id="blog:2020:internetanbindung">hier</a> nachlesen.
</p>
<p>
Unsere internen Routing-Systeme, welche die Gebäude und externen Liegenschaften versorgen, sind jeweils als VSS-System ausgelegt. Das bedeutet, dass es für jeden Router doppelte Hardware gibt, die beiden Systeme jedoch als ein und derselbe Router auftreten. Beispielsweise gibt es für die G-Reihe eine Hardware im Gebäude <abbr title="Gigabyte">GB</abbr> und eine weitere im Gebäude GD. Die beiden Systeme sind über Glasfaserkabel direkt miteinander verbunden und bilden ein sogenanntes VSS (Virtual Switching System), also ein großes Gerät bestehend aus den beiden einzelnen Hardware-Teilen.
</p>
<p>
Unsere AS-Border-Router sind absichtlich <strong>NICHT</strong> so konfiguriert. Während auf den internen Systemen die Vorteile überwiegen (geringere Anfälligkeit für Konfigurationsfehler, schnellere Konvergenzzeiten bei Ausfall einer Hardware), wollen wir auf den Border-Routern gerne auf die Nachteile verzichten (Konfigurationsfehler oder Software-Fehler können beide Systeme gleichzeitig lahm legen). Des weiteren haben wir die Leitungen zu den Internetprovidern in der Regel ohnehin nicht redundant, so dass beispielsweise beim Ausfall der Hardware, an die die TMR-Anbindung gesteckt ist, keine alternative Verbindung zu TMR besteht. Hier wäre es sinnfrei, ein VSS-System zu betreiben.
</p>
</div>
<!-- EDIT{"target":"section","name":"Unser Setup im Detail","hid":"unser_setup_im_detail","codeblockOffset":0,"secid":2,"range":"57-1590"} -->
<h3 class="sectionedit3" id="was_passiert_beim_ausfall_eines_as-border-routers">Was passiert beim Ausfall eines AS-Border-Routers?</h3>
<div class="level3">
<p>
Beim Ausfall oder Neustart eines AS-Border-Routers bekommt der verbliebene Router spontan mehr Arbeit. Er muss große Teile seiner Routingtabelle neu berechnen und gleichzeitig spontan in etwa doppelt so viel Traffic transportieren. Dabei ist es unerheblich ob der Ausfall unvorhergesehen (durch technischen Defekt oder Stromausfall) passiert oder absichtlich, z.B. wegen eines Software-Updates.
</p>
<p>
Die eigentliche Problematik in einer solchen Situation ist jedoch, dass nicht nur der verbleibende Router auf unserer Seite mehr Arbeit bekommt und alles mögliche neu berechnen muss, sondern dass das prinzipiell für alle autonomen Systeme des Internets gilt. Die Bekanntgabe von Routen im Internet erfolgt, indem die AS-Border-Router ihren direkt verbundenen Kommunikationspartnern (in unserem Fall den Provider-Routern von DFN-Verein und TMR) sagen, welche IP-Adressbereiche sich hinter ihnen befinden. Das sind bei uns zur Zeit: 134.147.0.0/16, 185.73.20.0/22, 192.35.72.0/24 und 2a05:3e00::/29. Unsere Router sagen also praktisch: „<em>Die RUB-Netze sind hier bei mir!</em>“. Die Provider verfahren genau so und sagen weiter: „<em>Die Netze der RUB bekommt ihr über mich!</em>“. Umgekehrt bekommen wir von den Provider-Routern sinngemäß für JEDES Subnetz der Welt gesagt: „<em>Das Netz für E erreicht ihr über mich, A, B, C und D!</em>“. Und zwar von jeder Internet-Anbindung, also insgesamt dreimal. Das sind aktuell ca. 850.000 IPv4- und ca. 100.000 IPv6-Netze (bzw. Routen). Jedes autonome System des weltweit verzweigten Internets empfängt diese Nachrichten und gibt sie entsprechend weiter. Es gibt natürlich Verfahren zur Vermeidung von Schleifen und Fehlinformationen, die wollen wir aber an dieser Stelle ausklammern.
</p>
</div>
<!-- EDIT{"target":"section","name":"Was passiert beim Ausfall eines AS-Border-Routers?","hid":"was_passiert_beim_ausfall_eines_as-border-routers","codeblockOffset":0,"secid":3,"range":"1591-3371"} -->
<h3 class="sectionedit4" id="die_stille_post_des_internets">Die Stille Post des Internets</h3>
<div class="level3">
<p>
Fällt einer unserer AS-Border-Router aus, so merkt der Provider das schnell und gibt diese Information auch weiter: „<em>Die Netze der RUB bekommt ihr jetzt nicht mehr über mich!</em>“. Für mindestens ein paar Sekunden (in der Regel bis zu zwei Minuten) bekommt er jedoch noch Daten für uns zugestellt, er kann dann in der Regel nichts weiter tun als diese zu verwerfen. Es kommt schlußendlich zum Abbruch empfindlicher Verbindungen wie z.B. dem RUB-VPN-Tunnel, wenn man ihn von zuhause aus gerade nutzt.
</p>
<p>
Beim ordentlichen Neustart eines unserer Router wird der Provider über das BGP-Protokoll entsprechend benachrichtigt, so dass er die Information rechtzeitig weiter geben kann (sog. „graceful shutdown“). Dann wird die Zeit, in der er Daten für uns bekommt, diese aber verwerfen muss, noch etwas kürzer. Das hängt aber auch immer davon ab, wie schnell die anderen mit dem Provider verbundenen autonomen Systeme diese Information verarbeiten.
</p>
</div>
<!-- EDIT{"target":"section","name":"Die Stille Post des Internets","hid":"die_stille_post_des_internets","codeblockOffset":0,"secid":4,"range":"3372-4360"} -->
<h3 class="sectionedit5" id="speicher_voll">Speicher voll</h3>
<div class="level3">
<p>
Die aus der „Stillen Post“ entstehenden Routingtabellen des Internets wachsen unaufhörlich. Seit Anfang der 1990er Jahre wächst die IPv4-Routingtabelle unaufhörlich. Waren es im Jahr 2008 noch ca. 250.000 Einträge, so wurde im Jahr 2014 schon die 500.000er-Marke überschritten. Aktuell sind es 850.000 Routen, Tendenz steigend. Dies erfordert immer mehr teuren, speziellen Speicher in den verwendeten Routern, wenn man nicht anderweitig aggregieren kann (was wir nicht sinnvoll können).
</p>
<p>
Bisher gelang es uns immer, durch vorausschauende Planung rechtzeitig Hardware-Anpassungen vorzunehmen. Anfang des Jahres 2020 wähnten wir und noch in Sicherheit, doch da geschah es. Das Auftreten folgender unscheinbarer Fehlermeldung im Log eines unserer AS-Border-Router bedeutete weitaus schlimmes als man zunächst annahm:
</p>
<p>
<code>%CFIB-DFC1-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched</code>
</p>
<p>
Es kam zu Erreichbarkeitsproblemen vieler Webseiten, Problemen mit dem RUB-VPN-Tunnel und vielen weiteren, nicht direkt damit in Verbindung zu bringenden Kleinigkeiten. Bevorzugt betroffen waren fast immer irgendwie die Netze der Telekom (die konnten nichts dafür, es war tatsächlich Zufall, wie sich später heraus stellte).
</p>
<p>
Eine detailliertere Analyse der Systeme, zusammen mit dem Hersteller Cisco, brachte die Erkenntnis, dass unsere Maschinen zwar genug Speicher hatten, aber mehr verbrauchten als sie sagten. Der Speicher war also wieder voll, wir konnten das nur nicht sehen. Ein paar Tricks haben wir noch versucht, aber lange halfen die auch nicht weiter. Es mussten also schnell neue Router her. Doch die hatten - natürlich - Lieferzeit. Und so lange blieb uns nichts anderes übrig als zu warten und hoffen, dass das Problem nicht allzu häufig auftritt.
</p>
<p>
Ein weiteres Indiz für einen nicht ordentlich funktionierenden Router war (bzw. ist) der Status der FIB (Forwarding Information Base). Folgender Befehl zeit den Status an:
</p>
<p>
<code>#show platform hardware cef exception status<br/>
Current IPv4 FIB exception state = TRUE<br/>
Current IPv6 FIB exception state = FALSE<br/>
Current MPLS FIB exception state = FALSE<br/>
Current EoM/VPLS FIB TCAM exception state = FALSE</code>
</p>
<p>
Taucht hier irgendwo <code>TRUE</code> auf, so ist der Fall eingetreten, dass die Maschine aufgrund irgendeines Problems nicht mehr ordentlich arbeiten kann. Es hilft nur ein kompletter Neustart des Geräts.
</p>
</div>
<!-- EDIT{"target":"section","name":"Speicher voll","hid":"speicher_voll","codeblockOffset":0,"secid":5,"range":"4361-6773"} -->
<h3 class="sectionedit6" id="alles_neu_macht_der__juni">Alles neu macht der ... Juni</h3>
<div class="level3">
<p>
Bis die neue Hardware ausgewählt, bestellt, angekommen und konfiguriert war, vergingen einige Wochen. Als besondere Herausforderung kam hinzu, dass die neuen Maschinen nicht mehr wie die alten Geräte auf IOS, dem althergebrachten Router-Betriebssystem von Cisco, basieren, sondern auf IOS-XE. Das klingt ähnlich - ist es auch - im Detail finden sich jedoch wichtige Unterschiede. Zusätzlich mussten wir die Konfiguration „blind“ machen, das heißt wir konnten vor dem Austausch der Geräte nicht wirklich testen, was wir konfigurieren.
</p>
<p>
Am 30.06.2020 war es dann so weit: Wir hatten alles fertig und konnten umbauen. Das bedeutete, nach einem vorher festgelegten Plan alle Kabel nacheinander von den alten Routern abzuziehen und in die neuen Router zu stöpseln. Ein Brandmelde-Alarm im Gebäude IC hätte die Aktion zwar fast verhindert - wir konnten zunächst nicht einordnen, ob der Alarm nicht doch im Gebäude IB war - letztendlich ist jedoch alles gut gegangen.
</p>
<p>
So sah das direkt nach dem Umbau aus:
</p>
<p>
<a href="https://noc.rub.de/web/_detail/blog/2020/border-router-2020.jpg?id=blog%3A2020%3Aborder-router-upgrade" class="media" title="blog:2020:border-router-2020.jpg"><img src="https://noc.rub.de/web/_media/blog/2020/border-router-2020.jpg" class="media" loading="lazy" alt="" /></a>
</p>
<p>
Die goldenen Kisten sind unsere alten Border-Router, die silbernen sind die neuen Geräte. Wir mussten also von unten nach oben umstöpseln.
</p>
</div>
<!-- EDIT{"target":"section","name":"Alles neu macht der ... Juni","hid":"alles_neu_macht_der__juni","codeblockOffset":0,"secid":6,"range":"6774-8003"} -->
<h3 class="sectionedit7" id="quintessenz">Quintessenz</h3>
<div class="level3">
<p>
Alles in allem sind wir mit den neuen Systemen (fast) zufrieden. Sie tun im Wesentlichen was sie sollen und verhalten sich sehr viel performanter als die alten Systeme. Die Routing-Updates werden auch nach einem Neustart wesentlich flotter verarbeitet. Sicher gibt es ein paar Kinderkrankheiten, die man von einem Hersteller wie Cisco eigentlich nicht erwarten sollte, aber Hard- und Software reift nunmal beim Kunden, so ist das leider mittlerweile. So ein Hersteller kann ja auch nicht damit rechnen, dass der Kunde ein Feature auch tatsächlich benutzen will (was dann unweigerlich zum Crash und Neustart des Routers führt). Und so ein Kunde kann offenbar auch weder erwarten, dass man beworbene Features auch benutzen kann, noch, dass der angezeigte Speicherverbrauch des Systems auch tatsächlich stimmt. Wir sind da hartnäckig bei der Nachverfolgung der Fehler und geben so schnell nicht auf.
</p>
<p>
Tja, würden nur endlich mehr Leute IPv6 benutzen, das war nämlich von den Ausfällen mit den alten Routern nie betroffen. <img src="https://noc.rub.de/web/lib/images/smileys/wink.svg" class="icon smiley" alt=";-)" />
</p>
</div>
<!-- EDIT{"target":"section","name":"Quintessenz","hid":"quintessenz","codeblockOffset":0,"secid":7,"range":"8004-"} -->text/html2020-11-26T13:08:51+00:00Robin DärmannWie funktioniert eigentlich unser Internet?
https://noc.rub.de/web/blog/2020/internetanbindung
<h2 class="sectionedit1" id="wie_funktioniert_eigentlich_unser_internet">Wie funktioniert eigentlich unser Internet?</h2>
<div class="level2">
</div>
<!-- EDIT{"target":"section","name":"Wie funktioniert eigentlich unser Internet?","hid":"wie_funktioniert_eigentlich_unser_internet","codeblockOffset":0,"secid":1,"range":"1-54"} -->
<h3 class="sectionedit2" id="das_internet_und_unsere_rolle_darin">Das "Internet" und unsere Rolle darin</h3>
<div class="level3">
<p>
Als eine der zehn größten Universitäten in Deutschland sind wir aus Sicht des Netzwerks im Grunde genommen eine Großstadt. Mit über 100.000 Netzwerkanschlüssen im Endgeräte-Bereich (Access-Ports) und über 1.000 WLAN Access-Points - Tendenz steigend - verfügen wir über ein vergleichsweise großes Datennetz. Durch vorausschauende Planung vor und in den 2000er Jahren ist es uns gelungen, schon vor der breiten Verfügbarkeit redundanter Anschlüsse seitens des DFN-Vereins durch die Kooperation mit der „Telekommunikation Mittleres Ruhrgebiet GmbH“ (TMR) eine redundante, d.h. mehrfach ausgelegte Internetanbindung zu realisieren.
</p>
<p>
Da die Anbindung eines Netzwerks unserer Größe nicht mit den aus Haushalten oder kleineren Unternehmen bekannten Komponenten (FritzBox, WLAN-Router o.ä.) realisiert werden kann war es nötig, in spezielle Hardware zu investieren. Wir besitzen für die Internetanbindung der RUB deshalb schon seit Jahren immer zwei spezielle Router. Sie zeichnen sich dadurch aus, dass sie das sogenannte „Border Gateway Protocol“ (BGP) beherrschen. Das ist die „Sprache“ des Internet-Routings.
</p>
<p>
Dieses „Internet“ ist prinzipiell eigentlich nur eine größere Ansammlung sogenannter autonomer Systeme (AS), die, wie der Name schon sagt, autonom funktionieren und wie ein Spinnennetz miteinander verbunden sind. Ein autonomes System ist beispielsweise ein Internetprovider wie die Deutsche Telekom, Vodafone oder - wie in unserem Fall - der DFN-Verein als Provider für Universitäten in Deutschland. Auch die TMR ist ein autonomes System, ebenso wie wir, die Ruhr-Universität. Alle autonomen Systeme haben eine sogenannte AS-Nummer und sind mit mindestens einem weiteren autonomen System verbunden, um Routen und Daten auszutauschen.
</p>
<p>
Relevante AS-Nummern für uns sind zum einen wir selbst (AS29484), der DFN-Verein (AS680) und die TMR (AS12329). Alle diese Daten sind kein Geheimnis, man kann sie z.B. <a href="https://bgp.he.net/AS29484" class="urlextern" title="https://bgp.he.net/AS29484" rel="ugc nofollow">hier</a> nachschlagen und dort auch sehen, wie wir mit dem Rest des Internets verbunden sind. Eine weitere interessante Stelle ist <a href="https://stat.ripe.net/AS29484" class="urlextern" title="https://stat.ripe.net/AS29484" rel="ugc nofollow">hier</a>.
</p>
</div>
<!-- EDIT{"target":"section","name":"Das \"Internet\" und unsere Rolle darin","hid":"das_internet_und_unsere_rolle_darin","codeblockOffset":0,"secid":2,"range":"55-2232"} -->
<h3 class="sectionedit3" id="fehleranfaelligkeit">Fehleranfälligkeit</h3>
<div class="level3">
<p>
Autonome Systeme tauschen über ihre Verbindungen untereinander Routen und Daten aus, das funktioniert erstaunlich gut - und das ist ernst gemeint! Denn die Konfiguration der Systeme ist recht komplex und es passieren immer wieder Unfälle (siehe z.B. <a href="https://taz.de/Ausfall-des-Videoportals/!5186029/" class="urlextern" title="https://taz.de/Ausfall-des-Videoportals/!5186029/" rel="ugc nofollow">hier</a>, <a href="https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/" class="urlextern" title="https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/" rel="ugc nofollow">hier</a> oder <a href="https://www.manrs.org/2020/07/big-route-leak-shows-need-for-routing-security/" class="urlextern" title="https://www.manrs.org/2020/07/big-route-leak-shows-need-for-routing-security/" rel="ugc nofollow">hier</a>). Dagegen helfen einige neuartige Technologien (z.B. RPKI) und die Konfiguration geeigneter Filter. Wir nutzen diese Technologien, es führt aber zu weit, darüber an dieser Stelle zu berichten.
</p>
</div>
<!-- EDIT{"target":"section","name":"Fehleranf\u00e4lligkeit","hid":"fehleranfaelligkeit","codeblockOffset":0,"secid":3,"range":"2233-2980"} -->
<h3 class="sectionedit4" id="die_globale_routingtabelle">Die globale Routingtabelle</h3>
<div class="level3">
<p>
Nimmt man sich die Liste aller Netzwerke des Internets vor, die aktuell in Benutzung sind, so kommt man Stand heute, 24.11.2020, auf 467.676 IPv4-Netzwerke weltweit. Die Anzahl der Routen, also der Wege über verschiedene autonome Systeme hin zu jedem einzelnen Netzwerk ist deutlich höher, nämlich 851.411. Das ist die (heutige) Anzahl der Einträge in unserer Routingtabelle für das IPv4-Internet. Für IPv6 sind die Zahlen noch etwas kleiner, es gibt heute 58.042 IPv6-Präfixe (Netzwerke) und 101.654 Routen dort hin. Die Daten stammen von <a href="https://www.cidr-report.org/" class="urlextern" title="https://www.cidr-report.org/" rel="ugc nofollow">https://www.cidr-report.org/</a> bzw. <a href="https://www.cidr-report.org/v6" class="urlextern" title="https://www.cidr-report.org/v6" rel="ugc nofollow">https://www.cidr-report.org/v6</a>.
</p>
<p>
Für ein halbwegs aktuelles Computersystem scheinen die Zahlen auf den ersten Blick nicht sehr groß zu sein, mit aktueller PC-Hardware kann man durchaus Tabellen mit knapp einer Million Zeilen verarbeiten. Allerdings geht es beim Routing um viel speziellere Dinge, es müssen nämlich im Mikrosekundenbereich Entscheidungen getroffen werden. Für jedes Datenpaket, was am Router eingeht, muss unter anderem anhand der Routingtabellen entschieden werden, wohin das Paket weiter gesendet werden muss. Das muss sehr schnell gehen und es spielen dabei auch noch ein paar andere Faktoren eine Rolle, die wir an dieser Stelle aber vernachlässigen können. Man stelle sich einfach vor, man müsse mehrere hunderttausend mal pro Sekunde in einer Tabelle mit knapp einer Million Zeilen die richtige finden.
</p>
</div>
<!-- EDIT{"target":"section","name":"Die globale Routingtabelle","hid":"die_globale_routingtabelle","codeblockOffset":0,"secid":4,"range":"2981-4438"} -->
<h3 class="sectionedit5" id="wie_sieht_das_konkret_bei_uns_aus">Wie sieht das konkret bei uns aus?</h3>
<div class="level3">
<p>
Das Datennetz bzw. autonome System der Ruhr-Universität ist über zwei sogenannte AS-Border-Router mit zwei weiteren autonomen Systemen verbunden. Es handelt sich um das AS des DFN-Vereins und um das AS der TMR. Zum DFN-Verein unterhalten wir zwei Verbindungen, eine geht nach Frankfurt am Main, eine geht nach Essen. Jede Verbindung hat eine Kapazität von 20 Gbit/s (2x 10 Gbit/s gebnündelt). Zur TMR unterhalten wir eine Verbindung mit einer Kapazität von 8 Gbit/s.
</p>
<p>
In folgender Live-Ansicht sieht man die Auslastung der wichtigsten Leitungen unseres Netzes (Klick auf das Bild zeit es in Originalgröße):
</p>
<p>
<a href="https://nedi.noc.ruhr-uni-bochum.de/netweather/" class="media" title="https://nedi.noc.ruhr-uni-bochum.de/netweather/" rel="ugc nofollow"><img src="https://noc.rub.de/web/lib/exe/fetch.php?w=700&tok=90722c&media=https%3A%2F%2Fnedi.noc.ruhr-uni-bochum.de%2Fnetweather%2Fweather.png" class="media" loading="lazy" alt="" width="700" /></a>
</p>
<p>
Im linken Bereich der Grafik erkennt man die beiden AS-Border-Router <code>rub-asr-1</code> und <code>rub-asr-2</code> mit den daran angeschlossenen Internet-Anbindungen „DFN-DUE“ (nach Essen), „DFN-FRA“ (nach Frankfurt) und „TMR“. Es ist auch zu erkennen, dass die beiden AS-Border-Router mehrfach untereinander verbunden sind. Über diese Verbindungen werden - wie auch mit dem Internet - Routen über BGP ausgetauscht. Fährt man mit dem Mauszeiger über einzelne Verbindungen, bekommt man angezeigt, wieviel Traffic (Datenverkehr) in den letzten Stunden über die Leitung transportiert wurde. Die Grafik wird minütlich aktualisiert.
</p>
<p>
Beide AS-Border-Router errechnen aus den von den Providern empfangenen Routen (wie gesagt pro Internet-Anbindung insgesamt knapp eine Million Routen) die optimale Route für jedes Netzwerk stets aktuell. Bei jeder Änderung, die von einem Provider empfangen wird, erfolgt eine Neuberechnung des optimalen Weges für entsprechende Ziele. Es wird hier selektiv neu berechnet, nicht jedes Mal die komplette Tabelle. Und es besteht auch die Möglichkeit, dass einer unserer Router entscheidet, dass das Ziel über den anderen Router besser zu erreichen ist. Daten werden dann zwischen den beiden AS-Border-Routern transportiert. Beispiel: Datenverkehr aus dem Data Center in Richtung Internet (jemand ausserhalb der RUB ruft z.B. <a href="http://www.rub.de" class="urlextern" title="http://www.rub.de" rel="ugc nofollow">www.rub.de</a> auf) kommt auf <code>rub-asr-2</code> an. Dieser hat entschieden, dass der günstigste Weg über unsere TMR-Anbindung erfolgt. Das Paket wird an <code>rub-asr-1</code> weiter geleitet, denn an diesem befindet sich die Verbindung zu TMR.
</p>
</div>
<!-- EDIT{"target":"section","name":"Wie sieht das konkret bei uns aus?","hid":"wie_sieht_das_konkret_bei_uns_aus","codeblockOffset":0,"secid":5,"range":"4439-6794"} -->
<h3 class="sectionedit6" id="die_eingesetzte_hardware">Die eingesetzte Hardware</h3>
<div class="level3">
<p>
Bis Ende Juni 2020 wurde das Internet-Routing durch zwei Layer-3-Switche der Firma Cisco erledigt. Es handelte sich um Catalyst 6807-XL mit erweitertem Speicher-Ausbau, damit sie die hohe Anzahl an Routen verarbeiten können. Aufgrund von Kapazitätsproblemen - die Routingtabellen des Internets wurden einfach zu groß - mussten wir die Hardware jedoch erneuern. Am 30.06.2020 wurden diese beiden Layer-3-Switche daher durch zwei (richtige) Router vom Typ ASR1002-HX ersetzt. Details zum Router-Tausch sind <a href="https://noc.rub.de/web/blog/2020/border-router-upgrade" class="urlextern" title="https://noc.rub.de/web/blog/2020/border-router-upgrade" rel="ugc nofollow">hier</a> zu finden.
</p>
</div>
<!-- EDIT{"target":"section","name":"Die eingesetzte Hardware","hid":"die_eingesetzte_hardware","codeblockOffset":0,"secid":6,"range":"6795-"} -->text/html2020-10-28T13:39:14+00:00Frank DegenhardtErneuerung der Serverinfrastruktur des E-Mailsystems
https://noc.rub.de/web/blog/2020/e-mail-server
<p>
Das Mailsystem bekommt eine komplett neue Infrastruktur bestehend aus Recheneinheiten (Server) und Speichereinheiten (Storage).
</p>
<p>
Dies wird die zweite Beschreibung der neuen Infrastruktur des Mailsystems, die Serverseite.
</p>
<p>
Um nicht allzu technisch und unverständlich zu werden, sollen hier Vergleiche aus dem täglichen Leben zur Vereinfachung dienen.
</p>
<p>
Die RUB ist ähnlich einer Großstadt mit ca. 170000 Einwohnern (Mailboxen).
</p>
<p>
Für die Abwicklung des täglichen Postgeschäfts (elektronisch) stehen im Moment
</p>
<p>
6 Mitarbeiter (Server) einer Leistungsfähigkeit von jeweils CPUs und 64 <abbr title="Gigabyte">GB</abbr> Hauptspeicher bereit .
Sie erledigen verschiedene Dienste von interner Koordination, Datenbankaufgaben, Kontrolle auf Viren in den ankommenden und ausgehenden Emails,
SPAM-Behandlung, Abweisung von Emails (bounces), über Messenger (Jabber), Versendung von sehr großen Emails mit der Möglichkeit Anhänge zwischen zu
lagern (storit) bis zur Auslieferung der Emails in die Postfächer.
Diese Mitarbeiter haben inzwischen das Computer-Rentenalter erreicht und werden ausgetauscht.
</p>
<p>
Nackte Zahlen:
</p>
<p>
Altes Mailsystem
</p>
<ul>
<li class="level1"><div class="li"> 6 Server </div>
</li>
<li class="level1"><div class="li"> 96 CPU Kerne</div>
</li>
<li class="level1"><div class="li"> 384 <abbr title="Gigabyte">GB</abbr> RAM</div>
</li>
</ul>
<p>
Neues Mailsystem
</p>
<ul>
<li class="level1"><div class="li"> 8 Server</div>
</li>
<li class="level1"><div class="li"> 384 CPU Kerne</div>
</li>
<li class="level1"><div class="li"> 2084 <abbr title="Gigabyte">GB</abbr> RAM</div>
</li>
</ul>
<p>
Die acht neuen Mitarbeiter haben eine Leistungsfähigkeit von jeweils 2 aktuellen CPUs und 256 <abbr title="Gigabyte">GB</abbr> Hauptspeicher.
Zwei der neuen Server ersetzen komplett die gesamten alten Server, um eine Steigerung des Mailaufkommens in den nächsten Jahren abfangen zu können.
</p>
<p>
Die Server werden in den nächsten zwei bis drei Wochen eingebaut und in Betrieb genommen.
</p>
text/html2020-10-25T15:56:44+00:00Andreas JobsUmbau des E-Mail-Speichersystems
https://noc.rub.de/web/blog/2020/e-mail-speichersystem
<p>
Das Mailsystem bekommt eine komplett neue Infrastruktur bestehend aus Recheneinheiten (Server) und Speichereinheiten (Storage).
</p>
<p>
In diesem Artikel beschäftigen wir uns etwas näher mit dem Speichersystem.
</p>
<p>
Das neue Speichersystem umfasst zwei Speicherserver mit jeweils 100 Terabyte Speicherkapazität. Diese beiden Speicherserver stehen räumlich getrennt in den Serverräumen GD und Zemos. Beide Speicherserver sind so eingerichtet, dass sie Änderungen in 15 Minuten-Rhythmen auf den jeweils anderen Speicherserver übertragen. Somit könnte ein Speichersystem komplett abbrennen ohne das nennenswerter Datenverlust eintritt (es gehen höchstens die Mails der letzten 15 Minuten verloren).
</p>
<p>
Aktuell werden die Daten von den beiden alten Speichersystemen in das neue System kopiert, was uns vor das Problem stellt: Wie kopiert man viele Mailboxen ohne das die Benutzer längere Zeit auf E-Mail verzichten müssen. Dazu ein paar Faken:
</p>
<p>
Im Mailsystem liegen derzeit:
</p>
<ul>
<li class="level1"><div class="li"> 170.000 Mailboxen</div>
</li>
<li class="level1"><div class="li"> 181 Millionen E-Mails</div>
</li>
<li class="level1"><div class="li"> 42 Terabyte Nettodaten</div>
</li>
</ul>
<p>
Die einfachste Variante wäre
</p>
<ul>
<li class="level1"><div class="li"> Mailzugriff abschalten</div>
</li>
<li class="level1"><div class="li"> Daten kopieren</div>
</li>
<li class="level1"><div class="li"> Mailzugriff wieder einschalten</div>
</li>
</ul>
<p>
leider mit dem Nachteil, das zwischen Ab- und Einschalten 1 bis 5 Tage liegen würden. Wir haben uns daher für eine Methode entschieden bei der Mailboxen fast unterbrechnungsfrei kopiert werden können. Lediglich einmal werden alle Benutzerverbindungen getrennt, wobei die Klienten diese in der Regel nach einigen Sekunden wieder selbständig aufbauen. Das äußert sich i.d.R. nur durch ein kurzes „Ruckeln“ am Klienten.
</p>
<p>
Der Ablauf ist dann in etwa der folgende:
</p>
<ul>
<li class="level1"><div class="li"> E-Mails vom alten Speicherort in den neuen kopieren</div>
</li>
<li class="level1"><div class="li"> E-Mails die während des ersten Kopiervorgangs eingetroffen oder geändert wurden in den neuen Speicherort kopieren</div>
</li>
<li class="level1"><div class="li"> Benutzer-Einstellungen kopieren und Mailboxspeicherort auf den neuen Speicherort ändern Mailboxverbindungen trennen</div>
</li>
<li class="level1"><div class="li"> E-Mails die evtl. seit dem letzten Kopiervorgang eingetroffen oder geändert wurden in den neuen Speicherort kopieren</div>
</li>
</ul>
<p>
Das hat dann natürlich den Nachteil, dass es länger dauert bis wirklich alle Mailboxen in das neue Speichersystem umkopiert wurden. Diesen Kopiervorgang haben wir am 10.10.2020 gestartet und er wird, aufgrund der oben beschriebenen Datenmengen, voraussichtlich bis Anfang Februar andauern.
</p>
text/html2020-09-01T08:57:08+00:00Robin DärmannAktualisierung der Software unserer Aggregation Switches
https://noc.rub.de/web/blog/2020/software-updates_auf_aggregation-switches
<h2 class="sectionedit1" id="aktualisierung_der_software_unserer_aggregation_switches">Aktualisierung der Software unserer Aggregation Switches</h2>
<div class="level2">
<p>
Dieser Artikel soll einige Hintergrundinformationen für technisch Interessierte zu den aktuellen Ereignissen (siehe Statushinweise unter <a href="https://noc.rub.de/status" class="urlextern" title="https://noc.rub.de/status" rel="ugc nofollow">https://noc.rub.de/status</a>) im Datennetz liefern.
</p>
</div>
<!-- EDIT{"target":"section","name":"Aktualisierung der Software unserer Aggregation Switches","hid":"aktualisierung_der_software_unserer_aggregation_switches","codeblockOffset":0,"secid":1,"range":"1-259"} -->
<h3 class="sectionedit2" id="aggregation_switches_bekommen_neue_software">Aggregation Switches bekommen neue Software</h3>
<div class="level3">
<p>
Zentrale Komponenten des Datennetzes - genauer gesagt unsere Aggregation Switches - werden zur Zeit mit neuer Software versorgt. Die Software-Updates erfordern mehrere Neustarts, die jeweils zu einer Netzwerkunterbrechung führen. Mehrere Neustarts deshalb, weil wir in mehreren Schritten aktualisieren müssen.
</p>
</div>
<!-- EDIT{"target":"section","name":"Aggregation Switches bekommen neue Software","hid":"aggregation_switches_bekommen_neue_software","codeblockOffset":0,"secid":2,"range":"260-628"} -->
<h3 class="sectionedit3" id="warum_tun_wir_das">Warum tun wir das?</h3>
<div class="level3">
<p>
Für die anstehenden Software-Updates gibt es mehrere Gründe. Wir haben die betreffenden Switches im Jahr 2018 eingebaut und in Betrieb genommen. Seitdem kämpfen wir mit kleineren und teilweise auch mit nicht ganz so kleinen Problemen. Es gibt inzwischen vielversprechende Software-Updates des Herstellers Cisco (die wir auch bereits getestet haben), so dass sich für uns diese Update-Prozedur lohnen wird.
</p>
</div>
<!-- EDIT{"target":"section","name":"Warum tun wir das?","hid":"warum_tun_wir_das","codeblockOffset":0,"secid":3,"range":"629-1070"} -->
<h3 class="sectionedit4" id="warum_sind_die_switches_so_wichtig">Warum sind die Switches so wichtig?</h3>
<div class="level3">
<p>
So ein Switch transportiert ja Daten, also zum Beispiel die E-Mails und Webseiten, die Sie mit Ihren Geräten aufrufen und versenden. Egal, ob es sich um ein Gerät im WLAN oder an einem kabelgebundenen Anschluss handelt. Letztendlich landen die Daten immer in einem Kabel, was runter in den Keller des Gebäudes geht und dort an einem Aggregation Switch angeschlossen ist. Dieses Gerät sammelt die Leitungen aller Verteiler im Gebäude und führt sie zusammen auf einen Router.
</p>
<p>
Fällt so ein Aggregation Switch aus, funktioniert das Datennetz (auch WLAN und Telefonie) in einem Gebäude nicht mehr. Das wollen wir natürlich vermeiden, weshalb wir mehrere Dinge tun:
</p>
<p>
Zum Einen werden die Aggregation Switches, die zwischen den Etagen-Switches (Access Switches) und den Routern sitzen, wenn möglich redundant ausgelegt. Die redundante Auslegung ist aber bisher nur in den Neubauten IA, IB und GD realisiert, die Aggregation Switches aller anderen Gebäude und Bereiche sind aus verschiedenen Gründen (meistens praktische Machbarkeit, fehlende oder zu alte Glasfaserverbindungen) nicht redundant vorhanden.
</p>
<p>
Zum Anderen aktualisieren wir hin und wieder die Software auf den Geräten - wie auch jetzt. Herstellerseitig werden Bugfixes vorgenommen, also Fehler beseitigt (leider manchmal auch neue Fehler eingebaut). Wir handeln hier in der Regel proaktiv, wenn sich ein Problem anbahnt (verdreckte Glasfaserleitung, merkwürdige Beobachtungen was den Speicherbedarf einzelner Prozesse angeht etc.). Wir tauschen dann gegebenenfalls kurzfristig ein Gerät aus oder starten es neu (immer mit Ankündigung).
</p>
</div>
<!-- EDIT{"target":"section","name":"Warum sind die Switches so wichtig?","hid":"warum_sind_die_switches_so_wichtig","codeblockOffset":0,"secid":4,"range":"1071-2727"} -->
<h3 class="sectionedit5" id="warum_nicht_nachts">Warum nicht nachts?</h3>
<div class="level3">
<p>
Wir könnten die Neustarts natürlich auch (wie es z.B. die Telekom durchaus auch bei DSL-Anschlüssen macht) mitten in der Nacht durchführen. Das geht zwar grundsätzlich sogar automatisch (mit Befehlen wie „reload at [Uhrzeit]“), dann müssten wir jedoch zur Sicherheit trotzdem eine Nachtschicht schieben. Es kann ja immer mal was schief gehen, wie beispielsweise neulich im ZEMOS. Der dortige Aggregation Switch wollte einfach nicht neu starten und musste einmal „angeschubst“ werden. Leider lässt die Qualität der Hardware in diesen Belangen in den letzten Jahren deutlich nach - zumindest unserer Beobachtung nach…
</p>
<p>
Es gibt noch einen weiteren, viel wichtigeren Grund warum wir das lieber früh morgens statt in der Nacht tun: Backups. Viele Lehrstühle betreiben irgendwo Dienste, die nachts automatisch Backups durchführen. Diese wollen wir wenn möglich nicht unterbrechen, weshalb wir uns auf unsere Traffic-Statistiken verlassen und die Zeit wählen, zu der im Datennetz am wenigsten los ist. Das ist in der Regel morgens früh der Fall.
</p>
</div>
<!-- EDIT{"target":"section","name":"Warum nicht nachts?","hid":"warum_nicht_nachts","codeblockOffset":0,"secid":5,"range":"2728-3815"} -->
<h3 class="sectionedit6" id="was_ist_mit_redundanten_gebaeuden">Was ist mit redundanten Gebäuden?</h3>
<div class="level3">
<p>
Nun ist es jedoch so, dass wir auch in den Bereichen mit redundant ausgelegtem Aggregation Layer (IA, IB und GD) bisher nicht ohne Netzwerkunterbrechung aktualisieren können, weil die aktuell auf diesen Switches laufende Software-Version das noch nicht unterstützt. Mit dem ersten Update, welches wir aktuell nach und nach auf den Aggregation Switches durchführen, kommt die Unterstützung für sogenannte In-Service Software-Updates (ISSU), sodass folgende Aktualisierungen dort keine Netzwerkunterbrechung mehr zur Folge haben werden. Das haben wir sogar bereits an einem Pärchen getestet - und keiner hat's gemerkt. <img src="https://noc.rub.de/web/lib/images/smileys/wink.svg" class="icon smiley" alt=";-)" />
</p>
<p>
Alle weiteren Aggregation Switches werden wir im Anschluss (in ein paar Wochen) noch einmal neu starten müssen, dazu wird es dann wieder separate Ankündigungen geben.
</p>
</div>
<!-- EDIT{"target":"section","name":"Was ist mit redundanten Geb\u00e4uden?","hid":"was_ist_mit_redundanten_gebaeuden","codeblockOffset":0,"secid":6,"range":"3816-4660"} -->
<h3 class="sectionedit7" id="und_mit_den_routern">...und mit den Routern?</h3>
<div class="level3">
<p>
Die Router sind aktuell nicht im Fokus von Software-Updates, das folgt später wieder. Auch hier gilt natürlich, dass wir hin und wieder Software-Aktualisierungen vornehmen. Allerdings sind die Router auf dem kompletten Campus redundant aufgebaut und angeschlossen, d.h. der Ausfall eines Routers - sei es ungeplant wegen eines technischen Problems oder geplant wegen eines Software-Updates - führt in der Regel zu keinerlei Einschränkung des Betriebs.
</p>
</div>
<!-- EDIT{"target":"section","name":"...und mit den Routern?","hid":"und_mit_den_routern","codeblockOffset":0,"secid":7,"range":"4661-5153"} -->
<h3 class="sectionedit8" id="und_den_externen_liegenschaften">...und den externen Liegenschaften?</h3>
<div class="level3">
<p>
Anders als bei den Routern sieht das mit der Redundanz in den externen Liegenschaften aus. Dorthin haben wir in der Regel nur eine Verbindung, so dass eine redundante Auslegung des Routers keinen Sinn ergibt, weshalb wir uns das dort sparen. Wir versuchen insbesondere dort immer, die Neustarts in eine nutzungsarme Zeit zu legen.
</p>
<p>
Die Gebäude auf dem Gelände Mark 51°7 (ehem. Opel-Werk) werden jedoch redundant angebunden werden und auch redundantes Routing bekommen.
</p>
</div>
<!-- EDIT{"target":"section","name":"...und den externen Liegenschaften?","hid":"und_den_externen_liegenschaften","codeblockOffset":0,"secid":8,"range":"5154-5674"} -->
<h3 class="sectionedit9" id="und_den_access_switches">...und den Access Switches?</h3>
<div class="level3">
<p>
Dann wären da noch die Access Switches. Das sind die Switches, die in unseren Netzwerkverteilern auf jeder Etage verbaut sind. Es handelt sich aktuell um knapp 3.000 Geräte. Auch diese benötigen hin und wieder Updates. In der Regel machen wir das häppchenweise so nebenbei (in Absprache mit den Netzbetreuern), wir müssen allerdings demnächst auch in diesem Bereich einmal größere Stückzahlen aktualisieren, dazu wird es dann aber noch einen eigenen Artikel geben.
</p>
</div>
<!-- EDIT{"target":"section","name":"...und den Access Switches?","hid":"und_den_access_switches","codeblockOffset":0,"secid":9,"range":"5675-"} -->text/html2018-04-25T13:08:11+00:00Robin DärmannInformationen zur Netz-Modernisierung 2018
https://noc.rub.de/web/blog/2018/netz-modernisierung-2018
<h2 class="sectionedit1" id="informationen_zur_netz-modernisierung_2018">Informationen zur Netz-Modernisierung 2018</h2>
<div class="level2">
<p>
Die teilweise über 15 Jahre alten Router und Switches in den zentralen Bereichen des Datennetzes bedürfen dringend einer Modernisierung. Wir stehen vor der Problematik, dass unser zentraler Netzknoten, an welchem sämtliche Glasfaserverbindungen des Campus zusammen laufen, vom Gebäude NAFOF nach IB umziehen muss. Inklusive angemieteter Leitungen bei diversen Providern. Dies muss relativ schnell nach der Inbetriebnahme des neuen Gebäudes geschehen und soll möglichst reibungsarm ablaufen.
</p>
<p>
Um die Wahrscheinlichkeit zu minimieren, dass es beim Umzug sämtlicher zentraler Komponenten zu Kollateralschäden kommt, planen wir das Vorhaben schon seit einiger Zeit und sind laufend damit beschäftigt, Ordnung in die gewachsenen Strukturen zu bringen und alles so zu dokumentieren, dass wir den Umzug mit möglichst ruhigem Gewissen durchführen können. Teil der Planung dieses komplexen Vorhabens ist die Erneuerung unserer zentralen Komponenten VOR dem Umzug. Wir möchten weder mit den alten Komponenten umziehen noch eine komplette Hardware-Erneuerung während des Umzugs durchführen, da die alte Hardware nicht 1:1 durch neue Komponenten ersetzbar ist und dies damit auch logische Veränderungen mit sich ziehen würde, die den Aufwand und die Komplexität des Vorhabens unnötig erhöhen würden. Deshalb ziehen wir die Hardware-Erneuerung vor.
</p>
</div>
<!-- EDIT{"target":"section","name":"Informationen zur Netz-Modernisierung 2018","hid":"informationen_zur_netz-modernisierung_2018","codeblockOffset":0,"secid":1,"range":"1-1415"} -->
<h3 class="sectionedit2" id="aenderungen_in_der_netz-topologie">Änderungen in der Netz-Topologie</h3>
<div class="level3">
<p>
Bisher war das Campus-Netz eine klassische Stern-Topologie. Das bedeutet, dass sämtliche Router (jeweils einer pro Gebäude) direkt mit einem Switch in der „Mitte“ (NAFOF) verbunden sind und durch diesen miteinander und mit dem Rest der Welt (Internet) kommunizieren. Diese Topologie hat unter anderem folgende Nachteile:
</p>
<ul>
<li class="level1"><div class="li"> Es gibt nur EINEN zentralen Switch. Dieser kann redundant, also doppelt ausgelegt werden (so ist das bei uns), jedoch bilden die beiden Geräte dann logisch eine Einheit mit genau einer gebündelten Ethernet-Verbindung zu jedem Router (LACP Ether-Channel)</div>
</li>
<li class="level1"><div class="li"> Bei Ausfall oder Neustart des zentralen Switches (z.B. bei Software-Updates) liegt die gebäudeübergreifende sowie die Internet-Kommunikation brach</div>
</li>
<li class="level1"><div class="li"> Neben gebridgten Ethernet-Verbindungen (über mehrere Gebäude durchgeschaltete Vlans) muss der zentrale Switch auf den selben Verbindungen auch sämtliche geroutete Kommunikation transportieren</div>
</li>
</ul>
<p>
Man hat dieses Prinzip in der Vergangenheit gerne verfolgt, weil die Implementierung sehr einfach und die Fehleranfälligkeit gering ist. Wir hatten in über 15 Jahren nicht einen zentralen Komplett-Ausfall, der nicht taggleich mit vorhandener Ersatz-Hardware zu reparieren gewesen wäre. Mittlerweile haben wir jedoch einen Stand der Technik erreicht, in dem IP-Kommunikation wichtiger denn je ist. Als Beispiel sei hier die Telefonie (Voice-over-IP) genannt. Vor diesem Hintergrund ist die redundante Auslegung nicht nur aller Router sondern auch aller Verbindungen praktisch nicht mehr weg zu diskutieren.
</p>
<p>
Die neue Netztopologie wird daher die zentralen Router in einem Ring miteinander verbinden, so dass die gebäudeübergreifende IP-Kommunikation sowie die Verbindungen ins Internet über redundante, geroutete Strecken mit 80 GBit/s transportiert werden. Ein Router wird jeweils eine komplette Gebäudereihe versorgen (G-Reihe, N-Reihe, I-Reihe sowie MA und Zentralachse). Übergangsweise wird es den zentralen Stern-Mittelpunkt noch geben um Spezialfälle so lange abzuwickeln, bis sie umgebaut sind. Teilweise sind das historische Altlasten, wo erst geklärt werden muss, was zu tun ist und wer das tun kann. Perspektivisch soll es den Stern dann aber nicht mehr geben.
</p>
</div>
<!-- EDIT{"target":"section","name":"\u00c4nderungen in der Netz-Topologie","hid":"aenderungen_in_der_netz-topologie","codeblockOffset":0,"secid":2,"range":"1416-3679"} -->
<h3 class="sectionedit3" id="relevantes_fuer_netzbetreuer">Relevantes für Netzbetreuer</h3>
<div class="level3">
<p>
Die Schaltung von Vlans über Gebäudegrenzen hinweg nehmen wir ja schon seit längerer Zeit nur noch ungerne vor. Das hat tatsächlich technische Gründe (die nächsten zwei Absätze können Sie überspringen, wenn Sie das technische nicht so interessiert):
</p>
<p>
Ein Vlan ist ein Ethernet-Segment. In einem Ethernet-Segment darf es immer nur exakt eine Verbindung von A nach B geben. Das allein sollte einem beim Aufbau redundanter Strukturen schon zu Denken geben. Abhilfe schafft hier das Spanning-Tree Protokoll. Es sorgt dafür, dass bei mehreren vorhandenen Verbindungen zwischen A und B immer nur eine Verbindung in Betrieb ist. Spanning-Tree ist absolut notwenig, jedoch stammt es aus den 1980ern, einer Zeit in der man über Redundanz noch nicht wirklich nachgedacht hat. Es ist daher auch eigentlich nur ein Hilfsmittel um versehentliche Schleifen zu verhindern, damit keine Brodacast-Stürme entstehen, durch die das komplette Netzwerk zum Erliegen kommt.
</p>
<p>
Um also redundante Verbindungen mit Umschwenkzeiten im Millisekundenbereich zu ermöglichen, muss man die Redundanz anders erledigen. Das geht nach heutigem Stand der Technik nur mit IP. Wir machen das indem wir geroutete Verbindungen zwischen den Gebäuden schaffen, die zudem um einiges schneller sind als die geswitchte Verbindung über den Stern-Mittelpunkt (80 GBit/s vs. 10 GBit/s).
</p>
<p>
Über geroutete Verbindungen können wir keine Vlans schalten. Das bedeutet, ein Vlan kann maximal an einem Router (d.h. in der Regel in einer Gebäudereihe) existieren. Wenn Sie Netz-Konnektivität in mehreren Gebäudereihen benötigen, bekommen Sie von uns ein weiteres Vlan mit separaten IP-Subnetzen (IPv4 und IPv6).
</p>
<p>
Gleiches gilt für die Unterstellung von Servern in Standorten des Datacenters: Sie bekommen für Ihre Server dort ein separates Vlan mit entsprechenden IPv4- und IPv6-Adressen. Die Kommunikation der Geräte zwischen den Vlans regeln Sie wie schon seit Jahren gewohnt per <abbr title="Access Control List">ACL</abbr> in unserem Netzbetreuer-Tool Alice. Wir unterstützen Sie da gerne.
</p>
<p>
Sollten Sie momentan Vlans im Einsatz haben, die sich über mehrere Gebäudereihen erstrecken, setzen Sie sich bitte bei Gelegenheit mit uns in Verbindung, damit wir diese entsprechend aufteilen können. Wenn Sie das nicht tun, werden wir uns irgendwann bei Ihnen melden.
</p>
</div>
<!-- EDIT{"target":"section","name":"Relevantes f\u00fcr Netzbetreuer","hid":"relevantes_fuer_netzbetreuer","codeblockOffset":0,"secid":3,"range":"3680-6014"} -->
<h3 class="sectionedit4" id="details_zur_umsetzung_der_netz-modernisierung">Details zur Umsetzung der Netz-Modernisierung</h3>
<div class="level3">
<p>
Die Modernisierung unserer Netzinfrastruktur haben wir in drei Phasen gegliedert:
</p>
<p>
In <strong>Phase 1</strong> tauschen wir sämtliche 10-Gigabit-Verteiler auf dem Campus gegen neue Geräte. Auf diese Verteiler sind direkt die Zuleitungen der Etagenverteiler gesteckt. Diese sind in der Regel nur einfach vorhanden, d.h. nicht redundant, was bedeutet, dass beim Umstecken ein kurzer Ausfall entsteht. Normalerweise merken Sie das an Ihren Endgeräten nicht, weil der Ethernet-Link nur zwischen Gebäudeverteiler und Etagenverteiler kurz aussetzt, nicht zwischen Etagenverteiler und Endgerät. VoIP-Telefonate brechen allerdings ab, da der Aussetzer zu lange dauert (ca. 15-30 Sekunden, wenn alles gut geht).
</p>
<p>
In <strong>Phase 2</strong> werden wir dann sämtliche Router auf dem Campus durch redundant ausgelegte, neue Router ersetzen. Hierbei wird es zumindest in der N-Reihe wieder einen Ausfall geben, der dann jedoch spürbar, weil länger, wird. Wir müssen in einigen Fällen aus Platzgründen zuerst das alte System aus unseren Schränken ausbauen und anschließend das neue System einbauen. Dies dauert einige Minuten und wird in den Morgenstunden, möglichst vor 8 Uhr passieren und jeweils gesondert angekündigt werden.
</p>
<p>
In <strong>Phase 3</strong> werden wir sämtliche Hauptverteiler in den angemieteten Aussenstellen der Ruhr-Universität tauschen. Hier wird es jeweils einen kurzen Ausfall geben, den wir mit den jeweiligen Netzbetreuern separat absprechen werden.
</p>
<p>
Phase 1 - Austausch der 10-Gigabit-Verteiler - ist mittlerweile (Stand: 25.04.2018) schon fast abgeschlossen. Es sind nur noch wenige Geräte zu tauschen, wir werden das in den nächsten Tagen durchführen. Phase 2 beginnt in Kürze, Phase 3 werden wir starten, wenn Phase 2 abgeschlossen ist.
</p>
</div>
<!-- EDIT{"target":"section","name":"Details zur Umsetzung der Netz-Modernisierung","hid":"details_zur_umsetzung_der_netz-modernisierung","codeblockOffset":0,"secid":4,"range":"6015-"} -->