[Sammelthread] Peering verschiedener ISP's, Diskussion

[Holzkopf]

wird einfach vergessen.

Wird wohl auch am mangelten Wissen liegen.

 

[kingpin42]

Ich war halt extrem positiv überrascht wie unproblematisch und schnell digital ocean das Problem lösen konnte. Das wäre praktisch unmöglich gewesen, wenn mein ISP die Telekom gewesen wäre. Da hätte man mir wahrscheinlich mitgeteilt dass es keine andere Route gebe dir man hätte nehmen können.

Da wärst du gar nicht zu den richtigen Ansprechpartnern durch gekommen Das ist auch gewollt so, ich würde auch nicht gerne ständig von Privatkunden kontaktiert werden. Hier ist das für mich was Anderes, das mache ich freiwillig in der Freizeit, kann mir aber vorstellen, das nicht alle Kollegen Lust auf sowas haben.

Aber bei Vodafone? Einfach auf AS1273 ausweichen und gut ist. Das muss man Vodafone einfach Mal hoch anrechnen wie gut deren peering einfach ist und das Dienste hier Optionen haben statt gegängelt zu werden.

Könnte die Telekom ja auch, wenn Sie ihre Endkunden nicht im AS3320 führen würden...dann hätten Sie einen noch größeren T1 als Vodafone in der Hinterhand. Dienste haben auch bei der Telekom Optionen, nur sind die oft träger und du bekommst als Außenstehender nix davon mit.

 

[floh667]

Da wärst du gar nicht zu den richtigen Ansprechpartnern durch gekommen

Ich hatte ja digital ocean kontaktiert, nicht vodafone. Es war Digital ocean was sein routing zu vodafone deutschland geändert hat. Das wäre digital ocean aber ganz sicher nicht möglich gewesen, wäre mein ISP die Telekom gewesen.

Könnte die Telekom ja auch, wenn Sie ihre Endkunden nicht im AS3320 führen würden

Welches große AS hat die Telekom denn noch in der Hinterhand wo sie ihre Kunden durchleiten könnte? Und wieso haben Dienste hier genauso die Optionen? Die telekom will viel Geld dafür, dass Dienste sich mit ihr verbinden, die sind doch gar nicht wirklich potent mit großen transits wie NTT, HE oder twelve99 verbunden.

Was ich mit meiner Aussage meinte war, dass digital ocean sich ganz einfach mit Vodafone über deren global net AS1273 verbunden hat und dort einfach einen der transit carrier nimmt (derzeit NTT) und die Sache gegessen war.

 

[Rapidie]

Wird wohl auch am mangelten Wissen liegen.

Mit Sicherheit. Aber wie heißt es so schön, wenn man keine Ahnung hat einfach mal die ..

Sorry wenn das etwas geflame ist, da schwingt sicherlich der generelle Frust gegen 3320 mit . Das Thema ist an sich schon nervig genug, dann zu lesen wie die "Telekom-Jünger" ahnungslos Unfug verteidigen tut dann doppelt weh .

Könnte die Telekom ja auch, wenn Sie ihre Endkunden nicht im AS3320 führen würden...dann hätten Sie einen noch größeren T1 als Vodafone in der Hinterhand.

Wo soll man denn da 60 Cent bei 100G Commit rauspressen?

Yokes aside: Das 3320 Backbone ist für sich genommen gar nicht schlecht. Ich habe es schon mal hier im Thread erwähnt: Wenn sie offen Peeren würden (mit Trennung in zwei AS - 3320 Global Carriers und eins für .DE only) und Ihren Transit günstiger verkaufen, wäre es durchaus als legitimer Transitprovider im Mix interessant. Gesamtwirtschaftlich würde es für Sie vermutlich sogar zum positiven wenden.


Aber das sehen die Aktionäre wohl anders.

 

[kingpin42]

Ich hatte ja digital ocean kontaktiert, nicht vodafone. Es war Digital ocean was sein routing zu vodafone deutschland geändert hat. Das wäre digital ocean aber ganz sicher nicht möglich gewesen, wäre mein ISP die Telekom gewesen.

Ja, ich bezog mich ja auch auf die DTAG.

Welches große AS hat die Telekom denn noch in der Hinterhand wo sie ihre Kunden durchleiten könnte? Und wieso haben Dienste hier genauso die Optionen? Die telekom will viel Geld dafür, dass Dienste sich mit ihr verbinden, die sind doch gar nicht wirklich potent mit großen transits wie NTT, HE oder twelve99 verbunden.

