Wartungsankuendigung 22. September

Freifunk Rheinland e.V. Rheinland Backbone
1

Hallo Community,

wir moechten hiermit ankuendigen dass @thomasDOTwtf und ich heute Abend Wartungsarbeiten an allen Backbone Standorten durchfuehren werden.
Konkret werden nacheinander alle BGP Sitzungen fuer ein paar Minuten verschwinden. Bevor wir diese Arbeiten durchfuehren werden wir alle Tunnel und BGP Sitzungen auf der bb-a.ak.ber.de wiederherstellen sodass jede Community ueber Tunnel zu mindestens 2 verschiedenen Routern verfuegen sollte.

Grund dafuer ist, dass wir Quagga durch Bird abloesen werden.
Dies geschieht weil Quagga nun mehrfach fuer blackholes im Netzwerk gesorgt hat, indem die aktuellen Routing Informationen nicht in die Kernel Routing Table eingetragen wurden. Ausserdem koennen wir mit Bird die Bereitstellung von BGP Siztungen einfacher automatisieren.

VG
takt

14 „Gefällt mir“
2

Moin,
danke, dass ihr euch da so reinhängt. Gerade hat es auch für einige Stunden keine Internetanbindung in der Fichte gehabt, hängt das zusammen?

LG JJX

3

Ohne das mit Sicherheit sagen zu koennen: Eine ganze Menge Verbindungen wurden kuerzlich in Frankfurt geblackholed. Vermutlich war das die Ursache fuer euren Ausfall!

Nachdem ich am Wochenende eine Bird Konfiguration vorbereitet habe, haben Thomas und ich soeben beschlossen die Migration nun zuegig zu vollziehen.
Fuer den Fall dass etwas schief geht bleibt die Quagga config natuerlich vorerst erhalten. Fuer den Fall der Faelle…

VG
takt

1 „Gefällt mir“
4

Könnt ihr einschätzen bis wann das Wartungsfenster andauern wird?
Ich gehe mal davon aus, das ihr voll dabei seit.

5

Wir sind voll dabei und haben Probleme mit den Treibern der neuen 10G NICs in Berlin.
Aktuell ist Berlin komplett trocken gelegt. Dort fließt kein Traffic.
Unklar ob wir heute Nacht alles migriert bekommen werden.

6

hmm hört sich ja nicht so dolle an.
aktuell bekomme ich kein v4 paket durchs ff (aus dem ruhrgebiet) geschoben.

Dann mal noch viel glück

7

Gibt eine Route dort hin:
bb-a.fra3.fra.de.ffrl.de# show ipv6 route 2a03:2260:50::
Routing entry for 2a03:2260:50::/44
Known via „bgp“, distance 20, metric 0, best
Last update 2d01h27m ago

  • fe80::200:5efe:9750:40ba, via tun-ffrg2-4

bb-a.fra3.fra.de.ffrl.de#
[takt@bb-a ~]$ ip -6 r g 2a03:2260:50::
2a03:2260:50:: from :: via fe80::200:5efe:9750:40ba dev tun-ffrg2-4 src 2a03:2260:0:32::1 metric 0
cache
[takt@bb-a ~]$

Keine Ahnung was die dann da hinter tun.
Am Backbone liegt es jedenfalls nicht.

8

Es gibt gute und schlechte Neuigkeiten.

bb-a.ak.ber.de.ffrl.de lebt wieder! :smile:
bb-b.ak.ber.de.ffrl.de ist tot! :frowning:

bb-a.ak.ber.de.ffrl.de läuft nun mit Bird und terminiert wieder Tunnel. Die bb-b.ak.ber.de.ffrl.de hat scheinbar eine defekte SD Karte. Diese wird zeitnah durch eine Festplatte ersetzt.

Die Router in DUS und FRA wurden heute entgegen aller Planung nicht angerührt. Allerdings haben wir bird installiert und mit Basiskonfiguration sowie der Config für die Upstreams versehen. Morgen werden wir mittels eines Skripts die BGP neighbor Configs aus der aktuellen Quagga Config erzeugen und nach und nach Quagga stoppen und Bird starten.

Bitte entschuldigt die Unannehmlichkeiten.

VG
takt

13 „Gefällt mir“
9

Zwischenzeitlich ein kurzes Update zum Status am Standort Berlin.
Unsere neu verbauten 10GE NICs (HP NC522SFP) bereiten uns einigen Ärger.
Der Link der Karten geht unvermittelt verloren und der Treiber erzeugt Stress.

Für Interessierte hier mal eine dmesg-Ausgabe dazu.
https://www.irccloud.com/pastebin/raw/nir3eBYQ

