FFNW BB Debugging

stefan6 · 28. März 2017 um 07:30

habt ihr gerade im Bereich v6 irgendwelche Störungen?

Heute morgen sind uns auf einem Gateway alle v6 Anbindungen um die Ohren geflogen. Konfigurationen wurden nicht angefasst.

bird6c gibt folgendes aus:
ffrl-bb-ber-a BGP master up 09:26:59 Established
ffrl-bb-ber-b BGP master start 09:26:56 Connect
ffrl-bb-dus-a BGP master start 09:26:56 Connect
ffrl-bb-dus-b BGP master start 09:26:56 OpenConfirm
ffrl-bb-fra-a BGP master start 09:26:56 Connect
ffrl-bb-fra-b BGP master start 09:26:56 Connect

Diese OpenConfirm Meldungen kommen nach einiger Zeit bei allen BB Anbindungen.

stefan6 · 28. März 2017 um 09:49

Ich hab grade selber mal ein wenig geschaut. Nach einem bird6 restart kommt keine BGP mehr zustande.

Laut LG ist hier auch was nicht erreichbar: http://lg.ring.nlnog.net/detail/lg01/ipv6?q=FREIFUNKRL3

takt · 28. März 2017 um 10:23

Hast du mal konkrete Infos?
Welche BGP sessions (a/b Ende)?
Welche Tunnel?
Pingt’s im Tunnel? v4? v6?
Pingt’s ohne Tunnel?

ich sehe gerade jedenfalls kein generelles Problem hier mit IPv6.

stefan6 · 28. März 2017 um 10:28

Hi,

das Problem betrifft anscheinend all unsere Sessions.

Entpunkte: 5.9.56.26, 46.38.241.104
Ping über v4 / v6 auf die Tunnel IPs klappt.

    ffrl-bb-ber-b BGP      master   start  12:23:45    OpenConfirm   Received: Hold timer expired
    ffrl-bb-dus-a BGP      master   start  12:28:14    Idle          BGP Error: Hold timer expired
    ffrl-bb-dus-b BGP      master   start  12:27:15    OpenConfirm   BGP Error: Hold timer expired
    ffrl-bb-fra-a BGP      master   start  12:28:29    Idle          Received: Hold timer expired
    ffrl-bb-fra-b BGP      master   start  12:25:09    OpenConfirm   BGP Error: Hold timer expired

64 bytes from 2a03:2260:0:35c::2: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from 2a03:2260:0:35c::2: icmp_seq=2 ttl=64 time=0.025 ms

64 bytes from 2a03:2260:0:35c::1: icmp_seq=1 ttl=63 time=34.2 ms
64 bytes from 2a03:2260:0:35c::1: icmp_seq=2 ttl=63 time=35.1 ms

Ohne Tunnel gehen die Pings auch, es scheint ein BGP Problem zu sein.

Ich meinte deswegen:
http://lg.ring.nlnog.net/detail/lg01/ipv6?q=FREIFUNKRL3

takt · 28. März 2017 um 12:28

1 root@bb-b.fra2.fra.de.ffrl.de ~ # ip r g 2a03:2260:0:35d::2
2a03:2260:0:35d::2 from :: dev tun-ffnw-srv12 proto kernel src 2a03:2260:0:35d::1 metric 256
root@bb-b.fra2.fra.de.ffrl.de ~ # ping6 2a03:2260:0:35d::2
PING 2a03:2260:0:35d::2(2a03:2260:0:35d::2) 56 data bytes
64 bytes from 2a03:2260:0:35d::2: icmp_seq=1 ttl=64 time=5.27 ms
^C
— 2a03:2260:0:35d::2 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.276/5.276/5.276/0.000 ms
root@bb-b.fra2.fra.de.ffrl.de ~ # telnet 2a03:2260:0:35d::2 179
Trying 2a03:2260:0:35d::2…
Connected to 2a03:2260:0:35d::2.
Escape character is ‚^]‘.
Connection closed by foreign host.

Stimmt wohl was bei euch nicht?

stefan6 · 28. März 2017 um 12:32

Öhm, wie soll denn die Kiste hier erreichbar sein, wenn die BGP nicht steht?

ich kann eure Seite pingen… Es betrifft ja nicht nur 1 GW.

Folgendes ist mir eben noch aufgefallen:
Incoming connection from 2a03:2260:0:267::1 (port 37240) rejected

EDIT: Port ist offen

     netstat -an | grep 179                                                                :(
tcp        0      0 0.0.0.0:179             0.0.0.0:*               LISTEN
tcp        0      0 100.64.4.189:179        100.64.4.188:52710      VERBUNDEN
tcp        0      0 10.18.1.5:57333         10.18.1.11:179          VERBUNDEN
tcp        0      0 10.18.1.5:179           10.18.1.7:53933         VERBUNDEN
tcp        0      0 100.64.4.195:42747      100.64.4.194:179        VERBUNDEN
tcp        0      0 10.18.1.5:37373         10.18.1.1:179           VERBUNDEN
tcp        0      0 100.64.6.115:179        100.64.6.114:52426      VERBUNDEN
tcp        0      0 10.18.1.5:179           10.18.1.20:36415        VERBUNDEN
tcp        0      0 10.18.1.5:33127         10.18.1.12:179          VERBUNDEN
tcp        0      0 10.18.1.5:39409         10.18.1.13:179          VERBUNDEN
tcp        0      0 10.18.1.5:54703         10.18.1.9:179           VERBUNDEN
tcp        0      0 10.18.1.5:179           10.18.1.4:59415         VERBUNDEN
tcp        0      0 10.18.1.5:32817         10.18.1.8:179           VERBUNDEN
tcp        0      0 10.18.1.5:41441         10.18.1.6:179           VERBUNDEN
tcp        0      0 100.64.4.191:179        100.64.4.190:42498      VERBUNDEN
tcp        0      0 10.18.1.5:45793         10.18.1.3:179           VERBUNDEN
tcp        0      0 100.64.6.113:179        100.64.6.112:55824      VERBUNDEN
tcp        0      0 10.18.1.5:40969         10.18.1.10:179          VERBUNDEN
tcp        0      0 100.64.4.193:179        100.64.4.192:33221      VERBUNDEN
tcp6       0      0 :::179                  :::*                    LISTEN
tcp6       0    126 2a03:2260:0:265::2:179  2a03:2260:0:265:::36364 LAST_ACK
tcp6       0      0 fd74:fdaa:9dc4:10:51591 fd74:fdaa:9dc4:106::179 VERBUNDEN
tcp6       0      0 fd74:fdaa:9dc4:105::179 fd74:fdaa:9dc4:10:46691 VERBUNDEN
tcp6       0      0 fd74:fdaa:9dc4:10:50423 fd74:fdaa:9dc4:108::179 VERBUNDEN
tcp6       0      0 fd74:fdaa:9dc4:105::179 fd74:fdaa:9dc4:11:57679 VERBUNDEN
tcp6       0     87 2a03:2260:0:266::2:179  2a03:2260:0:266:::38462 VERBUNDEN
tcp6       0      0 fd74:fdaa:9dc4:10:38319 fd74:fdaa:9dc4:109::179 VERBUNDEN
tcp6       0    106 2a03:2260:0:35d::2:179  2a03:2260:0:35d:::42814 VERBUNDEN
tcp6       0      0 fd74:fdaa:9dc4:105::179 fd74:fdaa:9dc4:10:47141 VERBUNDEN
tcp6       0      1 2a03:2260:0:265:::49713 2a03:2260:0:265::1:179  SYN_SENT
tcp6       0      0 fd74:fdaa:9dc4:10:38803 fd74:fdaa:9dc4:107::179 VERBUNDEN
tcp6       0      1 2a03:2260:0:267:::49913 2a03:2260:0:267::1:179  SYN_SENT
tcp6       0      0 fd74:fdaa:9dc4:10:57869 fd74:fdaa:9dc4:101::179 VERBUNDEN
tcp6       0      0 2a03:2260:0:264::2:179  2a03:2260:0:264:::40620 VERBUNDEN

takt · 28. März 2017 um 12:34

Eine TCP Verbindung zwischen 2a03:2260:0:35d::1 (uns) und 2a03:2260:0:35d::2 (euch) auf Port 179 ist die Grundlage der BGP Sitzung. Nachdem wir uns zu euch verbinden (siehe telnet) terminiert eure Kiste die Verbindung. Das sollte sie nicht tun. Kannst du bitte mal euren BIRD neu starten?

stefan6 · 28. März 2017 um 12:35

Hm, sehr merkwürdig, das dass hier auf mehreren Kisten auftritt.

done.

takt · 28. März 2017 um 12:50

root@bb-b.fra2.fra.de.ffrl.de ~ # telnet 2a03:2260:0:35d::2 179
Trying 2a03:2260:0:35d::2…
Connected to 2a03:2260:0:35d::2.
Escape character is ‚^]‘.
Connection closed by foreign host.

