<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/trouble-tickets/single-ticket.xsl"?>

<ticket>
  <meta>
    <id>750</id>
    <filename>750.xml</filename>
    <subject><![CDATA[Störung gewisser Peerings und Transits in Frankfurt]]></subject>
    <status>closed</status>
    <short-description><![CDATA[Aktuell besteht eine Störung bei Peering- und Transit-Verbindungen am Standort Frankfurt. Betroffen sind insbesondere IPv6-Verbindungen, verursacht durch ein BGP-Problem mit einer zu hohen Anzahl an Attributen. 
Verbindungen zu Adressen außerhalb des BelWü können hierdurch beeinträchtigt sein.

Die Ursachenanalyse läuft. Wir informieren in Kürze über weitere Details und den Fortschritt der Behebung.]]></short-description>
    <creation-time>2026-08-05 10:46:18</creation-time>
    <creation-time-timezone></creation-time-timezone>
    <creation-time-unix>1785919578</creation-time-unix>
    <closing-time>2026-08-14 18:13:28</closing-time>
    <closing-time-timezone></closing-time-timezone>
    <closing-time-unix>1786724008</closing-time-unix>
    <location><![CDATA[FRA-DECIX]]></location>
    <planned>false</planned>
    <ticket-meta-type><![CDATA[Software]]></ticket-meta-type>
    <ticket-start-work>2026-08-05 10:12</ticket-start-work>
    <ticket-end-work>2026-08-05 11:30</ticket-end-work>
    <ticket-start-work-unix>1785917520</ticket-start-work-unix>
    <ticket-end-work-unix>1785922200</ticket-end-work-unix>
  </meta>
  <actions>
    <update>
      <id>1</id>
      <timestamp>2026-08-05 11:39:36</timestamp>
      <timezone>+02</timezone>
      <text><![CDATA[Es gab ein Problem mit dem Transit über die Deutsche Telekom. Da einige andere Provider Routen über die Deutsche Telekom präferieren, kam es auch aus diesen Netzen zu Problemen.

Wir haben daraufhin alle Advertisements in Richtung Deutsche Telekom zurückgezogen. Trotz unseres Withdraws dauerte es rund 30 Minuten, bis die Deutsche Telekom unsere Routen nicht mehr an andere Netze advertiste.

Wir sind derzeit noch unsicher, ob die Ursache auf unserem Router lag oder ob ein Problem bei der Deutschen Telekom vorlag. 

]]></text>
    </update>
    <update>
      <id>2</id>
      <timestamp>2026-08-05 13:05:29</timestamp>
      <timezone>+02</timezone>
      <text><![CDATA[Update – Störung Router Frankfurt

Nachtrag zur Ursache: Der BGP-Prozess auf dem Router in Frankfurt am DECIX (fra-decix-a99) ist mehrfach gecrasht. Non-Stop-Routing (NSR) übernahm zunächst. Auf dem zweiten RSP lief noch ein BGP Prozess, der teilweise Routen an unsere Peers andvertiste. Allerdings akzeptierte der Router selbst keine Präfixe/Routen mehr. Die FIB geriet dadurch in einen undefinierten Zustand, wodurch eingehender Traffic per uRPF verworfen wurde. 
Als sich die Prozesse erholten, nahm die anschließende Konvergenz nahm längere Zeit in Anspruch.

Aktueller Stand:
Telekom- und Telia-Transit in Frankfurt sind gedrained, Traffic läuft übergangsweise über Transit Stuttgart und über NTT in Frankfurt (fra-tc-a99). 

Wir haben mittlerweile Core-Dumps von den Routern gezogen. 
Weitere Klärung mit dem Cisco TAC ist im Gange.]]></text>
    </update>
    <update>
      <id>3</id>
      <timestamp>2026-08-05 14:48:40</timestamp>
      <timezone>+02</timezone>
      <text><![CDATA[Wir sind mittlerweile schlauer: 
Einige Zeit vor dem Ausfall haben wir routinemäßig alte, nicht mehr genutzt BGP Peering-Configs aufgeräumt. 
Das triggerte einen Use-After-Free Bug im BGP Prozess auf dem Router. Der BGP Prozess beendete sich dann mit einem SIGSEGV.

Wir sind mit dem Hersteller dabei, an einer Lösung zu arbeiten. ]]></text>
    </update>
    <update>
      <id>4</id>
      <timestamp>2026-08-14 15:51:25</timestamp>
      <timezone>+02</timezone>
      <text><![CDATA[Seit heute Mittag sind wieder alle Transitverbindungen und alle Funktionen aktiv, die als Vorsichtsmaßnahmen deaktiviert waren.

Das Problem wurde vom Hersteller aus Softwarefehler eingestuft. Er war dem Hersteller bisher offenbar nicht bekannt, hat keine ID im Bugtracker und es ist derzeit unklar, ob es ein Software-Release ohne den Fehler gibt, bzw. ob er behoben wird. Unsere Logs zeigen, dass der gleiche Fehler bereits mehrfach aufgetreten war, aber vermutlich weniger schwere Auswirkungen hatte und daher nicht bemerkt wurde.]]></text>
    </update>
  </actions>
</ticket>
