Problem s multihomed serverem

[Pavel Kankovsky]

On Tue, 2 Jul 2013, Dalibor Toman wrote:

> V routovaci cache jsem tale nenasel rozdily, ktere by to vysvetlovaly, 
> flush cache nezpusobi zadnou zmenu (nezacne pingat a kdyz uz pinga 
> neprestane pingat).

A co udělá ip route flush cached, když už to pingá?


On Tue, 2 Jul 2013, Dalibor Toman wrote:

> ja nemam problem s tim upravit vahy v OSPF na tom serveru tak aby mi to 
> odeslo zase tim interfacem co prislo ale nesymetrickemu routingu se v 
> slozitejsi siti neda uplne vyhnout, takze bych rad ten problem vyresil 
> jinak.

Řekl bych, že v síti, kde jsou parametry (ceny linek, id routerů...) 
nastaveny konzistentně, by se asymetrické cesty měly vyskytovat jen zřídka 
a dočasně.


On Wed, 3 Jul 2013, Dalibor Toman wrote:

> tcdump vidi prichozi packety na jednom rozhrani (eth0:vlanA) a na zadnem 
> nenajdu odchozi packet (mel by byt na eth0:vlanB). Pokud to 
> "zpruchodnim" pomoci pingu na problemovy stroj, tak potom tcpdump chyti 
> na eth0:vlanB odchozi packety (ICMP reply).

Jeden rozdíl mezi vysláním odpovědi na cizí ping a vysláním vlastního 
pingu je imho ten, že v prvním případě je pevně určena moje (tj. 
zdrojová) adresa, zatímco v druhém se obvykle určí až v procesu směrování 
odesílaného paketu.

Možná dochází k tomu, že z nějakého důvodu nedokáže nasměrovat paket, 
pokud má zdrojovo adresu pevně danou, ale tu samou cestou najde, pokud je 
zdrojová adresa určena až při směrování (dovedu si představit, že by 
dostatečně šílená pravidla v ip rule mohla něco takového způsobovat). 
Pokud se však nejdřív udělá ping ven, tak se příslušná položka strčí do 
route cache a tam jí pak najde o směrování odpovědí a začne to fungovat.

Nemá stejný efekt jako odchozí ping také ip route get na cílovou adresu?
A neliší se výsledek od ip route get s from?


-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /