Eng ↴
  • Ger
  • Eng
  • Tag cloud
  • Site map
  • Login Login
    Forgot your password?
Lutz Donnerhacke
Navigation
  • Projekte
  • Veröffentlichungen
  • Blog
  • Impressum
  • GDPR
  • Search

Search

Search for "9" returned 27 matches

Was taugen Schnelltests?

14/04/2021 11:54 pm Lutz Donnerhacke Tags: Corona 0

Was taugen also diese Antigen-Tests die für Schnell- und Selbsttests eingesetzt werden? Prof. Drosten hat ja in seinem gestrigen Podcast auch auf die hohe Fehlerquote des Tests verwiesen. Hier lohnt es sich genau hin zu schauen …

Antigen- oder Lateral-Flow-Tests bekommen eine Probe eines Nasen/Rachenabstriches vorgelegt, die dann in einer Lösung langsam den Teststreifen entlang kriecht (das ist der lateral flow). In zwei Querstreifen befinden sich Farbstoffe, die an Sensormoleküle gebunden sind. Der weiter entfernte Querstreifen reagiert auf das Lösungsmittel und zeigt somit an, dass der Test korrekt benutzt wurde. Am eigentlichen Test-Querstreifen ist der Farbstoff an Antikörper gebunden, die spezifisch auf bestimmte Viruseiweiße reagieren. Derartige Antikörper sind auch Bestandteil des Immunsystems, sie dienen der Erkennung schädlicher Eindringlinge.

Problemfelder

Was kann dabei schief gehen?

Zunächst mal könnte es ein anderes Material geben, dass den Farbstoff zum Leuchten bringt. Säuren sind da beispielsweise geeignet. Deswegen sollte man einige Zeit vor einem Test nichts trinken (außer Wasser). Andere Krankheitserreger lösen den Antikörper nicht aus. Es ist jedoch denkbar, dass nahe Verwandte des SARS-CoV2 ebenfalls eine Reaktion hervor rufen. Praktisch bekannt sind solche Fälle bisher nicht.

Ist wenig Virusmaterial vorhanden, so gibt es nur eine sehr schwache oder gar keine Verfärbung des Teststreifens. Man könnte also eine schwache Linie für fälschlich negativ halten. Dass kein oder zu wenig Material vor liegt kann nicht nur daran liegen, dass die Person virenfrei ist, sondern auch an einem fehlerhaften Abstrich. Wer also nur kurz durch die Nase huscht, riskiert eine zu geringe Probenentnahme. Auch kann die Nase gerade frisch gereinigt worden (Nasenspray etc.) und so evtl. vorhandenes Virenmaterial beseitigt sein.

Darüber hinaus variiert die Virenmenge in den oberen Atemwegen während des Krankheitsverlaufs. So steigt die Virenlast erst einige Tage an (und der Test erkennt nichts), dann ist man infektiös (und der Test schlägt an). bekommt evtl. Symptome, weil sich das Virus in die Lunge verlagern (der Test schlägt nicht mehr an). Insbesondere die ersten Tage stellen ein Problem dar, denn obwohl der Test (gerade noch) negativ ist, ist man einige Zeit später schon infektiös.

Aber auch Umgebungseinflüsse können den Test beeinträchtigen. Ist es zu warm oder zu kalt, erfolgt die notwendige Nachweisreaktion nicht in der benötigten Stärke, der Test wird so unbrauchbar. Natürlich können auch Proben vertauscht werden. Und man sollte die Teststäbchen auch nicht mehrfach benutzen.

Fazit

Summiert man all diese Fehlermöglichkeiten auf, so stellt sich heraus, dass in der Praxis ein positiver Schnelltest fast immer auch eine positive PCR Bestätigung bekommt. Die Fälle in denen der Test falsch positiv ist, sind meist durch Fremdeinwirkung (z.B. Trinken von Cola oder Fruchtsaft) zurück zu führen. Andererseits sagt ein negativer Test wenig aus, denn an drei von acht Tagen des typischen Infektionsverlaufs bleibt er aufgrund der niedrigeren Virenlast negativ. Schlechte Abstriche und falsche Handhabung dazu, kann eine infizierte Person in 40% der Fälle fälschlich als negativ bewertet werden.

Kürzlich hat das RKI davon geschrieben, dass Geimpfte genauso angesehen werden sollen, wie negativ Getestete. Das ist in Anbetracht der gerade vorgenommen Ausführungen völlig verständlich: Geimpfte können sich zwar wieder infizieren und diese Infektion auch weiter geben, aber die Wahrscheinlichkeit dafür ist mit höchstens 10% deutlich kleiner als die 40% false-negative Wahrscheinlichkeit eines Schnelltests.

Das ist deutlich weniger als die Politik aus der Aussage heraus zu lesen versucht: Geimpfte sind also ebenso wenig wie negativ Getestete garantiert ungefährlich, sondern übertragen in einer vergleichbaren Größenordnung das Virus trotzdem weiter.

Der Krux mit den Prozenten

Nehmen wir ein Beispiel: In einer größeren Stadt wurden 10000 Schnelltests an einem Tag durchgeführt. Dabei wurden 20 positive Tests ermittelt. Die Inzidenz in der Gegend liegt bei 150.

Mit einer unbekannten Dunkelziffer (die die Anzahl der Infizierten nach oben treiben würde) und einer Vorselektion auf komplett symptomfreie Nutzer der Schnelltests (was die Anzahl nach unten treibt) ist es eine mögliche Annahme, dass sich diese beiden Effekte neutralisieren. Man kann also die Inzidenz direkt auf die Testmenge anwenden und würde somit 15 Infizierte unter den 10000 Test-Kandidaten erwarten.

Von den 15 Infizierten haben 40% ein falsch-negatives Ergebnis: 6 Personen bekommen also einen negativen Befund, obwohl sie aktive Virenträger sind. Die restlichen 9 Infizierten werden korrekt erkannt. Da aber 20 positive Tests vorliegen, sind elf Personen mit falsch-positiven Resultaten dazu gekommen.

Wenn man selbst zum Testen geht, interessiert man sich natürlich nur für die Wahrscheinlichkeit die der Test bei einem persönlich hat. Ob man infiziert ist oder nicht, weiß man ja nicht. Also gehört man zur Gesamtheit der getesteten Personen. Und da hat der Test also:

  • 11 von 10000 = 0,11% falsch-positive Wahrscheinlichkeit
  • 6 von 10000 = 0,06% falsch-negative Wahrscheinlichkeit

Hat man dann wirklich einen positiven Test (was erst mal unwahrscheinlich ist), dann kann der zu über 50% falsch-positiv sein. Diese massive Vergrößerung ist als bedingte Wahrscheinlichkeit bekannt und der menschlichen Intuition fremd.

Dieses Verschätzen der Intuition ist in die andere Richtung noch viel extremer. Aus der Angabe 40% nimmt man einfach an, dann 4000 Virenträger unerkannt durch die Tests kommen! Real sind es aber nur sechs Personen, also 1,5 Promille der intuitiven Vorstellung.

Schnelltests filtern also Infizierte aus der Masse heraus, verringern aber die Anzahl der Infizierten nicht ausreichend.

Die Verwendung von Schnelltests als Freigabe für Öffnungen und Treffen ist bei hohen Infektionszahlen schlicht fahrlässig. Nur bei niedrigen Inzidenzwerten eignen sich Schnelltests für diesen Zweck. Sie dienen dann dem Auffinden von noch unbekannten Infektionsclustern in einer fast komplett virenfreien Umgebung.

TCAM full - Überraschender Totalausfall

07/11/2020 9:52 am Lutz Donnerhacke Tags: IPv6 , Internet , Cisco , WTF , Broadband , Multicast , QoS , ARP 5

Gestern gegen Mittag gab es bei einem Kunden eine großen Ausfall, drei zentrale Switche (von sechs) haben beinahe gleichzeitig nicht mehr ordnungsgemäß funktioniert. Es folgte stundenlange eine Odyssee, denn nach einem Reboot eines Switches hatte man knapp eine halbe Stunde bis er wieder ausfiel.

Ausgangslage

Nichts geht mehr. Spontan. Ohne Vorwarnung.

Alle Geräte, die hinter der Ausfallstelle sich befinden sind nicht mehr erreichbar. Kunden, Infrastruktur, Monitoring. Da auch DNS Server betroffen sind, gestaltet sich jeder Zugriff extrem zäh. Man wartet also teilweise eine Minute, bis man die Ergebnisse eines Kommandos zu Gesicht bekommt.

Eigentlich ist Redundanz gegeben: Wenn ein Gerät ausfällt, übernimmt ein anderes. Jetzt ist es aber anders. denn drei Geräte sind zeitgleich ausgefallen. Diese dienen dem Großteil der Infrastruktur als Uplink, was die Diagnosemöglichkeiten drastisch einschränkt.

In der Annahme, es handle sich um ein Problem, dass von einer defekten Komponente (z.B. ein Layer2-Loop) an einer Stelle eingespeist wird, wurde zunächst systematisch versucht, diese Stelle einzukreisen. Erfolglos.

Es blieb nichts weiter übrig, als einem der betroffenen Switche das Chassis stromlos zu machen, um Zugriff auf das Gerät zu bekommen und damit mehr Informationen zu erlangen. Vor einem solchen Hart-Reset scheut man normalerweise zurück, weil der komplette Reboot knapp 20 Minuten dauert.

Der Zugriff auf das frisch gebootet Gerät zeigt ... keine Auffälligkeiten. Das ist schlecht. Sehr schlecht. Denn damit gibt es keinen Ansatzpunkt, wo der Fehler her kommen könnte. Nach wenigen Minuten friert jedoch die Verbindung zum Gerät ein und es geht wieder nichts mehr.

In einer der Phasen gelingt es, Zugriff auf das Monitoring zu erlangen, dort findet sich ein erster Hinweis:

Nov  6 12:36:41 172.27.44.252 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate.  Failure due to: add tcam space failed
Nov  6 12:38:41 172.27.44.254 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate.  Failure due to: add tcam space failed
Nov  6 12:52:12 172.27.44.253 %C4K_L3HWFORWARDING-4-TCAMFULL: FLC Tcam full, packets will be forwarded in software at reduced rate.  Failure due to: add tcam space failed

Oops. Die Meldung besagt, dass eine Hardware-Komponente voll gelaufen ist und nun die gesamte Funktion des Gerätes durch Software emuliert werden muss. Dabei die die CPU des Gerätes für eine solche Last gar nicht ausgelegt, sie soll eigentlich nur die Hardware konfigurieren, so dass die Datenströme die CPU selbst nie treffen.

Das erklärt einige der Effekte: Zum einen fällt das Gerät selbst nicht aus, so dass die Umschaltung auf die Redundanztechnik nicht stattfinden kann. Zum anderen erfüllt es seine Funktion nicht mehr ausreichend. Wir haben Paketverluste von 99%, was einer Unbenutzbarkeit gleich kommt.

TCAM - ein teurer Spaß

Was ist nun dieses ominöse TCAM? TCAM ist im Endeffekt eine Hardware, in der Key-Value-Paare abgelegt werden können. Man kann direkt nach dem Schlüssel (Key) suchen und bekommt in einem Takt das Ergebnis aus dem TCAM ausgelesen. Das ist natürlich irre schnell.

Diese gute Einführung in die Funktion des TCAM enthält das schöne Funktionsbild:

cam-architecture

Auf einem TCAM Chip sind also Speicherzellen, die parallel die anliegende Datenanfrage mit den abgelegten Werten vergleichen und – wenn alles überein stimmt – die komplette Zeile aktivieren. Kann der Vergleicher nur 0/1, spricht man von CAM – Content Addressable Memory. Kann der Vergleicher auch den anliegenden Wert ignorieren, also einen dritten Zustand abbilden, so spricht man von TCAM – Tenary CAM.

Normalerweise müsste eine CPU den normalen Speicher nach dem Suchwert durchkämmen, um das Ergebnis zu ermitteln. Je nach Algorithmus dauert das, logarithmisches Wachstum der Suchzeit ist aber typisch. Dagegen hat der TCAM eine konstante Suchzeit von eins, das Ergebnis ist instantan verfügbar.

TCAM macht also die Geräte schnell, jedoch auch teuer. Deswegen versucht man den TCAM so effektiv wie möglich zu nutzen. Dabei trifft der Hersteller eine Reihe von Kompromissen.

Ein Teil des TCAM wird für QoS, ein Teil für ACLs, ein Teil für Layer2 (MAC Adressen), ein Teil für Layer3 (Routing), etc. pp, benutzt.

Wer hat meinen TCAM belegt?

Die Meldung im Log deutet darauf hin, dass der Layer3, also der Routing-Teil zu voll wird.

Das Datenblatt des Geräts schreibt:

  • 128,000 Flexible NetFlow entries in hardware
  • 64,000/32,000 IPv4/IPv6 routing entries for campus access and aggregation deployments
  • IPv6 in hardware, providing wire-rate forwarding for IPv6 networks and support for dual stack with innovative resource usage
  • Dynamic hardware forwarding-table allocations for ease of IPv4-to-IPv6 migration
  • Scalable routing (IPv4, IPv6, and multicast) tables, Layer 2 tables, and access-control-list (ACL) and quality-of-service (QoS) entries to make use of 8 queues per port and comprehensive security policies per port

All diese Punkte haben mit TCAM Kapazitäten zu tun.

Wir haben in dem Netz ca. 2500 IP4 Routen (meist für Kunden mit statischen IPs) und ca. 8000 IPv6 Routen (hauptsächlich IPv6-PD). Das liegt weit unter den Limits.

Wir haben pro Gerät höchstens 35k MAC Adressen, das haben wir aber schon lange im Blick und sorgen dafür, dass diese Werte nicht in kritische Bereiche ansteigen.

Wir haben NetFlow aktiv. Das ist verzichtbar, also wird das abgeschaltet. Keine Besserung.

Wir haben Multipath-Routing aktiv, um Datenpakete über mehrere Leitungswege zu verteilen. Das ist meist auch verzichtbar und wird dort abgeschaltet. Keine Besserung.

Wir haben anti-spoofing ACLs aktiv, die schon wichtig sind. Aber vor der Wahl – gar keine Funktion oder Bösewichter aufhalten – fällt die Entscheidung leicht, besonders, da wir es bisher nicht mit Bösewichtern zu tun hatten und es noch weitere Filter tiefer im Netz gibt. Allerdings auch wieder keine Besserung.

Was bleibt denn noch?

Schauen wir uns das TCAM für Layer3 mal genauer an:

#sh platform hardware ip route summary

block#  start   end     mode    entries used    free    group   type
0       80 Bit  0       4095    4096    4096    0       3       Dst
1       160 Bit 4096    8190    2048    104     1944    5       Dst
2       160 Bit 8192    12286   2048    439     1609    4       Dst
3       80 Bit  12288   16383   4096    4096    0       3       Dst
4       80 Bit  16384   20479   4096    4096    0       3       Dst
5       80 Bit  20480   24575   4096    4095    1       3       Dst
6       80 Bit  24576   28671   4096    4096    0       3       Dst
7       80 Bit  28672   32767   4096    4094    2       3       Dst
8       80 Bit  32768   36863   4096    4096    0       3       Dst
9       80 Bit  36864   40959   4096    3454    642     3       Dst
10      Unused  40960   45055   4096    0       4096    -       -
11      Unused  45056   49151   4096    0       4096    -       -
12      Unused  49152   53247   4096    0       4096    -       -
13      Unused  53248   57343   4096    0       4096    -       -
14      Unused  57344   61439   4096    0       4096    -       -
15      Unused  61440   65535   4096    0       4096    -       -

Das TCAM ist in 16 Blöcke unterteilt, von denen noch sechs Blöcke frei sind. Die anderen Blöcke sind entweder mit 80bit oder 160bit Schlüsselbreite konfiguriert und verschiedenen Funktionsgruppen zugeordnet. Sie liefern Ziele (vermutlich für Routingentscheidungen).

Auffällig ist, dass die 160bit Blöcke nur die Hälfte der Einträge fassen können, wie die 80bit Blöcke. Es ist jedoch nur logisch, da für die Schlüssel doppelt so viel Platz brauchen.

group#  inUse   mode    type      lookup  entries free    util%   rangeId
0       yes     80 Bit  uRPF Ipv4 Src     0       0       100     0
1       yes     160 Bit uRPF Ipv6 Src     0       0       100     1
2       yes     160 Bit SpecSrc   Src     0       0       100     255
3       yes     80 Bit  UC Ipv4   Dst     32768   645     98      0
4       yes     160 Bit MC Ipv4   Dst     2048    1609    21      1
5       yes     160 Bit UC Ipv6   Dst     2048    1944    5       2
6       yes     320 Bit MC Ipv6   Dst     0       0       100     3
7       yes     160 Bit SpecDst   Dst     0       0       100     255
8       yes     160 Bit OtherL3   Otr     0       0       100     4

        range
0       [ipv4: 0.0.0.0 - ipv4: 255.255.255.255]
1       [ipv6: :: - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF]
2       [null]
3       [ipv4: 0.0.0.0 - ipv4: 223.255.255.255]
4       [ipv4: 224.0.0.0 - ipv4: 239.255.255.255]
5       [ipv6: :: - ipv6: FEFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF]
6       [ipv6: FF00:: - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF]
7       [null]
8       [ipv4: 0.0.0.0 - ipv6: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF]

Hier haben wir die Verwendungszwecke der TCAM Blöcke. Für reverse Path Filtering (das jetzt abgeschaltet ist) wird also die Source-Adresse als Schlüssel verwendet. Für IPv4/v6 Routing wird die Zieladresse als Schlüssel benutzt. Soweit so wenig überraschend.

Eher überraschend ist, dass Multicast doppelte Breite benötigt. Multicast Routing funktioniert anhand der Zielgruppe (einer IP) und der Quell-IP (einer IP), es ist also doch keine Überraschung.

Was Spec und OtherL3 ist, weiß ich nicht. Das kommt hier schlicht nicht vor.

        blocks
0       (0)
1       (0)
2       (0)
3       (8)  0, 3, 4, 5, 6, 7, 8, 9
4       (1)  2
5       (1)  1
6       (0)
7       (0)
8       (0)

Auch die Zuordung der logischen Gruppen zu den physikalischen Blöcken ist nachvollziehbar. Es ist genau das, was bei der Auflistung der Blöcke schon stand.

entity        total     used      free      util%
Entries       61440     32639     28801     53
  uRPF Ipv4   0         0         0         0
  uRPF Ipv6   0         0         0         0
  UC Ipv4     32768     32091     677       97
  MC Ipv4     2048      438       1610      21
  UC Ipv6     2048      110       1938      5
  MC Ipv6     0         0         0         0
  SpecDst     0         0         0         0
  SpecSrc     0         0         0         0
  OtherL3     0         0         0         0
  unused      24576     24576     0         100

Diese Zusammenfassung zeigt die relevanten Kenngrößen.

  • Von den (80bit)-Einheiten des TCAM sind 53% belegt.
  • IPv4 Routing hat 32091 Einträge aktiv, damit sind von den aktuell allozierten Blöcken 97% belegt.
  • IPv4 Multicast hast 438 Einträge, was von dem einzigen allozierten Block 21% ausmacht.
  • IPv6 Routing belegt mit 110 Einträgen in dem einzigen allozierten Block 5%

Wesentlich ist hier fest zu halten, das die Aussage im Datenblatt etwas euphemistisch formuliert wurde. Das TCAM wird für alle Protokolle gemeinsam benutzt, dabei passen maximal 32k IPv6 Routen rein, wenn nichts anderes auf der Maschine läuft. 64k IPv4 Routen passen nur, wenn nichts anderes damit gemacht wird. Sobald IPv4 und IPv6 oder Multicast oder uRPF gemischt werden, sinken die entsprechenden freien Blöcke rasant.

Die relevante Kenntgröße zur Überwachung ist also die Prozentzahl rechts oben (53%) oder noch besser die Zahl der freien Blöcke (die man sich als unused/4096 berechnen muss).

Gestern sah das anders aus. Wir hatten über 20000 Einträge bei IPv6 Routing und dazu noch die uRPF Belegungen. Damit war der der TCAM erschöpft.

Weiter oben sprach ich von ca 2500 IPv4 Routen, hier stehen nun 32091. Warum? Mit IPv6 war es gestern ähnlich, warum?

#sh ip route summary
IP routing table name is default (0x0)
IP routing table maximum-paths is 8
Route Source    Networks    Subnets     Replicates  Overhead    Memory (bytes)
application     0           0           0           0           0
connected       0           50          0           3640        9200
static          2           525         0           40264       96968
ospf 1          2           2084        0           150192      392168
  Intra-area: 156 Inter-area: 68 External-1: 1565 External-2: 0
  NSSA External-1: 297 NSSA External-2: 0
internal        18                                              108332
Total           22          2659        0           194096      606668

Die 2681 passen gar nicht mit den 32091 zusammen. Was ist da los?

Der Catalyst routet nicht wie ein normaler Router, sondern ist ein Layer3-Switch. Er benutzt das TCAM, um in einem einzelnen Schritt, das Ziel eines eingehenden Paketes zu ermitteln. Das Verfahren nennt sich Cisco Express Forwarding und ist der Grund dafür, dass die Geräte ebenso schnell switchen wie routen.

#sh ip cef summary
IPv4 CEF is enabled for distributed and running
VRF Default
 32097 prefixes (32093/4 fwd/non-fwd)
 Table id 0x0
 Database epoch:        2 (32097 entries at this epoch)

Das passt sehr gut (die Werte sind dynamisch und der TCAM Wert zeigt nun 32124). Aber was enthält CEF nun genau?

# sh ip cef
Prefix               Next Hop             Interface
5.102.167.0/26       192.168.255.18       Vlan29
5.102.167.128/29     192.168.255.18       Vlan29
10.10.10.10/32       217.17.207.163       Vlan115
10.100.0.0/16        attached             Vlan142
10.100.0.0/32        receive              Vlan142
10.100.0.1/32        receive
10.100.0.3/32        receive              Vlan142
10.100.0.4/32        attached             Vlan142
10.100.0.5/32        attached             Vlan142
10.100.1.1/32        attached             Vlan142
10.100.1.2/32        attached             Vlan142
10.100.1.3/32        attached             Vlan142
10.100.1.7/32        attached             Vlan142
10.100.1.9/32        attached             Vlan142
...

Es enthält die Routing-Einträge (wie erwartet) und alle Nachbarschaftseinträge (unerwartet). Damit ist mit einem Lookup im TCAM sofort ein neuer Layer2-Header verfügbar, der an einem bestimmten Interface raus geblasen werden kann. Er verweist entweder direkt auf die MAC Adresse des Zieles oder auf die MAC Adresse des nächsten Routers.

Dazu kommt, dass diese CEF hier distriuted ist, d.h. die verschiedenen eingesteckten Line-Cards haben ihr eigenes TCAM, dass analog befüllt wurde. Im Idealfall verläßt also eine eingehendes Paket nicht mal die Linecard sondern geht direkt auf einem anderen Port der gleichen Karte wieder raus.

Da diese Einträge im CEF auch die MAC Adressen enthalten, haben sie direkt mit den ARP Tabellen zu tun.

#sh arp summary
Total number of entries in the ARP table: 29979.
Total number of Dynamic ARP entries: 29800.
Total number of Incomplete ARP entries: 143.
Total number of Interface ARP entries: 36.
Total number of Static ARP entries: 0.
Total number of Alias ARP entries: 0.
Total number of Simple Application ARP entries: 0.
Total number of Application Alias ARP entries: 0.
Total number of Application Timer ARP entries: 0.

Das passt also sehr gut zusammen.

Und wieder ist die Dokumentation zumindest ungenau. Es ist also nur dann 64k IPv4 Routen möglich, wenn die Ziele alle zu wenigen externen Geräte weiter geleitet werden müssen. Sobald es verschiedene Ziele für eine Route gibt, reicht das nicht mehr aus. Im Extremfall kann man also höchstens ein fast voll besetztes /16 lokal anbinden und schon geht gar nichts mehr.

Bei IPv6 halbieren sich die erreichbaren Zahlen. Bei Multicast noch einmal.

Ich bin solche Mogel-Aussagen von Cisco nicht gewöhnt. Ich bin ehrlichweise etwas ungehalten.

Lösung

Was nun tun?

Von den Kisten muss zuerst einmal das IPv6 runter. Große Layer2-Segmente mit SLAAC füllen das TCAM so schnell, dass es irgendwann platzt. Deswegen waren auch nur Geräte betroffen, die zwei solche Anbindungen versorgen. Mittlerweile ist die IPv6 Adoption der Endgeräte so weit angestiegen, dass es die TCAM Grenzen gerissen hat. Natürlich ist das allein kein Grund, dass alle drei Geräte gleichzeitig betroffen waren, sie waren aber alle in anderen Konstellationen kurz vor der Grenze und haben deswegen einen weiteren Anstieg anderswo im Netz nicht verkraftet.

IPv6 ist aktuell kein Vertragsbestandteil beim Kunden, deswegen muss für die IPv6-Versorgung eine andere Lösung gefunden werden, die nicht am TCAM knabbert. Wie genau die aussehen wird, ist noch nicht klar.

Nach einem beherzten "no ipv6 nd prefix ..." und einem "no ipv6 address 2a01:..../64" auf den dicken Kunden-Leitungen, ist Ruhe eingekehrt.

Und dabei bleibt es jetzt erst einmal.

Bleibt noch die Frage, ob sich das System selbst heilen kann. Was passiert also, wenn die TCAM-Blöcke nicht mehr von der zugeordneten Gruppe benötigt werden?

block#  start   end     mode    entries used    free    group   type
0       80 Bit  0       4095    4096    4096    0       3       Dst
1       160 Bit 4096    8190    2048    56      1992    5       Dst
2       160 Bit 8192    12286   2048    195     1853    4       Dst
3       80 Bit  12288   16383   4096    4094    2       3       Dst
4       80 Bit  16384   20479   4096    4096    0       3       Dst
5       80 Bit  20480   24575   4096    4092    4       3       Dst
6       80 Bit  24576   28671   4096    4019    77      3       Dst
7       160 Bit 28672   32766   2048    0       2048    5       Dst
8       80 Bit  32768   36863   4096    3383    713     3       Dst
9       160 Bit 36864   40958   2048    1       2047    5       Dst
10      160 Bit 40960   45054   2048    3       2045    5       Dst
11      160 Bit 45056   49150   2048    1       2047    5       Dst
12      160 Bit 49152   53246   2048    2       2046    5       Dst
13      Unused  53248   57343   4096    0       4096    -       -
14      Unused  57344   61439   4096    0       4096    -       -
15      Unused  61440   65535   4096    0       4096    -       -

Ganz einfach. Sie sind verloren.

Block 7 wurde für IPv6 Routing allokiert und nun nicht mehr benötigt. Er wird aber nicht als unbenutzt zurück gegeben. Er ist verloren. Ebenso wie die anderen Blöcke 9 bis 12.

Die einzige Möglichkeit TCAM wieder frei zu bekommen, ist also ein Reboot des Geräts. Das kann man aber planen.

Auch für die Kennzahlen der Überwachung ist dieser Zustand lehrreich:

entity        total     used      free      util%
Entries       51200     24004     27196     46
  uRPF Ipv4   0         0         0         0
  uRPF Ipv6   0         0         0         0
  UC Ipv4     24576     23767     809       96
  MC Ipv4     2048      174       1874      8
  UC Ipv6     12288     63        12225     0
  MC Ipv6     0         0         0         0
  SpecDst     0         0         0         0
  SpecSrc     0         0         0         0
  OtherL3     0         0         0         0
  unused      12288     12288     0         100

Mit 46% frei schaut es doch gar nicht so schlecht aus, oder? Aber es sind nur die Hälfte der Blöcke frei, wie beim anderen, weniger belasteten, Gerät.

Bandbreite im DHCP

09/10/2020 6:15 pm Lutz Donnerhacke Tags: Broadband 0

DHCP-Pakete, die über Broadband-Infrastruktur wie DSLAMs laufen, werden providerseitig mit Zusatzinformationen angereichert. Beispielsweise mit Angaben zur Leitungsqualität und Bandbreite. Diese Informationen auszulesen und ggfl. auch selbst setzen zu können ist entweder Bitpfriemelei oder eine Konfiguration des ICS DHCP-Servers.

Rohe Bits

Selbstverständlich ist es möglich, die Daten unterwegs mitzuschneiden und aus dem Binärblob zu extrahieren. RFC4243 definiert dazu die Suboption 9 in der DHCP Option (82) die für das DHCP-Relay zuständig ist. In dieser Option sind herstellerspezifische Dinge abgelegt.

Das Extrahieren per Perl ist einfach:

my $d = Net::DHCP::Packet->new($data);
die "Not a DHCP packet.\n" unless $d->isDhcp;

my $bbf;
my $o82 = $d->getOptionRaw(82);
if(defined $o82) {
    my %o = unpack('(CC/a)*', $o82);
    if(%o) {
        my $o9 = rfc4243($o{9});
        if(exists $o9->{3561}) {
            $bbf = BBF($o9->{3561});
        }
    }
}

sub rfc4243($) {
    local $_ = shift;
    my %r = unpack('(NC/a)*',$_);
    return \%r;
}

sub BBF($) {
    local $_ = shift;
    my %c = unpack('(CC/a)*',$_);

    foreach(keys %c) {
        if($_ >= 129 && $_ <= 142) {
            ($c{$_}) = unpack('N', $c{$_});
        } elsif($_ >= 155 && $_ <= 162) {
            ($c{$_}) = unpack('N', $c{$_});
        }
    }
    return \%c;
}

Im Ergebnis bekommt man einen Hash-Referenz in $bbf in die Hand, die die Angaben der eingefügten Optionen nach Broadbandforum (Vendor-ID 3561) enthält.

Im Einzelnen sind das:

my %bbfnames = (
    129 => 'Actual data rate Upstream in kbps',    # from client
    130 => 'Actual data rate Downstream in kbps',  # from client
    131 => 'Minimum Data Rate Upstream in kbps',
    132 => 'Minimum Data Rate Downstream in kbps',
    133 => 'Attainable Data Rate Upstream in kbps',
    134 => 'Attainable Data Rate Downstream in kbps',
    135 => 'Maximum Data Rate Upstream in kbps',   # from server
    136 => 'Maximum Data Rate Downstream in kbps', # from server
    137 => 'Minimum Data Rate Upstream in low power state in kbps',
    138 => 'Minimum Data Rate Downstream in low power state in kbps',
    139 => 'Maximum Interleaving Delay Upstream in milliseconds',
    140 => 'Actual interleaving Delay Upstream in milliseconds',
    141 => 'Maximum Interleaving Delay Downstream in milliseconds',
    142 => 'Actual interleaving Delay Downstream in milliseconds',

    155 => 'Expected throughput (ETR) upstream in kbps',
    156 => 'Expected throughput (ETR) downstream in kbps',
    157 => 'Attainable expected throughput (ATTETR) upstream in kbps',
    158 => 'Attainable expected throughput (ATTETR) downstream in kbps',
    159 => 'Gamma data rate (GDR) upstream in kbps',
    160 => 'Gamma data rate (GDR) downstream in kbps',
    161 => 'Attainable gamma data rate (ATTGDR) upstream in kbps',
    162 => 'Attainable gamma data rate (ATTGDR) downstream in kbps',
);

