Wie du unter http://ffrl.de/ sehen kannst gibt es bei uns keinen Trafficeinbruch.
Geändert wurde am Backbone ebenfalls nichts.
Dazu kommt dass du (bisher) der einzige mit dem Problem bist.
Ich tippe daher auf Probleme direkt vor deiner Haustür.
ip r s t 42 default via 100.64.6.112 dev gre-ffrl-fra-a proto bird src 10.18.1.5
unreachable 10.18.0.0/16 proto bird src 10.18.1.5
10.18.1.1 via 10.18.248.6 dev bb-test01 proto bird src 10.18.1.5
10.18.1.3 via 10.18.248.16 dev bb-lkst01 proto bird src 10.18.1.5
10.18.1.4 via 10.18.248.4 dev bb-os01 proto bird src 10.18.1.5
10.18.1.5 dev lo proto bird src 10.18.1.5
10.18.1.6 via 10.18.248.8 dev bb-vec01 proto bird src 10.18.1.5
10.18.1.7 via 10.18.248.10 dev bb-bra01 proto bird src 10.18.1.5
10.18.1.8 via 10.18.248.12 dev bb-wtm01 proto bird src 10.18.1.5
10.18.1.9 via 10.18.248.14 dev bb-noh01 proto bird src 10.18.1.5
10.18.128.0/21 via 10.18.248.16 dev bb-lkst01 proto bird src 10.18.1.5
10.18.136.0/21 via 10.18.248.6 dev bb-test01 proto bird src 10.18.1.5
10.18.144.0/21 via 10.18.248.4 dev bb-os01 proto bird src 10.18.1.5
10.18.152.0/21 dev bat-stadtol proto bird src 10.18.1.5
10.18.160.0/21 via 10.18.248.8 dev bb-vec01 proto bird src 10.18.1.5
10.18.168.0/21 via 10.18.248.8 dev bb-vec01 proto bird src 10.18.1.5
10.18.176.0/21 via 10.18.248.10 dev bb-bra01 proto bird src 10.18.1.5
10.18.184.0/21 via 10.18.248.12 dev bb-wtm01 proto bird src 10.18.1.5
10.18.192.0/21 via 10.18.248.14 dev bb-noh01 proto bird src 10.18.1.5
10.18.248.2/31 via 10.18.248.6 dev bb-test01 proto bird src 10.18.1.5
10.18.248.4/31 dev bb-os01 proto bird src 10.18.1.5
10.18.248.6/31 dev bb-test01 proto bird src 10.18.1.5
10.18.248.8/31 dev bb-vec01 proto bird src 10.18.1.5
10.18.248.10/31 dev bb-bra01 proto bird src 10.18.1.5
10.18.248.12/31 dev bb-wtm01 proto bird src 10.18.1.5
10.18.248.14/31 dev bb-noh01 proto bird src 10.18.1.5
10.18.248.16/31 dev bb-lkst01 proto bird src 10.18.1.5
10.207.0.0/16 dev icvpn proto bird src 10.18.1.5
100.64.4.188 dev gre-ffrl-ber-a proto bird src 10.18.1.5
100.64.4.190 dev gre-ffrl-dus-a proto bird src 10.18.1.5
100.64.4.192 dev gre-ffrl-ber-b proto bird src 10.18.1.5
100.64.4.194 dev gre-ffrl-dus-b proto bird src 10.18.1.5
100.64.6.112 dev gre-ffrl-fra-a proto bird src 10.18.1.5
100.64.6.114 dev gre-ffrl-fra-b proto bird src 10.18.1.5
185.66.195.3 dev lo proto bird src 10.18.1.5
ip rule 0: from all lookup local
10: from all to 10.18.0.0/16 lookup 42
10: from 10.18.0.0/16 lookup 42
100: from all iif lo lookup main
101: from all iif lo lookup default
1000: from all lookup 42
1001: from all unreachable
32766: from all lookup main
32767: from all lookup default
Die 10.18.1.5 ist die IP des Serves intern.
Wir routen zwischen den Servern, damit nicht jeder einen Exit braucht. Bis um 20 Uhr ging es Problemlos, da hatten wir einen Reboot durchgeführt.
Am System ist von uns nichts geändert worden.
Der Traffic geht ja durch, nur kriechend…
Wir hatten das schon mal, dass V4 nur noch zäh lief. Da war die NAT-Tabelle (conntrac-Modul) vollgelaufen. Das sollte aber nicht kurz nach einem reboot sein oder durch einen behoben werden (Reihenfolge der Handlungen ist mir gerade nicht ganz klar.).
Das nur so als Erfahrungstipp von der Seite eingeworfen.
soifz …so langsam wird es echt mal Zeit eine Petition gegen Implementierung von Offloading zu starten… oder zumindest eine Opt-In Policy … Ich glaube da wären so ein paar Leute direkt mal mit vorne dabei, gell @takt ?
Im Vorfeld könnte man mal eine Erhebung machen, ob mehr (echte) Hardware als Netzwerk-Endgerät/-punkt oder als Router/Bridge/Hypervisor eingesetzt wird… Ich glaube schon fast, dass der Großteil der Pakete heutzutage von den echten Netzwerkkarten eher intern über irgendwelche SDN-Konstrukte geforwarded wird und daher man GSO/TSO/etc auf diesen Systemen abschalten will/wird …
Gibt es abgesehen von dem generellen Rant und dass es nicht mit dem FFRL-Backbone zu tun haben scheint eine konkrete Handlungsempfehlung. „TCP-Offloading bei XEN-GPL-Windows-Drv ist defekt.“ und „TCP-Offloading bei 10G mit Linuxkerneln ist Glücksspiel“ dürfte bekannt sein.
Aber das ist hier vermutlich beides nicht das Szenario.