Computernetwerken III: Reeks B

Computernetwerken III: Reeks B B1. Multicasting a. Hoe weet een router dat hij verantwoordelijk is om multicast berichten af te leveren aan cliënts (nietrouters) op de diverse subnetwerken waarop hijzelf is aangesloten. Bespreek het protocol dat hierbij gehanteerd wordt, inclusief de bijkomende faciliteiten van meer recente versies ervan. • IGMP ∗ Internet Group Management Protocol (IGMP) ∗ Wordt gebruikt om groepslidmaatschap informatie tussen hosts en routers te versturen ∗ IGMPv1 → Report berichten worden naar het groepadres die bereikt moet worden verstuurd → Wanneer de host niet meer geïnteresseerd is in luisteren dan stopt hij simpelweg met zenden van report berichten ∗ IGMPv2 → Report berichten worden naar het groepadres die bereikt moet worden verstuurd → Vanaf IGMPv2: Concept van 'explicit leave' ‐ Leave‐Group bericht ‐ De router antwoordt met een groepspecifiek Query bericht ° dit om te bepalen of er nog er nog andere hosts zijn die geïnteresseerd zijn ∗ IGMPv3 → Report berichten worden naar 224.0.0.22 verstuurd • De host ∗ 2 taken om een groep te joinen: → Luisteren naar layer 2 adres dat naar het IP multicast groep adres wijst → Een Host Memberschip Report bericht ‐ Dit triggert een van de routers, die IGMP ondersteunt, op het LAN om de groep te joinen mbv een multicast routing protocol (vb PIM‐SM) ∗ Een router zend periodiek IGMP Host Memberschip Query berichten → De router reageert hier op met een Report bericht → Om een stortvloed van berichten te vermijden worden 2 technieken toegepast ‐ De host wacht even (random) voor het antwoorden ‐ Vanaf IGMPv3 worden report berichten naar 224.0.0.22 verstuurd, als een host een report van een andere host krijgt, dan onderdrukt hij zijn eigen response bericht • De router ∗ Verstuurd IGMP Query berichten naar 224.0.0.1 met TTL = 1 ∗ Indien er meer dan 1 router op het netwerk is → Router van wie de Query berichten het laagste IP source adres heeft, wordt als actieve 'Querier' voor het subnet gekozen → De andere routers onderdrukken het zenden van IGMP queries, maar luisteren en cachen wel alle informatie van alle IGMP berichten ∗ Elke router die IGMP ondersteunt houdt een IGMP groep cache bij, dit is een tabel met volgende info: → Een lijst van alle groepen die geïnteresseerde hosts hebben → Het IP-adres van de host die het laatst aangekondigd heeft dat hij interesse heeft → Een time out value voor elk item van de tabel ‐ Als die 0 is, gaat de router er vanuit dat de groep geen members meer heeft ‐ Deze wordt gereset bij elke Memberschip Report Christophe Sysmans



b. Geef de basisprincipes van multicastrouting, en van de twee fundamenteel verschillende manieren om dit te realiseren, inclusief hun relatieve voor- en nadelen. c. Bespreek in detail de diverse facetten van het momenteel meest gebruikte multicastroutingprotocol, inclusief de technieken om de werking ervan nog meer te optimaliseren. d. Hoe kan men een Linux toestel als multicastrouter laten werken ? Geef twee concrete voorbeelden, en geef hierbij telkens aan hoe men de diverse multicastverkeerstromen kan opvolgen. e. Sommige routers verzorgen in het multicastproces (cfr. deelvragen a en c) bijzondere rollen, die ze pas na specifieke verkiezingsprocessen toebedeeld krijgen. Geef een overzicht van deze bijzondere functies, en de overeenkomstige verkiezingsprocessen.

Christophe Sysmans



