Hi mainziman,
wie schon angemerkt sind die v4 und v6 routen deutlich anders, da du dafür ja ein Interesse hast versuch ich das mal aufzubereiten, ich kann gerade eh nicht schlafen.
die v4 ip liegt in 200.7.7.0/24, diese route lernen wir über 3 Pfade:
mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 200.7.7.3 table inet.0 | match path
AS path: 262589 14259 27678 I, validation-state: valid
AS path: 262589 14259 27678 I, validation-state: valid
AS path: 3320 6762 14259 27678 I, validation-state: valid
AS262589 = Internexa ist hierbei der kürzeste pfad, wir lernen diese über den DE-CIX Frankfurt Route Server.
Konkret also Internexa -> GTD -> NIC.cl
die v6 IP liegt in 2001:1398:5::/48, diese route lernen wir über 9 Pfade:
mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 2001:1398:5::6003 table inet6.0 | match path
AS path: 1299 174 18747 27678 I, validation-state: unverified
AS path: 2914 174 18747 27678 I, validation-state: unverified
AS path: 1299 174 18747 27678 I, validation-state: unverified
AS path: 1299 174 18747 27678 I, validation-state: unverified
AS path: 1299 174 18747 27678 I, validation-state: unverified
AS path: 2914 174 18747 27678 I, validation-state: unverified
AS path: 3320 5511 52468 18747 27678 I, validation-state: valid
AS path: 6939 262589 14259 27678 27678 27678 I, validation-state: valid
AS path: 6939 262589 14259 27678 27678 27678 I, validation-state: valid
Wir nehmen hier Telia.
Was dabei auffällt ist, dass wir diese route nicht von AS262589 über den DE-CIX Routeserver lernen, AS262589 taucht nur hinter Hurricane Electric AS6939 auf.
Ein kurzer blick ins DE-CIX LookingGlass verrät auch warum: https://lg.de-cix.net/routeser…v6?s=asn&o=asc&q=AS262589
Die IPv6 Session ist seit einem Jahr down. Warum weiß nur Internexa selbst.
Unabhängig davon fällt auch auf, dass AS27678(nic.cl) hier 3 mal am ende vorkommt, also prependet ist. Warum das so ist, weiß nur nic.cl. AS-Path prepending verwendet man um das routing zu beeinflussen, BGP nimmt meist den kürzesten Pfad, man könnte das also als versuch der nic.cl werten diesen Pfad schlechter zu machen.
Das ist also die Erklärung warum unterschiedliche Pfade für v4 und v6 verwendet werden.
Schauen wir uns mal den v4 Pfad an:
dcr02.anx84.nue.de (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. ae3-4019.bbr02.anx84.nue.de.anexia-it.net 0.0% 421 4.7 5.0 0.4 98.5 12.0
2. ae0-0.bbr01.anx84.nue.de.anexia-it.net 0.0% 420 6.0 8.4 3.7 113.6 15.4
3. ae2-0.bbr02.anx25.fra.de.anexia-it.net 0.0% 420 3.8 11.7 3.5 139.8 19.9
4. de-cix.fra.internexa.com 83.1% 420 113.4 119.0 113.2 181.2 14.3
5. 190.211.167.5 0.0% 420 242.8 250.1 242.5 315.4 15.7
6. 190.211.167.6 0.0% 420 263.5 270.6 263.1 350.3 17.1
7. ciscoc1e.nic.cl 0.0% 420 241.7 245.7 241.0 306.5 12.2
8. ciscoa1i.nic.cl 0.0% 420 243.9 247.6 242.9 315.2 12.5
9. www.nic.cl 0.0% 420 254.9 245.8 241.5 315.8 12.0
Alles anzeigen
Auffällig ist, dass zwischen Hop 4 und 5 ca. 110ms liegen, Internexa Peert also relativ sicher nicht in Frankfurt sondern kommt über ein Remote Peering rein.
Kurzer blick auf das DE-CIX LG bestätigt auch das, Internexas router steht irgendwo in New York (https://lg.de-cix.net/routeser…/protocols/R194_15/routes -> klick auf eine route und blick auf die communities). Da diese ganze DE-CIX remote peering Geschichte reines Layer2 ist sehen wir leider nichts vom tatsächlichen Pfad, das Paket kommt in Frankfurt rein und landet irgendwann in NYC.
Danach kann man eigentlich nur noch Hops Raten, das sind ca. 8500km Luftlinie, also vmtl. das 1.5-fache an Faserweg, was mit ca. 130ms auch ganz gut hinkommt (Faustformel: 100km = 1ms RTT). Die geringe Anzahl an Hops könnte darauf hinweisen, dass internexa hier Seerouten nimmt, und nicht über den Landweg nach Chile kommt.
Der v6 Pfad sieht so aus:
dcr02.anx84.nue.de (::)(tos=0x0 psize=64 bitpattern=0x00) Fri May 28 20:22:51 2021
Host Loss% Snt Last Avg Best Wrst StDev
1. 2a03:4000:ff00:1:: 0.0% 68 3.5 6.7 0.4 68.9 14.7
2. 2a00:11c0:47:3::20 0.0% 68 0.6 13.0 0.5 83.0 16.6
3. 2a00:11c0:47:1:47::138 0.0% 68 2.2 5.0 0.5 61.1 10.9
4. 2a00:11c0:47:1:47::136 0.0% 68 8.9 13.5 8.8 129.0 16.8
5. win-b2-link.ip.twelve99.net 79.1% 68 9.5 10.6 9.2 14.0 1.9
6. be1300.ccr51.vie01.atlas.cogentco.com 65.7% 68 9.4 15.8 9.3 91.6 19.5
7. be2974.ccr21.muc03.atlas.cogentco.com 70.6% 68 14.6 22.8 12.4 129.3 30.0
8. be2959.ccr41.fra03.atlas.cogentco.com 94.0% 68 14.1 15.0 13.0 19.7 3.2
9. be2799.ccr41.par01.atlas.cogentco.com 86.6% 68 22.2 46.1 22.1 88.3 28.4
10. be2315.ccr31.bio02.atlas.cogentco.com 76.1% 68 41.0 40.9 38.1 62.3 6.7
11. be2331.ccr41.dca01.atlas.cogentco.com 83.6% 68 153.8 112.3 102.8 153.8 16.1
12. be2112.ccr41.atl01.atlas.cogentco.com 86.6% 68 116.5 120.1 116.5 129.0 4.6
13. be3482.ccr21.mia01.atlas.cogentco.com 78.5% 66 131.2 132.0 131.1 135.6 1.2
14. be2025.ccr22.mia03.atlas.cogentco.com 80.6% 63 131.6 134.5 131.1 167.7 10.5
15. 2001:550:2:19::2c:2 0.0% 63 126.9 133.1 126.7 187.8 15.7
16. 2802:2:4fff:ffff:ffff:ffff:ffff:ff1a 0.0% 61 236.4 242.5 236.4 292.0 13.5
17. 2803:fd80:f:1::230 0.0% 61 232.4 236.7 232.4 293.8 10.2
18. 2803:fd80:2:6::3 0.0% 60 238.8 238.9 232.7 292.8 14.1
19. ciscom1i.intra.nic.cl 0.0% 60 254.7 260.2 254.5 316.1 13.7
20. ciscoa1i.intra.nic.cl 0.0% 59 232.7 236.7 232.3 297.7 11.8
21. www.nic.cl 0.0% 59 258.8 264.4 258.4 323.8 15.1
Alles anzeigen
Wir geben es also von Nürnberg nach Wien, dort an Telia, die geben es in wien an cogent und von dort geht es
VIENNA -> MUNICH -> FRANKFURT -> PARIS -> BINGHAMTON(also new york) -> WASHINGTON -> ATLANTA -> MIAMI
Dort wird es an IXFNETWORKS übergeben (hop 16), und die latenz steig, vmtl. geht es auch hier über ein seekabel, und landet dann auf relativ direktem wege in chile.
In Summe geben sich v4 und v6 von der Latenz auch nicht viel, ca 19ms. was sich relativ einfach erklären lässt: Wir geben das Paket von NUE nach Wien an Telia, die geben es an cogent, die wiederum bringen es über Frankfurt nach Paris.
Warum ist das so?
BGP weiß von der Entfernung natürlich nichts, sondern sieht nur den AS-Pfad, im BGP output von vorhin ist der 1. unser Telia Transit in Wien, der 3. unser Telia Transit in Frankfurt. Die AS-Pfade sind exakt gleich und am Ende vom Tag gewinnt die ältere Route (weil diese als stabiler angesehen wird), und das ist "leider" die in Wien, die grandiose 35min älter ist.
Konkret heißt das, dass wir hier noch etwas optimieren können, was wir am Montag auch tun werden, insofern Danke für den Hinweis.
Die Anzahl der Hops ist allerdings nicht wirklich ein Indiz, weil das durch die Layer2 Remote Peering Geschichte verdeckt wird.
Ich hoffe das ganze war etwas interessant, ich zumindest kann jetzt ruhig schlafen
Noch eine Bitte an alle hier: bitte nutzt mtr unter linux oder winMTR auf windows statt traceroutes. postet bitte auch keine screenshots sondern kopiert den output in ein code feld, sonst müssen wir beim debuggen alles von hand abtippen.