1.1 Inleiding

Networking Services

4/1 IP-services 4/1.1

IPX

Inleiding

Onder andere door internet is het woord TCP/IP bij veel meer mensen bekend geraakt dan alleen maar bij computerbeheerders. TCP/IP is in principe een protocol waarmee communicatie opgezet kan worden tussen servers en clients. In het verleden had Novell een eigen protocol ontwikkeld, namelijk IPX. Door de druk vanuit de markt is Novell overstag gegaan en heeft het bedrijf bij de introductie van NetWare 5 een pure IP-omgeving geïntroduceerd hetgeen inhoudt dat de kernel van het operatingsysteem in staat is puur en alleen op IP te draaien. In het verleden bedacht Novell nogal eens oplossingen waarbij men door middel van het inpakken van pakketten in IPX (of andersom) toch in staat was bepaalde diensten aan te bieden. De markt is (en was) hier niet echt gelukkig mee en heeft liever maar een protocol om te beheren en op dit moment ligt daarbij de voorkeur op TCP/IP. Daarmee hebben we gelijk het eerste probleem te pakken. Werkstations dienen van IP-informatie, zoals een IP-nummer, default gateway en DNS-gegevens te worden voorzien. In het verleden kon u dat moeiteloos doen met Bootp (een soort platte database, waarin per regel een IP-nummer aan een MAC-adres werd gekoppeld), maar dit werkt niet meer vanaf NetWare file, servicepack 6 en bijvoorbeeld Windows 95 en hoger. Uiteraard kunt u dit oplossen door op de werkstations de nummers met de hand in te stellen en als er maar weinig

Novell Netwerkoplossingen, basiswerk

4/1.1-1

IP-services

stations zijn, is dit waarschijnlijk de snelste oplossing. Maar als er nu 100, 200, 1000 of nog meer stations staan? De operatie wordt dan wel erg omvangrijk en ook de kans op dubbele nummers door fouten neemt toe. Gelukkig ondersteunt Novell vanaf NetWare 4.11 DHCP.

Beheer IPnetwerk simplificeren

Wat is DHCP? DHCP staat voor Dynamic Host Configuration Protocol en is gemaakt om ervoor te zorgen dat individuele computers op een IP-netwerk de configuratie van een server (de DHCPserver) kunnen afhalen. De algemene bedoeling is het beheer van een groot IP-netwerk te simplificeren. De belangrijkste informatie in de configuratie is het uit te geven IP-nummer en het adres van de name-server. DHCP is gemaakt door the Dynamic Host Configuration Working Group van de Internet Engineering Task Force (IETF; een vrijwilligersorganisatie die protocollen definieert voor gebruik op internet). Als gevolg hiervan is de definitie vastgelegd in RFC 2131 van R. Droms, ‘Dynamic Host Configuration Protocol’, 3/97. Meer informatie over RFC’s (Requests for Comment) kunt u terugvinden via: http://info.internet.isi.edu/1s/in-notes/rfc/ http://www.cis.ohio-state.edu/hypertext/information/ rfc.html http://www.pmg.lcs.mit.edu/rfc.html Met DHCP hebt u twee mogelijkheden, namelijk het uitdelen van statische adressen en dynamische adressen. Aan beide zijn voordelen verbonden.

Statische adressen

4/1.1-2

De voordelen van statische adressen zijn dat u een koppeling hebt tussen het IP-adres en het MAC-adres dat niet


Networking Services

verloopt. Mochten er vanaf een bepaald IP-adres dingen gebeuren waarover klachten ontstaan (bijvoorbeeld een seks-webserver), dan is vrij gemakkelijk de locatie te achterhalen. Een ander voordeel is de minimale belasting van de DHCP-server; minder veranderingen in de DHCPtabellen brengt met zich mee dat er relatief weinig updates nodig zijn voor de tabellen. Dynamische adressen

De voordelen van dynamische adressen zijn de relatief eenvoudige initiële configuratie en indien een tekort aan adressen dreigt, kunnen deze gemakkelijk weer vrijgegeven worden voor gebruik door andere computers. Welk soort adressen u wilt gebruiken hangt af van de eisen die de gebruikersomgeving stelt. We gaan nu zowel voor de NetWare 4.11-omgeving als een NetWare 5.x-omgeving dieper in op het installeren, configureren en beheren van de DHCP-server.


4/1.1-3

IP-services

4/1.1-4


Networking Services

4/1.2 Beheer van DHCP in OES2 4/1.2.1 Inleiding Een van de vernieuwingen in OES2 is dat DNS en DHCP tegenwoordig ook in de Linux-versie van OES in eDirectory geïntegreerd zijn. Dit betekent dat de configuratie meelift met de eDirectory-replicatie en dat het beheer vanuit iManager plaatsvindt en niet langer vanuit YaST of met behulp van Linux-configuratiebestanden. In deze paragraaf leest u hoe u DHCP installeert in OESv2. Het beheer van DHCP in OES2 vindt plaats vanuit iManager. Voordat echter alle noodzakelijke componenten beschikbaar zijn, moet u eerst met YaST de DHCP-service installeren. Wilt u DHCP beheren op een NetWare 6.5 SP 7-server? Dan gebruikt u de stand-alone Java-utility die sinds NetWare 5 voor dit doel met NetWare meegeleverd wordt.

Procedure

4/1.2.2 Installatie van DHCP in YaST Voordat u DHCP in iManager kunt configureren, moet u het eerst in YaST installeren. De onderstaande procedure beschrijft hoe u hiervoor te werk gaat. 1. Start YaST met rootpermissies en kies vervolgens Open Enterprise Server en Open Enterprise Server Install and Configuration. Selecteer dan onder OES Services de optie Novell DHCP. Klik op Accept om verder te gaan en wacht totdat alle softwarepackages naar uw server gekopieerd zijn.

Novell Netwerkoplossingen, aanvulling 29

4/1.2-1

IP-services

Voordat u met Novell DHCP aan het werk kunt, moet u het in YaST installeren.

2. Klik in het scherm Novell Open Enterprise Server Configuration op de link Novell DHCP Services om de initiele configuratie te doen. Hiermee opent u het venster dat u in de volgende afbeelding ziet. 3. Om te beginnen wordt gevraagd waar in eDirectory u het DHCP-serverobject wilt aanmaken. Standaard wordt het object aangemaakt in dezelfde context als uw serverobject en het ligt voor de hand dit gewoon zo te laten. De locatorcontext en de groupcontext hebben betrekking op de mogelijkheden voor de DHCP-server om informatie uit eDirectory te halen. Het is een goed idee deze objecten zo hoog mogelijk in de tree te zetten (dus op organizationniveau) om het zoeken te vereenvoudigen.

