Hallo,
ich habe heute erfahren, dass es in unsrer Domäne seit ein paar Tagen ein Peering mit dem IC-VPN gibt.
Das IC-VPN peert auch mit DN42 und ChaosVPN.
Leider habe ich keine Verbindung aufbauen können:
https://gist.github.com/stv0g/9811f636d540dc919936
Wie ist denn dazu der aktuelle Stand? Bzw. benötigt ihr eventuell Unterstützung oder Peers in dem Bereich?
viele Grüße
Steffen
An sich sollte das schon klappen.
@Shiva kann es sein, dass deine bgp Einträge fürs icpvn nicht rebootfest waren?
Vielleicht werden auch die DN42/ChaosVPN routen gefiltert?
Warum sollten wir so etwas machen?
Ich habe mal darüber geschaut und nachdem ich festgestellt habe, dass unsere icvpn vm das Problem ist und dort die Config sehr sauber ausschaut dezent gegen getreten.
Zumindest am Beistpiel Hamburg sieht man dass es grundsätzlich funktioniert, auch wenn du hops etwas seltsam sind:
tracepath 10.112.1.2
1?: [LOCALHOST] pmtu 1406
1: aachen02.ffac 27.197ms
1: aachen02.ffac 65.220ms
2: srv02.ffhh 169.704ms pmtu 1400
2: icvpn.ffac 77.810ms
3: 10.207.0.61 72.882ms
4: srv02.ffhh 73.923ms reached
Resume: pmtu 1400 hops 4 back 4
oder auch Weimar:
tracepath 10.63.1.1
1?: [LOCALHOST] pmtu 1406
1: aachen02.ffac 20.388ms
1: aachen02.ffac 23.862ms
2: 10.63.1.1 27.584ms pmtu 1400
2: icvpn.ffac 47.310ms
3: 10.63.1.1 78.017ms reached
Resume: pmtu 1400 hops 3 back 3
Ich werde mich mit dem Thema nicht weiter beschäftigen, ich denke aber @Shiva ist weiterhin an der Sache dran.
Alternativ kannst du auch mal bei einem unserer Treffen aufschlagen, dann erledigen wir das gemeinsam und du bekommst in Absprache mit den anderen Admins Zugang zu der icvpn VM um das Thema zu betreuen.
Ich kann da leider nichts anders konfigurieren. Die Routen biegen wie man sehen kann schon korrekt via icvpn ab. Dort läuft BGP… Und wenn ich aus der BGP-Wolke keine korrekten Routen-Announcements bekomme, dann kann auch nicht korrekt weitergeroutet werden… 
Dass es prinzipiell korrekt eingerichtet ist, sieht man daran, dass wie oben gezeigt andere Ziele funktionieren.
Man möge mich allerdings hier auch gerne eine besseren belehren
EDIT: Und eine Routenverfolgung aus der anderen Richtung würde mich interessieren.
Hier mal ein Traceroute von 172.23.156.7 zu 10.63.1.1:
traceroute to 10.63.1.1 (10.63.1.1), 30 hops max, 60 byte packets
1 tux.0l.dn42 (172.23.156.1) 7.929 ms 7.917 ms 7.928 ms
2 ixp-nn.port0.nixnodes.dn42 (172.23.3.1) 48.565 ms 48.590 ms 48.586 ms
3 10.29.131.187 (10.29.131.187) 39.557 ms 39.577 ms 39.579 ms
4 * * *
Wenns aber nicht auf eurer Prio-Liste steht, könnt ihrs auch mal links liegen lassen…
So dringend ists nicht.
Nimm ruhig ein Ziel in Aachen, also z.B. 10.5.0.100
Würde mich auch interessieren wie das in aus anderen Freifunk Domänen ausschaut.
Klar kein Problem. Hier nochmal direkt nach Aachen:
traceroute to 10.5.0.100 (10.5.0.100), 30 hops max, 60 byte packets
1 tux.0l.dn42 (172.23.156.1) 7.198 ms 7.165 ms 7.104 ms
2 ixp-nn.port0.nixnodes.dn42 (172.23.3.1) 48.229 ms 48.239 ms 48.222 ms
3 gw03.ffda (10.223.0.3) 61.122 ms 61.116 ms 61.093 ms
4 * *
Wollt ihr die Routing Tabelle von icvpn.ffac mal checken? Tauchen da überhaupt DN42/ChaosVPN routen auf?
Scheint aber ja nicht hier an Aachen zu haken…
Ist die Aachener Infrastruktur eigentlich iwo dokumentiert?
viele Grüße
Aus Moehne sieht es so aus:
tracepath 10.5.0.100
1: 10.15.254.249 0.178ms pmtu 1500
1: 10.15.0.103 10.480ms
1: 10.15.0.103 9.698ms
2: 10.5.0.100 9.634ms pmtu 1445
2: 10.207.0.114 19.785ms
3: 10.5.0.100 21.482ms pmtu 1402
3: 10.5.254.1 24.239ms
4: no reply
5: no reply
traceroute to 10.5.0.100 (10.5.0.100), 30 hops max, 60 byte packets
1 10.15.0.103 (10.15.0.103) 8.171 ms 8.165 ms 8.372 ms
2 10.207.0.114 (10.207.0.114) 16.497 ms 16.703 ms 16.736 ms
3 10.5.254.1 (10.5.254.1) 20.517 ms 20.562 ms 20.668 ms
4 * * *
Edit: traceroute hinzugefügt
root@ffac0x1:~# ip route sh | grep ^172\. | wc -l
177
sieht so aus, ja…
allerdings sind dort auch die
172.22.2.0/23 via 10.207.0.142
172.22.6.0/23 via 10.207.0.142
172.22.8.0/24 via 10.207.0.219
...
die ersten Routen vom gesamten 172.16.0.0/12 Prefix - zu deinem ersten Ziel 172.22.0.53 existiert also keine unserem icvpn-GW mitgeteilte Route…
das sieht komisch aus… aber ich glaube ich weiss, wo ich mal ansetzen und nachschauen muss…
(zur Vollständigkeit: ich erreiche die 10.5.0.100 auch nicht vom icvpn.ffac direkt… was prinzipiell nicht schlimm ist, weil ich ja eigentlich hier nur Pakete von Nicht-10.5.0.0/16 Prefixen routen muss - und die laufen korrekt, wie man bspw. oben an Hamburg als Ziel erkennen kann… Trotzdem ändere ich mal am internen Transfer-Netz die IPs auf etwas nicht-mit-der-eigenen-Range-kollidierendes…)
so - die versprochene Änderung ist vollzogen @Lars kuckst du noch mal bitte? sieht’s jetzt besser aus?
trotzdem sind die Routen in die von @stv0g latürnich immer noch nicht da - aber ich habe immer noch keinen Einfluss darauf
Na klar.
tracepath 10.5.0.100
1: 10.15.254.249 0.101ms pmtu 1500
1: 10.15.0.103 11.399ms
1: 10.15.0.103 12.644ms
2: 10.5.0.100 10.564ms pmtu 1445
2: 10.207.0.114 19.480ms
3: 10.5.0.100 22.304ms pmtu 1402
3: 100.114.5.1 30.238ms
4: 10.5.0.100 36.589ms reached
Resume: pmtu 1402 hops 4 back 61
Danke - Ich glaube ich werde die Ausgabe von tracepath nie verstehen … 
traceroute und mtr sehen da anders/besser aus…?
Hab mich auch etwas gewundert aber der mtr sieht gut aus. 
HOST: moehne Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.15.0.103 0.0% 20 22.4 29.8 22.4 34.2 2.6
2.|-- 10.207.0.114 0.0% 20 46.3 38.6 32.3 46.3 2.8
3.|-- 100.114.5.1 0.0% 20 36.4 42.2 33.7 47.5 3.0
4.|-- 10.5.0.100 0.0% 20 54.1 55.4 45.1 62.7 3.6
Ich versuche hier grade das IC-VPN in Troisdorf ans laufen zu bekommen…
Ich habe zum testen mal ebenfalls die 10.5.0.100 versucht:
Ping geht nicht…
Traceroute geht über 10.207.0.114 zu 10.114.5.1. Danach ist ende
Das liegt an dem Server mit der 10.5.0.100, nimm mal die 10.5.0.1
Wo ist nochmal das Verzeichnisses all jener Services, aus solchen Netzen die beim IC-VPN Netzen mitmachen?
Es gibt ne Möglichkeit, Services in der Freifunk-API-Datei anzugeben ob es was zentrales gibt, weiß ich grade nicht.
(Wollen wir die Aachener FF-API-JSON mal in ein git packen vielleicht?)
Ja klar, warum nicht, dort können wir besser Änderungen einpflegen, hau rein!