Man kann dann also über das Feld {130} der Variable $bbf auf die aktuelle Downloadgeschwindigkeit in kbps zugreifen.

ISC DHCP

Natürlich sind solche Programmierungen bei der Benutzung fertiger Software, wie dem DHCPD von ISC, nicht möglich. Hier muss mit Bordmitteln die Option auseinander genommen werden. Es ist nahezu unmöglich, die Substrukturen auf Bitebene selbst zu parsen, dass muss der Daemon schon allein hin bekommen. Aber dafür braucht er Hilfe.

Man muss der Software erklären, wie die Option strukturiert sind, damit sie die parsen kann. Zunächst einmal erkläre ich den RFC4243.

option space rfc4243 code width 4 length width 1 hash size 7;
option agent.vendor code 9 = encapsulate rfc4243;

Es wird eine neuer Optionsbereich definiert, der intern mit 32bit Codenummern arbeitet. Da ich nur eine Handvoll Codes auch real definieren will, lass ich die Hashtable auf einer kleinen Primzahl (hier 7) stehen, um RAM zu sparen.

Dieser Optionsbereich wird dann als Suboption 9 an die vordefinierte "agent" Option 82 eingehängt. Der Server weiß also bereits, wie Option 82 zu parsen ist, kennt nun auch die innere Struktur der Unteroption 9: Eine komplette eigene DHCP-Optionsstruktur mit eigenen Code- und Längenangaben.

Man sieht auch gleich, dass die Struktur (rfc4243) nicht den gleichen Namen haben muss wie die Option (vendor).

option space bbf code width 1 length width 1 hash size 257;
option rfc4243.bbf code 3561 = encapsulate bbf;

In analoger Weise wird die Substruktur des Vendors Broadbandforum definiert. Wenn in der Suboption 9 der (32bit) Code 3561 auftaucht, so ist der gesamte Datenbereich dieses Feldes wieder eine DHCP-Optionsstruktur mit 8bit-Code und 8bit-Länge. Diesmal will ich aber mehr Codes definieren, mache also die Hashtable größer.

option bbf.actual-up-rate code 129 = unsigned integer 32;
option bbf.actual-down-rate code 130 = unsigned integer 32;
option bbf.minimum-up-rate code 131 = unsigned integer 32;
option bbf.minimum-down-rate code 132 = unsigned integer 32;
option bbf.attainable-up-rate code 133 = unsigned integer 32;
option bbf.attainable-down-rate code 134 = unsigned integer 32;
option bbf.maximum-up-rate code 135 = unsigned integer 32;
option bbf.maximum-down-rate code 136 = unsigned integer 32;
option bbf.maximum-up-lowpower-rate code 137 = unsigned integer 32;
option bbf.maximum-down-lowpower-rate code 138 = unsigned integer 32;
option bbf.maximum-delay-up code 139 = unsigned integer 32;
option bbf.actual-delay-up code 140 = unsigned integer 32;
option bbf.maximum-delay-down code 141 = unsigned integer 32;
option bbf.actual-delay-down code 142 = unsigned integer 32;

option bbf.expected-throughput-up code 155 = unsigned integer 32;
option bbf.expected-throughput-down code 156 = unsigned integer 32;
option bbf.attainable-throughput-up code 157 = unsigned integer 32;
option bbf.attainable-throughput-down code 158 = unsigned integer 32;
option bbf.gamma-data-rate-up code 159 = unsigned integer 32;
option bbf.gamma-data-rate-down code 160 = unsigned integer 32;
option bbf.attainable-gamma-data-rate-up code 161 = unsigned integer 32;
option bbf.attainable-gamma-data-rate-down code 162 = unsigned integer 32;

Hier wurden die für mich interessanten Werte definiert. Der Server kann also beim Parsen der Unterstruktur anhand des (8bit) Codes erkennen, um welchen Wert es geht und wie dieser in interpretieren ist (als uint32 in Netzwerkbyteorder).

Und wie greift man auf die Werte zu?

log (info, concat("BBF: ",
            binary-to-ascii(16, 8, ":", hardware),
            " current speed ",
            binary-to-ascii(10, 32, ".", option bbf.actual-down-rate),
            "/",
            binary-to-ascii(10, 32, ".", option bbf.actual-up-rate)
          ));

Die Loganweisung an passender Stelle in der Konfig erzeugt dann eine Menge Einträge.

Oct  9 18:55:26 dhcpd: BBF: 1:e0:28:6d:aa:bb:cc current speed 5999/639
Oct  9 18:55:27 dhcpd: BBF: 1:34:31:c4:dd:ee:ff current speed 50000/9999
Oct  9 18:55:29 dhcpd: BBF: 1:38:10:d5:gg:hh:ii current speed 54999/11000 

Tut.

Coronavirus: Warum wir jetzt handeln müssen

12/03/2020 1:55 pm Lutz Donnerhacke Tags: Politik , Mathe , Corona 6

Dieser Artikel ist eine Übersetzung eines sehr guten Artikels von Tomas Pueyo. Ich halte ihn für so wichtig, dass Sprachbarrieren nicht zum Hindernis werden sollten. Los gehts:

Bei all dem, was über das Coronavirus geschieht, könnte es sehr schwer sein, eine Entscheidung darüber zu treffen, was heute zu tun ist. Sollten Sie auf weitere Informationen warten? Heute etwas tun? Was denn?

In diesem Artikel werde ich mit vielen Diagrammen, Daten und Modelle aus vielen Quellen arbeiten:

  • Wie viele Fälle von Coronaviren wird es in Ihrer Region geben?
  • Was wird passieren, wenn diese Fälle auftreten?
  • Was sollten Sie tun?
  • Wann wird es passieren?

Wenn Sie den Artikel fertig gelesen haben, werden Sie das hier mitnehmen:

  • Das Coronavirus kommt zu Ihnen.
  • Es kommt mit exponentieller Schnelligkeit: langsam und dann ganz plötzlich.
  • Es ist eine Frage von Tagen. Ein oder zwei Wochen vielleicht.
  • Wenn das geschieht, wird das Gesundheitssystem überfordert sein.
  • Ihre Mitbürger werden in den Fluren versorgt werden.
  • Erschöpftes Pflegepersonal wird zusammenbrechen. Einige werden sterben.
  • Diese müssen entscheiden, welcher Patient mit Sauerstoff versorgt wird und welcher stirbt.
  • Die einzige Möglichkeit, dies zu verhindern, ist sofortige soziale Abgrenzung. Nicht morgen. Sondern heute.
  • Das bedeutet, so viele Menschen wie möglich zu Hause zu halten, und zwar ab sofort.

Als Politiker, Gemeindevertreter oder Unternehmer haben Sie die Macht und die Verantwortung, dies zu verhindern.

Vielleicht haben Sie jetzt Angst: Was ist, wenn ich überreagiere? Werden die Leute mich belächeln? Werden sie wütend auf mich sein? Werde ich dumm dastehen? Wird es nicht besser sein, darauf zu warten, dass andere zuerst handeln? Werde ich der Wirtschaft zu sehr schaden?

Aber in 2-4 Wochen, wenn die ganze Welt in der Quarantäne ist, wenn die wenigen kostbaren Tage der sozialen Abgrenzung, die Sie ermöglicht haben, Leben gerettet haben, wird man Sie nicht mehr kritisieren: Sie werden Ihnen dafür danken, dass Sie die richtige Entscheidung getroffen haben.

Ok, los geht's.

Wie viele Fälle von Coronavirus wird es in Ihrem Gebiet geben?

Länderüberblick

corona1

Die Gesamtzahl der Fälle stieg exponentiell an, bis China sie eindämmte. Aber dann ist sie nach außen gedrungen, und jetzt ist es eine Pandemie, die niemand mehr aufhalten kann.

corona2

Bis jetzt ist dies hauptsächlich Italien, Iran und Südkorea zuzuschreiben:

corona3

In Südkorea, Italien und China gibt es so viele Fälle, dass es kaum möglich ist, die anderen Länder zu sehen, aber lassen Sie uns die rechte untere Ecke näher betrachten.

corona4

Es gibt zahlreiche Länder mit exponentiellen Zuwächsen. Heute sind die meisten von ihnen westliche Länder.

corona5

Hält diese Art von Wachstum nur eine Woche an, dann bekommen Sie das hier:

corona6

Wenn man verstehen will, was passieren wird oder wie man es verhindern kann, muss man sich die bereits bekannten Beispiele anschauen: China, asiatische Länder mit SARS-Erfahrung und Italien.

China

corona7

Dies ist eines der wichtigsten Diagramme. Klicken Sie drauf, um die Details besser erkennen zu können.

In orangefarbenen Balken zeigt es die tägliche offizielle Zahl der Fälle in der Provinz Hubei: Wie viele Menschen an diesem Tag diagnostiziert wurden.

Die grauen Balken zeigen die tatsächlichen täglichen Coronavirus-Fälle. Die chinesische Gesundheitsbehörde CDC ermittelte diese, indem sie die Patienten während der Diagnose fragte, wann ihre Symptome begannen.

Entscheidend ist, dass diese tatsächlichen Fälle zu diesem Zeitpunkt noch nicht bekannt waren. Wir können sie nur rückblickend herausfinden: Die Behörden wissen nicht, wann jemand erste Symptome hatte. Sie wissen, wann jemand zum Arzt geht und die Diagnose gestellt wird.

Das heißt, die orangefarbenen Balken zeigen Ihnen, was die Behörden wussten, und die grauen, was in Wirklichkeit geschah.

Am 21. Januar explodierte die Zahl der neu diagnostizierten Fälle (orange): Es gibt etwa 100 neue Fälle. Tatsächlich gab es an diesem Tag 1.500 neue Fälle, die exponentiell anwachsen. Aber die Behörden wussten das nicht. Was sie wussten, war, dass es plötzlich 100 neue Fälle dieser neuen Krankheit gab.

Zwei Tage später sperrten die Behörden Wuhan. Zu diesem Zeitpunkt betrug die Zahl der täglich diagnostizierten neuen Fälle ~400. Beachten Sie diese Zahl: Sie beschlossen, die Stadt mit nur 400 neuen Fällen an einem Tag zu schließen. In Wirklichkeit gab es an diesem Tag 2.500 neue Fälle, aber das wussten sie nicht.

Einen Tag später wurden 15 weitere Städte in Hubei dicht gemacht.

Bis zur Schließung von Wuhan am 23. Januar zeigt das graue Diagramm, dass die Zahl der Fälle exponentiell zunimmt. Die tatsächlichen Fälle sind geradezu explodiert. Sobald Wuhan geschlossen wurde, wurden die Zahlen immer weniger. Als am 24. Januar weitere 15 Städte schließen, kommt die Zahl der tatsächlichen Fälle (wieder grau) zum Stillstand. Das Maximum an tatsächlichen Fällen wurde zwei Tage später erreicht, und seither ist die Zahl der tatsächlichen Fälle zurückgegangen.

Man beachte, dass die orangefarbenen (offiziellen) Fälle immer noch exponentiell anwachsen: Noch 12 Tage lang sah es so aus, als würde das ganze Ding immer noch explosionsartig anwachsen. Aber das war nicht der Fall. Es ist nur so, dass die Patienten immer stärkere Symptome bekamen und häufiger zum Arzt gingen, während gleichzeitig das systematische Erfassen der Patienten besser funktionierte.

Dieses Konzept der offiziellen und tatsächlichen Fälle ist wichtig. Behalten wir es für später im Gedächtnis.

In den übrigen Regionen Chinas koordinierte die Zentralregierung ihre Aktivitäten gut, sie ergriff sofortige und drastische Maßnahmen. Dies ist das Ergebnis:

corona8

Jede gerade Linie ist eine chinesische Region mit Coronavirus-Fällen. Jede einzelne hatte das Potential, sich exponentiell zu entwickeln, aber dank der Maßnahmen, die gerade Ende Januar durchgeführt wurden, konnte das Virus gestoppt werden, bevor es sich ausbreiten konnte.

In der Zwischenzeit hatten Südkorea, Italien und der Iran einen ganzen Monat Zeit, um sich zu informieren, taten es aber nicht. Es begann das gleiche exponentielle Wachstum wie in Hubei und überholte bis Ende Februar alle chinesischen Regionen.

Asiatische Länder

In Südkorea ist die Zahl der Fälle explodiert, doch haben Sie sich schon gefragt, was in Japan, Taiwan, Singapur, Thailand oder Hongkong anders ist?

corona9

Taiwan schaffte es nicht einmal in dieses Diagramm, weil es nicht die von mir gewählte Schwelle von 50 Fällen hatte.

Alle wurden 2003 von SARS heimgesucht, und alle haben daraus gelernt. Sie lernten, wie viral und tödlich die Krankheit sein kann, und wussten daher, dass sie das Problem ernst nehmen mussten. Daher sehen alle ihre Werte, obwohl sie schon viel früher begannen, immer noch nicht wie Exponentialkurven aus.

Bislang haben wir Berichte von Regierungen, die die Bedrohung der sich verbreitenden Coronaviren erkannten und sie eindämmten. In den übrigen Ländern gibt das allerdings eine komplett anders verlaufende Entwicklung.

Doch bevor wir dazu kommen, eine Anmerkung zu Südkorea: Das Land ist wahrscheinlich ein Ausreißer. Das Coronavirus war nach den ersten 30 Fällen eingedämmt. Patient 31 war ein Superüberträger, der es an Tausende andere Menschen weitergegeben hat. Da sich das Virus ausbreitet, bevor die Menschen Symptome zeigen, war das Virus zu dem Zeitpunkt, als die Behörden das Problem erkannten, längst da draußen. Nun tragen sie die Folgen dieses einen Falls. Ihre Eindämmungsbemühungen zeigen jedoch: Italien hat es in einer Reihe von Fällen bereits überschritten, und der Iran wird es schon morgen überschreiten (3/10/2020).

Washington State

Sie kennen bereits das Anwachsen in den westlichen Ländern und haben gesehen, wie schlecht die Prognosen von nur einer Woche aussehen. Nun stellen Sie sich vor, dass die Eindämmung nicht wie in Wuhan oder in anderen asiatischen Ländern geschieht, und Sie bekommen eine kolossale Epidemie.

Schauen wir uns einige Fälle an, wie z.B. den Bundesstaat Washington, die San Francisco Bay Area, Paris und Madrid.

corona10

Der Bundesstaat Washington ist das Wuhan der USA. Die Zahl der Fälle dort wächst exponentiell. Sie liegt derzeit bei 140.

Doch schon früh geschah etwas Interessantes. Die Todesrate ging durch die Decke. Es gab 3 Fälle und einen Todesfall.

Von anderen Orten wissen wir, dass die Sterblichkeitsrate des Coronavirus zwischen 0,5 und 5 % liegt (dazu später mehr). Wie konnte die Sterblichkeitsrate 33% erreichen?

Es stellte sich heraus, dass sich das Virus seit Wochen unbemerkt ausgebreitet hatte. Es ist nicht so, dass es nur 3 Fälle gab. Die Behörden wussten nur von 3, und einer von ihnen war tot, denn je ernster der Zustand, desto wahrscheinlicher ist es, dass jemand getestet wird.

Das ist ein bisschen wie bei den orangefarbenen und grauen Balken in China: Hier wussten sie nur von den orangefarbenen Balken (offizielle Fälle) und sie sahen gut aus: nur 3. Aber in Wirklichkeit gab es Hunderte, vielleicht Tausende von tatsächlichen Krankheitsfällen.

