Lassú, néha kihagyó DHCP

Hálózatok általános

Sziasztok!

Van szerencsém működtetni egy viszonylag nagy hálózatot:
63 db menedzselhető HP switch (5406,26xx,28xx,29xx,17xx,18xx,19xx), a 41 VLAN-ban DHCP szerverek osztják a (IPV4) címeket (2db Windows 2012R2, 2db Ubuntu 16.04). A hálózat kiterjedése (két legtávolabbi végpont közötti switch-ek száma) 6.
Beállítottam egy monitorozó gépet (https://github.com/csikfer/lanview2 , https://github.com/csikfer/dhtest ), ami rendszeresen üzenget, hogy időtúllépés van (időkorlát 5 másodperc, két sikertelen kísérlet után jelez).
Ettől függetlenül az a tapasztalat, hogy lassú a DHCP.
Másik furcsaság, hogy ha beteszek egy új switch-et (legutobb egy 1920-48G, később egy 1820-8G), nagyon sok idő telik el mire a kliensek kapnak címet. A 1920-asnál kétszer néztem át a konfigokat (nincs GVRP a 1920-on), mire kiderült, hogy jó az.
Mi lehet a gond? Hol érdemes vizsgálódni?

  • 2761 megtekintés

( andrej_ v | 2017. 09. 10., v – 09:59 )

Elsőre azt nézném meg, hogy nincs-e valahol loop a hálózaton. A HP switchek, ha jól rémlik, akkor automatikusan védenek ellene, de azért mégis idő mire észreveszik és tiltják a portot.

Ha nincs loop, akkor megnézném, hogy melyik ponton jelentkezik legkorábban a probléma.

Jah. És többször annyi ideig tart megcsinálni, mint amennyi idő alatt megváltozik. Főleg, ha rajtad kívül mindenkinek másodlagos, működjön, oszt jó napot. És akkor még nem volt szó az önjelölt rendszergazdákról, és hálózat buherátorokról (nem a lessúság miatt monitorozom a DHCP-t, és forkoltam egy munin plugint).

Egy skicc akkor se artana, hogy konnyebben megertsuk hogy fest ez es erdemben lehessen otletelni.
Szamomra pl az se vilagos ennyibol hogy azon a 63 switchen vegigmegy-e az a vlan amiben dhcp-vel van ip osztas vagy relay-ezve van, vagy hogy mekkora subnetekrol van szo.
Meg esetleg olyan info is jol jonne hogy ez mennyire rendszeres, miutan kapott igy lassan ip-t valaki akkor mar rendben valaszol a kliens vagy akkor is lassu.
Dhcp szerver logokban, switch logokban barmi erdemleges?

Biztos nem egyszeru ugy uzemeltetni hogy pattognak az ember nyakan, hogy miert nem megy mar, vagy mas is belenyul, csak arra jobb megoldas ha hatarozottan kijelented te csak akkor uzemelteted ha ugy tortenik ahogy mondod, masoktol megvonod a hozzaferest amig nem tanulja meg stb.

Nem reklamálták meg a lassulást, vagy csak eddig nem jutott el hozzám panasz, nekem tűnt fel.
Épp most próbálok a monitorozó programra rágyógyítani egy gráf rajzoló modult, hogy lehessen látni topológiát, idő... (kézzel megrajzolni is eltart egy darabig).
A DHCP egy-két kivételtől eltekintve relay-en keresztül megy, legtöbbször a 5406 a relay, de néhány esetben egy SoniWall tűzfal.
A monitorozó program 5 percenként kér egy címet VLAN-onként, ha nem kap egy perc múlva újra próbálkozik, ha akkor sem sikerül küld egy levelet. Amíg az első sikertelenre riasztott naponta kaptam egy párat, most kb. naponta egy.
Ha a VLAN nem jut el a végpontig, akkor nem lassú lesz, nem csak néha nem lesz cím, hanem egyáltalán nem működik, mintha be se lenne dugva a hálózati kábel. Nincsenek redundáns utak a hálózatban, ahol több kábel van két csomópont között az mindig trunk. (Volt, hogy elcsesztem a tunk-öt, de annak markánsabb következményei voltak.)
Logok: Ha nem tudom mit keresek, az olyan mintha tűt keresnék egy szénakazalban, úgy, hogy még azt sem tudom tűt keresek.
Eszembe jutott egy régebbi eset, egy bugyuta ethernet modulban, ahol egy basic program volt a DHCP kliens, hosszas nyomozás után derült ki, hogy a ProCurve switch-ek az első 2-3 DHCP kérést simán lenyelték (hogy relay volt-e arra már nem emlékszem).

ui.:"hatarozottan kijelented te csak akkor uzemelteted ha ugy tortenik ahogy mondod"
Ez a kijelentést csak egy módon tehetem meg, a munkaügyön felmondás formájában (ha 20-30 évvel fiatalabb lennék meg is tenném). Nem tudom, kiderült-e, hogy egyetemről van szó. Amúgy tettem hasonló kijelentéseket (de ki nem szarja le?). Ép a héten: Nyáron lecserélték a fali csatlakozókat a kollégiumba, az RJ45-öket is. Ez onnan derült ki, hogy szolt az egyik diák, hogy nem működik. Tudni kell, hogy a kábel hálózat 10-15 éves alultervezett, toldozgatott, tele kábelmegosztással). Az RJ45-öket kevesebb mint 50% találati valószínűséggel kötötte be a hozzáértő al(al...)vállalkozó (kb 120*2 végpont). A hiányzó kábelek pótlása gondolom szóba sem került, mert bár sokszor leírtam, de mint előbb is említettem "Ki nem szarja le?".