Die haben wohl ein paar AS-Nummern gebunkert, in eines davon ließen sich sicherlich die PK stecken, wie es AS3209 auch macht. Und doch, AS3320 ist potent mit anderen großen T1 (nicht Transits, die DTAG bezieht keinen Transit als T1) verbunden, nur eben (manchmal) nicht potent genug. HE ist übrigens kein T1.

Was ich mit meiner Aussage meinte war, dass digital ocean sich ganz einfach mit Vodafone über deren global net AS1273 verbunden hat und dort einfach einen der transit carrier nimmt (derzeit NTT) und die Sache gegessen war.

Die werden ihre Routen anders announced oder mit Communities versehen haben, sodass die Pakete einen anderen Weg zu 3209 nehmen, ja. Sowas kann man sehr schnell umsetzen.

 

[Rapidie]

Die werden ihre Routen anders announced oder mit Communities versehen haben, sodass die Pakete einen anderen Weg zu 3209 nehmen, ja. Sowas kann man sehr schnell umsetzen.

Andere Richtung: Announcements und Communites manipulieren die Gegenseite. Wenn DO Communites tagged, importiert die Telekom die Routen nach DO anders.


Was in dem Fall manipuliert wurde, ist vermutlich die interne Local-Pref (oder Metrik) seitens DO.

 

[Holzkopf]

Frag mich warum DO weiterhin ihre Transits nutzt und nicht über den DECIX das abwickelt mit 3209

 

[Rapidie]

Der DECIX hat sich preislich mittlerweile von ihren ehemaligen Vorteilen entfernt. Zumindest wenn man nach Liste geht.

PNI oder Transit, DECIX ist big Layer2 Foo.

Laut https://www.peeringdb.com/net/6494 haben sie 2x100G, kann tatsächlich sein dass Transit günstiger ist als Port-Expansion.

 

[floh667]

[IMG]https://www.computerbase.de/forum/attachments/1666188801529-png.1272371/[/IMG]
Die haben wohl ein paar AS-Nummern gebunkert, in eines davon ließen sich sicherlich die PK stecken, wie es AS3209 auch macht. Und doch, AS3320 ist potent mit anderen großen T1 (nicht Transits, die DTAG bezieht keinen Transit als T1) verbunden, nur eben (manchmal) nicht potent genug. HE ist übrigens kein T1.

Danke, wusste nicht das HE gar kein T1 ist.
Aber was die telekom angeht, so ists halt weiterhin einfach so, dass sie über transit kaum erreichbar ist und sie wollen, das sich jeder mit ihnen per PNI kurzschließt. Da ist es völlig egal, wie "groß" 3320 ist.
Darum meinte ich ja, dass es für digital ocean ein leichtes war, die route zu Vodafone zu verändern, da Vodafone vielfach erreichbar ist. Sei es mit PNI, öffentlichen Knoten wie dem decix (wenn auch hier vodafone selektiv agiert, weswegen längst nicht alle darüber gehen) oder ganz lapidar mittel transit über AS1273 was für die meisten Dienste wohl am einfachsten und günstigsten ist.
Und dadurch, dass vodafone so vielfach erreichbar ist, hab ich auch noch nie erlebt, dass mal eine Verbindung über transit vollgelaufen wäre. Nur einmal gabs oder gibts teilweise noch probleme mit einzelnen Verbindungen nach Österreich, wenns über den 10g link am VIX geht. Da wurden schon Engpässe von Nutzern gezeigt.

Frag mich warum DO weiterhin ihre Transits nutzt und nicht über den DECIX das abwickelt mit 3209

ich hab nicht schlecht gestaunt als ich kürzlich sah, dass die content server von Valve(steam) ihren traffic bei vodafone über den decix rein zu kippen scheinen. Normal macht man sowas doch bevorzugt über PNIs und stopft damit nicht die links an exchanges zu?

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                   No response from host -  100 |    1 |    0 |    0 |    0 |    0 |    0 |
|ip-081-210-144-156.um21.pools.vodafone-ip.de -0 |    5 |    5 |    6 |    6 |    7 |    7 |
|         de-fra04d-rc1-ae-48-0.aorta.net -    0 |    5 |    5 |   10 |   13 |   17 |   10 |
|                           84.116.190.94 -    0 |    5 |    5 |    9 |   12 |   16 |   10 |
|                   de-cix2ipv4.valve.net -    0 |    5 |    5 |    9 |   11 |   16 |   10 |
|                   No response from host -  100 |    1 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |    1 |    0 |    0 |    0 |    0 |    0 |
|                          155.133.226.18 -    0 |    5 |    5 |    9 |   12 |   16 |   10 |
|________________________________________________|______|______|______|______|______|______|

 

[roket]

geg. war die route über das decix günstiger als über level3 (größter partner meines wissens von steam diensten)

 

