[Admin] Debugging-Session: Kein Internet per IPv4 in lk-os01

Hi,

in der Hood lk-os01 habe ich leider kein Internet per IPv4. Ich war ja schon
sehr lange nicht mehr auf einer Supernode drauf, habe aber trotzdem mal mein
Glück mit Debugging versucht. Und jetzt habe ich einen Haufen Fragen. Also:
wer Zeit und Lust hat kann ja mal bei meiner Debugging-Session mitlesen und
ein paar Kommentare da lassen...

Die Verbindung von der Node zur Supernode läuft über l2tp. Erstmal checken ob
da überhaupt etwas tut...

# Was ist mein Default-Gateway?

[cjohn@flohlap ~]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.18.144.1 0.0.0.0 UG 600 0 0 wlp3s0
10.18.144.0 0.0.0.0 255.255.248.0 U 600 0 0 wlp3s0

Mein Default Gateway ist 10.18.144.1. Über diesen Router sollte ich Internet
bekommen. Bekomme ich aber nicht.

# Wie weit kommt meine Verbindung?

[cjohn@flohlap ~]$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * _gateway (10.18.144.1) 1.459 ms !N

Meine Verbindung kommt bist zum Router 10.18.144.1. Ich weiß, dass 10.18.144.1
auf einer Supernode liegt. Heißt: bis auf die Supernode komme ich, aber da ist
Schluss. Um von der Supernode weiter zu kommen, brauche ich einen GRE-Tunnel
auf einen Exit-Node und eine Route nach 0.0.0.0/0 über diesen GRE-Tunnel zu
einem Exit-Node. Also per SSH auf die Supernode zu meiner Hook: ssh lk-
os01.sn.ffnw.de.

Auf der Supernode sind diverse GRE-Tunnel zu unseren Exit-Nodes eingerichtet.
Details stehen dazu im Wiki: https://wiki.ffnw.de/Administration/AS206313/
Tunnel_%C3%9Cbersicht

# Welche GRE-Tunnel genau sind auf lk-os01 eingerichtet?

1 floh1111@lk-os01 ~ % ip tunnel
gre-ffnw-ams-a: gre/ip remote 185.116.236.32 local any ttl 64
bb-ol01: gre/ip remote 5.9.56.26 local any ttl 64
gre-ffnw-fra-a: gre/ip remote 185.197.132.3 local any ttl 64
gre-ffnw-ber-a: gre/ip remote 185.197.132.7 local any ttl 64
gre-ffnw-ber-b: gre/ip remote 185.197.132.8 local any ttl 64
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre-ffnw-ef-a: gre/ip remote 87.118.74.56 local any ttl 64

Die große Frage ist: wie finde ich jetzt heraus, ob diese GRE-Tunnel auch
funktionieren?

# Details zu den GRE-Tunneln anzeigen

floh1111@lk-os01 ~ % ip addr show gre-ffnw-ams-a
7: gre-ffnw-ams-a@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue
state UNKNOWN group default qlen 1
    link/gre 0.0.0.0 peer 185.116.236.32
    inet 100.100.64.13 peer 100.100.64.12/32 scope global gre-ffnw-ams-a
       valid_lft forever preferred_lft forever
    inet6 fe80::2/64 scope link
       valid_lft forever preferred_lft forever

Meine lokale Adresse für diesen GRE-Tunnel ist 100.100.64.13 und die des Peers
(Exit-Node) ist 100.100.64.12. Diese Daten suche ich mir jetzt für jeden
Tunnel raus und schaue per Ping auf den Peer, ob der Tunnel funktioniert
(Gibts da eine schlauere Möglichkeit?).

Ich stelle fest:
gre-ffnw-ams-a (Lokal: 100.100.64.12; Peer: 100.100.64.12): TOT
bb-ol01: Was tut das Ding?
gre-ffnw-fra-a (Lokal: 100.100.32.13; Peer: 100.100.32.12): TOT
gre-ffnw-ber-a (Lokal: 100.100.96.13; Peer: 100.100.96.12): LÄUFT
gre-ffnw-ber-b (Lokal: 100.100.112.13; Peer: 100.100.112.12): LÄUFT
gre-ffnw-ef-a (Lokal: 100.100.0.13; peer: 100.100.0.12): TOT
gre0: Was tut das Ding? Okay, Google hilft...

Im Ergebnis heißt das: wir haben zwei funktionierende GRE-Tunnel zu Exit-
Nodes: gre-ffnw-ber-a und gre-ffnw-ber-b.

Zu diesen Nodes sollten wir jetzt auch Routen in bird haben.