4/1.2-2


Networking Services

Configureer hier de initiële parameters voor de DHCP-service.

De volgende optie die wellicht niet helemaal duidelijk is, is de LDAP-methode. Hier kiest u Static als u niet wilt dat de DHCP-server probeert verzoeken van hosts die binnenkomen te verifiëren in eDirectory. Dit is goed voor de performance, maar minder veilig. Kiest u Dynamic, dan checkt de DHCP-server of hosts die een verzoek uitsturen voorkomen in eDirectory en zal dit weigeren als dit niet het geval is. Tot slot is er de optie Chase referrals. In LDAP is een referral informatie die een LDAP-server niet in zijn eigen database kan vinden, maar waarvoor contact moet worden gemaakt met een andere LDAP-server. Dit betekent in de praktijk dat u naar een replica gaat van een childpartitie die niet op uw eigen server voorkomt.


4/1.2-3

IP-services

Voor goed functioneren van de DHCP-server is het van belang deze optie altijd aan te hebben. Klik nadat u al deze opties naar wens hebt aangepast op Next om verder te gaan. 4. In het volgende scherm regelt u de beveiliging van de communicatie tussen server en eDirectory. Deze koppeling is belangrijk als de DHCP-server op een server draait waar geen replica van eDirectory aanwezig is. Bestaat er wel een lokale eDirectory-replica, dan is het niet nodig om TLS-beveiliging toe te voegen. Om te beginnen voert u beheerderscredentials in waarmee aangemeld kan worden op eDirectory. Daarnaast geeft u aan of en zo ja, hoe certificaten gebruikt moeten worden in de communicatie. De beste optie die u kunt opgeven bij Request Certificates is Allow. Dit betekent dat de server de client vraagt een certificaat aan te bieden om een SSL-sessie tot stand te brengen. Heeft de client dat certificaat niet, dan is dat niet erg, maar als een fout certificaat aangeboden wordt, wordt de verbinding direct verbroken. Als er dan gewerkt moet worden met certificaten, moet u ook aangeven waar de servercertificaten teruggevonden kunnen worden. Hiervoor laat u de onderste drie opties verwijzen naar een certificaat in de directory /etc/opt/novell/certs, waar Open Enterprise Server standaard zijn certificaten neerzet.

4/1.2-4


Networking Services

Als de DHCP-server draait op een server waar geen eDirectory-replica aanwezig is, is het een goed idee een SSL-beveiligde verbinding tot stand te brengen.

5. Geef nu aan op welke netwerkkaart de DHCP-server zijn diensten moet aanbieden en klik op Next om verder te gaan.


4/1.2-5

IP-services

Bepaal op welke netwerkkaart uw DHCP-server zijn diensten aanbiedt.

6. Op dit moment keert u terug in het hoofdscherm in YaST waar u Novell-services kunt configureren. Klik hier op Next om de module af te sluiten. U bent nu klaar met dit deel van de configuratie.

Opties

4/1.2-6

4/1.2.3 DHCP configureren vanuit iManager Nu u zo ver bent dat de service geïnstalleerd is, kunt u DHCP verder configureren vanuit iManager. Dit doet u in iManager door onder Roles and Tasks de optie DHCP (OES Linux) te kiezen. U vindt hier een aantal opties. Hierna volgt een korte omschrijving van de verschillende beschikbare opties: • Scope Settings. De DNS- en DHCP-services hebben in eDirectory een aantal objecten die gebruikt worden om informatie uit eDirectory te halen en toe te passen in Novell Netwerkoplossingen, aanvulling 29

Networking Services

•

•

•

• •

•

•

•

de service. Standaard wordt voor dit doel de volledige eDirectory doorzocht. Dit is niet altijd handig, bijvoorbeeld niet als u een aparte organization unit hebt waarin alle benodigde objecten staan. U zou dan veel tijd verliezen met het doorzoeken van de volledige eDirectory. Maak daarom een scope aan waarin u aangeeft dat niet verder gezocht hoeft te worden dan de betreffende container. Service. Als u meerdere DHCP-servers in eDirectory hebt, kunt u een DHCP-serviceobject aanmaken. Dit is een container waarin alle algemene configuratiesettings voorkomen, die vervolgens door de specifieke DHCP-servers gebruikt kunnen worden. Server. Om DHCP te kunnen gebruiken moet ergens een DHCP-server fysiek op een server beschikbaar zijn. Deze server wordt via eDirectory beheerd via een DHCP-serverobject. Dit object maakt u hier aan. Shared Network. Een shared network is een fysiek netwerk waarop meerdere IP-subnetten beschikbaar gesteld worden. U kunt uw DHCP-server instrueren adressen beschikbaar te stellen op een shared network. Subnet. Hiermee verwijst u naar het IP-subnet waarop de DHCP-server zijn diensten gaat aanbieden. Pool. Waarschijnlijk kent u dat wat Novell een pool noemt beter als een range. De pool bevat de IP-adressen die u wilt uitdelen. Host. Met behulp van de host entry zorgt u ervoor dat afzonderlijke machines op basis van hun MAC-adres elke keer hetzelfde IP-adres toegewezen krijgen. Class. Een class is een zelf te definiëren categorie machines, bijvoorbeeld printers. U kunt Class gebruiken als aparte groep binnen de DHCP-omgeving waaraan u IP-adressen gaat toewijzen. Zone. Met behulp van Zone verwijst u naar een DNSzone. Dit is nodig als u Dynamic DNS wilt configureren,


4/1.2-7

IP-services

waarbij de DHCP-server updates stuurt naar de DNSserver als het IP-adres van een node gewijzigd is. Zo is de DNS-server altijd op de hoogte van de laatste wijzigingen. • TSIG Key. Als u Dynamic DNS wilt gebruiken, is het van belang dat DNS- en DHCP-servers elkaar vertrouwen. Hiervoor maakt u gebruik van TSIG-keys. Dit zijn symmetrische encryptiesleutels die tussen beide servers gedeeld worden. 4/2.1.4 Configuratie van DHCP Op basis van de kennis van wat de verschillende DHCPobjecten doen, bespreken we nu een eenvoudig voorbeeld. In dit voorbeeld wordt besproken hoe u een DHCP-server configureert, daarin een subnet aanmaakt en vervolgens een hostdefinitie maakt. Aangezien het verplicht is ook een DHCP-service te definiëren, beginnen we met de configuratie daarvan.

Voordat u een DHCP-server aanmaakt, moet u aangeven waar in eDirectory u de DHCP-service wilt maken.

4/1.2-8


Networking Services

1. Start iManager en meld u aan als gebruiker met beheerderspermissies. 2. Selecteer onder Roles and Tasks de optie DHCP (OES Linux), Service en kies dan Create Service. Geef in het volgende venster aan welke naam u voor de service wilt gebruiken en in welke context u deze neer wilt zetten. 3. Selecteer onder Roles and Tasks de optie DHCP (OES Linux) > Server > Create Server. Voer vervolgens een servernaam in en geef aan in welke context u de DHCPserver wilt aanmaken. Klik dan op Create om het DHCPserverobject aan te maken.

De configuratie in iManager begint met het aanmaken van het DHCP-serverobject.

4. Nadat het DHCP-serverobject is aangemaakt, gaat u verder met het aanmaken van een subnet. Selecteer hiertoe de optie Subnet > Create Subnet. U kunt nu aangeven binnen het bereik van welke service en welk shared network u het subnet wilt aanmaken, maar aanNovell Netwerkoplossingen, aanvulling 29

4/1.2-9

IP-services

gezien we in deze procedure deze objecten niet aangemaakt hebben, kunt u deze stappen overslaan. Voer nu het IP-adres in van het subnet en het subnetmasker dat gebruikt wordt. Voor alle duidelijkheid: het subnetmasker is hetzelfde als dat wat op alle nodes in het subnet gebruikt wordt, en in het IP-adres wordt het nodegedeelte op 0 gezet (zie afbeelding). U moet een subnetobject aanmaken voor alle subnetten waar nodes voorkomen die van de DHCP-server een IP-adres krijgen.

Bij het definiëren van het subnet voert u het IP-adres en bijbehorende subnetmasker in.

5. Nu u de te gebruiken subnetten hebt gedefinieerd, kunt u pools aanmaken. Een pool is een reeks adressen die u binnen dat subnet uitdeelt. Normaliter gaat het hier uitsluitend om adressen die u dynamisch uitdeelt, de adressen die u statisch uitdeelt wijst u toe door middel 4/1.2-10


Networking Services

van het hostobject. Om een pool aan te maken geeft u een naam aan de pool en specificeert u wat het eerste en wat het laatste adres is dat u in de pool wilt uitdelen.

Met de pool bepaalt u welke adressen binnen de range ook daadwerkelijk uitgedeeld worden.

6. Tot slot is het de moeite om ook hostobjecten aan te maken. Deze gebruikt u om bepaalde IP-adressen statisch aan een host toe te wijzen. Selecteer om te beginnen de optie Host > Create Host. De service wordt automatisch geselecteerd, maar u moet zelf aangeven in welk subnet de host gedefinieerd moet worden. Vervolgens geeft u de naam op van de host, het MAC-adres van de netwerkkaart van die host en het IP-adres dat u aan deze host wilt uitdelen. Met deze informatie kunt u er desgewenst ook voor zorgen dat uw DHCP-server de hostnamen dynamisch uitdeelt, zodat u dit vanuit Novell Netwerkoplossingen, aanvulling 29

4/1.2-11

IP-services

één locatie in het netwerk centraal kunt beheren. Klik dan op Create om de host aan te maken.

Het hostobject maakt het mogelijk om naast IP-adressen ook hostnamen dynamisch toe te wijzen.

7. Op dit punt is uw DHCP-server klaar voor gebruik. Ga terug naar de optie Server en selecteer hier Load/unload server. Kies vervolgens uit de uitschuiflijst uw server, vervolgens de optie Load Server en klik op OK om deze te starten. Vanaf dit moment is uw DHCP-server operationeel.

4/1.2-12


Networking Services

4/1.3

Integratie

Beheer met SNMP

DHCP onder Netware 5.1

4/1.3.1 Inleiding De basisbeginselen van DHCP zijn onder Netware 5.x niet veel veranderd. Het uitdelen van IP-adressen aan clients die daarom vragen blijft centraal staan. Zagen we echter in versie 2 bij Netware 4.x dat er met tekstfiles werd gewerkt, en dat er geen integratie was met de NDS, dan zien we dat Novell dit heeft veranderd en DHCP integreert met NDS. Er is nu dus wel een centrale plaats voor het beheer en dat is NDS geworden. Novell DHCP zorgt voor de volgende diensten: • Alle DHCP-configuratie wordt in en door NDS gedaan. • DHCP-opties kunnen op verschillende niveaus worden bepaald: • enterprise-niveau; • subnetniveau; • specifiek clientniveau. • De configuratietool ondersteunt im- en export voor: • inlezen van een DHCP-tab versie 2.0; • het wegschrijven en inlezen van de configuratie in NDS. • DHCP is nu met SNMP te beheren, waarbij er verschillende trapniveaus zijn (alle gebeurtenissen, belangrijke gebeurtenissen of geen gebeurtenissen). • Client policy-opties zijn (met name voor mobiele gebruikers binnen het netwerk) de volgende: • dubbele adressen zijn toegestaan; • dubbele adressen worden verwijderd; • dubbele adressen zijn niet toegestaan. • Het is mogelijk een deny-filter te maken waarmee aan specifieke MAC-adressen geen IP-adres wordt uitgedeeld.


4/1.3-1

IP-services

•

• Ping-ahead •

•

De DHCP-server zorgt ervoor dat de adressen worden gecacht, waardoor informatie sneller beschikbaar is vanuit NDS. In deze versie is het mogelijk om een zogenaamde ‘ping-ahead’ te doen, die dus controleert of het uit te geven adres niet al in gebruik is. Fouttolerantie is ingebouwd doordat de data met NDS worden gerepliceerd en doordat een andere server tijdelijk als DHCP-server kan worden ingezet. Het is mogelijk auditing aan te zetten, waardoor een logfile wordt bijgehouden van de belangrijke incidenten.