Wieder instant zu nachdem es beim vorherigen Versuch mal kurz offen geblieben ist.

stefan6 · 28. März 2017 um 12:52

Das ist aber mächtig komisch, wie kann der Port zu sien wenn wir uns über v4 über den gleichen unterhalten?

Mach ich das zu eurer Seite, bricht die verbindung auch direkt ab

takt · 28. März 2017 um 12:58

Der IPv4 und der IPv6 TCP Port 179 sind unabhängig voneinainder. Die haben nichts miteinander zu tun.

Hier mal ein TCPdump:
root@bb-b.fra2.fra.de.ffrl.de ~ # tcpdump -n -i tun-ffnw-srv12 host 2a03:2260:0:35d::1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun-ffnw-srv12, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:58:11.549644 IP6 2a03:2260:0:35d::1.43642 > 2a03:2260:0:35d::2.179: Flags [S], seq 1687196440, win 26800, options [mss 1340,sackOK,TS val 406022771 ecr 0,nop,wscale 7], length 0
14:58:11.569725 IP6 2a03:2260:0:35d::1.43642 > 2a03:2260:0:35d::2.179: Flags [.], ack 3622802651, win 210, options [nop,nop,TS val 406022776 ecr 38889], length 0
14:58:11.569765 IP6 2a03:2260:0:35d::1.43642 > 2a03:2260:0:35d::2.179: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406022776 ecr 38889], length 51: BGP, length: 51
14:58:11.589893 IP6 2a03:2260:0:35d::1.43642 > 2a03:2260:0:35d::2.179: Flags [.], ack 2, win 210, options [nop,nop,TS val 406022781 ecr 38894], length 0
14:58:11.589940 IP6 2a03:2260:0:35d::1.43642 > 2a03:2260:0:35d::2.179: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406022781 ecr 38894], length 0
14:58:15.549995 IP6 2a03:2260:0:35d::1.43698 > 2a03:2260:0:35d::2.179: Flags [S], seq 1419286592, win 26800, options [mss 1340,sackOK,TS val 406023772 ecr 0,nop,wscale 7], length 0
14:58:15.569444 IP6 2a03:2260:0:35d::1.43698 > 2a03:2260:0:35d::2.179: Flags [.], ack 99612436, win 210, options [nop,nop,TS val 406023776 ecr 39890], length 0
14:58:15.569476 IP6 2a03:2260:0:35d::1.43698 > 2a03:2260:0:35d::2.179: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406023776 ecr 39890], length 51: BGP, length: 51
14:58:15.588871 IP6 2a03:2260:0:35d::1.43698 > 2a03:2260:0:35d::2.179: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406023781 ecr 39894], length 0
14:58:20.546035 IP6 2a03:2260:0:35d::1.43782 > 2a03:2260:0:35d::2.179: Flags [S], seq 701583473, win 26800, options [mss 1340,sackOK,TS val 406025021 ecr 0,nop,wscale 7], length 0
14:58:20.565652 IP6 2a03:2260:0:35d::1.43782 > 2a03:2260:0:35d::2.179: Flags [.], ack 940702130, win 210, options [nop,nop,TS val 406025025 ecr 41138], length 0
14:58:20.565771 IP6 2a03:2260:0:35d::1.43782 > 2a03:2260:0:35d::2.179: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406025025 ecr 41138], length 51: BGP, length: 51
14:58:24.616400 IP6 2a03:2260:0:35d::1.43864 > 2a03:2260:0:35d::2.179: Flags [S], seq 1086845339, win 26800, options [mss 1340,sackOK,TS val 406026038 ecr 0,nop,wscale 7], length 0
14:58:24.635825 IP6 2a03:2260:0:35d::1.43864 > 2a03:2260:0:35d::2.179: Flags [.], ack 4147909740, win 210, options [nop,nop,TS val 406026043 ecr 42156], length 0
14:58:24.635879 IP6 2a03:2260:0:35d::1.43864 > 2a03:2260:0:35d::2.179: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406026043 ecr 42156], length 51: BGP, length: 51
14:58:24.655188 IP6 2a03:2260:0:35d::1.43864 > 2a03:2260:0:35d::2.179: Flags [.], ack 2, win 210, options [nop,nop,TS val 406026048 ecr 42161], length 0
14:58:24.655252 IP6 2a03:2260:0:35d::1.43864 > 2a03:2260:0:35d::2.179: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406026048 ecr 42161], length 0
^C
17 packets captured
26 packets received by filter
0 packets dropped by kernel

