ich sehe hier gerade das ich im FF Rheinland gerade ziemlich viele ICMP Redirects bekomme und das teilweise der Rechner von außen per V6 nicht direkt beim ersten mal erreichbar ist (ssh)
alpha ~]$ ping www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=246 time=102 ms
From 10.53.96.1 icmp_seq=1 Redirect HostFrom 10.53.96.1: icmp_seq=1 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1: icmp_seq=2 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=2 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=246 time=92.4 ms
From 10.53.96.1: icmp_seq=3 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=3 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=246 time=42.5 ms
From 10.53.96.1: icmp_seq=4 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=4 Redirect HostFrom 10.53.96.1: icmp_seq=5 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=5 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=5 ttl=246 time=52.8 ms
From 10.53.96.1: icmp_seq=6 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=6 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=6 ttl=246 time=47.1 ms
From 10.53.96.1 icmp_seq=7 Redirect HostFrom 10.53.96.1: icmp_seq=7 Redirect Host(New nexthop: 10.53.72.1)
64 bytes from www.heise.de (193.99.144.85): icmp_seq=7 ttl=246 time=64.8 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=8 ttl=246 time=75.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=9 ttl=246 time=108 ms
From 10.53.96.1: icmp_seq=10 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=10 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=10 ttl=246 time=45.8 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=11 ttl=246 time=45.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=12 ttl=246 time=43.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=13 ttl=246 time=49.4 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=14 ttl=246 time=48.8 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=15 ttl=246 time=46.9 ms
From 10.53.96.1: icmp_seq=16 Redirect Host(New nexthop: 10.53.72.1)
From 10.53.96.1 icmp_seq=16 Redirect Host64 bytes from www.heise.de (193.99.144.85): icmp_seq=16 ttl=246 time=64.2 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=17 ttl=246 time=74.3 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=18 ttl=246 time=47.2 ms
Dabei kommt es auch vor, das einige pakete verlustig sind.
Das eine muss aber nichts mit dem anderen zu tun haben.
Redirects werden gesendet, wenn mehr als ein Router im lokalen Netz sind und der Router, an den Dein Rechner die Packete an eine Zieladresse sendet, ein anderes Bild vom Netzwerk hat als Dein Rechner.
Im Prinzip sagt der Router mit dem ICMP Redirect ‚sende die Packete, die für Rechner xyz sind an den Rotuer mit der Adresse ABC, da dieser einen besseren Weg zum Ziel kennt, als ich‘. Das Gehoert zum IP Protokoll und kommt immer vor, wenn die Endgeräte kein aktives Routingprotokol benutzen, sondern einen Default Router konfiguriert haben, und -wie gesagt- mehr als ein Router im Netz ist. Packetverluste können vorkommen, sind aber nicht automatisch die Folge von Redirects, da der Router, der das Redirect sendet, gleichzeitig das Packet, das er empfangen hat, and den ‚besseren‘ Router weiterleitet.
Wenn dein Rechner die Aufforderung akzeptiert wendet er sich an den richtigen Router und du bekommt keine redirect Pakete mehr.
Ich vermute dass dein Rechner diese einfach nicht akzeptiert.
Interessant ist jedoch dass du diese Pakete ueberhaupt bekommst.
Jede Supernode sollte selber nur eine default route haben und die Pakete einfach dort hin weiterleiten.
In welcher Domaene bist du?
Rheinufer?
Moehne?
Ruhrgebiet?
das ist mal ein guter Tipp. ipv4 all (für alle Interface) ist accept redirect aus.
Allerdings ist es für alle einzel Interface eingeschaltet.
Sowieso für IPv6. OS ist ein ein CentOS 7.1
Aktuell ist es schon verwunderlich.
Zumal ich das Verhalten gerade mit meinem Mac verglichen habe und da dieses verhalten nicht nachvollziehen können.
In diesem Sinne werde ich mal ein wenig weiter Forschen.
Wenn ich mich recht erinnere, werden icmp redirects vom Ping ignoriert, daher vielleicht die vielen redirects.
Wie sieht es denn aus, wenn du einen Webserver mehrfach ansprichst, z.B. beim surfen?
Dann sollte nur ein redirect kommen, und dein Rechner die weiteren Requests and den ‚besseren‘ Router weiterleiten.
Ich kann zumindest zum Hintergrund der beiden IP Adressen etwas sagen.
Die 10.53.96.1 ist eine „normale Supernode“, während die 10.53.72.1 eine Supernode mit GRE Tunnel ins Rheinland Backbone ist.
Jede Supernode announced sich erstmal selber als IPv4 Gateway an den Client, allerdings ist durch die Layer2 Struktur natürlich aus IP-Sicht auch jede andere Supernode dank batman unmittelbar erreichbar, auch wenn es im Layer2 eigentlich nicht so ist.
Auf allen Supernodes läuft BGP, das ganze Netz ist dynamisch geroutet.
Erst einmal es waren auf dem Router einige Fehler im Kernel log erfasst (dmesg)
Dies waren aber nicht soviele, das ich mir diese genauer angesehen (notiert) habe.
Als nächstes habe ich versucht die Lokalen IPs des Routers zu Pingen. Ja, mir ist bewusst, das Ping keine gute methode ist aber besser als nichts
Fakt ist das ich hier auf der Wlan Strecke teilweise massive Paket los hatte, die sich natürlich dann auch bei den Supernodes gezeigt hat.
Soweit so gut.
Nach etlichen Reboots ist die Paket loss nun auch einem geringen wert (je nachdem halt).
Die Bandbreite ist aktuell allerdings nicht gerade rosig aber das mag auch an der Abendstunde liegen. (6 mbit/s down, 7,5 mbit/sec up)
Ich werde das verhalten einmal in den nächsten Tagen beobachten und schauen was passiert.
Prinzipiell ist das verhalten aber mit mehreren Clients aufgetreten und ich konzentriere mich deshalb nun auf den neuen „1043 v2.1“.
Alles im allen bin ich mit der Situation aber alles andere als zufrieden. Den der neue Router sollte eigentlich eine Abhilfe schaffen und nicht für „staled“ ssh connections sorgen.
