unerwartete ECN/L4S Manipulationen durch O2?

Servus,

Guter Fund, falls ich da etwas für dich testen kann (halb kaputten o2 auf Telekom FTTH Anschluss) lasse es mich gerne wissen.

Hängt das mit 

zusammen?

Dein Trippy Ergebnis wird mir allerdings hier nicht angezeigt, kannst du es ggf. erneut posten?

Ach ja, wenn man sucht, findet man sicherlich noch mehr kuriositäten bei o2 :)

Entschuldigt, aber der Bilder Upload hatte geklemmt, hier der Trippy-Trace
 

Danke

Zum Traceroute, ich würde mal aus der Glaskugel behaupten, der ECN Wert wird an der Übergabe zu Telefonica verändert. Wenn man ein bisschen in den DNS Records der Präfixe von Telefonica schaut, ergibt es sagen wir mal einen gewissen logischen Aufbau. Das (also dass der hier nicht antwortende Hop ein Telefonica Hop ist) sollte man aber auch mit einem Traceroute in der anderen Richtung als jetzt im Testergebnis verifizieren können.

Hängt das mit 

P

• Probleme mit unerwarteten ECT(1) ECN-Werten

zusammen?

Nur bedingt, ja es geht auch hier um unerwartete ECN Bits, aber inzwischen kann ich besser lokalisieren wo etwas daneben geht ;)
Hier jetzt vermute ich bleicht entweder O2 oder WobCom inkonsistent, je nach gewaehltem Pfad due ECN Bits, und ich vermute das ist keine Absicht, sondern bisher einfach nicht aufgefallen.

Verstehe, danke für die Ausführung.

Ich hatte tatsächlich in letzter Zeit auch nach diesem Phänomen geschaut, konnte aber in einem zugegeben relativ kurzem Testzeitraum (und nur IPv4, was aber nicht wirklich viel Traffic ausmacht im Dual Stack Netz, da IPv6 vorrang hat) nur Pakete im TCPDump Filter auffangen in Senderichtung, was ich dann auf ein konkretes Netzelement bei mir verorten konnte (naja, es bleibt eine Vermutung, aber das macht am meisten Sinn, dieses Netzelement hat eine durchaus veraltete Software, die ggf. die neueren RFC zu den ECN Werten eben nicht berücksichtigt).

Ansonsten sah es “hier” erstmal sauber aus, aber wie gesagt, der Test an sich war so oder so nicht gut genug für ein echtes Urteil. Das war halt das übliche “nach Probleme suchen”, dafür bin ich aber bei einem anderen Thema fündig geworden, mal sehen wann das adressiert wird :)

und ich vermute das ist keine Absicht, sondern bisher einfach nicht aufgefallen.

Das sehe ich auch so. Das lässt sich auch auf anderen Fällen übertragen.

Zum Traceroute, ich würde mal aus der Glaskugel behaupten, der ECN Wert wird an der Übergabe zu Telefonica verändert

Genau so sieht es aus, entweder macht das der letzte Router von AS9136 oder der erste von AS6805. Ich dachte ich frage mal hier, weil die Moderatoren hier, aus nachvollziehbaren Gruenden, zwar selten reinschauen, aber in der Vergangenheit gezeigt haben, dass sie auch vertrackte Probleme nicht scheuen

Achso gemeint war, meine Behauptung ist der erste Router von AS6805. Das ist natürlich Beleglos, nur eine Vermutung/Behauptung aus der Glaskugel (mit etwas Hilfe der DNS PTR Records) eben

Jedenfalls mal wieder ein spannendes Thema und Fund, mal sehen was da kommt

Gerade ein neuer Trace mit einem Hop 10:
 

7    AS207592 et-0-0-0-0.cr-fesch1.as207592.net (195.12.38.67)                                                  58.5%    253     105     46.3    47.5    29.6    67.3    8.4      🔵      0x2d    ECT0   │
│8    AS9136 ifp-0-0-2-0.trma2021.as9136.net (62.176.224.40)                                                     76.7%    253     59      40.3    49.0    35.6    78.6    9.5      🔵      0x2d    ECT0   │
│9    AS9136 et-0-0-3-0.cbrc1101.as9136.net (62.176.251.15)                                                      39.9%    253     152     60.3    54.4    36.0    68.2    8.4      🔵      0x2d    ECT0   │
│10   telefonica.bcix.de (193.178.185.101)                                                                       64.8%    253     89      47.6    57.6    40.8    107.8   9.5      🔵      CS5     NotECT │
│11   AS6805 lag25.0002.cord.02.ber.de.net.telefonica.de (62.53.11.114) [mpls(label=16640, ttl=1, exp=0, bos=1)] 90.5%    253     24      48.3    48.1    41.1    62.2    4.7      🔵      CS5     NotECT │
│12   AS6805 lag10-0.0001.corx.05.ber.de.net.telefonica.de (62.53.15.250) [mpls(label=16640, ttl=1, exp=0, bos=1 77.9%    253     56      52.2    50.2    40.3    79.7    7.9      🔵      CS5     NotECT │
│13   AS6805 

Der xu bestaetigen scheint, dass es an der Uebergabe zu passieren scheint, auch wenn das immer noch nicht klar macht wer verantwortlich ist (wenn der TTL exceeded Test bei Hop 9 gemacht wird bevor die Egress-Filter gelaufen sind, dann wuerde man genau dieses Muster erwarten, oder aber wen auf O2s Seite die Ingress Filter vor dem TTL Test laufen, und ich weiss nicht genau wo es da hakt). Ich werde aber WobCom auch informieren, vielleicht ist das ja deren Werk...

So gerade noch mal gemessen, es handelt sich wohl um generelles Bleaching/Bleichen:

Update: das Telefonica-NOC hat auf meine parallele Email reagiert, und will sich die Sache mal ansehen (weil das so nicht beabsichtigt waere).  Mit ein bisschen Glueck ist bald klar ob das Problem von O2 oder vom AS9136 her kommt.

(Positiv) überraschend dass es da eine Reaktion gibt. Hoffentlich werden sich auch alle potenziel betroffenen Übergaben angesehen und nicht nur die eine im BCIX (zumindest den Traceroutes zu entnehmen)…

Aber im Zweifelsfall ließe sich das ggf. auch testen, denke ich jedenfalls.

Berichte gerne wie es weiter geht :)

Edit: Ggf. ist das “bleaching” der Grund, weshalb meine letzten Tests keine ECT(1) Pakete (eingehend) aufgefangen hatte, da ja scheinbar alles zu NotECT konvertiert wird. Das ist dann aber relativ neu (<1 Jahr), ich hatte in der Vergangenheit durchaus solche Pakete empfangen (wobei ich mich hier völlig auf dem TCPdump Filter verlasse, in der Hoffnung dass dieser korrekt ist)