Wir haben bereits die Kernel auf die Version 4.1.X angehoben.
Folgende ethtool-Konfiguration wurde durchgeführt:

ethtool -K ens2f1 rx off
ethtool -K ens2f1 tx off
ethtool -K ens2f1 gro off
ethtool -K ens2f1 gso off
ethtool -K ens2f1 tso off
ethtool -K ens2f1 sg off

Die Firmware der NICs ist auf dem vorletzten Stand.
Hier sind lediglich noch Fixes für den promiscous mode und Win2012 dazu gekommen.

Das BIOS der Server ist auf Static High Performance konfiguriert.
Es könnte noch ein BIOS-Update durchgeführt werden.

Heute morgen hat sich dann eine kpanic ausgehend vom Treiber für die onBoard-NICs (tg3) ereignet.
Darauf hin haben wir beide Systeme am Standort Berlin abgeschlatet um Falpping zu vermeiden.

ilo.png1033×843 29 KB
ilo_bb-a_150920.png732×479 31.8 KB

Wir werden das Problem heute abend weiter untersuchen.
Idee sind natürlich willkommen :smile:

1 „Gefällt mir“
10

Das Problem mit den Karten ist mir nur zu gut bekannt, eine richtige Lösung kenne ich auch nicht.
Laut HP soll das Problem mit der aktuellsten Firmware gelöst sein. Zusätzlich sollen die Karten in bestimmte Slots oder die Lüfter auf „Enhanced Cooling“ gestellt werden.

Hat bei mir das Problem bei mehreren ESX-Hosts nur verringert, gelegentlich tritt es immer noch auf. Immerhin fangen sich die Karten nach ein paar Sekunden wieder.
Eine Intel X520-SR2 läuft bisher absolut unauffällig.

Sind zwar nicht wirklich gute Nachrichten, aber vielleicht hilft es trotzdem…

Grüße

1 „Gefällt mir“
11

Für mich hört sich das Problem sehr merkwürdig an.
Was ich mir vorstellen könnte ist, das die Karte entweder überhitzt oder in einem falschen Slot steckt.
Allerdings gibts da nicht so viel auswahl in einem DL320.

Falls ihr support für die Maschinen habt würde ich mal einen Support Case aufmachen.
Eigentlich können die Kollegen einem weiterhelfen.

1 „Gefällt mir“
12

Hallo zusammen,

die Karten sind gestern Abend gegen

Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0)

getauscht worden und laufen seitdem problemlos. In Berlin ist Quagga durch BIRD ersetzt.

1 „Gefällt mir“
13

Hallo Takt,

danke ersteinmal für die Mühe.

Kannst du vielleicht etwas dazu sagen warum das gesamte FF Netz ausgefallen war obwohl die Tunnel z.b. nach Düsseldorf aufgebaut wurden?

Gruß
Thomas

14

Hallo Thomas,

schwierig zu sagen was da im Argen war.
Da ich bisher aber nur von dir von Problemen gehört habe sollten folgende Dinge mal überprüft werden:

  1. Funktionieren alle Tunnel?
  2. Sind alle BGP Sitzungen established?
  3. Erhaltet ihr auf allen BGP Sitzungen eine default route und wird diese auch akzeptiert?
  4. Announced ihr eure IP Adressen auf allen BGP Sitzungen?

VG
takt

15

Hallo Takt,

wir benutzen BGP Sessions zum Ruhrgebiet welches dann bei euch angeklemmt ist.
Du hast nur nichts gehört weil wir eher nicht nerven wollen wenn da rumgeschraubt wird,
deshalb haben wir den kompletten Traffic einfach Lokal ausgeworfen bis es dann
irgendwann nach 23:~~Uhr wieder lief.

Gruß

16

Bei uns (Göttingen), sind diese Links ausgefallen:

link/gre 46.38.234.223 peer 185.66.194.1
inet 100.64.0.199/31 brd 255.255.255.255 scope global ffrl0

link/gre 46.38.234.223 peer 185.66.195.1
inet 100.64.0.201/31 brd 255.255.255.255 scope global ffrl1

Der erste ist seit ca. 24 Stunden wieder da, der zweite ist immer noch tot.

17

Ersterer ist in Frankfurt und war aus noch unklaren Gruenden kurzzeitig down, lebt aber wieder vollstaendig.

Letzterer laeuft in Berlin wo es wieder Probleme mit den NICs gibt.
10G Routing und Linux scheinen eine sehr schlechte Kombination zu sein.

