search

freifunk-mwu / technik-meta

Hier werden offene Punkte und Dokus zu Gateway, Software und Netzwerk verwaltet
5 stars 9 forks source link

Störung: Netz scheint ok, aber kein Zugriff auf Internet #21

Closed whallmann closed 9 years ago

whallmann commented 9 years ago

Hallo. Gerade wurde von mehreren gemeldet, dass wir keinen Zugriff aufs Internet haben. Was könnte man an Daten sichern um die Suche hilfreich zu gestalten?

Hier mal auf Verdacht die Infos von meiner VPN-Kiste PARTENHEIM-WH-01

partenheim-wh-01

...oder als Text:...

Partenheim-WH-01

Model: TP-Link TL-WR741N/ND v4
Firmware release: 0.0.2

11:58:08 up 16 days,  2:08,  load average: 0.00, 0.09, 0.13

6: br-client:  mtu 1500 qdisc noqueue 
    link/ether 64:66:b3:59:5a:a8 brd ff:ff:ff:ff:ff:ff
    inet6 fd37:b4dc:4b1e:0:6666:b3ff:fe59:5aa8/64 scope global dynamic 
       valid_lft 86353sec preferred_lft 14353sec
    inet6 fe80::6666:b3ff:fe59:5aa8/64 scope link 
       valid_lft forever preferred_lft forever

             total         used         free       shared      buffers
Mem:         28860        25656         3204            0         2156
-/+ buffers:              23500         5360
Swap:            0            0            0

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 2304      2304         0 100% /rom
/dev/mtdblock3             576       264       312  46% /overlay
Neighbours

wlan0

Joined IBSS 02:04:08:16:32:64 (on wlan0)
    SSID: 02:04:08:16:32:64
    freq: 2437

Station 12:01:ee:2b:74:9a (Partenheim-WH-02) (on wlan0)
    inactive time:  10 ms
    rx bytes:   146580114
    rx packets: 48673720
    tx bytes:   699650411
    tx packets: 1011375
    tx retries: 452928
    tx failed:  242
    signal:     -56 [-56] dBm
    signal avg: -56 [-56] dBm
    tx bitrate: 135.0 MBit/s MCS 6 40MHz short GI
    rx bitrate: 108.0 MBit/s MCS 5 40MHz
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no

VPN status

fastd running for 1390100.425 seconds
There are 3 peers configured, of which 2 are connected:

mesh_vpn_backbone_peer_spinat: not connected
mesh_vpn_backbone_peer_hinterschinken: connected for 1390040.709 seconds
mesh_vpn_backbone_peer_lotuswurzel: connected for 1390038.350 seconds
Klexx commented 9 years ago

Ich habe das auch festgestellt. Zusätzlich habe ich festgestellt, dass ich andere Rechner im Netz (via gateway) nur sehr schlecht erreichen. Die Übertragungen haben ungewöhlich lange gedauert.

(Auch habe ich festgestellt, dass ich auf einem Client kein DHCP bekommen habe - könnte aber am Client liegen)

ka-ba commented 9 years ago

Nachdem ich letzte Nacht auch seltsames Verhalten hatte (mag aber auch an der schlechten Anbindung gelegen haben? - jetzt wieder VPN-uplink), sehe ich jetzt keine Schwierigkeiten. Bekomme eine v4IP und habe auch connectivity in die weite Welt.

Klexx commented 9 years ago

Hat sich bei mir auch wieder gelegt

whallmann commented 9 years ago

ja sieht wieder gut aus. Am 03.01.2015 04:43 schrieb "Marc" notifications@github.com:

Hat sich bei mir auch wieder gelegt

— Reply to this email directly or view it on GitHub https://github.com/freifunk-mwu/technik-meta/issues/21#issuecomment-68581886 .

kokel commented 9 years ago

Irgendwer verteilt momentan seltsame Routen über das ICVPN:

10.32.0.0/12 via 10.207.0.142 dev icVPN  proto bird  src 10.37.0.23 
10.56.0.0/13 via 10.207.0.142 dev icVPN  proto bird  src 10.37.0.23

10.207.0.142 ist Rhein-Neckar. Habe den zuständigen schon angeschrieben, er kümmert sich drum. Als Workaround habe ich bird4 auf allen Gates gestoppt. Hatte ich aber auch über die Admin Liste kommuniziert...

ka-ba commented 9 years ago

Ach, so'n Dreck! :( Ich hatte gedacht, so was würden wir gar nicht annehmen, aber da ist unsere bird config tatsächlich nicht so sinnvoll. Wir haben bisher:

function is_freifunk_dn42() {
    return (net ~ [
        10.0.0.0/8{12,32},
        172.22.0.0/15+,
        172.31.0.0/16
        ]);
}

Wir sollten auf

        10.0.0.0/8{16,32},

ändern. Damit müssten wir noch immer alle legalen Routen reinlassen, oder?

BTW: Soll wir die 172er so lassen? Eigentlich gehen mir diese ganzen Mini-Netze auf die Nerven, andererseits sind es diese ganzen "hack spaces" - ist ja vielleicht für manche interessant!?

kokel commented 9 years ago

Ja, super. Sieht nun besser aus:

