A DHCP Rejtett Szépségei - I.

NetAcademia-tudstr
A DHCP rejtett szpsgei I.

Szinte minden TCP/IP hlzat rendelkezik DHCP szolgltatssal. Ez az alkalmazs
httrbe hzdik, a felhasznlk sohasem tallkoznak vele, s ha jl mkdik, a
rendszergazdk is csak hbe-hba vetnek r pillantst. Itt is rvnyes az kori
blcsessg: ami nem lthat, az fontosabb, mint ami lthat.
Az Internet elterjedse technikai rtelemben a TCP/IP protokollcsald szles kr alkalmazst jelenti. Szemben azonban
ms protokollokkal, amelyek nem ignyelnek klnsebb konfigurlst, a TCP/IP negyedik verzija csak akkor nyeri el
robosztussgt, ha az zemeltetk precz belltsokat vgeznek rajta. Ha igen sok lloms dolgozik egy hlzatban, a
belltsok sokszorosan terhelik a rendszergazdt. Kzzel kellene azokat vgezni, mghozz a helysznen, hiszen csak a
konfigurci utn lehet hlzati kapcsolatot ltrehozni, msrszt a szabvny megkveteli, hogy minden lloms egyedi IPcmmel rendelkezzk, - ezt csak precz s napraksz nyilvntartssal lehet biztostani. Az adatbzist folyton frissteni
kellene, amikor egy j gp rkezik, vagy egy eszkzt az egyik hlzatbl a msikba kell kltztetni. A problmahalmazra a
vlasz a DHCP szolgltats kialaktsa. A Dynamic Host Configuration Protocol, vagyis a dinamikus cmkonfigurcis eljrs
kpes automatikusan az gyfelek szmra egyedi IP-cmeket osztani. A DHCP egy szabvny (RFC), brmely opercis
rendszer hasznlhatja, ha ismeri. Ma mr taln nincs is olyan, amelyiket ne ksztettek volna fel a cmek automatikus
kezelsre. Akr egy Windows for Workgroups 3.11, egy Linux, vagy egy OS/2 is lehet gyfl. A kliensek viselkedse
klnbz helyzetekben s konfigurcis ignyei eltrek lehetnek, ahogy ezt ksbb majd ltni fogjuk.
DHCP alapok
A DHCP-szabvny megrtshez nhny TCP/IP alapfogalmat preczen ismerni kell. Ezek a kvetkezk: IP-cm, alhlzati
maszk, alaprtelmezett tjr, szrt zenet (broadcast), tvlaszt (router). Lakonikus tmrsggel nzzk, mi mit jelent.
IP-cm: ngy szmjegybl ll, az adott llomst a hlzaton egyrtelmen azonost egyedi cm. A cm kt rszbl ll: a
hlzati cmbl s az lloms cmbl. Rnzsre nem llapthat meg, hogy hol r vget az egyik, s hol kezddik a msik.
Pl.: 172.16.3.14
Alhlzati maszk: az a szm, amely meghatrozza, hogy az IP-cm mely rsze hlzati, s mely rsze llomscm. Ennek
segtsgvel lehet megllaptani egy msik IP-cmrl, hogy az a mi hlzatunkba tartozik-e vagy sem. Pl: 255.255.0.0
Alaprtelmezett tjr: ha egy olyan cmre kell csomagokat kldeni, amely nem a mi hlzatunkban van, az llomsok az
alaprtelmezett tjr fel tovbbtjk az adatokat. A valsgban az alaprtelemzett tjrk tbbnyire tvlasztk (routerek).
Szrt zenet (broadcast): egy specilis csomag, amelyet minden lloms megkap, s fel is dolgoz. A szrt zenetek nem
jutnak t az tvlasztn, mivel ltalban loklis jelentsgk van. Ethernet hlzaton a szrt zenet MAC clcme FF-FF-FFFF-FF-FF.
tvlaszt (router): egy olyan specilis lloms, amely kett vagy ennl tbb IP-alhlzatot kapcsol ssze, s rendelkezik
azzal a kpessggel, hogy az egyik hlzatbl rkezett csomagot a megfelel tvonalat kivlasztva egy msik hlzatba
juttatja.
Az alapvet TCP/IP fogalmak mellett meg kell bartkoznunk nhny specilis, a DHCP szabvnyra vagy kiszolglra
jellemz defincival is.
Scope: Egy folytonos cmtartomny (Pl.: 10.10.10.1-10.10.10.254), amelybl a DHCP kiszolgl cmeket oszt az
gyfeleknek. (Egy vdr IP-cm a szerk.) Egyszerbb esetekben a scope egy alhlzatot reprezentl.
Superscope: Tbb scope rendszergazdk ltal meghatrozott csoportja, amely kpes tbb logikai alhlzat kezelsre egy
fizikai alhlzaton.
Exclusion range: Azon cmek listja, tartomnya, amelyeket a DHCP kiszolgl nem fog kiajnlani az gyfeleknek pldul
mert mr foglaltak.
Address pool: A cmtartomny kioszthat rsze.
Lease (brlet): a DHCP szerver ltal meghatrozott idszak, amely id alatt egy gyfl hasznlhatja a szervertl kapott
cmet. A brletet meg kell jtani, klnben lejr s tovbb nem hasznlhat. A kiadott brlet aktv. Ha nem trtnik
megjts, a brlet aktv llapotbl felhasznlhat (szabad) llapotba kerl, vagyis egy msik lloms szmra kiadhatv
vlik.
Reservation (lefoglals): lland cm hozzrendelse egy gyflhez. Ezzel biztostani lehet, hogy egy adott eszkznek
mindig ugyanaz marad az IP-cme.
Option types: Az gyfeleknek tadand konfigurcis paramter. ltalban egy scope-hoz adunk meg opcikat, de
lteznek ms lehetsgek is.
Option classes: Egy msik mdszer, hogy az gyfelek rszre konfigurcis belltsokat adjunk ki. Az IP-cmet ignyl
rendszerek tisztban vannak a sajt gyrtjukkal s egyb tulajdonsgaikkal, ezek alapjn specilis konfigurcis
belltsokat is megrtenek. Az adott osztlyba tartoz gyfelek rvnyesteni fogjk a belltsokat, msokra viszont
hatstalan lesz.
Ez a dokumentum a NetAcademia Kft. tulajdona. Vltoztats nlkl szabadon terjeszthet. 2000-2003, NetAcademia Kft.
1
NetAcademia-tudstr
A cmkioszts clja s elvei
A DHCP szolgltats legfontosabb feladata, hogy egyedi cmekkel lssa el azokat az llomsokat, amelyek ezt ignylik. A
cmeket egy elre kijellt cmtartomnybl, a scope-bl veszi. A folyamat szpsge abban rejlik, hogy megold egy
paradoxont: miknt lehet egy llomssal TCP/IP szabvny szerint kommuniklni gy, hogy az nem rendelkezik IP-cmmel,
ergo kptelen a kommunikcira. A megolds a szrt zenetek alkalmazsa. Ez az egyetlen csomagtpus, amelyet minden
lloms feldolgoz, s csak a csomag tartalma alapjn dnti el, az vajon neki szl-e vagy sem. Lssuk pontosan a folyamatot.
Az IP-cmkioszts menetrendje
Egy lloms indulsakor rzkeli, hogy az zemeltetk statikus IP konfigurci helyett dinamikus cm krsre lltottk. A
68-as UPD-forrsportrl a 67-es UDP-clportra egy n. DHCP-Discover (DHCP-felfedezs) szrt zenetet indt a hln. A
csomag clja, hogy az lloms felhvja magra a figyelmet, s arra krje az ilyen csomagokat figyel DHCP-kiszolglkat,
hogy ajnljanak fel szmra cmet.
Az gyfl s a DHCP szerver kezdeti csomagvltsai

A szerver vagy szerverek az zenetet feldolgozzk, s szintn broadcast mdszerrel elkldik felajnlsukat (feltve, ha van
kioszthat cmk). Ezt a csomagot nevezzk DHCP-Offernek (DHCP ajnlat).
A berkezett ajnlatbl vagy ajnlatokbl az lloms kivlasztja a neki megfelelt, s mg mindig a szrt zenettpust
hasznlva egy DHCP-Request (DHCP krs) csomagot kld el a hlzaton. A csomagban elhelyezi annak a szervernek az
azonostjt, amelytl a cmet kri. A szrt zenet azrt hasznos, mert br az lloms mr tudja a kivlasztott szerver cmt,
a broadcast csomaggal knnyen rtestheti a tbbi szervert a vlasztsrl, gy azok erre a szrt zenetre gy reaglnak,
hogy korbbi ajnlatukat visszavonjk. A visszavons nem jr hlzati forgalommal, csupn a felajnlott cm kerl jra
felajnlhat sttuszba.
Ha a DHCP-szerver elfogadja a krst, egy DHCP-Acknowledgement (DHCP-jvhagys) csomaggal nyugtzza az gyfl
fel, tovbbra is szrt zenettel. Ekkor kapja meg az gyfl az egyb DHCP-opcikat is. A kiszolgl rgzti kliense
legfontosabb adatait az adatbzisban, tbbek kztt a host nevt, MAC-cmt, s a brlet lejratnak idpontjt.
Igen ritka esetben az is elfordulhat, hogy nem fogadja el a szerver a krst (pldul mert egy msik szmtgp gyorsabb
volt s elbb elhappolta a cmet), ekkor egy negative acknowledgement (DHCP-Nack) csomagot kap az IP-cmet kr gp,
amely azutn jrakezdi az eljrst.
Ltnunk kell, hogy nem igazn vagy nem csupn egy IP-cmet kap a szmtgpnk, inkbb egy engedlyt arra
vonatkozan, hogy egy meghatrozott ideig hasznlhat egy adott IP-cmet nhny tovbbi paramterrel egytt. Ebbl
kvetkezik, hogy nem a fenti az egyetlen kommunikci a DHCP-szerver s az gyfl kztt.
Kommunikci a DHCP-szerverrel
Az IP-cm boldog tulajdonosa legkzelebb egy jraindtskor fog kapcsolatba lpni a cmkioszt szolgltatssal. Azt vrnnk,
hogy a fentiekkel teljesen megegyez prbeszd zajlik majd le, de tvednk. Az gyfelek ugyanis eltroljk a brletre
vonatkoz sszes informcit, vagyis tisztban vannak azzal, hogy ket megilleti egy cm. Ezrt indulskor DHCP-Discover
helyett egy DHCP-Request csomagot kldenek, amelyben a korbban mr elnyert IP-cmet krik clzott zenet formjban,
megsprolva kt csomagot, nmi idt s svszlessget. A kiszolgl ezt rendesen DHCP-ACK zenettel nyugtzza, s az
let megy tovbb.
Ha azonban a ki- s bekapcsols kztt fontos vltozsok trtntek, pldul a hordozhat gpnket egy msik telephelyen
kapcsoltuk be, ms eredmnye lesz a csomagvltsnak. Az j alhlzatban a msik DHCP-szerver megkapja a DHCPRequest csomagot, mert a szrt zenetet fel kell dolgoznia. Mivel a krt cm nem az hlzatbl val, DHCP-Nack
csomaggal vlaszol a krsre. Az gyfl ezutn elfelejti a korbbi cmt, s egy szablyos IP-cm ignylsbe kezd. No, s
mi van, ha a notebook-ot az otthoni hlzatba kapcsoltam be, ahol nincs is DHCP szerver?
A szituciban a klnbz opercis rendszerek eltr mdon viselkednek. Ha a rendszer Windows 95, vagy Windows NT
4.0, esetleg ezeknl korbbi vltozat, az gyflszoftver azt felttelezi, hogy nem vltozott a helyzete, csak a DHCP-szerver
nem rhet el! A vlasz nlkl maradt DHCP-Request csomag arra kszteti az gyfelet, hogy ellenrizze, rvnyes-e mg a
brlete. Amennyiben a vlasz igen, a rendszer a korbban megkapott IP belltsokkal elindul. Ha a brlet mr nem
rvnyes, a hlzati protokollt nem tlti be a szoftver.
2
NetAcademia-tudstr
Windows 98-tl felfel, valamint Windows 2000-nl s Windows XP-nl mr okosabbak az eszkzk. Ha nem jn vlasz a
DHCP-Request csomagra, az opercis rendszer ksrletet tesz arra, hogy eldntse, vajon a helyn van-e mg s csak a
DHCP-kiszolgl nem rhet el, vagy egy j hlzatban mkdik, ahol nincs DHCP-szolgltats. A trkk egyszer, egy
ICMP (ping) csomagot kld az alaprtelmezett tjr fel. Ha vlaszt kap, a rendszer ott bredt fel, ahol kikapcsoltk, s a
DHCP-szolgltatssal van problma. Ellenkez esetben, teht ha az tjr sem vlaszol, a felttelezs az, hogy nem a sajt
helyn indtottk a rendszert ekkor hasznlja a szoftver az APIPA kpessgt. Tegynk egy kis kitrt, s nzzk meg,
mirl van sz.
Csinld magad DHCP: az APIPA
A rvidts az Automatic Private Internet Protocol Addressing kifejezs rvidtse, magyarul automatikus magn IP-cm
kiosztsi eljrs. A Microsoft otthoni s kisebb irodai hlzatokhoz vezette be a mg csak draft formjban ltez APIPA-t,
olyan helyekre, ahol bizonyosan nincs kiszolgl, mert nem rn meg, s nincs szaktuds sem a hlzat konfigurlsra.
Az APIPA mkdse egyszer: ha indulskor az opercis rendszer nem tall DHCP kiszolglt, a draft ltal lefoglalt, Btpus IP-cmtartomnybl (169.254.0.0, subnet mask: 255.255.0.0) vletlenszeren kivlaszt egy cmet, meggyzdik arrl,
hogy azt ms nem hasznlja, majd elindul. A meggyzds annyit tesz, hogy egy ICMP csomagot indt a kivlasztott cm
fel. Ha rkezik r vlasz, mr ltezik a cm a hlzatban, teht msikat kell keresni. Tzszer prbl gy cmhez jutni, s
tekintve, hogy 65535 a lehetsges cmek szma, kicsi az eslye, hogy nem tallja meg az igazit.
Az automatikusan meghatrozott cmhez azutn nem ragaszkodik, s minden tdik percben kibocst egy DHCP-Discover
csomagot, htha meggondoltk magukat az zemeltetk s mkdkpes llapotba hoztak egy cmkioszt szolgltatst.
A DHCP s az APIPA azrt fr meg egyms mellett, mert az opercis rendszer el tudja dnteni, hogy milyen szituciban
van. Ha korbban mr kapott IP-cmet, most pedig nem, ugyanakkor az alaprtelmezett tjr mkdik, vlheten a DHCPszerver ll. Sebaj, a korbban kapott, s rvnyes brletet lehet hasznlni. Ha az alaprtelmezett tjr sem mkdik, gy
nincs is DHCP a kzelben. Sebaj, ad magnak cmet az APIPA eljrssal. gy vagy gy, de az gyfl IP-cmhez jut. Persze,
ha olyan rgta nincs mr DHCP-szolgltats, hogy a brlet lejrt, a rendszergazdk szndka ellenre az APIPA
segtsgvel led fel a hlzat, de ez mr nem az opercis rendszer felelssge.
Tovbbi DHCP-zenetvltsok
A brlet egy meghatrozott idtartamra vonatkozik, a brlet lejrati dtummal rendelkezik. Az idtartamba beletartozik a
kikapcsolt llapotban eltlttt id is. Ha eltelik a brleti id fele, az gyfl egy megjtsi krelmet kld annak a DHCPkiszolglnak, amelytl a cmet kapta. Nincs szksg szrt csomagokra, az zenetvlts kzvetlen. Ha nincs vlasz, 4, 8,
majd 16 msodperccel ksbb jra prblkozik az gyfl. A szerver egy DHCP-Ack csomaggal jelzi, hogy elfogadja a brlet
meghosszabbtst.
Amennyiben egy szerencstlen vletlen miatt nem sikerl megjtani a brletet flidben, nem trtnik semmi, az gyfl
tovbbra is kommunikcikpes. Amikor a brlet idtartamnak 87,5%-a is eltelt, az ignyl jra prblkozik. Ha ezttal sem
jr szerencsvel, mr felbred benne a gyan, hogy valami gond van a kiszolglval, ezrt a unicast, vagyis direkt csomag
helyett ismt elveszi a rgi trkkt, szrt zenetet kld a hlzatra, htha van ott DHCP-szolgltats, csak egy msik
szerveren. Ms kiszolglk persze DHCP-Nack csomagot kldenek, de sebaj, ekkor jraindul a cmignylsi eljrs, a
vgeredmny pedig egy j brlet kiadsa.
Ha minden jakaratunk ellenre 87,5%-nl sem sikerl a brlet megjtsa (mg az jra bevetett 4, 8, s 16 msodperces
jraprblkozs ellenre sem) a kvetkez krelem a brlet lejratakor esedkes. A sikertelensgnek mr kommunikcis
kvetkezmnyei vannak. Ha a rendszer ismeri az APIPA mdszert, azzal szerez cmet, de ha nem ismeri (Win95, NT4), cm
(s hlzat) nlkl marad.
Nhny sz elljrban a DHCP megbzhatsgrl
Miutn ttekintettk a lehetsges zenetvltsokat, vizsgljuk meg, hogy egyetlen kiszolglval, s nmi gyes belltssal
milyen rendelkezsre llst tudunk biztostani. A DHCP egy alapvet szolgltats, a legfontosabb krds mindenek eltt
teht az, vajon mennyire bzhatunk benne.
Lttuk, brmely gyfl, amely kpes eltrolni a sajt brletre vonatkoz informcikat, a DHCP-kiszolgl nlkl is kpes
hasznlni a brlett, st az sem problma egy darabig, ha a megjts nem sikerl. Egy egyszer jraindtst a felhasznlk
nem vesznek szre. Az is bizonyos, hogy a kiszolgl kiesst nem ugyanakkor szlelik majd a kliensek, hanem a brletk
lejratakor. Az albbi bra mutatja, hogy egy tlagos gyfl vlheten a brletid negyednl jr (de nem zrhat ki, hogy
van olyan delikvens, amely mr kitlttte a sajt idejt, pl. napokig nem volt bekapcsolva).
3
NetAcademia-tudstr
Az gyflszmtgpek eloszlsa az eltelt brletid fggvnyben

Mennyi ideig llhat egy DHCP-szolgltats? A hiba nem azonnal jelentkezik, hanem aprnknt. Elbb egy gp esik ki, majd
mg egy, majd egyre tbb. Ha a brletid felnl tovbb ll a szerver, az gyfelek tbbsgt rinteni fogja. Ebbl viszont az
kvetkezik, hogy a brletid nvelse a hiba eszkalldsnak sebessgt cskkenti. Ha teht csupn egyetlen szervernk
van, s vlheten csak lassan tudjuk megjavtani a DHCP-kiszolglt, nyugodtan nveljk meg a brleti id hosszt (persze
mg a hiba eltt), gy vlheten nagyon kevs gp esik ki, amg a problmt elhrtjuk. Szegny ember statisztikai alapon
biztosthat magasabb rendelkezsre llst.
No persze gp s gp kztt jelents klnbsg lehet. Ha ne adj Isten pp a fnknk gpe, vagy az fnknek a PC-je
nem mkdik, nincs mrlegelsi lehetsgnk, gyorsan kell cselekednnk s javtanunk. A jvbeli fejmossok elkerlse
rdekben pedig elbb-utbb gondoskodni kell valahogyan a kiszolgl tbbszrzsrl. Sokfle lehetsgnk van,
knyelmesek s drgk, olcsbbak s tbb beavatkozst ignylk. A kiszolgl funkciinak ismertetse utn visszatrnk
mg a rendelkezsre lls krdsre, mr csak azrt is, mert sszetett DHCP belltsoknl nem is mindig knny
megoldani a problmt.
A DHCP rejtett szpsgei II.

A Windows-rendszerekben mkd DHCP-kiszolgl teleptse tbb, egymstl
fggetlen lpsbl ll. A hitelests buktatinak ismertetse s az els cmtartomny
ltrehozsa utn azt vizsgljuk, milyen integrcit lehet megvalstani a cmkioszt s
a nvfelold szolgltatsok kztt.
A DHCP-kiszolgl teleptse magtl rtetd: a funkcit a Windows-komponensek hlzati szolgltatsai kztt talljuk. A
teleptssel azonban mg nem kapunk azonnal zemksz eszkzt. Ha tartomnyi krnyezetben, Active Directoryval
dolgozunk, el kell vgeznnk egy n. hitelestsi eljrst, s - krnyezettl fggen - be kell lltanunk, hogy milyen adatokat
szeretnnk az gyfelek fel kzvetteni.
A DHCP hitelestse
A hitelests biztonsgi okokbl szksges. Ha brki telepthet DHCP-kiszolglt, s azt konfigurlja, knnyen elfordulhat
(s a funkci meglte azt mutatja, el is fordult), hogy helytelen paramtereket kapnak, majd furcsa, nehezen megfejthet
tneteket produklnak a munkallomsok. Elfordul, hogy nem kpesek a helyi hlzaton tli gpekkel kommuniklni (rossz
az alaprtelmezett tjr paramter), vagy mr a cmet is rossz tartomnybl veszik (nem megfelel a scope). A gondokat
megelzend a DHCP ellenrzi, hogy az Active Directory szmon tartja-e a neki helyet ad kiszolglt a hitelestett DHCPszerverek listjn. Ha a megfelel bejegyzs hinyzik, a szolgltats lell, s az esemnynaplban elhelyez egy rvid
magyarzatot tartalmaz hibazenetet.
A hitelestst a DHCP-konzol segtsgvel vgezhetjk el, ha tagjai vagyunk a gykrtartomny Enterprise Administrators
csoportjnak. Ez egy meglehetsen fontos momentum. A klnbz magyarorszgi Windows 2000 eladsokon azt
hallhattuk, hogy a mi zleti letnkben elegend egyetlen tartomnyt ltrehozni. A ktsgtelen elnyk (egyszersg,
tlthatsg, bizonyos bonyolult szitucik elkerlse) mellett azonban ez a szerkezet htrnyos is lehet. Egyetlen
tartomnyban, amely egyben a gykrtartomny is, a Domain Administrators csoport tagjai brmit megtehetnek. Ha el is
vesznek tlk jogokat, azokat kpesek visszaszerezni, mg a restricted groups csoporthzirend-trkk sem akadlyozhatja
ket.
A problmt gy lehet megoldani, ha az AD tervezsekor a gykrtartomnyt egy res domainnek tervezzk, s alatta
ptjk ki a valdi adminisztrcis egysgnket. A gykr adminisztrtorainak (szmbeli) korltozsval mr knnyedn
elrhetjk a clunkat, nevezetesen, hogy ne vgezhessen el akrmilyen mveletet egy rendszergazda, csak ha erre kln
4
NetAcademia-tudstr
engedlyt kapott. (Technikai rtelemben a hitelests egyetlen felttele, hogy az AD NetServices kontnerhez teljes
hozzfrsi joggal rendelkezzen a felhasznl.)
A fenti sma a DHCP szerverek esetn nagyon ers kontrollt jelent. Tbb szz telephely megltekor is legfeljebb 2-3
hozzrt kezben sszpontosul a cmkioszt szolgltats engedlyezse. (Tovbb a RIS szerverek is, ahogy ez majd
ksbb lthat.) Ezzel egytt a hitelests eljrsa deleglhat az AD delegcis mechanizmusn keresztl.
s van let az AD-n kvl? Igen van: Novell, Linux, st NT4-es DHCP-kiszolglk nem veszik figyelembe a Windows 2000
cmtr korltozst, teht az igazn rosszakar tehet krt a kontrkodstl s figyelmetlen zemeltetktl azonban az AD
megvd.
Azt az eljrst, amely a hitelests megltt ellenrzi a Windows 2000 s 2003 szerverek rouge detection mveletnek
nevezik. A kiszolglk, amelyek az ellenrzst vgzik, eltr mdon viselkednek attl fggen, hogy tagjai-e egy Active
Directory tartomnynak, vagy sem. Ha AD-tagok (tagkiszolglk, vagy tartomnyvezrlk), egy LDAP-lekrdezst
kezdemnyeznek, hogy megllaptsk, tagjai-e a hitelestett kiszolglk listjnak. Igenl vlasz esetn tovbb mkdnek,
egybknt lellnak.
Ha a Windows 2000 kiszolgl nem tagja AD-tartomnynak, hanem gynevezett stand-alone, vagyis munkacsoport
zemmdban fut, vagy egy NT4 tartomny tagja, a DHCP-szerver indulsakor egy DHCP-INFORM szrt zenetet helyez el
a hlzaton. Ez az zenettpus szmos gyrtspecifikust opcit tartalmaz. A csomaggal a kiszolgl ms DHCP-szervereket
keres, amelyek egy AD gykrtartomnyban helyezkednek el. A krt opcik alapjn a megclzott DHCP-szerverek
informcikat kldenek vissza a gykrtartomnyrl. A vlasz DHCPACK csomagban rkezik. Ezzel a mdszerrel egy (de
akr tbb) gykrtartomnyrl is tudomst szerezhet az pp indul DHCP-szolgltats. Ha nincs AD a helyi hlzaton, a
szolgltats elindul, de minden tdik percben DHCP-INFORM csomagot bocst ki, tovbb kutatva a Windows 2000 cmtra
utn.
Ha mr az els csomagra is rkezett vlasz, minden egyes felfedezett gykrtartomny fel egy lekrdezst indt a DHCPkiszolgl, hogy ellenrizze, tagja-e a hitelestett szerverek csoportjnak. Amennyiben egyik listn sem tallja magt, a
szolgltats lell. Ez azt jelenti, hogy nem kell felttlenl egy Windows 2000 szervernek tartomnytagnak lennie, hogy
rvnyes legyen r a hitelestett szerverek listja!
Szerverkonfigurci
Miutn szerencssen testnk a hitelestsi eljrson, igazn nekieshetnk az rdemi konfigurcinak.
Az els feladat a megfelel scope (brlettartomny) ltrehozsa. Ezt egy varzsl segti: meg kell adnunk a kezd- s a
vgs cmet, amelyet a scope-on bell a szolgltats kioszthat, az alhlzati maszkot, a brletidt s a kivteleket, vagyis
azokat a cmeket a tartomnyon bell, amelyeket mgsem lehet kiosztani. Miutn vgeztnk, megjelenik egy scope a konzol
bal oldaln. A kvetkez bra az ltalnos tulajdonsgokat mutatja.
A legproblmsabb krds a brletid meghatrozsa. A rendszer ht napot ajnl fel s ltalban ezt el is fogadhatjuk.
Szmos megfontols azonban amellett szl, hogy gondoljuk t alaposan ezt az rtket. Elmletileg a hosszabb brletid azt
jelenti, hogy a gpek kevesebbet kommuniklnak a kiszolglval, vagyis nem terhelik azt. Htnapos brletid esetn hrom
s flnaponta kldenek brletmegjtsi krelmet, mg pldul 28 napos brlet esetn csak tizenngy naponta ltszlag ez
tiszta haszon.
A scope legfontosabb adatai

Csakhogy a megtakarts egyedl a soha ki nem kapcsolt gpekre vonatkozik, mert az indul DHCP gyfelek mindenkpp
krnek cmet a szervertl. A nyeresg teht csekly. Ezen mg az sem segt, ha vgtelenre lltannk a brletidt st
azzal csak rosszabbul jrunk. A brletid vgtelenre lltsa azt jelenti ugyanis, hogy a brletidnek nincs fele, teht nem kell
krni a meghosszabbtst sem. A vgtelen idre kiadott cm elvsz, nem hasznlhat jra. Ezrt azt javaslom, hogy sohase
adjunk meg vgtelen hossz brletet! A tl rvid id sem j, mivel sok gyfl esetn ez a reggeli cscs mellett is valban
nagy forgalomhoz vezet.
5
NetAcademia-tudstr
A legclszerbb megbecslni az gyfelek s a kioszthat cmek arnyt. Ha sok gyflre jut relatve kevs cm, clszer
rvid brletet megadni (pl.: 3 nap) Ha sok cmnk van s kevs gyfelnk, a cmkioszts szlhat akr 15, vagy 30 napra is.
A cmtartomny kijellsvel s ltrehozsval azonban mg korntsem kapunk mkd szolgltatst. Egy Windowsos
krnyezetben meg kell adnunk nhny nagyon fontos opcit (konfigurcis paramtert) is, amely az gyfeleket eligaztja. A
kvetkez bra egy ilyen listt mutat be.
Az t kritikus opci Windows krnyezetben

Mindenekeltt tudatni kell az gyfelekkel az alaprtelmezett tjr cmt az opci szma 003, s magyarul az tvlaszt
nevet kapta a keresztsgben, ami esetleg kiss flrevezetheti a kezd rendszergazdkat.
Windows 2000 krnyezetben kritikus, egybknt is mind fontosabb a DNS kiszolglk adatainak pontos belltsa. A 006
opci teszi lehetv akr tbb kiszolgl megadst is. A fontossgot a sorrend jelzi.
A tartomnyi gyfelek szmra meg kell adni, hogy a hostnevkhz milyen DNS suffix-et, vagyis tartomnyi kiegsztst
biggyesszenek. Ha a gp hostneve mal-001, mostantl az gyfl tisztban lesz a teljes nevvel: mal-001.mal.priv.
(Egy klns hibval tallkoztam nem is olyan rgen. A jelensg az volt, hogy a kliensnk mindenron a proxy szervernket
akarta hasznlni egy bels weblap elrshez is, holott nem ez volt a kvnatos. Kiderlt, hogy egy elvigyzatlan kollgnk
egy hibs DNS suffixet adott meg kzzel ami fellrta a DHCP belltsokat. A Helyi intranet cmek esetn a proxy
figyelmen kvl hagysa bellts ezrt nem mkdtt. A paramter trlse s egy jraindts segtett. Tanulsg: semmit se
konfigurljunk az gyflgpeken az IP belltsok kztt!!)
A DNS kiszolglk mellett termszetesen meg kell adni a WINS szerverek cmt a 044-es opciban. Vgezetl a 046-os
paramterre is szksg van, ezzel definiljuk, hogy a NetBIOS szabvnyt hasznl gyfelek milyen stratgit folytassanak a
nvfeloldshoz. A legelterjedtebb a hibrid-node zemmd, ennek a kdja a 0x8. A lersunk keretein tlmutat a NetBIOS
nvfeloldsi stratgik ismertetse, de egy korbbi technet cikkben ez fellelhet, esetleg a Q119493-as cikk tisztzza az
idetartoz NetBIOS fogalmakat.
(Ha ragaszkodunk a technikai rszletekhez, el kell mondanunk, hogy tulajdonkppen szinte minden adat DHCP-opciknt jut
el az gyfelekhez, mg akkor is, ha a kezeli felleten mshol lltottuk is be. Az alhlzati maszk a 001-es, a brlethossz a
051-es, a megjtsi id a 058-as, ez alaprtelmezetten 50%, s a cmkrsi id, 059-es, amely ltalban 87,5%. A
Windows-gyfelek a fenti opcikon kvl mst nem vesznek figyelembe.)
A DNS s a DHCP egyttmkdse
A scope tulajdonsgai kz tartozik a DNS-sel val egyttmkds definilsa is. Windows 2000 s AD krnyezetben ez
nagyon fontos paramtercsoport. Lssuk rszletesen, mirl van sz.
Engedlyezhetjk, vagy tilthatjuk, hogy a DHCP-kiszolgl automatikusan frisstse az gyfelei DNS znarekordjait.
Amennyiben engedlyezzk a frisstst, vlaszthatunk, hogy csak az gyfl krsre trtnjen a regisztrci, vagy
mindenkpp vgezze el a DHCP-szolgltats. Hogyan mkdik mindez?
A Windows 2000 s Windows XP a sajt DHCPREQUEST csomagjban hasznl egy 81-es opcis szmmal rendelkez,
Fully Qualified Domain Name nev mezcsoportot, amelyben meghatrozza, hogy a DHCP-kiszolgl mikpp regisztrlja a
megfelel rekordokat a DNS adatbzisban. Szmunkra a mezcsoport harmadik tagja rdekes, amely a kvetkez rtkeket
veheti fel:
0 az gyfl regisztrlja a sajt hostrekordjt.
1 az gyfl azt szeretn, hogy a DHCP-szerver regisztrlja a hostrekordot
3 a DHCP szerver frissti a hostrekordot az gyfl belltstl fggetlenl.
6
NetAcademia-tudstr
A DHCP s a DNS szolgltatsok egyttmkdnek, ha ez mi belltjuk

A rtkek kztt nem tallhat olyan, amely a PTR rekordokra vonatkozna. Azt minden esetben a DHCP-kiszolgl
jegyezteti be, kivve, ha a DHCP-szerver nem ismeri a 81-es opcit. A Windows 2000 s XP kliensek ezt felismerik, s k
vgzik rekordfrisstst a DNS-szolgltats megfelel reverse lookup znjban.
A opci rtknek belltst a TCP/IP konfigurcis paneljben lehet elvgezni, mg ha ez elsre nem is tnik fel.
A titokzatos 81-es opci a kezelfelleten

A bekarikzott jellngyzet bekapcsolt llapotban gondoskodik arrl, hogy az gyfl a DHCP-Request csomagban a 81-es
opciban 1-es rtket kldjn a szervernek.
Vajon mikor rdemes az gyflre s mikor a kiszolglra bzni a rekordfrisstst? Nos, ltalban mindegy, hogy a feladatot ki
vgzi el. Ha azonban olyan DHCP-gyfelnk is van, amely tbb hlzati krtyval is rendelkezik (multihomed), a kliensekre
kell hagyni a regisztrcit pp gy, ahogy a korbbi brn lthattuk. A DHCP-szolgltats ugyanis egy gyflhez csak
egyetlen A rekordot jegyez be, illetve fellr minden korbbi bejegyzst, ami a tbblb gpeknl nem elnys.
Szintn nem ajnlott a DHCP-kiszolglkra bzni a DNS-rekordfrisstst, ha a DNS csak biztonsgos rekordfrisstst vr el
(secure update). Ebben a szituciban a bejegyzsnek a DHCP-szolgltats vlna a tulajdonosv, ami gondot jelenthet. Ha
pldul egy NT4-es gyfl DNS rekordjnak bejegyzst a DHCP-szerver vgzi el, majd a gpet frisstjk Windows 2000-re,
az j rendszer nem lesz kpes a sajt rekordjnak a kezelsre, mert nem a tulajdonosa. Hasonl helyzet alakulna ki, ha
kt (egymsnak tartalk) DHCP kiszolgl kzl az egyik meghibsodik. Ugyanazt a hostcmet a tartalk DHCP-szerver nem
frisstheti, mert nem tulajdonosa. Summa summrum: biztonsgi frisstskor ajnlatos megfontoltan hasznlni a DHCP s a
DNS ilyen irny integrcijt.
s mi trtnik, ha az gyfl nem is ismeri a 81-es opcit? Ilyen kliensek a Windows NT4, Win95, Win98. Szmukra is kpes
a regisztrci elvgzsre a DHCP, ha a zna tulajdonsgai kztt az utols jellngyzetet bekapcsoljuk.
Vgezetl addik a krds: mirt van szksg a DHCP-n keresztli dinamikus frisstsre? Mirt kell a dinamikusan vltoz
gyfelek cmt regisztrlni? Egyszer: korbban a Microsoft gyfeleket szrt csomagokkal, ksbb a dinamikus regisztrcit
lehetv tv WINS nvfelold szerverek segtsgvel lehetett megtallni. Ha egy munkallomson mkdik egy megosztott
7
NetAcademia-tudstr
nyomtat, arrl a szolgltatsrl a WINS-adatbzis tartalmazott egy bejegyzst, a browser szolgltats egy erforrslistban
trolta, s egy WINS-hez cmzett nvfeloldsi krelem utn knnyedn fel lehetett venni a kapcsolatot azzal a bizonyos
munkallomssal. A NetBIOS-szabvnyok eliminlsval azonban a fenti mechanizmusbl semmi sem marad: nincs
broadcast, sem WINS, sem browser szolgltats. Van viszont Active Directory az erforrs nyilvntartsra, LDAPlekrdezs a megltnek ellenrzsre, dinamikus kpessgekkel felvrtezett DNS a nvfeloldshoz st az j kliensek
esetn mg dinamikusan frisstett DNS-bejegyzsek is. A rgebbi opercis rendszerek viszont mit sem tudnak az j idk j
szeleirl, s k bizony nem kpesek a DNS-bejegyzs frisstsre. Ha azonban valami ezt elvgzi helyettk, a korbbi
NetBIOS-funkcionalits minden vonatkozsban megmarad, csak j szabvnyokkal. Egyszer taln alaposan vgig kellene
gondolni, hogy a klnbz NetBIOS-funkcikat s szolgltatsok mi mdon cserlte fel a Microsoft natr TCP/IP
megoldsokkal szigoran ragaszkodva a meglv RFC-khez. De ez mr egy msik trtnet.
Q119493 NetBIOS over TCP/IP Name Resolution and WINS
Q191290 Description of How DHCP Integrates Dynamic DNS
Q289583 DHCP Server Does Not Update the A Record on the DNS Server If Option 81 Is Received with the S Bit Set
A DHCP rejtett szpsgei III.

Elz alkalommal teleptettnk s cmtartomnnyal szereltnk fel egy DHCPkiszolglt, majd elkalandoztunk a DNS- s DHCP-integrci terletre. Most mg egy
rvid idre visszatrnk a scope-okhoz, s alaposan szemgyre vesszk, milyen
rszei vannak, s milyen lehetsgekkel rendelkeznk a cmtartomnyok
kiterjesztsre.
A scope kzponti fogalom a DHCP-szolgltats kialaktsakor. Miutn a varzsl segtsgvel ltrehoztunk egyet, rdemes
alaposan megvizsglni a kezelfelletet, hogy lssuk, hogyan finomthatjuk mg a belltsokat.
DHCP-kiszolgl egy scope ltrehozsa utn

A cmtartomny bellrl
A scope tulajdonsgairl s a legfontosabb opcikrl mr rtekeztnk, de a kizrt s lefoglalt cmekkel (reservations),
valamint a specilis scope tulajdonsgokkal mg nem foglalkoztunk.
A fenti brn lthat, hogy a cmtartomny definilsa mellett azonnal meg kell adni azokat a cmeket vagy cmintervallumokat, amelyeket a teljes cmtartomnyon bell szeretnnk kizrni a kiadhat IP-cmek kzl. A kizrs persze
nem ktelez, de nha kifejezetten hasznos. Ha pldul vannak lland, statikus IP-cmet ignyl kiszolglk vagy egyb
aktv eszkzk, switchek, nyomtat-szerverek, s azok cmei bekeldnek egy rvnyes cmtartomnyba, a kizrs
mdszervel megakadlyozhatjuk, hogy a DHCP-szerver egy msik gyfl rendelkezsre bocsssa az ominzus
azonostt. Jobb helyeken, ahol ezek az eszkzk eleve egy elklnlt cmtartomnybl rszeslnek, vagy lefoglalt cmeket
kapnak a hostok, erre kln nincs szksg. A kizrs funkci ott is hasznlhat, amikor kt DHCP-szolgltatssal magasabb
rendelkezsre llst szeretnnk biztostani, de errl majd ksbb.
A kiadott cmek listja
Nem elhanyagolhat haszonnal jr, ha szeretnnk bepillantani az pp kiadott cmek listjba. Ha egy lloms MAC-cmt
szeretnnk megtudni, vagy csak egyltaln az IP-cmre vagyunk kvncsiak, a kiadott cmek listjnak tblzatt kell
tbngsznnk. A konzol informcikat is szolgltat a brletek kiadsrl s lejrati idejrl is. Ha szksges, trlni is lehet
egy rekordot, m ez csak nagyon krltekint mdon ajnlott. Egy cm trlse hasonl hatssal van a hlzatra, mint amikor
8
NetAcademia-tudstr
egy brlet vglegesen lejr, azzal a klnbsggel, hogy a brletet hasznl gyfl aktv maradhat, s hasznlhatja a cmet,
hisz semmifle rtestst a rekordtrlsrl nem kap. A cm radsul felszabadul, amit les krnyezetben egy msik lloms
megkaphat, ezltal kt lloms is ugyanazzal a cmmel rendelkezhet. Csak akkor javaslom teht brlet trlst, ha az IPcmet szeretnnk felvenni a kizrt vagy a lefoglalt cmek kz. Az utbbi esetben az gyfl oldaln mindenkpp el kell
vgezni egy ipconfig /renew mveletet is.
A lefoglalt cmek listja
Gyakran sszekeverik a kizrt s a lefoglalt cmeket, holott ez utbbiak ms clt szolglnak. Ha szeretnnk minl tbb
gyfelet a DHCP-szolgltats kliensei kztt tudni, de nhny esetben bizonyosan ugyanazt az IP-cmet kellene kiadnunk
egy-kt llomsnak, a lefoglalt cmek kz kell felvennnk az gyfl adatait, s mindkt kvnsgunk teljeslt. A lefoglalt
cmek funkci azrt mkdik, mert a DHCP kpes a cmignyl csomagbl megllaptani az adott lloms hardver-cmt
(Ethernet hlzat esetn ez a MAC address), s ha tall ehhez a bejegyzshez egy lefoglalt cmet, azt fogja minden esetben
kiajnlani. A reservations mkdsi elvbl kvetkezik, hogy ha egy cmet kizrtunk, akkor az nem lehet egyben lefoglalt
cm, s fordtva, a lefoglalt cmeket nem szabad kizrni. Br ltszlag trivilis dologrl van sz, mgis nagyon gyakori
konfigurcis hiba, hogy a lefoglalt cmeket megprbljk kizrni, nehogy vletlenl is ms kapja meg, vagy mert a
lefoglalt cm nem jtszik, az msra nem hasznlhat, teht ki kell zrni. Mindez a fogalmak pontatlan ismeretbl fakad. A
hrom cmtpus egymshoz val viszonyt egy brn is megjelentettem, hogy az olvas mr soha tbb ne tartozzon az
ilyen hibkat elkvetk kz.
Cmtartomny
Kizrt
cmek
Lefoglalt
cmek
A cmtartomny, a lefoglalt cmek s a kizrt cmek viszonya
Visszatrve a lefoglalt cmekhez: ismernnk kell, miknt viselkedik a kiszolgl, ha olyan cmek kzl foglalunk le egyet,
amely korbban a cmtartomny norml cmei kz tartozott, s amelyet esetleg egy msik lloms mr ignybe vett.
Ilyenkor vagy meg kell vrnunk a brlet vgt, vagy az adott gyfelet r kell szortanunk, hogy engedje el a cmet.
NT/2000/XP rendszereknl az ipconfig /release paranccsal rhetjk el ezt, a Win9x vilgban pedig a winipcfg nvre
hallgat kis grafikus program siet a segtsgnkre. Egybknt a brlet kiadsa szintn nem automatikus, vagyis attl, hogy
a lefoglalt cmet rgztettk, mg nem kapta meg azt az gyfl. A kliensgpen kiadott ipconfig /renew parancs azonban
ltalban meghozza gymlcst: a friss lefoglalt cmet.
A lefoglalt cm nagyon hasznos szolgltats. Egy hlzatban rengeteg olyan lloms mkdhet, amely lland IP-cmet
ignyel. Hromszz munkallomshoz mr akr fltucat switch, 10-20 hlzati nyomtat, tbb szerver tartozhat, amelyeket
mind-mind lland cmmel kell elltni. Egy IP-cm vagy hlzati maszk-vlts rengeteg munkval jr, ha statikus cmekkel
dolgozunk. A manulis munka ugyanakkor mindig magban rejti a hibzs lehetsgt is. Knnyen kimaradhat egy DNS-cm
vagy az id-szerverek megadsa, s mris megjsolhatatlan hibk tnnek fel a rendszerben. A lefoglalt cmekkel mindez
elkerlhet, a vltozsok bizonyosan rvnyre jutnak. Hasonl mdon lehet leszerelni azokat a megoldsszlltkat, akik egy
monitoroz, tarifikl vagy egyb berendezst szlltanak, s ktik az ebet a karhoz a statikus IP-cmrt. Bven megteszi
egy lefoglalt cm is. Egy tkletes hlzatban szinte csak a WINS s DHCP-kiszolglk rendelkeznek statikus cmekkel.
Mveletek a cmtartomnnyal
Ahhoz, hogy egy scope ellssa feladatt, aktivlni kell. Csak aktv scope bocst ki IP-brleteket. A mvelet rendkvl
egyszer, csupn a jobboldali egrgombbal kell kattintani a cmtartomnyon, majd az aktivlst vlasztani. A scope
deaktivlsval megsznik a korbbi funkcija. Csak nem aktv cmtartomnyt lehet trlni.
A cmtartomny krl a legnagyobb felhajts akkor keletkezik, amikor a rendelkezsre ll cmek elfogynak. A brletid
rvidtsvel lehet mg orvosolni a cmhsget, a hossz tv megolds azonban mindenkppen a scope talaktsa.
Elsre azt gondolhatnnk, hogy knyelmesen tlltjuk a cmtartomny tulajdonsglapjn a kezd s a vgs cmet, st akr
az alhlzati maszkot, s mr kszen is vagyunk. Sajnos, ez egy jrhatatlan t. A szabvny szerint nem nagyon lehetne
nyomon kvetni, hogy melyik brletet milyen cmtartomny-paramterekkel adtuk ki. Sok kiadott cm kikerlhetne az
rvnyes brletintervallumbl, esetleg rvnytelen lenne az alhlzati maszk, egyszval kavarods lenne. Hrom
lehetsgnk maradt a problma megoldsra:
- a scope kiterjesztse
- az alhlzat jrakonstrulsa (resubnetting)
- Superscope-ok alkalmazsa (multinetting)
A cmtartomny kiterjesztse
9
NetAcademia-tudstr
A scope megvltoztatsnak egyetlen jrhat tja a kiterjeszts. Ha az eredeti cmtartomny kisebb, mint az alhlzati
maszkja alapjn az lehetsges lenne, akkor md van a tartomny vgs cmnek kitolsra. Pldul a 192.168.0.1 192.168.0.100 cmtartomnyunkat 255.255.255.0 maszkkal, kiterjeszthetjk 192.168.0.254-ig mindenfle kros
kvetkezmny nlkl. A kiterjeszts lehet tbblpcss is, s az alhlzat elmleti hatrig tarthat. Korbban (a Windows NT
4.0 szervernl) csupn 32-esvel lehetett a tartomnyt kiterjeszteni, vagyis 100-rl 132-re kellett volna nvelni a tartomny
hatrt. A SP6-tl kezdve ez a ktttsg mr nem ltezik. Amennyiben eleve belefoglaltuk a scope-ba az alhlzat engedte
sszes cmet, ezt a mdszert nem alkalmazhatjuk.
Az alhlzat jrakonstrulsa (resubnetting)
Ha egy subnet maskot gy alaktunk t, hogy az egyre kisebb szmokat tartalmaz, akkor az alhlzatban rendelkezsre ll
cmek szma megn. Nagyszer, pp ezt szeretnnk. Csakhogy ennek komoly ra van. Az alhlzati maszk meghatrozza
az alhlzatot, vagyis: j maszk, j hlzat. Ezt az j hlzatot meg kell ismertetni valamennyi tvlasztnkkal, t kell
lltanunk az sszes statikus IP-cmmel rendelkez llomsunkat, tovbb el kell dobnunk a mr ltez scope-ot s az
sszes brletet, ltre kell hozni egy jat. Erre azrt van szksg, mert egy scope az alhlzati maszkja alapjn csak egyetlen
logikai alhlzatnak szolgltat cmet, kettnek nem. Ha sok gppel dogozunk, s nem kivitelezhet a mvelet rvid id alatt,
akkor biztostani kell a kt hlzat kztti kommunikcit az alaprtelmezett tjrk tkonfigurlsval. Summa summarum,
az alhlzati maszk megvltoztatsa hatkony ugyan, de nem stagalopp.
Superscope-ok alkalmazsa
A superscope a Windows NT4 SP2 verzija ta ismert fogalom, lnyegben a cmtartomnyok egybefogst jelenti.
Kt cmtartomny alkotta superscope

Ha szeretnnk egyetlen fizikai alhlzaton tbb logikai (IP) alhlzatot zemeltetni, azt csupn scope-ok segtsgvel nem
knny megvalstani. A DHCP-kiszolgl minden gyflnek a legelszr aktivlt cmtartomnybl hajland cmet adni.
Csupn azt tehetnnk, hogy egy msodik hlzati krtyt is zembe helyeznnk, majd elltnnk az j alhlzatbl szrmaz
cmmel, vgl ltrehoznnk a msodik scope-ot is. Minden tovbbi (logikai) alhlzat egy tovbbi hlzati krtyt ignyelne.
Ettl a barkcsolstl kml meg minket a superscope.
Tegyk fel, hogy van egy hlzatunk, ahol minden aktv eszkz egyben DHCP-gyfl is. Szeretnnk elklnteni az aktv
elemeket cm szerint is a munkallomsoktl. Mivel a switchekkel csak a hlzati adminisztrtorok kommuniklnak az IPcmeken keresztl, a nem tlsgosan nagy forgalom miatt az elklnts utn nem keletkezik szk keresztmetszet. A
superscope segtsgvel a feladat megoldsa knny.
Elszr ltre kell hoznunk egy 192.168.0.11-192.168.0.254 cmtartomnyt a megfelel alhlzati maszkkal s egyb
opcikkal. Ezutn el kell kszteni egy msodik scope-ot is, amely a 172.16.0.0/24 hlzatot foglalja magban, m rgtn
valamennyi cmet ki kell zrni, az els hrmat kivve. Ez utbbiakat mint elre lefoglalt cmet kell rgzteni a hlzati
kapcsolk MAC cmvel egytt. Vgezetl ltre kell hozni egy superscope-ot, majd a kt korbbi cmtartomnyt a
superscope tagjv kell tenni.
10
NetAcademia-tudstr
DG.
IP Address1: 172.16.0.245
IP Address2: 192.168.0.254
172.16.0.3
172.16.0.2
172.16.0.1
192.168.0.14
192.168.0.13
192.168.0.12
DHCP-kiszolgl
Scope1: 172.16.0.0/24
Scope2:192.168.0.0/24
192.168.0.11
Egy alhlzat kt logikai IP-hlzattal

Ezzel kszen is vagyunk. A kt alhlzat kztti kommunikcit az alaprtelmezett tjrn felvett tvonalbejegyzs
segtsgvel lehet biztostani, szksg esetn szrve az tvonalat hasznl llomsok szmt, cmt. (Csak zrjelben
jegyzem meg, hogy a superscope-ok nem csak a helyi hlzatokon tmogatjk a tbb logikai alhlzatot, hanem tvoli
routereken tli - hlzatokon is. Ezeket a kpessgeket a DHCP Relay Agent trgyalsakor mg rintjk. A fenti
172.16.0.0/24 jells a tovbbiakban tbbszr szerepel majd. Azt jelenti, hogy az alhlzati maszkban 24-db 1-es szerepel,
ami decimlisan 255.255.255.0-t jelent.)
A superscope-ok fenti kpessgei hasznosak a cmtartomnyok kiterjesztsekor. Elegend egy msodik cmtartomnyt
definilni, majd az els scope-pal egy superscope-ot alkotni, a cmtartomny kiterjesztse mris megtrtnt.
A cmtartomnyok sszefogsa az alhlzat jrakonstrulsakor is j szolglatot tesz. Az j alhlzat bevezetse egy
superscope segtsgvel a legegyszerbb. Bele kell foglalni az j s a rgi cmintervallumokat, a rgi scope-ot pedig gy kell
mdostani, hogy valamennyi cmt ki kell zrni. Az gyfelek jraindulsakor mindegyik az j intervallumbl kap majd
cmeket. A statikus llomsok, valamint az tvlasztk konfigurlst nem lehet megszni.
Superscoping, multinetting, supernetting
MCP vizsgra kszl szakrt-jelltek tapasztalhattk, hogy nhny vizsgakrds elszeretettel prbl zavart kelteni a fenti
fogalmakkal kapcsolatban a vizsgzk fejben. Az alhlzatok kialaktsa s a superscope fogalmnak ismeretben most
megragadom az alkalmat, s amennyire lehetsges, tisztzom az egymssal rszben sszefgg kifejezseket.
A multinetting azt a szitucit jelenti, amikor egy fizikai alhlzaton tbb logikai (IP) hlzatot hozunk ltre. A multinetting
elmletileg nem ktdik a DHCP fogalmakhoz, gy a superscope-hoz sem, elkpzelhet ugyanis multinet DHCP nlkl.
Gyakorlatilag azonban ilyen szituci csak kivteles esetekben fordulhat el, gy a multinetting szinte mindig a superscope
fogalmval egytt jelenik meg, hisz a superscope a multinet DHCP-tmogatst takarja.
A superscoping s a supernetting sszehasonltsnak az az alapja, hogy lnyegben ugyanazt a clt szolglja mindkt
eljrs, habr teljesen eltr mdon kzeltik meg a problmt.
A superscoping alapvet clja a DHCP-gyfelek ltal felhasznlhat cmek szmnak nvelse az alhlzati maszk
vltoztatsa nlkl. Ennek rdekben jabb IP-alhlzatokat alkalmaz, s egy kzs superscope-ot hoz ltre. A megolds
elnye, hogy viszonylag gyors s egyszer mdszer, a meglv IP-cmek nem vltoznak, s ignytelen megolds,
amennyiben nem szksgszer, hogy a cmtartomnyok egybefggek legyenek. A 192.168.0.0/24-hez hozz lehet fzni a
192.168.3.0/24-et, de akr a 172.16.0.0/24-et is. A mdszer htrnya, hogy szk keresztmetszetet hoz ltre, hiszen a
klnbz alhlzatok kztt az adatforgalom az alaprtelmezett tjrn keresztl ramlik, tovbb az llomsoknak nincs
kzs broadcast cme.
A supernetting clja ugyancsak a kioszthat cmek nvelse, de a fenti megoldstl eltren az alhlzati maszk
vltoztatsval. Minl kisebb szmok szerepelnek a maszkban, annl tbb host-cm ll rendelkezsre. A 255.255.255.0
maszk 254 lehetsges llomscmet jelent, mg a 255.255.252.0 mr tbb mint ngyszer ennyit. Ha az eredeti cmtartomny
192.168.0.0/24 volt, az j pedig 192.168.0.0/22, akkor a 192.168.0.1-192.168.0.254 cmintervallum 192.168.3.254-ig bvl.
A supernetting egy folytonos cmtartomnyt eredmnyez, a DHCP tmogatsa pedig megoldhat egyetlen scope-pal. Nem
keletkezik szk keresztmetszet, s van kzs broadcast cm is. Htrnya a mdszernek, hogy minden cm megvltozik, mg
akkor is, ha egy host nvlegesen ugyanazt a cmet kapja vissza. A 192.168.0.100/24 ms jelent, mint a 192.168.0.100/22.
sszegzsl azt mondhatjuk, hogy a superscoping s a supernetting ugyanazt a clt (felhasznlhat cmek nvelse) eltr
mdszerekkel, elnykkel s htrnyokkal valstja meg. A konkrt szituci s preferencik hatrozzk meg, hogy melyik
mdszer a clravezetbb.
Lepenye Tams, MCSE 2000
lepenyet@mal.hu
Fontosabb forrsok s ajnlott irodalom:
Q161571 Using DHCP "Superscopes" to Serve Multiple Logical Subnets
Q163055 DHCP Client May Fail with WinNT 4.0 SP2 Multinetted DHCP Server
Q169140 Using DHCP to Assign IP Addresses to Secondary Networks
11
NetAcademia-tudstr
Q174051 DHCP Server Fails to Lease Addresses for New Scope
Q255999 Increasing the Number of IP Addresses on a Subnet
A DHCP rejtett szpsgei IV.