Das ist ein Problem: Sie kennen nur die offiziellen Fälle, nicht die tatsächlichen. Aber Sie müssen die tatsächlichen Fälle kennen. Wie können Sie die tatsächlichen Fälle abschätzen? Es gibt verschiedene Möglichkeiten. Ich hab für beide ein Modell, so dass Sie auch mit den Zahlen spielen können (direkter Link zum Kopieren des Modells).

Einmal durch Todesfälle. Wenn Sie Todesfälle in Ihrer Region haben, können Sie damit die Anzahl der tatsächlichen aktuellen Fälle schätzen. Wir wissen ungefähr, wie lange es im Durchschnitt (17,3 Tage) dauert, bis ein Mensch stirbt, der sich das Virus eingefangen hat. Die Person, die am 29.2. im Bundesstaat Washington starb, hat sich also wahrscheinlich am 12.2. infiziert.

Dann weiß man die Sterblichkeitsrate. Für dieses Szenario verwende ich 1% (die Einzelheiten besprechen wir später). Demzufolge gab es um den 12.2. herum bereits etwa 100 Fälle in der Gegend (von denen nur einer 17,3 Tage später zum Tode kam).

Nehmen wir nun die durchschnittliche Verdoppelungszeit für das Coronavirus (Zeit, die durchschnittlich für die Verdoppelung der Fälle benötigt wird). Sie liegt bei 6,2. In den 17 Tagen, die diese Person zum Sterben brauchte, haben sich die Erkrankungen also mit ~8 (=2^(17/6)) multipliziert. Anders ausgedrückt: Wenn man nicht alle Fälle diagnostizieren kann, bedeutet ein Todesfall heute 800 tatsächliche Fälle.

Im Bundesstaat Washington gibt es derzeit 22 Todesfälle. Mit dieser kurzen Hochrechnung erhält man heute ungefähr 16.000 tatsächliche Coronavirus-Fälle. So viele wie die offiziellen Fälle in Italien und im Iran zusammen.

Wenn wir ins Detail gehen, erkennen wir, dass 19 dieser Todesfälle auf eine Gruppe zurückzuführen sind, die das Virus möglicherweise nicht weit verbreitet hat. Betrachten wir also diese 19 Todesfälle als einen einzigen, ergibt sich eine Gesamtzahl von vier Todesfällen in diesem Bundesstaat. Wenn wir das Modell mit dieser Zahl aktualisieren, erhalten wir heute immer noch ~3.000 Fälle.

Trevor Bedford betrachtet in seinem Ansatz die Viren selbst und ihre Mutationen, um die aktuelle Fallzahl zu ermitteln. Er kommt zu dem Schluss, dass es derzeit wahrscheinlich ~1.100 Fälle im Bundesstaat Washington gibt.

Keiner dieser Ansätze ist perfekt, aber sie alle zielen auf die gleiche Kernaussage ab: Wir kennen die Zahl der tatsächlichen Fälle nicht, aber sie ist viel höher als die offizielle. Es sind nicht Hunderte. Es sind Tausende, vielleicht sogar mehr.

San Francisco Bay Area

Bis zum 8.3. gab es in der Bay Area keine Todesfälle. Daher ist es schwer zu sagen, wie viele tatsächliche Fälle es gab. Offiziell gab es 86 Fälle. In den USA ist die Zahl der Fälle jedoch sehr gering, weil es nicht genügend Testkits gibt. Das Land beschloss, ein eigenes Testkit zu erstellen, was sich allerdings als wirkungslos erwies.

Dies war die Anzahl der bis zum 3. März in verschiedenen Ländern durchgeführten Tests:

corona11

In der Türkei, wo es keine Fälle von Coronaviren gab, wurden pro Einwohner 10-mal mehr Tests durchgeführt als in den USA. Heute ist die Situation mit ~8.000 in den USA durchgeführten Tests nicht viel besser, wodurch ~4.000 Menschen getestet wurden.

corona12

An dieser Stelle kann man nur einen Teil der offiziellen Fälle zu tatsächlichen Fällen machen. Wie soll man sich entscheiden? Für die Bay Area testeten sie jeden, der eine Reise unternommen hatte oder mit einem Reisenden in Kontakt stand, d.h. sie kannten die meisten reisebezogenen Fälle, jedoch keinen der Fälle, die sich in der Bevölkerung ausbreiteten. Indem man ein Gefühl für die Ausbreitung in der Bevölkerung im Vergleich zur Ausbreitung auf Reisen hat, kann man wissen, wie viele echte Fälle es gibt.

Ich habe mir dieses Verhältnis für Südkorea angesehen, das über großartige Daten verfügt. Als sie 86 Fälle hatten, betrug der Prozentsatz der Fälle, die auf die Ausbreitung in der Bevölkerung zurückzuführen sind, 86% (86 und 86% sind ein Zufall).

Anhand dieser Angabe kann man die Anzahl der tatsächlichen Fälle berechnen. Wenn es heute in der Bay Area 86 Fälle gibt, ist es wahrscheinlich, dass die tatsächliche Zahl bei ~600 liegt.

Frankreich und Paris

Frankreich verzeichnet heute 1.400 Fälle und 30 Todesfälle. Mit den beiden oben genannten Methoden können Sie eine Spanne von Fallzahlen haben: zwischen 24.000 und 140.000.

Die tatsächliche Zahl der Coronavirus-Fälle in Frankreich dürfte heute zwischen 24.000 und 140.000 liegen.

Lassen Sie mich das wiederholen: Die Zahl der tatsächlichen Fälle in Frankreich wird wahrscheinlich um ein bis zwei Größenordnungen höher sein, als sie offiziell gemeldet wird.

Sie glauben mir nicht? Schauen wir uns noch einmal das Wuhan-Diagramm an. Wenn Sie die orangefarbenen Balken bis zum 22. Januar aufsammeln, erhalten Sie 444 Fälle. Addieren Sie nun alle grauen Balken. Das ergibt ~12.000 Fälle. Als Wuhan also dachte, er hätte 444 Fälle, waren es 27 Mal mehr. Wenn Frankreich glaubt, es habe 1.400 Fälle, dürften es durchaus Zehntausende sein.

Für Paris gilt die gleiche Rechnung. Mit ~30 Fällen innerhalb der Stadt liegt die tatsächliche Zahl der Erkrankungen wahrscheinlich bei Hunderten, vielleicht sogar Tausenden. Bei 300 Fällen in der Region Ile-de-France könnte die Gesamtanzahl der Fälle in der Region bereits Zehntausende übersteigen.

Madrid und Spanien

Spanien hat sehr ähnliche Zahlen wie Frankreich (1.200 Fälle gegenüber 1.400, und beide haben 30 Todesfälle). Das heißt, es gelten die gleichen Regeln: Spanien hat wahrscheinlich schon über 20.000 echte Fälle.

In der Region Madrid (Comunidad de Madrid) mit 600 offiziellen Fällen und 17 Todesfällen liegt die wahre Zahl der Fälle wahrscheinlich zwischen 10.000 und 60.000.

Wenn Sie diese Daten sehen und sich selbst sagen: "Unmöglich, das kann nicht wahr sein", dann bedenken Sie Folgendes: Bei dieser Zahl von Fällen war Wuhan bereits unter Quarantäne.

Bei der Zahl der Fälle, die wir heute in Ländern wie den USA, Spanien, Frankreich, Iran, Deutschland, Japan, den Niederlanden, Dänemark, Schweden oder der Schweiz sehen, befand sich Wuhan bereits in Quarantäne.

Und wenn Sie sich sagen: "Nun, Hubei ist nur eine Region", dann möchte ich Sie daran erinnern, dass dort fast 60 Millionen Menschen leben, mehr als in Spanien und etwa so viele wie in Frankreich.

Was passiert, wenn Coronavirus-Fälle auftreten?

Das Coronavirus ist schon hier. Es ist versteckt und wächst exponentiell.

Was wird in unseren Ländern passieren, wenn es zuschlägt? Das lässt sich leicht feststellen, denn wir haben bereits mehrere Orte, an denen es sich ausbreitet. Die besten Beispiele sind Hubei und Italien.

Die Sterblichkeitsraten

Die Weltgesundheitsorganisation (WHO) gibt 3,4 % als Sterblichkeitsrate an (% Menschen, die sich mit dem Coronavirus infizieren und dann sterben). Diese Zahl ist aus dem Kontext gerissen, lassen Sie mich das erklären.

corona13

Es hängt stark vom Land und vom Zeitpunkt ab: zwischen 0,6% in Südkorea und 4,4% im Iran. Und was heißt das? Mit einem Trick können wir es herausfinden.

Die beiden Möglichkeiten, wie man die Sterblichkeitsrate berechnen kann, sind Todesfälle/Gesamtfälle und Todesfälle/abgeschlossene Fälle. Die erste ist wohl eine zu niedrige Schätzung, denn viele offene Fälle können immer noch mit dem Tod enden. Die Zweite stellt eine Überschätzung dar, da Todesfälle wahrscheinlich schneller abgeschlossen werden als Heilungen.

Ich habe mir angesehen, wie sich beide im Laufe der Zeit entwickeln. Beide Zahlen werden zum gleichen Ergebnis führen, wenn alle Fälle erst einmal abgeschlossen sind. Projiziert man also die Entwicklung der Vergangenheit in die Zukunft, kann man eine Schätzung der endgültigen Sterblichkeitsrate vornehmen.

Dies ergibt sich aus den Daten. Chinas Sterblichkeitsrate liegt jetzt zwischen 3,6 % und 6,1 %. Wenn Sie das in die Zukunft projizieren, sieht es so aus, als würde sie sich in Richtung 3,8%-4% annähern. Das ist doppelt so hoch wie die aktuelle Schätzung und 30 x schlimmer als die Grippe.

Sie setzt sich jedoch aus zwei völlig unterschiedlichen Situationen zusammen: Hubei und das übrige China.

corona14

Die Sterblichkeitsrate von Hubei wird sich wahrscheinlich auf 4,8% zubewegen. Im übrigen China wird sie sich dagegen voraussichtlich auf ~0,9% einpendeln:

corona15

Für den Iran, Italien und Südkorea, die einzigen Länder mit genügend Todesfällen, habe ich ebenfalls die Zahlen aufgeführt, um dies einigermaßen verwertbar zu machen.

corona16
corona17
corona18

Die iranische und die italienische Sterblichkeitsrate nähern sich beide der 3- bis 4-Prozent-Marke an. Meine Vermutung ist, dass sich auch ihre entgültigen Raten um diese Zahl herum bewegen werden.

Am interessantesten ist Südkorea, denn diese beiden Zahlen stehen in keinem Zusammenhang: Die Zahl der Todesfälle/Gesamtzahl der Fälle beträgt nur 0,6%, aber die Zahl der Todesfälle/abgeschlossenen Fälle liegt bei satten 48%. Meiner Meinung nach ist das Land einfach extrem vorsichtig: Sie testen jeden (bei so vielen offenen Fällen scheint die Todesrate niedrig zu sein) und lassen die Fälle länger offen (so dass sie die Fälle schnell schließen, wenn der Patient tot ist). Relevant ist, dass sich die Sterblichkeitsrate von Anfang an um 0,5% bewegt hat, was darauf hindeutet, dass sie auch weiterhin bestehen bleiben wird.

Das letzte relevante Beispiel ist die Kreuzfahrt der Diamond Princess: bei 706 Fällen, 6 Todesfällen und 100 Genesungen dürfte die Sterblichkeitsrate bei 1 bis 6,5% liegen.

Die Altersverteilung in den einzelnen Ländern wird ebenfalls Auswirkungen haben: Da die Sterblichkeit bei älteren Menschen viel höher ist, werden Länder mit einer alternden Bevölkerung wie Japan im Durchschnitt stärker betroffen sein als jüngere Länder wie Nigeria. Es gibt auch Wetterfaktoren, insbesondere Feuchtigkeit und Temperatur, aber es ist noch unklar, wie sich dies auf die Übertragungs- und Sterblichkeitsraten auswirken wird.

Daraus kann man schließen:

  • Es gibt noch einige andere externe Faktoren, die die Sterblichkeitsrate beeinflussen werden.
  • Abgesehen davon werden die Länder, die darauf vorbereitet sind, eine Sterblichkeitsrate von ~0,5% (Südkorea) bis 0,9% (übriges China) aufweisen.
  • Überforderte Länder werden eine Sterblichkeitsrate zwischen ~3%-5% haben.

Anders ausgedrückt: Länder, die schnell handeln, können die Zahl der Todesfälle um den Faktor zehn reduzieren. Und das ist nur die Zahl der Todesfälle! Schnelles Handeln reduziert auch die Zahl der Krankheitsfälle drastisch, womit dies noch mehr zu einem Selbstläufer wird.

Was braucht ein Land also, um vorbereitet zu sein?

Wie groß ist die Belastung für das Gesundheitssytem?

corona19
corona20

Das Problem ist, dass Artikel wie Beatmungsgeräte und Herz-Lungen-Maschinen nicht einfach hergestellt oder gekauft werden können. Vor einigen Jahren gab es beispielsweise in den USA insgesamt 250 Herz-Lungen-Maschinen.

Wenn sich also plötzlich 100.000 Menschen infiziert haben, werden sich viele von ihnen testen lassen wollen. Etwa 20.000 müssen ins Krankenhaus eingeliefert werden, 5.000 auf die Intensivstation und 1.000 brauchen Geräte, von denen wir heute nicht genug haben. Und das bei nur 100.000 Fällen.

Dabei bleiben Fragen wie Masken unberücksichtigt. Ein Land wie die USA verfügt nur über 1% der Masken, die es benötigt, um den Bedarf seiner Mitarbeiter im Gesundheitswesen zu decken (12M N95, 30M chirurgischer Bedarf vs. 3,5B benötigt). Treten viele Fälle auf einmal auf, gibt es Masken nur für 2 Wochen.

Länder wie Japan, Südkorea, Hongkong oder Singapur sowie chinesische Regionen außerhalb von Hubei sind vorbereitet und bieten den Patienten die erforderliche Versorgung.

Die übrigen westlichen Länder bewegen sich jedoch eher in Richtung Hubei und Italien. Was geschieht dort also?

Wie ein überfordertes Gesundheitssystem aussieht

Die Geschichten, die in Hubei und die in Italien geschehen sind, beginnen sich auf unheimliche Weise zu ähneln. Hubei baute zwei Krankenhäuser in zehn Tagen, aber selbst dann war es völlig überfordert.

Beide klagten darüber, dass die Patienten ihre Krankenhäuser überfluteten. Sie mussten überall versorgt werden: in den Fluren, in den Wartezimmern …

Mitarbeiter des Gesundheitswesens verbringen Stunden mit einem einzigen Stück Schutzkleidung, weil es nicht genug davon gibt. Daher können sie die Infektionsgebiete stundenlang nicht verlassen. Danach bleiben sie liegen, sind dehydriert und erschöpft. Es gibt keine Schichten mehr. Die Menschen werden aus dem Ruhestand zurückgeholt, um den Bedarf zu decken. Menschen, die keine Ahnung von der Krankenpflege haben, werden über Nacht geschult, um kritische Aufgaben zu erfüllen. Jeder ist immer auf Abruf, immer.

Das heißt, bis sie krank werden. Das passiert oft, weil sie ohne ausreichende Schutzausrüstung ständig dem Virus ausgesetzt sind. Dann müssen sie 14 Tage lang in Quarantäne bleiben, in denen sie nicht helfen können. Im besten Fall gehen 2 Wochen verloren. Im schlimmsten Fall sind sie tot.

Am schlimmsten ist es auf den Intensivstationen, wenn die Patienten sich Beatmungsgeräte oder Herz-Lungen-Maschinen teilen müssen. Es ist eigentlich unmöglich, diese gemeinsam zu nutzen, also müssen die medizinischen Fachkräfte bestimmen, welcher Patient sie benutzen wird. Das heißt konkret, welcher Patient lebt und welcher stirbt.

