Das Routing-Problem zwischen Osteuropa und Asien ist gelöst. Irgendwo beim oder in der Nähe vom Upstream in Osteuropa gab es wohl Probleme. Ich konnte mein als temporary workaround konfiguriertes 5 faches AS-Path prepend wieder aus meiner Border-routerconfig herausnehmen, jetzt wo meine Verbindungen Richtung Asien wieder über Osteuropa läuft sind sie etwa 30-50 ms schneller. Das Problem erinnert mich an 2003 als ich den Provider einer sehr großen Computerzeitschrift als Upstream nutzte und eigentlich dachte die müssen es ja am besten wissen was gut ist. Das war ein Zebra-Router nahe Hauptbahnhof in Frankfurt (landet am Bahnhof das deutsche Bahn netz mannesmann/arcor – heute vodafone - seine Fiber an?) damals der den Peering-Traffic per Tunneln über ein drahtloses Drittnetz weiterreichte (ich wollte keinerlei Telekom-drähte oder Fasern auf diesem Weg involviert wissen) und mit dem anderen Border-Router auf Zebra-Basis in einem andern Rechen-zentrum in der Frankfurter Innenstadt seine BGP-Routen-Updates und Traffic austauschte. Dieser Tier1-Upstream-Provider (der das andere große Netz in Deutschland als Infrastruktur nutzt, das der Deutschen Telekom) gehört zu den Top5 weltweit und verfügt in den USA über eigene Infrastruktur. Und als dieses Peering ausfiel hakte es ganz plötzlich wenn man über das andere Peering Pakete in die USA sendete, soweit ich erinnere irgendwo bei Colocrossing/Buffalo oder so die in Nordamerika was unsren Traffic anging einen hohen Anteile erzielt haben als Knoten damals. Was war geschehen? Nun, von dort aus wurde Traffic über Infrastruktur des Tier1 Provider geschickt (niedriger dreistellige ASN) der in Europa/Frankfurt ausgefallen dem wir unsere Routen announcten.
---
-------- Nachricht --------
Betreff: Re: [Ticket #787001] Cannot reach anything within
193.109.132.0/23 AS21158 using your looking glass
Datum: Mon, 29 Jun 2020 22:49:42 +0300
Von: *** L2 technical <***@***.***>
Antwort an: *** L2 technical <l2tech@***.***>
An: Maximilian Baehring <maximilian.baehring@googlemail.com>
***.*** <https://***.*** >
Ticket #787001
Cannot reach anything within 193.109.132.0/23 AS21158 using your looking
glass
I'm sorry but I can't find a question in these piles of text.
If this is regarding /24 - currently we are installing new router
(already received one).
When it will be in production (this week or early next week) we will
stop filtering /24 networks and everything will be fine.
*** ***
Review the ticket
< https://***.***/*** >
[...]
---
Die hatten nun im globalen Routing wohl einen Filter drinne der Traffic an uns und zurück nur über deren direktes Peering in Frankfurt ausleitete. Und sobald der Traffic den wir dem andere Provider sendeten in den US in dern Netz gelangte versuchten die den über das ausgefallene Peering zurückzusenden anstatt über das zwote mit dem zwoten Upstream. In deren IBGP/IGP könnte irgendwo unsere /23 Route vorhanden gewesen sein, vielleicht weil das Peering in Frankfurt EBGP-Multihop war. Statt aber diese route mit extrem niedriger Priorität (geringer als das was nachher per BGP in die Routingtabelle kommt) nur für den EBGP-Next-hop zu setzen könnte die dann per IGP/IBGP bis in die USA weiterverteilt worden sein was hätte verhindert werden müssen. Reine Spekulation aber das ist ein mögliches Szenario. Die route zum EBGP next-hop muß immer statisch sein genau wie man am besten eine /32 Host-Route zu jeweils andern der beiden EBGP-Speaker setzt auf den Hops dazwischen. Es könnte auch an einem prefix- oder as-path-filter gelegen haben. Das mochte ich an dem andern global operierenden TIER1 Provider im oberen dreistelligen AS-Bereich so gerne mit dem ich mal peerte daß der für Europa und USA eigene AS-Nummern verwendete aber die waren dann zu dämlich ordentlich mehrere Leitungen zu loadbalancen was dazu führte daß von zwo E1 die eine E1 zu denen 2/3 und die ander 1/3 Traffic bekam. Sowas passierte da nicht. Jedenfalls: Irgend so ein Problem wird auch das aktuell gerade gelöste Problem zwischen Asien und Osteuropa gewesen sein denn nutzte man andere IP-Adressen stad der Pfad so rein hard-waretechnisch/physikalisch, das war ein reines Routingproblem. AS-Pfad Filter darf man an den AS-Pfad Endpunkten eines Netzes setzen aber niemals in Netzen die andere ASe durchleiten.
Routen Filtern kann man was eingehenden Traffic angeht sehr gut aber wo der Traffic rausgeht kann man kaum (nur über den Umweg von do-not-announce-to BGP-Communities und auch nur dann wenn ein Upstream das unterstützt/dokumentiert) steuern. Ich announce mein/e Netz/e immer nicht nur meinem Upstream sondern auch zeitglich all den Netzen mit denen er verbunden ist. Ich muß also das Netz eines Providers durch den hindurch mein Traffic geleite wird nicht selber sehen und erreichen können es genügt vollauf wenn ich selbst eine Route zum Zielnetz habe (und sei es eine Fallback-Default Route) und meinen nächsten Hop dorthin sehe. Das Zielnetz wiederum muß mein Netz sehen und seinen nächsten Hop, der Rest ist das Problem Dritter. Jeder Upstream von mir reicht meine Route/n – um sein vorangestellten AS-Pfad erweitert – weiter durch (Ausnahme: ich weise per BGP Community setzen einen Upstream der das implementiert hat an das nicht zu tun) da brauch ich mich nicht drumm zu kümmern. Nicht ich kontrolliere ob das Ziele oder ein Hop dazwischen meine route sieht sondern der jeweils nächste Hop beim um seinen AS-Pfad ergänzten Durchreichen meiner Route/n. Beweis: siehe neuerdings häufiger in traceroutes sichtbare Transfernetze aus dem Privaten Adress-Bereich 10.0.0.0/8, 172.16.0.0/12 192.168.0.0./16 zwischen öffntlichen IP-Adressen (die bei lokaler RFC1918 Reverse-Namensauflösung DNS-namen bekommen könne die im lokalen Netz vergeben sind, daher wird der cimp of weggfiltert, man isht dann Sternchen) wegen knapp werdender IPv4-Adressen, besonders in den USA: Ich muß immer nur meinen eignen nächsten Hop und das Ziel sehen, nicht zwingend jeden einzelnen Router dazwischen.
[0] "202007051000-0-1.jpg"
[1] "202007051000-0-2.jpg"
[2] "202007051000-0-3.jpg"
[3] "202007051000-0-4.jpg"