"Logok: Ha nem tudom mit keresek, az olyan mintha tűt keresnék egy szénakazalban, úgy, hogy még azt sem tudom tűt keresek."

Ha jol ertem neked monitorozo eszkozod erzekeli hogy lassan kap valaszt, vagyis vannak pontos idopontjaid amikor gond volt plusz hozza kliensed is, ha eszkozokon szinkronban vannak az idopontok es/vagy kozponti log szerverre tovabbitjak a logokat akkor adott idopontokban nem olyan veszes megnezni latszik-e valami furcsasag dhcp szerver oldalon, meg az erintett switcheken (hisz te kliensed csak tudod melyik switcheken megy at a forgalma).

Egyebkent dhcp snooping van bekapcsolva a switcheken, csak hogy nem-e lehet valaki mas dhcp-je kavar be, illetve mac utkozes nincs esetleg?

Elvileg igazad van, nem teljesen reménytelen.
A snooping nincs bekapcsolva. Jelen számosságú eszköz esetén konfigurálja be a snooping-ot az akinek hat anyja van.
A monitorozó rendszer azonnal kiböki ha valaki feltesz egy kalóz DHCP-t (a dhcp teszt pluginba betettem pár okosságot), volt alkalmam tesztelni is.

( gyu v | 2017. 09. 10., v – 23:46 )

Azt, hogy elég kevés támpont van, azt már megírták.

Közben csak tapogatózás: isc dhcp?
Próbáltad már dnsmasq-al kiszolgálni?

A dhcp szerver oldalán néztél már tcpdump-ot, hogy ott mennyi idő telik el a req és resp közt?
Oroszlánfogás első lépéshez mindenképp jó lenne: Kiderülne, hogy a dhcp szerver válaszol lassan (és akkor az isc-> dnsmasq váltás segíthet) vagy később keletkezik a "lassulás" a szerver és a kliens közti részen?
Megerősítésként nem árt, ha ugyanilyen tcpdump-os mérést csinál az ember a kliens oldala felől is.

( rts | 2017. 09. 11., h – 13:02 )

A switchek élveboncolása mellett/helyett nekem ez szúrt szemet:
DHCP szerverek osztják a (IPV4) címeket (2db Windows 2012R2, 2db Ubuntu 16.04)
Ez most mi? Két db egymástól független DHCP klaszter? Ha igen, tuti hogy mind a kettő lassú? És ez biztos? :D

Van 41 VLAN, és van egy Win. Hyper-V cluster.
A Hyper-V alatt futnak Windows, és Linux szerverek.
Egy VLAN-ba egy DHCP szerver van. Van 2db Win tartomány, 15 és 16 VLAN-nal. Egy-egy VLAN kivételével a DHCP szerver és kliensek között RELAY van, a domain-ek esetén a relay mindig az 5406 router switch.
Vannak domain-en kívüli VLAN-ok, ezekben egy Ubuntu 16.04 server osztja a címeket ez DNS szerver is, és a vékony klienseknek van egy saját VLAN-ja, és abban a LTSP boot szerver egyben a DHCP szerver is (szintén Ubuntu 16.04).
Mindegy Windows, vagy Linux ossza a címet, minden VLAN-on tapasztalható a lassúság. A távolság sem igazán számít. A cluster és a monitorozó szerver egymás mellet van (a monitorozó szerver egyedi gép, mert az összes VLAN-t macerás lett volna a Hyper-V vel kiosztani, a virtuális gép pedig nem tudja a VLAN-okat kezelni, vagy nem tudom hogyan).
Kicsit bonyolítja a helyzetet, hogy a Windows szervereknek nem én vagyok a gazdája, és azokhoz annyira nem is értek, de itt semmi jele, hogy azokkal lenne baj.
A hálózat teljes dokumentációját talán érthető okokból nem tenném közhírré.