"Nach einigen Tagen müssen wir uns entscheiden. [...] Nicht jeder kann intubiert werden. Wir entscheiden aufgrund von Alter und Gesundheitszustand." -Christian Salaroli, italienischer Arzt.

Dies alles führt dazu, dass ein solches System eine Sterblichkeitsrate von ~4% anstatt von ~0,5% aufweist. Wenn Sie wollen, dass Ihre Stadt oder Ihr Land Teil der 4% ist, tun Sie heute nichts.

Was sollten Sie tun?

Die Kurve flacher machen

Dies ist jetzt eine Pandemie. Sie kann nicht beseitigt werden. Was wir aber tun können, ist ihre Auswirkungen zu verringern.

Einige Länder waren in dieser Hinsicht vorbildlich. Am besten ist Taiwan, das extrem mit China verbunden ist und dennoch bis heute weniger als 50 Fälle hat. In diesem jüngsten Artikel werden alle Maßnahmen erläutert, die sie schon früh ergriffen haben und die auf Eindämmung ausgerichtet waren.

Taiwan konnte es unter Kontrolle bringen, aber die meisten Länder hatten diese Expertise nicht und haben sie nicht. Nun betreiben sie ein anderes Spiel: Eindämmung. Sie müssen dieses Virus so harmlos wie möglich machen.

Wenn wir die Infektionen so weit wie möglich eindämmen, wird unser Gesundheitssystem in der Lage sein, die Fälle viel besser zu bewältigen und die Zahl der Todesfälle zu senken. Und wenn wir es über einen längeren Zeitraum hinweg verzögern, werden wir einen Punkt erreichen, den Rest der Gesellschaft zu impfen, so dass das Risiko ganz eliminiert wird. Unser Ziel ist also nicht die Eliminierung von Coronavirus-Infektionen. Es ist, sie zu verschieben.

Je mehr wir Krankheitsfälle hinausschieben, desto besser kann das Gesundheitssystem funktionieren, desto niedriger ist die Sterblichkeitsrate und desto höher ist der Anteil der Bevölkerung, der geimpft wird, bevor er sich ansteckt.

Wie können wir die Kurve abflachen?

Soziale Isolierung

Es gibt eine ganz einfache Sache, die wir tun können und die funktioniert: soziale Isolierung.

Wenn Sie zum Wuhan-Diagramm zurückkehren, werden Sie sich daran erinnern, dass sobald es eine Quarantäne gab, die Fälle abgenommen haben. Das liegt daran, dass die Menschen nicht miteinander interagierten und der Virus sich nicht verbreitete.

Der derzeitige wissenschaftliche Konsens ist, dass dieses Virus im Umkreis von 2 Metern verbreitet werden kann, wenn jemand hustet. Andernfalls fallen die Tröpfchen zu Boden und infizieren Sie nicht.

Die größte Ansteckung erfolgt dann durch Oberflächen: Das Virus überlebt stunden- oder tagelang auf verschiedenen Oberflächen. Wenn es sich wie eine Grippe verhält, kann es wochenlang auf Metall, Keramik und Kunststoffen überleben. Das bedeutet, dass Dinge wie Türgriffe, Tische oder Fahrstuhlknöpfe schreckliche Infektionsherde sein können.

Nur mit sozialer Isolation lässt sich das wirklich reduzieren: Die Menschen so viel wie möglich zu Hause zu halten, so lange wie möglich, bis sich das Problem gelegt hat.

Dies wurde bereits in der Vergangenheit bewiesen. Nämlich bei der Grippepandemie von 1918.

Lehren aus der Grippeepidemie von 1918

corona21

Man sieht, dass Philadelphia nicht schnell genug handelte und einen massiven Höhepunkt bei den Todesraten hatte. Vergleichen Sie das mit St. Louis, das es tat.

Dann schauen Sie sich Denver an, das erst Maßnahmen erließ und sie dann lockerte. Sie hatten einen doppelten Höhepunkt, wobei die zweite Spitze höher war als die erste.

corona22

Verallgemeinert man, so findet man das hier:

corona23

Dieses Diagramm zeigt für die Grippe von 1918 in den USA, wie viele weitere Todesfälle es pro Stadt gab, je nachdem, wie schnell Maßnahmen ergriffen wurden. Eine Stadt wie St. Louis hat beispielsweise 6 Tage vor Pittsburg Maßnahmen ergriffen und hatte weniger als die Hälfte der Todesfälle pro Bürger. Im Durchschnitt wurde die Sterblichkeitsrate durch die 20 Tage eher ergriffenen Maßnahmen halbiert.

Italien hat dies schließlich auch erkannt. Am Sonntag sperrten sie zunächst die Lombardei ab, und am Montag, einen Tag später, erkannten sie ihren Fehler und entschieden, das ganze Land abzuriegeln.

Hoffentlich werden wir in den kommenden Tagen Resultate sehen. Allerdings wird es ein bis zwei Wochen brauchen. Erinnern Sie sich an das Wuhan-Diagramm: Zwischen der Ankündigung der Abriegelung und dem Beginn der offiziellen Fälle (orange) lagen 12 Tage.

Wie können Politiker zur sozialen Isolierung beitragen?

Die Politiker stellen sich heute nicht die Frage, ob sie etwas tun sollen, sondern vielmehr, was die angemessene Maßnahme ist.

Zur Bekämpfung einer Epidemie gibt es mehrere Stufen, die mit der Vorbeugung beginnen und mit der Ausrottung enden. Aber für die meisten Optionen ist es heute zu spät. Bei diesem Ausmaß an Erkrankungen haben die Politiker nur zwei Optionen vor Augen: Eindämmung und Abschwächung.

Die Eindämmung stellt sicher, dass alle Fälle identifiziert, kontrolliert und isoliert werden. Genau das machen Singapur, Hongkong, Japan oder Taiwan so gut: Sie schränken sehr schnell die Zahl der einreisenden Personen ein, identifizieren die Kranken, isolieren sie sofort, verwenden schwere Schutzausrüstung zum Schutz ihrer Mitarbeiter im Gesundheitswesen, verfolgen alle ihre Kontakte, stellen sie unter Quarantäne... Das funktioniert sehr gut, wenn man vorbereitet ist und es frühzeitig tut, und man muss die Wirtschaft dafür nicht zum Erliegen bringen.

Ich habe bereits die Vorgehensweise Taiwans angedeutet. Aber auch der chinesische Ansatz ist gut. Die Anstrengungen, die das Land unternommen hat, um das Virus einzudämmen, sind verblüffend. Beispielsweise hatten sie bis zu 1.800 Teams von je 5 Personen, die jede infizierte Person verfolgten, jeden, mit dem sie in Kontakt kamen, und dann jeden, mit dem diese Personen interagierten, und die Gruppe isolierten. Auf diese Weise konnten sie das Virus in einem Land mit einer Milliarde Menschen eindämmen.

Die westlichen Länder haben das nicht getan. Und jetzt ist es zu spät. Die jüngste Ankündigung der USA, dass die meisten Reisen aus Europa verboten wurden, ist eine Eindämmungsmaßnahme für ein Land, das bis heute dreimal so viele Fälle hatte wie Hubei, als es geschlossen wurde, und das exponentiell anstieg. Wie können wir wissen, ob es genug ist? Das wissen wir, wenn wir uns das Reiseverbot von Wuhan ansehen.

corona24

Diese Grafik zeigt, wie sich das Reiseverbot in Wuhan auf die Verzögerung der Epidemie ausgewirkt hat. Die Blasengrößen zeigen die Anzahl der täglichen Erkrankungen. Die obere Zeile zeigt die Fälle, wenn nichts unternommen wird. Die beiden anderen Zeilen zeigen die Auswirkungen, wenn 40% und 90% der Reisen eliminiert werden. Es handelt sich um ein von Epidemiologen erstelltes Modell, denn wir können es nicht mit Sicherheit wissen.

Wenn Sie keinen großen Unterschied sehen, haben Sie Recht. Es ist sehr schwer, eine Veränderung in der Entwicklung der Epidemie zu erkennen.

Forscher schätzen, dass das Reiseverbot in Wuhan die Ausbreitung in China insgesamt nur um 3-5 Tage verzögert hat.

Was dachten die Forscher, was denn eine Verringerung der Übertragung bewirken sollte?

corona25

Der obere Block ist derselbe wie zuvor. Die beiden anderen Blöcke zeigen abnehmende Übertragungsraten. Wenn die Übertragungsrate um 25% sinkt (durch soziale Isolierung), verflacht sich die Kurve und verzögert den Höhepunkt um ganze 14 Wochen. Wenn die Übergangsrate um 50% sinkt, kann man die Epidemie nicht einmal innerhalb eines Quartals sehen.

Das Reiseverbot der US-Regierung für Europa ist gut: Es hat uns wahrscheinlich ein paar Stunden, vielleicht ein oder zwei Tage erkauft. Aber nicht mehr. Es ist nicht genug. Es ist Eingrenzung, wenn es darum geht, die Seuche zu entschärfen.

Wenn die Zahl der Fälle in der Bevölkerung einmal um Hunderte oder Tausende wächst, reicht es nicht mehr aus, weitere Fälle zu verhindern, die bestehenden zu verfolgen und ihre Kontakte zu isolieren. Die nächste Ebene ist die Entschärfung.

Linderung

Die Abmilderung erfordert eine starke soziale Isolierung. Die Menschen müssen aufhören, sich draußen aufzuhalten, um die Übertragungsrate (wie viele Menschen steckt ein Infizierter an) von ca. zwei bis drei, der das Virus ohne Maßnahmen folgt, auf unter eins zu senken, damit es schließlich aussterben kann.

Dazu müssen Unternehmen, Geschäfte, öffentliche Verkehrsmittel, Schulen geschlossen, Sperren durchgesetzt werden... Je schlimmer die Situation, desto größer die soziale Isolation. Je früher Sie schwere Maßnahmen verhängen, desto weniger Zeit brauchen Sie, um sie aufrechtzuerhalten, desto leichter ist es, Störungen zu erkennen, und desto weniger Menschen werden infiziert.

Genau das musste Wuhan tun. Das ist es, was Italien zu akzeptieren gezwungen war. Denn wenn das Virus grassiert, besteht die einzige Maßnahme darin, in allen betroffenen Gebieten die Verbreitung des Virus auf einmal zu stoppen.

Bei Tausenden von offiziellen Fällen - und Zehntausenden von tatsächlichen Fällen - müssen Länder wie der Iran, Frankreich, Spanien, Deutschland, die Schweiz oder die USA genau das tun.

Einige Unternehmen arbeiten von zu Hause aus, was fantastisch ist.
Einige Massenveranstaltungen werden gestoppt.
Einige betroffene Gebiete stehen unter Quarantäne.

All diese Maßnahmen werden das Virus verlangsamen. Sie werden die Übertragungsrate von 2,5 auf 2,2, vielleicht sogar auf 2 senken. Aber sie reichen nicht aus, um uns für einen längeren Zeitraum unter eins zu bringen, um die Epidemie zu stoppen. Und wenn wir das nicht schaffen, müssen wir sie so nahe wie möglich an eins herankommen, um die Kurve abzuflachen.

Also lautet die Frage: Welche Kompromisse könnten wir eingehen, um die Übertragungsrate zu senken? Dies ist das Programm, das Italien uns allen vorgelegt hat:

  • Niemand darf Sperrgebiete betreten oder verlassen, es sei denn, es gibt nachgewiesene familiäre oder berufliche Gründe.
  • Bewegung innerhalb der Bereiche ist zu vermeiden, es sei denn, sie sind aus dringenden persönlichen oder beruflichen Gründen gerechtfertigt und können nicht aufgeschoben werden.
  • Menschen mit Symptomen (Atemwegsinfektion und Fieber) wird "dringend empfohlen", zu Hause zu bleiben.
  • Die Standardurlaubszeit für Beschäftigte im Gesundheitswesen wird ausgesetzt.
  • Schließung aller Bildungseinrichtungen (Schulen, Universitäten...), Sporthallen, Museen, Skistationen, Kultur- und Sozialzentren, Schwimmbäder und Theater.
  • Bars und Restaurants haben begrenzte Öffnungszeiten von 6 Uhr morgens bis 18 Uhr abends, wobei der Abstand zwischen den Personen mindestens einen Meter betragen muss.
  • Alle Pubs und Clubs müssen schließen.
  • Alle kommerziellen Aktivitäten müssen einen Abstand von einem Meter zwischen den Kunden einhalten. Diejenigen, die das nicht schaffen, müssen schließen. Kirchen können geöffnet bleiben, solange sie diesen Abstand garantieren können.
  • Krankenhausbesuche von Familie und Freunden sind begrenzt.
  • Meetings müssen verschoben werden. Die Arbeit von zu Hause aus muss gefördert werden.
  • Alle Sportveranstaltungen und Wettbewerbe, ob öffentlich oder privat, werden abgesagt. Wichtige Veranstaltungen können hinter verschlossenen Türen abgehalten werden.

Nur zwei Tage später fügte man hinzu: Nein, eigentlich müssen Sie alle Geschäfte schließen, die nicht unverzichtbar sind. Jetzt schließen wir also alle kommerziellen Aktivitäten, Büros, Cafés und Geschäfte. Nur das Transportwesen, die Apotheken und die Lebensmittelgeschäfte bleiben geöffnet.

Ein Lösungsansatz ist die schrittweise Ausweitung der Maßnahmen. Unglücklicherweise gibt das dem Virus wertvolle Zeit, sich zu verbreiten. Wenn Sie sicher sein wollen, machen Sie es im Wuhan-Stil. Die Leute mögen sich jetzt beschweren, aber sie werden Ihnen später danken.

Wie können Führungskräfte aus der Wirtschaft zur sozialen Isolierung beitragen?

Wenn Sie ein Unternehmer sind und wissen möchten, was Sie tun sollten, ist der Staying Home Club die beste Ressource für Sie. Es handelt sich um eine Liste von Maßnahmen zur sozialen Isolierung, die von US-Technologieunternehmen ergriffen wurden - bisher 138. Sie reichen von erlaubter bis hin zu vorgeschriebener Heimarbeit und eingeschränkten Besuchen, Reisen oder Veranstaltungen.

Es gibt noch mehr Dinge, die jedes Unternehmen festlegen muss, wie z.B. was mit den stundenweise beschäftigten Arbeitern zu tun ist, ob das Büro offen bleiben soll oder nicht, wie Bewerbungsgespräche zu führen sind, was mit den Cafeterias zu tun ist … So machen wir das bei uns.

Wann?

Es ist sehr gut möglich, dass Sie bisher mit allem, was ich gesagt habe, einverstanden waren und sich von Anfang an gefragt haben, wann die einzelnen Entscheidungen getroffen werden sollen. Anders ausgedrückt: Welche Auslöser sollten wir für jede Maßnahme haben?

Risiko-basiertes Modell

Mein Modell ermöglicht es Ihnen, die wahrscheinliche Anzahl der Krankheitsfälle in Ihrem Gebiet zu beurteilen, die Wahrscheinlichkeit, dass Ihre Mitarbeiter bereits infiziert sind, wie sich dieser Zustand im Laufe der Zeit entwickelt und wie sich daraus ableiten lässt, ob Sie weiterhin offen bleiben sollten.