B2. Draadloze netwerken a. Met welke opdrachten kan men respectievelijk op Windows Server en op Linux toestellen nagaan welke de karakteristieken zijn van de eigen Wifi interface en van de Wifi zenders in de buurt. Geef aan welke karakteristieken vermeld worden. • Windows: ∗ Karakteristieken eigen WiFi interface: netsh wlan sh int → Naam, beschrijving, GUID → Fysiek adres, status, SSID → BSSID, netwerktype, radiotype → Verificatie, coderingsmethode, verbindingsmodus → Kanaal, ontvangst-en verzendsnelheid, signaal en profiel ∗ Karakteristieken alle WiFi zender: netsh wlan sh net m=b → Netwerktype, verificatie, versleuteling → BSSID met ‐ Signaal, kanaal, radiotype, basissnelheden en overige snelheden • Linux: ∗ Karakteristieken eigen WiFi interface: ifconfig wlan0 of iwconfig wlan0 → ESSID, mode, frequentie → AP, bit rate → bij ifconfig: ipadres, Hwaddr, Broadcastadres ∗ Karakteristieken alle WiFi zender: iwlist scan wlan0 → kanaal, frequentie, kwaliteit, signaallevel, ESSID, encryptie b. De figuur ... toont het uiterste bereik van ... access points. Geef (naast de pijltjes) voor elk een Wifi kanaal aan. Verantwoord jouw keuze. Arceer de gebieden waar de gekozen topologie niet optimaal is, en geef aan wat daar het probleem is. • Zorg voor een ruimte van 5, 1‐6‐11 is ideaal voor geen storing te hebben. Kanalen die dicht bij elkaar liggen, zullen vechten voor dezelfde bandbreedte. c. In welk opzicht zijn Ad Hoc routingprotocollenk (in wireless meshes) anders dan de meer traditionele routingprotocollen (bedoeld voor internetwerken die uit bekabelde subnetwerken bestaan) ? • eventuele mobiliteit van de routers • uitvallen en herstel van verbindingen meer frequent, met variabele kwaliteit van de link • bijkomende criteria voor performantie en metriek, zoals stabiliteit onder mobiele omstandigheden, energie‐verbruik, signaal/ruis verhouding, ... • strikt minimale processing (energieverbruik) en netwerkbelasting gewenst bij topologiewijzigingen • alleen gedistribueerde algoritmen aanvaardbaar d. Geef de twee fundamenteel verschillende manieren om Ad Hoc routingprotocollen te realiseren, inclusief hun relatieve voor- en nadelen en hun optimaal toepassingsgebied. • 1. proactieve of table driven protocollen ∗ cfr. traditionele routing protocollen: routes voor alle actieve verbindingen, onafhankelijk hoe frequent die gebruikt worden ∗ berekend op basis van één of andere metriek ∗ aanpassing routes bij wijziging linkkarakteristieken ∗ relatief grote netwerkbelasing Christophe Sysmans



∗ routes onmiddellijk bruikbaar indien nodig, ook bij sporadisch gebruik concreet voorbeeld: OLSR • 2. reactieve of on‐demand protocollen ∗ routes pas geconstrueerd indien noodzakelijk ∗ route discoveries van andere routers worden gecached om routes sneller te kunnen bekomen ∗ zonder enige statische netwerkbelasting ∗ werkt in situaties met duizenden knooppunten, indien relatief weinig communicerende koppels ∗ initiële vertraging vooraleer gegevensoverdracht (of ICMP Unreachable) mogelijk is ∗ → concreet voorbeeld: AODV (Ad hoc On Demand Distance Vector Routing) e. Bespreek een concreet voorbeeld van een implementatie die tot één van deze categorieën behoort, met vooral aandacht voor de verschillen met het traditionele routingprotocol (voor bekabelde internetwerken), waarvan het is afgeleid. • Optimized Link State Routing ∗ LSAs router enkel doorgestuurd door beperkt aantal buren (multipoint relays, MPRs) ∗ minder overhead (t.o.v. OSPF) door meer selectieve flooding ∗ alle routes verwijzen naar een MPR als eerste hop naar de eindbestemming ∗ MPR criterium: beperkte deelverzameling bidirectionele buren van router, zodanig dat alle 2‐ hop routers onmiddellijke buur zijn van één van de geselecteerde MPRs ∗ elke router meldt periodiek (hello) zijn buren, zodat elke router uiteindelijk ook de volledige topologie tot op afstand 2 kent → MPR selec e ∗ selectieve flooding via MPRs leidt niet noodzakelijk tot route met optimale metriek (met betrekking tot bandbreedte, ...) f. Bespreek een concreet voorbeeld van een implementatie die tot de andere categorie behoort, nu met een gedetailleerde beschrijving van hoe de routingtabellen door specifieke berichtuitwisselingen ingevuld worden. • • • •