Ich sehe keine Antwort kommen. Kannst du mal bitte bei dir dumpen?

stefan6 · 28. März 2017 um 13:04

listening on gre-ffrl-fra-b, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:04:19.495143 IP6 2a03:2260:0:35d::1.50018 > 2a03:2260:0:35d::2.bgp: Flags [S], seq 2551849558, win 26800, options [mss 1340,sackOK,TS val 406114757 ecr 0,nop,wscale 7], length 0
15:04:19.515235 IP6 2a03:2260:0:35d::1.50018 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2185820854, win 210, options [nop,nop,TS val 406114762 ecr 130875], length 0
15:04:19.515355 IP6 2a03:2260:0:35d::1.50018 > 2a03:2260:0:35d::2.bgp: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406114762 ecr 130875], length 51: BGP
15:04:19.535202 IP6 2a03:2260:0:35d::1.50018 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2, win 210, options [nop,nop,TS val 406114767 ecr 130880], length 0
15:04:19.535270 IP6 2a03:2260:0:35d::1.50018 > 2a03:2260:0:35d::2.bgp: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406114767 ecr 130880], length 0
15:04:23.805711 IP6 2a03:2260:0:35d::1.50088 > 2a03:2260:0:35d::2.bgp: Flags [S], seq 3062443566, win 26800, options [mss 1340,sackOK,TS val 406115834 ecr 0,nop,wscale 7], length 0
15:04:23.824990 IP6 2a03:2260:0:35d::1.50088 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 712392325, win 210, options [nop,nop,TS val 406115839 ecr 131953], length 0
15:04:23.825291 IP6 2a03:2260:0:35d::1.50088 > 2a03:2260:0:35d::2.bgp: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406115839 ecr 131953], length 51: BGP
15:04:23.844388 IP6 2a03:2260:0:35d::1.50088 > 2a03:2260:0:35d::2.bgp: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406115844 ecr 131957], length 0
15:04:28.509310 IP6 2a03:2260:0:35d::1.50176 > 2a03:2260:0:35d::2.bgp: Flags [S], seq 2526649341, win 26800, options [mss 1340,sackOK,TS val 406117010 ecr 0,nop,wscale 7], length 0
15:04:28.528650 IP6 2a03:2260:0:35d::1.50176 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2090384464, win 210, options [nop,nop,TS val 406117015 ecr 133128], length 0
15:04:28.528675 IP6 2a03:2260:0:35d::1.50176 > 2a03:2260:0:35d::2.bgp: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406117015 ecr 133128], length 51: BGP
15:04:31.384320 IP 100.64.6.115.48073 > 100.64.6.114.bgp: Flags [P.], seq 2332643319:2332643338, ack 3634880599, win 22, options [nop,nop,TS val 133847 ecr 406104254], length 19: BGP
15:04:31.389191 IP 100.64.6.114.bgp > 100.64.6.115.48073: Flags [.], ack 19, win 211, options [nop,nop,TS val 406117730 ecr 133847], length 0
15:04:33.633611 IP6 2a03:2260:0:35d::1.50266 > 2a03:2260:0:35d::2.bgp: Flags [S], seq 2879858318, win 26800, options [mss 1340,sackOK,TS val 406118291 ecr 0,nop,wscale 7], length 0
15:04:33.664703 IP6 2a03:2260:0:35d::1.50266 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2393577900, win 210, options [nop,nop,TS val 406118299 ecr 134410], length 0
15:04:33.664827 IP6 2a03:2260:0:35d::1.50266 > 2a03:2260:0:35d::2.bgp: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406118299 ecr 134410], length 51: BGP
15:04:33.686343 IP6 2a03:2260:0:35d::1.50266 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2, win 210, options [nop,nop,TS val 406118304 ecr 134417], length 0
15:04:33.686494 IP6 2a03:2260:0:35d::1.50266 > 2a03:2260:0:35d::2.bgp: Flags [F.], seq 51, ack 2, win 210, options [nop,nop,TS val 406118305 ecr 134417], length 0
15:04:37.473727 IP6 2a03:2260:0:35d::1.50338 > 2a03:2260:0:35d::2.bgp: Flags [S], seq 1750007639, win 26800, options [mss 1340,sackOK,TS val 406119251 ecr 0,nop,wscale 7], length 0
15:04:37.493097 IP6 2a03:2260:0:35d::1.50338 > 2a03:2260:0:35d::2.bgp: Flags [.], ack 2202354983, win 210, options [nop,nop,TS val 406119256 ecr 135370], length 0
15:04:37.493117 IP6 2a03:2260:0:35d::1.50338 > 2a03:2260:0:35d::2.bgp: Flags [P.], seq 0:51, ack 1, win 210, options [nop,nop,TS val 406119256 ecr 135370], length 51: BGP

