Ankündigungen von Wartungsarbeiten und Meldungen von Ausfällen


#18

Nessus hat uns informiert, dass heute Nacht an der 1 GBIt/s-Verbindung zur Uni Wien (Teil unseres Backbone) gearbeitet wird:
24.07.2018 22:00 Uhr bis voraussichtlich 25.07.2018 04:00 zu Unterbrechnungen Ihrer Verbindung aufgrund
von Wartungsarbeiten kommen wird.

Es ist folgende Leitung betroffen: Interconnect 1G NDC1 UniVie

Wir werden vom Backbone das BGP-Routing mit Nessus in der Zeit runternehmen und der Roofnode rn02nessus wird die Default Routen heute Nacht nicht selbst announcen (kein HNA)!


#19

Hallo,

wir bauen am Freitag (10.8.2018) das Equipment bei Nessus auf Wunsch von Nessus in ein neues Rack. Dadurch wird va. die Anbindung für das Funknetz ab ca. 15:00/15:30 einige Zeit (ca. 2 Stunden?) nicht verfügbar sein.

LgS


#20

finde das cool wie sich das mit dem ankündigen hier entwickelt!
wollen wir das damit verbessern, dass wir aus diesem thread eine kategorie machen und dann threads themenbezogen erstellen?
(dann könnte man sich z.b. nur die für sich interessanten threads abonnieren… :slight_smile: )


#22

Liebe Freunde,

momentan haben wir am OZW leider keine gute Zeit. Nach dem gestrigen Tunnelaufall der noch immer andauert, ist heute am Dach des OZW ein fünf Port Switch ausgefallen, der die Router 130deg, 170deg und 220deg versorgt hatte.
Da wir Erstatz beschaffen müssen, sind die genannten Nodes momentan offline.

Falls jemand zufällig einen RB-750UP herumliegen hat und diesen nicht mehr benötigt, bitte bei mir melden…!

Grüße
Gottfried


#23

hi gottfried,
falls noch aktuell, ich hätte zwei solcher dinger rumliegen und brauch sie nicht, gebe ich gerne ab.
lg


#24

Hi,
hat sich mittlerweile erledigt. Aber vielen Dank für das Angebot!

Gottfried


#25

Am heutigen 07.01.2019 gab es Probleme mit dem Routing für 2a02:60:100::/40, dem alten Prefix für OLSR (OLSRv1+IPv6). Durch einen Dokumentationsmangel war nicht erkennbar, dass der Tunnelserver 6 (tunnel6) der letzte Uplink für diesen Netzbereich zu den Core-Routern war.
Tunnel6 galt als obsolet und wurde in Vorbereitung der Migrationen von virtuellen Maschinen auf den Host „Ford“ abgeschaltet. Dadurch wurde das Problem einer für den neuen Tunnelserver (ts2018) fehlenden statischen Route von den Core- bzw Roofnode-Routern schlagend.
@pocki hat unter eifriger Mithilfe des Backbone-Teams nun die Route mittels OSPF auf ts2018 angekündigt.

Es wird den verbleibenden Teilnehmern des OLSRv1+IPv6-Dienstes dennoch empfohlen, eine Migration auf IPv6+OLSRv2 ( Projekt v642 ) anzustreben, um über die bessere Redundanz, die für den Prefix 2a02:61::/32 gegeben ist, zu verfügen.


#26

IPv6 am OZW geht wieder.

In der Core Mailing Liste stand zu lesen, dass der Adressbereich 2a02:60:100::/40 nun wieder als freigegeben markiert wurde. Dass dies falsch ist und hier nach wie vor Nodes aktiv sind, ist hoffentlich schon klar !!!

Grüße
Gottfried


#27

Gottfried, du hast hier vollkommen Recht!

