Sziasztok!
Kezdő freebsd-s, meg linuxos vagyok egy iskola új rendszergazdájaként.
Egy új (Debian 5-ös) Samba szerver installása közben figyelmetlenségből elkövettem az alábbi két kapitális hibát:
- a szükséges (172.22.2.2) IP cím helyett egy már meglévő másik File szerver(Ubuntu 8.10-es) IP címét (172.22.2.3),
- a jó "...:d8"-ra végződő MAC address helyett pedig "...:d9" végűt adtam meg.
A beállítási hibát a Samba szervernél javítottam, de azóta főszerverünk (FreeBSD 6.2, DHCP+másodlagos DNS (az elsődleges DNS egy WIN2003))
rendszertelen időközönként, de gyakran az alábbi üzenetekkel "örvendeztet" meg:
" xxxx.xxxx.hu kernel log messages:
> +++ /tmp/security....
> +arp: 172.22.2.3 moved from 00:xx:xx:d3:8b:bc to 00:xx:xx:71:19:d9 on em2
> +arp: 172.22.2.3 moved from 00:xx:xx:71:19:d9 to 00:xx:xx:d3:8b:bc on em2
> +arp: 172.22.2.3 moved from 00:xx:xx:d3:8b:bc to 00:xx:xx:71:19:d9 on em2
> +arp: 172.22.2.3 moved from 00:xx:xx:71:19:d9 to 00:xx:xx:d3:8b:bc on em2"
Valamint még ezzel is:
+arp: 00:1a:64:71:19:d9 attempts to modify permanent entry for 172.22.2.3 on em2
Az arp táblában nem láttam inkorrekt bejegyzést:
xxxxx.xxx.hu (172.22.2.1) at 00:xx:xx:xx:xx:ba on em2 permanent [ethernet]
samba.xxx.hu (172.22.2.2) at 00:xx:xx:71:19:d8 on em2 [ethernet]
file.xxx.hu (172.22.2.3) at 00:xx:xx:d3:8b:bc on em2 permanent [ethernet]
Wireshark-kal(XP-s gépről:Intel_93:a9:7e) viszont nagyon gyakran ezt lehet látni a File szerver(Vmware_d3:8b:bc)egyszerű pingelése esetén is:
(A File szerver Intel vason Vmware alatt virtuális gépen fut, a Samba szerver pedig IBM vason)
No...Time.......Source....................Destination.........Protocol....Info
1..0.000000..Intel_93:a9:7e........Broadcast...........ARP..........Who has 172.22.2.3? Tell 172.22.2.8
2..0.000176..Ibm_71:19:d9.........Intel_93:a9:7e...ARP..........172.22.2.3 is at 00:xx:xx:71:19:d9
3..0.000302..172.22.2.8..............172.22.2.3..........ICMP.........Echo (ping) request
4..0.000523..Vmware_d3:8b:bc..Intel_93:a9:7e....ARP..........172.22.2.3 is at 00:xx:xx:d3:8b:bc
Nem tudok rájönni a Wireshark lista 2. sorában jelentkező inkorrekt "beszólás" okára.
(Itt "köszön vissza" a korábban elkövetett két hiba.)
A hiba kikapcsolt Samba szervernél is fennáll.
A szerverek karbantartási és egyéb munkák miatt már párszor újra lettek indítva.
A probléma másik oldala, hogy Windows kliensek próbálnak kapcsolódni a File szerverhez,de a fenti rendszertelenül előforduló hiba miatt ez gyakran sikertelenül végződik.
Sokat böngésztem a netet ilyen, illetve hasonló problémák megoldása után kutatva, de nem találtam olyat, ami segített volna, lehetőségeimet pedig kimerítettem.
Kérem a segítségeteket.
Üdvözlettel,
Dobóvári János
Hozzászólások
Semmi ötlet?
Kényszerűség miatt írtam ebbe a topikba, mert a FreeBSD-s szerverünk jelezte a fent leírt hibát.
A hiba oka természetesen máshol is lehet, csak képtelen vagyok kapaszkodót találni.
Üdv,
János
A tracert mit mond a két szerverre a kliensről indítva?
Route ?
Connected.
Összefoglalva így néz ki a hálózat:
A Debiané dinamikus és jó, tehát élő és valós:
Viszont a Debian rossz MAC-je még jelenleg is aktív használatban van, és nála van a rossz IP is:
A beállítási hibát a Samba szervernél javítottam
Pedig itt úgy tűnik, hogy a Debian beállításainál maradt el valami, vagy pedig szerencsétlen módon valóban létezik egy másik gép az Ibm_71:19:d9 MAC-kel, és 172.22.2.3 IP-vel.
Próbáld meg ezeket:
1.) Debianon MAC és IP ellenőrzése az ifconfig alapján.
2.) A switch(ek)en megnézni, hogy az Ibm_71:19:d9 MAC melyik port(ok) felé látszik, ill. megegyezik-e az Ibm_71:19:d8 portjával.
3.) FreeBSD-n az ARP ellenőrzése után megpingelni a 172.22.2.2-t, eközben a Debianon tcpdumppal, a promiscuous mód tiltása mellett (i[]-p[/i])nézni az ARP és ICMP forgalmat. Sejtés: a ping odatalál (és az ARP is jól válazol, ha éppen kell ARP), azaz a Debian birtokolja a jó MAC-et és IP-t is, hallgat rájuk, és ezekről válaszol is.
4.) Az előző, csak a 172.22.2.3-mal. Ehhez a FreeBSD-n ideiglenesen törölni kellene a statikus ARP-bejegyzést, valamint "le kell húzni a hálózatról" az Ubuntut. Itt két eset lehetséges:
a) válaszol az ARP-re a rossz MAC-kel és IP-vel, ez baj.
b) Nem érkezik meg, ez viszont azt jelenti, hogy nem a Debian a ludas.
:)
Ha tudod vmelyik wines gépet állítsd csak a sambás gépre és nézd meg
rendesen odatalál-e(elsődleges dns és wins fül).
"(elsődleges dns és wins fül)"
A DNS-nek és a WINS-nek semmi köze a MAC-hez és ARP-hez.
Ez igaz.
Csak azt nem tudjuk, hogy a win mit tárol(vagy tárolt) le
a hibás konfig miatt.
Elnézést a kései válaszért, engem is elért az elhavazás. :)
1. A Debianon az ifconfig alapján minden rendben van.
2. Van a szerver szobában egy menedzselhető switch is a "buliban", de nem tudok hozzáférni."Örököltem" a rendszert és a switch-nek már nem volt IP címe és a nem ismert jelszó hiányában sem a soros sem az USB porton nem engedett belépni. A reset gombját egyenlőre nem szeretném megnyomni, mert egyrészt erre csak a nyári szünet az alkalmas időpont, másrészt elveszhetnek, elvesznek a switch jelenlegi beállításai.
3-4. Köszönöm az ötletet! Ezzel fogom folytatni a hiba "vadászatát".
Kellemes karácsonyi ünnepeket és BUÉK!
Üdv,
János
a freebsd -s gép arp tábláját másold már be ide:)
BUÉK!
Mcsiv, elnézésed kérem a kései válaszért. Szabadságon voltam.
Tegnap és ma elég meglepő dolgokat tapasztaltam az arp táblánál valamint a kernel log-ban.
A tegnapi arp tábla.(A lényegtelen sorok nélkül. Azokkal jóval 100 fölött van a számuk.):
Meglepő, hogy nincs benne a file.xxxx.hu (172.22.2.3)... bejegyzés!
cartman.xxxx.hu (172.22.2.1) at 00:14:4f:20:7f:ba on em2 permanent [ethernet]
samba.xxxx.hu (172.22.2.2) at 00:1a:64:71:19:d8 on em2 [ethernet]
chef.xxxx.hu (172.22.2.4) at 00:14:c2:3b:34:ba on em2 [ethernet]
mail.xxxx.hu (172.22.2.5) at 00:0c:29:35:de:22 on em2 [ethernet]
licman.xxxx.hu (172.22.2.7) at 00:0c:29:35:29:42 on em2 [ethernet]
rc.xxxx.hu (172.22.2.8) at 00:d0:b7:93:a9:7e on em2 [ethernet]
stan.srv.xxxx.hu (172.22.2.11) at 00:04:23:af:b3:eb on em2 [ethernet]
licman2.xxxx.hu (172.22.2.13) at 00:0c:29:21:fa:9f on em2 [ethernet]
dc1.xxxx.hu (172.22.2.26) at 00:0c:29:cb:28:17 on em2 [ethernet]
ups-1.srv.xxxx.hu (172.22.2.37) at 00:c0:b7:4a:96:be on em2 [ethernet]
xrx7132.xxxx.hu (172.22.2.40) at 08:00:37:38:7d:1a on em2 [ethernet]
di2510.srv.xxxx.hu (172.22.2.42) at 00:0d:02:89:55:57 on em2 [ethernet]
cartman.xxxx.sulinet.hu (195.199.142.233) at 00:14:4f:20:7f:b9 on em1 permanent [ethernet]
w3.xxxx.sulinet.hu (195.199.142.235) at 00:14:4f:20:7f:b9 on em1 permanent [ethernet]
gw.xxxx.sulinet.hu (195.199.142.238) at (incomplete) on em1 [ethernet]
A hajnali kernel jelentés (a kernel.log-ból. Email-ben küldi a szerver.):
(Ilyen tartalmú üzenet november elején volt utoljára!!)
cartman.xxxx.hu kernel log messages:
+++ /tmp/security.9tBP4z1A Tue Jan 4 03:04:01 2011
+arp: 172.22.2.3 moved from 00:0c:29:d3:8b:bc to 00:1a:64:71:19:d9 on em2
+arp: 172.22.2.3 moved from 00:1a:64:71:19:d9 to 00:0c:29:d3:8b:bc on em2
+arp: 172.22.2.3 moved from 00:0c:29:d3:8b:bc to 00:1a:64:71:19:d9 on em2
+arp: 172.22.2.3 moved from 00:1a:64:71:19:d9 to 00:0c:29:d3:8b:bc on em2
...
...
A ma délelőtti állapot az arp táblában:
Van file.xxxx.hu (172.22.2.3)... bejegyzés!!
(Most éppen a jó MAC-kel.)
cartman.xxxx.hu (172.22.2.1) at 00:14:4f:20:7f:ba on em2 permanent [ethernet]
samba.xxxx.hu (172.22.2.2) at 00:1a:64:71:19:d8 on em2 [ethernet]
file.xxxx.hu (172.22.2.3) at 00:0c:29:d3:8b:bc on em2 [ethernet]
chef.xxxx.hu (172.22.2.4) at 00:14:c2:3b:34:ba on em2 [ethernet]
mail.xxxx.hu (172.22.2.5) at 00:0c:29:35:de:22 on em2 [ethernet]
licman.xxxx.hu (172.22.2.7) at 00:0c:29:35:29:42 on em2 [ethernet]
rc.xxxx.hu (172.22.2.8) at 00:d0:b7:93:a9:7e on em2 [ethernet]
stan.srv.xxxx.hu (172.22.2.11) at 00:04:23:af:b3:eb on em2 [ethernet]
licman2.xxxx.hu (172.22.2.13) at 00:0c:29:21:fa:9f on em2 [ethernet]
dc1.xxxx.hu (172.22.2.26) at 00:0c:29:cb:28:17 on em2 [ethernet]
phaser8200n.xxxx.hu (172.22.2.35) at (incomplete) on em2 [ethernet]
ups-1.srv.xxxx.hu (172.22.2.37) at 00:c0:b7:4a:96:be on em2 [ethernet]
xrx7132.srv.xxxx.hu (172.22.2.40) at 08:00:37:38:7d:1a on em2 [ethernet]
di2510.srv.xxxx.hu (172.22.2.42) at 00:0d:02:89:55:57 on em2 [ethernet]
cartman.xxxx.sulinet.hu (195.199.142.233) at 00:14:4f:20:7f:b9 on em1 permanent [ethernet]
w3.xxxx.sulinet.hu (195.199.142.235) at 00:14:4f:20:7f:b9 on em1 permanent [ethernet]
gw.xxxx.sulinet.hu (195.199.142.238) at (incomplete) on em1 [ethernet]
Mitől "tűnt" el, mikor nyáron permanent-re állítottam és mitől "jött" vissza?
Üdv,
János
"Mitől "tűnt" el, mikor nyáron permanent-re állítottam"
Szerintem ennek a hozzászólásodnak a 4. pontja után nem írtad vissza.
"és mitől "jött" vissza?"
Dolgozik az ARP, ez a dolga - hacsak nem "tiltod le" a permanens bejegyzésekkel.
Nos, hát éppen az a probléma, hogy permanent bejegyzése volt (lásd az indító hsz.-t) én meg nem írtam át.
Értem. Akkor ezek szerint az utolsó két tcpdumpos tesztet még nem nézted meg. Ha szánnál rá néhány percet, kiderülne, hogy melyik gépen illetve rendszeren keressük vagy ne keressük a hibát.
A file szerveren valóban vmware fut, vagy csak innen csíptél le egy mac addresst?
Ha nem, és a sejtéseim is igazak, miszerint a 00:0c:29:d3:8b:bc egy kézzel beállított, a 00:1a:64:71:19:d9 pedig a tényleges, hardware-es mac-je a gépnek, akkor valószínűleg egy kicsit komplexebb dologgal állunk szemben:
1. Rossz hálókártya driver, mely valamilyen oknál fogva bizonyos esetekben a hw-s macet küldi.
2. Ha szerver, előfordulhat hogy valamilyen monitoring rendszer is ül ezen az interface-en és néha kikandikál (hp-s iLO esetében találkoztam ilyennel)
3. A hálókártya hardware-e alapból nem támogatná a mac átírását de az openszósz driverbe beletuszkolták, így bizonyos esetekben (pl.: incorrect icmp packet-nél lehet ilyet kikényszeríteni bizonyos kártyáknál) a kártya helyből és hardware-esen válaszol a saját macjével.
Bármi is a megfejtés, soha nem célszerű a mac-et kézzel átírni (van ami támogatja, van ami nem).
Pl némelyik (igaz régi, de profi) 3com kártya helyből alkalmatlan pl bridge üzemben, mert sok mindent szeret maga megoldani.
Ha a 00:1a:64:71:19:d9 nem a gép hardware-es macje, akkor van ami még csücsül a hálón ezzel az ip-vel. (engem nyomtató szerver szivatott egyszer meg, mert boot során felvette ezt az ip-t). Ilyenkor célszerű körbenézni a hálón és megkeresni a mac gazdáját, majd seggberúgni az adott hw-t.
A vason Vmware Esxi 3.5 alatt fut az ubuntus file szerver.
A 00:......8b:bc a hálókártya hw-es MAC-je. Az átmenetileg megadott majd javított a 00:..19:d9.
1.A nyári szünet alatt -iskolai környezetről van szó- a samba szerver hosszú ideig nem volt bekapcsolva, de a hiba ugyanúgy fennállt, mint fentebb már említettem.
2-3. Nincs monitoring rendszer, egyszerű "fapados" a samba szerver. Az 1.-ben leírtak miatt én is más eszközre gyanakszom, de nem tudtam még megfogni. Rendszeresen ellenőrzöm a hálózaton levő eszközöket, de mindegyik "önmagát" adja. A menedzselhető switch is lehet a hunyó (fentebb írtam róla), de jelszó hiányában nem férek hozzá, tanév közben meg nem merem megkockáztatni a reset-elését. A már elhangzott tanácsok szerint sorban megpróbálom végigellenőrizni az egyes eszközöket és ha nem jutok eredményre, akkor a switch lesz a hunyó és a következő iskola szünetben reset-elem.
Ami nagyon aggaszt, az az arp tábla megváltozása. Permanent bejegyzése volt a file szervernek, most nem az, én meg nem írtam át. Akkor most a permanent mégsem permanent?
a permanent eltünése valóban fura, erre részemről nincs magyarázat (esetleg egy kutakodás közben nem lehetséges, hogy elfelejtetted visszaírni?)
Az utolsó "akcióm" ezzel kapcsolatban a permanent-re állítás volt.
Az is jó pár hónappal ezelőtt. A dologgal nem is foglalkoztam addig, amíg a témanyitó hozzászólásban leírt hiba újra jelentkezett. Bíztam a "permanent"-ben.:) Az is érdekes jelenség, hogy a legutóbbi arp tábla ellenőrzésekor reggel nem volt file.xxxx.hu bejegyzés, pár óra múlva viszont igen, de permanent opció nélkül! (Fentebb látható az aznapi két lista.)
Másik érdekesség a folyamatos csere-bere:
cartman.xxxx.hu kernel log messages:
.
+arp: 172.22.2.3 moved from 00:1a:64:71:19:d9 to 00:0c:29:d3:8b:bc on em2
+arp: 172.22.2.3 moved from 00:0c:29:d3:8b:bc to 00:1a:64:71:19:d9 on em2
.
.
+arp: 172.22.2.3 moved from 00:1a:64:71:19:d9 to 00:0c:29:d3:8b:bc on em2
+arp: 172.22.2.3 moved from 00:0c:29:d3:8b:bc to 00:1a:64:71:19:d9 on em2
+arp: 172.22.2.3 moved from 00:1a:64:71:19:d9 to 00:0c:29:d3:8b:bc on em2
Ez akár 8-10-szer is ismétlődik!
Természetesen ekkor már nem permanent a bejegyzés.
szétnéznék a vmware beállításaiban, hogy miért válaszolgat a hw-s maccel a megadott ip-n. Esetleg valami heartbeat funkció lenne?
Mindenesetre nem zárnám ki továbbra sem a rossz driver/hálókártya firmware dolgot.
Ami esetleg egyenesen előre viheti a dolgot, megpróbálni valamihez kötni az adott eseményt (majd egy tcpdump/ngrep párossal megnézni, mégis mi váltja ki hálózati oldalról az eseményt). A szarul formázott/széthulló packet nálam a befutó érzésem szerint.
Közben gugliztam egy kicsit, amit még célszerű lenne megnézned:
http://communities.vmware.com/message/1383789
Itt hasonló jelenségről írnak mint esetedben, és az előző postban is írt egyik vmware beállítás a ludas.
Köszönöm!
Mcsiv, ez talán kiutat jelent a körben járásból!
(A Google nekem is a barátom, de ezt a linket nem hozta fel nekem a "piszok" ! :))
Elfeledkeztem a hibakeresés folyamán egy lényeges dologról: a file.xxxx.hu az egy virtuális gép... Tudom, jeleztem is az indító hozzászólásban, de figyelmen kívül hagytam :(
Ez az ESXi-s post ütött.
Mihelyst túl leszek ezen héten (hófúvásban vagyok), ebből az irányból "támadok".
Addig is köszönöm mindenkinek a eddigi segítségét, ötleteit.