veronderstelt bidirectionele verbindingen ttl route verlengd door elk gebruik ervan eenvoudig principe: drie berichttypes volstaan voor basis implementatie 1) bron broadcast Route Request (RREQ) ∗ door bron, die data wenst te sturen, maar over geen recente route (ttl≠0) naar doel beschikt ∗ verwijzend naar bron en naar beoogd doel, + seq.nr. ∗ eenmalig doorgestuurd door intermediaire routers (niet bevestigd → verlies door collision mogelijk) ∗ die meteen Reverse Path naar bron construeren • 2) unicast van Route Reply (RREP) ∗ na ontvangst van RREQ ∗ hetzij door het beoogde doel ∗ hetzij door een intermediaire router die wel over een recente route (ttl≠0) naar het doel beschikt ∗ via geconstrueerd Reverse Path naar bron ∗ zodat intermediaire routers en de bron hun routingtabellen naar het doel kunnen bijwerken ∗ hello bericht (detectie buren): RREP met ip.ttl=1 • 2) Route Error (RERR) berichten zorgen voor: ∗ update routingtabellen, o.a. indien routers mobiel Christophe Sysmans



B3. Configuratie van DNS servers onder Linux De figuur in bijlage stelt een intranet bestaand uit een aantal Linux computers voor, met corresponderend IP-adres, van de vorm 192.168.16.z . Het getal z lees je af links van de naam van de computer. De getallen rechts van de naam van de computer moet je negeren. De computers staan gegroepeerd in een tabel met als header de naam van het domein waarin ze zich bevinden. De rechthoeken die domeinen groeperen stellen dan weer een zone voor. Stippellijnen duiden op een domein/sub-domein relatie. De pijlen laten toe om de primaire name-server van elke zone te achterhalen. Je hoeft geen reverse DNS te configureren. a. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers, waarbij je er rekening moet mee houden dat elk van deze servers ook secundaire nameserver is voor alle zones van de andere server: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht ! • / b. Bespreek in detail het begrip secundaire nameserver, inclusief voordelen, beperkingen en problemen. • Behouden exact dezelfde informatie als de primaire nameserver ∗ Voordelen: → Taak van primaire nameservers te verlichten → Fouttolerantie (indien primaire nameserver zou wegvallen) ∗ Beperkingen: → Wijzigingen van zone-gegevens kunnen enkel via primaire nameserver gebeuren ‐ Secundaire zal bij elke wijziging een nieuwe kopie moeten vragen aan primaire ∗ Configuratie: → Configuratie primaire nameserver ‐ Voor zonetransfer mogelijk te maken tss primaire en secundaire nameserver ° allow-transfer{ 192.168.0.2; } → Configuratie secundaire nameserver ‐ Type van de zone dient aangeduid te worden als ‘slave’ ‐ Primaire nameserver(s) moeten opgegeven worden, om zone‐kopie te kunnen opvragen ‐ zone “example.com” { type slave; master{ 192.168.0.1; } file “db.example.com” } ‐ De ontvangen gegevens worden automatisch in opgegeven file weggeschreven ° Zo kan secundaire nameserver snel als primaire geconfigureerd worden

Christophe Sysmans



B4. Configuratie van DNS servers onder Linux De figuur in bijlage stelt een intranet bestaand uit een aantal Linux ...(cfr.vraag B3)... achterhalen. Geen enkele zone heeft een secundaire nameserver. Je hoeft geen reverse DNS te configureren. a. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht ! • / b. Bespreek in detail het formaat van een zonebestand en zijn records. Je mag dit doen op basis van één van de oplossingen in a), doch je moet ook alternatieve records en formaten beschrijven, die je niet noodzakelijk hebt gebruikt. • Een zonebestand bevat de naamgegevens voor een enkele zone • Formaat: ∗ Elke lijn correspondeert met een DNS‐record ∗ Indien verdeeld over meerdere lijnen, groeperen met ( ) ∗ Elk DNS record bestaat uit 5 vaste velden (naam ttl klasse recordtype waarde): → Naam ‐ De naam van een machine of domein ° Indien spatie of tab wordt de naam van vorige record gebruikt ‐ Formaat: ° Niet‐gekwalificeerde alfanumeriek naam
Relatief t.o.v. het domein waarvoor dit een zonebestand is ° Absolute domeinnaam
Eindigt met een punt ° Speciale naam “@”
Verwijst naar de huidige oorsprong
Oorsprong kan gewijzigd worden met de $ORIGIN opdracht
Doorgaans enkel gebruikt bij SOA record → Time-To-Live ‐ Optioneel veld ‐ Geeft de geldigheidsduur aan van het DNS record ° Geeft dus aan hoelang de record mag gecached worden ‐ Weinig gebruikt, daar SOA record een default TTL waarde toekent → Klasse ‐ Definieert het geldige protocol voor een record ‐ Tegenwoordig altijd ‘IN’ (= INTERNET) ‐ Andere mogelijke waarden zijn ‘HS’ en ‘CH’ (protocollen ontwikkeld aan MIT) → Recordtype ‐ Geeft aan welk type record het is ‐ Mogelijke types: ° A
Een regulier IPv4 adres ° AAAA
Een IPv6 adres ° PTR
Pointer record dat verwijst naar een andere hostnaam
Gebruikt bij reverse DNS resolving ° MX
Een mailserver record
Wijst naar de mailserver waar mails voor die zone naar gestuurd worden Christophe Sysmans



°

SOA
Start Of Authority record
Definieert de zone ° NS
Een nameserver record
Definieert welke nameserver verantwoordelijk is voor deze zone ° CNAME
Een canonical name record
Gebruikt om alias op te geven voor bepaalde DNS naam
Gekozen naam mag enkel links van CNAME record staan  Niet aan linkerkant van andere definitie! → Waarde ‐ Laatste veld bepaalt de effectieve waarde van het record ° Bij A Type zal er bijvoorbeeld een IPv4 adres staan ∗ Eerste record is steeds een SOA record → Maar 1 SOA record, als we per zone 1 bestand gebruiken → Formaat: @IN SOA primaire_dns email ( volgnummer refresh interval retry interval expire interval default ttl ); ‐ Primaire DNS ° Een absolute naam die verwijst naar de primaire DNS server voor deze zone ‐ Email ° Het contactadres van de persoon, verantwoordelijk voor deze zone
“@” is vervangen door “.” (want @ heeft hier andere betekenis) ‐ Volgnummer ° Geeft de versie aan van de records ° Dient om nieuwe van oude data te onderscheiden ‐ Refresh interval ° Geeft aan hoe vaak de secundaire nameserver zijn records dient te updaten ‐ Retry interval ° Geeft aan hoelang de secundaire nameserver moet wachten voor een retry, bij een mislukte refresh ‐ Expire interval ° Geeft aan hoelang de gegevens mogen bewaard worden indien refresh mislukt is ‐ Default TTL ° Dit is de default TTL voor alle records in deze zone ∗ Na SOA record dienen de nameservers, verantwoordelijk voor de zone, opgegeven te worden → Ook indien de NS in het SOA record de enige NS is → Mogen relatieve vermeldingen zijn → @ NS primaire_DNS @ NS secundaire_DNS ∗ Bij de rootserver moeten de namen gebruikt in bovenstaande, expliciet geregistreerd worden in een A record (daar deze nergens kunnen opgezocht worden)

Christophe Sysmans



