[Berlin-wireless] Routen loop
Marco Tidow
martidow
Sa Mär 31 11:49:32 CEST 2007
On Sat, Mar.24. 23:23 +0100, Joern wrote:
> Moin
> am Wochenende gab es hier in der Gegend Grünberger Strasse/Comenius Platz
> ein paar Knotenausfälle. Als Resultat ergaben sich ungewöhnliche Routen
> und ab einem bestimmten Zeitpunkt ein Routen-Loop:
>
> Routenverfolgung zu nf-in-f99.google.com [64.233.183.99] über maximal 30
> Abschnitte:
>
> 1 1 ms 1 ms 1 ms 192.168.0.1
> 2 2 ms 2 ms 2 ms 192.168.1.1
> 3 4 ms 4 ms 3 ms wrt54gs_torell.olsr [104.129.25.30]
> 4 8 ms 15 ms 6 ms 104.129.1.9
> [...]
> 21 32 ms 43 ms 43 ms wrt54gs_torell.olsr [104.129.25.30]
> 22 35 ms 82 ms 109 ms 104.129.1.9
>
> Ich hätte gedacht dass so etwas im Protokoll erkannt wird?
Hallo Jörn,
ich vermute, die ausgefallene node war kein FF-firmware-router?
eine mögliche ursache für dieses bild stellen nicht-FFF-olsr-nodes dar.
es hat zunächst den anschein, als würde das host-routing laufen,
aber in wirklichkeit nehmen packets umwege, und wenn ein bestimmter node
ausfällt, tritt der eigentliche fehler sichtbar zu tage.
folgendes betrifft sowohl self-made olsr-router, die auf linux- als auch
auf m$-windows basieren, sowie andere fertig-router im 104er-netz.
also auch unvollständig konfigurierte laptops...
knackpunkt ist, ob ein IP-interface auf eine 104er IP konfiguriert ist.
anzeichen dafür sind ICMP-redirect-packets dieser nodes, die u.a. besagen
"hey, Du schickst mir packets für eine IP, die Du doch direkt erreichen können
solltest, weil sie im gleichen netz-segment wie Deine absender- und meine
empfänger-IP liegt, also sende Deine packets gefälligst direkt dorthin"
also, die buggy 104er-node guckt die <dest-IP> eines empfangenen packets an,
macht dafür einen lookup in ihrer vom olsrd gefüllten routing-table, findet
einen weiteren 104er-nachbarn als <next-hop-IP>, meint, die sei im selbem
subnet (104.0.0.0/8) wie der absender (genauer: sieht, daß das forward´d packet
über dasselbe interface wieder rausgehen würde), und schickt dem absender pro
tcp-packet (!!!) ein icmp-redirect retour.
analoges gilt auch für non-olsr IP-router mit 104er-adresse.
(vergl. http://iptables-tutorial.frozentux.net/iptables-tutorial.html#REDIRECT)
beispiel tcpdump (absichtlich fehl-konfiguriertes test-szenario):
IP 104.136.12.12 > 104.136.12.6: icmp 116: redirect 104.136.12.30 to host 104.136.12.9
dieses extra icmp-packet verschickt der "buggy"-router 104.136.12.12 bei
_jedem_ tcp-packet von oder zu node 104.136.12.6, nicht grade effizient.
diese icmp-redirects haben in einem host-routing netz nichts zu suchen !!!
so "reagieren" IP-stacks per default, forwarden das auslösende IP-packet
zwar, erzeugen aber unnötigen extra traffic. ist der absender seinerseits
nicht "immunisiert" gegen icmp-redirects, probiert er ab da packets anstatt
zur vom lokalen routing-daemon bestimmten <next-hop-IP> eben
direkt an die <dest-IP> zu senden, was funktionieren kann (wenn die dest-IP
in reichweite liegt).
ignoriert der absender dagegen den icmp-redirect, wiederholt sich genau der
gleiche ablauf wieder. deshalb sieht man die sich wieder-
holenden zeilen im traceroute:
> 3 4 ms 4 ms 3 ms wrt54gs_torell.olsr [104.129.25.30]
> 4 8 ms 15 ms 6 ms 104.129.1.9
vermutung: die 104.129.1.9 ist kein FFF-router?
für hop-zu-hop host-routing ist dieses verhalten natürlich unpassend.
während mit der FFF betriebene router solche ICMP-redirects ignorieren,
_forwarden_ sie diese aber weiter an andere 104er-nodes.
als folge fällt es nicht unbedingt sofort auf, daß solche icmp-redirects
unterwegs sind, wenn wie oben geschildert, die <dest-IP> normalerweise vom
hop _vor_ dem buggy node auch direkt erreichbar ist, und der "vor-hop"
nicht immunisiert ist, also auf die redirects mit direktem zustellversuch
reagiert und antwort von der <dest-IP> erhält.
typisches szenario hierfür sind mehrere laptops (egal ob linux oder windows)
mit selfmade-setups + olsrd in direktem funk-kontakt
(ich sage nur c-base)
obwohl der eigentliche fehler nicht in der FF-firmware liegt, erschwert deren
forwarding von icmp-redirect-packets manchmal, solche fehl-konfigs schneller
zu bemerken, fällt ein node zuviel aus, tritt der fehler ggfs. erst später
offensichtlich zu tage.
IMO eine schwäche im freifunk-netz, gegen die es keine entgültige abhilfe
gibt.
self-made linux und windows router lassen sich entsprechend korrigieren; bei
black-box IP-routern (access-point-router) hilft nur, ihnen _keine_ 104er-IP
auf irgendweinem interface (WAN,LAN) zuzuweisen, sonst krachts.
in eng-räumigen olsr-dramen a la c-base hilft dagegen wohl nur monitoring
der luft nach absendern der besagten icmp-redirects.
eine idee am rande: man könnte per ipt_recent module solche redirects detektieren,
und eine automatische blackhole-vermeidung per implementieren, dann braucht man
nur diese recent-table im web-interface abfragbar zu machen und sieht
die buggy-nodes in der nachbarschaft sofort... weil die meisten ja doch zu faul
sind, ihre eigenen setups zu monitoren ;-)
zum automatischen reset nachdem das problem behoben wurde, prüft man umgekehrt
pro empfangenem olsr-packet, ob der absender in der REDIRECT_BUG table enthalten
ist und keine icmp-redirects seit einem bestimmten intervall von ihm weiter
aufgetaucht sind.
ohne runtime-interface, mit dem sich LQ´s zu diesem zweck fein-justieren liessen
(was es leider derzeit im olsrd nicht gibt), so daß buggy-nodes nur zu seiten-ästen
im routing herabstufbar wären, bleibt aber derzeit allein der weg, durch DROP´n
aller olsr-packets vom buggy-node diesen _komplett_ aus dem olsr-net auszuschließen.
:-(
oder, jedesmal den olsrd mit aktualisierter ff_lqmult neu zustarten, was auch
sehr störend wäre.
comments?
Gruß, marco
P.S.
der eigentliche fix für self-made configs sieht unter linux IMO so aus,
abgesehen von korrekten forwarding-rules der iptables-filter und einschalten
des forwardings als kleine nebensächlichkeiten ;-) :
[...]
ipv4set() { echo "$1" > /proc/sys/net/ipv4/"$2" 2>/dev/null; }
# per default, no icmp-redirects; olsrd will disable per iface too ("but on wrt that is not enough")
ipv4set "0" conf/all/send_redirects
# per interface config
# *_DEVS : e.g. WORLD_DEVS="eth1 wlan0"
# INT_DEVS : LAN or DMZ, devices on internal networks
# WORLD_DEVS : devices on public (olsr) networks
for DEV in ${INT_DEVS} ${WORLD_DEVS} "lo"; do
if [ -f "/proc/sys/net/ipv4/conf/${DEV}" ]; then
#: ignore redirects
ipv4set "0" "conf/${DEV}/accept_redirects" # default 0
#: do not send redirects
ipv4set "0" "conf/${DEV}/send_redirects" # disabled by olsrd per interface, too
#: accept icmp only for gateways listed in default gw list
ipv4set "1" "conf/${DEV}/secure_redirects" # was 0
#: s.a. shared_media
#: log packets not matching iface address
ipv4set "1" "conf/${DEV}/log_martians"
[...]
fi
done
[...]
#: in-case this script is run after startup of olsrd, restore settings done by olsrd at least for interfaces bound to
OLSR_ACTIVE_CFGFILE="$(/bin/ps ax |/bin/sed -n '/olsrd/ { /sed/n;s/^.* -f \+//;s/ .*$//;p; }')"
OLSR_DEVS=''
if [ -n "${OLSR_ACTIVE_CFGFILE}" ]; then
OLSR_DEVS="$(/bin/sed -n '/^ *Interface */ {s/^ *Interface *//;s/"//g;p;}' "${OLSR_ACTIVE_CFGFILE}")"
for DEV in ${OLSR_DEVS}; do
if [ -f "/proc/sys/net/ipv4/conf/${DEV}" ]; then
# log "$0 : found olsrd device : ${DEV} ; setting rp_filter=0 + send_redirects=0"
ipv4set "0" "conf/${DEV}/rp_filter"
ipv4set "0" "conf/${DEV}/send_redirects"
fi
done
fi
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
Mehr Informationen über die Mailingliste Berlin