takt · 28. März 2017 um 13:05

Okay, unsere Pakete kommen also zu dir. Allerdings sehe ich keine Antwort?

stefan6 · 28. März 2017 um 13:06

Jo, und das wundert mich.
Siehst du mögliche Ansatzpuntke was wir mal checken könnten? Was mich wundert, das es bei 2 Servern auftritt.

Edit: Die einzige BGP die UP ist, ist zu BER-a, keine Ahnung warum.

15:19:10.580051 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 129
15:19:10.792806 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 99
15:19:11.016833 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148
15:19:11.479526 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148
15:19:12.364519 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148
15:19:14.156865 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148
15:19:17.749596 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148
15:19:24.941878 IP6 2a03:2260::3 > 2a03:2260:0:35d::2: ICMP6, time exceeded in-transit for 2a03:2260:0:35d::1, length 148

takt · 28. März 2017 um 13:25

Schwer zu sagen was das ist.
Wir können gerne heute Abend mal zusammen auf eure Server schauen.
Bin ab ca. 19:30 CEST zuhause.

stefan6 · 28. März 2017 um 13:27

Ja, können wir gerne machen. Ich hau dich nachher im XMPP an
Ich bin langsam echt überfragt.

stefan6 · 28. März 2017 um 13:42

Mir ist gerade noch aufgefallen, der Kram tritt auch so auf dem anderen Gateway auf:

15:41:44.676085 IP6 2a03:2260::3 > 2a03:2260:0:356::2: ICMP6, time exceeded in-transit for 2a03:2260:0:356::1, length 129
15:41:44.906943 IP6 2a03:2260::3 > 2a03:2260:0:356::2: ICMP6, time exceeded in-transit for 2a03:2260:0:356::1, length 99
15:41:45.123632 IP6 2a03:2260::3 > 2a03:2260:0:356::2: ICMP6, time exceeded in-transit for 2a03:2260:0:356::1, length 129

Wir haben nur in der letzten Woche mittels apt Updates ausgeführt. Bird ist auf Version 1.4.5

Zumpel · 28. März 2017 um 14:30

Moin, ist die Kiste mit Proxmox virtualisiert und irgendwer hat die FW angeschaltet?!
Hatte ein ähnliches Verhalten… man muss auf dem VM Host ggf. nen modul nachschieben
nf_conntrack_gre oder so. Zum Testen als erstes die FW bei Proxmox komplett deaktivieren. dann siehste ob es daran liegt. danach kannst du das modul laden, sie wieder aktivieren… alles aber halt wie gesagt nur wenn du den gleichen fehler hast den wir hatten…

adorfer · 28. März 2017 um 15:03

Ich sehe in unseren Logs nichts dergleichen.

Der einzige, der heute zwei kurz gezuckt hat, aber das auch nur in den letzten Stunden (ab 13h)

stefan6 · 28. März 2017 um 15:22

Hi,

es ist ein KVM Host.
Offloading und so ein Kram ist aus