[mici01]

ich hab nicht schlecht gestaunt als ich kürzlich sah, dass die content server von Valve(steam) ihren traffic bei vodafone über den decix rein zu kippen scheinen. Normal macht man sowas doch bevorzugt über PNIs und stopft damit nicht die links an exchanges zu?

Macht o2 auch so 😉

Start: 2022-10-19T22:31:37+0200
HOST: [host].fritz.box                                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    fritz.box (10.0.0.1)                                                 0.0%    10    3.9   4.4   3.4  10.3   2.1
  2. AS6805   loopback1.0001.acln.06.ham.de.net.telefonica.de (62.52.201.198)      0.0%    10   11.7  16.2  11.7  37.2   9.1
  3. AS6805   bundle-ether8.0002.dbrx.06.ham.de.net.telefonica.de (62.53.1.234)    0.0%    10   13.0  13.8  12.2  17.0   1.6
  4. AS6805   ae7-0.0002.corx.01.ham.de.net.telefonica.de (62.53.14.66)            0.0%    10   19.9  19.5  18.8  20.7   0.5
  5. AS6805   ae6-0.0001.corx.01.off.de.net.telefonica.de (62.53.0.35)             0.0%    10   21.5  20.0  18.7  23.9   1.6
  6. AS6805   bundle-ether1.0002.dbrx.01.off.de.net.telefonica.de (62.53.28.155)   0.0%    10   19.6  20.7  18.8  26.3   2.4
  7. AS6805   bundle-ether2.0002.prrx.01.off.de.net.telefonica.de (62.53.28.179)   0.0%    10   19.8  22.7  18.1  36.9   6.9
  8. AS???    de-cix2ipv4.valve.net (80.81.193.63)                                 0.0%    10   18.8  19.1  18.5  19.6   0.4
  9. AS???    ???                                                                 100.0    10    0.0   0.0   0.0   0.0   0.0
 10. AS???    ???                                                                 100.0    10    0.0   0.0   0.0   0.0   0.0
 11. AS32590  155.133.226.18                                                       0.0%    10   19.7  21.3  19.2  34.1   4.6

Scheint also durchaus von Valve so gewollt zu sein, sonst würden sie die IPs nicht am DE-CIX advertisen

 

[kingpin42]

Andere Richtung: Announcements und Communites manipulieren die Gegenseite. Wenn DO Communites tagged, importiert die Telekom die Routen nach DO anders.


Was in dem Fall manipuliert wurde, ist vermutlich die interne Local-Pref (oder Metrik) seitens DO.

Du kannst ja mit Communities auch intern alles setzen, auch local pref. Metrik ist meist Cisco proprietär. Theoretisch gibts aber natürlich noch mehr Möglichkeiten des Outbound steerings. Ich könnte mir aber auch vorstellen, das DO intern bereits SR einsetzen.

Ergänzung (19. Oktober 2022)

ich hab nicht schlecht gestaunt als ich kürzlich sah, dass die content server von Valve(steam) ihren traffic bei vodafone über den decix rein zu kippen scheinen. Normal macht man sowas doch bevorzugt über PNIs und stopft damit nicht die links an exchanges zu?

Man hat normalerweise zu PNIs immer Backupsessions über IXPs (sofern man an IXPs peert).

 

[Rapidie]

Du kannst ja mit Communities auch intern alles setzen, auch local pref.

Stimmt natürlich, aber so ganz verstehe ich den Sinn dahinter nicht. Initial müsste am Edge eine informational Community getagged werden, die im weiteren eigenen netzinternen Verlauf im Importfilter für Actions (wie z.B. niedrige oder hohe local pref) verwendet werden kann.

Warum dann nicht gleich anhand vom AS-Paths entscheiden? Oder direkt in der Policy vom Peer?

Habe Communites für die Steuerung des eigenen outbound Traffics so noch nicht gesehen. Nur im Zusammenhang mit Kunden Sessions.

Vllt. kannst du an einem konkreten Szenario festmachen, wo das sinnvoll wäre?

Metrik ist meist Cisco proprietär.

Eigentlich können das alle gängigen Implementationen von Arista, Juniper, Huawei usw.

 

[kingpin42]

Stimmt natürlich, aber so ganz verstehe ich den Sinn dahinter nicht. Initial müsste am Edge eine informational Community getagged werden, die im weiteren eigenen netzinternen Verlauf im Importfilter für Actions (wie z.B. niedrige oder hohe local pref) verwendet werden kann.