DHCP versie 3.0 ondersteunt de mogelijkheden die al in de voorgaande versie waren opgenomen en ondersteunt eveneens de mogelijkheden die in de volgende RFC’s zijn verwoord: • RFC 2131 – Dynamic Host Configuration Protocol; • RFC 2132 – DHCP Options and BOOTP Vendor Extensions; • RFC 2241 – DHCP Options and Novell Directory Services; • RFC 2242 – NetWare/IP Domain Name and Information. Voor het geval er nog gebruik wordt gemaakt van BOOTP (de voorloper van DHCP) worden de volgende RFC’s ondersteund: • RFC 1497 – BOOTP Vendor Information Extensions; • RFC 1534 – Interoperation Between DHCP and BOOTP; • RFC 1542 – Clarifications and Extensions for the Bootstrap Protocol.

4/1.3-2


Networking Services

4/1.3.2

Installatie van een DHCP-server onder Netware 5.x

Na deze inleiding in de mogelijkheden van DHCP gaan we ons bezighouden met het in bedrijf nemen van deze dienst. Bij een default-installatie wordt de installatie van de DHCP-server meegenomen en hoeven we dit niet alsnog te doen. Om te achterhalen of DHCP al op de server is geïnstalleerd, kunnen we via Nwconfig op de console kijken wat al aan services is geïnstalleerd. We doen dat als volgt: Laad Nwconfig op de console: NWCONFIG

Kies nu ‘Product Options’ en het volgende scherm verschijnt:


4/1.3-3

IP-services

Kies ‘View/Configure/remove installed products’ en vervolgens verschijnt een scherm waarop alle geïnstalleerde services alfabetisch worden weergegeven. Op deze server is DHCP nog niet geïnstalleerd en dat moeten we dus eerst gaan doen.

4/1.3-4


Networking Services

Tip: Indien u een product achteraf installeert, dan dient u ook het laatst geïnstalleerde servicepack van Novell opnieuw te draaien. Bij het draaien van het servicepack wordt namelijk in de products.dat file (de informatie die u via Nwconfig, product options, view installed products ziet) als uitgangspunt genomen voor de files die moeten worden geïnstalleerd. Als het product er niet bij staat, worden er ook geen updates van geïnstalleerd.

Activeren DHCP

Normaal gesproken zijn alle benodigde bestanden bij de installatie al naar het SYS-volume gekopieerd en moeten we de volgende stappen uitvoeren om DHCP te activeren: 1. Uitbreiden van het NDS-schema om de nieuwe DHCP NDS objecten te kunnen gebruiken. 2. Installeren van een Novell-client op het werkstation waarop de DHCP-managementsoftware gaat draaien. 3. Installatie van de managementsoftware en de benodigde snap-infiles in Nwadmin32. Ad. 1. Het uitbreiden van het NDS-schema voor DHCP doet u door op het fileserverconsole het volgende in te tikken: LOAD DNIPINST Nadat u deze NLM hebt geladen, krijgt u de melding terug dat het schema is uitgebreid en nu kunt u verder. Gemakshalve gaan wij ervan uit dat u de Novell Client32 al hebt geïnstalleerd op de machine waar u het managementconsole op wilt draaien. We gaan dus verder met stap 3, het installeren van de DHCP-managementsoftware. U doet dit als volgt:


4/1.3-5

IP-services

Start het programma SYS:public\dnsdhcp\setup.exe en u krijgt het volgende scherm:

Klik op Next om verder te gaan en u krijgt het volgende scherm, waar u kunt invullen op welke schijf en directory u de software wilt installeren. We hebben hier gekozen voor de defaultwaardes die Novell opgeeft.

4/1.3-6


Networking Services

Snap-infiles

Novell heeft inmiddels het set-upprogramma zodanig gemaakt, dat gevraagd wordt of de snap-infiles voor u moeten worden geïnstalleerd. Uiteraard wilt u dat, want het managen van de software wordt hierdoor een stuk makkelijker. Vink deze optie dus aan.

Hierna vraagt het installatieprogramma waar de snap-ins moeten worden geïnstalleerd. Het is het handigst dit in de SYS:public\win32 te doen, zodat bij het standaard gebruik van Nwadmin vanaf het netwerk deze DHCP snap-in in ieder geval is geladen.


4/1.3-7

IP-services

Het initiële installatiewerk is gedaan en we kunnen nu verder gaan met het configureren van de software. Hiervoor moeten we uiteraard de managementconsole starten. Op uw desktop of in uw menu is een link aangemaakt naar het programma. Start dit nu op en u krijgt het eerste scherm, dat vraagt om welke NDS-tree het gaat.

U krijgt nu het volgende scherm te zien:

4/1.3-8


Networking Services

De console start standaard op met als beeld de DNS-zones. We zijn echter op dit moment geïnteresseerd in DHCP en moeten dus op deze optie klikken om in het DHCP-scherm te komen:


4/1.3-9

IP-services

Nieuwe server maken

We gaan allereerst een nieuwe DHCP-server aanmaken. Dit doen we door op het ‘Create’-icoon te klikken. Dit is het tweede icoon vanaf de linkerkant gezien en is een soort geel-bruin blokje. Als we hierop klikken krijgen we het volgende scherm te zien:

Vervolgens wordt ons gevraagd welke server we moeten hebben. Hiervoor kunnen we door de NDS browsen om over te gaan tot een selectie.

Waarbij we uiteindelijk het juiste serverobject selecteren.

Nadat we de server hebben aangemaakt gaan we verder met aanmaken van het subnet waarvoor we IP-adressen

4/1.3-10


Networking Services

willen uitdelen. We doen dit door wederom op het ‘Create’icoon te klikken en de optie ‘Subnet’ te selecteren. Het volgende invulscherm verschijnt:

C-range

Dit vullen we vervolgens in met onze eigen gegevens. Hier is gekozen voor een C-range uit de private range (een nietrouteerbare range die bedoeld is voor intern gebruik in een netwerk en niet direct verbonden is aan internet) en deze zijn vervolgens gecreëerd.

Als dit alles is voltooid, gaan we weer terug naar het hoofdmenu en zien dat een adresrange 192.168.2.0 is gecreëerd, waar de FSNG14NW5101 verantwoordelijk voor is.


4/1.3-11

IP-services

We maken nu de gegevens expliciet en vullen het commentaarveld en het hostname-veld in en krijgen dan het volgende beeld:

4/1.3-12


Networking Services

Standaardwaarde

Parameters

