Intercity-Verbindung und Backbone

Reka · 29. Dezember 2014 um 10:20

(da ich unter Technik keine Kategorie für den Backbone des FFRL finde, schreibe ich mal hier. bitte ggfs. verschieben!)

Verfügen die Domänen und Freifunk-Communities, die bereits an den Backbone des FFRL angebunden sind, automatisch über eine Intercity-Verbindung?

Oder hat das eine nichts mit dem anderen zu tun?
Was müsste ggfs. dafür getan werden?

CHRlS · 29. Dezember 2014 um 10:45

Im Rheinland Backbone werden ausschließlich öffentliche Adressräume geroutet.

Das icvpn kümmert sich im Gegensatz primär um die Konnektivität der internen Netze untereinander.

Reka · 29. Dezember 2014 um 11:20

verstehe.
ist diese Anleitung noch aktuell? IC-VPN – wiki.freifunk.net
Hat das schon mal jemand hier ausprobiert?

steffend · 29. Dezember 2014 um 11:37

Ich hab das nach der Anleitung vom Freifunk Dreiländereck mal ausprobiert. Die Anleitung basiert auf dem Wiki Eintrag, sollte also funktionieren:
root@ffeh-gw01:~# birdc show protocol |grep „Established“ braunschweig1 BGP ebgp up 21:16:07 Established braunschweig2 BGP ebgp up 21:17:04 Established bremen2 BGP ebgp up 10:04:16 Established chemnitz1 BGP ebgp up 21:16:07 Established darmstadt2 BGP ebgp up 21:16:07 Established dreilaendereck1 BGP ebgp up 21:16:07 Established dreilaendereck3 BGP ebgp up 21:16:05 Established goettingen1 BGP ebgp up 12:32:26 Established guetersloh1 BGP ebgp up 21:16:58 Established guetersloh4 BGP ebgp up 21:16:07 Established hamburg02 BGP ebgp up 21:17:53 Established luebeck2 BGP ebgp up 21:16:08 Established mainz2 BGP ebgp up 04:00:49 Established moehne1 BGP ebgp up 21:16:08 Established paderborn01 BGP ebgp up 01:42:04 Established paderborn02 BGP ebgp up 21:16:08 Established wiesbaden1 BGP ebgp up 21:32:58 Established wiesbaden2 BGP ebgp up 21:27:47 Established

Allerdings ist das ganze sehr chaotisch. Zu manchen Communities bekomme ich keine Verbindung, trotz Aussage von bird dass eine Verbindung besteht und in der Routing Tabelle die Informationen korrekt eingetragen sind.
(Beispiel Gütersloh)
root@ffeh-gw01:~# ip route […] 10.255.0.0/16 via 10.207.0.132 dev icvpn proto bird src 10.252.0.2 […] root@ffeh-gw01:~# ping 10.207.0.132 PING 10.207.0.132 (10.207.0.132) 56(84) bytes of data. 64 bytes from 10.207.0.132: icmp_seq=1 ttl=64 time=0.820 ms 64 bytes from 10.207.0.132: icmp_seq=2 ttl=64 time=1.04 ms — 10.207.0.132 ping statistics — 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.820/0.930/1.041/0.114 ms root@ffeh-gw01:~# traceroute 10.255.1.1 traceroute to 10.255.1.1 (10.255.1.1), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * *

Reka · 29. Dezember 2014 um 11:45

Im Wiki ist @wusel als Admin für Gütersloh eingetragen, der wuselt hier ja auch rum. Vielleicht weiß er was dazu?^^

steffend · 29. Dezember 2014 um 11:55

Ich hab @wusel schon ne Mail geschickt, er meinte ICVPN wäre bei Gütersloh gerade low prio, da es keine überregional interessanten Dienste gäbe.

DSchmidtberg · 29. Dezember 2014 um 12:03

Macht es nicht mehr sinn das vom Backbone erledigen zu lassen?

steffend · 29. Dezember 2014 um 12:41

@DSchmidtberg Das Backbone kümmert sich nur um öffentliche Adressräume, siehe Zitat. Wer ins ICVPN will muss sich dann wohl selbst drum kümmern…

