Linux routing - podivná záhada

Pavel Troller patrol na sinus.cz
Čtvrtek Červenec 30 21:00:59 CEST 2015


Zdravím,

> Pavel Troller <patrol na sinus.cz> [2015-07-30 17:33:08]:
> 
> > Ještě před měsícem to ten redirect opravdu mohlo dostat.
> > Garantuji, že nejméně týden už ho to nedostalo.
> 
> tcpump, nebo neverim :) A 'sysctl net.ipv4.conf.eth0.accept_redirects' rika co?

Verit nemusite, je mi jedno, zda verite a v co / koho :-) :-).
Obecne eth0 samozrejme redirecty akceptuje.

> 
> > A teď tedy sekundární otázka: Jak to z té cache vyženu ???
> 
> ip route cache flush
> ip nei flush all
> 
V tom je prave asi bug v tomto jadre. Vsechny tyto postupy se zdaji fungovat,
ale nefunguji! Cache na chvili "zmizi", ale pak se znovu postupne objevi se vsemi
"zamrzlymi" nesmysly presne tak, jako byla.

Ale vnuknul jste mi napad a uz mi chodi alespon 192.168.20.4 :-).
Rekl jsem routeru (x.x.x.126), aby mi poslal redirect na spravnou adresu
(x.x.x.8), kdyz mu prijde pozadavek na 192.168.20.4. A ted pozor,
juknete na tohle:

root na box:~# ping 192.168.20.4
PING 192.168.20.4 (192.168.20.4) 56(84) bytes of data.
>From x.x.x.126: icmp_seq=1 Redirect Network(New nexthop: x.x.x.8)
64 bytes from 192.168.20.4: icmp_req=1 ttl=57 time=15.6 ms
>From x.x.x.126: icmp_seq=2 Redirect Network(New nexthop: x.x.x.8)
64 bytes from 192.168.20.4: icmp_req=2 ttl=57 time=15.4 ms
>From x.x.x.126: icmp_seq=3 Redirect Network(New nexthop: x.x.x.8)
64 bytes from 192.168.20.4: icmp_req=3 ttl=57 time=14.1 ms
>From x.x.x.126: icmp_seq=4 Redirect Network(New nexthop: x.x.x.8)
64 bytes from 192.168.20.4: icmp_req=4 ttl=57 time=15.1 ms
>From x.x.x.126: icmp_seq=5 Redirect Network(New nexthop: x.x.x.8)
64 bytes from 192.168.20.4: icmp_req=5 ttl=57 time=15.3 ms
^C
--- 192.168.20.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 14.112/15.131/15.626/0.537 ms
root na box:~# ip -s route get 192.168.20.4
192.168.20.4 via x.x.x.126 dev eth0  src x.x.x.5
    cache <redirected>  users 1 used 12749 ipid 0xc722

Co to rika ? Ani jadro si do te cache neumi zapsat! Kazdy paket routuje
"ad hoc", kdyz mu router nafackuje redirect, ale v te cache porad visi ten
puvodni spatny, kvuli kteremu na ten router vubec jde... 

Ovsem routing na 192.168.20.5 neopravim, protoze se to snazi posilat na x.x.x.7 a
ta je mrtva, takze "opravny redirect" nema kdo poslat.

> Pak je asi potreba nejaky cas pockat(15min?), aby vyexpirovala peer cache, ta
> podle me nejde mazat, ale maze se casem sama. Jinak asi reboot :D

Jo, jo, teorie to rika, ale praxe v tomto pripade je bohuzel jina... Zjevne
je to v tom jadre zavarene a nezbude nez reboot, ale kdyz uz, tak do noveho
jadra...

Pokud uz nikdo nema neco opravdu podstatneho k tematu, myslim, ze uz jsme to
tu pretrasli dostatecne, mame zaver - kernel bug, new kernel needed - a tedy
diskuse splnila ucel...

Zdravi Pavel

> 
> -- ynezz


Další informace o konferenci Hw-list