Backbone v4 Probleme?

Hey @takt @ThomasDOTwtf

habt ihr grade extreme Probleme mit v4 Traffic? Über unseren Hetzner Host gehen keine 10kbit/s mehr weg.

Getestet via FRA und BER:

130 root@ol01 ~ # traceroute -s 10.18.152.1 srv01.ffnw.de :frowning: traceroute to srv01.ffnw.de (37.120.176.207), 30 hops max, 60 byte packets
1 * * *
2 gw-decix.ffm.netcup.net (80.81.193.182) 20.514 ms 20.648 ms 20.601 ms
3 srv01.ffnw.de (37.120.176.207) 20.532 ms 20.901 ms 20.863 ms
root@ol01 ~ #

Hallo Stefan,

ich kann keine generellen Probleme feststellen.
Von unserem (Möhne) Hetzner Gateway bekomm ich 80MB/s> durch.

:~# wget --bind-address 185.66.193.16 -O /dev/null http://ftp.de.debian.org/debian-cd/8.5.0/amd64/iso-cd/debian-8.5.0-amd64-netinst.iso
--2016-07-21 20:52:40--  http://ftp.de.debian.org/debian-cd/8.5.0/amd64/iso-cd/debian-8.5.0-amd64-netinst.iso
Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4
Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 258998272 (247M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

/dev/null                                         100%[=============================================================================================================>] 247.00M  85.5MB/s   in 2.9s   

2016-07-21 20:52:43 (85.5 MB/s) - ‘/dev/null’ saved [258998272/258998272]

Welches Ziel möchtest du erreichen? Von welchem eurer Gateways probierst du es genau? IPv4/IPv6?

Viele Grüße,
Lars

Hi Lars,

es ist egal, welches Ziel ich nutze.
Es geht um unseren Host 5.9.56.26

Ohne Tunnel gehen auch >70mb/s durch.
Am Server wurde nichts geändert, daher kann es an uns nicht liegen.

Im Trace sieht du ja eure tunnelseite nicht mal…

Der Aufbau zum Server dauert auch schon mind. 20 Sek
root@ol01 ~ # wget --bind-address 185.66.195.3 -O /dev/null http://ftp.de.debian.org/debian-cd/8.5.0/amd64/iso-cd/debian-8.5.0-amd64-netinst.iso
–2016-07-21 21:14:23-- http://ftp.de.debian.org/debian-cd/8.5.0/amd64/iso-cd/debian-8.5.0-amd64-netinst.iso
Auflösen des Hostnamen »ftp.de.debian.org (ftp.de.debian.org)«… 141.76.2.4
Verbindungsaufbau zu ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80…

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.

Hallo Stefan,

kann es sein das ihr versehentlich die externe IP nicht mehr auf dem Loopback konfiguriert habt oder euer Policy Routing nicht passt?

Ich kann die externe IP die ihr auf dem Host benutzt gar nicht pingen bzw. ihr antwortet mir nicht obwohl die Pakete in den Tunnel gehen:

bb-a:~$ sudo tcpdump -i tun-ffnw-srv12 host 144.76.18.174 -n
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
22:38:58.288575 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 16257, length 44
22:38:58.743713 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 17537, length 44
22:38:58.834808 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 17793, length 44
22:38:58.926137 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 18049, length 44
22:38:59.016896 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 18305, length 44
22:38:59.107900 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 18561, length 44
22:38:59.198994 IP 144.76.18.174 > 185.66.195.3: ICMP echo request, id 29459, seq 18817, length 44

Viele Grüße,
Lars

1 „Gefällt mir“

Hi Lars,

die NAT IP war bei uns noch nie pingbar obwohl diese auf lo liegt. Routing tables sehen auch korrekt aus.

Wie sehen denn die BGP Sessions aus?

Sollten sie aber sein.

Definiere korrekt. Zeig sie uns doch einfach mal.
ip rules wären auch hilfreich.

Die Frage kannst du dir selber beantworten.

Hey,

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 NAT IP liegt auf dem Iface lo

default via 100.64.6.112 dev gre-ffrl-fra-a proto bird src 10.18.1.5

Wer oder was ist 10.18.1.5 und warum steht es als src-address an der route?

Mein Bird macht sogar nicht:

vpn01.paderborn.freifunk.net:~# ip r s t 42 | grep defa
default via 100.64.0.234 dev gre_ffrl_fra_a proto bird

Davon ab gehen über den Tunnel zu Euch (mit der 100.64.6.112) einige MBit/s:

average 7.76 Mbit/s | 25.74 Mbit/s

Darin sowohl v4 (getNATed) als auch v6.

Ich gehe da mit Oli und Lars mit und prophezeie, dass das Problem nicht im Backbone liegt.

VG
Max

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…

Soll ich lachen oder weinen?
Da war doch wohl was nich reboot safe.

2 „Gefällt mir“

Wenn ich darüber lachen könnte wäre mir auch lieber :smiley:
Mittlerweile werden unsere Server js mit Puppet deployed und wir greifen hier gsr nicht mehr ein.

Die Configs sind identisch zu unseren anderen Servern.
Nur das der Host eben bei Hetzner steht

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.

1 „Gefällt mir“

Was sagt denn

dmesg
?

Check mal deine offloader settings.

Hey,

dmesg sagt nichts in diese Richtung.
Den Tipp mit dem Offloading testen wie mal.

Es war tatsächlich das offloading der Maschine.

Vielen Dank für eure Hilfe! :blush:

soifz …so langsam wird es echt mal Zeit eine Petition gegen Implementierung von Offloading zu starten… :wink: oder zumindest eine Opt-In Policy … :wink: Ich glaube da wären so ein paar Leute direkt mal mit vorne dabei, gell @takt ? :wink:

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 …

1 „Gefällt mir“

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.

(Mod darf das hier gern abtrennen/verschieben)

1 „Gefällt mir“

Bis auf Checksum offloading sollte bei einer Maschine die Pakete forwarded alles abgeschaltet werden. Unabhaenging ob das nun 1G oder 10G NICs sind.

3 „Gefällt mir“