Van egy Zabbix szerver (a rektorátus ezt szereti, az egyéni kezdeményezéseket meg nem). A Zabbix nem monitorozza a switch-eket, mert belerokkan. A szervereket igen, de ott nem látszik túl nagy forgalom, vagy extra terhelés.
A saját monitoring rendszer pedig (még) csak az aktuális értékeket mutatja a (switch-eken is), de ott egyik érték sincs kritikus közelben.
Van két VLAN, ami nagyobb a többinél (elvileg egy B osztályú tartomány felét ill. negyedét tudja kiosztani a DHCP szerver, de gyakorlatban a közelében sem lehet), nem tűnt fel, hogy azokkal több probléma lenne.

Ellenőrizd, hogy van-e frissebb szoftver a switchekre.
Ellenőrizd a trönkök sebességét és telitettségét. Előfordulhat rossz sebesség egyeztetés, sőt trönkbe vlan pakolásnál is, ha rossz a firmware. Ellenőrizd a spanning treet, az eszközclusterek állapotát, lacp összeköttetéseket. Mérd, vagy méresd ki a trunk kábeleket.

Használj per vlan spanning tree-t vagy lacpt hogy böveld a megbizhatóságot.

Irsd ki az ipv6-ot, okozott mar windows driver halozat floodot ipv6on.

Separálj jobban. Legyen központi core switch es relay. Ne különböző helyekről jöjjenek a dhcpk.

Ha olyan a halo akkor legyen dhcp trust, csak trunkön közlekedjen dhcp szerver üzenet, meg a szerverekrol.

Spanning tree portfast legyen bekapcsolva az egde portokon. Első körben!

A frissítéseket átnézem, el leszek vele egy darabig. (A HP oldalán nem mindig könnyű megtalálni az aktuális firmware-t, ráadásul kezd migrálni az sgi.com -ra párat, amihez én nem férek hozzá).
Mérni nem igazán tudok. Egy ilyet megrendelni agyrém, műszert venni még nagyobb agyrém. A 15 éves kábelsorrend mérőmmel pedig nem sokra megyek.
A win-ipv6 problémát a Windows rendszergazdával kell megkonzultálni.
A négy DHCP szerverből nem tudok egyet csinálni, már a két Windows Domain miatt sem (nem az én döntésem). A négy DHCP egy Hyper-V clusteren fut, a cluster közvetlenül kapcsolódik a core switch-re, és a relay a core switch, vagy a szintén arra csatlakozó tűzfal.

"elvileg egy B osztályú tartomány felét ill. negyedét tudja kiosztani a DHCP szerver, de gyakorlatban a közelében sem lehet"

Vagyis egy /17 es /18 van felveve egyben azon az 1-1 vlan-on?
Mert akkor az nem kicsi es broadcast csomagokbol nem lehet keves, amit akar egy default broadcast storm control limit megfoghat ha van ilyen switchen.
(De switchkonfigtol fuggetlenul se szep ekkora tartomanyt egyben tartani ha tenyleg ugy van, sok fejfajast okozhat.)

Ezek olyan VLAN-ok, ahol sokat cserélődnek a kliensek. Egyszerre nincs ennyi kliens. Lehet, hogy meglepő, de nem vagyok teljesen hülye. Nincsenek extra terhelések, nincs túl sok broadcast se, ill. ennek semmi egyéb jele.
Nem emlékszem olyan riasztásra, ami erre a két VLAN-ra vonatkozott volna, ha ez lenne a bibi, akkor rendszeresen jönnének a riasztások.
Inkább a két Win. tartományból jönnek, azok pedig kicsik, és viszonylag állandóak a kliensek.

Lehet, hogy meglepo de ilyen informacio morzsakbol, mert meg azt se lehet mondani hogy felinformaciokbol, nehez kitalalni mi lehet a gond.

Paran probalunk itt vakon otletelni, hatha tudunk segiteni neked, de leginkabb csak olyan falakba utkozunk amiket te magad allitasz fel.
Ha legalabb egy skicc lenne a halozat azon reszerol mik kozvetlenul erintettek a hibajelenseget produkalo pont es dhcp szerverek kozott, netan egy dhcp szerver vagy monitoring konfig ha mar abban latszik a hiba, switch konfig ha mar az a relay vagy logok a hibajelenseg idejerol.