Ich moechte daher ankuendigen, dass das Wartungsfenster heute nicht fuer Bird Migration genutzt werden kann, da die Router in Berlin erst stabil laufen muessen.
Aktuell stehen wir vor der Wahl am Treiber der NIC Aenderungen vorzunehmen oder zu FreeBSD zu migrieren. Eines von beidem wird heute Nacht stattfinden.

Ich hab die Faxen langsam echt dicke…

takt

5 „Gefällt mir“
18

Moin moin Freifunkas,

gute Neuigkeiten!

  1. bb-a.ak.ber.de läuft seit fast 5 Stunden mit Linux 4.3.0-rc3-taktpatch (Ich habe da mal am mlx4 Treiber gearbeitet)
  2. bb-b.ak.ber.de läuft seit mehr als 6 Stunden testweise mit einem Kernel von CentOS 7
  3. Quagga in FRA wurde durch Bird ersetzt

Daraus folgt => Nur noch in DUS läuft Quagga und ich muss dringend ins Bett.

takt

17 „Gefällt mir“
19

Hallo @takt,
vielen Dank für Deinen Einsatz.
Was hat der Treiber für ein Problem gehabt, wie hast Du es rausgefunden
und kann man Deine Änderungen im Git nachvollziehen?

Weiter so und Gruß!
Christian

20

Moin,

leider ist es kein echter fix den ich so an kernel.org senden wuerde.
Konkret habe ich den Code aus dem Treiber entfernt, welcher entscheidet, ob ein Paket fuer die Verarbeitung an die NIC offgeloadet werden kann oder nicht.

http://lxr.free-electrons.com/source/drivers/net/ethernet/mellanox/mlx4/en_rx.c#L871
Hier habe ich den folgenden Block entfernt:

        if (!mlx4_en_cq_busy_polling(cq) &&
                (dev->features & NETIF_F_GRO)) {
                    struct sk_buff *gro_skb = napi_get_frags(&cq->napi);
                    if (!gro_skb)
                            goto next;

                    nr = mlx4_en_complete_rx_desc(priv,
                            rx_desc, frags, gro_skb,
                            length);
                    if (!nr)
                            goto next;

                    if (ip_summed == CHECKSUM_COMPLETE) {
                            void *va = skb_frag_address(skb_shinfo(gro_skb)->frags);
                            if (check_csum(cqe, gro_skb, va,
                                           dev->features)) {
                                    ip_summed = CHECKSUM_NONE;
                                    ring->csum_none++;
                                    ring->csum_complete--;
                            }
                    }

                    skb_shinfo(gro_skb)->nr_frags = nr;
                    gro_skb->len = length;
                    gro_skb->data_len = length;
                    gro_skb->ip_summed = ip_summed;

                    if (l2_tunnel && ip_summed == CHECKSUM_UNNECESSARY)
                            gro_skb->csum_level = 1;

                    if ((cqe->vlan_my_qpn &
                        cpu_to_be32(MLX4_CQE_CVLAN_PRESENT_MASK)) &&
                        (dev->features & NETIF_F_HW_VLAN_CTAG_RX)) {
                            u16 vid = be16_to_cpu(cqe->sl_vid);

                            __vlan_hwaccel_put_tag(gro_skb, htons(ETH_P_8021Q), vid);
                    } else if ((be32_to_cpu(cqe->vlan_my_qpn) &
                              MLX4_CQE_SVLAN_PRESENT_MASK) &&
                             (dev->features & NETIF_F_HW_VLAN_STAG_RX)) {
                            __vlan_hwaccel_put_tag(gro_skb,
                                                   htons(ETH_P_8021AD),
                                                   be16_to_cpu(cqe->sl_vid));
                    }

                    if (dev->features & NETIF_F_RXHASH)
                            skb_set_hash(gro_skb,
                                         be32_to_cpu(cqe->immed_rss_invalid),
                                         (ip_summed == CHECKSUM_UNNECESSARY) ?
                                            PKT_HASH_TYPE_L4 :
                                            PKT_HASH_TYPE_L3);

                    skb_record_rx_queue(gro_skb, cq->ring);
                    skb_mark_napi_id(gro_skb, &cq->napi);

                    if (ring->hwtstamp_rx_filter == HWTSTAMP_FILTER_ALL) {
                            timestamp = mlx4_en_get_cqe_ts(cqe);
                            mlx4_en_fill_hwtstamps(mdev,
                                                   skb_hwtstamps(gro_skb),
                                                   timestamp);
                    }

                    napi_gro_frags(&cq->napi);
                    goto next;
            }

Dies fuehrt dazu dass kein Offloading mehr verwendet wird.
Uptime aktuell ueber 12h!

VG
takt

1 „Gefällt mir“