Durch den Ausfall wurde augenscheinlich, dass im Adressbereich 2a02:60:100::/40 noch Leben herrscht. Daher haben wir diesen Prefix auf Suidao via OSPF (bird6) gegenüber den Coreroutern angekündigt. Der Prefix 2a02:60:100::/40 wird also von r01krypta und r01nessus direkt zu Suidao gesendet. Dort übernimmt der olsrd6 (olsr-v1) das weitere Routing in Richtung OpenVPN-Tunnel-Clients.

Noch vorhandene Routen von olsrd6:
http://tunnel.funkfeuer.at/olsrd6_route.php


#28

Am heutigen 9. Jänner 2019 zwischen 21 und 23 Uhr wird im Zuge von Wartungsarbeiten ein Reboot des Tunnelservers durchgeführt werden. Es ist mit einer bis zu fünf Minuten dauernden Unterbrechung der Tunneldienste zu rechnen.


#29

Am heutigen 6. Februar 2019 kommt es um ca. 01:55 zu einer kurzen Unterbrechung bei den Diensten des Tunnelservers.


#30

Es kommt jetzt zu einem Reboot der Tunnelserver-VM. Grund sind dringend notwendige Optimierungen im Zusammenhang mit OLSR-Abstürzen in der jüngeren Vergangenheit.


#31

Könnt ihr euch noch zu Matrix / Riot / in den Funkfeuer Chat einloggen? Mein Client meldet nur mehr:

Connectivity to the server has been lost.


#32

https://riot.im/

Down for Emergency Maintenance

See https://twitter.com/matrixdotorg for more information.


https://twitter.com/matrixdotorg

Matrix ‏ @ matrixdotorg 3 Std.vor 3 Stunden

More details to follow, but the security maintenance is to address issues with http://Matrix.org 's production infrastructure. This is not a Synapse issue.


Matrix ‏ @ matrixdotorg 3 Std.Vor 3 Stunden

We’ve taken down the servers which host http://Matrix.org and http://Riot.im for emergency security maintenance - estimated downtime is several hours. More updates as we have them.


#33

ah, thx. stimmt, auf die Idee hätt’ ich auch kommen können einfach mal auf die Website zu schaun :wink:


#34

scheinbar was wirklich kritisches, sonst hätte man das geplant… meine verbindung vom online client war auch ganz plötzlich weg.


#35

Matrix ‏ @ matrixdotorg 8 Min.vor 8 Minuten

We are currently rebuilding our production infrastructure; work is in progress - please bear with us!


#36

Matrix ‏ @ matrixdotorg 34 Min.Vor 34 Minuten

In terms of the incident itself, we will publish an update shortly. Summary is: an attacker accessed the production infra that runs http://matrix.org , hence the rebuild. Source code & packages are unaffected. We do not think user data was targeted, but are playing it safe.


Matrix ‏ @ matrixdotorg 48 Min.Vor 48 Minuten

We’ve been hitting problems whilst rebuilding production from scratch; there’s still several hours before we get back online - many apologies for the downtime, but we have to play it safe.


#37

Matrix ‏ @ matrixdotorg 2 Std.Vor 2 Stunden

We are almost at the point of getting things turned back on; websites, databases, synapse, LBs, etc are ready to go. Just sorting final networking issues between them. Thank you for your patience, and apologies for the massive disruption…


#38

Das Hostsystem unseres Tunnelservers hängt momentan - somit haben wir einen Ausfall aller Tunnel. Die Störung betrifft auch IPv6 im Prefix 2a02:60:100::. Behebung der Störung erfordert Krypta-Zugang.

Update: System läuft seit 2019-05-15 03:43:33 (host) 2019-05-15 03:44:06 (vm) wieder. Danke!
Update: Ursache - Ein Systemdienst (swap) auf der VM hat sich beim außerplanmäßigen Reboot (Dringende Updates auf dem Wirtsystem) bis zum Systemd-Timeout von 30 Minuten aufgehängt und Host und VM so in einem 30 Minuten dauernden Zustand ohne Netzwerkanbindung und sonstige Prozesse gehalten. Danach lief der Bootprozess wieder normal durch.