Megadtam a linket hozzá :).
Sőt még dokumentáció is van hozzá, bár nem a legjobb, de még mindig sokkal jobb mint a legtöbb openszósz doksi.
Ott van a DHCP-t ellenőrző Nagios plugin linkje is.
Annyiból igazatok van, hogy a felmerülő problémák legtöbbjét észre sem venném a monitorozás nélkül, és akkor nem is zavarna.

"Ott van a DHCP-t ellenőrző Nagios plugin linkje is."
Ez lehet nekem kerulte csak el a figyelmem, de nem latom mire gondolsz.

De akkor ezek szerint nagios-bol van meghivva ez a dhtest tool 5 masodperces timeout-al, meg gondolom eltero kliens mac-el mind a 41(ha jol ertem?) vlanban.
Mond az magarol tobbet azon kivul hogy timeout, kapott-e barmi valaszt vagy valami?
log esetleg van rola amit vissza tudsz nezni, hatha latszik benne valami bovebb, vagy ha nagioskent ezt nem tudja akkor mondjuk cronbol futtava lehet bovebb infot logolni vele, hogy latszodjon erdemben valami?

Nagios riasztasok idopontjai alapjan dhcp szerver logokban latszik valami, eljut-e addig a keres legalabb?

Megfigyelheto barmi rendszer a hiba elofordulasaban, netan kizarhato valamelyik komponens esetleg mert abban nem jelentkezett sose (adott vlan, subnet, dhcp szerver stb.)?

Mivel eredetileg fejlesztéssel foglalkoztam, és csak később lettem rendszergazda, az az idióta ötletem támadt (mivel nekem igényem volt rá), hogy írok egy nyilvántartó és monitorozó rendszert. Bár tisztában voltam vele, hogy ehhez kevés vagyok mint macisajtban a brummogás, megtoldottam a hülyeség cunamit, azzal a téveszmével, hogy bizonyára kapok hozzá segítséget vagy támogatást, mert ha nekem kell, akkor talán más is hasznosnak találhatja.
Szóval a monitorozó rendszert én írtam, és a linkje (újra): https://github.com/csikfer/lanview2 .
Mivel a Munin és a Nagios részben mintaként szolgált, kézenfekvő volt a pluginjaik használatára felkészíteni a rendszert (a Munin pluginok még nem működnek).
Az DHCP-t ellenőrzéseket a dhtest Nagios pluginnal túnt legegyszerűbbnek kivitelezni. De úgy gondoltam, hogy lecsekkolhatná a válaszban a DHCP és a router címet is, valamint az első válasz blokk után várhatna arra, hogy jön-e további válasz egy esetleges lassúbb szervertől.
Ezért forkoltam a plugint, és beleírtam a hiányolt funkciókat, a link (újra): https://github.com/csikfer/dhtest .
A dhtest jelen esetben csak egy discover csomagot küld, és arra nem válaszol. Ha nem kap választ, vagy nem stimmel a GW vagy DHCP címe, akkor 'critical'-lal tér vissza. A MAC minden kérésnél ugyan az, mivel a vlan interfészeknek a linuxon nincs külön MAC-je, és nem gondoltam rá, hogy ezen változtassak.
A plugin nem válaszol semmi mást azon túl, hogy időtúllépés. Azért ritkábban jön hiba a kétszeri próba esetén, mint először írtam, közelebb van a heti egyhez, (most kezdődött a tanév, a hálózati terhelés jelentősen növekedett, nem ezt vártam volna). A program fejlesztés alatt van, néha leállítom, van hogy elszáll, így nehéz pontos statisztikát csinálni.

Szoval ha jol ertem, a plugin timeout, ami a riasztast generalja (2 hiba utan), kovetkezhet ezekbol:
- nem is jutott el keres routerig (relay)
- nem is jutott el a keres dhcp szerverig
- eljutott a keres dhcp szerverig, de nem erkezett valasz 5 masodpercen belul
- erkezett valasz de nem jo routertol (relay)
- erkezett valasz de nem jo dhcp szervertol
? (ket utolso eseten ha jol ertem az is lehetseges, hogy nem jo valasz erkezett elsokent, de mondjuk 1 masodperccel kesobb erkezett jo is es akkor viszont nem fut hibara az ellenorzes?)

Dhcp szerver logokban latszik riasztas idopontjaban hogy eljutott-e oda a discover vagy valaszolt-e elvileg ra?