CHRlS · 29. Dezember 2014 um 12:46

So ist es thumbsup

Rheinland Backbone und icvpn sind koexistent ohne zu konkurrieren.

Überschneidungen gibt es beim IPv6, in Netzen, wo öffentliche IPv6 Adressen genutzt werden. Diese erreichen sich dann auch über das Rheinland Backbone, da sie im Internet geroutet werden.

In privat adressierten IPv6 Netzen und bei IPv4 generell, besteht nur über das ICVPN die Möglichkeit sich untereinander zu konnektieren.

DSchmidtberg · 29. Dezember 2014 um 12:48

Nur weil es bis jetzt immer so war muss es nicht auch in Zukunft so sein.

An einem Backbone werden Netze miteinander verbunden.

Zur Zeit werden nur einzelne Domänen ins Internet geleitet, Ziel sollte es sein auch diese Domänen untereinander zu verbinden und anschließend auch die Verbindung zu anderen Vereinen und Communitys sicherzustellen. Sonst ist später nicht überall Freifunk drin wo (die SSID) Freifunk draufsteht.

CHRlS · 29. Dezember 2014 um 13:08

Deine Ziele für das Rheinland Backbone kannst Du dem Vorstand und Team Backbone ja mal vorstellen…

wusel · 29. Dezember 2014 um 18:33

Moin,

  On 29/12/14 13:05, <a class="moz-txt-link-abbreviated" href="mailto:forum@freifunk-rheinland.net">forum@freifunk-rheinland.net</a> wrote:

steffend

December
Reka:

Im Wiki ist @wusel als Admin für Gütersloh eingetragen, der wuselt hier ja auch rum. Vielleicht weiß er was dazu?^^

Ich hab @wusel schon ne Mail geschickt, er meinte ICVPN wäre bei Gütersloh gerade low prio, da es keine überregional interessanten Dienste gäbe.

Yepp, so ist das. Von einem Linux-Rechner im FFGT-Netz sieht's
übrigens so aus:




wusel@ysabell:~$ traceroute 10.29.0.2


traceroute to 10.29.0.2 (10.29.0.2), 30 hops max, 60 byte packets


 1  gw01.ffgt (10.255.1.1)  36.155 ms  36.687 ms  39.884 ms


 2  vpn1.freifunk-bielefeld.de (37.221.194.149)  56.388 ms  61.773
ms  62.413 ms


 3  vpn1.freifunk-bielefeld.de (37.221.194.149)  2787.599 ms !H 
2790.332 ms !H  2790.917 ms !H




wusel@ysabell:~$ traceroute 10.36.0.2 [Berlin]


traceroute to 10.36.0.2 (10.36.0.2), 30 hops max, 60 byte packets


 1  gw01.ffgt (10.255.1.1)  36.125 ms  39.886 ms  40.269 ms


 2  * * *


 3  * * *


 4  * * *


 5  * * *


 6  * * *


 7  * bgp01.berlin.freifunk.net (77.87.48.49)  55.402 ms  59.522 ms


 8  * * *


 9  bgp01.berlin.freifunk.net (77.87.48.49)  78.911 ms  80.359 ms 
81.793 ms


10  * * *


11  bgp01.berlin.freifunk.net (77.87.48.49)  83.862 ms * *


12  * * *


13  * * *


14  * *^C




wusel@ysabell:~$ traceroute 10.132.0.2


traceroute to 10.132.0.2 (10.132.0.2), 30 hops max, 60 byte packets


 1  gw01.ffgt (10.255.1.1)  44.422 ms  44.482 ms  45.267 ms


 2  * * *


 3  * * *


 4  gw05.paderborn.freifunk.net (192.26.175.162)  74.203 ms  74.608
ms  90.942 ms


 5  gw05.paderborn.freifunk.net (192.26.175.162)  2631.953 ms !H 
2635.236 ms !H  2641.376 ms !H




wusel@ysabell:~$ traceroute 10.252.0.2 [Ehingen]


traceroute to 10.252.0.2 (10.252.0.2), 30 hops max, 60 byte packets


 1  gw01.ffgt (10.255.1.1)  45.041 ms  44.984 ms  45.091 ms


 2  Freifunk-GT-GW01-EXIT (192.251.226.168)  45.119 ms  45.211 ms 
45.290 ms


 3  xmws-gtso-de12.nw.mediaways.net (192.251.226.203)  49.641 ms 
49.826 ms  49.799 ms


 4  xmws-gtso-de32-chan-2.nw.mediaways.net (195.71.9.5)  50.296 ms 
50.508 ms  51.263 ms


 5  xmwc-gtso-de02-chan-32.nw.mediaways.net (195.71.9.13)  52.131
ms  54.443 ms  54.521 ms


 6  rmwc-gtso-de01-ge-3-1-0-0.nw.mediaways.net (195.71.97.65) 
55.376 ms  40.329 ms  41.568 ms^C




(Hmm, ja, ein ip route add unreachable 10.0.0.0/8 metric 500 table
42 wäre wohl sinnvoll. Fixed:)




wusel@ysabell:~$ traceroute 10.252.0.2


traceroute to 10.252.0.2 (10.252.0.2), 30 hops max, 60 byte packets


 1  gw01.ffgt (10.255.1.1)  47.644 ms !H  47.863 ms !H  47.925 ms !H




birdc sagt:




berlin1  BGP      icvpn    start  Dec26       Active        Socket:
Connection closed


bielefeld1 BGP      icvpn    up     11:51       Established  


bielefeld2 BGP      icvpn    up     10:34       Established  


ehingen1 BGP      icvpn    start  16:16       Active        Socket:
Connection refused




Paderborn hat AFAIK erst zum diesjährigen C3 die Verbindung zum
ICVPN aufgebaut, daher haben wir die noch nicht drin, ebensowenig
wie Hamburgs Änderungen.




Wir streben eine überwachbare Ausgabe von u. a. "birdc show
protocols" an (=&gt; Nagios), und zumindest mit dem alten Setup (aus
dem Wiki), mit dem gw01 und gw04 noch fahren, ist das nicht machbar.




gw01:~# birdc show protocols | grep icvpn | grep Established  | wc
-l


25


gw01:~# birdc show protocols | grep icvpn | wc -l


73




Mit bgp1/bgp2 werden wir den Checkout aus git probieren (Ralf hat da
schon mal angefangen), aber die Arbeiten werden immer wieder durch
8-Stunden-Slices höher priorisierter Tasks unterbrochen -- und ja,
derzeit liegt der Schwerpunkt darauf, daß wir zu den Nachbarn direkt
kommen und IPv6 via Förderverein tut.

steffend · 29. Dezember 2014 um 20:05

jap, also Verbindung nach Gütersloh klappt jetzt.
Ehingen ist damit erfolgreich mit
Braunschweig
Bremen
Chemnitz
Dreiländereck
Gütersloh
Lübeck
Wiesbaden
verbunden.

Laut bird ist die Verbindung zu folgenden Communities erfolgreich, Clients kommen aber nicht in das Netz:
Darmstadt
traceroute to 10.223.0.1 (10.223.0.1), 64 hops max, 52 byte packets 1 1.gateways.services.ffeh (10.252.0.2) 35.261 ms 24.228 ms 25.422 ms 2 * * * 3 * * *
Göttingen
traceroute to 10.109.0.42 (10.109.0.42), 64 hops max, 52 byte packets 1 1.gateways.services.ffeh (10.252.0.2) 37.078 ms 24.626 ms 38.174 ms 2 * * * 3 holstentor.ffhl (10.130.12.1) 55.604 ms 43.866 ms 39.881 ms 4 burgtor.ffhl (10.130.14.1) 53.083 ms 43.765 ms 78.189 ms 5 * * * 6 * * * 7 * * *
Hamburg
traceroute to 10.112.1.1 (10.112.1.1), 64 hops max, 52 byte packets 1 1.gateways.services.ffeh (10.252.0.2) 35.790 ms 26.237 ms 24.592 ms 2 10.255.255.254 (10.255.255.254) 43.234 ms 45.994 ms 46.629 ms 3 * * *
Möhne
EDIT: siehe Intercity-Verbindung und Backbone - #17 von thomasDOTwtf
Paderborn
traceroute to 10.132.12.1 (10.132.12.1), 64 hops max, 52 byte packets 1 1.gateways.services.ffeh (10.252.0.2) 34.461 ms 47.713 ms 22.983 ms 2 10.207.0.231 (10.207.0.231) 32.493 ms 41.169 ms 32.634 ms 3 * * * 4 * * *
Bei allen anderen Communities erfolgt keine Verbindung per bird. Bei vielen aber per tinc schon. Also VPN Verbindung steht, Routing klappt nicht.