Egy vgs lendlettel megbirkzunk a DHCP utols nagy fogalomkrvel, vagyis az
osztlyokkal s opcikkal. A cikksorozat msodik rszben mr megemltettk a
legfontosabbakat, de tlsgosan nem merltnk el a rszletekben. Most viszont pp
ezt fogjuk tenni, hogy megrtsk, milyen eszkzeink vannak az gyfelek
finomhangolsra, s egyltaln: mi mindenre kpes a DHCP...
Az opcikrl ltalban
Az opcik lnyegket tekintve paramterek, amelyeket az gyfl megkap, feldolgoz vagy ppensggel elvet. A szabvnyt
gy alkottk meg, hogy a DHCP-csomagokban opcik tmkelege, egszen pontosan legfeljebb 312 byte (oktet) vndorolhat
a kiszolglrl a klienshez. Csoportostsukkal vilgos kpet alkothatunk, hogy mikor kell belltani egyet-egyet, s mikor
nem.
Tbbfle rendezs is elkpzelhet. Technikai rtelemben lteznek informciopcik (information options) s
protokollopcik (protocol options). Az informciopcikat explicit mdon be kell lltani, hogy rvnyre jussanak. Az
albbiak mind ennek a csoportnak tagjai:
3
6
15
44
46
47
Router
DNS kiszolgl
DNS domain nv
WINS kiszolglk
WINS/NetBIOS node tpus
NetBIOS Scope ID stb.
A protokollopcikat ezzel szemben csak implicit mdon lehet megadni a brlettartomny ltrehozsval s konfigurlsval,
vagyis egy scope ltrehozsa rszben DHCP-opcik megadsa, mg ha ezt el is rejti a felhasznli fellet.
A brletid megadsval az 51-es, 58-as s 59-es

opcit is belltjuk. A subnet mask opciszma 1.
Az albb felsoroltak mind a protokollopcik kz tartoznak:
51
53
55
Brletid
DHCP-zenettpus
Ignyelt paramterlista
12
NetAcademia-tudstr
Megjtsi id (Renewal time)
Cmkrsi id (Rebind time)
58
59
Ltezik msfajta csoportosts is, ekkor az alapvet jellemz az a hatkr, amelyben a paramter felhasznlhat. Ez alapjn
megklnbztethetnk:
1. Szerver avagy default global opcikat
2. Scope opcikat
3. Class opcikat, amelyek lehetnek User class s Vendor class opcik
4. Kliens opcikat, amiket lefoglalt (reserved client) opciknak is hvnak.
Mindez persze nem jelent pontos egymsba gyazdst. A szerver-scope-client opcik mg jl kvethetk a konzolon is, m
a user class s a vendor class opcik a szp egymsba gyazdst keresztlszelik, mert elvileg brhol elfordulhatnak.
A szerver, a scope s a client opcik egymsba gyazdnak

Az ersorrendet ezzel egytt nem nehz fellltani. A leggyengbb opci-csoport a szerverhez ktdik. Ezek minden
brlettartomnyban rvnyre jutnak, hacsak a scope-ban definiltak fell nem rjk ket.
A brlettartomnyhoz rendelt opcik a leggyakoribbak. Minden gyfl megkapja ket, s amennyiben rti, fel is dolgozza
azokat. Mit is jelent ez pontosan? Nos, elfordul, hogy egy gyfl olyan paramtert is kap, amely t nem rdekli. Pldul egy
Windows for Workgroups 3.11-es gyfelet egyltaln nem foglalkoztatja a hlzatban fellelhet NIS szerverek IP-cme
(Option 41), ugyanakkor egy Linux rendszer szmra meghatroz informcirl lehet sz. A WfW 3.11.-be egyszeren nem
programoztk bele valamennyi opci feldolgozst, gy az csak a szmra relevnsakat fogja megrteni. S melyek ezek?
Ezt mr szintn rintettk korbban, de nem rt ismtelni. A Microsoft gyfelek ltal hasznlt paramterek a kvetkezk:
01
03
06
15
44
46
47
51
58
59
Subnet mask
Router
DNS Servers
Domain Name
WINS/NBNS Servers
WINS/NBT Node Type
NetBIOS Scope ID
Lease Time
Renewal Time (T1)
Rebinding Time (T2)
Inverz szedssel jelltem a protokollopcikat ezeket a rendszer mindenkpp kiadja, ahogy azt mr kicsit korbban lttuk.
Visszatrve az ersorrendhez: a szerveropcikat fellrhatjk a scope-opcik, azokat pedig a kliensopcik. Ezt a sort
sznestik nmikpp az opciosztlyok.
Opciosztlyok (option classes)
Az osztlyokat azrt hoztk ltre, hogy tovbbi finomtsokat vgezhessnk a cmkiosztsi rendszernkn. Nem ktelezen,
de ltalban a scope-on bell definiljuk azokat a belltsokat, amelyeket egy meghatrozott osztlyhoz szeretnnk
rendelni.
Aki figyelmesen megnzi a brlettartomnyhoz tartoz paramterek rszletes listjt, lthatja, hogy az oszlopok kztt
szerepel egy vendor (szllt) s egy class (osztly) elnevezs is. Egy htkznapi opci, pldul a 15-s szlltja
standard, osztlya pedig none.
Ebbl az kvetkezik, hogy egy opcihoz rendelhetnk szlltt s osztlyt is, st akr mindkettt egyszerre. Az albbi brn
lthat, hogy a 002-es a Microsoft Options kategriba tartozik, a 051-es pedig a Default Routing and Remote Access
osztlyba.
13
NetAcademia-tudstr
Szlltk s osztlyok alkalmazs az opcik kztt

Mi is a fenti konfigurci rtelme? A 002-es opci rvnyre jut minden Microsoft Options szllti kategriba es gyflnl.
Melyek ezek? A Windows 98 s annl frissebb, valamint a Windows 2000 s annl frissebb MS rendszerek. Az NT4 mirt
nem? Mert a szabvny, amely az osztlyokat s a szllti opcikat definilta 1997-es keltezs, teht az NT4 megjelense
utn alkottk. s honnan tudja egy Windows 2000-es gyfl, hogy ebbe a szllti kategriba tartozik? Ezt egyszeren
tudja, mert a szlltja beleprogramozta. Brmely szllt (Pl. Xerox, Cisco, Motorola, Ericsson stb., stb.) definilhat sajt
opcikat s sajt szllti osztlyokat, amelyeket azutn a DHCP szolgltats ki tud osztani a megfelel szlltazonostval
rendelkez gyfelek szmra.
Nzzk meg mindezt egy fiktv m mgis lehetsges pldn. Tegyk fel, hogy hlzati nyomtatk gyrtsra szntuk el
magukat, a cg mrkanevl pedig a nem tl fantziads, m jl cseng HunPrint nevet adtuk. A nyomtatnkat felksztettk
arra, hogy egy DHCP kiszolgl segtsgvel tvolrl konfigurlni lehessen azt az idt, ami utn, ha hasznlaton kvl van a
gpnk, automatikusan energiatakarkos zemmdba (standby) vlt. A nyomtat opercis rendszerbe begyaztuk a
megfelel kdot, s tudattuk vele, hogy a HUNPRNT szllti osztly tagja. Ezek utn ezt az osztly ltre kell hoznunk a
DHCP kiszolgln is. A konzolon kattintsunk a jobb egrgombbal a szerveren, majd vlasszuk a Define Vendor classes
pontot. A hrom, elre definilt osztlyt lthatjuk, ezt a listt kell kiegszteni a sajtunkkal.
Szlltosztly ksztse
Ezutn a fenti context-ment jra elcsalogatva definilhatunk egy j belltst a Set Predefinied Options funkci
segtsgvel, st, mg alaprtelmezett rtket is adhatunk neki.
Definiltunk egy sajt opcit a nyomtatinkhoz

Ha a fenti opcit kiajnljuk egy brlettartomnyban, minden eszkz, amely a szllti osztlynak tagja (vagyis a nyomtatink),
gond nlkl alkalmazni fogja.
Persze mi nem fogunk nyomtatgyrtsba kezdeni, de lehetsges, hogy a fenti neves gyrtk egyike-msika lni fog a
lehetsggel, hogy preczebb belltsokkal lssa el a gyrtmnyait a DHCP szolgltats segtsgvel.
A fenti pldval analg mdon lehetsges user class s user class option ltrehozsa is, m ekkor alkalmazhatunk egy
tovbbi trkkt is.
A belltsnl az Advanced flre kattintva kivlaszthatjuk, hogy melyik szllti osztlybl szeretnnk opcit belltani.
14
NetAcademia-tudstr
Elre belltott User class opci alkalmazsa

Az opcik tbbsge a DHCP standard Options szllti osztlyba tartozik. Az azonban, hogy mely user classba soroljuk,
rajtunk mlik. gy lehetsges, hogy egy opcit msik user classba sorolunk, mint az alaprtelmezett. Melyikbe sorolhatjuk? A
Windows 2000 DHCP implementcija 3 elre definilt user classt ismer:
Default user class
Default remote access class
Default BOOTP class

Az elsbe tartozik minden gyfl, aki nem definilt magnak user classt. A msodikba tartoznak a Microsoft gyfelek, ha
betrcsznak, a harmadikba pedig a BOOTP gyfelek.
Ezek kvl termszetesen magunk is ltrehozhatunk user classt. Ha pldul szeretnnk, hogy minden gp, amely a
humnpolitikai osztlyon mkdik, egy alternatv alaprtelmezett tjrt hasznljon, akkor ltre kell hoznunk egy HUMAN
user classt, be kell lltanunk egy 03-as opcit hozz, vgl konfigurlnunk kell valamennyi gpet a humnpolitikai osztlyon.
Ezt a rgi ismers ipconfig paranccsal vgezhetjk el
P:\>ipconfig /setclassid "Local Area Connection" human
Windows IP konfigurci
Az adapter (Local Area Connection) osztlyazonostnak belltsa sikeresen megtrtnt.
P:\>
Sajnos jelenleg egy adott host csak egyetlen user classnak lehet tagja, mivel a szabvny csak egyetlen ASCII stringet
hasznl az gyfelek azonostsra. Ezrt ha van egy human osztlyunk s egy mobil osztlyunk, a mindkt osztlyba
tartoz gpekhez egy kln osztlyt kell definilnunk, pldul human-mobil nven.
A szllti s a user class kztti klnbsget jl szemllteti a fenti kt plda. Br mindkt mdszer az gyfelek szelektv
konfigurlsra szolgl, az egyik a gyrtspecifikus konfigurcis paramterek tovbbtsra terveztk, mg a msik a
rendszergazdk ltal valamilyen kritrium szerint fellltott ad-hoc csoportok elklntett paramterezst segti.
Az brkon egybknt nem vletlenl szerepelt tbbszr is a Default Routing and Remote Access Class. Ennek az
osztlynak a segtsgvel elrhetjk, hogy az RRAS gyfelek csak rvidebb ideig kapjanak DHCP cmeket gy, hogy a 051es opci segtsgvel lervidtjk a brletidt.
Miutn ttekintettk mindazt, amit az opcikrl tudni rdemes, egy elmleti krdst meg kell vlaszolnunk: Vajon mirt nem
alkalmaz szlesebb krben opcikat a Microsoft az opercis rendszereiben? A user class azonostkkal pldul LPR
nyomtatkat lehetne megadni egy-egy osztlynak, vagy be lehetne lltani egy id-kiszolglt stb. stb. Ehelyett a vilgels
szoftvercg ismt letr az Internetes jrt trl s csoporthzirendeket fabrikl (ahol pldul ppgy meg lehet mr adni az
alaprtelmezett tjrt, a DNS szervereket, a DNS prefixet s lehetne mg sorolni).
A vlasz kzenfekv: a DHCP szabvny 312 bjtnyi adatot (paramtert) tovbbthat. Ez bizony egy tisztessges hzirendhez
kevs. Radsul bonyolult adatstruktrk sem kzvetthetk a DHCP segtsgvel. A testreszabhatsga, az gyfelek
megklnbztetse sem tlsgosan kifinomult (pl. az Active Directoryhoz kpest.) Summa summra: a csoporthzirendnek
van helye a nap alatt.
s akkor hossztvon DHCP-re nem lesz szksg? Ht, hossz tvon ott van ugye az IPv6, ami sokkal inkbb kpes
konfigurlni magt, mint az IPv4, teht a DHCP slya valamennyire cskken majd. Az IPv4 vilgban azonban vrhatan
mindig is megmarad, mert az eredeti funkcijra, vagyis az IP cmek kiosztsra tovbbra is ez a legalkalmasabb mdszer.
Ami pedig a Microsoft gyflrendszereket illeti, egyre tbb DHCP-opcit fogadnak el, s mire beksznt az IPv6-korszak,
taln mindet ismerni fogjk de addigra kihal a DHCP.
Szerveroldalon ugyanakkor vrhat, hogy az jabb verzik kvetni fogjk a DHCP szabvnyok vltozst, hiszen nemcsak
Microsoft gyfeleket kell kiszolglniuk, s ms rendszerek esetn ha nincs hzirend marad a DHCP.
lepenyet@mal.hu
15
NetAcademia-tudstr
Felhasznlt s ajnlott irodalom
Q240247 - How to Create a New DHCP User or Vendor Class
Q298844 - DHCP Server Handles the Global User Class Lease Option Incorrectly
Q266675 - Microsoft DHCP Vendor and User Classes
Windows 2000 Resource Kit TCP/IP Core Networking Guide
A DHCP rejtett szpsgei V.

A cmkioszt szolgltats zembehelyezsekor klnsen fontos jl megvlasztani a
helysznt. Egyszer krnyezetben, ha nincs is tbb telephely, ez nem problma, ma
azonban mr egyre tbb sszetett hlzat mkdik. Lehet a topolgia brmilyen
bonyolult, a DHCP szervereknek megfelelen kell mkdnik.
Az egyszer nagyszer?
Tudjuk mr, hogy a DHCP-rendszerek a szrt zenetekre ptenek. Nincs is ms lehetsgk, hiszen a minden
informciramls alapjt jelent egyedi IP-cm kiosztsa a feladatuk. Egy kommunikcikptelen gyfllel
kommuniklnak, s vgl alkalmass teszik ket az adatcserre.
A szrt zenetek azonban a helyi hlzat foglyai, az tvlasztk nem engedik t a broadcast csomagokat ezltal
cskkentve a WAN vonalak s a tbbi LAN terhelst.
A fenti kt lltsbl az kvetkezik, hogy minden DHCP-kiszolgl a sajt LAN-jnak csapdjban kellene vergdnie, s br
helyben nagyszer, tvoli hatsa nincs. A huszros megolds, amely a hlzat aktv tagjaiv teszi az llomsokat, csdt
mond, ha ki kellene terjeszteni. Hacsak nincs a tarsolyban egy jabb trkk. Nos, van ilyen.
A DHCP tovbbt gynkk (Relay Agent)
A Windows NT4, Windows 2000 s Windows 2003 rendszereknek van egy specilis, a DHCP-szervereket tmogat
szolgltatsa, ezek a tovbbt gynkk. Az NT4-ben mg kln szolgltatsknt telepthet (gyakran sszekevertk a
DHCP kiszolglval s teleptettk is), a Windows 2000-ben az RRAS szolgltats rsze.
A tovbbt gynk az RRAS szolgltats egyik funkcija

Egy tovbbt gynk feladata borzasztan egyszer: elkapja a helyi hlzatban kszl DHCP-kiszolglknak sznt
csomagokat, majd azokat a belltsai szerint egy vagy tbb ms alhlzaton mkd DHCP szerver fel tovbbtja.
Egybl rthet a trkk: a szrt zenetek az gynk kezei kzt egyszer unicast csomagokk vlnak, gy knnyedn, akr
tbb tvlasztn is thaladhatnak. Mindezt azrt tudja megtenni a Relay Agent, mert a DHCP szabvny, egszen pontosan
az RFC 1542, a DHCP csomagban definil egy Relay IP Address mezt (Ezt ismerik gy is, mint Gateway IP Address,
vagy GIADDR). Az gynk ide rja bele a sajt cmt, ettl egy csapsra minden DHCP kiszolgl unicast csomagokkal kezd
el kommuniklni vele. A DHCP szerver az gynk krst kirtkeli, mghozz az IP-cme alapjn. Azt vizsglja, hogy az IPcmhez, amelyrl a krs rkezett, tartozik-e egy scope. Ha pldul az gynk cme 10.1.0.10/16, van-e olyan
brlettartomny a szerveren, amelynek akr ez a cm is tagja lehetne. Ha igen, a szolgltats kiad egy brletet. A megrkez
vlaszokat gy kldi tovbb a Relay Agent az gyfeleknek, mintha csak egy valdi cmkezel lenne.
16
NetAcademia-tudstr
Az egyszer mkdshez egyszer konfigurls tartozik. A bellts csupn ngy paramtert rint. Meg kell adnunk azt az
interfszt (hlzati krtyt), amelyre a szolgltats mkdni kezd, s fel kell sorolnunk azokat a DHCP-kiszolglkat,
amelyeket az gynk rtest, ha helyi cmkrelmet fog el.
Az gynkkonfigurls nem rdngssg

Ezen fell meg lehet vltoztatnunk az un. Hop-count threshold rtket. A paramternek igazi jelentsge nincs.
Tulajdonkppen az IP csomag TTL rtkhez hasonl mezrl van sz, de attl kln kezelik. Azt jelenti, hogy maximum
ennyi Relay Agenten keresztl jhet a csomag. Azrt nincs a gyakorlatban jelentsge, mert br a szabvny szerint egy
gynk az elkapott cmet broadcast, multicast vagy unicast cmre tovbbthatja, s gy elmletileg elkpzelhet, hogy tbb
Agentnl is megfordul a DHCP-Discover csomag, gyakorlatilag kizrlag unicast cmeket hasznlnak az gynkk,
kzvetlenl a kiszolglkat megcmezve, teht szinte sohasem kap ez a mez 1-nl magasabb rtket.
A Boot threshold paramter mr hasznosabb. Ennek segtsgvel kt kln hlzatban lv DHCP kiszolglt (egyb
konfigurcis trkkk mellett) egyms tartalkv tehetjk mghozz gy, hogy a helyi kiszolgl lesz a preferlt. A boot
thresholdban meghatrozott msodpercig vr ugyanis az gynk, mieltt tovbbtan az zenetet a (tvoli) kiszolglnak.
Amennyiben van helyi DHCP szervernk, s az gynkt csak arra hasznljuk, hogy a tvoli kiszolglt, mint tartalkot
elrje, a ngy msodperc bven elegend a helyi cmkiosztnak az IP-cm alloklshoz, teht a kvnatos rendszert
hasznltk az gyfelek. Amennyiben a helyi DHCP-kiszolgl nem mkdik, az gynk elvgzi a rbzott munkt s
tovbbtja a tartalk rendszer fel a krelmeket. A DHCP rendelkezsre llsnak nvelst szolgl technikk
ismertetsekor erre a felptsre mg visszatrnk.
A hlzat-topolgia s a DHCP
Most, hogy az gynkkkel a cmkioszt szolgltats olyan, akr a brtnbl szabadult sas, nzzk sorra a kiszolglk
elhelyezsnek alapeseteit. Szeretnm elrebocstani, hogy az albbiaknl sokkal bonyolultabb elrendezsek is lteznek,
amelyeket ksbb majd trgyalunk is, most csak a leglnyegesebbeket tekintjk t.
A teljesen egyrtelm krnyezet, amikor nincs is tvlasztnk, csupn egy LAN-unk, rajta gyfelek s egyetlen DHCPszerver. Elegend egyetlen scope, habr korbban lthattuk, hogy nem lehetetlen tbb cm-intervallum hasznlata sem.
A klyha: egy DHCP kiszolgl, egy alhlzat

Az elz esetnl egy icipicit bonyolultabb, amikor tbb LAN-t egy tvlaszt kt ssze. Ekkor a tvolabbi helyi hlzat
gyfelei csak akkor kaphatnak IP-cmet, ha a router maga futtat egy DHCP tovbbt gynki funkcit. Ma mr az
tvlasztk tbbsge kpes erre csupn annyit kell tennnk, hogy a megfelel belltsokat elvgezzk.
Egy cmkioszt szerver tbb alhlzattal
17
NetAcademia-tudstr
A fenti brn lthat konfigurci azonban sok esetben csak illzi. Elszr is ritka eset, amikor egy helyi hlzatot egyetlen
router vlaszt el egy msiktl. Egyetemi hlzatokon, egy-egy nagyobb vros hlzatban elkpzelhet, ezzel egytt nem
jellemz. Msrszt a topolgia azt felttelezi, hogy az tvlaszt konfigurlsa a kisujjunkban van.
Kis magyar valsgunk nem ilyen. Ha vannak routerek, azt tbbnyire a kls szllt felgyeli (sokszor is birtokolja). Ha a
cmkiosztst ilyen krlmnyek kztt a magunk kezben akarjuk tudni, gy szksgnk lesz egy sajt tovbbt gynkre.
Ekkor mr mindegy, hogy hny eszkz vlasztja el egymstl a helyi hlzatokat, s hogy azok milyen messze vannak
egymstl. A kvetkez bra modellezi azt a szitucit, amelyben a leginkbb elkl a tovbbt gynk. Knny elkpzelni,
hogy a bal oldali hlzathoz, a kzponthoz, tbb olyan LAN kapcsoldik, mint a jobb oldalon lthat, vagyis egyetlen DHCP
szolgltatst akr tbb tucat telephelyet is ellthat. Tovbbt gynkk krdse az egsz.
Ha nem mi felgyeljk az tvlasztkat

A sklzhatsgrl csak annyit, hogy a Microsoft ajnlsa szerint ne rakjunk egy DHCP-kiszolglra 1000-nl (!) tbb
brlettartomnyt. sszesen pedig ne legyen tbb, mint 10000 gyfele egy szervernek. Ha valaki takarkoskodni szeretne a
cmkioszt szerverekkel, akr a legnagyobb kiterjeds magyar LAN is nhny szerverrel elzemel. Ugye, hogy brtnbl
szabadult a DHCP?
A tovbbt gynknek mg egy nagyon fontos szerep jut, ugyanis a betrcszskor is hrul re feladat. Ezt a szitucit
brzolja a kvetkez kp.
Betrcszs s DHCP
Ahhoz, hogy megrtsk, milyen szerepe van a Relay Agent-nek, meg kell vizsglnunk az RRAS s a DHCP viszonyt. Ltni
fogjuk, hogy nemcsak a tovbbt gynk tetszeleg nha a DHCP tulajdonsgaival, hanem az RRAS is.
A Routing And Remote Access ahogyan a nevben is mutatja, tbbek kztt tvlasztssal s betrcszssal kapcsolatos
szolgltatsokat nyjt. Amikor egy tvoli, telefonos kapcsolattal rendelkez gyfl betrcsz, tulajdonkppen egy tvlaszt
kel letre, amelynek egyik lba egy hlzati krtya, a msik pedig egy modem. A DHCP gy kerl a kpbe, hogy az RRASnak valamilyen mdon gondoskodnia kell a tvoli szmtgp modemes lbnak IP-cmmel val elltsrl.
Tbbfle lehetsg is ltezik. Elvileg bellthat kzzel egy IP-cm a kliensnl, mg egy modemes kapcsolathoz is. Na de a
dinamikus cmek korban? s ha egy msik hlzathoz szeretnk csatlakozni? Vagy egy nagy hlzat msik alhlzatn
keresztl lpek be? A statikus cm nem igazn jrhat.
Egy msik megolds lehet(ne), ha a felhasznl kap egy IP-cmet. Ezt megadhatjuk az ADUC felletn keresztl, de az
eredmny hasonl lenne az elzekhez. Knytelenek lesznk az RRAS-ra bzni a cm tadst. Ekkor kezd egy router
DHCP tollakkal keskedni.
Az RRAS kiszolgl tulajdonsgai prbeszdpanelen egy kln fl foglalkozik az IP-cmek kezelsvel. me, az albbi kpre
gondolok.
18
NetAcademia-tudstr
Az RRAS-t s a DHCP-t ezen a panelon

lhetjk ssze
A cm kiosztsra kt lehetsg is adott. A legegyszerbb, ha mindent az alaprtelmezett rtken hagyunk. Ekkor az RRAS
cmeket kr (elre) a DHCP kiszolgltl, mghozz 10 darabot. Egyet lefoglal magnak, a tbbit pedig szksg szerint
kiosztja a betrcsz gyfeleknek. Ha mind a tz cm elfogyna, akkor kr jabb tizet s gy tovbb. Az albbi cmen
egybknt a kikrt cmek szma mdosthat:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip\InitialAddressPoolSize
A cmkrs az RRAS indulsakor trtnik. Amennyiben ekkor nem rhet el DHCP szolgltats, az RRAS az APIPA ltal
meghatrozott cmek kzl oszt ki majd az gyfeleknek. Ha valaki 169.254.x.x cmeket lt, s azt panaszolja, hogy nem
tudja elrni a bels hlzatot, az gyanakodjon a DHCP s az RRAS kztti kommunikcis zavarra, s legalbb egyszer
indtsa jra a betrcsz szolgltatst gy, hogy meggyzdtt a DHCP helyes mkdsrl.
A fenti brn az is lthat, hogy meghatrozhatjuk azt az adaptert, ahonnan a RAS a klnbz opcikat veszi. Ez krem itt
egy csapda. Az igaz, hogy az RRAS cmeket kr a cmkiszolgltl. Egyb opcikat azonban nem kr! A most emlegetett
sor teht azt mutatja meg, hogy az RRAS melyik hlzati krtyjnak belltst veszik t majd a betrcsz gyfelek. Az
els s legfontosabb dolog teht a RRAS LAN krtyjnak nagyon korrekt belltsa. Egy rvid tblzat arrl, milyen IP
konfigurcis rtket honnan vesz az RRAS
Opci
Forrs
IP address
DHCP kiszolgltl az RRAS-on keresztl
WINS server
RRAS LAN adapter belltsa
DNS server
RRAS LAN adapter belltsa
Subnet mask
Az IP-cm alapjn, automatikusan Class A,B vagy C subnetet kap az gyfl
NetBIOS scope ID
Nem tovbbtdik
Node type
Ha az RRAS-nak nincs WINS szervere, akkor a kliens b-node lesz, egybknt h-node a
kapcsolat ideje alatt.
No s a korbban emlegetett DHCP RRAS opcikat sem kldi t az RRAS? Nem, azokkal sem foglalkozik. Viszont az
gyfelek a kapcsolat ltrejtte utn kldhetnek egy DHCPINFORM csomagot, amelyben a megfelel opcikat krik. Itt jn a
tovbbt gynk jabb feladata. Amennyiben az IP-cmeket DHCP kiszolgltl kapta az RRAS is, az gynk
automatikusan tovbbtja az gyfelek csomagjait ennek a cmkiosztnak. Ha viszont statikus cmlistval dolgoztunk az
RRAS-on, akkor csak abban az esetben mkdik a tovbbts, ha az gynkt kln konfigurltuk, vagyis megmondtuk,
hogy mely cmkioszt rendszerrel vegye fel a kapcsolatot.
A betrcsz gyfelek persze mit sem tudnak arrl, hogy a cmeket nem kzvetlenl egy cmkioszt szervertl kaptk.
Szmukra csak az a lnyeges, hogy megkapjk a hn htott IP-cmet, hozz a megfelel paramtereket s vgre
kommuniklhassanak. Neknk rendszergazdknak azonban nem rt tisztban lennnk, hogy ez a tbbnyire
problmamentes sszekapcsolds valjban igencsak sszetett s kacifntos mdon jn ltre.
19
NetAcademia-tudstr
lepenyet@mal.hu
Windows 2000 Server Internetworking Guide
Chapter 3: IP Unicast
Chapter 7: Remote Access Server
Windows 2000 TCP/IP Core Networking Guide
Windows 2000 Help RRAS
Windows 2000 Help DHCP
A DHCP rejtett szpsgei VI.

Azt mr korbban is lthattuk, hogy a DHCP szolgltats nem ll nmagban, szmos
ms komponenssel egyttmkdik. A DNS, az Active Directory, az RRAS s a DHCP
viszonyt mr tisztztuk. A cmkioszt szerver azonban egyb funkcikkal is szorosan
integrlt, st nha sajt maga tartalmazza ezeket az alkalmazsokat. Ezttal a BOOTP,
a MADCAP, a RIS s a DHCP kzti sszefggseket vizsgljuk.
BOOTP a flig lenyelt eld
A DHCP szolgltats nem volt elzmnyek nlkli, isteni fejbl kipattant szikra. 1985-ben Bill Croft a Stanford egyetemrl s
John Gilmore a Sun Microsystemtl ksztettek egy szabvnytervet, amely RFC 951-es szmmal s Bootstrap Protocol
(BOOTP) cmmel vonult be a trtnelembe. Az megoldsuk sok tekintetben hasonlan mkdtt, mint a mai DHCP
kiszolglk, br nem pontosan ugyangy. Az eltrsek az alkotk indtkaibl, az elttk ll feladatokbl fakadtak. A fenti
kt riember a lemez nlkli munkallomsok elindulsi folyamatt szerette volna automatizlni. gy a BOOTP szabvny egy
ktfzis indtst definilt. (Az RFC az elst rta le rszletesen.)
Az els fzisban a munkallomsok UDP 67 (szerver) s UDP 68 (kliens) portokon keresztl kommuniklnak. A szerver egy
IP cmet biztost a lemez nlkli gpnek, tovbb nhny paramtert, amelyet k gyrti kiegsztseknek (vendor
extensions) neveztek. Azt az informcit, hogy a munkalloms melyik kiszolglrl, milyen nev boot llomnyt tlthet le az
indulshoz szintn a BOOTP kiszolgl adja meg. A msodik fzisban a lemez nlkli rendszer TFTP protokollon keresztl
felveszi a kapcsolatot a korbban megadott szerverrel, lemsolja a boot llomnyt, majd azt betltve elindtja a szksges
opercis rendszert.
Tulajdonkppen az RFC szerzi oldottk meg a tyk-tojs problmt, amit mi korbban paradoxonknt emlegettnk, vagyis
k javasoltk a szrt zenetek alkalmazst. Lthatjuk, hogy az els fzis igen-igen hasonlt a DHCP mkdsi elveihez.
Kzponti cmkezelsrl van sz mindkt esetben, ugyanazokat az UDP kapukat hasznljk a BOOTP s DHCP kiszolglk,
kliensek, tovbb az zenetvltsnl a csomagszerkezet is megegyezik, egy kivteltl eltekintve: a BOOTP csomagok csak
64 oktetnyi helyet biztostanak a gyrti kiegsztseknek, mg a DHCP 312 oktetet rtelmez, amelyben a klnbz opcik
utaznak. (A kt fogalom opci s gyrti kiegszts - gyakorlatilag ugyanazt takarja.)
Ezek a hasonlsgok arra ksztettk a DHCP kiszolglt megalkot programozkat, hogy lehetv tegyk a BOOTP
gyfelek tmogatst. A Microsoft a Windows NT 4.0 SP2 ta tmogatja az idsebb testvr klienseit.
A hasonlsgok mellett szlni kell a meglv klnbsgekrl is. J kiindulsi alap a szllti kiegsztsek felsorolsa.
Kd
1
3
4
5
9
12
15
17
Lers
Subnet Mask
Router
Time Server
Name Server
LPR Server
Computer Name
Domain Name
Root Path
20
NetAcademia-tudstr
42
44
45
46
47
48
49
69
70
NTP Servers
WINS Server
NetBIOS over TCP/IP Datagram Distribution Server
NetBIOS over TCP/IP Node Type
NetBIOS over TCP/IP Scope
X Window System Font Server
X Window System Display Manager
SMTP Server
POP3 Server
A fenti lista lnyegesen rvidebb, mint a DHCP opcik teljes tblzata, radsul nhny nagyon fontos paramter is
hinyzik. Nincs sehol sz brletidrl (51-es opci) megjtsi idrl (renewal time, 58-as opci, rebind time 59-es opci).
Ezek szerint egy BOOTP kliens nem jtja meg a brlett? Nos, nem jtja meg, mivel az IP cm krst nem
brletviszonynak fogja fel. S me, ez a legnagyobb klnbsg egy DHCP s egy BOOTP gyfl kztt. Egy BOOTP kliens
kr ugyan IP cmet a rendszerindulskor, s minden jabb indulskor is, m onnantl a cmet sajt magnak rzi. Nincs
tovbbi kapcsolata a BOOTP kiszolglval! Hogyan lehet gy cmeket kezelni? Hiszen az egyszer kiadott cmrl azutn mr
nem rendelkezhetnk, nem vonhatjuk vissza.
A BOOTP vilg mskpp mkdik, mint a DHCP. A cmek kiadsa ugyanis a szabvny szerint egy tblzat alapjn trtnik,
amelyben elzleg rgztik a leend gyfl azonost adatait, tbbek kztt a MAC cmt is. Ha analgit keresnk, a DHCP
lefoglalt cmeihez hasonlthatjuk az eljrst a brletidtl eltekintve. Vagyis sz sincs ellenrizetlen folyamatokrl, pp
ellenkezleg. A BOOTP vilg nem is kaphat cmet olyan lloms, amelyrl a rendszergazda nem tud. Kizrlag a BOOTP
tblzatba felvett hostok nyernek bebocstst a hlzatba.
No persze ez nem is olyan knyelmes megolds, mint a DHCP, mivel elzetesen be kell gyjteni legalbb a MAC cmeket, a
boot llomnyneveket, a TFTP szerver cmeket, kzzel frissteni a tblt stb., stb. Mai szemmel nzve meglehetsen fura, a
szabvny megalkotsakor azonban mg nem kellett naponta tucatjval telepteni s kivonni gpeket a hlzatbl, vagyis a
fenti megolds is kielgt volt. Arrl nem beszlve, hogy a DHCP-hez kpest a BOOTP vilg mg biztonsgosabbnak is
tekinthet, hiszen kizrlag a rendszergazdk explicit engedlye utn kaphat egy host cmet, ami azrt erteljesebb kontroll,
mint egy scope aktivlsa. A DHCP biztonsgrl azonban ksbb mg lesz sz, most nzzk, hogyan is fest a konkrt
BOOTP implementci.
A Windows NT 4.0-ban a tmogats azt jelentette, hogy a szerver elfogadta a BOOTP csomagokat, majd a lefoglalt cmeket
(reserved addresses) kezdte el vizsglni. Amennyiben tallt olyan MAC-cmet, amely a csomagban szerepl gyfllel
megegyezett, a brletet kiosztotta. Amikor teht korbban a lefoglalt cmek mkdshez hasonltottuk a BOOTP
megoldsait, egyltaln nem jrtunk tvol az igazsgtl, mert a DHCP BOOTP emulcija pp ezt a lehetsget hasznlja
ki.
A Windows 2000-ben tovbbfejlesztettk a BOOTP tmogatst, s a fenti megolds megtartsa mellett bevezettk a
dinamikus BOOTP gyfelek fogalmt. Ez azt jelenti, hogy mr nem kell a lefoglalt cmek kz felvenni elre a BOOTP
gyfeleket, azok ppen gy egy aktv brlettartomnybl kapnak cmet, mint a kznsges gyfelek. Csupn kt dologra kell
figyelni. A brlettartomny tulajdonsgai prbeszdpanelen az Advanced lapon engedlyezni kell a BOOTP gyfelek
dinamikus kiszolglst, tovbb meg kell hatrozni, hogy mennyi idre kapjk meg kiadott IP-cmet.
A BOOTP gyfeleknek 30 napra szl az alaprtelmezett brlet

A 30 napos brletid elgg veszlyes dolog. Attl, hogy egy DHCP kiszolgl DHCP gyflknt szeretn kezelni a BOOTP
klienseket, a szabvny mg nem vltozik meg. Mrpedig a BOOTP gyfelek nem fogjk megjtani a brletket. Ha teht 30
napon tl sem indtjuk jra ket, a DHCP kiszolgl msnak is kiadhatja a cmket. Blcs rendszergazda teht ezt az rtket
legalbb 100 napra, vagy mg inkbb 365 napra mdostja. Manapsg ugyanis a BOOTP gyfelek elgg sokig kpesek
21
NetAcademia-tudstr
zemelni egyhuzamban. A dinamikus tmogatsnak van mg egy fontos felttele: az gyfelek csak IP cmet krjenek. Ha
szksgk van a boot llomny nevre, TFTP szerver cmre stb., akkor a dinamikus BOOTP gyfl mint megolds nem
jhet szba. Valamilyen mdon ugyanis hozz kell rendelni a fenti adatokat is a klienshez. Marad a korbban felvillantott
reserved address alap megolds. Felvesszk a BOOTP gyfeleket a lefoglalt cmek kz megadva a MAC cmt, nevt
stb. s bejellve, hogy BOOTP krs rkezik majd.
Ezutn be kell lltani kt specilis opcit, a 66 s 67 szmt. Az els TFTP kiszolgl nevt, a msodik a bootfjl nevt
tartalmazza.
Vgl a szerver tulajdonsgai lapon bekapcsolhatjuk a BOOTP tbla mappt. Ha ezt megtettk, lehetsgnk van hrom
adattal elltni a BOOTP gyfeleket. Az els s a harmadik mr ismers, itt azonban megadhatjuk mg a teljes elrsi utat is
a boot llomnyhoz. A klienshez felvett rtkek alapjn a tbla bejegyzshez egyrtelmen hozzrendelhet a BOOTP
gyfl is. Ugye nem bonyolult?
A Windows 2000 ennl tovbb nem megy. A sgban azt a fura mondatot olvashatjuk, hogy a TFTP szervernek egy
harmadik gyrttl kell szrmaznia, mert a Windows 2000 nem rendelkezik ilyen kiszolglval.
A BOOTP szabvnyt kvet prbeszdpanel

A fenti llts egy kicsit sntt, hiszen a RIS kiszolglhoz dukl egy TFTP is. A pontos megfogalmazs teht az lehetne,
hogy a Windows 2000-et nem szlltottk olyan TFTP kiszolglval, amely a BOOTP gyfeleket is kiszolgln. (Kr, hiszen a
PXE kliensek nagyon kzeli rokonai a BOOTP-t hasznl llomsoknak.)
A BOOTP szolgltatsrl sszessgben annyit mondhatunk, hogy a szabvny h kvetse, m nem teljes megolds.
Amennyiben azonban az IP-cm kiosztst tekintjk feladatnak, gy a DHCP kiszolgl megfelel tmogatst nyjt a BOOTP
gyfeleknek is.
MADCAP
Ha a BOOTP szabvny a mlt, akkor a Multicast Address Dynamic Client Allocation Protocol (MADCAP) egy kicsit taln a
jv. Nem azrt, mintha a multicast szabvny nem lenne legalbb olyan ids, mint nmely mai kzpiskols (1986-ban jelent
meg az RFC 988, amelyben elszr definiltk), hanem inkbb azrt, mert a r pl alkalmazsok, mint a videkonferencia, azonnali zenetklds, e-learning megoldsok, stb. mg csak most kezdik meg hdt tjukat.
A MADCAP megrtshez minimlis szinten rteni kell a multicast vilgot is. Az mr kzismert, hogy a gpeknek egyedi IP
cmmel kell rendelkeznik, amelyek A, B, C osztlyba sorolhatk, esetleg osztly nlkliek. Lteznek azonban D osztly
cmek is, ezeket onnan lehet felismerni, hogy a IP cm els ngy bitje 1110, vagyis egy multicast cm a 224.0.0.0 s
239.255.255.255 tartomnyba esik. A multicast cmekre a kvetkez szablyok vonatkoznak:
1. Egy llomsnak rendelkeznie kell legalbb egy unicast cmmel, mieltt egy multicast cmet kap.
2. Egy multicast cmet tbb lloms is megkaphat tulajdonkppen ez az rtelme. Egyedi cmeknl ez tilos. A szabvny
szerint az azonos multicast cmmel rendelkez llomsok halmazt nevezik multicast csoportnak, amelynek nulla vagy
annl tbb tagja lehet. Egy csoport nem csak egy logikai alhlzatbl fogadhat tagokat, s a hlzat tudja, hogy mely
llomsok tagok, s azok hol helyezkednek el. A csoport dinamikusan vltozhat. Brmely lloms brmikor
csatlakozhat, vagy elhagyhatja a csoportot. (Ennl mlyebbre nem megynk, habr a tma izgalmas.)
3. Egy llomsnak tbb multicast cme is lehet egyidejleg.
Tudni kell mg, hogy bizonyos cmek foglaltak, vagy specilis tulajdonsgokkal brnak. Nhny plda:
1. A 224.0.0.0-224.0.0.255 cmek csak a helyi alhlzaton rvnyesek, az tvlasztk semmikpp sem tovbbtjk
ket.
2. A 239.0.0.0-239.255.255.255 cmtartomny olyan alkalmazsok szmra van fenntartva, amelyek elrhetsgt
(vagy inkbb sugrzsi tvolsgt) szablyozni lehet.
3. A fenti cmtartomnyon bell a 239.192.0.0 255.252.0.0 alhlzati maszkkal nagyjbl hasonl szerepet jtszik a
multicast vilgban, mint a 10.0.0.0/8 az unicast forgalomnl. Bels hasznlatra ajnlott cmtartomny, idelis a
MADCAP kiszolglk szmra. Ez a cmtartomny 262144 cmet jelent, ami risi szm, ha meggondoljuk, hogy
egyetlen cmet akr tbb ezer lloms is hasznlhat.
4. 224.0.0.1 minden lloms a helyi hlzaton.
5. 224.0.0.2 minden tvlaszt a helyi hlzaton
6. 224.0.0.5 OSFPv2 tvlasztk a hlzatban
7. 224.0.0.6 OSFPv2 tvlasztk a hlzatban
8. 224.0.0.9 RIPv2
22
NetAcademia-tudstr
9.
224.0.1.1 Network Time Protocol
A 224.0.1.0 238.255.255.255 szabadon felhasznlhat multicast-ra pl alkalmazsok szmra, legyenek akr az

Interneten is. Persze a cmeket ugyangy meg kell ignyelni, de taln itt nincs olyan cmhsg, mint az egyedi cmek
esetben.
Fontos tisztzni, hogy a multicast cmek fggetlenek az egyedi IP azonostktl, teht a MADCAP szerver sem fgg a DHCP
cmtartomnyok meglttl. Ha egy kiszolgln csak multicast brlettartomny tallhat, akkor azt MADCAP szervernek
mondjuk. m ksbb itt is ppgy lehet normlis scope-okat ltrehozni, jl megfrnek egyms mellett.
Az sem szksges, hogy az gyfl unicast cme egy DHCP kiszolgltl szrmazzon s fordtva: egy DHCP gyfl nem
csak a MADCAP ltal adott multicast cmmel kapcsoldhat olyan csoporthoz, amely tbbi tagja viszont MADCAP gyfl.
A MADCAP kezelfellete
Egy multicast cmtartomny ltrehozsa pp olyan knny, mint egy kznsges brlettartomny, st, ha lehet, mg
egyszerbb. A MADCAP kiszolglk ugyanis szinte kizrlag cmtartomnyokat definilnak, opcikat azonban nem
ennyivel egyszerbb az let.
A varzsl, amely a scope-ot ltrehozza, csupn a cmtartomny nevt, kezd- s vgcmt, a kizrt cmeket s a brletidt
krdezi meg. Mindezt azonban ksbb is bellthatjuk a scope tulajdonsgai kztt, ahogy a kvetkez bra mutatja.
A multicast cmtartomnyokkal nem bnik olyan finnysan a kiszolgl. A tulajdonsgok lapon knnyedn mdosthatjuk a
kezd s vgs cmet is, ha ez szksges.
Kln emltst ignyel a TTL rtk. Az tvlasztk szmt jelenti, amelyeken mg thaladhat a multicast forgalom. Ez
egyszeren szablyozza, hogy milyen messzirl rhet el az adott multicast alkalmazs (pl. egy e-learning tanfolyam).
Egyszeren konfigurlhat multicast cmtartomny

A multicast vilgnak van egy klns sajtossga, az illkonysg. Egy videokonferencia zros idn bell vget r, akrcsak
egy tanfolyam, vagy egy l kzvetts. A cmeket hipp-hopp elhagyjk a munkallomsok, st akr az egsz cmtartomny
is feleslegess vlhat. A Windows 2000 kszti szmoltak ezzel a szitucival. A multicast brlettartomny tulajdonsgai
kztt a msodik lapon bellthatjuk, hogy a scope meddig ljen, szakszval: mikor jrjon le. Ha eljtt az id, t a scope
rja. Elillan, mintha sohasem lett volna.
Amilyen sszetett s bonyolult tud lenni egy multicast forgalmat lebonyolt hlzat, olyan egyszer a MADCAP letre
keltse ez most kiderlt. Egy valamit azonban rdemes fejben tartani: a MADCAP csupn egy eleme a hlzatnak, amely
a fenti alkalmazsokat biztostja. Szksges, de nem elgsges felttele multicast alkalmazsok bevezetsnek. Nem
kerlhet el az tvlasztk alapos fellvizsglata s alkalmass ttele e specilis forgalom lebonyoltsra.
A DHCP s a RIS
Mg 2001 vgn indult e lap hasbjain egy t rszbl ll sorozat, amelynek keretben az Olvas rszletekbe menen
megismerkedhetett a RIS, vagyis a Remote Installation Services rejtelmeivel. Most csak rviden szlunk a RIS s a DHCP
kapcsolatrl.
A RIS s a DHCP kztt nha rejtlyes kapcsolat van. Elszr is minden RIS szervert fel kell venni az Active Directory
hitelestett DHCP kiszolglinak listjra. Vagyis a Windows 2000 bizonyos szempontbl a DHCP kiszolglkhoz hasonlan
bnik az automatikus szoftverdisztribcis feladatokat vgz RIS szerverekkel. Mirt is? A RIS kiszolglk feladata a PXE
gyfelek kiszolglsa, s csodlatos mdon a PXE gyfelek DHCP csomagok segtsgvel kommuniklnak a RIS
szerverekkel. Ezrt szksges a hitelests.
Lssuk a tnyleges forgalmat. Felttelezzk, hogy mind a DHCP, mind a RIS kiszolgl az PXE klienssel azonos
alhlzatban van.
23
NetAcademia-tudstr
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
A PXE gyfl kibocst egy DHCP-DISCOVER csomagot, amelyben IP cmet s PXE boot szerver cmet kr.
DHCP-OFFER csomag rkezik a DHCP kiszolgltl egy IP cmmel.
DHCP-OFFER csomag rkezik a RIS kiszolgl BINLSVC komponenstl a PXE szerver cmmel.
A PXE kliens DHCP-REQUEST csomagot kld a DHCP szervernek, IP cmet kr.
A DHCP kiszolgl DHCP-ACK csomaggal nyugtzza a krelmet.
A PXE gyfl egy jabb DHCP-DISCOVER csomagot bocst ki.
DHCP-OFFER csomag rkezik a DHCP kiszolgltl az elz IP cmmel.
DHCP-OFFER csomag rkezik a RIS (BINLSVC) kiszolgltl a PXE szerver cmmel.
A PXE kliens DHCP-REQUEST csomagot kld a RIS szervernek, s a PXE boot szerver cmt kri.
A RIS (BINLSVC) egy DHCP-ACK csomagot kld, amely a szerver IP cmt, nevt, valamint annak az llomnynak a
nevt tartalmazza, amelyet a TFTP kiszolgltl kell krnie az gyflnek (Ez a startrom.com).
Lthat, hogy a harmadik s hetedik csomag felesleges. A harmadik csomagra sohasem fog vlaszolni a PXE gyfl, mert
nem tartalmaz IP cmet, mg a hetedik azrt felesleges, mert IP cmmel mr rendelkezik a delikvens. Mindez azonban a
szabvnybl kvetkezik. DHCP-OFFER csomagra minden DHCP kiszolgl vlaszol. (A BINLSVC konfigurlhat ennl
finnysabb mdon is. A RIS-nl bellthat, hogy csak az ismert gyfeleknek vlaszoljon. Ha a PXE gyfl nem tud ismert
GUID-ot felmutatni, a BINLSVC egyszeren hallgat, nem kld vlaszokat.)
Ha a RIS s a DHCP egy kiszolgln dolgoznak, lnyegesen egyszerbb prbeszd zajlik a szerver s az gyfl kztt.
Csupn az albbi:
1. DHCP-DISCOVER csomagot bocst ki az gyfl (IP cmet s PXE boot szerver nevet keres).
2. DHCP-OFFER csomagot kld a kiszolgl IP-cm ajnlattal s PXE boot szerver nvvel.
3. DHCP-REQUEST krs indul az gyfltl a kivlasztott IP cmmel.
4. DHCP-ACK nyugtzza a cm kiadst. A csomag tartalmazza az IP cmet, a RIS szerver cmt, s az els
letltend llomny nevt.
A trkk annyi, hogy a DHCP megkrdezi a BINLSVC szolgltatst, hogy kvnja-e hozzadni a maga informciit a DHCP
csomagokhoz. A PXE kliens egybknt az utbbi forgalmat szereti. Ha kt DHCP kiszolgltl is kap csomagot, akkor azt
fogja minden esetben preferlni, amelyik egyben RIS szerver is. A RIS kiszolglk terhelselosztsnl ezt figyelembe kell
venni.
A fenti forgalomnl feltteleztk, hogy a hrom szerepl (PXE gyfl, DHCP s RIS kiszolgl) egy alhlzaton mkdik. Az
let azonban lehet ennl bonyolultabb, megeshet, hogy akr az egyik, akr mindkt szerver egy msik alhlzaton dolgozik.
Ekkor termszetesen DHCP Relay Agentekre van szksg, amelyeknek tbb helyre is tovbbtani kell az elkapott DHCPDISCOVER csomagot: a cmkiszolglk mellett a RIS szervereknek is rteslnie kell a PXE gyfl indulsrl.
A Q259670 cikk egy rdekes, de a Microsoft ltal nem tmogatott eljrst r le. Ennek lnyege, hogy hrom opcit be kell
lltani egy adott scope-hoz (ezek kzl egyet netsh felleten keresztl), amelynek nyomn a DHCP kiszolgl rgvest
elvgzi a BINLSVC munkjt is, mert megadja a RIS szerver nevt, cmt s a boot llomny nevt. A megolds htrnya,
hogy a RIS szervert a scope-hoz kti, radsul kicselezi a BINLSVC fent emltett biztonsgi mechanizmust is. Viszont a
megolds teljesen hasonlatos egy BOOTP indulshoz. Mi kell egy BOOTP kliensnek? IP cm, TFTP szerver cm, boot fjl
nv. s mi kell egy PXE kliensnek? Ugyanez. Noht, noht. Akkor mirt kellett megalkotni egy j szabvnyt, a PXE-t,
ahelyett, hogy az reg motoros BOOTP-t hasznltk volna?
A vlasz nem trivilis, de valamennyire rthet. A BOOTP egy kihalban lv szabvny, mra mr alig hasznljk,
legfkppen pedig nem dinamikus. A DHCP ugyan dinamikus, de alaprtelmezetten nem tartalmaz olyan adatokat a
kliensekrl, amilyenek egy PXE hostnak szksge van. (Lttuk, megoldhat, de nem tl szerencss). Kell teht egy olyan
szabvny, amely IP cmet oszt, TFTP szerver nevet s boot image elrhetsget s dinamikus. Ilyen nem volt, ezrt
megalkottk a PXE-t.
Nem lehetett volna ezt a funkcit mgis a DHCP-be gyrni? Taln lehetett volna, ki tudja. Az mindenesetre rulkod, hogy a
PXE nem egy RFC szabvnyon alapul, vagyis nem IETF alkots. Ki tudja? Egyszer taln sszeolvasztjk a kt eljrst
olyan sok kzs vonsuk van. Egyelre azonban ez csak tallgats. Volt a BOOTP, van a DHCP s a PXE, neknk pedig
mindegyiket tudni kell alkalmazni a maga helyn.
lepenyet@mal.hu
Windows 2000 Server Internetworking Guide Chapter 3: IP Unicast
Windows 2000 TCP/IP Core Networking Guide
RFC-951 BOOTP Protocol
RFC-1930 "Guidelines for creation, selection, and registration of an Autonomous System (AS)."
RFC-2365 "Administratively Scoped IP Multicast."
Q244036 Description of PXE Interaction Among PXE Client, DHCP, and RIS Server
Q259670 Using Dynamic Host Configuration Protocol Options 60, 66, 67 to Direct PXE Clients to RIS Servers May Fail
24
NetAcademia-tudstr
A DHCP rejtett szpsgei VII.

A cikksorozat befejez rszben hrom fontos tmakrt elemznk. Megvizsgljuk,
milyen lehetsgeink vannak a DHCP-szolgltats rendelkezsre llsnak nvelsre,
ttekintjk a beptett monitoroz eszkzket, vgl nhny hasznos fogst
ismertetnk, amelyek a DHCP-adatbzis karbantartst segthetik.
A rendelkezsre lls nvelse
Akik figyelemmel ksrtk a tech.net magazin DHCP-cikksorozatt, pontosan tudjk, hogy a cmkioszt szolgltats kritikus
funkci, s br nem kell minden msodpercben mkdnie, a hibs szerver lassan, de biztosan megbntja az egsz hlzat
lett. Szerencsre szmos lehetsg van a keznkben, hogy a rendelkezsre llst nveljk. Az albbi pr mdszer kzl
a vkonyabb pnztrcj s a professzionlis szolgltatk is megtallhatjk a nekik megfelel megoldst.
Rendelkezsre lls nvelse jzan sszel
Szr mentn mr emltettk, most jra elvesszk az egyik legegyszerbb s legkzenfekvbb megoldst, amellyel akr
napokat is nyerhetnk a DHCP helyrelltshoz. A cmkrs mdszerbl, valamint az Windowsos gyfelek alaprtelmezett
belltsbl kvetkezik, hogy a szolgltatst csak rvid idre ignylik az IP-cmmel dolgoz eszkzk. Egy gyfl akkor
kerl kapcsolatba a DHCP-szerverrel, amikor elszr cmet kr, jraindul, amikor meg kell jtani a brletet a brletid
felnl, sikertelensg esetn a hromnegyednl, vgl a brlet tnyleges lejratakor. A kontaktusok kzl csak az els s
az utols kritikus, vagyis ha a kliensnek eleve nem volt cme, vagy vgleg lejrt a brlete. Minl hosszabb a kt idpont
kztti id vagyis a brletid, annl nagyobb a valsznsge, hogy nem ilyen kritikus helyzet ll fenn.
Vagyis a brletid nvelse nmagban a rendelkezsre llst nvel tnyez. Persze csak statisztikai alapon. A brletid
fggvnyt vizsglva azt tapasztalhatnnk, hogy az gyfelek legtbbje a brlet egynegyednl jr. Mirt? Mert ha jl
mkdik a DHCP-szolgltats, akkor a gpek tlnyom tbbsge flidben megjtja a brlett, vagyis a brletid 0 s 50%a kztt egy normlis jelleg eloszls jellemzi a gpek cmbrleteit.
A gyflszmtgpek eloszlsa az eltelt brletid fggvnyben

Tkletes normlis eloszlsrl azrt nem beszlhetnk, mert mindig lesznek olyan gpek, amelyek kikapcsolt llapotban
talusszk a flidt, s megjsolhatatlan, hogy mikor brednek. Ezzel egytt egy kevs gpbl (20-60) ll hlzatban,
naponta hasznlt llomsokkal a normlis eloszls nagyon j kzelts. Belthat, hogy egy 90 napos brletperidus esetn
majdnem 45 nap ll rendelkezsre a DHCP-szolgltats megjavtshoz megint csak statisztikai alapon. Akkor javasolt
ehhez a taktikhoz folyamodni, ha:
Egyetlen szervernk van.
Viszonylag kicsi, jl tlthat hlzattal dolgozunk.
Stabil a krnyezetnk, teht nem konfigurljuk t gyakran a DHCP-kiszolglt, nem vsrolunk ppen most gpeket,
nem adunk j IP-cm tartomnyt a hlzatnak.
Nincsenek olyan gyfeleink, amelyek egy msik hlzatban is rendszeresen megfordulnak, s ott cmet ignyelnek.
Nincsenek BOOTP gyfeleink. (k jraindulskor mindenkpp ignyelnek IP-cmet.)
Nem konfigurltuk gy az gyfeleket, hogy lellskor engedjk el a cmket.

Br kemny korltok a fentiek, azrt szp szmmal akad olyan hlzat, amely minden kritriumot teljest. Fontos
megemlteni, hogy a tbb telephely nem akadly, hisz az gyfl szmra transzparens, vajon egy valdi cmkiszolgl
szervertl kapja a cmet, vagy egy Relay Agent kzvetti azt.
Nem ajnlott a megolds extrapollsa a brletid vgtelenre lltsval. Igaz ugyan, hogy ekkor nincs flid sem, teht a
haranggrbe a fenti bra bal tengelyre vasaldik, m a megoldsnak tbb a htultje, mint az elnye. A vgtelen
brletperidussal elltott gyfl csak akkor reflektl a DHCP-opcikban bekvetkezett vltozsokra ha jraindtjk, m ez
mg csak a kisebbik baj.
25
NetAcademia-tudstr
A nagyobb gond, hogy a DHCP-kiszolgl nem rtesl arrl, ha egy gpet vgkpp kivonnak a hlzatbl. A kiadott cm
rkre az adott MAC-Address-hez tartozik, teht elvsz. A cm visszanyershez pontos nyilvntartssal kell
rendelkeznnk a hlzatunk tallhat valamennyi DHCP gyfl MAC-cmrl. Ez tl sok tbbletmunka a vgtelen brletrt
cserbe. Igazbl pp ezt a nyilvntartst teszi feleslegess a cmkioszts.
A fenti mdszer, br mkdik, igazbl a szolgltats tehermentestsvel teremt rendelkezsre llst. Ha a statisztikai elv
nem fogadhat el, vagy nem alkalmazhat, egy komolyabb s megbzhatbb megoldst kell keresnk.
80-20-as (50-50-es) megolds
Ha nem csak egyetlen kiszolglval rendelkeznk, hanem legalbb kettvel, egy gyes trkkel biztosthatjuk, hogy az
gyfelek mindig hozzjussanak a mindennapi IP-cmkhz.
A mdszer igen egyszer. Hozzunk ltre kt DHCP kiszolglt, s konfigurljuk mindegyiken egy-egy azonos
cmtartomnyra vonatkoz brlettartomny. Ezutn az egyik kiszolgln zrjuk ki a cmek fels hsz (vagy tven)
szzalkt. Vgezzk el ugyanezt a mveletet a msik szerveren is, de ott az als 80 (vagy 50) szzalknyi cmet zrjuk ki.
Az eredmnyt a msodik bra mutatja.
Scope: 172.16.0.1172.16.0.254
Scope: 172.16.0.1172.16.0.254
Excluded addresses:
172.16.0.129-172.16.0.254
Excluded addresses:
172.16.0.1-172.16.0.128
DHCP Server1
DHCP kliens
DHCP kliens
DHCP Server2
DHCP kliens
DHCP kliens
A 80-20-as (50-50-es) eljrs alkalmazsa

A vgeredmny kt, azonos cmtartomnyt kezel, de pontosan azonos cmeket soha ki nem oszt szerverpr lesz. Az
eljrs alkalmazsakor a kvetkezre kell figyelni:
Vletlenl sem fordulhat el, hogy azonos dinamikus cmet mindkt szerver kiadhasson, teht a cmek kztt nem lehet
tfeds.
A kt scope opciinak teljesen azonosnak kell lennie, belertve a brletidt s a specilis opcikat is.
A lefoglalt cmeket (reserved addresses) mindkt kiszolgln be kell lltani, belertve a kiegszt opcikat is, ha
vannak ilyenek.
A BOOTP cmeket a lefoglalt cmekhez hasonlan kell kezelnnk, vagyis ktszer kell felvennnk minden rekordot.
A cmtartomny nagysgt gy rdemes megvlasztani, hogy akr egy kiszolgl is kpes legyen valamennyi
potencilis gyfelet kiszolglni. Ha teht van 300 gpnk, s 150-et szolgl ki egy DHCP-szolgltats, akkor a
brlettartomny tartalmazzon legalbb 300 cmet. Manapsg, a privt cmtartomnyok hasznlatakor ez ritkn
problma. (Ugyanakkor gyakoribb az 50-50%-os megosztsa a brlettartomnynak, ezrt szerepel ez az brn.)
Stabil a krnyezetnk, teht nem konfigurljuk t gyakran a DHCP-kiszolglt, nem vsrolunk ppen most gpeket,
nem adunk j IP-cm tartomnyt a hlzatnak.
Nzzk, mit nyernk a konfigurcival. A mdszer valdi rendelkezsre-lls nvekedst jelent, mert az egyik kiszolgl
kiesse esetn is ellthatk az gyfelek IP-cmekkel. Akr kzzel is nekillhatunk egy teljesen j DHCP kiszolgl
fellltsnak, ha kiesne az egyik, hiszen van egy tkrkpnk, amit csak le kell msolnunk. Nem akadlyoznak az elz
megoldsnl felsorolt kritriumok sem, lehetnek vndorl gpeink, BOOTP klienseink, tetszlegesen konfigurlhatjuk az
gyfeleket, sklzhat megoldshoz jutunk amely radsul mindig mkdik. Mindezt gy, hogy nem kellett extrn
konfigurlt hardvert vsrolnunk, sem j technolgit bevezetnnk, nincs szksg a Windows Server drgbb vltozatra.
Olyannyira nincs, hogy a tkrszerver akr msik opercis rendszert is futtathat, pldul Linuxot. A felttel csupn annyi,
hogy a DHCP-szabvny pontosan kvesse a msik rendszer is, legalbbis mindazt tudja, amit mi hasznlunk a szabvnybl
(esetleg: superscope, klnleges opcik (class, vendor stb.))
A magasabb sznvonal szolgltatsnak azonban ra van. Lnyegben ktszer kell elvgeznnk minden konfigurcis
mveletet. Ha ritkn vltoz scope-pal dolgozunk ez kevsb fjdalmas, m ha sok lefoglalt cmnk van, netn mg BOOTP
gyfeleket is kiszolglunk, akkor nehz kt szerveren preczen azonos adatbzist fenntartani. (Ilyenkor javasolt minden
mveletet parancssorbl vgezni, mert a megkonstrult parancssort knny kt szerverre lefuttatni.)
Katasztrfatr megolds
Az 50-50-es mdszert tovbbfejleszthet valdi katasztrfatr megoldss. A kvetkez bra kt telephelybl felpl
hlzatot mutat az elbb ismertetett DHCP-konfigurcival.
26
NetAcademia-tudstr
Scope1: 172.16.0.1172.16.0.254
Excluded addresses:
172.16.0.129-172.16.0.254
Scope2: 172.16.1.1172.16.1.254
Excluded addresses:
172.16.1.129-172.16.1.254
Scope2: 172.16.1.1172.16.1.254
Excluded addresses:
172.16.1.1-172.16.1.128
Scope1: 172.16.0.1172.16.0.254
Excluded addresses:
172.16.0.129-172.16.0.254
DHCP Server1
DHCP Server2
DHCP kliens
DHCP kliens
DHCP kliens
DHCP kliens
Katasztrfatr megolds
Az eredeti mdszert ki kell egszteni az tvlasztk konfigurlsval (vagy egyb mdon kell biztostani DHCP Relay
Agenteket). A rajzrl leolvashat, hogy mindkt telephelyen mindkt DHCP-szerver megkapja az gyfelek krst. Ha
azonban a tovbbt gynkk nmi ksssel indtjk el a cmignyl csomagokat a tvoli hlzat fel, norml mkdskor a
helyi kiszolgl gyz. Meghibsodskor viszont a tvoli rendszer mindenkpp kiszolglja az gyfeleket. A mdszer
katasztrfatr, amennyiben az egyik szerver fizikai megsemmislse esetn is mkdkpes marad a cmkioszts. Egyb
vonatkozsaiban a megolds pontosan ugyanazokat az elnyket s htrnyokat hordozza, mint az egy telephelyes
kialakts.
A frtzs
A Windows 2000 Advanced Server az els olyan Windows kiszolgl vltozat, amely lehetv teszi, hogy megfelelen
kialaktott hardverrel a DHCP szolgltatst frtzhessk.
A megolds ezttal a virtualizls. A frtk llomsokbl (node) s virtulis szerverekbl llnak. A virtulis szerverek
erforrsokat tartalmaznak. Ilyen erforrs lehet egy fizikai lemez, egy IP cm, egy hlzati nv, vagy ppensggel egy
DHCP-szolgltats. A frt elvi mkdst mutatja a kvetkez bra:
A DHCP-szolgltats a virtulis szerveren tallhat

A kliensek sohasem az egyik, vagy msik llomstl kapjk a frtztt szolgltatst, hanem mindig egy virtulis szervertl.
Ez a szerver szksg szerint kltzhet egyik llomsrl a msikra. (Windows Server 2003 ngy, vagy akr 8 node egyikre.)
Az tkltzsi id az erforrsok szmtl s terheltsgtl fgg. Ha a DHCP-szolgltats szmra egy sajt virtulis
szervert definiltunk, akkor az tkltzs 6-10 msodperc. Ennyi teht a kiess tulajdonkppen semennyi.
A frtztt DHCP-kiszolgl, a virtulis erforrs ltrehozst leszmtva, semmiben sem klnbzik egy normlis
cmkioszt szervertl. A frt nem ad hozz s nem vesz el a teljestmnybl vagy a funkcionalitsbl, csupn a
rendelkezsre llst nveli.
A megolds elnye az elzekhez kpest az egyszeres konfigurci. Elnys lehet sok (max: 10000!) scope kezelsekor,
nagyszm lefoglalt cm nyilvntartsakor, vagy BOOTP gyfelek kiszolglsa esetn. Akrcsak az elz kt mdszer, ez is
valdi rendelkezsre llst nvel eljrs.
Persze a tkletes megoldsnak ra van: a frt kialaktsa host-bus adaptereket, kzs httrtrat, specilis HCL listn
hitelestett konfigurcit felttelez. Az opercis rendszer vagy kt Windows 2000 Advanced Server, vagy (legalbb kt)
Windows 2003 Server Enterprise Edition lesz frtzskor. Ez jelents tbbletkltsg, mert a standard vltozatokhoz kpest a
27
NetAcademia-tudstr
licencr legalbb tzszeres (ha mindkt llomst szmolom.) Meggondoland, hogy a frtk felptse, mkdtetse
szakrtelmet kvn, a hibajavtskor szakrti kltsgek merlhetnek fel, hacsak nem profik az zemeltetk.
Lthatjuk, hogy a rendelkezsre llst segt technolgik igen sokflk. A klnbzsgk lehetsget teremt arra, hogy
tvzzk ket, ha van r lehetsgnk s a felttelek adottak. A frtzs nem zrja ki a hossz brletid hasznlatt, ha
pedig kt frtnk is futtat DHCP-kiszolglt klnbz telephelyen, fldrajzilag elosztott megoldst alakthatunk ki az 50-50es megoldssal. Az egyes mdszereket ptelemnek tekinthetjk, s tetszs szerint kszthetnk akr nagyon bonyolult
cmkioszt architektrkat is. Csupn a fantzia (s a pnz) szab hatrt az elkpzelseinknek. Egy fontos tancsot azonban
rdemes megfogadni: lehet bonyolult, amit elksztnk, csak legyen jl dokumentlt. A rendelkezsre lls egyik hallos
ellensge a hinyos dokumentci. A msik a felgyelet hinya.
A DHCP kiszolglk monitorozsa
A kiszolglk figyelse a rendszergazdk napi feladatai kz tartozik. Ha figyelembe vesszk a DHCP fontossgt, ez mg
inkbb gy van. Amikor azonban az ember szembesl a teljestmnynapl szmaival, hajlamos kiss visszavenni a
lendletbl.
A helyi tmegkzlekeds menetrendje DHCP szmllkba csomagolva

A fenti diagram az egyik nagyobb telephelynk DHCP-kiszolgljnak teljestmnyadatait mutatja. A napl eredetileg a teljes
24 rt rgztette, n azonban csak az 5.30 s 9.00 kztti idszakot brzoltam. Mivel kezdetben csupa kisimtott vonalakat
lttam, elkezdtem nagytani a diagramot, jl ltszik, hogy ezer s tzezerszeres nagyts hozott eredmnyt. Vgl pusztn
az adatok fel fordulva (s tovbb szktve az idt 5.30 s 8.00 kz) a kvetkezt mondhatjuk a telephelyrl.
Nhny adat a reggeli indulsrl

Vannak kimutathatatlanul alacsony rtkek, pldul nem alakult ki sor, hogy a DHCP leellenrizze keletkezne-e konfliktus
egy cm kiadsakor. Ugyancsak nem trtnt elutasts (Nack/sec), ami leginkbb azt jelenti, hogy nem rkezett olyan
notebook a hlzata, amely korbban ms alhlzatban kapott cmet. A cmjvhagysok (Ack/sec) tlagos rtke 0,018
msodpercenknt, teht 1,08 percenknt 64,8 rnknt. A kt s fl ra alatt teht nagyjbl 162 gpet kapcsoltak be,
amelyek azutn jvhagyott cmmel elindultak. Persze a tbbsg eleve ltez brlettel indult, a discover csomagot is
kibocst gpek szma (0,001x60x60x2,5) mindssze 9. Ha elrulom, hogy kb. 10 gp llandan zemel, 10-et pedig
tlagosan nem kapcsolnak be, mris megkaptuk, hogy kb. 190 gpet lt el a cmkioszt rendszernk. A DHCP kiszolgl
28
NetAcademia-tudstr
teljes terheltsge 0,020 csomag msodpercenknt, vagyis csak 1,2 csomag percenknt. Ez a szolgltats vlheten nem
fogja megizzasztani a legkisebb szervereket sem.
Tudom, hogy vannak ennl jval nagyobb implementcik is. Egy Internetszolgltat akr szzezer cmet is kioszthat
egyetlen este nagyvllalati krnyezetben azonban a DHCP szerver mretezse s terhelse egyszeren nem lehet
problma.
A Diagnostic log
A mindennapi hibaelhrts sorn a teljestmnynaplnl is fontosabb lehet a Windows 2000-ben bevezetett diagnostic vagy
ms nven audit log.
Az audit log hasznlata nem ktelez, a szerver tulajdonsgai prbeszdpanelen lehet bekapcsolni, az advanced fln pedig
a naplllomnyok helyt is megadhatjuk.
Egy hasznos szolgltats az audit

A kvetkez pr sor a fenti szerver naplja ugyanaznap.
Microsoft DHCP Service Activity Log
Event ID Meaning
00
The log was started.
01
The log was stopped.
02
The log was temporarily paused due to low disk space.
10
A new IP address was leased to a client.
11
A lease was renewed by a client.
12
A lease was released by a client.
13
An IP address was found to be in use on the network.
14
A lease request could not be satisfied because the scope's address pool was exhausted.
15
A lease was denied.
16
A lease was deleted.
17
A lease was expired.
20
A BOOTP address was leased to a client.
21
A dynamic BOOTP address was leased to a client.
22
A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23
A BOOTP IP address was deleted after checking to see it was not in use.
50+
Codes above 50 are used for Rogue Server Detection information.
ID Date,Time,Description,IP Address,Host Name,MAC Address
51,11/03/03,00:35:43,Authorization succeeded,,mal.priv,
57,11/03/03,00:35:43,Server found in our domain,10.5.0.14,mal.priv,
11,11/03/03,00:47:07,Renew,10.5.1.32,AJK-056.mal.priv,00A0C9417B89
57,11/03/03,01:36:15,Server found in our domain,10.5.0.14,mal.priv,
11,11/03/03,02:06:04,Renew,10.5.1.38,AJK-099.mal.priv,00A0C9419FB2
A napl szerkezete meglehetsen egyszer, tblzatba foglalva a kvetkez:

Mez
Lers
ID
Az esemnyt azonost kd
Dtum
A bejegyzs dtuma
29
NetAcademia-tudstr
Id
A bejegyzs pontos idpontja
Lers
Az esemny lersa
IP-cm
Az gyfl IP-cme
Host nv Az gyfl host neve

MAC cm Az gyfl hlzati krtyjnak MAC cme
A napl elejn angolul felsoroljk a legfontosabb esemnykdokat. Ilyen lehet az induls, egy cmbrlet kiadsa, egy cm
megjtsa stb. Az 50 feletti kdok a szerverek felhatalmazsval kapcsolatosak, a DHCP sgjban minden kdot
rszletesen lernak.
Az audit log hallatlan elnye, hogy minden esemnyt feljegyez, ha teht a cmkiosztssal, az gyfelekkel val
kommunikcival vagy a felhatalmazssal brmi problmnk lenne, ez lesz az els szm segdletnk a problma
elhrtsakor.
Nem rszletezzk, csak megemltjk, hogy a DHCP termszetesen a Windows 2000 esemnynapljba is kpes elhelyezni
bejegyzseket. Akinek a fenti megoldsok egyike sem nyjtja azt, amit elvr, akkor mg mindig adott a lehetsg, hogy
SNMP alap megfigyelst vgezzen (a DHCP kln MIB adatbzissal rendelkezik) vagy akr a Microsoft Operation Manager
beptett tudstrt is hasznlhatja. A naplz s monitoroz rendszerek tovbbi boncolgatsa helyett ttrnk egy msik
nagyon fontos tmra, a DHCP adatbzis kezelsre s karbantartsra.
A DHCP kiszolglk adatbzisa
Volt olyan kollgm, aki ktkedst fejezte ki, amikor elmesltem neki, hogy a DHCP-adatbzisokrl akarok rni. Szerinte, ha
baj van, egyszeren csinlunk egy j kiszolglt s ksz. Nos, valban, az esetek nem elhanyagolhat rszben ez egy
jrhat t. Igaz, elfordulhat esetlegesen cmtkzs, de kisebb hlzatoknl ez is ritka. Vannak azonban esetek, amikor
egy DHCP-adatbzis fontoss vlhat. Ha nagyszm lefoglal cmnk van, vagy BOOTP gyfelnk, ha tbb scope-ot is
mkdtetnk (akr tbb tucatot), ha klnleges paramterekkel, osztlyazonostkkal lttuk el az gyfeleinket, taln nem
mindegy, hogy jabb hossz napokat tltnk el az adatbzisunk kialaktsval, hagyjuk, hogy zporozzon a felhasznlk
panaszradata a cmtkzsek miatt, vagy nmi erfesztssel megmentjk az adatbzisunkat az enyszettl.
A legfontosabb fogsokat tekintjk t: megvizsgljuk az adatbzis mkdsi elvt, majd nhny kritikus mveletet is
ismertetnk, mint pldul az adatbzis mozgatsa, javtsa, mentse s helyrelltsa.
A DHCP-adatbzis szerkezete
A DHCP a Microsoft ltal tbb termkben is alkalmazott JET adatbzismotort hasznlja. (Ez az alapja tbbek kztt az
Access, az Exchange 5.5 s a WINS szolgltatsok.) A hasonlsg olyan fok, hogy aki jrtassgot szerzett mr egy msik
termk adatbzisnak menedzselsben, knnyedn megbirkzik a DHCP adataival is.
A JET adatbzis nem egyetlen llomnybl ll. Ha megvizsgljuk a DHCP knyvtrat, akkor a kvetkez fjlokat fedezhetjk
fel:
J50.log (J50xxx.log) tranzakcis llomnyok. A JET adatbzismotor nem azonnal az adatbzisba rja a vltozsokat,
hanem n. tranzakcis llomnyokba. Egy tranzakcis llomny mrete lland, a hasznlat sorn az adatbzismotor
csak kitlti. Amikor a fjl megtelt, egy jat kezd a rendszer mindaddig, amg egy sikeres ments nem trtnik, vagy
szablyosan le nem lltjuk a DHCP-szervert.
J50.chk Checkpoint llomny. Annak az informcinak a helyt jelzi az utols tranzakcis llomnyban, amelyet
sikeresen bert a rendszer az adatbzisba.
DHCP.MDB A tnyleges adatbzis.
Dhcptmp.mdb Ideiglenes llomny az indexek karbantartsakor keletkezik. Hibs lellskor a knyvtrban maradhat.
Resx.log Egy helyfenntart llomny. Ha vletlenl elfogyna a hely a DHCP adatbzis ktetn, a motor ezeket az
llomnyokat felhasznlva fejezn be a tranzakcit, majd lelltan a szolgltatst.
A teljes adattartalom ezek szerint az adatbzis, a chk llomny, valamint az adatbzisba be nem rt tranzakcikat tartalmaz
llomnyok egyttesvel rhat le.
Az adatbzis mentse
Az adatbzis mentsrl maga a rendszer is gondoskodik. A regisztrcis adatbzis szerint az alaprtelmezett backup
tvonal a %SystemRoot%\System32\dhcp\backup. A ments gyakorisga 60 perc. Ezt az
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\backupInterval
rtkkel mdosthatjuk. Ugyanitt vltoztathat meg a ments tvonala. Ha az tvonal ms meghajtra mutat, mint az eredeti
adatbzis helye, mris megtettk az els lpst a DHCP szervernk megmentse rdekben.
Az adatbzis tmrtse s javtsa
30
NetAcademia-tudstr
A mentsnk megvan, de ez nem jelenti azt, hogy rgtn hasznlnunk kellene. Ha az esemnynaplban piros x-szel jelzett
JetErr hibkat tallunk, a rendszerhez mellkelt Jetpack.exe segdprogram segtsgvel megprblkozhatunk az
adatbzisunk kijavtsval. A mvelethez le kell lltanunk a DHCP kiszolglt, majd a kvetkez mdszert hasznlhatjuk:
1. Navigljunk a DHCP-adatbzis knyvtrhoz.
2. Adjuk ki az albbi parancsot:
Jetpack dhcp.mdb temp.mdb
A mvelet megprblja orvosolni az adatbzis logikai hibit, tovbb egy offline tmrtst vgez.
(A fenti mveletet frtztt DHCP-nl is elvgezhetjk, feltve, hogy eltte az erforrst Offline llapotba lltottuk. A
munkaknyvtr ekkor termszetesen az erforrs ltal hasznlt kzs lemezen lesz. A mvelet befejezse utn az erforrst
jra el kell indtanunk.)
Az adatbzis helyrelltsa
Amennyiben nem boldogulunk az adatbzis javtsval, ktfle mdszerrel is helyrellthatjuk a szolgltatsunkat.
Az els esetben ragaszkodunk az eredeti adatbzishoz. Ekkor a kvetkez teendink vannak:
1. Mentsk el a rgi nem hasznlhat adatbzist.
2. Ha megvan a legutbbi automatikus ments, msoljuk az eredeti DHCP adatbzis helyre.
3. Tmrtsk a Jetpack.exe programmal az adatllomnyt.
Ezutn a szolgltatsnak mr el kell tudnia indulni. Ha nem talljuk a scope-jainkat, helyre kell lltanunk a DHCP
konfigurcit tartalmaz regisztrcis gat is. Az automatikus backuppal egytt a Windows 2000 ezt is lementi egy DHCPCfg
nev llomnyba. (Ez valjban a HKLM\Software\Microsoft\DHCPServer\Configuration kulcs tartalma). Ha ezzel nem
rendelkeznk, a legutbbi mentsbl kell megszereznnk az llomnyt.
Akrhogy is, amikor a szervernk elindul, egszen biztosan nem a legfrissebb llapottal rendelkeznk. Szksgnk lesz a
regisztrcis kulcs s az adatbzis kztti konzisztencia megteremtsre, tovbb biztostani kell, hogy az gyfelek
vletlenl se kapjanak dupln IP cmet. Az els feladatrl gy gondoskodunk, hogy a szerverre jobb oldali egrgombbal
kattintunk, majd a Reconcile menpontot vlasztjuk. Ezutn be kell kapcsolni a szerver tulajdonsgai kzt az Advanced
fln tallhat Conflict detection eljrst, gy a kiszolgl egy cm kiadsa eltt - szrt zenettel meggyzdik arrl, hogy
van-e msik lloms, amely ezt a cmet hasznlja mr. Ez persze nmi teljestmny-visszaesssel jr.
Van egy msik jrhat t a szerver helyrelltshoz, ennek menete a kvetkez:
1. Egy j adatbzis hozunk ltre gy, hogy elmozgatjuk az eredeti adatbzist, s resen hagyjuk a knyvtrt. A
DHCP-szolgltatst elindtva egy j res adatbzis keletkezik
2. Helyrelltjuk a DHCPCfg llomny segtsgvel a regisztrcis adatbzis DHCP-szerverre vonatkoz rszt
3. Elvgezzk a Reconcile mveletet.
4. Bekapcsoljuk a Conflict detection eljrst.
Az adatbzis mozgatsa
A fenti tudsunkat arra is felhasznlhatjuk, hogy a DHCP kiszolglt egyik szerverrl a msikra kltztessk. (Tegyk fel,
hogy a Server1-rl a Server2-re mozgatjuk az adatbzist.) Ehhez a lpsek a kvetkezk:
1. lltsuk le a Server1-en a DHCP szolgltatst.
2. Mentsk le a DHCPCfg llomnyt a regisztcis adatbzis fent ismertetett gbl. Msoljuk az llomny a Server2-re.
3. A Server2-n teleptsk a DHCP szolgltatst, majd lltsuk le a szervizt.
4. Trljk a frissen teleptett adatbzisfjlokat a %systemroot%\system32\dhcp knyvtrbl s msoljuk oda a Server1
DHCP adatbzist
5. lltsuk helyre a DHCPCfg regisztrcis gat a Server1-rl lementett fjl segtsgvel
6. Indtsuk el a Server2-n a DHCP-kiszolglt
7. Vgezznk Reconcile mveletet.
Zrsz
A DHCP-t ismertet cikksorozat lezrul. gy rzem, hogy az elmlt tbb mint fl v sorn egy j alapos tvtanfolyamot
sikerlt alkotni. Azt remlem, hogy az olvask tbbsgnek tfog kpet adtam errl a meghzd, mde fontos
rendszerelemrl. Taln voltak kezdk, akik most mr majdnem mindent tudnak, s voltak haladk, akik imitt-amott
kiegszthettk a tudsukat. Habr az IPv6 hosszabb tvon cskkenteni fogja tmnk fontossgt, gy gondolom, mg
hossz ideig hasznos lesz a megszerzett tuds.
Vgezetl egy apr titok: a Windows Server 2003 cmkioszt szolgltatsa s a Windows 2000-hez kpest minimlis
vltoztatson esett t, az itt megszerzett ismerethalmaz teht j esllyel 2006-ig, vagyis a kvetkez Windows Server
verziig is friss maradhat. Br az is igaz, hogy ez esetben kevsb az opercis rendszer, mint inkbb a szabvnyvltozs
lehet fontosabb. Akrhogy is: legynk rsen, legynk naprakszek.
lepenyet@mal.hu
31
NetAcademia-tudstr
Q173396 How to Restore a Corrupted DHCP Database File
Q130642 How to Move a DHCP Database to Another Windows Server
Q145881 How to Use Jetpack.exe to Compact a WINS or DHCP Database
Microsoft Systems Architecture: Enterprise Data Center
Reference Architecture Guide Chapter 6 Network Services
32

A DHCP Rejtett Szépségei - I.

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

A DHCP Rejtett Szépségei - I.

Încărcat de

Drepturi de autor:

Formate disponibile

NetAcademia-tudstr

A DHCP rejtett szpsgei I.

Az gyfl s a DHCP szerver kezdeti csomagvltsai

Az gyflszmtgpek eloszlsa az eltelt brletid fggvnyben

A DHCP rejtett szpsgei II.

A scope legfontosabb adatai

Az t kritikus opci Windows krnyezetben

A DHCP s a DNS szolgltatsok egyttmkdnek, ha ez mi belltjuk

A titokzatos 81-es opci a kezelfelleten

A DHCP rejtett szpsgei III.

DHCP-kiszolgl egy scope ltrehozsa utn

Kt cmtartomny alkotta superscope

Egy alhlzat kt logikai IP-hlzattal

A DHCP rejtett szpsgei IV.

A brletid megadsval az 51-es, 58-as s 59-es

A szerver, a scope s a client opcik egymsba gyazdnak

Szlltk s osztlyok alkalmazs az opcik kztt

Definiltunk egy sajt opcit a nyomtatinkhoz

Elre belltott User class opci alkalmazsa

Default user class

Default remote access class

Default BOOTP class

A DHCP rejtett szpsgei V.

A tovbbt gynk az RRAS szolgltats egyik funkcija

Az gynkkonfigurls nem rdngssg

A klyha: egy DHCP kiszolgl, egy alhlzat

Egy cmkioszt szerver tbb alhlzattal

Ha nem mi felgyeljk az tvlasztkat

Az RRAS-t s a DHCP-t ezen a panelon

DHCP kiszolgltl az RRAS-on keresztl

RRAS LAN adapter belltsa

RRAS LAN adapter belltsa

Az IP-cm alapjn, automatikusan Class A,B vagy C subnetet kap az gyfl

A DHCP rejtett szpsgei VI.

A BOOTP gyfeleknek 30 napra szl az alaprtelmezett brlet

A BOOTP szabvnyt kvet prbeszdpanel

224.0.1.1 Network Time Protocol

A 224.0.1.0 238.255.255.255 szabadon felhasznlhat multicast-ra pl alkalmazsok szmra, legyenek akr az

Egyszeren konfigurlhat multicast cmtartomny

A DHCP rejtett szpsgei VII.

A gyflszmtgpek eloszlsa az eltelt brletid fggvnyben

Egyetlen szervernk van.

Viszonylag kicsi, jl tlthat hlzattal dolgozunk.

Nincsenek BOOTP gyfeleink. (k jraindulskor mindenkpp ignyelnek IP-cmet.)

Nem konfigurltuk gy az gyfeleket, hogy lellskor engedjk el a cmket.

A 80-20-as (50-50-es) eljrs alkalmazsa

A DHCP-szolgltats a virtulis szerveren tallhat

A helyi tmegkzlekeds menetrendje DHCP szmllkba csomagolva

Nhny adat a reggeli indulsrl

Egy hasznos szolgltats az audit

A napl szerkezete meglehetsen egyszer, tblzatba foglalva a kvetkez:

A bejegyzs pontos idpontja

Host nv Az gyfl host neve

DHCP.MDB A tnyleges adatbzis.

S-ar putea să vă placă și