Re: Linux routing - podivná záhada

[Butrus Damaskus]

2015-07-30 21:00 GMT+02:00 Pavel Troller <patrol na sinus.cz>:

> 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...
>

Právě jsem se chtěl zeptat, co Vám brání provést reboot ;-).
(Já vím, tohle je Linux a ne Windows, ale přece...)


>
> 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...
>

Pokud to budete hlásit jako chybu, můžete sem, prosím, ještě hodin link?

Děkuji!


> Zdravi Pavel
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20150731/d9bce88d/attachment-0001.html>