In het tabblad ‘Subnet options’ kunnen we vervolgens ingeven welk soort lease-type we willen gebruiken. Het lease-principe is gebaseerd op het feit dat een DHCP-client om de zoveel tijd contact opneemt met een DHCP-server om te bevestigen dat het uitgedeelde IP-adres nog in gebruik is door de client en dat de client dit IP-adres nog steeds wil gebruiken. Als u dus een tekort heeft aan IPadressen, zult u de leasetijd kort willen instellen, zodat de uitgedeelde adressen weer snel beschikbaar komen. De standaardwaarde is drie dagen. Ook kunt u kiezen voor de waarde ‘permanent’, waarbij de IP-adressen permanent aan het MAC-adres van de client worden gekoppeld.

Bij het tabblad ‘Other DHCP options’ kunnen we vervolgens nog allerlei parameters meegeven. Hieronder is door ons de nameserver voor dit segment ingegeven. Op het moment dat een client een DHCP-request doet, zal deze informatie ook aan de client worden gegeven en krijgt de client behalve een IP-adres ook een opgave van de nameserver.


4/1.3-13

IP-services

4/1.3-14


Networking Services

Exclusion

Dynamische pool

Als we nu weer teruggaan naar het hoofdmenu en de zojuist door ons geselecteerde range uitklappen, zien we dat daar al twee adressen vermeld staan, namelijk het netwerkadres 192.168.2.0 en het broadcast-adres 192.168.2.255. Deze adressen hebben een exclusion meegekregen en worden dus niet uitgedeeld.

Om een begin te maken met onze DHCP-server gaan we nu een dynamische pool van 100 IP-adressen aanmaken, zodat we snel in de lucht kunnen komen. We doen dit door het subnet te selecteren en vervolgens op het ‘Create’icoon te klikken. Het volgende scherm verschijnt:


4/1.3-15

IP-services

Subnetrange

We kiezen nu voor een Subnet Address Range, geven deze subnetrange een logische naam en geven aan welke adressen we willen uitdelen. In dit geval delen we dus de adressen vanaf 192.168.2.1 tot en met 192.168.2.100 uit.

We klikken op ‘Create’ en vervolgens keren we terug in het hoofdmenu waar we nu zien dat er een range van 1 tot 100 is tussengevoegd. We zijn nu klaar om onze DHCP-server te starten zodat er daadwerkelijk IP-adressen zullen worden uitgedeeld. We doen dit door op het fileserverconsole DHCPSRVR in te tikken gevolgd door een <Enter>. De DHCP-server wordt nu geladen en is klaar om adressen aan clients uit te delen.

4/1.3-16


deel 4_1_4

19-04-2006

15:59

Pagina 1

Networking Services

4/1.4

Het Service Location Protocol configureren

Vroeger, in de tijd van het IPX-protocol, was het vinden van een server eigenlijk nooit een probleem. Het protocol maakte gebruik van de zogenoemde ‘pushtechnologie’, waarbij informatie wordt verzonden over het netwerk ongeacht of de client de ook informatie nodig heeft. Bij het IPX-protocol verzond elke server elke minuut een compleet overzicht van alle services die bij die server bekend waren. Een server zond dus niet alleen zijn eigen informatie maar ook de informatie die hij van andere servers had gekregen. Omdat de pakketjes met informatie ook bij de andere servers aankwamen, leerden de servers van elkaar hoe het netwerk er uitzag. Door de tijdsinterval van een minuut was de convergentiesnelheid van het netwerk ook redelijk hoog en hadden de servers een behoorlijk accurate view van het netwerk. Het nadeel van deze technologie was/is dat in grotere netwerken een aanzienlijk deel van de bandbreedte wordt gebruikt om informatie uit te wisselen, ook als dit niet nodig is. Met de overstap naar TCP/IP ontstond voor Novell een probleem. IP-netwerken kunnen veel groter worden dan dat men met IPX gewend was. In theorie zou een aansluiting op internet tot gevolg kunnen hebben dat de server zou gaan proberen om alle informatie op te slaan en door te geven aan de clients. Maar zelfs als door middel van de configuratie zou zijn bepaald dat alleen het lokale netwerk in de IPX-scope zou worden opgenomen, zou het protocol met de huidige groei van netwerken te veel bandbreedte in gebruik nemen.


4/1.4-1

deel 4_1_4

19-04-2006

15:59

Pagina 2

IP-services

Pulltechnologie

De noodzaak om over te stappen op een ander soort protocol was dus duidelijk. Novell heeft ervoor gekozen om gebruik te maken van een reeds bestaand protocol, namelijk het door Sun ontwikkelde SLP-protocol. Dit protocol maakt gebruik van een ‘pulltechnologie’, waardoor er maar een minimale hoeveelheid communicatie noodzakelijk is en de gebruikte bandbreedte dus wordt beperkt. Het SLPprotocol kan op twee manieren werken: ongeconfigureerd of geconfigureerd. Volgens de RFC zou het voor kleine en middelgrote netwerken voldoende moeten zijn om de ongeconfigureerde methode te gebruiken. De ervaring leert echter dat in Novell-netwerken het verstandiger is om wat extra tijd te spenderen aan de configuratie van SLP. Het blijkt namelijk dat bij de standaardconfiguratie een server soms niet snel genoeg kan worden gevonden, en dan ontstaan er time-outs. Deze paragraaf bespreekt het SLP-protocol en legt uit hoe u de configuratie van SLP moet maken en beheren. Deze configuratie is gelukkig niet ingewikkeld en het kost feitelijk ook weinig tijd om hem te maken. Gezien de beperkte inspanning is het zeer verstandig om ook voor middelgrote en zelfs kleine netwerken SLP gewoon te configureren. Situaties waarin servers de ene keer wel en andere keer niet kunnen worden gevonden, zullen dan minder vaak (of zelfs nooit meer) voorkomen. 4/1.4.1 De standaardconfiguratie In de standaardconfiguratie maakt SLP gebruik van user agents (UA) en service agents (SA). Een UA is een systeem dat informatie van het netwerk nodig heeft. Een SA is een systeem dat informatie aan te bieden heeft. In elk geval zullen servers bijna altijd SA’s zijn, maar servers zijn ook eigenlijk altijd wel UA’s: ze hebben SLP-informatie nodig, bijvoorbeeld om elkaar te ontdekken of om uit te vinden

4/1.4-2


deel 4_1_4

19-04-2006

15:59

Pagina 3

Networking Services

waar een tijdserver te vinden is. SLP is immers een open standaard en de informatie die kan worden gevonden beperkt zich dus niet alleen tot Novell-services. Een werkstation zal eigenlijk altijd UA zijn, maar kan soms ook best als SA dienstdoen, bijvoorbeeld als de TSA’s op het werkstation zijn geïnstalleerd. De communicatie tussen SA en UA vindt plaats op basis van multicast. Multicast

Een multicast-pakket wordt niet naar een specifieke machine gezonden, maar is gekoppeld aan een bepaalde service. In het geval van SLP is het multicast-adres dat wordt gebruikt 224.0.1.22. Alle informatie die aan dit adres wordt gezonden, wordt door de switch op alle poorten doorgezonden. Op die manier zouden dus alle SA’s de informatie moeten krijgen en tijdig informatie moeten kunnen terugzenden aan de UA (in praktijk blijkt het dus niet altijd te werken). De communicatie naar de UA wordt overigens gedaan via een normaal unicast-pakket. 4/1.4.2 De directory agent (DA) Als u de moeite neemt om SLP te configureren, krijgt u te maken met een nieuw object. Dit object is een directory agent (DA). Zodra de DA actief wordt in een netwerk, verandert de manier waarop SLP communiceert. De SA zal de DA via een andere multicast ontdekken (het gebruikte adres is 224.0.1.35) en zich vanaf dat moment alleen nog maar registreren bij de DA. De SA zal ook niet meer reageren op vragen van UA’s. De DA verzamelt na verloop van tijd dus alle informatie van alle SA’s op het netwerk. De informatie wordt niet in een platte tabel weergegeven maar gesorteerd per service. Een NetWare-server zal meerdere entries in de database aanmaken voor bijvoorbeeld de eDirectory (service:NDAP_novell), de licensing server (service:nlsmeter_novell) en de server zelf (service:nwser-


4/1.4-3

deel 4_1_4

19-04-2006

15:59

Pagina 4

IP-services

ver_novell). Afhankelijk van de services die u op de server actief hebt, kunnen er natuurlijk nog meer entries worden gemaakt. Ook de manier waarop de UA’s communiceren verandert zodra er een DA in het netwerk actief is. De UA’s zullen niet langer via een multicast proberen een SA te bereiken, maar richten al hun vragen via een unicast aan de DA. Het gebruik van unicast-verkeer heeft een gunstig effect op de netwerkbelasting en zorgt ervoor dat vooraf bekend is waar het pakket naartoe moet worden gezonden. De communicatie die op deze manier wordt opgezet, zal onder normale omstandigheden nooit mislukken. Indien u in uw netwerk meerdere DA’s hebt geconfigureerd, die dezelfde informatie moeten bevatten, zult u er op de een of andere manier voor moeten zorgen dat de informatie wordt gesynchroniseerd. De standaardmanier om dit te doen is om gebruik te maken van een configuratiefile waarin u aangeeft met welke andere DA’s de machine moet communiceren. Novell heeft het overigens op een andere manier opgelost. Als u ooit de RFC’s zou nalezen, dan ziet u ook dat men aanraadt om zo min mogelijk DA’s in het netwerk actief te hebben. In principe is één voldoende, maar vanuit het oogpunt van beschikbaarheid is het logisch om een tweede aan te maken en misschien zelfs een derde, maar alleen in heel uitzonderlijke situaties meer dan drie. Dat betekent dus dat men ervoor heeft gekozen om in een netwerk met WAN-verbindingen de informatie op te vragen over die verbindingen heen en dus niet op alle nevenlocaties nog eens DA’s te gaan plaatsen. Ook hier kunnen we in een Novellomgeving iets afwijken van de standaard: door de manier

4/1.4-4


deel 4_1_4

19-04-2006

15:59

Pagina 5

Networking Services

waarop wij synchroniseren is hoeveelheid extra verkeer die nodig is om een DA te updaten minimaal. 4/1.4.3 De SLP-scopes Omdat het in grotere netwerken toch nog kan voorkomen dat de informatie te veel wordt, of dat het niet wenselijk is om bijvoorbeeld alle servers te tonen aan clients, hebt u de mogelijkheid om verschillende scopes aan te maken. Zo zou u een scope per locatie kunnen aanmaken (bijv. een voor Amsterdam, een voor Rotterdam en een voor Utrecht), maar u kunt ook scopes aanmaken die zijn gebaseerd op de taken van een server (bijv. een voor administratieve servers, een scope voor development en een scope voor algemeen toegankelijke servers). Bedenk wel dat SLP geen security-mechanisme is: dat u de informatie niet via SLP krijgt, wil niet zeggen dat u de server kunt bereiken of de informatie niet op een andere manier kunt krijgen. In de eDirectory-omgeving kunt u, als u eenmaal bent ingelogd, ook in de eDirectory zoeken naar servers en op die manier het adres achterhalen. Het doel van scopes moet u dus vooral zien als een mogelijkheid om de hoeveelheid informatie die wordt verzonden zoveel mogelijk te kunnen beperken. U kunt een server zodanig configureren dat zijn informatie in meerdere scopes wordt opgeslagen, of zelfs dat bepaalde informatie in de ene scope en bepaalde informatie in een andere scope terechtkomt. Dit kan zinvol zijn om informatie die voor gebruikers belangrijk is te splitsen van informatie die voor de servers zelf belangrijk is. Het gebruik van meerdere scopes zal in veel situaties echter niet noodzakelijk zijn. Ook een UA kan zodanig worden geconfigureerd dat er meerdere scopes worden geraadpleegd en zo hebt u dus de mogelijkheid om bijvoorbeeld


4/1.4-5

deel 4_1_4

19-04-2006

15:59

Pagina 6

IP-services

de werkstations van gewone gebruikers alleen maar in de lokale scope te laten zoeken en de werkstations van beheerders ook in de scopes van andere locaties. 4/1.4.4

Technische verschillen