Ez a monitorozas mind a 40 vlan-on tortenik vagy csak az egyiken/paron? Ha tobbon is, akkor mit szol hozza dhcp szerver/router hogy ugyanazzal a mac-el megy dhcp keres eltero vlan-bol?

Nem igazán tudom, hogy egy ekkora hálózatot hogyan lehet jobban leírni, itt. Elképzelésem sincs, jelen esetben hogy is nézne ki az a skicc, ami több infót tartalmaz, mint amit leírtam. Az életben még nem láttam olyat, hogy egy ekkora hálót úgy lerajzoljanak, hogy az a jelen probléma megoldásában segítene, és azt még skicc-nek lehessen nevezni.
Azon kívül nyugodtan lehet feltételezni, hogy valamilyen szinten értek hozzá, vagyis, ha egy triviális dolgot nem írok le, abból még nem következik, hogy arról nem tudok, vagy azt elrontottam. Sokan azt hiszik egy fórum arra való, hogy fogást kell keresni a másikon.
És jó pár válaszból én azt szűrtem le, hogy a "kevés" infóból is sikerült néhányat figyelmen kívül hagyni.
A fő probléma, hogy felesleges volt ez a fórumtémát elindítani. A kisebb problémákkal megküzdök, a nagyobbak meg nem ide valók, csak a munkahelyemen egy olyan ember sincs akivel érdemes konzultálni (most nem arra célzok, hogy mind hülye, de azokban a témákban, amikben szeretnék konzultálni, na azokhoz nem ért itt senki).

Egy egyszerusitett skiccre gondoltam, amibol logikailag latszik a felepites, nem kell hogy rajta legyen mind a 60db switch meg 40 vlan subnetekkel, ip-kkel stb.
pl valami ilyesmi , legalabbis szamomora valami hasonlo korvonalazodott az eddigi leirasaid alapjan, de lehet teljesen maskent kellene elkepzelni, emiatt tud hasznos lenni egy gyors vazlat.

Lehet, hogy van amit a kevesbol is sikerult figyelmen kivul hagyni, dehat nem gondolkozunk egyforman, mig neked valami trivialis, nem biztos hogy masnak is, ahogy te lehet ezt tartod fontosnak, mas meg azt hogy meg kell vizsgalni. Viszont ha olyan trivialis lenne a problema illetve a te gondolatmeneteddel is gyorsan meg lehetne oldani, akkor nem kertel volna itt segitseget csak rajossz es megoldod. Ahhoz hogy mas nezopontbol, frissen mas megvizsgalja neked a lehetseges problema okat viszont informaciok kellenek, olykor olyanok is amik szamodra trivialisak vagy te mar kizartad mint hibalehetoseget (fuggetlenul attol, hogy tevesen-e vagy sem).

Ahhoz hogy legyen kivel megvitatni a problemkat, foleg olyanokat ahol segitseget szeretnel kapni, nem csak az kell hogy az illeto ertsen hozza, hanem hogy te is ki tudd fejezni magad es megertse az adott problemat, kornyezetet stb.
Lehet szemelyesen ez sokkal egyszerubb szamodra, van kozvetlen visszajelzes a masiktol, meg tudsz neki mutatni dolgokat (pl mit latsz hibajelensegnek, hogy van parameterezve a parancs, milyen konfig van a szerveren stb.), papiron gyorsan huzni 5 vonalat hogy felfogja mi hogy kapcsolodik a tobbihez, milyen utvonalat jarhat be a csomag stb. Ezzel szemben itt a forumon nehezebb es lassabb a kommunikacio de nem lehetetlen.

( fastline | 2017. 09. 15., p – 10:30 )

Helló!

Ha a Hyper-V szerverekben Broadcom hálózati kártya van, akkor a driver beállításánál ki kell kapcsolni VMQ támogatást. A legtöbb BC kártyán vadul bugos (Windowson). Igaz ennek a fő tünete, hogy VM-ek sávszélessége konvergál a nullához.

Illetve, Windowsos hálózati anomáliáknál az első nálam mindig az, hogy az összes energia gazdálkodási funkciót kikapcsolom/letiltom ami a hálózattal kapcsolatos. Tízből hatszor megoldja a problémát. Ezt mind a VM-eken, mind a fizikai vasakon.

Ha van olyan hálózat, ami nem bussiness critical, ott kipróbálnám relay nélkül.

Elnézést ha túl dummy a kommentem, de az a tapasztalatom, hogy pont a trivialitása miatt képbe se kerül, mint megoldási lehetőség.