wusel · 30. Dezember 2014 um 03:37

Hmm. Du scheinst das z. T. über GT zu routen (10.255.255.254); wie „kerel“ von FF KBU heute morgen mitteilte, announcten wir fälschlich 10.207.0.0/16, das sollte nun gefixt sein (effektiv sollte GT jetzt einzig 10.255.0.0/16 announcen).

steffend · 30. Dezember 2014 um 10:34

Liegt scheinbar daran:
10.255.255.254/32 via 10.207.0.196 on icvpn [bremen2 04:16:08] * (100) [AS64787?] via 10.207.0.196 on icvpn [wiesbaden1 04:17:52 from 10.207.0.56] (100) [AS64787?] via 10.207.0.196 on icvpn [hamburg02 04:17:37 from 10.207.0.64] (100) [AS64787?] via 10.207.0.196 on icvpn [dreilaendereck3 04:17:07 from 10.207.0.72] (100) [AS64787?] via 10.207.0.196 on icvpn [paderborn02 04:17:04 from 10.207.0.232] (100) [AS64787?] via 10.207.0.196 on icvpn [dreilaendereck1 04:16:59 from 10.207.0.75] (100) [AS64787?] via 10.207.0.196 on icvpn [darmstadt2 04:16:58 from 10.207.0.219] (100) [AS64787?] via 10.207.0.196 on icvpn [mainz2 04:16:56 from 10.207.1.37] (100) [AS64787?] via 10.207.0.196 on icvpn [wiesbaden2 04:16:08 from 10.207.1.56] (100) [AS64787?] via 10.207.0.196 on icvpn [luebeck2 04:16:08 from 10.207.0.131] (100) [AS64787?] via 10.207.0.196 on icvpn [paderborn01 04:16:08 from 10.207.0.231] (100) [AS64787?] via 10.207.0.196 on icvpn [goettingen1 04:16:07 from 10.207.0.65] (100) [AS64787?]
Ausgabe von birdc show route. Anscheinend announcen hier viele Communities Routen via Bremen im Subnetz von Gütersloh.

wusel · 30. Dezember 2014 um 11:07

Hmm.

gw01:~# birdc show route 10.255.255.254/32 all
BIRD 1.3.7 ready.
10.255.255.254/32 via 10.255.4.1 on br-ffgt [pipe_ibgp 03:49] * (70)
Type: pipe unicast univ
BGP.origin: IGP
BGP.as_path:
BGP.next_hop: 10.255.4.1
BGP.local_pref: 100
BGP.community: (56662,42)

root@gw04:~# birdc show route 10.255.255.254/32 all
BIRD 1.4.5 ready.
10.255.255.254/32 via 10.207.0.196 on icvpn [pipe_icvpn 03:47:50] ! (70)
Type: pipe unicast univ
BGP.origin: Incomplete
BGP.as_path: 65196 4242420128 4242420128 4242420128 64649 56662 64787 64787
BGP.next_hop: 10.207.0.196
BGP.local_pref: 100
BGP.community: (56662,42)

Und ich hatte gedacht, ich nehme keine Routen von uns von außen an. Wahrscheinlich liegt’s am 10.255.0.0/16 statt 10.255.0.0/16+?

template bgp bgp_icvpn {
local as 65533;
table icvpn;
import where (is_freifunk_dn42() && !is_self_net());
export where is_self_net();;
};

seufz

thomasDOTwtf · 30. Dezember 2014 um 15:24

Die Möhne-Anbindung an das Intercity VPN ist z.Z. nur outbound monitoring:
http://icvpn.wg1337.de