Het verschil tussen SLP versie 1 en SLP versie 2 Zoals bij zoveel producten en implementaties was ook de eerste versie van SLP niet foutloos. De eerste versie had een aantal tekortkomingen waar men pas in praktijk achterkwam en die in de tweede versie zijn verholpen. Het gaat hier met name om technische zaken. Een van de belangrijkste toevoegingen is de mogelijkheid om authenticatie te gebruiken bij de communicatie tussen DA’s onderling en de communicatie tussen DA’s en SA’s of DA’s en UA’s. Versie 2 heeft ook het formaat en de definitie van veelgebruikte flags en waarden aangepast, met name om minder verplichte velden nodig te hebben. SLP gebruikt nu dezelfde codering van strings als LDAPv3, wat het voor ontwikkelaars eenvoudiger en dus aantrekkelijker maakt om ook SLP te ondersteunen. Mede hierdoor zullen steeds meer services zich gaan aanmelden bij SLP. Een van de grote verschillen tussen versie 1 en versie 2 is dat we in versie 1 konden werken zonder scopes (we noemden dit de ‘unscoped’ scope). Het risico van het werken zonder scopes is dat op het moment dat twee netwerken aan elkaar worden gekoppeld, de kans bestaat dat u verkeerde informatie krijgt of dat de twee scopes door elkaar heen gaan lopen. Om die reden moeten we in versie 2 altijd een scope-naam opgeven. Aardig detail is dat veel implementaties, ook die van Novell, nu standaard worden geconfigureerd met een ‘default’-scope. Als we van deze standaardnaam gebruik zouden blijven maken, lopen we dus hetzelfde risico als in versie 1.

4/1.4-6


deel 4_1_4

19-04-2006

15:59

Pagina 7

Networking Services

Een ander verschil tussen de twee versies is, dat we inmiddels, met versie 2 dus, een grotere hoeveelheid informatie in één keer kunnen verzenden. In versie 1 kon namelijk maximaal 64 kB aan informatie in één keer worden verzonden. Dat zou dus kunnen betekenen dat we niet alle informatie van beschikbare servers binnen zouden krijgen. Hoewel er bij het bepalen van de nieuwe versie veel te doen is geweest over deze beperking, valt hij in praktijk reuze mee: u kunt in die 64 kB gemiddeld (afhankelijk van de lengte van de servernamen) zo’n 700 servers bekendmaken. Er zullen niet veel netwerken zijn waarin het dus echt een probleem is om met versie 1 te werken. 4/1.4.5 De NetWare-implementatie Toen Novell in versie 5 van NetWare SLP voor de eerste keer implementeerde, maakten ze gebruik van versie 1 van SLP. De Novell-client maakt hier overigens nog steeds gebruik van. In NetWare 6 is Novell echter omgeschakeld naar versie 2 van SLP op de server. Hoewel het wel mogelijk is om in een combinatie van versie 1 en versie 2 DA’s te draaien (zeker aangezien ze de informatie in de eDirectory opslaan) is het niet aan te bevelen en kunt u beter alles op NetWare 6-servers draaien. De NetWare-implementatie van DA’s is namelijk zonder meer in staat om informatie van de beide versies van de SA’s op te slaan en weer aan UA’s aan te bieden. De versie van de UA is dan ook niet belangrijk: de SLPDA gedraagt zich als een versie 1-systeem als dat nodig is en gedraagt zich als een versie 2-systeem als het mogelijk is.

Synchronisatie

Zoals al gezegd wijkt Novell op sommige punten af van de standaardconfiguratie. Deze afwijking heeft niets te maken met de manier waarop SLP werkt naar de servers of clients, maar heeft met name te maken met de manier waarop de synchronisatie tussen de DA’s verloopt. Novell heeft ervoor


4/1.4-7

deel 4_1_4

19-04-2006

15:59

Pagina 8

IP-services

gekozen om de informatie die de DA’s verzamelen op te slaan in de eDirectory. Het effect hiervan is dat de synchronisatie van de informatie tussen DA’s dus niet wordt bepaald door de synchronisatie van de specifieke SLPinformatie, maar door de synchronisatie van eDirectory. Als we er door een slimme replica-plaatsing maar voor zorgen dat de informatie toch al naar de servers wordt gezonden die als DA dienst gaan doen, is er geen enkele reden om niet meerdere DA’s een netwerk actief te hebben. Natuurlijk is het onzin om van elke server een DA te maken, maar een situatie waarbij op elke locatie in elk geval een DA aanwezig is, kan zonder problemen worden opgezet, dit in tegenstelling tot wat de RFC’s voorschrijven. In veel netwerken die over verschillende vestigingen werken met een eDirectory, zal er al iets zijn als een globale container, waarin informatie staat die overal beschikbaar moet zijn en die dus al op alle vestigingen is gerepliceerd. SLP kan meeliften op deze configuratie door de SLPinformatie op te slaan in deze container. Als een netwerk normaal functioneert, zal SLP maar een minimale hoeveelheid bandbreedte en processorbelasting vergen. De servers die worden aangeboden op het netwerk zullen immers niet continu veranderen en zo vaak lange tijd ongewijzigd in de database blijven staan. 4/1.4.6 Waar configureren we SLP-informatie? De Novell-oplossing probeert zoveel mogelijk van de configuratie en de informatie van SLP op te slaan in de eDirectory. Als u wilt overstappen naar een geconfigureerd systeem, zult u dus informatie in eDirectory moeten invoeren. Daarnaast zijn er enkele bestanden op de server waarin u aanpassingen zult moeten doen. De eerste stap is het aanmaken van een scope in eDirectory. Hoewel het

4/1.4-8


deel 4_1_4

19-04-2006

15:59

Pagina 9

Networking Services

mogelijk is om SLP te configureren via iManager, is het eenvoudiger om deze taak nog in NwAdmin uit te voeren. In eDirectory zijn twee soorten objecten beschikbaar voor het configureren van SLP. U begint met het configureren van een scope-object:

Dit object heeft alleen een eDirectory-naam en een scopenaam nodig. Deze namen hoeven niet hetzelfde zijn, maar normaal gesproken is dat wel zo duidelijk. Zodra de scope is aangemaakt, kunnen we het SLPDAobject of de SLPDA-objecten aanmaken. Dit hoeft natuurlijk alleen te worden gedaan voor servers die als DA dienst zullen gaan doen. Het configureren van de SLPDA is iets meer werk dan het configureren van een scope. Na het invoeren van de naam van het object dient u aan te geven bij welke server het object hoort en welke scope-unit u wilt gebruiken.


4/1.4-9

deel 4_1_4

19-04-2006

15:59

Pagina 10

IP-services

Herhaal deze actie voor alle servers die als SLPDA dienst zullen gaan doen. Om ervoor te zorgen dat de SLPDA’s snel bij hun informatie kunnen komen, is het zeer wenselijk om een eDirectory-replica van de container waarin op de machine de configuratie is opgeslagen, aanwezig te hebben, maar strikt noodzakelijk is dat niet. Op alle servers, dus niet alleen de machines die als SLPDA dienst gaan doen, maken we een aanpassing in de file sys:\etc\slp.cfg:

