NFS lassulás router fw upgrade után
Asus routerem van. Ma reggel gondoltam egyet és upgrade-eltem a firmware-t. Kár volt. Van egy log szerverem, amin többek közt a router logjait őrizgetem. Ezeket a logokat NFS segítségével publikálom és ezt az NFS share-t mountolom a notebookomra, ott turkálok bennük.
A mai napig semmi gond nem volt vele, viszont... a reggeli boot után még normálisan működött, de úgy egy-két perc elteltével iszonyatosan lelassult. Értsd: egy ~30000 soros logot normálisan fél másodperc alatt olvas végig mondjuk egy wc -l parancs, most meg 4-5 másodpercbe telt minimum.
Persze sehol semmi érdemi infó, minden log, journal stb. üres, nincs hibaüzenet, nincs timeout, a wireshark sem mutat érdemi eltérést a mount utáni pillanatban még gyors és a későbbi, lassú olvasás forgalma között.
Véletlenül belenéztem a router admin felületén is a logba és feltűnt valami: rengeteg ACCEPT IN=br0 OUT=br0 ... sor.
Na itt már "leesett", hogy mi történik.
Asus-ék elcseszték a logolást, nálam meg egy viszonylag ritka felállásban van a hálózat összetákolva: a fizikai vasak 172.16.0.0/12 tartományban vannak, a virtuális gépek meg 192.168.0.0/16-ban. Ez korábban nem okozott gondot, de amikor IPv6-ot próbálgattam, már feltűnt, hogy vannak problémák az Asus fejlesztőinek a logokat illető elképzeléseivel. IPv6 esetében már korábban is az volt a gond a logolással, hogy nem az interface alapján döntötte el egy packet-ről, hogy kívülről jön-e vagy belülről, hanem a forrás cím alapján.
Most ugyanez történt IPv4 alatt is: nem azt nézi, hogy a ppp0-n/egyéb WAN interface-en jön-e a packet, hanem azt, hogy a forráscím tartománya egyezik-e a routerével vagy sem.
Mivel fizikai gép (notebook) és egy virtuális gép (log szerver) közt folyik a kommunikáció, az új verziókban veszettül logolni kezdi az elfogadott csomagokat, ami viszont lelassít minden LAN-os kommunikációt, ami a virtuális gépekkel folyik. Egyelőre nem tudok jó megoldást, mert az eldobált csomagok logolását még csak-csak lekapcsolom, de pont a beengedetteket nem logolni, elég rossz ötletnek tűnik, ha már van logom róla...
Ja, a router webes admin felülete meg azért kellett a hiba felfedezéséhez, mert még az IPv6 tesztek alatt a syslog-ng-ben kiszűrtem azokat a sorokat, amelyekben az "IN=br0 OUT=br0" string szerepel, így az őrzött logokban ezek eleve nem jelennek meg.
Update (2020.04.20) : ugyan régebben kerültem ki ezt a dolgot, de csak most jutott eszembe a blog. Szóval annyit tudtam tenni, hogy a virtuális gépeket (valójában már csak egy van) áthoztam a 172.16.0.0/12 tartományba egy NAT jellegű megoldással. A host etherned adaptere kapott pár plusz IP címet és ami ezekre a címekre jön csomag, azt azonnal küldi tovább a megfelelő 192.168.x.x címre. Nem szép, de legalább csúnya. :)
A mai napig semmi gond nem volt vele, viszont... a reggeli boot után még normálisan működött, de úgy egy-két perc elteltével iszonyatosan lelassult. Értsd: egy ~30000 soros logot normálisan fél másodperc alatt olvas végig mondjuk egy wc -l parancs, most meg 4-5 másodpercbe telt minimum.
Persze sehol semmi érdemi infó, minden log, journal stb. üres, nincs hibaüzenet, nincs timeout, a wireshark sem mutat érdemi eltérést a mount utáni pillanatban még gyors és a későbbi, lassú olvasás forgalma között.
Véletlenül belenéztem a router admin felületén is a logba és feltűnt valami: rengeteg ACCEPT IN=br0 OUT=br0 ... sor.
Na itt már "leesett", hogy mi történik.
Asus-ék elcseszték a logolást, nálam meg egy viszonylag ritka felállásban van a hálózat összetákolva: a fizikai vasak 172.16.0.0/12 tartományban vannak, a virtuális gépek meg 192.168.0.0/16-ban. Ez korábban nem okozott gondot, de amikor IPv6-ot próbálgattam, már feltűnt, hogy vannak problémák az Asus fejlesztőinek a logokat illető elképzeléseivel. IPv6 esetében már korábban is az volt a gond a logolással, hogy nem az interface alapján döntötte el egy packet-ről, hogy kívülről jön-e vagy belülről, hanem a forrás cím alapján.
Most ugyanez történt IPv4 alatt is: nem azt nézi, hogy a ppp0-n/egyéb WAN interface-en jön-e a packet, hanem azt, hogy a forráscím tartománya egyezik-e a routerével vagy sem.
Mivel fizikai gép (notebook) és egy virtuális gép (log szerver) közt folyik a kommunikáció, az új verziókban veszettül logolni kezdi az elfogadott csomagokat, ami viszont lelassít minden LAN-os kommunikációt, ami a virtuális gépekkel folyik. Egyelőre nem tudok jó megoldást, mert az eldobált csomagok logolását még csak-csak lekapcsolom, de pont a beengedetteket nem logolni, elég rossz ötletnek tűnik, ha már van logom róla...
Ja, a router webes admin felülete meg azért kellett a hiba felfedezéséhez, mert még az IPv6 tesztek alatt a syslog-ng-ben kiszűrtem azokat a sorokat, amelyekben az "IN=br0 OUT=br0" string szerepel, így az őrzött logokban ezek eleve nem jelennek meg.
Update (2020.04.20) : ugyan régebben kerültem ki ezt a dolgot, de csak most jutott eszembe a blog. Szóval annyit tudtam tenni, hogy a virtuális gépeket (valójában már csak egy van) áthoztam a 172.16.0.0/12 tartományba egy NAT jellegű megoldással. A host etherned adaptere kapott pár plusz IP címet és ami ezekre a címekre jön csomag, azt azonnal küldi tovább a megfelelő 192.168.x.x címre. Nem szép, de legalább csúnya. :)
Megjegyzések
Megjegyzés küldése