Es sagt uns Dinge wie:

  • Wenn Ihr Unternehmen 100 Mitarbeiter im Gebiet des Bundesstaates Washington mit 11 Coronavirus-Toten hat, besteht eine 25%ige Wahrscheinlichkeit, dass mindestens einer Ihrer Mitarbeiter infiziert ist, und Sie sollten sofort schließen.
  • Wenn Ihr Unternehmen 250 Mitarbeiter hauptsächlich in der South Bay (San Mateo und Santa Clara County, die zusammen 22 offizielle Fälle haben und die tatsächliche Zahl wahrscheinlich mindestens 54 beträgt) hat, haben Sie am 9. März eine 2%ige Wahrscheinlichkeit, dass mindestens ein Mitarbeiter infiziert ist.
  • Wenn Ihr Unternehmen in Paris (intramuros) angesiedelt ist und 250 Mitarbeiter hat, besteht heute eine Wahrscheinlichkeit von 95%, dass einer Ihrer Mitarbeiter das Coronavirus hat, und Sie sollten Ihr Büro morgen schließen.

Das Modell verwendet Bezeichnungen wie "Unternehmen" und "Mitarbeiter", aber dasselbe Modell kann auch für alles andere verwendet werden: Schulen, öffentliche Verkehrsmittel... Wenn Sie also nur 50 Mitarbeiter in Paris haben, aber alle den RER nehmen und auf Tausende von anderen Menschen treffen, ist die Wahrscheinlichkeit, dass mindestens einer von ihnen infiziert wird, plötzlich viel höher, und Sie sollten Ihr Büro sofort schließen.

Wenn Sie immer noch zögern, weil niemand Symptome zeigt, sollten Sie sich klarmachen, dass 26% der Ansteckungen auftreten, bevor es Symptome gibt.

Gehören Sie zu echten Führungskräften?

Diese Rechnung ist egoistisch. Es betrachtet das Risiko jedes Unternehmens individuell und geht so viel Risiko ein, wie wir wollen, bis der unvermeidliche Hammer des Coronavirus unsere Büros schließt.

Aber wenn Sie zu der Spitzengruppe der Unternehmer oder Politiker gehören, dann beziehen sich Ihre Berechnungen nicht nur auf ein einzelnes Unternehmen, sondern auf das Ganze. Die Mathematik lautet: Wie hoch ist die Wahrscheinlichkeit, dass eines unserer Unternehmen infiziert ist? Wenn Sie eine Gruppe von 50 Unternehmen mit durchschnittlich 250 Mitarbeitern in der SF Bay Area repräsentieren, besteht eine 35%ige Wahrscheinlichkeit, dass mindestens eines der Unternehmen einen Mitarbeiter infiziert hat, und eine 97%ige Wahrscheinlichkeit, dass das nächste Woche zutrifft. Ich habe einen Reiter in das Modell eingefügt, damit Sie damit spielen können.

Fazit: Die Kosten des Wartens

Es mag sich beängstigend anfühlen, heute eine Entscheidung zu treffen, aber Sie sollten nicht zu sehr darüber nachdenken.

corona26

In diesem theoretischen Modell werden verschiedene Bevölkerungsgruppen dargestellt: Die eine trifft keine sozialen Abgrenzungsmaßnahmen, die andere trifft sie am Tag n des Ausbruchs, die andere am Tag n+1. Alle diese Zahlen sind völlig fiktiv (ich habe sie so gewählt, dass sie den Ereignissen in Hubei ähneln, mit ~6k täglich neuen Fällen im schlimmsten Fall). Sie sind nur dazu da, zu veranschaulichen, wie wichtig ein einziger Tag bei etwas sein kann, das exponentiell wächst. Man kann sehen, dass die eintägige Verzögerung später und stärker zunimmt, aber dann konvergieren die täglichen Fälle gegen Null.

Aber was ist mit kumulativen Fällen?

corona27

In diesem theoretischen Modell, das in etwa an Hubei erinnert, führt das Warten eines weiteren Tages zu 40% mehr Krankheitsfällen! Hätten die Behörden in Hubei den Ausnahmezustand am 22. Januar statt am 23. Januar erklärt, hätten sie die Zahl der Fälle womöglich um ganze 20.000 reduziert.

Und denken Sie daran, dass dies nur Fälle sind. Die Sterblichkeit wäre viel höher, denn es gäbe nicht nur direkt 40% mehr Todesfälle. Es gäbe auch einen viel stärkeren Zusammenbruch des Gesundheitssystems, was zu einer bis zu 10-mal höheren Sterblichkeitsrate führen würde, wie wir zuvor gesehen haben. Ein eintägiger Unterschied bei den Maßnahmen zur sozialen Isolierung kann also dazu führen, dass die Zahl der Todesfälle in Ihrer Region explodiert, indem mehr Fälle und eine höhere Sterblichkeitsrate vervielfacht werden.

Dies ist eine exponentielle Bedrohung. Jeder Tag zählt. Wenn Sie eine Entscheidung um einen einzigen Tag verzögern, tragen Sie vielleicht nicht zu ein paar Fällen bei. Wahrscheinlich gibt es in Ihrer Gegend bereits Hunderte oder Tausende von Fällen. Jeden Tag, an dem es keine soziale Isolierung gibt, wachsen diese Fälle explosionsartig an.

Selbstbau eines A10NSP Gateways

11/03/2020 9:58 pm Lutz Donnerhacke Tags: IPv6 , Internet , BSD , Dokumentation , CPE , Fernsehen , QoS 0

Ein Kunde wünscht eine bezahlbare, skalierbare Lösung für den Anschluss von xDSL-Kunden, die per L2-BSA von der DTAG zugeführt werden. Natürlich sollen die eigenen Produkte erhalten bleiben, die Kunden in ihrem Router - wie gewohnt - den richtigen Provider auswählen, kurz gesagt, ein Telekom-Anschluss soll so funktionieren wie ein direkt durch den Kunden betriebener DSL Zugang.

Aufgabenstellung

Der Anschluss beim Endkunden wird als Ethernet-Übergabe mit mehreren (einfach getaggten) VLANs ausgeführt. Der Kunde soll dort alle VLANs nutzen können, die auch sonst an einem direkt versorgten Anschluss zur Verfügung stehen.

Es soll Triple-Play möglich sein, also nennen wir die benötigten VLANs mal 140 für Internet, 141 für IPTV und 142 für VoIP. Die Nummern sind egal, es können auch 7, 18 und 4012 benutzt werden. Wichtig ist nur, dass alle Pakete am Anschluss nach einem festen Schema getaggt übergeben werden. Dieses Schema wird durch die Auswahl des Providers in der CPE (z.B. Fritzbox) des Endkunden festgelegt.

VLANs am Kundenanschluss
Payload (z.B. IP)
C-VLAN Tag
Source-MAC
Destination-MAC

Ein L2-BSA Zugang durch die DTAG sammelt nun die einfach getaggten Pakete (C(ustomer)-Tag) ein, versieht sie mit einem zusätzlichen VLAN-Tag (S(erviceprovider)-Tag), anhand dessen die Transporttechnik der DTAG den Endkundenport wieder identifizieren kann und übergibt die Pakete dann doppelt getaggt an uns. Umgekehrt erkennt die DTAG anhand des äußeren S-Tags, an welchen Kundenanschluss die Pakete raus fallen sollen. Das S-Tag wird entfernt und das C-Tag ist beim Kunden sichtbar.

VLANs am Übergabesanschluss
Payload (z.B. IP)
C-VLAN Tag
S-VLAN Tag
Source-MAC
Destination-MAC

Dieses Verfahren hat mehrere Konsequenzen:

  • Das S-Tag charakterisiert die Verbindung zwischen Kundenanschluss und Provider.
  • Hinter dem S-Tag stehende C-Tags, Protokolle oder gar MAC-Adressen sind dem Transportweg komplett egal.
  • Auf diese Weise können beliebig viele Endgeräte hinter einem Anschluss versorgt werden.
  • Es können auch beliebige Produkte (IPv4, IPv6, ...) angeboten werden.
  • Da sich die DTAG für die Inhalte der Pakete nicht interessiert, übernimmt sie auch keine Multicast-Replikation z.B. für IPTV. Wenn also fünf Teilnehmer einen Sender schauen, müssen die Pakete fünf mal (mit unterschiedlichen S-Tags) gesendet werden.
  • Pro Kundenanschluss benötigt man ein anderes, eindeutiges Tag. Dieses muss von dem Transportprovider, der DTAG, verwaltet werden.
  • Somit sind pro Übergabeanschluss (BNG) nur ca. 4000 Kundenanschlüsse möglich (Wertebereich von VLAN Tags)

Die DTAG behält sich vor, dass sie das S-Tag pro neuem Verbindungsaufbau (DSL-Sync) neu vergibt. Ist der Kunde also bisher unter dem S-Tag 432 sichtbar gewesen, so kann er nach einem Reset seines Routers oder einer Leitungsstörung spontan unter dem neuen S-VLAN 874 auftauchen. Pakete, die in Richtung Kunden mit dem S-Tag 432 geschickt werden, kommen also von jetzt auf gleich nicht mehr an.

VLANs am Übergabesanschluss
Payload (z.B. IP) Daten Daten
C-VLAN Tag 140 140
S-VLAN Tag 432 874
Source-MAC 01:02:03:04:05:06 01:02:03:04:05:06
Destination-MAC 01:02:03:07:08:09 01:02:03:07:08:09
  vorher nachher

Interessanterweise besteht die DTAG bei einer umgekehrten Versorgung mit L2-BSA durch ein Netz eines anderen Providers darauf, dass die S-Tags pro Kunde fix bleiben und sich nicht ändern dürfen.

Da bisher das Netz wie eine große L2-Wolke betrachtet wurde, sollen die neuen Anschlüsse ebenso funktionieren.

Darüber hinaus gibt es ein Problem durch die unterschiedlichen Anschlussbandbreiten. Die DTAG möchte keinesfalls bei Produktwechseln (andere Anschlussbandbreite) involviert sein, also:

  • handelt sie selbst in Richtung Endkunden die höchstmögliche Geschwindigkeit aus, die die Technik her gibt.
  • verpflichtet sie den Provider, nicht mehr Bandbreite dem Endkunden zur Verfügung zu stellen, wie dieser lt. Produktbeschreibung verkauft hat, auch wenn der Anschluss schneller synchronisierte.
  • verpflichtet die den Provider, nicht mehr Bandbreite zum Endkunden zu schicken, als dessen Anschluss auch real her gibt, selbst dann, wenn die verkaufte Bandbreite höher ist.
  • bietet sie dem Provider gewisse reservierte Bandbreiten mit besonderen QoS-Zusagen, z.B. geringer Jitter (für VoIP) oder minimaler Paketverlust (für IPTV).

Um den Provider zur Einhaltung dieser Regeln zu zwingen (und damit der Überlastung des eigenen Netzes entgegen zu wirken), sind Verletzungen dieser Regeln vertraglich strafbewehrt.

Von der Idee zur Umsetzung

Konzentriert man sich allein auf das S-Vlan Problem, so genügt es anhand der MAC Adresse herauszufinden auf welchem Weg das Paket ursprünglich herein gekommen war. Stellt man sich jedes S-Vlan als eigene Leitung vor, so würde ein Switch mit 4096 Ports die Aufteilung bestens erfüllen: Er lernt anhand der Source-MAC, auf welchem Interface das Paket rein kam, und schickt die Antworten (mit der Ziel-MAC) auch dahin zurück. Kommt die MAC mal von einem anderen Interface (geändertes S-Tag), lernt er um.

Natürlich stellt man sich nicht einen Switch mit derartig vielen Interfaces real hin. Schließlich kommen diese 4000 "Leitungen" pro Anschluss an einen BNG. Für ein kleines Bundesland wie Thüringen, sind das einige Hundert Zuleitungen, die wir aber nicht alle brauchen, weil wir ja selbst ein Netz haben. Die Überschlagsrechnung ergibt: 2,3 Mio Einwohner = 600k Haushalte = 150 BNGs (Minimum)

Anderseits sind sicher nicht alle Haushalte fest als Kunden zu planen, sondern nur ein kleiner Teil wird wechseln wollen. Von den potentiell 4000 "Leitungen" werden nur wenige belegt sein. Es wäre also völlig abstrus, hier dauerhaft alle möglichen Verbindungen offen zu halten. Dazu kommt, dass Broadcast-Traffic (z.B. ARP) an alle potentiellen Teilnehmer gesendet werden müssen. Hält man also alle potentiellen "Leitungen" offen verviertausendfacht man den Traffic. Unnötigerweise.

  1. Der erste Schritt war die Erstellung eines Testbeds, dass die verwendete Anschlusstechnik simulieren kann. Dies wird ausführlich in einem eigenen Artikel dargestellt.
  2. Da zur Terminierung keine realen Switche verwendet werden, sondern preisgünstige Server, landen mehrere BNG-Zuleitungen auf einem Server. Es ist sinnvoll, diese Zuleitungen zu aggregieren, um nicht für jede Zuleitung ein eigenes Terminierungsnetz verwalten zu müssen. Damit werden aus doppelt getaggten Paketen - dreifach getaggte. das zusätzliche A-Tag gibt an, welches Zuleitungs-Interface gerade angesprochen werden soll. Auch das wird in einem eigenen Artikel ausgeführt.

    VLANs nach Aggregation
    Payload (z.B. IP)
    C-VLAN Tag
    S-VLAN Tag
    A-VLAN Tag
    Source-MAC
    Destination-MAC
  3. Da in jedem C-Vlan die MAC-Adressen des Kunden gleich sein dürfen, ist für die weitere Verarbeitung eine Trennung nach C-Vlans nötig. Auch QoS-Einstellungen sind dienstabhängig. Die C-Vlans stehen aber ganz innen im VLAN-Stapel. Es war notwendig, den Stapel zur rotieren, so dass aus der Abfolge C/S/A-Vlan die Abfolge S/A/C-Vlan wird. Nach dieser Rotation steht das C-Vlan direkt zur Verfügung und es kann je nach Dienst getrennt verarbeitet werden. Ein entsprechendes Netgraph-Modul ng_vlan_rotate wurde erstellt.

    VLANs nach Rotation
    Payload (z.B. IP)
    S-VLAN Tag
    A-VLAN Tag
    C-VLAN Tag
    Source-MAC
    Destination-MAC
  4. Was nun noch bleibt, sollte eigentlich leicht sein: Die doppelt getaggten VLANs (außen A, innen S) müssen wieder auseinander genommen, und über ein Netgraph-Modul ng_bridge mit dem Ausgang zum Providernetz verbunden werden. Unglücklicherweise kann das Modul aber nur 32 Links verbinden, viel zu wenig! Aber wie verbindet man die Links nur bei Bedarf? Auch das wird in einem eigenen Artikel ausgeführt.

    VLANs pro Dienst
    Payload (z.B. IP)
    S-VLAN Tag
    A-VLAN Tag
    Source-MAC
    Destination-MAC
  5. Und woher kommen die QoS-Parameter, damit die Leitungen nicht überlastet werden? Die stehen in den DHCP-Paketen: Die DTAG schreibt in die Option82/9 die aktuelle Bandbreite rein. Das muss natürlich ausgewertet werden. Wenn man schon mal an der Stelle ist, kann man mit der Antwort vom DHCP-Server auf die gleiche Weise auch die verkaufte Produkt-Bandbreite übermitteln. Auch das wird in einem eigenen Artikel ausgeführt.

Alles zusammen genommen besteht das Netgraph Netzwerk aus folgenden Komponenten:

L2BSA Netgraph Übersicht

In den Tests zeigten sich dann weitere Probleme:

  • Die MAC-Adress-Tabelle der ng_bridge und die Anzahl der VLANs an einem ng_vlan wird schnell so groß, dass die Daten nicht mehr ausgewertet werden können.
  • Noch ein paar Daten mehr und sie passen nicht mal mehr durch die Kernel-API.
  • Natürlich ist es komplett sinnfrei, auf dem Uplink zum ISP hin die MAC Adressen zu lernen. Das entschärft einen Großteil der Probleme.

Und tut's?

Wie man mit tcpdump auf doppelt getagged Pakete prüft

20/02/2020 4:03 pm Lutz Donnerhacke Tags: BSD 0

Für einen bpf Filter benötige ich die Möglichkeit mehrfach mit VLANs getaggte Pakete zu erkennen und in deren Inhalt nach protokollspezifischen Werten zu durchsuchen. Natürlich möchte ich die binären Regeln nicht komplett von Hand schreiben.

Der einfache Ansatz ist sich das Regelwerk durch tcpdump selbst erzeugen zu lassen.

# tcpdump -s 0 -p -d 'ip and udp and src port 12345'
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x11            jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 14]
(008) jeq      #0x3039          jt 9    jf 10
(009) ret      #262144
(010) ret      #0

Dieser Code macht folgendes:

  • Im Ethernet-Header (an Position 12) wird der Ethertype ermittelt.
  • Ist der IPv4 (0800), so geht's bei 2 weiter, anderenfalls Abbruch zu 10.
  • Im IP-Header (an Position 23 aus Sicht des kompletten Frames) steht die Protokollnummer.
  • Ist diese UDP (17 = 0x11), geht's weiter.
  • Nach dem variabel langen IP-Header (Länge in 32bit Worten an Position 14) folgt der UDP Header.
  • Dort steht an (der variablen) Position die Portnummer.
  • Entspricht die dem gewünschten Wert, gibt's einen positiven Rückgabewert (der i.d.R. die Länge der zu exahierenden Daten entspricht).
  • Anderenfalls gibt es den Fehlercode 0 zurück (oder auch 0 verwertbare Bytes).

Oder direkt binär, so wie ich es brauche:

# tcpdump -s 0 -p -ddd 'ip and udp and src port 12345'
11
40 0 0 12
21 0 8 2048
48 0 0 23
21 0 6 17
40 0 0 20
69 4 0 8191
177 0 0 14
72 0 0 14
21 0 1 12345
6 0 0 262144
6 0 0 0 

Dieser BPF Code nimmt an, dass das Paket direkt mit IP beginnt, es gibt keine VLAN Frames (die jeweils 4 Byte kosten).

Ich lönnte jetzt also an allen Stellen, wo auf eine Position im Paket Bezug genommen wird, einen entsprechenden Offset manuell hinzufügen. Dieses manuelle Nachpatchen ist jedoch nicht sonderlich wartungsfreundlich.

Nach einigem Suchen fand ich den undokumentierten Befehl vlan. Wenn man den vor den Ausdruck stellt, passt das tcpdump den BPF-Filter passend an.

# root@a10nsp:~ # tcpdump -s 0 -p -d 'vlan 123 and ip and udp and src port 12345'
(000) ldh      [12]
(001) jeq      #0x8100          jt 4    jf 2
(002) jeq      #0x88a8          jt 4    jf 3
(003) jeq      #0x9100          jt 4    jf 17
(004) ldh      [14]
(005) and      #0xfff
(006) jeq      #0x7b            jt 7    jf 17
(007) ldh      [16]
(008) jeq      #0x800           jt 9    jf 17
(009) ldb      [27]
(010) jeq      #0x11            jt 11   jf 17
(011) ldh      [24]
(012) jset     #0x1fff          jt 17   jf 13
(013) ldxb     4*([18]&0xf)
(014) ldh      [x + 18]
(015) jeq      #0x3039          jt 16   jf 17
(016) ret      #262144
(017) ret      #0 

Man sieht sehr schön, dass die Offsets für die Paketanalyse schön um vier Bytes verschoben wurden.

Gehen auch zwei VLANs?

# tcpdump -s 0 -p -d 'vlan 123 and vlan 456 and ip and udp and src port 12345'
(000) ldh      [12]
(001) jeq      #0x8100          jt 4    jf 2
(002) jeq      #0x88a8          jt 4    jf 3
(003) jeq      #0x9100          jt 4    jf 24
(004) ldh      [14]
(005) and      #0xfff
(006) jeq      #0x7b            jt 7    jf 24
(007) ldh      [16]
(008) jeq      #0x8100          jt 11   jf 9
(009) jeq      #0x88a8          jt 11   jf 10
(010) jeq      #0x9100          jt 11   jf 24
(011) ldh      [18]
(012) and      #0xfff
(013) jeq      #0x1c8           jt 14   jf 24
(014) ldh      [20]
(015) jeq      #0x800           jt 16   jf 24
(016) ldb      [31]
(017) jeq      #0x11            jt 18   jf 24
(018) ldh      [28]
(019) jset     #0x1fff          jt 24   jf 20
(020) ldxb     4*([22]&0xf)
(021) ldh      [x + 22]
(022) jeq      #0x3039          jt 23   jf 24
(023) ret      #262144
(024) ret      #0

Hervorragend: Nun werden doppelt getaggte Pakete ausgewertet. Allerdings muss man die VLAN Tags exakt kennen.

Ich möchte aber nur double tagged VLANs mit variablen VLAN-Nummern bearbeiten, kenne diese also nicht. Wie kann man das beschreiben? Vielleicht als Negation? Nicht VLAN 123? Gibt es eine VLAN Nummer die sicher nicht auftreten kann?

ja, die Null. Eine VLAN Header mit der VLAN-ID 0 ist definiert als untagged, gestattet aber QoS Parameter. Untagged will ich aber nicht, das ist also okay.

# tcpdump -s 0 -p -d 'not vlan 0 and not vlan 0 and ip and udp and src port 12345'
(000) ldh      [12]
(001) jeq      #0x8100          jt 4    jf 2
(002) jeq      #0x88a8          jt 4    jf 3
(003) jeq      #0x9100          jt 4    jf 6
(004) ldh      [14]
(005) jset     #0xfff           jt 6    jf 22
(006) ldh      [16]
(007) jeq      #0x8100          jt 10   jf 8
(008) jeq      #0x88a8          jt 10   jf 9
(009) jeq      #0x9100          jt 10   jf 12
(010) ldh      [18]
(011) jset     #0xfff           jt 12   jf 22
(012) ldh      [20]
(013) jeq      #0x800           jt 14   jf 22
(014) ldb      [31]
(015) jeq      #0x11            jt 16   jf 22
(016) ldh      [28]
(017) jset     #0x1fff          jt 22   jf 18
(018) ldxb     4*([22]&0xf)
(019) ldh      [x + 22]
(020) jeq      #0x3039          jt 21   jf 22
(021) ret      #262144
(022) ret      #0

Und tut!

Flexible Netflow mit Voraggregation im Router

13/09/2018 5:57 pm Lutz Donnerhacke Tags: Internet , Cisco , WTF , Dokumentation 0

Was bei einem ISP so rein und raus geht, ist für die Planung wichtig und für Traffic-Engineering essentiell. Um diese Informationen abzugreifen, hat der Netzwerk-Gott Netflow erfunden. Normalerweise ist Netflow zu detailliert, um es auf höheren Bandbreiten einsetzen zu können, also muß man schon am Router aggregieren.

Beschränkung aufs Relevante

Von Interesse ist, mit welchen Autonomen Systemen der ISP Daten austauscht. Genau dafür gibt es ein vordefiniertes Profil:

#show flow record netflow ipv4 as      
flow record netflow ipv4 as:
  Description:        AS aggregation schemes
  No. of users:       0
  Total field space:  29 bytes
  Fields:
    match routing source as
    match routing destination as
    match interface input
    match interface output
    match flow direction
    collect counter bytes
    collect counter packets
    collect timestamp sys-uptime first
    collect timestamp sys-uptime last

Der entsprechende Eintrag ist gar nicht von der IP Version abhängig und paßt genauso auch auf IPv6. Er definiert einen Flow primär anhand des Quell- und Ziel-ASN. Für alle Pakete, die in allen match-Feldern übereinstimmen, werden die collect-Felder gesammelt. Ob summiert, das Minimum oder das Maximum genommen wird, ist vom jeweiligen Feld abhängig.

Den aufgesammelten Datenwust kann man sich lokal anschauen oder exportieren:

flow exporter server8
 destination 192.0.2.8
 source Loopback0
 transport udp 9995
flow monitor asn
 exporter server8
 record netflow ipv4 as
interface TenGigabitEthernet0/1/0
 ip flow monitor asn input
 ip flow monitor asn output
 ipv6 flow monitor as input
 ipv6 flow monitor asn output

Soweit so einfach.

Auf dem betreffenden Server läuft dann ein Netflow-Collector, der die Daten einsammelt und alle fünf Minuten in eine extra Datei auf der Platte ablegt. Auf dieser Datei führe ich nun meine Aggregation aus.

~# nfdump -r /var/spool/netflow/2018/09/27/12/nfcapd.201809271200 -A srcas -O bps | head
Date first seen          Duration  Src AS   Packets    Bytes      bps    Bpp Flows
2018-09-27 11:58:23.111   400.103   15169    38.9 M   47.7 G  953.1 M   1225 25304
2018-09-27 11:58:22.973   401.026       0   157.9 M   45.9 G  915.4 M    290 714869
2018-09-27 11:58:24.009   399.987    2906    23.3 M   34.4 G  688.4 M   1474  1223
2018-09-27 11:58:23.215   400.643   16509    26.0 M   33.7 G  673.7 M   1297 34785
2018-09-27 11:58:23.167   399.702   16097    18.3 M   27.0 G  541.3 M   1477  2560
2018-09-27 11:58:23.143   399.853    3356    16.9 M   25.2 G  503.6 M   1486  3869
2018-09-27 11:58:23.411   396.579    6185    15.3 M   22.7 G  458.5 M   1488  3624
2018-09-27 11:58:29.698   393.297   22822    10.8 M   16.0 G  324.6 M   1482   734
2018-09-27 11:58:23.095   400.807   32934    11.7 M   14.6 G  292.4 M   1251 11138

Sehr schön. Das AS0 ist Traffic, der von lokal kommt (ausgehend also). Dann plotte ich das mal auf:

2018-09-13-151512_447x228_scrot

WTF? Das ist definitiv nicht korrekt.

Fehlersuche

Bei der Auswertung sind ja viele einzelne Flows nochmal nachaggregiert worden. Wenn man die sich einzeln anschaut, dann gibt es keinen einzigen Flow, der mehr als 4,3 GByte an Daten enthält. Und von diesen gibt es eine ganze Menge. Alle mit der identischen Datenmenge.

Was ist passiert?

#show flow exporter templates
  Client: Flow Monitor asn
  Exporter Format: NetFlow Version 9
  Template ID    : 0
  Source ID      : 0
  Record Size    : 29
  Template layout
  _____________________________________________________________________
  |                 Field                   |  Type | Offset |  Size  |
  ---------------------------------------------------------------------
  | timestamp sys-uptime first              |    22 |     0  |     4  |
  | timestamp sys-uptime last               |    21 |     4  |     4  |
  | counter bytes                           |     1 |     8  |     4  |
  | counter packets                         |     2 |    12  |     4  |
  | interface input snmp                    |    10 |    16  |     4  |
  | interface output snmp                   |    14 |    20  |     4  |
  | flow direction                          |    61 |    24  |     1  |
  | routing destination as                  |    17 |    25  |     2  |
  | routing source as                       |    16 |    27  |     2  |
  ---------------------------------------------------------------------

Der Byte-Zähler hat eine Größe von 4 Byte, also 32bit, was genau bis 4294967295 enthalten kann. Anders gesagt: Mehr als 4,3 GByte kann man nicht pro Flow exportieren. Und diese Grenze wird immer wieder gerissen.

Normalerweise ist es kein Problem, einen Flow auf 4GB zu beschränken, da die typische Flow-Definition auch IPs und Portnummern enthält. Mit ausgelasteten 100Mbps braucht man für diese Datenmenge fast sechs Minuten, also mehr als das Meßintervall.

Hier jedoch wird schon auf Routerseite stark voraggregiert, die IP Adressen oder gar die Portnummern spielen keinerlei Rolle mehr. Deswegen werden deutlich weniger Flows erzeugt und exportiert. Andererseits werden die Zähler nun aber deutlich größer.

Ebenfalls auffällig ist, daß auch für die AS-Nummern nur 2 Byte zur Verfügung stehen. Und tatsächlich sind im Export alle 4-Byte ASNs durch 23456 ersetzt, so wie es RFC 4893 vorschreibt. Für die Auswertung ist das natürlich witzlos.

Also definiere ich mir einen maßgeschneiderten Record:

flow record asn
 match routing source as 4-octet
 match routing destination as 4-octet
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long

Und siehe an, das schaut viel besser aus. Wie im obigen Bild zu sehen ist, habe ich die Änderung am ersten Router gegen 17 Uhr vorgenommen. Die Spitzen sind danach deutlich angestiegen.

Aber warum überhaupt die seltsamen Spitzen? Alle halbe Stunde steigt der Traffic stark an, um dann wieder abzufallen? Sehr unwahrscheinlich.

Es sieht so aus, als ob die Flow-Records schlicht nicht gleichmäßig ankommen, sondern schubweise.

#show flow monitor asn
Flow Monitor asn:
  Description:       User defined
  Flow Record:       asn
  Flow Exporter:     server8
  Cache:
    Type:                 normal (Platform cache)
    Status:               allocated
    Size:                 200000 entries
    Inactive Timeout:     15 secs
    Active Timeout:       1800 secs
    Trans end aging:   off

Der Timeout für aktive Flows, also die, auf denen weiter Daten rein kommen, ist 1800 Sekunden, 30 Minuten, eine halbe Stunde!

Selbstverständlich sind bei der aggressiven Aggregation alle Flows dauerhaft aktiv. Sie werden also still aufsummiert und die Zwischensummen alle halbe Stunde exportiert. Im Ergebnis sieht man die Spitzen, da fast alle Flows zu der Zeit beginnen, als Netflow auf dem Interface aktiviert wurde.

Da alle fünf Minuten ein Snapshot beim Collector weggeschrieben wird, sollte man etwas häufiger Zwischensummen exportieren.

flow monitor asn
 exporter server8
 cache timeout active 100
 cache timeout update 150
 record asn

Und schon flutscht es.

2018-09-24-164028_497x248_scrot

Nachts in Neuland

13/09/2018 3:15 pm Lutz Donnerhacke Tags: Internet , WTF , Verfügbarkeit 2

Ein Kunde beschwert sich über eine kaputte Firewall. Die würde abstürzen und müsse immer wieder rebootet werden. Als Verkäufer sollen wir das Gerät tauschen. Aus dieser eigentlich trivialen Aufgabe wurde eine beinahe unendliche Geschichte.

Fehlerbild

Seit einigen Monaten kann der Kunde beinahe jeden Morgen nicht arbeiten. Manchmal ist es Dienstag und Donnerstag. Man manchmal Montag, Mittwoch und Freitag. Manchmal auch ganz anders. Reboot der Firewall und es geht alles wieder. Logischerweise vermutet er einen Defekt an diesem Gerät und möchte einen Hardware-Tausch.

Andererseits macht der Hersteller Streß, wenn funktionierende Technik (unnötig) getauscht werden soll. Ich brauche also zumindest den Ansatz einer Fehlerursache.

Zunächst stellt sich heraus, daß die Reboots zu regelmäßig sind, um auf einen Hardwareschaden hinzudeuten. Jeden Tag um die gleiche Uhrzeit rebootet das Gerät. Auf Rückfrage sagt der Kunde, daß er die Faxen dicke hatte und per Zeitschaltuhr den Reset erzwingt.

Das Logging liegt nur auf dem Gerät selbst vor, so daß keine Aussagen über die Zeit vor dem Reboot getätigt werden können. Der Kunde aktiviert wieder seinen Syslog-Server, der das anfangs noch entgegen genommen hatte. Mangels Nutzeffekt hat man den Server vor einiger Zeit schon abgeschaltet.