# Wird das Interface zu 10.18144.1 von bird gemanaged?

Zunächst einmal checken wir aber auf welchem Interface unsere Adresse
10.18.144.1 liegt und ob dieses Interface überhaupt von bird gemanaged wird.

"ip addr" sagt uns, dass 10.18144.1 auf dem Interface "bat-stadtos" liegt.

root@lk-os01 /home/floh1111 # birdc show interfaces
bat-stadtos up (index=16)
        MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500
        10.18.144.1/21 (Primary, scope site)
[...]

Ergo: Alles was über 10.18.144.1 bzw. bat-stadtos reinkommt wird von bird
geroutet. Also checken wir als nächstes ob bird routen zu unseren Exit-Nodes
über unsere GRE-Tunnel kennt.

# Was haben wir in Bird an Protokollen?

root@lk-os01 /home/floh1111 # birdc show protocols | grep Established
ffnw-bb-ber-a BGP master up 2019-03-11 Established
ibgp-clp01.sn.ffnw.de BGP master up 2019-02-12 Established
ibgp-default01.sn.ffnw.de BGP master up 2019-03-19 Established
ibgp-fri01.sn.ffnw.de BGP master up 2019-02-12 Established
ibgp-gw-ol-01.sn.ffnw.de BGP master up 2019-02-12 Established
ibgp-lk-os02.sn.ffnw.de BGP master up 2019-03-13 Established
ibgp-noh01.sn.ffnw.de BGP master up 2019-04-01 Established
ibgp-wtm01.sn.ffnw.de BGP master up 2019-02-12 Established
ffnw-bb-ber-b BGP master up 2019-04-01 Established

Hier tauchen auch unsere beiden Exit-Nodes auf.

# Sind unsere Routen auch die Präferierten Routen?

root@lk-os01 /home/floh1111 # birdc show route for 0.0.0.0/0
[...]

Ich nehme an, dass die derzeit Präferierte Route die erste Route in dieser
Liste ist? Ist das korrekt?

In diesem Fall wäre das:
via 100.100.96.12 on gre-ffnw-ber-a [ffnw-bb-ber-a 2019-04-01] * (100/0) [i]

Das beduetet, die Routen passen auch.

Scheint eigentlich alles zu passen. Warum zum Teufel hat die Hood lk-os01
trotzdem kein Internet via IPv4?

Viele Grüße
Clemens

Hi Clemens,

Danke für das tolle Debugging, mit Gluon 2017 läuft das bei mir. Ich schaue mir das morgen an und gehe auf deine Punkte ein :wink:

Hi Stefan,

wie gerade schon telefonisch besprochen tritt das Problem mit unserer Firmware
Version 20181124 nicht auf (getestet mit zwei wr841nd).

Auf den Servern scheint also soweit alles in Ordnung zu sein sodass ich das
Problem mal rüber ins Dev-Team gebe.

Viele Grüße
Clemens

10.18.144.1 ist die next_node Adresse. die hat dein eigener FF_Node, nicht der supernode.

oO, wieso das?
Dann kann er das Gateway theoretisch ja nicht erreichen. Aber der Thread gehört ja auf die DEV Liste, da FW Bug

Oha.

Sowohl meine Node (local-node@local-port) als auch die Supernode (bat-stadtos)
haben die Adresse auf den angegebenen Interfaces. Ist das richtig? Was das
Thema next_node angeht bin ich etwas überfragt. Mein Client hat die IP als
Default-Gateway darum bin ich davon ausgegangen, dass hier die Supernode
angesprochen wird.

Ich dachte immer Next Node wäre irgedein IPv6-Feature. Was hat es damit auf
sich?

Viele Grüße
Clemens

next_node ist erstmal eine simple anycast Adresse.

Ich dachte allerdings auch, dass wir da bisher nur eine fdXX IPv6 hatten und keine v4.

Viele Grüße,
Simon

oh. das war mir garnicht bewußt. wieder was gelernt. bzw. könnte diese kollision (?) das Problem sein? oder muss das genau so sein? in der 20181124 gab es keine ipv4 next_node. Bei ipv6 gibt es zumindest keine solche Kollission: der Supernode hat
fd74:fdaa:9dc4:9000::1, während die next_node in der Firmware
fd74:fdaa:9dc4:9000::1:1 ist

der dhcp vergibt v4 Adressen aus dem Bereich 10.18.144.2-10.18.151.254, so dass man jetzt nicht wirklich kollisionsfrei mit zb 10.18.144.2 als next_node testen kann.

LG Lorenz