root@spinat:~# birdc 'show route table ic' | egrep '^10.3|^10.5'
10.31.0.0/16       via 10.207.0.5 on icVPN [luebeck2 15:16:28 from 10.207.0.131] * (100) [AS44194i]
10.38.0.0/16       via 10.207.0.40 on icVPN [braunschweig1 15:18:09] * (100) [AS65380i]
10.36.0.0/16       via 10.207.0.5 on icVPN [luebeck2 15:16:28 from 10.207.0.131] * (100) [AS44194i]
10.37.0.0/18       dev mzBR [wi_subnets 15:16:23] * (240)
10.59.78.0/24      via 10.207.0.2 on icVPN [dresden1 15:16:39 from 10.207.0.19] * (100) [AS65041i]
10.50.0.0/16       via 10.207.0.23 on icVPN [luebeck2 15:16:28 from 10.207.0.131] * (100) [AS65024i]
10.52.0.0/16       via 10.207.0.8 on icVPN [luebeck2 15:16:28 from 10.207.0.131] * (100) [AS65530i]
10.59.0.0/21       via 10.207.0.2 on icVPN [dresden1 15:16:39 from 10.207.0.19] * (100) [AS65041i]
10.56.0.0/18       dev wiBR [wi_subnets 15:16:23] * (240)

Hier ein paar mehr Infos über die bösen Routen:

root@spinat:~# birdc 'show route table ic for 10.32.0.0/12'
BIRD 1.4.5 ready.
10.32.0.0/12       via 10.207.0.142 on icVPN [rhein_neckar 15:20:25] * (100) [AS76103?]
                   via 10.207.0.142 on icVPN [luebeck2 15:20:18 from 10.207.0.131] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dresden1 15:20:20 from 10.207.0.19] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dreilaendereck1 15:20:19 from 10.207.0.75] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [koeln1 15:20:18 from 10.207.0.57] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dreilaendereck3 15:20:18 from 10.207.0.72] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [ehingen1 15:20:18 from 10.207.0.45] (100) [AS76103?]

root@spinat:~# birdc 'show route table ic for 10.56.0.0/13'
BIRD 1.4.5 ready.
10.56.0.0/13       via 10.207.0.142 on icVPN [rhein_neckar 15:20:25] * (100) [AS76103?]
                   via 10.207.0.142 on icVPN [bremen2 15:21:08 from 10.207.0.196] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [goettingen1 15:21:07 from 10.207.0.65] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [westpfalz1 15:21:03 from 10.207.0.85] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dreilaendereck2 15:20:47 from 10.207.0.74] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [luebeck2 15:20:18 from 10.207.0.131] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dresden1 15:20:20 from 10.207.0.19] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dreilaendereck1 15:20:19 from 10.207.0.75] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [koeln1 15:20:18 from 10.207.0.57] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [dreilaendereck3 15:20:18 from 10.207.0.72] (100) [AS76103?]
                   via 10.207.0.142 on icVPN [ehingen1 15:20:18 from 10.207.0.45] (100) [AS76103?]
ka-ba commented 9 years ago

Ich hab doch noch gar nicht. :} Das ist jetzt nur der positive Effekt Deines zusätzlichen Filters.

Aber wenn es keine Einwände gibt, dann setze ich das demnächst um.

ka-ba commented 9 years ago

Die folgenden Routen werden jetzt bei uns offenbar herausgefiltert / nehmen wir per BGP nicht an, obwohl sie uns geschickt werden (dafür habe ich mal import keep filtered on auf dem hinterschinken aktiviert):

10.8.0.0/14        via 10.207.0.142 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS76103?]
                   [aus div. Quellen]
                   via 10.207.0.63 on icVPN [hamburg03 02:39:41] (100) [AS76103?]
10.16.0.0/12       via 10.207.0.142 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS76103?]
                   [aus div. Quellen]
                   via 10.207.0.63 on icVPN [hamburg03 02:39:41] (100) [AS76103?]
104.59.246.0/24    via 10.207.0.2 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS65041i]
                   [aus div. Quellen]
10.32.0.0/12       via 10.207.0.142 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS76103?]
                   [aus div. Quellen]
                   via 10.207.0.63 on icVPN [hamburg03 02:39:41] (100) [AS76103?]
104.62.0.0/16      via 10.207.0.13 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS65046i]
                   [aus div. Quellen]
10.52.0.0/14       via 10.207.0.142 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS76103?]
                   [aus div. Quellen]
                   via 10.207.0.63 on icVPN [hamburg03 02:39:41] (100) [AS76103?]
10.56.0.0/13       via 10.207.0.142 on icVPN [dreilaendereck1 02:39:49 from 10.207.0.75] * (100) [AS76103?]
                   [aus div. Quellen]
                   via 10.207.0.63 on icVPN [hamburg03 02:39:41] (100) [AS76103?]

(Und diverse 172.31.x.y/z mit z>16 ... was vielleicht unbeabsichtigt ist?)

Wollen wir das so belassen?

kokel commented 9 years ago

Also hier scheint es unterschiedliche Meinungen zu geben. Ich persönlich würde die auch erstmal rausnehmen. Beim dn24 hats ja auch iwie experimental charakter, um mit bgp rumzuspielen und Erfahrungen zu sammeln. So meine ich das gelesen zu haben.

Andererseits ist es auch ein freies Netz, wie steht denn das pico peering agreement dazu? Vermutlich würden wir dann dagegen verstoßen?

ka-ba commented 9 years ago

Wollen wir dieses issue als gelöst schließen?

spookey commented 9 years ago

Ja, ich will..