Mit dem Syslog ergeben sich nun neue Einsichten:

  • Irgendwann zwischen drei und fünf Uhr fällt das Interface zum Internet-Modem aus und kommt kurz danach wieder.
  • Es taucht ein Gerät im Syslog auf, daß auch im diese Zeit herum in den Stromsparmodus geht und daraus wieder erwacht. Das Gerät hat leistungsstarke Motoren.
  • Die Firewall macht DHCP in Richtung Internet und erneuert alle 5h ihre 10h-Lease.
  • Die Reboots werden inzwischen manuell über die GUI der Firewall zwischen fünf und sechs Uhr ausgelöst.
  • Vor den Reboots meldet die Firewall, daß sie auf Pakete ins Internet keine Antwort bekommt.

Ursachenforschung

Der auffälligste Punkt ist, daß die Firewall nicht völlig kaputt sein kann, wenn man sie über die GUI rebootet.

Die nächste Korrelation ist das Gerät mit den Motoren. Wenn es an oder aus geht, könnte es Störungen im Stromnetz verursachen und so einen Fehler triggern. Auch könnten hochfrequente Störungen den Internetzugang unterbrechen. Schließlich gibt es da ja einen Interface Reset. Der Kunde sagt, das Gerät sei erst vor einigen Monaten angeschafft worden. Das korreliert auffällig mit dem Zeitpunkt ab dem Störungen auftraten. Der Kunde schließt diese Ursache aber kategorisch aus.

Also bleibt die Frage nach dem Internetzugang. Ein Anruf beim Provider (einem kleineren) bringt neue Erkenntnisse:

  • Vor einigen Monaten ist aufgefallen, daß die Anschlußtechnik beim Kunden nicht regelmäßig rebootet wird.
  • Man hat die Geräte in Richtung des Kunden in die Liste der automatischen Reboot aufgenommen.
  • Die Reboots werden sequentiell ausgeführt, eine Sortierung wird nicht erzwungen. Man möchte es zufällig halten.

Wahrscheinlich passiert folgendes:

  • Der Provider rebootet Teile seines Netzes.
  • Die Zuleitungstechnik vergißt dabei die ausgeteilte DHCP Lease, leitet also keine Daten mehr weiter.
  • Im Schnitt erneuert ein Endgerät 2,5h nach dem Reboot die Lease und es geht wieder.
  • Der Kunde beginnt regelmäßig um 5 Uhr mit Arbeiten.
  • Er bemerkt die fehlende Konnektivität und rebootet die Firewall.
  • Die Firewall holt sich direkt beim Booten per DHCP eine neue Adresse und alles geht wieder.

Man kann jetzt ausrechnen, wie hoch die Wahrscheinlichkeit ist, daß der Kunde um 5 Uhr noch keine Konnektivität hat.

Man kann auch die Firewall einmal so rebooten, daß die Lease immer zwischen 4 und 5 Uhr erneuert wird. Dank der 10h Lease ist dieser Rhythmus ja ziemlich stabil, er verschiebt sich täglich um 4h nach vorn. Das erklärt, warum der Kunde den Effekt nicht jeden Tag hat, sondern im Abstand von zwei bis drei Tagen beobachtet.

Man kann aber auch den Provider bitten, nicht zu rebooten.

Fazit

Internetprovider benutzen die Zeit zwischen Mitternacht und sechs Uhr morgens für beliebige, unangekündigte Arbeiten. In dieser Zeit gibt es keinerlei Funktionsgarantie für alles, was irgendwas mit Telekommunikation zu tun hat. Die gesamte IT-Branche benutzt die Nacht für Wartung, Umbauten und Updates.

Die Fachbegriffe der Informatik kennen es so:

337: Uptime Verfügbar an Werktagen zwischen 9:00 und 12:00, sowie 14:00 bis 17:00. (Microsoft SQL Server 2000 Administrator's Companion)

Denk ich an #Neuland in der Nacht, bin ich um den Schlaf gebracht.

nach Heinrich Heine

Datenschutz beim Friseur

24/08/2018 11:46 am Lutz Donnerhacke Tags: Datenschutz 25

Die finale Umsetzung der DSGVO ist nun bald 100 Tage alt. Da läuft mir ein Interview mit dem Landesdatenschutzbeauftragen Herrn Hasse über den Weg, das mich ratlos zurück läßt. Es geht um einen Friseurbesuch.

TLZ: Mir hat ein Friseur neulich erklärt, er könne mir nicht mehr die Haare schneiden, wenn ich sein DSGVO-Formular nicht ausfüllen würde. Das ist doch Unsinn.
Hasse: Mir ist zumindest nicht klar, welche Daten der Friseur da gemeint haben sollte. Wenn es nur darum geht, jemandem die Haare zu schneiden, werden ja keine Daten erhoben. …

Cut-off_ponytail_(close_in)

By Vive la Rosière - Own work, CC BY-SA 3.0

Dies ist für jemanden, der Schulnoten als datenschutzrechtlich relevant ansieht, eine überraschende Aussage.

Was geschieht denn genau beim Friseur?

Man wartet und bekommt die Haare geschnitten. Dann bezahlt und geht man wieder.

Zurück bleiben die Haare.

Haare sind Körpermaterial und damit biometrische Daten.

Die DSGVO sagt dazu in Artikel 9 (Abs 1)

Die Verarbeitung personenbezogener Daten, aus denen die rassische und
ethnische Herkunft, politische Meinungen, religiöse oder
weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit
hervorgehen, sowie die Verarbeitung von genetischen Daten, biometrischen
Daten zur eindeutigen Identifizierung einer natürlichen Person,
Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen
Orientierung einer natürlichen Person ist untersagt.

Wie gefährlich Haare sind, mußte schon ein Fussballtrainer erfahren. Man kann also nicht behaupten, die Deutschen™ wüßten nichts davon.

Geht man noch einen Schritt weiter und schaut, was mit den Haaren im Friseursalon so passiert, wird es erst richtig spannend. Echthaar ist bei der Perückenherstellung begehrt. Dazu muß es sortiert aufbewahrt werden, was sich natürlich beim einfachen Trimm nicht lohnt.

Die DSGVO sagt dazu in Art 4 (Abs 6)

"Dateisystem" jede strukturierte Sammlung personenbezogener Daten, die
nach bestimmten Kriterien zugänglich sind, unabhängig davon, ob diese
Sammlung zentral, dezentral oder nach funktionalen oder geografischen
Gesichtspunkten geordnet geführt wird;

Eine sortierte Aufbewahrung von Haaren gehört hier zweifelsfrei dazu.

Und was macht der Friseur dann mit dem Langhaar? Verkaufen. Aber das will ich in Hinblick auf Art 46 DSGVO nicht weiter thematisieren.

Was nicht verkauft wird, wird weggeworfen (gelöscht). Auch dafür gibt es entsprechende Reglungen, wie Art 28 DSGVO, da der Entsorger als Auftragsdatenverarbeiter anzusehen ist.

Warum kreide ich das Herrn Hasse an? Weil er nach Art 35 Abs 2 DSGVO im Rahmen der notwendigen Datenschutzfolgeabschätzung als absegnende Stelle involviert ist.

Wenn der Traceroute Kreise tanzt

25/07/2018 1:24 pm Lutz Donnerhacke Tags: WTF , BSD 0

Manchmal überrascht einen eine Trivialität. Ich wollte das Routing einer Server-IP prüfen, aber der Trace wurde zu mir zurück reflektiert. Wie geht das?

Wunder

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 40 byte packets
 1  switch1-9-4-1-vl52.net.iks-jena.de (217.17.197.11)  1.470 ms  1.372 ms  1.304 ms
 2  turm1-g001.net.iks-jena.de (217.17.197.49)  0.382 ms  0.438 ms  0.363 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.613 ms  0.574 ms  0.566 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.465 ms  1.141 ms  1.170 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.567 ms  0.538 ms  0.541 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  2.181 ms  1.469 ms  1.686 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.641 ms  0.635 ms  0.575 ms
 8  switch2-v58.net.encoline.de (5.102.160.129)  9.887 ms  3.478 ms  1.380 ms
 9  rudo7-t000-123.net.encoline.de (5.102.160.90)  0.879 ms  0.740 ms  0.721 ms
10  turm1-g001-116.net.iks-jena.de (5.102.160.99)  0.991 ms  0.942 ms  1.012 ms
11  * * *
12  nat-178-19-224-48.net.encoline.de (178.19.224.48)  1.123 ms  1.052 ms  1.025 ms

Der Trace geht raus, kehrt um, kommt zurück und am Ende meint er das Ziel erreicht zu haben.

Dabei trifft er sogar bestimmte Router mehrfach. Das ist deswegen verwunderlich, weil doch die Router ihre Entscheidung allein anhand der Zieladresse fällen. Wie kann also das Paket in verschiedene Richtungen geroutet werden?

Zunächst erst einmal handelt es sich nicht um ein lokales Phänomen, sondern es funktioniert auch von anderen Quellen aus.

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 60 byte packets
...
 4  inexio2.gw.network.manitu.net (89.238.127.62)  4.593 ms  4.594 ms  4.592 ms
 5  209-096-244-077.ip-addr.inexio.net (77.244.96.209)  7.633 ms  7.634 ms  7.642 ms
 6  DE-CIX1.de.lambdanet.net (80.81.193.74)  7.605 ms  7.358 ms  6.739 ms
 7  ae2.irt2.fra25.de.as13237.net (217.71.96.45)  7.881 ms  7.878 ms  7.584 ms
 8  ae5.irt1.han87.de.as13237.net (217.71.96.30)  13.407 ms  13.380 ms  13.390 ms
 9  ae7.irt1.ber02.de.as13237.net (217.71.96.133)  16.610 ms  16.613 ms  16.607 ms
10  bb-erf-02-loc.netz.netkom-line.net (109.73.31.198)  213.352 ms  213.364 ms  213.361 ms
11  tnk-ilm-001-loc.netz.netkom-line.net (109.73.31.195)  22.149 ms  20.946 ms  20.579 ms
12  109.73.31.141 (109.73.31.141)  147.983 ms  147.987 ms  147.974 ms
13  tnk-jen-001-loc.netz.netkom-line.net (109.73.31.193)  19.504 ms  19.453 ms  19.471 ms
14  tnk-jen-001-ipt.netz.netkom-line.net (109.73.31.194)  19.468 ms  19.468 ms  19.467 ms
15  rudo7-t010.net.encoline.de (5.102.160.105)  33.994 ms  34.003 ms  34.002 ms
16  switch2-v123.net.encoline.de (5.102.160.91)  34.350 ms  34.407 ms  34.573 ms
17  server16-vlan58.net.encoline.de (5.102.160.132)  33.875 ms  33.879 ms  33.866 ms
18  switch4-v94.net.encoline.de (5.102.160.178)  34.753 ms  35.605 ms  35.596 ms
19  server16-vlan94.net.encoline.de (5.102.160.185)  34.362 ms  34.259 ms  34.179 ms
20  switch2-v58.net.encoline.de (5.102.160.129)  34.800 ms  35.279 ms  34.905 ms
21  rudo7-t000-123.net.encoline.de (5.102.160.90)  34.440 ms  34.203 ms  34.452 ms
22  rudo5-t001-123.net.encoline.de (5.102.160.89)  34.228 ms  34.449 ms  34.435 ms
23  ar2.ber.de.colt.net (213.61.70.177)  55.706 ms  55.705 ms  55.674 ms
24  212.36.135.22 (212.36.135.22)  55.909 ms  56.438 ms  56.417 ms
25  212.36.135.22 (212.36.135.22)  55.398 ms  55.416 ms  55.389 ms
26  * * *
27  * * *
28  * * *
29  nat-178-19-224-48.net.encoline.de (178.19.224.48)  68.590 ms  68.544 ms  68.691 ms

Wow. Hin- und Rückrouting in einem Trace! Man sieht sehr schön den asymmetrischen Rouingweg.

Aber was passiert da?

Schnüffeln

Die Ursache sollte ausschließlich am angesprochenen Server zu suchen sein. Alles andere wäre eine grobe Überraschung, denn dann müßten die Geräte im Transportweg irgendeine Manipulation vorgenommen haben.

Also ein Mitschnitt auf den Außeninterfaces des betroffenen Servers aktiviert:

13:39:51.074580 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 13, length 20
13:39:51.074601 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077408 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 14, length 20
13:39:51.077414 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077939 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 15, length 20
13:39:51.077944 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.078590 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 16, length 20
13:39:51.079237 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.082388 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 17, length 20
13:39:51.084253 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.084855 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 18, length 20
13:39:51.088146 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.088802 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 19, length 20
13:39:51.088848 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092134 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 20, length 20
13:39:51.092176 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092892 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 21, length 20
13:39:51.092934 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.093756 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 22, length 20
13:39:51.093774 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 22, length 20
13:39:51.097201 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.100803 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 23, length 20
13:39:51.100823 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 23, length 20
13:39:51.101499 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.102261 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102280 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102924 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.103742 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103763 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103870 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.106558 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106577 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106687 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.107389 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107408 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107510 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.108284 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108302 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108652 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.111847 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 29, length 20
13:39:51.111866 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 29, length 20
13:39:51.112220 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.113013 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113032 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113386 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.114062 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 31, length 20
13:39:51.114080 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 31, length 20
13:39:51.115606 IP 217.17.197.43 > 217.17.192.34: ICMP time exceeded in-transit, length 36

Man sieht sehr schön, wie anfangs die Echo-Pakete mit einem Timeout beantwortet werden.

Kurz darauf (ab Sequenznummer 22) tauchen plötzlich Echo-Pakete auf, bei denen Quell- und Ziel-Adresse vertauscht sind. Diese entstehen offenbar direkt nach dem Eingang des ersten Paketes.

Nun dient die Kiste ein (Carrier Grade)-NAT. Ihr Zweck ist es also Pakete umzuschreiben und zwar so, daß möglichst wenig Pakete verloren gehen. Schließlich dient NAT ja dazu, Verbindungen zu ermöglichen! Eine Firewall oder Paketfilter würde Pakete verwerfen. NAT dagegen muß so gut wie möglich raten, wo das Paket eigentlich hin soll.

In diesem Fall geht das NAT systematisch vor:

  • Es nattet die fremde Quell-Adresse auf die eigene öffentliche IP.
  • Und es nattet die eigene öffentliche Ziel-IP zu – tja wohin, achja, da ist ja ein ganz frischer Eintrag in der NAT Tabelle …

Fertig ist der Spiegel.

Gefährlich?

Kann man das mit allen Protokollen machen? Wenn ja, könnte man trivial unter falscher Flagge segeln, oder?

Tracing the path to 178.19.224.48 on TCP port 80, 30 hops max
 1  switch1-9-4-1-vl4.net.iks-jena.de (217.17.192.125)  6.742 ms  2.125 ms  1.139 ms
 2  turm2-g001-5.net.iks-jena.de (217.17.197.50)  0.228 ms
    turm1-g001.net.iks-jena.de (217.17.197.49)  0.350 ms
    turm2-g000-3.net.iks-jena.de (217.17.197.34)  0.265 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.449 ms  0.468 ms  0.423 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.414 ms  1.570 ms  2.359 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.489 ms  0.431 ms  0.418 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  1.443 ms  1.166 ms  1.921 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.429 ms  0.473 ms  0.444 ms
 8  switch4-v94.net.encoline.de (5.102.160.178)  14.355 ms  2.695 ms  1.462 ms
 9  server16-vlan94.net.encoline.de (5.102.160.185)  0.473 ms  0.495 ms  0.465 ms
...

Nein, man kann nicht. Und das ist gut so™.

Next » 1 2 3