Linux routing - podivná záhada

[Pavel Troller]

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

Reboot mi brání provést to, že to je produkční mašina (ústředna), na které je
občas i nějaký provoz :-). Dále nechci rebootovat jen tak, ale chci tedy předem
zkompilovat nové jádro. A když bude nové jádro, musím zkompilovat i nové moduly
třetích stran (DAHDI pro Asterisk), neboť ty staré by mi nezalezly. To znamená
tak nejméně 20 minut výpadek (když vše půjde dobře, je to na 5 minut, ale co
když nepůjde :-) ?) a tedy v noci a musím u té mašiny sedět, což teď v době
dovolených, kdy spoustu věcí včetně laborování s tou sítí dělám dálkově, není
úplně easy.
> 
> 
> >
> > 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?

Nevím, zda má dnes smysl hlásit chybu v jádře 3.1.0 :-). Asi to nechám být.

Zdraví Pavel

> 
> Děkuji!
> 
> 
> > Zdravi Pavel
> >