B5. Configuratie van DNS servers onder Linux De figuur in bijlage stelt een intranet bestaand uit een aantal Linux ...(cfr.vraag B3)... achterhalen. Geen enkele zone heeft een secundaire nameserver. Je hoeft geen reverse DNS te configureren. a. Stel het configuratiebestand en alle zonebestanden op van volgende DNS servers: ... . Gebruik relatieve DNS namen waar mogelijk. Gebruik noch forwarders, noch de $ORIGIN opdracht ! • / b. Bespreek in detail het formaat van een configuratiebestand. Je mag dit doen op basis van één van de oplossingen in a), doch je moet ook alternatieve opdrachten en sleutelwoorden beschrijven, die je niet noodzakelijk hebt gebruikt. • Een configuratiebestand is onderverdeeld in een aantal opdrachten, bepaald door sleutelwoorden • Belangrijkste sleutelwoorden: ‘zone’ en ‘options’ ∗ Deze opdrachten configureren de effectieve zones waarvoor de NS verantwoordelijk is ∗ zone “naam” { type ... } → Zonespecifieke configuratie afhankelijk van type: ‐ (Meerdere adressen worden gescheiden door ‘;’) ‐ type master ° file $BESTAND: de naam van het zonebestand ° allow‐update { $ADRES; }; : (optioneel) bepaalt welke clients dynamische updates mogen uitvoeren (kan ook adres met prefixlengte zijn) ° allow‐transfer{ $ADRES; }; : (optioneel) bepaalt welke clients zone‐transfers mogen uitvoeren (kan ook adres met prefixlengte zijn) ‐ type slave ° masters { $ADRES; }; : specifieert welke NS verantwoordelijk zijn voor de zone ° file $BESTAND: het bestand waarin de opgehaalde data zal opgeslagen worden ‐ type stub ° Gedraagt zich als een secundaire nameserver, maar dupliceert enkel NS‐records van de opgegeven master servers ‐ type forward ° Een nameserver die enkel requests doorstuurt naar een andere nameserver ‐ type hint ° Een speciaal type server, enkel gebruikt bij de “.” zone ° Wordt enkel gebruikt om bij opstarten de namen van de echte root‐servers te achterhalen ° file $BESTAND: het bestand waarin de root‐servers staan ° zone “.” { type hint; file “named.ca”; }

@ 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

Christophe Sysmans



B6. Configuratie van reverse DNS onder Linux a. Wat wordt beoogd met reverse DNS? Hoe wordt dit gerealiseerd? • Reverse DNS laat doe om een domeinnaam te vragen voor een gegeven IP adres • De DNS records voor deze omzetting zijn PTR‐records • Werking: ∗ Wat is de domeinnaam, horende bij ip w.x.y.z ? ∗ De NS verantwoordelijk voor dit domein is onbekend → Oplossing: ‐ Maken gebruik van pseudo‐domein: in‐addr.arpa ‐ w.x.y.z  z.y.x.w.in‐addr.arpa ∗ Sturen van aanvraag met behulp van dit pseudo‐domein → Aanvraag wordt gestuurd naar NS, verantwoordelijk voor in-addr.arpa → Aanvraag wordt gedelegeerd, totdat uiteindelijk de juiste NS uitgekomen wordt ‐ Dit delegeren is meestal mogelijk, daar de numerieke opdeling deels overeenkomt met de hierarchie ‐ Indien niet mogelijk op te delen, zal de delegerende server verschillende aanliggende blokken moeten uitdelen (supernetting) • Realisatie: ∗ Er dient een primaire nameserver geconfigureert te worden voor domein “in‐addr.arpa” → Identiek SOA record → Enkel PTR records in de zone → Alle namen in bestand zijn relatief t.o.v. y.x.w.in-addr.arpa → Getallen in de linkerkolom van PTR records duiden op ip-adressen ‐ Relatief t.o.v. w.y.x → Namen in de rechterkolom van PTR records zijn absoluut ∗ Nameserver verantwoordelijk voor w.in‐addr.arpa dient duidelijk de zone x.w.‐in‐addr.arpa te delegeren, enz. b. De figuur in bijlage stelt een intranet voor bestaand uit een aantal Linux computers. Alle computers hebben een IP-adres van de vorm 172.x.y.z . De getallen x en y lees je af rechts van de naam van de computer. Het getal z lees je af links van de naam van de computer. De computers staan gegroepeerd in een tabel met als header de naam van het domein waarin ze zich bevinden. De recht-hoeken die domeinen groeperen stellen dan weer een zone voor. Stippel-lijnen duiden op een domein/sub-domein relatie. De pijlen laten toe om de primaire name-server van elke forward DNS zone te achter-halen. De reverse DNS van de volgende adresruimten wordt gedelegeerd aan: ... . Geen enkele zone heeft een secundaire nameserver. Stel het configuratiebestand en de zonebestanden op van alle servers die een rol spelen bij de reverse DNS resolving van IP-adressen behorend tot de adresruimten ... en ... . Je hoeft hierbij enkel de configuratie informatie te vermelden die noodzakelijk is voor reverse DNS. Gebruik relatieve DNS namen waar mogelijk. Het gebruik van forwarders is hier niet toegelaten ! • /

Christophe Sysmans