4/1.4-10


deel 4_1_4

19-04-2006

15:59

Pagina 11

Networking Services

Standaard bevat deze file heel veel informatie over hoe SLP moet worden geconfigureerd. In het voorbeeld is dit verwijderd en staat alleen de informatie die interessant is voor de implementatie. In elk geval dient de eerste regel te worden opgenomen en hier wordt het adres gezet van de SLPDA. Indien u meer dan één SLPDA hebt, kunt u deze regel ook meerdere keren in uw configuratie-file zetten, steeds met een ander IPadres. In principe is het voldoende om maar één verwijzing te hebben. Zolang deze DA is opgestart, zal de registratie gewoon verlopen. Meerdere entries garanderen echter ook nu een betere beschikbaarheid. De regel die nog uitgemarkeerd is (register-type) stelt u in staat om bepaalde services alleen aan bepaalde scopes toe te voegen. Als u deze regel niet gebruikt, zal elke service in elke beschikbare scope worden aangemaakt.


4/1.4-11

deel 4_1_4

19-04-2006

15:59

Pagina 12

IP-services

Sla het bestand op nadat u de aanpassingen hebt gemaakt. Voor de configuratie van de server hoeft u nog maar één ding te doen: door middel van een aantal set-parameters de scope of scopes bepalen en de manier waarop een server zich mag registreren. Deze setting kunt u invoeren op de console, u kunt ze in de autoexec.ncf plaatsen en u kunt ze in het monitorscherm aanpassen:

Normaal gesproken hoeven er maar een paar settings te worden aangepast: • Set SLP scope list Deze parameter moet corresponderen met de naam van SLP-scope die u in iManager hebt opgegeven. • Set SLP static scope list De waarde van deze parameter bepaalt of de geconfigureerde scope list de enige is waarin deze server zich aanmeldt. U zou er dus voor kunnen kiezen om naast de gebruikte list ook dynamische lists te ondersteunen. Dit lijkt echter geen logische keuze.

4/1.4-12


deel 4_1_4

19-04-2006

15:59

Pagina 13

Networking Services

•

Set SLP DA discovery options Via deze parameter wordt bepaald hoe naar DA’s mag worden gezocht. De standaardwaarde is 15, wat betekent dat het op alle mogelijke manieren mag. Als u echter de configuratie via SLP.cfg bepaalt, is het logischer om dit ook als enige input te accepteren. Dit doet u door de waarde 4 toe te kennen aan deze parameter. Een uitleg van de mogelijke keuzes wordt overigens getoond in het monitorscherm als u deze optie kiest.

Naast deze drie opties is er nog een tiental opties die u zou kunnen instellen. De overige settings zijn alleen in specifieke situaties noodzakelijk. Op de machines waar u de SLPDA’s hebt geconfigureerd, kunt u deze nu opstarten door het commando LOAD SLPDA.NLM te geven op het console. Zodra de SLPDA’s draaien, klieren op de machines en op alle andere servers het commando SET SLP RESET=ON geven. Hierdoor wordt een her-initialisatie van SLP uitgevoerd en worden de setting sieDirectory SLP.CFG dus actief. Na enkele seconden zult u in de eDirectory, in uw scope container, de services van iedere machine zien verschijnen. Hieraan kunnen controleren of u de configuratie foutloos hebt gedaan:


4/1.4-13

deel 4_1_4

19-04-2006

15:59

Pagina 14

IP-services

Let er verder nog op dat u de autoexec.ncf aanpast en ervoor zorgt dat de SLPDA.NLM vanaf dat moment automatisch wordt gestart op machines die deze functionaliteit moeten gaan bieden. Hiermee is de confrontatie van de servers voltooid. U ziet nu een extra reden waarom het logischer is om SLP te configureren: de hoeveelheid tijd die u moet investeren om het geconfigureerd te krijgen, is zo minimaal, dat het zich altijd terugbetaalt. Ook op het werkstation dient er een en ander te worden gecontroleerd voor SLP. Deze settings staan allemaal in het client-configuratiescherm in het tabblad Service Location.

4/1.4-14


deel 4_1_4

19-04-2006

15:59

Pagina 15

Networking Services

In het scherm kunt u scope list en de directory agent invullen en voor beide settings kunt u ook bepalen of ze statisch zijn. Er is een aantal manieren om deze informatie automatisch in te vullen. Voor organisaties die ZENworks gebruiken, zou u ervoor kunnen kiezen om het via een policy te distribueren. Een andere mogelijkheid is om het via de DHCP-server te verspreiden. Bij de Novell DHCP-server kan deze informatie als een standaardoptie worden gekozen, bij andere DHCP-servers zult u deze opties waarschijnlijk eerst moeten toevoegen. Het gaat om opties 78 (directory agent) en 79 (service scope). Op alle Windows-machines waar de Novell-client op is geïnstalleerd, kunt u eenvoudig controleren hoe SLP is


4/1.4-15

deel 4_1_4

19-04-2006

15:59

Pagina 16

IP-services

gecontroleerd. Op een command window (een “DOS-box”) en geeft u het commando slpinfo /a (de /a zorgt er voor dat u alle opties ziet). Dit commando geeft u onder andere de informatie over de sloop list en de directory agent.

De scope-informatie van deze client toont dat de client dynamisch geconfigureerd is (anders zou u geen ‘unscoped’ scope zien) en dat de dide-scope hard in de client is ingevoerd, anders zou er achter DA tussen haakjes mcast staan als de confrontatie via multicast was ontdekt en DHCP als de configuratie via DHCP was gezonden. Hiermee is de complete configuratie van SLP uitgevoerd en hebt u er feitelijk geen omkijken meer naar. Natuurlijk moet u erop letten dat u alle nieuwe servers die u in een

4/1.4-16


deel 4_1_4

19-04-2006

15:59

Pagina 17

Networking Services

netwerk opneemt, ook voorziet van de juiste SLP-configuratie, maar als u zich daaraan houdt, zult u merken dat u nooit meer problemen hebt om services te kunnen vinden. Hiermee hebt u de voordelen van een semi-dynamische configuratie, zonder de overhead van een protocol zoals SAP.


4/1.4-17

deel 4_1_4

19-04-2006

15:59

Pagina 18

IP-services

4/1.4-18


1.1 Inleiding

Recommend Documents