Wir nutzen das für Downstreamcustomer die über mehrere Links zu uns verfügen. Die können dann bei uns localpref setzen.
Die Informationals werden ja hoffentlich überall gesetzt, zumindest sollte man das in seinem eigenen Netz tun, nicht nur für daraus abgeleitete Actions, auch um den eingehenden Datenfluss besser differenzieren zu können.

Warum dann nicht gleich anhand vom AS-Paths entscheiden? Oder direkt in der Policy vom Peer?

Das sollt eigentlich immer gemacht werden, außer bei Downstream/Customer AS, da machts ja schon Sinn die localpref zu ändern. Ich höre schon Gert Döring im Hintergrund predigen 😅

Eigentlich können das alle gängigen Implementationen von Arista, Juniper, Huawei usw.

Also von Juniper weiß ich nichts, welcher Command ists denn da ? Die Metric wird ja nicht über Update Messages von BGP gesendet.

 

[Rapidie]

Wir nutzen das für Downstreamcustomer die über mehrere Links zu uns verfügen. Die können dann bei uns localpref setzen.

Ok, in dem Setup machts natürlich durchaus sinn In dem Fall oben gings ja explizit nicht um Customer Traffic, daher meine Annahme, dass da eher weniger Communites im Spiel sein dürften.

Die Metric wird ja nicht über Update Messages von BGP gesendet.

Doch, tatsächlich schon. Einige Peers schicken das für "unbequeme" (3320, 12956..) Pfade mit, als höfliche Bitte es nicht zu verwenden.

Also von Juniper weiß ich nichts, welcher Command ists denn da ?

Auf Runlevel ganz normal via show route

139.7.0.0/16 (9 entries, 1 announced)
BGP Preference: 170/-111
Peer AS: 1299
[...]
Metric: 2050

Configlevel lässt sich im Importfilter die Metrik, die mitgeschickt wird, überschreiben.

then {
metric 0;
local-preference 100;
[...]
accept;
}

Vllt. fehlte dir bei Juniper always-compare-med? Andernfalls wird nur bei gleichem neighbor verglichen.

set protocols bgp path-selection ?
Possible completions:
always-compare-med Always compare MED values, regardless of neighbor AS

 

[kingpin42]

Ok, in dem Setup machts natürlich durchaus sinn In dem Fall oben gings ja explizit nicht um Customer Traffic, daher meine Annahme, dass da eher weniger Communites im Spiel sein dürften.

-Könnte- man auch intern machen, da seh ich aber noch nicht so den Sinn dahinter, evtl. wenn intern noch mehrere Pfade mit privaten AS-Nummern vorhanden sind und an das Main-AS angeflanscht werden.

Doch, tatsächlich schon. Einige Peers schicken das für "unbequeme" (3320, 12956..) Pfade mit, als höfliche Bitte es nicht zu verwenden.
Auf Runlevel ganz normal via show route
Configlevel lässt sich im Importfilter die Metrik, die mitgeschickt wird, überschreiben.
Vllt. fehlte dir bei Juniper always-compare-med? Andernfalls wird nur bei gleichem neighbor verglichen.

Ah moment, der MED war nicht gemeint mit Metrik (auch wenn das eigentlich korrekt ist)
Meinte da eher die lokale Metrik bzw. "Weight" in Cisco-Sprech.

 

[Wechsler]

Absolut absurd wird’s, wenn der Telekom Techniker/Support einem den VPN empfiehlt. Statt den Mist vor der eigenen Haustür zu kehren, bitte doch mal Traffic via Paid-Port abwerfen - danke

Bei mir gibt es Festnetz auf zwei Wegen (beide Kupfer) nur von der Telekom. Also habe ich gar kein Festnetz mehr. Ist einfach überteuerter Schrott.

aber wenn sowas als ernsthafter Vorschlag von der Kundenrückgewinnung kommt.

🤣 Siehe https://zonenblog.blogspot.com/2010/10/spa-mit-der-telekom-oder-die-drei-mit.html

Spoiler

Gerüchteweise ist die ganze Sendung gestorben, weil die frisch privatisierte Telekom Druck auf RTL gemacht hat.

 

[Holzkopf]

AS3209 Vodafone hat nun übrigens eine direkt Verbindung zu Twelve99 (ex Telia), über AS1273 wird aber noch bevorzugt.
Die Verbindung befindet sich bisher nur in Frankfurt.

 

[whispet]

Hi Zusammen,
gibt es eigentlich seitens der Telekom hier ein Update? Peering-Probleme behoben, oder ist das immer noch ein Graus mit denen?

 

[DLMttH]

Es ist Firmenpolitik, die wird sich so schnell nicht ändern...

Gibt's denn konkreten Anlass, dort Kunde sein zu wollen? Seit der letzen Preissteigerung sind die Tarife ja so uninteressant wie nie...