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
Könnt ihr einschätzen bis wann das Wartungsfenster andauern wird?
Ich gehe mal davon aus, das ihr voll dabei seit.
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.
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
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
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.
Es gibt gute und schlechte Neuigkeiten.
bb-a.ak.ber.de.ffrl.de lebt wieder! 
bb-b.ak.ber.de.ffrl.de ist tot! 
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
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.
Wir werden das Problem heute abend weiter untersuchen.
Idee sind natürlich willkommen
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
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.
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.
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
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:
VG
takt
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ß
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.
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
Moin moin Freifunkas,
gute Neuigkeiten!
Daraus folgt => Nur noch in DUS läuft Quagga und ich muss dringend ins Bett.
takt
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
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
Inwieweit hat das denn eine höhere Belastung des Prozessors zur Folge?
Oder ist das kaum merkbar?
Ich sag mal so viel: Der Treiber in Linux 3.10 hatte dieses Feature ueberhaupt nicht.
Und im Prinzip wollen wir das garnicht haben. GRO fuehrt mehrere Pakete, die beispielsweise zu einem TCP Datenstrom gehoeren, zu einem grossen zuammen um dem TCP einen grossen Haufen Daten abliefern zu koennen. Das spart natuerlich Overhead. Allerdings tritt dieser Overhead bei uns garnicht auf, da die allermeisten Pakete garnicht fuer den Router selber bestimmt sind. Sie werden geforwardet. Dabei fuehrt GRO zu ungewuenschter Latenz. Daher kann man die Zusatzbelastung wohl als marginal bezeichnen.
VG
takt