Essay: Op 17 november 1988 werd een koppeling met het ‘internet’…

SAMENVATTING

Op 17 november 1988 werd een koppeling met het ‘internet’ ingevoerd in Nederland. Zes jaar daarvoor werd het TCP/IP model de standaard in het ARPANET. Voor iets dat zo kort bestaat heeft het voor een grote impact gezorgd in de wereld. De manier waarop informatie wordt gedeeld is niet meer weg te denken uit de samenleving. Door deze immens snelle groei hebben zich over de jaren een aantal problemen voorgedaan. Het meest bekende probleem is het opraken van de IPv4-adressen, maar dat is niet het meest belangrijke probleem. Het aantal routes die zich in de BGP-tabellen van het default free zone (DFZ) bevinden is ontzettend hard gestegen en het bestrijden van het probleem is een bijzonder lastig proces gebleken. De oorzaak hiervan is een conflict in de kern van het internet waarbij een IP-adres zowel de locatie als identiteit van een eindsysteem bepaald. Dat betekent dat wanneer een systeem verplaatst het IP-adres moet worden aangepast, of er moet een extra route worden aangemaakt. Dit zorgt voor grote vervuiling van de tabellen en om die reden wordt al jaren gezocht naar een goede oplossing. In 2006 lijkt deze gevonden te zijn in het Locator/ID Separation Protocol (LISP). Door middel van LISP worden twee IP-adressen toegekend aan elk systeem. Het ene adres bepaald de locatie en de andere de identiteit. De koppeling tussen deze twee adressen wordt opgeslagen in een database en daarmee kan de druk op de tabellen in het DFZ worden verlicht. Daarnaast biedt LISP goede alternatieven voor technieken als multihoming, IPv6 transitie, VM/IP mobility en network virtualuzation.
Het probleem van het onderzoek is het feit dat binnen Qi ict weinig tot geen informatie aanwezig is over het protocol. De interesse in het protocol komt voort uit een presentatie van een CiscoLive conferentie. Het doel van het onderzoek is dan ook om een onderzoek uit te voeren dat resulteert in rapportage en demo-opstellingen die inzicht bieden in de werking en het gebruik van LISP. Door middel van deze informatie kan Qi ict haar klanten beter adviseren over het gebruik van dit protocol.
Voor het uitvoeren van het onderzoek is gebruik gemaakt van de watervalmethode. Een simpele, flexibele en beheersbare methode waarmee experimentele protocollen als LISP perfect onderzocht kunnen worden. De eerste fase van de gekozen watervalmethode was de analysefase waar door middel van systematisch literatuuronderzoek informatie is gezocht over LISP. Op basis van deze informatie is een onderzoeksrapport geschreven dat inzicht biedt in de werking van LISP en de plaatst die het heeft in het huidige internetmodel. Op basis van dit rapport zijn in de volgende fase drie ontwerpen opgesteld met bijbehorende testplannen. Deze ontwerpen zijn in de opvolgende implementatiefase daadwerkelijk gebouwd. In de laatste fase van het onderzoek zijn de testplannen uitgevoerd en is op basis van de resultaten een adviesrapport geschreven voor Qi ict. Uit dit rapport is duidelijk geworden in hoeverre de theorie uit het onderzoeksrapport zich uit in de praktijk en uiteraard of het protocol van enige waarde is voor Qi ict.
Door middel van de bovenstaande uitvoering is een duidelijk beeld gevormd van LISP. Het is een indrukwekkende techniek met veel mogelijkheden. Naast het hoofddoel van LISP om het aantal routes in de BGP-tabellen van het DFZ te doen dalen is LISP ook een goed alternatief voor situaties waarbij multihoming, IPv6 transitie en VM/IP mobility voorkomen. Ondanks dat het een indrukwekkend protocol is, is het advies toch om LISP nog even niet te adopteren in productienetwerken die Qi ict beheert. Dit met de reden dat een onderneming niet zomaar ‘?n onderdeel van LISP kan adopteren. Wanneer bijvoorbeeld multihoming op basis van LISP wordt ingeregeld moet automatisch ook de mapping-system en proxy-service worden geadopteerd om connectie te behouden met de buitenwereld en het draagvlak van het protocol, met de nadruk op het mapping-system, is op het moment bijzonder laag. Dat geldt zeker voor Nederland. Toch is het niet alleen maar slecht nieuws. De ontwikkeling van LISP bevindt zich op het moment op een belangrijk punt. Er wordt ontzettend veel aandacht geschonken aan het protocol in de vorm van verschillende implementaties. Zo is het niet langer alleen Cisco die als netwerkfabrikant werkt aan de ontwikkeling. Toch blijft het erg lastig om in schatten of het protocol ooit wereldwijd wordt geadopteerd. Dat het protocol, of een soortgelijke oplossing, nodig is, is duidelijk. Het is echter altijd lastig om ondernemingen hiervan te overtuigen.
‘
VERKLARENDE WOORDENLIJST
Woord Betekenis

Decapsulation Data dat tijdens het encapsulationproces is bijgevoegd verwijderen.

DFZ Default Free Zone. Vrij vertaald de ‘kern’ van het internet waar alle autonomous systems met elkaar verbinden.

EID Endpoint ID. Een 32- of 128 bits IP-adres van een eindsysteem dat gebruikt wordt voor de afzender- of bestemmingsadres in de LISP-header.

EID-Prefix Een blok EID’s dat door een autoriteit wordt uitgegeven. Deze blok van EID’s wordt aan een RLOC gekoppeld in het mapping-system database.

Encapsulation Het ‘inpakken’ van verkeer en tijdens het proces het pakket voorzien van nieuwe data, zoals het bijvoegen van een LISP header.

ETR Egress tunnel router. Een router die op de grens tussen EID en RLOC omgevingen werkt en zorgt dat de encapsulation van een ITR wordt verwijderd. Tevens verantwoordelijk voor het doorsturen van verkeer naar de gezochte EID.

ISP Internet Service Provider. Een partij die connectie met het internet levert aan derde partijen.

ITR Ingress tunnel router. Een router die op de grens tussen EID en RLOC omgevingen werkt en zorgt voor de encapsulation van LISP-verkeer.

Mapping System Overkoepelende term voor de map-server, map-resolver en de mapping-system-database.

Mapping-system database Omschrijft een database techniek die gebruikt wordt voor het opzoeken van de koppeling tussen EID en RLOC.

MR Map-resolver. Component dat map-request berichten ontvangt van een ITR en deze verwerkt door bijvoorbeeld door te sturen naar een DDT-Root of Map-server

MS Map-server. Component waar een ETR zijn registraties doet. Hier worden de koppelingen tussen EID en RLOC opgeslagen

PITR Proxy ITR. Zorgt voor een koppeling tussen wel- en niet LISP omgevingen door bekende LISP routes te distribueren in het traditionele internetmodel via BGP.

PETR Proxy ETR. Een ETR die decapsulation kan toepassen op verkeer dat niet voor een LISP omgevingen bestemt is. Dit kan nodig zijn bij het overbruggen van een netwerk met een ander type IP protocol.

RLOC Routing locator. Een IPv4 of IPv6 adres van een xTR aan de zijde dat in verbinding staat met het DFZ. Tevens het resultaat van zoekopdracht in de database.

(P)xTR Router dat de functionaliteit kan hebben van een ITR, ETR, PITR of PETR

‘
SYMBOLENLIJST
Symbool Betekenis

Router
Verantwoordelijk voor het verbinden van twee computernetwerken.
Vaak ook te zien als xTR in een topologie. Een xTR is een router met LISP functionaliteit.

Switch
Verbinden van eindsystemen op laag twee.

Eindsysteem
Eindpunt in een netwerk. Kan een desktop, laptop, telefoon etc. zijn.

Server
Eindsysteem dat gebruikt wordt om informatie op te slaan, zoals databases met mapping-data.

Wolk
Netwerk waarvan de interne werking niet relevant is. Bestaat uit een tal van routers.

1. INLEIDING
Het internet is op het moment niet meer weg te denken uit de hedendaagse samenleving. Er is een miljardenindustrie gebouwd op een technologie waarmee informatie gedeeld kan worden tussen eindsystemen over de hele wereld. Deze technologie lijkt voor alle eindgebruikers goed te functioneren, maar als dieper wordt gekeken naar de werking komen problemen naar voren. Het meest bekende probleem is het opraken van IPv4-adressen dat al jaren aan de gang is , maar dit is niet het grootste probleem waar het internet mee te maken heeft. Op 12 augustus 2014 bereikte het aantal routes in de BGP-tabellen van het DFZ een totaal van 512.000 . Dit was een vooraf aangekondigde grens die veel routers niet aan zouden kunnen en door geen actie te ondernemen werd een deel van het internet die dag onbereikbaar. Het probleem was snel verholpen door het vervangen van ouder apparatuur, maar met de snelheid waarmee het aantal routes groeit is het duidelijk dat dit geen definitieve oplossing is, maar slechts een uitsteltactiek om kosten te besparen.
Gelukkig zijn naast partijen die het probleem negeren ook partijen serieus bezig met het zoeken naar een oplossing. Een veelbelovende oplossing en tevens het onderwerp van dit onderzoek is het Locator/ID Separation Protocol (LISP). LISP introduceert een model waarbij elk eindsysteem twee IP-adressen toegekend krijgt. E??n adres voor het bepalen van de identiteit en ‘?n adres voor het bepalen van de locatie. Door het maken van een scheiding tussen locatie en identiteit kan aggregatie optimaal worden ingeregeld in het DFZ, waardoor het aantal routes in de BGP-tabellen zal afnemen. Dit met betere routering en langere levensduur van apparatuur tot gevolg. Daarnaast levert LISP een goed alternatief voor zaken als multihoming, IPv6 transitie, VM/IP mobility en network virtualization.
Qi ict is ook ge??nteresseerd in de adoptie van dit protocol en wilt graag meer weten over de werking, vereisten en knelpunten van adoptie om klanten beter te kunnen adviseren. Het doel van het onderzoek is dan ook om voor 23 maart 2015 een onderzoeks- en adviesrapport te hebben geschreven met bijbehorende demo-opstelling die inzicht biedt in het gebruik van LISP. Dit afstudeerverslag beschrijft het proces dat gevolgd is voor het uitvoeren van dit onderzoek. Allereerst wordt wat achtergrondinformatie gegeven over de organisatie waarin het onderzoek plaatsvindt en de omschrijving van de opdracht. Vervolgens wordt de aanpakmethode van het onderzoek toegelicht. Hierna komt de kern van het onderzoek aan bod door alle werkzaamheden en keuzes toe te lichten met daarbij ook de analyse van de producten die zijn opgeleverd. Het verslag wordt daarna afgerond met een evaluatie van het proces, een overzicht van gebruikte literatuur en een overzicht van de bijlagen.

‘
2. ORGANISATIE
Qi ict is een bedrijf dat zich al ruim dertig jaar inzet om de beschikbaarheid en continu??teit van netwerken hoog te houden. Dit doet men bij Qi ict met een team van ruim honderd werknemers, verdeeld over drie vestigingen en met klanten die werkzaam zijn in diverse sectoren. Om het motto ‘living uptime’ te garanderen levert Qi ict al jaren verschillende netwerk-, security-, en storageoplossingen en is daarin ook erg succesvol. Inmiddels behoort Qi ict tot de top tien bedrijven die werkzaam zijn in deze sector .
Met het gegeven dat de ‘i’ in Qi staat voor innovatie is het belangrijk dat nieuwe technieken onderzocht blijven worden. Klanten verdienen het beste advies en komen daarvoor naar Qi ict met diezelfde reden. De inspiratie om nieuwe technieken te onderzoeken komt vaak vanuit de engineers van Qi ict. Zij zijn regelmatig op conferenties en evenementen van leveranciers te vinden en komen hierdoor in aanraking met nieuwe producten en technieken. Zij hebben zelf alleen niet altijd de tijd om deze nieuwe producten en technieken te onderzoeken, waardoor vaak een beroep wordt gedaan op stagiairs en afstudeerders die gedurende het hele jaar aanwezig zijn bij Qi ict. Dat geldt ook voor dit onderzoek.
Veel klanten maken gebruikt van technieken als multihoming om de beschikbaarheid van het netwerk hoog te houden en tegenwoordig wordt het werken per definitie steeds meer mobiel. Het Location/ID Separation Protocol (LISP) dat in dit onderzoek wordt onderzocht zou in theorie een verrijking zijn voor zaken als multihoming en VM/IP mobility. Het is dan ook logisch dat Qi ict hier meer vanaf wilt weten. Daarnaast is LISP als initiatief bedacht om het aantal routes in de BGP-routers van het DFZ terug te dringen en dat is een kwestie die voor Qi ict als RIPE LIR ook belangrijk is.
Op de volgende bladzijde (Figuur 2.1) is de organogram van de organisatie te zien. Zoals reeds is vermeld bestaat Qi ict op het moment uit drie vestigingen. De hoofdvestiging is in Delft en bestaat uit de afdelingen administratie, services en sales. Deze drie afdelingen bestaan uit een aantal disciplines. De discipline waar de student het onderzoek zal uitvoeren is ‘Networking & Storage ‘ LAN Backbone’. Deze afdeling houdt zich vooral bezig met de onderste lagen van het OSI-model en daar past LISP perfect tussen aangezien LISP een nieuwe indeling aangeeft voor de netwerklaag van het huidige internetmodel. Naast de hoofdvestiging zijn er nog twee vestigingen waarvan ‘?n in Veldhoven (zuid) en ‘?n in Nijkerk (noord). Deze vestigingen zijn op het moment nog niet erg groot, waardoor ze geen eigen organisatiestructuur hebben. Deze vestigingen zijn opgenomen als afdelingen in de hoofdorganogram.
Gedurende het onderzoek wordt de student begeleid door senior network engineer & CCIE Wouter Prins. Ook hij is actief werkzaam op LAN backbone. Tevens is Wouter de engineer die initieel met het voorstel kwam om LISP te onderzoeken. Hij kwam in aanraking met het protocol op een CiscoLive evenement.

FIGUUR 2.1 – ORGANOGRAM QI ICT ‘
3. OPDRACHTOMSCHRIJVING
Voorafgaand aan het onderzoek is een afstudeerplan en plan van aanpak geschreven om de kernpunten van het onderzoek vast te stellen. Daarbij zijn zaken als de probleemstelling en doelstelling vastgesteld. Met de reden dat er nog geen informatie aanwezig was binnen de organisatie is voor het schrijven van deze documenten een korte voorstudie gedaan. Deze kernpunten worden hieronder toegelicht om de lezer een beter beeld van het proces te geven. Tevens kan aan de hand van deze punten in de conclusie worden bepaald of het onderzoek succesvol is verlopen.
3.1 PROBLEEMSTELLING
Qi ict is een kennisorganisatie. Naast het verkopen en installeren van (netwerk)apparatuur is de primaire functie van de onderneming het verkopen van kennis in de vorm van ondersteuning en advies. Om dit succesvol te blijven doen moet het bedrijf op de hoogte zijn van de nieuwste technieken. Met dit in gedachte worden engineers van het bedrijf naar conferenties en presentaties van leveranciers gestuurd. Tijdens deze evenementen komen zij in aanraking met nieuwe technieken die vervolgens door het grote aantal stagiairs binnen Qi ict worden onderzocht. LISP is ook zo’n techniek. Het feit dat LISP een oplossing kan zijn voor het verlagen van het aantal routes in de routeringstabellen van het DFZ is interessant voor Qi ict als RIPE LIR. Tevens biedt LISP mogelijkheden voor technieken als multihoming die door Qi ict ook regelmatig worden ge??mplementeerd.
Het probleem van het onderzoek is dat Qi ict weinig tot niets af weet van de werking en implementatie van LISP in netwerkomgevingen en daar dus ook geen kennis over kan verkopen.
3.2 DOELSTELLING
Het doel is om voor 23 maart 2015 een onderzoek te hebben uitgevoerd dat Qi ict inzicht biedt in het gebruik en de implementatie van het LISP protocol in het bestaande internetmodel. Het onderzoek dient rapportage en een testopstelling op te leveren die als basis gaat fungeren voor het beter adviseren van klanten die ge??nteresseerd zijn in deze techniek.
3.3 RESULTAAT
Op het moment van succesvol voltooien van de opdracht beschikt Qi ict over rapportage dat inzicht biedt in het gebruik en de implementatie van LISP. In deze rapportage zal de focus vooral liggen op implementatie van LISP in bestaande netwerken en in hoeverre het bestaande protocollen kan vervangen. Vervolgens kan Qi ict deze kennis gebruiken om oplossingen te verkopen aan ge??nteresseerde klanten.
De eindproducten die worden opgeleverd aan Qi ict zijn:
– Onderzoeksrapport
– Adviesrapport
– Demo-opstelling(en)
Tussenproducten die tijdens het onderzoek worden gegenereerd zijn:
– Plan van aanpak
– Programma van eisen
– Ontwerprapport
‘
3.4 ONDERZOEKSVRAGEN
Uit de doelstelling is duidelijk geworden dat het doel van het onderzoek is om de kennis van Qi ict te vergroten met informatie over LISP. Dit doel is vrij breed en om die reden zijn twee hoofdonderzoeksvragen opgesteld om het doel te specificeren. Tevens zijn een aantal deelvragen opgesteld om het beantwoorden van de hoofdvragen beheersbaar te houden.
Hoofdvragen:
– In hoeverre is het LISP protocol een verrijking voor het bestaande internetmodel?
– Is het protocol interessant voor Qi ict en haar klanten?
Deelvragen:
1. Wat is het LISP protocol en welke problemen lost het op?
2. Hoe werkt LISP en wat is nodig om het te kunnen implementeren in een netwerk?
3. Wat is het verschil met bestaande routingprotocollen (en bestaande tunneling/overlay methoden)?
4. Op welke manier vervangt LISP andere protocollen(/tunnel mechanismen) in bestaande technieken?
5. Voor welke omgevingen is LISP een geschikt protocol?
3.5 PROJECTGRENZEN
Ondanks dat de hoofd- en deelvragen het doel van het onderzoek specifieker maken blijft het onderzoeken van LISP ontzettend breed. Aangezien voor het afstuderen slechts een periode van achttien weken staat zijn in overleg met de opdrachtgever een aantal grenzen opgesteld om het werk te beperken. De eerste drie opsommingen geven mogelijkheden aan die bij het onderzoek betrokken kunnen worden. Daaronder is aangegeven welke selectie gemaakt is.
Mogelijke protocollen die LISP zou kunnen vervangen en die in het onderzoek vergelijken zouden kunnen worden:
– BGP
– EIGRP
– IS-IS
– OSPF
– RIPv2
– MPLS
– GRE
– IPIP
Technieken die door Cisco worden aangegeven als ideaal voor LISP en welk gebruikt zouden kunnen worden als demo-opstelling en vergelijkingsmateriaal in het onderzoek:
– Multi-homing
– IPv6 Transition Support
– VM Mobility
– Network Virtualization
Mogelijke partijen om onderzoek op af te stemmen:
– Datacenters
– Enterprise
– Small Business
– ISP netwerken
– Intern netwerk Qi
De selectie van onderwerpen om grenzen op te stellen is op basis van economische redenen gemaakt. Samen met de opdrachtgever is bekeken welke onderwerpen het meest voorkomen tijdens de werkzaamheden van Qi ict en daarmee het meest interessant zijn voor de onderneming. Daarmee is ten slotte de grootste kans dat geld verdient kan worden. De selectie van protocollen, technieken en partijen is hieronder opgesomd.
Protocollen: BGP, MPLS, OSPF, IS-IS
Technieken: Multi-homing, IPv6 Transition, VM/IP Mobility
Partijen: Enterprise, ISP netwerken

‘
4. PROJECTAANPAK
Om een onderzoek uit te voeren naar een techniek waarover weinig informatie bekend is dient een goede strategie opgesteld te worden. Dat geldt ook voor het bouwen van een demo-opstelling op basis van een nieuwe (experimentele) techniek. In dit hoofdstuk worden de verschillende methoden vergeleken die bekeken zijn voor het uitvoeren van dit onderzoek. Verder wordt de gekozen methode ook uitgewerkt aan de hand van beslismomenten en fasering.
4.1 METHODIEK
Het onderzoek dat besproken wordt in dit plan van aanpak bestaat uit twee hoofdonderdelen. Allereerst dient een literatuuronderzoek uitgevoerd te worden die inzicht biedt in de werking, voor- en nadelen van LISP en ten tweede dienen verschillende demo-opstellingen ontwikkeld te worden waarmee getest kan worden of de eerder gevonden theorie ook daadwerkelijk in de praktijk zich zo uit. Om deze twee hoofdonderdelen samen te voegen en beheersbaar te houden dient een geschikte methode gevonden te worden. De volgende speerpunten zijn opgesteld om een selectie te maken uit de grote hoeveelheid bestaande methoden.
– Beheersbaarheid voor een individu. Het onderzoek wordt uitgevoerd door ‘?n afstudeerder wat betekent dat alle processen simpel en beheersbaar moeten zijn. Grote onderzoeksmethoden zoals Prince2 die normaal door complete teams worden gehanteerd om alle processen te beheersen vallen voor dit onderzoek buiten de mogelijkheden.
– Ruimte voor uitgebreid literatuur onderzoek. Het literatuuronderzoek dat van toepassing is op dit project is niet een korte fase van bronnen zoeken om uiteindelijk een product op te leveren. Het literatuuronderzoek van dit project is al een groot deel van het product. Qi ict wilt namelijk graag een onderzoeks- en adviesrapport over de werking en geschiktheid van LISP. De methode moet dus ruimte bieden voor een uitgebreid literatuuronderzoek.
– Compacte rapportage. Vanuit de Haagse Hogeschool worden al meerdere eisen gesteld aan de literatuur die verplicht opgeleverd moet worden en daarnaast heeft Qi ict alleen behoefde aan het onderzoeks- en adviesrapport. Elk document dat erbij komt is van weinig interesse voor zowel de hogeschool als het bedrijf, wat betekent dat het simpelweg extra werk is voor de student. Een methode die weinig extra documentatie genereerd is gewenst.
Met deze speerpunten in gedachte is besloten verder te kijken naar de mogelijke vormen van onderzoek. Voor het eerste gedeelte van het onderzoek waarbij informatie gezocht en ge??nventariseerd wordt zijn kwalitatief en kwantitatief onderzoek het meest bekend . Kwalitatief onderzoek richt zich vooral op de diepgang van de informatie terwijl kwantitatief onderzoek zich vooral richt op de hoeveelheid.
TABEL 4.1 – LITERATUURONDERZOEK MOGELIJKHEDEN
Kwalitatief Kwantitatief

Observatieonderzoek
– Hier wordt alleen gelet op gedragingen die interessant zijn voor het onderzoek
– Kleine groepen Surveyonderzoek
– Voor het bijhouden van opinies, meningen of kennis van grote groepen
– Informatie wordt verzameld door het uitvoeren van enqu??tes en vragenlijsten

Open Interview
– Gebruikt voor het bijhouden van belevingen en motieven in een kleine groep Secundaire analyse
– Een analyse uitvoeren op basis van eerder verzameld werk. Dit kan informatie zijn van een andere onderzoeksgroep

Literatuuronderzoek
– Algemene technieken waarbij literatuur wordt gebruikt voor het zoeken van informatie over een onderwerp Experimenteel onderzoek
– Onderzoek op basis van hypothesen en experimenten.
– Gebruikt om effecten te meten

Voor het kiezen van een methode voor het eerste gedeelte van het onderzoek is literatuuronderzoek van de kwalitatieve methode de enige optie. Dit is de enige vorm die zich puur richt op het winnen van informatie op basis van bronnen. De resterende vormen hebben betrekking op meetgegevens en marktonderzoeken en zijn hier niet toepasbaar. Een belangrijk punt dat wel vermeld moet worden is dat experimenteel onderzoek op basis van hypothesen en experimenten een goede keuze zou kunnen zijn voor het tweede gedeelte van het onderzoek, waarbij vergeleken moet worden hoe de theorie zich uit in de praktijk.
Het uitvoeren van literatuuronderzoek zelf is een redelijk eenvoudig proces en is vaak geen onderzoeksmethode op zichzelf, maar juist een onderdeel van een grotere methode. Dat idee wordt in dit onderzoek ook toegepast, wat betekent dat een methode gezocht moet worden die aan de ene kant kwalitatieve literatuuronderzoek toelaat en anderzijds ruimte houdt voor het ontwikkelen van een product met daarbij kwantitatieve onderzoek voor het advies. De verschillende vormen van methoden voor productontwikkeling zijn als volgt.
TABEL 4.2 – PRODUCTONTWIKKELING METHODEN
Iteratief Incrementeel Waterval

Iteratieve ontwikkeling bestaat uit het ontwikkelen van een voorlopige versie, vervolgens feedback vragen en dat verwerken in een nieuwe versie Incrementeel ontwikkelen omvat het uitbrengen van verschillende releases waarbij steeds meer functionaliteit wordt bijgevoegd Bij de watervalmethode verloopt het ontwikkelen in meerdere fasen, waarbij de ene fase pas mag worden aangeroepen als de voorgaande fase af is. Aan het eind van alle fasen is er een volledige product afgeleverd
Voorbeelden:
– RUP
– Spiraalmodel
– Test-Driven Development Geen concreet voorbeeld. Vaak zijn incrementele methoden ook iteratief, zoals SCRUM. Voorbeelden:
– Model van Royce
– Sashimi model
– AORTA
– SDM

Om de afweging te maken tussen de bovenstaande methoden is gekeken naar de wensen van de opdrachtgever. Die heeft geen behoefte halve producten of een voorlopige versie die steeds vernieuwd wordt. De opdrachtgever heeft behoefte aan kennis in een eenvoudig te bevatten vorm, die vervolgens aan de hand van demo-opstellingen kan worden gepresenteerd aan collega engineers en klanten. Daarbij komt ook dat incrementele en iteratieve methoden vooral interessant zijn voor software ontwikkelprojecten. Met dit in gedachte is besloten de iteratieve en incrementele methoden te laten vallen en verder te focussen op de watervalmethode.
De watervalmethode komt in een tal van verschillende vormen voor, maar de basis blijft over het algemeen hetzelfde. Als eerste vindt de analysefase plaats, waarbij eisen worden opgesteld en informatie wordt gezocht. De tweede fase is het ontwerpen van het product. Als derde komt het implementeren en daarna het testen als vierde fase. Tevens is er nog een vijfde fase waarin onderhoud plaatsvindt, maar omdat het hier niet om productienetwerken gaat, kan die fase worden laten vallen.
Een aantal van deze watervalmethoden zijn naast elkaar gezet om een vergelijking te maken:
TABEL 4.3 – WATERVALMETHODEN
Model van Royce Sashimi Model SDM

Toelichting Watervalmethode zoals het origineel is bedacht. Wanneer de ene fase is afgerond, mag worden vervolgd naar de volgende fase. De watervalmethode is hier iets veranderd. De fasen komen nu niet na elkaar maar overlappen elkaar. Door deze overlap is het mogelijk alvast voorwerk te doen en/of terug te vallen op een vorige fasen als iets niet lukt Vaak gebruikt voor projecten waarbij geautomatiseerde systemen worden ontwikkeld. Voor elke fase wordt precies vastgelegd met de klant wat er opgeleverd wordt. Doorgaan naar de volgende fase gebeurt op basis van GO’s en NO-GO’s.

Voordelen Simpel en beheersbaar. Fouten kunnen makkelijk worden herstelt.

Aan de hand van mijlpalen kan de voortgang worden gevolgd
Mogelijkheid om een vervolgfase alvast voor te bereiden, terwijl er in een andere fase wordt gewerkt.

Mogelijkheid om terug te gaan naar een oude fase om werk aan te passen Duidelijke fasering, omdat er uitgebreid is besproken wat er precies opgeleverd moet worden.

Nadelen Als aan het eind van het project eisen wijzigen is er weinig mogelijkheid om terug te gaan naar een oude fase

Door de eenvoud van de techniek is er ook geen ruimte opgenomen voor planningstechnieken en dergelijke. Dit zal zelf moeten worden beheerst. Omdat de fasen overlappen is het lastig te bepalen wanneer iets definitief af is. Extra documentatie en gesprekken om eisen op te stellen voor elke fasen kost ontzettend veel tijd. Vooral een probleem wanneer je het onderzoek zelfstandig uitvoert.

In essentie is de werking van alle watervalmethoden hetzelfde. Elke vorm heeft zijn eigen draai gegeven in de vorm van een toevoeging. Het is de vraag of die toevoeging een voordeel biedt voor het onderzoek. Aangezien het afstuderen zelfstandig gebeurd, het onderwerp door zijn experimentele aard niet eenvoudig is en de afstudeerperiode kort, is het belangrijk dat fasen direct worden afgerond en vervolging naar de volgende fase zonder twijfelen gebeurt. Er wordt verwacht dat het Sashimi-model met het overlap voor teveel twijfel zorgt of de fase wel afgerond is en omdat het afstuderen zelfstandig gebeurt is het mogelijk onoverzichtelijk om in twee verschillende fasen tegelijk te werken. SDM klinkt aantrekkelijk doordat het goede beheersing van het project levert, maar de extra documentatie en afhankelijkheden van GO/NO-GO’s van de opdrachtgever zorgt voor vertragingen die niet gebruikt kunnen worden in een strakke planning. Om deze redenen lijkt het werken met de generieke watervalmethode, het model van Royce, de beste optie. Het is simpel, beheersbaar en de mijlpalen zorgen voor een goed beeld van de voortgang voor zowel de afstudeerder en het bedrijf.
De watervalmethoden die hiervoor zijn vergeleken zijn erg flexibel en kunnen voor een tal van projecten worden gebruikt. De methode die het beste uit de test komt, het model van Royce, is om die reden ook geschikt voor dit onderzoek. Echter omdat in dit onderzoek ook een demo-opstelling wordt gebouwd dat eigenlijk ook een netwerkinfrastructuur is, is gekozen om ook een aantal infrastructuur ontwikkelmethoden te vergelijken.
De methoden die in de vergelijking zijn meegenomen zijn ASI , TOGAF en DYA . ASI is een oudere ontwikkelmethode die op de Haagse Hogeschool nog wel eens naar voren komt tijdens projecten, terwijl TOGAF en DYA methoden zijn die op het moment zeer populair zijn bij het ontwikkelen en onderhouden van netwerken. Bij het analyseren van de basiskenmerken werd al vrij snel duidelijk dat deze methoden niet geschikt waren voor dit project. Het eerste probleem is het feit dat binnen deze technieken geen ruimte is voor onderzoek. Deze methoden zijn specifiek bedacht voor ontwikkeling en onderhoud van een netwerk. Daarnaast zijn deze methoden vooral bedacht voor productienetwerken en het integreren ervan in een onderneming. Dat is iets wat tijdens dit project niet gaat gebeuren. De infrastructuur die gebouwd wordt is een demo-opstelling voor de engineers van Qi ict. Op basis van deze gegevens is besloten dat verder onderzoek niet nodig was. Het eerder gevonden model van Royce biedt de flexibiliteit die nodig is in dit project. Door ruimte te bieden voor onderzoek en productontwikkeling is dit de meest geschikte methode.
Als laatste rest zich de keuze voor de manier waarop het literatuuronderzoek gedaan wordt. Tijdens de verschillende projecten die uitgevoerd worden aan de Haagse Hogeschool wordt normaliter geen bepaalde manier van literatuuronderzoek gehanteerd. Het is vaak niet meer dan een klein onderdeel van een analyse fase. Met het feit dat literatuuronderzoek een ontzettend belangrijk deel van dit onderzoek is en om te garanderen dat relevante informatie niet overgeslagen wordt is gekozen om te werken volgens het ‘systematisch literatuur zoeken’ (SLZ). SLZ is een methode dat ontwikkeld is aan de rijksuniversiteit van Groningen . Het is een methode dat bestaat uit drie fasen; ori??ntatie en afbakening, systematisch zoeken en proces en opbrengst evalueren. De kern van deze methode baseert zich op de sneeuwballenmethode. Het is de bedoeling dat je begint met het zoeken naar betrouwbare artikelen en vervolgens daarvan de referenties gaat lezen en van die referenties ook weer de referenties. Op deze manier is de kans klein dat relevante informatie overgeslagen wordt.
‘
4.2 FASERING EN BESLUITMOMENTEN
De watervalmethode die in de vorige paragraaf is gekozen bestaat uit vijf verschillende fasen, namelijk de analyse-, ontwerp-, implementatie-, test- en onderhoudsfase. Hoewel de onderhoudsfase in dit geval geschrapt mag worden, omdat het niet om productienetwerken gaat zijn de andere fasen wel belangrijk. Verder bevatten alle fasen een bepaald moment waarbij de volgende fase gestart mag worden. Deze fasen en beslismomenten worden toegelicht in het volgende overzicht.

TABEL 4.4 – FASERING EN BESLUITMOMENTEN
Fase Werkzaamheden Besluitmomenten

Analyse:
Ori??ntatie en afbakeningen
Systematisch zoeken
Proces en opbrengst evalueren Programma van eisen opstellen
Opstellen onderzoeksvragen
Literatuur onderzoek uitvoeren
Schrijven onderzoeksrapport Wanneer er voldoende informatie is verzameld en de opdrachtgever tevreden is met de (voorlopige) antwoorden op alle vragen zal worden doorgegaan met het schrijven van een ontwerprapport en testplannen.

Ontwerp:
Ontwerprapport schrijven
Testplannen schrijven Wanneer het ontwerprapport in voldoende mate beschrijft welke testopstellingen gebouwd gaan worden en de opdrachtgever akkoord geeft mag de implementatiefase worden gestart.

Implementatie:
Opbouwen en uitwerken van de opstellingen die beschreven zijn in het ontwerprapport. In principe mag na het bouwen van de opstellingen worden gestart met het testen. Het hangt van het beschikbare apparatuur af of deze fasen na elkaar op samen worden uitgevoerd. Ter verduidelijking, als er maar genoeg apparatuur is voor ‘?n opstelling, zal deze ook gelijk moeten worden getoetst. Zo komen de implementatie- en testfase wel na elkaar, maar wordt de fasen meerdere keren uitgevoerd.

Testfase: Testen van de opstellingen
Schrijven adviesrapport n.v.t

Voor het bijhouden van de planning is een GANTT-planning gemaakt. Deze is te vinden in het plan van aanpak. ‘Externe bijlagen ‘ II’.’
5. ANALYSEFASE

De analysefase van het onderzoek is de meest belangrijke fase van het onderzoek. Hierin vind de afbakening van het onderzoek plaats, wordt literatuurstudie uitgevoerd en wordt het onderzoeksrapport geschreven. De afbakening van het onderzoek is in hoofdstuk drie reeds grotendeels beschreven en wordt om deze reden verder niet uitgebreid toegelicht. De resterende werkzaamheden van de analysefase en de opgeleverde producten zullen in dit hoofdstuk worden toegelicht.
5.1 ORI??NTATIE & AFBAKENING
De methode systematisch literatuuronderzoek (SLZ) bestaat uit drie fasen. Ori??ntatie en afbakening, systematisch zoeken en evalueren van informatie. De eerste fase van het onderzoek is voor het grootste gedeelte al uitgewerkt in hoofdstuk drie. Het enige wat ontbreekt zijn de eisen. Met de reden dat op voorhand geen informatie aanwezig was over LISP is in overleg met de begeleiders van Qi ict en de Haagse Hogeschool besloten dat eisen per fase worden opgesteld. De reden hiervoor is dat informatie uit de ene fase nodig is voor het opstellen van eisen in de opvolgende fase. Bijvoorbeeld informatie uit het onderzoeksrapport is nodig om te besluiten welke opstellingen in de ontwerpfase worden ontworpen. De eisen van de analysefase hebben betrekking op het onderzoeksrapport. Om deze eisen te kunnen opstellen is een korte voorstudie gedaan naar LISP. Daar zijn de volgende eisen uitgekomen in overleg met de opdrachtgever.
– Het rapport dient algemene informatie te bevatten over het LISP protocol. Elementen die hierin moeten voorkomen zijn als volgt:
o Globale werking van het huidige netwerkmodel met de nadruk op IP-routing en de huidige problemen met het model
o Ontstaan van LISP
o Op welke mechanismen en/of protocollen het is gebaseerd
o Welke problemen mogelijk door LISP opgelost kunnen worden
– Het rapport bevat informatie over de werking van LISP met hierin de volgende elementen:
o De werking van LISP op protocol laag.
‘ Control- en data-plane
‘ Mapping system technieken
‘ LISP encapsulation
o De minimale topologie vereisten die nodig zijn om LISP te implementeren in een netwerk
‘ LISP ‘ to ‘ LISP
‘ LISP ‘ to ‘ Non-LISP
‘ Non-LISP ‘ to – LISP
o In welke mate apparatuur en/of software nodig is om LISP te kunnen gebruiken
– Het rapport bevat informatie van LISP in vergelijking met andere routingprotocollen. Hierin minimaal te verstaan, de protocollen BGP, OSPF, IS-IS en MPLS. Verder dient in de vergelijking opgenomen te worden:
o De globale werking van het te vergelijken protocol in het huidige internet model
o Minimale topologie en apparatuur dat nodig is om het protocol te laten werken
o Toepassingen van het protocol
o Welke werkzaamheden LISP zou kunnen overnemen
– Het rapport bevat informatie over technieken die LISP mogelijk vervangt of vernieuwd. Technieken die minimaal omschreven dienen te worden zijn:
o Multi-homing
o IPv6 Transition Support
o VM/IP Mobility
– Vergelijken van deze technieken ten opzichte van huidige oplossingen dient beoordeelt te worden op basis van:
o Minimale topologie en apparatuur vereisten (voor zo ver dat relevant is)
o Voor- en nadelen
o Mogelijke problemen die verdwijnen na het inzetten van LISP
– Het rapport bevat een afweging of het LISP protocol in theorie een interessante oplossing is voor ISP en Enterprise netwerken
5.2 SYSTEMATISCH ZOEKEN
De tweede fase van systematisch literatuur zoeken is het daadwerkelijk zoeken van bronnen. Dit gebeurt aan de hand van de sneeuwballenmethode. Het idee van deze techniek is om eerst representatieve en betrouwbare bronnen te zoeken die als kern fungeren en vervolgens van die bronnen de referenties te volgen. Van de bronnen die daaruit komen worden ook weer de referenties gevolgd, waardoor de hoeveelheid informatie exponentieel groeit en de kans dat goede bronnen worden overgeslagen klein is.
Voor het uitvoeren van de sneeuwballenmethode is initieel gebruik gemaakt van Google Scholar. Google Scholar is een zoekmachine die allerlei documenten indexeert die beoordeeld zijn door derde partijen. De eerste bronnen die bij het zoeken naar voren kwamen zijn de request for comments (RFC’s) van het protocol zelf die bij het IETF zijn opgeslagen. De onderstaande opsomming geeft de gevonden resultaten weer.
TABEL 5.1 ‘ LISP RFC’S
RFC Titel

6830 The Location/ID Separation Protocol (LISP)

6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments

6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites

6833 Locator/ID Separation Protocol (LISP) Map-Server Interface

6834 Locator/ID Separation Protocol (LISP) Map-Versioning

6835 The Locator/ID Separation Protocol Internet Groper (LIG)

6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)

De RFC’s geven een zeer gedetailleerd beeld van de werking van LISP op protocolniveau wat erg gewenst is voor dit onderzoek, maar gaven weinig informatie over business cases of configuratie voorbeelden. Daarbij kwam ook dat het document de eerste keer lastig lezen was door de geringe voorkennis. Naast de RFC’s zijn nog een aantal andere bronnen die gevonden die minder specifiek waren dan de RFC’s. Deze bronnen waren wat eenvoudiger op technisch gebied en daarom beter leesbaar, maar bevatte niet de technische diepgang die nodig was voor het onderzoeksrapport. Om die reden zijn deze documenten vooral gebruikt voor het opdoen van idee??n voor bijvoorbeeld adoptietechnieken in het adviesrapport. Voorbeelden van deze documenten zijn:
TABEL 5.2 ‘ PEER REVIEWED BRONNEN
Auteur Bron

UCL Belgium Evaluating the Benefits of the Locator/Identifier Separation

TU Berlin Implementing the Locator/ID Separation Protocol: Design and Experience

Uni. Catalunya Implementing a BGP-Free ISP Core with LISP

Om wat meer technische diepgang te vinden op het niveau van de RFC’s, maar ondersteund met configuratie voorbeelden en illustraties zijn diverse referenties gevolgd. De gevonden documenten die uit dat zoekproces voort kwamen waren eigendom van verschillende partijen die werken aan de ontwikkeling van LISP. Deze documenten waren te vinden op de volgende websites:
TABEL 5.3 – LISP WEBSITES
Website Toelichting

Lisp.cisco.com Website van Cisco vrijwilligers die werken aan LISP

Lispmob.org Opensource Linux implementatie van LISP en partner van het b??ta-netwerk

Lisp4.net Offici??le site van het LISP b??ta-netwerk

Cisco.com/../locator-id-separation-protocol-lisp/ Offici??le Cisco LISP product pagina

Naast het vinden van relevante informatie heeft het volgen van referenties ook geleidt tot een Linkedin en Facebook groep die gewijd is aan LISP. Door lid te worden van beide groepen is er contact opgesteld tussen mijzelf en personen die daadwerkelijk het protocol ontwikkelen, gebruiken en ondersteunen. Een opsomming van deze vakgenoten zijn:
TABEL 5.4 – VAKGENOTEN
Persoon Bedrijf Functie

Gregg Schudel Cisco Technical Marketing Engineer

Darrel Lewis Cisco Technical Leader

Dino Farinacci Lispers.net / Cisco Ex-partner Cisco, bedenker van LISP

Sander Steffann Steffann ISP CEO

‘
5.3 BRONNEN EVALUEREN
De derde fase van het systematisch literatuuronderzoekmethode is het beoordelen van de gevonden informatie. Dit is een lastig proces gebleken. Hoewel het aantal beschikbare informatie met betrekking tot LISP beperkt is op het moment door de experimentele aard van het protocol is er wel veel informatie te vinden dat overlapt. Veel hobbyisten plaatsen voorbeelden van LISP omgevingen online en geven daarbij hun mening. In een aantal gevallen waren de voorbeelden bijna hetzelfde, maar de conclusies anders. Hierdoor was het lastig om te bepalen wat er precies met LISP bereikt kon worden. Om deze reden is gekozen om de verschillende bronnen te verdelen in vier klassen.
– Primaire bronnen. De primaire bronnen zijn afkomstig van gerenommeerde partijen zoals het IETF, Cisco en LISPMob. Dit zijn partijen die betrokken zijn (geweest) bij de ontwikkeling van het protocol en om die reden mag vanuit worden gegaan dat de geleverde informatie betrouwbaar is.
– Secundaire bronnen. De secundaire bronnen zijn afkomstig van onoffici??le partijen die werken met LISP. Voorbeelden zijn blogs of bedrijfspresentaties over LISP. Deze bronnen worden niet gebruikt bij het schrijven van het onderzoeksrapport, maar kunnen wel gebruikt worden als ondersteuning bij onder andere configuratie kwesties.
– Vakgenoten. Vakgenoten zijn logischerwijs de individuen die werkzaam zijn in het ‘LISP-veld’. Het gaat hier onder andere om mensen in het Cisco-LISP-team of mensen die werken aan het b??ta-netwerk. Deze personen zijn vaak gebruikt om informatie in te winnen over kwesties die nog niet publiek zijn gemaakt of voor het bevestigen van bevindingen.
– Configuratie bronnen. Documenten uit deze categorie zijn puur configuratievoorbeelden van onder andere Cisco en LISPMob. Deze bronnen zijn geraadpleegd tijdens de implementatiefase bij het opzetten van de opstellingen.
‘
5.4 ONDERZOEK
Op basis van de bronnen die tijdens de literatuurstudie zijn gevonden is een onderzoeksrapport geschreven. Het rapport bevat informatie over de werking van LISP en waar het protocol zich ongeveer plaatst in het huidige internetmodel. Het volledige verslag is te vinden in ‘Externe bijlagen ‘ IV’. De belangrijkste onderdelen worden hieronder uitgewerkt om een beter beeld van LISP te geven. Dat is noodzakelijk voor het begrijpen van de resterende informatie in dit verslag.
Ontstaan van LISP
Het idee voor een protocol dat later leidde tot LISP is ontstaan op het Amsterdam Routing and Addressing Workshop in 2006. Heir werd gezegd dat de schaalbaarheid van routering het grootste probleem is dat het internet op het moment heeft en moet opgelost worden. Met deze slechte schaalbaarheid van routering wordt verwezen naar de omvang van de routetabellen in het DFZ. In de onderstaande afbeelding is te zien dat het aantal routes dat op het moment aanwezig is in de tabellen van BGP-routers de 500.000 is gepasseerd (Figuur 5.1). Hierbij gaat het alleen nog maar op IPv4 routes. Normaliter bevatten de routers ook nog routes voor IPv6 en ISP specifieke locaties.

FIGUUR 5.1 – BGP TABELGROOTTE 1994 TOT NU
Het feit dat het aantal routes ontzettend hard groeit is de wijten aan verschillende factoren. De kern van het probleem is dat het aggregeren, het samenvatten van routes achter een minder specifiek adres, niet gemakkelijk is. De bedenkers van LISP zijn van mening dat het slecht aggregeren van routes te wijten is aan een fundamenteel probleem in de kern van het IP-adres . Het IP-adres zoals het veertig jaar geleden is bedacht bepaald de locatie en identiteit van een eindsysteem. Het fundamentele probleem tussen locatie en identiteit is dat je als identiteit het liefst onafhankelijk bent van een topologie, zodat je IP-adres altijd hetzelfde blijft en als locatie juist wel afhankelijk wilt zijn van een topologie, zodat routes optimaal geaggregeerd kunnen worden. Dit fundamentele probleem kan door LISP worden opgelost door de twee verantwoordelijkheden van locatie en identiteit te scheiden over twee adressen en de koppeling tussen de twee op te slaan in een database om de druk op de BGP-tabellen te verlichten.
Idee achter LISP
Zoals hiervoor is vermeld werkt LISP op basis van twee adressen. Het eerste adres is de endpoint-identifier (EID). Dit is het IP-adres van een eindsysteem dat nooit veranderd en bepaald daarmee de identiteit. Het tweede adres is de routing-locator (RLOC). Dit RLOC-adres is het IP-adres van de router dat zich voor het eindsysteem bevindt en kan veranderen wanneer de locatie van het eindsysteem veranderd.
In de onderstaande afbeelding (Figuur 5.2) komt het EID van host A overeen met het IP-adres 192.168.1.2 en het RLOC adres van host A komt overeen met 80.80.80.1, omdat host A zich op het moment van zoeken achter die router bevindt. Stel dat host A zich zou verplaatsen naar het netwerk van host B, dan zou de EID van host A nog steeds 192.168.1.2 zijn, maar de RLOC zou veranderen naar 90.90.90.1. In het mapping system wordt de koppeling tussen EID en RLOC, de EID-to-RLOC mapping, bijgehouden.

FIGUUR 5.2 – LISP TOPOLOGIE
LISP werkt op basis van een client-server model. Een eindsysteem kan een verzoek doen om een koppeling uit een hi??rarchisch server model door het mapping-system te gebruiken voor het zoeken van de juiste RLOC bij een EID. Dit model is ge??nspireerd door de werking van het Domain Name System (DNS). LISP zorgt zelf nog niet voor het volledig versturen van een pakket van A naar B. Het LISP protocol zorgt voor de juiste eindbestemming en is afhankelijk van onderliggende routeringsprotocollen om het pakket van A naar B te krijgen.
Netwerkcomponenten
Om verkeer via LISP te kunnen versturen zijn er twee lagen aanwezig in het LISP-model . De control-plane en het data-plane. De control-plane zorgt voor het bijhouden van de informatie die nodig is om verkeer via LISP te versturen, zoals de informatie in de database van het mapping-system. De data-plane is verantwoordelijk voor het daadwerkelijk versturen van het verkeer en zorgt voor zaken als encapsulation. Elke laag heeft zijn eigen netwerkcomponenten.
Voor het versturen van verkeer heeft de data-plane vier mogelijke componenten:
– Ingress tunnel router (ITR). De ITR bevindt zich op de grens van de LISP omgeving tussen de EID en RLOC adressen. De verantwoordelijkheid van de ITR is het ontvangen van IP-pakketten van een host en daarna te bepalen of deze door middel van LISP verstuurd moet worden, of via het traditionele internetmodel. Dit doet de ITR op basis van een map-request bericht die gestuurd wordt naar het mapping-system.
– Egress tunnel router (ETR). De ETR bevindt zich net als de ITR op de grens van een LISP omgeving tussen de EID en RLOC adressen. De verantwoordelijkheid van de ETR bestaat uit twee onderdelen. Allereerst het registreren van de EID’s uit het lokale netwerk achter zich bij de mapping-server en als tweede het analyseren of de opgevraagde EID adres uit de map-request inderdaad in zijn achterliggende EID-omgeving actief is om dit vervolgens te melden aan ITR.
– Proxy ingress tunnel router (PITR). Is net als de ITR verantwoordelijk voor het verzenden van een verzoek om een EID-to-RLOC koppeling om verkeer te kunnen sturen, maar bevindt zich op de grens tussen wel- en niet-LISP omgevingen, om wel-LISP omgevingen bereikbaar te houden voor het traditionele internet. Om dit te realiseren distribueert een PITR bekende LISP-adressen door middel van BGP in tabellen van het traditionele internet.
– Proxy egress tunnel router (PETR). De PETR wordt net als de PITR gebruikt als scheiding tussen wel- en niet-LISP omgevingen, maar waar de PITR verkeer regelt van niet- naar wel-LISP omgevingen, doet de PETR het andersom.
De bovenstaande netwerkcomponenten worden in topologi??n vaak vermeld als xTR of PxTR, omdat de functionaliteit van beide componenten vaak wordt geregeld door ‘?n router. Tevens moet vermeld worden dat de PxTR’s officieel alleen nodig zijn tijdens de transitiefase naar LISP. Wanneer het totale internetmodel op basis van LISP fungeert zijn deze niet langer nodig.
Voor het bijhouden van informatie om verkeer via LISP te kunnen sturen heeft de controle plane twee netwerkcomponenten:
– Map-Resolver (MR). De MR is een netwerkcomponent dat verzoeken ontvangt van de ITR, waarbij de ITR wil weten of er bij een opgevraagd EID een RLOC bekend is. Deze verzoeken worden door de MR doorgestuurd naar de map-server via het mapping-system. Tevens is de MR verantwoordelijk voor het versturen van negatieve mapping-berichten, wanneer de EID niet bekend is en het verkeer zonder LISP encapsulation via de default gateway het traditionele internet op moet gaan.
– Map-Server (MS). De MS is een netwerkcomponent die registraties ontvangt van een ETR en deze verwerkt in de mapping-system-database. De MS stuurt ook map-requests door naar de verantwoordelijke ETR wanneer deze bekend is in zijn database.
Daarnaast heeft de control-plane ook nog een drietal databases die gebruikt worden voor het opslaan van de informatie:
– Map-Cache (MC). De MC is een tijdelijk geheugen op de ITR die routes opslaat die op basis van map-replies van de ETR zijn aangemaakt. Deze routes worden aan de hand van een time-to-live (TTL) voor een bepaalde tijd vastgehouden.
– Site Mapping-Database (MD). De MD is een lokale database op de ETR die alle EID-to-RLOC koppelingen bijhoudt voor een lokale LISP-omgeving.
– Mapping-System-Database (MSD). De MSD wordt omschreven als een database, maar is een techniek voor het distribueren van routes tussen de MR en MS. Op het moment wordt in het LISP b??ta-netwerk gebruik gemaakt van hi??rarchisch boomstructuur waarbij EID-to-RLOC koppelingen worden gedelegeerd. Dit model heet het LISP Delegated Database Tree (LISP-DDT).
Om informatie uit te wisselen tussen de control en data-plane zijn de volgende berichten nodig:
– Map-Register. Dit bericht wordt door de ETR naar de MS gestuurd met informatie over de EID’s die zich in zijn lokale LISP-omgeving bevinden. De MS koppelt vervolgens deze EID-prefixes aan de gewenste RLOC(‘s), zodat bij een verzoek van de ITR de juiste eindbestemming wordt gekozen.
– Map-Request. Dit bericht wordt door de ITR naar de MR gestuurd om te controleren of een IP-pakket in aanmerking komt voor LISP encapsulation. Het bericht is een verzoek om een koppeling tussen EID en RLOC. Het bericht wordt ook gebruikt voor het controleren of het doel nog te bereiken is.
– Map-Reply. Dit bericht wordt door de ETR teruggestuurd naar de ITR wanneer de EID van het eerder genoemde map-request is bevestigd in zijn lokale omgeving. De ITR gebruikt dit bericht voor het toevoegen van de router aan de mapping-cache op de ITR.
– Map-Notify. Dit bericht wordt door de MS naar de ETR gestuurd om te bevestigen dat registratie van een koppeling succesvol heeft plaatsgevonden. Dit is een optioneel bericht en wordt alleen gestuurd wanneer een bepaalde flag is gezet in de header.
De berichten worden door het mapping-system en routers verstuurd via UDP poort 4341 en 4342. De reden dat gekozen is voor UDP komt doordat oudere legacy routers de berichten dan wel accepteren en doorsturen, ondanks dat ze LISP niet begrijpen.
Globale werking van LISP
Op basis van de componenten en berichten die op de vorige bladzijden zijn besproken wordt hier de werking van LISP dieper toegelicht.

FIGUUR 5.3 – GLOBALE TOPOLOGIE LISP
De bovenstaande afbeelding (Figuur 5.3) is een globale uitwerking van de manier waarop LISP is ge??mplementeerd in het huidige internetmodel. Er zal gebruik worden gemaakt van deze tekening in combinatie met eerder gegeven informatie over LISP-componenten en berichten om de werking stapsgewijs toe te lichten.
1. De eerste stap start net als elke andere situatie. Een eindsysteem uit SITE-A wilt een connectie maken met een ander eindsysteem zoals een webserver. Stel dat in dit geval een eindsysteem uit SITE-A een DNS-lookup doet voor het IP-adres van een eindsysteem uit SITE-B. De DNS-Server retourneert het IP-adres 20.20.20.2 en op basis daarvan maakt het eindsysteem uit SITE-A een IP-pakket aan en stuurt deze door naar zijn default gateway, xTR1.
2. In stap twee begint het LISP proces. Router xTR1 ontvangt het pakket en gaat nu beoordelen of het in aanmerking komt voor LISP encapsulation. Als dat het geval is wordt een map-request aangemaakt een gestuurd naar de MR van de mapping-system.
3. Op basis van cache-informatie van de MR of informatie van een MS wordt bepaald dat SITE-B inderdaad een LISP-omgeving is, waarop de map-request wordt doorgestuurd naar xTR2. De informatie die hiervoor gebruikt wordt kan opgevraagd worden op LISP-componenten. Als er bij het mapping-system informatie opgevraagd zou worden zoals in stap drie wordt het volgende getoond:

FIGUUR 5.4 – VOORBEELD INFORMATIE MS
In de bovenstaande afbeelding (Figuur 5.4) is te zien dat SITE-A zich heeft geregistreerd achter het RLOC-adres 1.1.1.1 en SITE-B achter 2.2.2.2. Dit komt overeen met de topologie Figuur 5.3.
4. Router xTR2 ontvangt de map-request en controleert of het IP-adres van het gezochte eindsysteem inderdaad in zijn lokale omgeving bevindt. Wanneer dit het geval is maakt xTR2 een map-reply aan en stuurt deze naar de xTR1.
5. Door middel van de informatie uit de map-reply wordt een route aangemaakt in de mapping-cache van xTR1. Als deze informatie geraadpleegd wordt krijg je de onderstaande informatie te zien (Figuur 5.5). Deze informatie wordt gebruikt in het encapsulationproces om verkeer te kunnen versturen tussen de twee eindsystemen. In dit geval wordt al het verkeer richting EID’s in 20.20.20.0/24 voorzien van het RLOC-adres 2.2.2.2.

FIGUUR 5.5 – OPGESLAGEN MAPPING INFORMATIE
6. Nu er informatie bekend is over de identiteit en locatie van het eindsysteem kan door middel van encapsulation een pakket worden gemaakt dat gebruikt wordt om de connectie op te stellen. Hoe deze pakketten eruit zien wordt onder de kop ‘LISP encapsulation’ verder toegelicht.
Het bovenstaande stappenplan wordt uitgevoerd wanneer verkeer tussen twee LISP omgevingen wordt verstuurd. Wanneer verkeer wordt verstuurd van een wel-LISP naar een niet-LISP omgeving wordt hetzelfde stappenplan uitgevoerd. Echter wanneer bij stap drie duidelijk wordt dat geen informatie bekend is over de eindbestemming wordt bepaald dat het geen LISP omgeving is en wordt de informatie zonder encapsulation via de default gateway verstuurd. Het is ook mogelijk dat het verkeer met encapsulation wordt gestuurd naar een PETR om vervolgens door te gaan naar een niet-LISP eindbestemming zonder encapsulation. Dit hangt van de configuratie af. Deze techniek wordt bijvoorbeeld gebruikt om een ander IP-versie-netwerk te overbruggen.
De laatste mogelijkheid is dat een niet-LISP eindsysteem verkeer wilt sturen naar een wel-LISP eindsysteem. Hiervoor wordt een PITR gebruikt. De PITR distribueert bekende LISP EID-prefixes via BGP in het traditionele internetmodel, zodat alle eindsystemen in LISP omgevingen toch bereikbaar blijven. Wanneer het verkeer een PITR bereikt gaat het proces ongeveer hetzelfde. De juiste informatie wordt opgezocht in het mapping-system en wanneer deze bekend is kan een connectie worden opgezet. Het verschil is dat hiertussen geen encapsulation aanwezig is.
N.B. De bovenstaande informatie geeft een goed beeld van de werking van LISP. Het geeft echter niet het volledige proces in detail weer. Voor het volledige proces wordt verwezen naar ‘Externe bijlagen ‘ IV’.
LISP encapsulation
In de voorgaande paragraven is meerdere malen aangehaald dat LISP werkt op basis van twee adressen, EID en RLOC. Tevens is vermeld dat LISP werkt op basis van encapsulation. Om de link hiertussen te begrijpen is de onderstaande afbeelding (Figuur 5.6) nodig. De afbeelding geeft het pakket weer dat tussen LISP netwerkcomponenten wordt verstuurd. Het onderste deel van de afbeelding, de inner header, is het standaard IP-pakket zoals dat wordt gemaakt wanneer het ene eindsysteem een connectie wil maken met de ander. De bovenste helft, de outer header, bevat informatie over de RLOC’s.

FIGUUR 5.6 – LISP PACKET
Als het eerder getoonde netwerk wordt gebruikt (Figuur 5.3) en een eindsysteem uit SITE-A een connectie zou willen maken met een eindsysteem uit SITE-B zou het pakket er zo uit zien.
– Source EID: 10.10.10.2
– Destination EID: 20.20.20.2
– Source Routing Locator: 1.1.1.1
– Destination Routing Locator: 2.2.2.2
Wanneer het DFZ, de RLOC omgeving, overbrugt wordt, wordt gebruikt gemakt van de RLOC adressen om te routeren. Wanneer het eindstation, de xTR van de gezochte omgeving, wordt gevonden en decapsulation plaatsvind, blijft de inner header over om op basis van de EID adressen de EID omgeving te kunnen doorkruisen.

Mogelijkheden met LISP
Naast het hoofddoel van LISP om de hoeveelheid routes in het DFZ terug te dringen zijn er nog een viertal technieken mogelijk met LISP. IPv6 transitie, multihoming, VM/IP mobility en network virtualization. De eerste drie technieken zijn in het onderzoeksrapport onderzocht en vergeleken met bestaande technieken.
1. IPv6 transitie is een techniek dat standaard is ge??mplementeerd in LISP door middel van encapsulation. In de vorige paragraaf is te zien dat er in de inner- en outer header ruimte is voor EID- en RLOC-adressen. Deze kunnen gevuld worden met zowel IPv4- als IPv6-adressen. Hierdoor kan LISP gebruikt worden voor alle vormen van transitie. IPv4-over-IPv4, IPv4-over-IPv6, IPv6-over-IPv4 en IPv6-over-IPv6. Het is hiermee ook een goed alternatief voor bestaande tunnel-, translatie en dualstacktechnieken.
2. Multihoming is mogelijk door de koppeling tussen EID’s en RLOC’s die bepaald wordt door een ETR. Wanneer een map-request wordt ontvangen door een ETR kan die reageren met een map-reply waarin meerder RLOC’s aanwezig zijn. Aan deze adressen kan ook een prioriteit en verdeling worden toegekend om bijvoorbeeld load-balancing in te regelen. In de onderstaande afbeelding (Figuur 5.7) is het resultaat zichtbaar van zo’n map-reply. Het eindsysteem 192.168.1.2 is bereikbaar over zowel 10.10.10.2 als 11.11.11.2 met een verdeling van 50/50. Deze techniek is een goed alternatief voor multihoming met BGP en NAT.

FIGUUR 5.7 – VOORBEELD MEERDERE RLOC VOOR MULTIHOMING
3. VM/IP mobility laat de ware kracht van LISP zien wanneer locatie en identiteit gescheiden worden. Het is mogelijk om een eindsysteem van het ene subnet te verplaatsen naar een ander zonder het IP-adres te wijzigen en toch bereikbaar te blijven voor het publiek. Deze techniek baseert zich op het maken van een specifieke /32 route in het mapping-system wanneer een verplaatsing wordt gedetecteerd. Tevens moeten de xTR’s waar tussen de verplaatsing gebeurd wel verwachten dat een verplaatsing mogelijk is door ‘?n interface op de router te configureren met het zogeheten ‘lisp mobility’. Deze techniek kan bestaande mogelijkheden zoals Route Health Injection (RHI), DSN based redirection en mobile IPv4/6 in bepaalde situaties vervangen.
Plaats in het internetmodel
Naast het uitwerken van de werking van LISP in verschillende situaties en de verschillende toepassingen waar LISP voor gebruikt kan worden is in het onderzoeksrapport ook geprobeerd te bepalen waar het LISP protocol ongeveer ligt in het huidige internetmodel. Hiervoor is LISP vergeleken met andere bekende protocollen.
De protocollen die vergeleken zijn met LISP waren BGP, MPLS, OSPF en IS-IS. OSPF en IS-IS zijn echte routeringsprotocollen zonder verdere speciale toepassingen en hebben geen overlap met LISP. LISP heeft protocollen als OSPF en IS-IS nodig om verkeer van A naar B te krijgen. Binnen BGP en MPLS was er wel overlap zichtbaar. Niet zozeer in de werking van de protocollen, maar wel in toepassing. Zo is het bijvoorbeeld mogelijk voor LISP om BGP te vervangen in een multihomed omgeving en MPLS te vervangen in een BGP+MPLS-VPN omgeving.
Voorafgaand aan het onderzoek werd gedacht dat LISP een routeringsprotocol was, omdat het in bepaalde gevallen routeringsprotocollen als BGP kon vervangen. Dit is een misconceptie geweest. Het feit dat LISP hulp biedt bij het routeren met informatie uit het zijn mapping-system, maakt het geen routeringsprotocol. LISP is nog steeds afhankelijk van onderliggen protocollen om zijn berichten van A naar B te krijgen. Het feit dat LISP gebruikt maakt van encapsulation oppert het idee dat LISP een tunnelprotocol is, maar een conclusie als deze zou het protocol te kort doen. Uiteindelijk is de conclusie getrokken dat LISP net als MPLS eigenlijk geen protocol is, maar een architectuur. Het is een techniek dat in veel verschillende situaties gebruikt kan worden en brengt daarmee een verrijking aan het internet.
‘
6. ONTWERPFASE

In de ontwerpfase worden drie ontwerpen toegelicht die zijn bedacht op basis van informatie uit de analysefase. Tevens wordt het proces toegelicht die voor het ontwerpen is gevolgd.
6.1 MIDDELEN
LISP is op het moment te gebruiken in bepaalde versies van het Cisco besturingssysteem en als opensource variant dat ontwikkeld wordt door LISPMob . Om een keuze te maken tussen deze twee mogelijkheden is gekeken naar de toekomst van LISP. Stel dat Qi ict ooit LISP zou implementeren bij een klant, dan is het vanuit de contracten van Qi ict verplicht om daar service over te leveren. Dat betekent dat wanneer Qi ict een probleem (met LISP) niet kan oplossen de ontwikkelaar/fabrikant moet worden geraadpleegd voor ondersteuning. Hiervoor moeten afspraken gemaakt kunnen worden. Als je dan als bedrijf moet kiezen tussen een erkende fabrikant van en een opensource groep dat afhankelijk is van vrijwilligers is Cisco de logische keus.
Naast de keuze tussen Cisco en LISPMob is ook nog nagedacht over het bouwen van een virtuele opstelling of een hardware opstelling. Uiteindelijk was het nodig om de twee te combineren, omdat er voor beide gevallen niet genoeg middelen zijn om ‘?n soort volledig uit te voeren. Zo heeft de ESX-server niet genoeg capaciteit om een compleet LISP-lab te draaien zonder dat de resterende werknemers last hebben en heeft de reservevoorraad van Qi ict op het moment niet genoeg componenten liggen die LISP ondersteunen i.v.m. licenties.
6.2 EISEN
Met de beschikbare middelen in gedachte in combinatie met het doel om inzicht te bieden in de werking en implementatie van LISP zijn de volgende eisen opgesteld.
– Het ontwerprapport bevat informatie over de opstellingen die gebouwd worden om LISP in de praktijk te demonstreren en de manier waarop deze worden getest. Hierin staan drie opstellingen beschreven.
o Een opstelling op basis van een LISP-ISP, in dit geval het b??ta-netwerk, om te bepalen welke gevolgen het adopteren van LISP heeft op de bereikbaarheid van een omgeving.
o Een ‘standalone’ omgeving waarin de technieken IPv6 transitie, multihoming en VM/IP mobility werken en alle netwerkelementen van een LISP omgeving aanwezig zijn (xTR, PxTR, MS, MR). Dit lab is bedoeld om technieken te demonsteren en meten.
o Een veelvoorkomend topologie van een Qi ict klantnetwerk dat gecombineerd is met LISP functionaliteit om te bepalen waar mogelijke breek- en knelpunten zitten wanneer LISP wordt geadopteerd.
– Voor alle drie de opstellingen dienen de volgende elementen beschreven te worden:
o Het doel van de opstelling
o De topologie van de opstelling, zonder specifieke gegevens zoals IP-adressen.
o De benodigde hard- en software van de opstelling
o Het testplan van de opstelling
6.3 ONTWERPEN
In dit hoofdstuk worden de drie ontwerpen behandeld die ontworpen zijn om de werking van LISP te demonstreren. Van de ontwerpen worden alleen de globale elementen getoond, omdat een deel van de informatie afhankelijk is van derde partijen.
Opstelling ‘?n

FIGUUR 6.1 ‘ GLOBALE TOPOLOGIE OPSTELLING ‘?N
De bovenstaande opstelling (Figuur 6.1) geeft de topologie van opstelling ‘?n weer waar een intern (lab-)netwerk van Qi ict wordt verbonden met een LISP-ISP. In dit geval het b??ta-netwerk. Er zijn geen IP-adressen zichtbaar in het netwerk, omdat die gegevens verstrekt moeten worden door de beheerders van het b??ta-netwerk.
Deze opstelling is bedacht om inzicht te krijgen in de verschillende obstakels die komen kijken bij het adopteren van LISP en in hoeverre het de bereikbaarheid van een netwerk schaadt. Het idee om deze opstelling te bouwen komt voort uit de LISP-ISP’s die op het moment actief zijn op de wereld. Stel dat je verbonden wordt met een LISP-ISP, dan is het belangrijk om te weten wat voor invloed dat heeft op het netwerk. Met de reden dat een actieve LISP-ISP geld kost is er gekeken naar alternatieven. Een goed alternatief was het LISP b??ta-netwerk dat op het moment actief wordt beheert door vrijwilligers van Cisco en LISPMob. Het b??ta-netwerk voorziet het internet van een publieke mapping-system om te verbinden met andere LISP omgevingen en distribueert bekende LISP adressen door middel van BGP in het DFZ, zodat ook niet-LISP omgevingen bereikbaar blijven. Het b??ta-netwerk levert hiermee dezelfde functionaliteit als een LISP-ISP. Het enige verschil is dat het apparatuur van het b??ta-netwerk uit donaties bestaat en om die reden vaak wat ouder is, waardoor het netwerk wat minder snel is dan die van een ISP. Voor het verbinden met het b??ta-netwerk was slecht ‘?n netwerkcomponent nodig dat over LISP-functionaliteit beschikt en ‘?n publiek IP-adres.
Opstelling twee
De tweede opstelling (Figuur 6.2) is een standalone omgevingen waarmee de globale werking van LISP gedemonstreerd en geanalyseerd kan worden naast het gebruikt van diverse technieken. In dit lab komen multihoming, IPv6 transitie en VM/IP mobility aan bod.

FIGUUR 6.2 – GLOBALE TOPOLOGIE OPSTELLING TWEE
De bovenstaande topologie geeft de tweede opstelling weer. De drie ‘Interne’ netwerken, SITE-A, B en C worden voorzien van priv?? IP-adressen volgens RFC1918 om het gevoel van een intern netwerk te simuleren. De resterende IP-adressen zijn niet weergeven, omdat deze zowel IPv4 als IPv6 kunnen zijn. De opstelling is geen productienetwerk en wordt ontwikkeld in een afgesloten testomgeving, waardoor een willekeurige adressen gekozen kunnen worden.
De tweede opstelling wordt gebruikt om LISP technieken te demonsteren in een op zichzelf staande omgeving. De reden dat er voor een op zichzelf staande omgeving wordt gekozen komt voort uit de wens om ook verkeer te kunnen inspecteren en te kunnen begrijpen hoe LISP werkt. Als de verschillende technieken aan de hand van het b??ta-netwerk zouden worden gedemonstreerd wordt het bijzonder lastig om componenten zoals het mapping-system te inspecteren, omdat deze zich ergens op het internet bevinden en toegang niet mogelijk is.
Om de opstelling te kunnen bouwen zijn vier componenten nodig die LISP ondersteunen. Door middel van deze vier componenten kunnen twee omgevingen die op basis van LISP werken (SITE-A en SITE-B), ‘?n niet-LISP omgeving (SITE-C) en een lokale mapping-system worden opgezet. Tevens is er gekozen om alle componenten aan elkaar te verbinden met een Check Point firewall die het DFZ simuleert. De reden hiervoor is de uitgebreide samenwerking tussen Check Point en Qi ict. Door middel van het plaatsen van een Check Point firewall kan ook bekeken worden hoe Check Point apparatuur reageert op experimentele protocollen als LISP.
‘
Opstelling drie
De derde opstelling (Figure 6.3) is vergelijkbaar met opstelling twee. De enige verandering is het toepassen van een extra firewall voor xTR1 van SITE-A, om te demonsteren hoeveel invloed inspectie en NAT heeft op de werking van LISP. Deze opstelling is representatief voor netwerken die vaak voorkomen bij klanten van Qi ict. Let wel, de firewall die toegevoegd is, is niet LISP-ware.

FIGUUR 6.3 – GLOBALE TOPOLOGIE OPSTELLING DRIE
De derde opstelling is het meest representatief voor Qi ict en is later pas toegevoegd aan het ontwerprapport. De tweede opstelling gaf een goed beeld van de werking van LISP en de knelpunten in een netwerk, maar het was niet erg representatief voor Qi ict, omdat er weinig klantnetwerken voorkomen die er uit zien zoals opstelling twee. Om die reden is gekozen om een derde opstelling te bouwen die door middel van firewallinspectie en NAT een beter beeld geeft van een netwerk dat bij klanten van Qi ict voorkomt. Door de meetresultaten van deze opstelling te vergelijken met die van opstelling twee kan bepaald worden hoeveel van de LISP functionaliteit overblijft voor klanten van Qi ict in hun bestaande netwerken.
Normaliter is het gebruikelijk om in een ontwerprapport diverse mogelijkheden te bespreken voordat een definitief besluit wordt genomen over de opstellingen die gebouwd gaan worden. Zoals te zien is in het ontwerprapport is dat hier niet uitgebreid gebeurd. De reden hiervoor is dat een alternatief netwerk niet altijd mogelijk is en een alternatief netwerk eigenlijk niet uitmaakt. Bij opstelling ‘?n ben je afhankelijk van informatie van externe partijen, waardoor er weinig speling is. Daarnaast is de werking van het interne netwerk niet relevant voor de werking van LISP. Verkeer komt uiteindelijk in de vorm van een IP-pakket aan bij een xTR en of daar nu ‘?n of tien stappen voor nodig zijn is niet relevant. Dat geldt ook voor het DFZ in de netwerken. In dit geval wordt gebruikt gemaakt van ‘?n tussenliggend netwerkcomponent, zodat de netwerken niet direct verbonden zijn, maar of het nu ‘?n component is of honderd maakt voor de simulatie van het DFZ niet uit.
‘
6.4 TESTPLANNEN
Onder de eisen van de ontwerpfase valt ook het schrijven van een aantal testplannen die gebruikt gaan worden om de opstellingen te toetsen. Het format dat hiervoor gebruikt wordt is ge??nspireerd door het ASL-BISL foundation . De keuze hiervoor heeft geen specifieke reden. Het is slechts een methode die eerder gebruikt is bij verschillende projecten op de Haagse Hogeschool en dat is altijd goed bevallen. Het vormt een goed leidraad voor het testen en het opslaan van resultaten. Kort samengevat bevat een testplan gebaseerd op ASL-BISL de volgende elementen:
– Het doel van de opstelling en testen
– De benodigdheden voor het bouwen van de opstelling
– Een toelichting van de testomgeving
– De testen die uitgevoerd gaan worden (en hoe)
De testplannen die uitgevoerd gaan worden zijn in de volgende drie tabellen uitgewerkt.

TABEL 6.1 – TESTPLAN OPSTELLING ‘?N
LISP b??ta-netwerk

Doel Demonstratie van het b??ta-netwerk. Bepalen in hoeverre de bereikbaarheid van het interne netwerk is na het adopteren van LISP

Toelichting Als een onderneming gebruik zou willen maken van de functionaliteiten van LISP is gebruik maken van een LISP-ISP veruit de meest eenvoudige optie. Door middel van deze opstelling kan bepaald worden hoeveel configuratie nodig is voor het gebruik maken van LISP en welke voor- en nadelen er bij komen kijken.

Testomgeving De topologie van de testomgeving is te vinden op pagina twee van het ontwerprapport. De opstelling omvat een zelf geconfigureerde xTR dat in verbinding staat met het LISP b??ta-netwerk.

Benodigdheden – Publiek IP-adres
– Component met LISP functionaliteit
– Eindsysteem

Testen Vanuit de EID-omgeving:
– Ping non-LISP IPv4-omgeving
– Ping LISP IPv4-omgeving
– Ping non-LISP IPv6-omgeving
– Ping LISP IPv6-omgeving
Vanaf een machine in het DFZ:
– Ping machine in EID-omgeving over IPv4
– Ping machine in EID-omgeving over IPv6
Op de machine in de LISP omgeving:
– Doe een IPv6 ready test: http://www.test-ipv6.com

‘

TABEL 6.2 – TESTPLAN OPSTELLING TWEE
Standalone Netwerk

Doel Demonstratie van LISP functionaliteiten.

Toelichting De drie hoofdfunctionaliteiten die LISP heeft naast het terugdringen van onnodige routers in het DFZ zijn multihoming, IPv6 transitie en VM mobility. Deze technieken zijn ook te demonstreren met het b??ta-netwerk, maar het is dan moeilijker om data te verzamelen in onderdelen die zelf niet beheerd worden. Door middel van een standalone netwerk kan op elk punt door middel van programma’s als Wireshark data worden verzameld over de werking.

Benodigdheden – Drie eindsystemen
– Vier componenten met LISP functionaliteit
– Twee switches
– Check Point firewall

Testomgeving De topologie van de testomgeving is te vinden op pagina vier van het ontwerprapport. De opstelling omvat een volledige geconfigureerd LISP omgeving waarin alle mogelijk LISP componenten aan bod komen (xTR, PxTR, MS, MR).

Testen Multihoming (IPv4/IPv6)
– Verstuur een ping naar de overzijde met afzenderadres link ‘?n.
– Verstuur een ping naar de overzijde met afzenderadres link twee.
– Ontvang een ping van de overzijde over link ‘?n.
– Ontvang een ping van de overzijde over link twee.
– Ping overzijde constant en verwijder de actieve verbinding. Meet de tijd van connectieherstel, als deze aanwezig is.
– Start een ftp-sessie van het ene eindsysteem naar de ander en verwijder actieve verbinding. Meet de tijd van herstel, als deze aanwezig is.
VM/IP Mobility (IPv4/IPv6)
– Verplaats het ene eindsysteem naar het netwerk aan de overzijde. Meet hoe lang het duurt voordat de mapping-server op de hoogte is van de verandering.
– Hetzelfde als bovenstaand, maar ook met een ping lopend om connectieherstel te meten.
– Ping het verplaatste systeem vanaf een eindsysteem uit beide LISP omgevingen en de niet-LISP omgeving.
– Start een FTP sessie voor het verplaatsen en controleer of de sessie wordt voortgezet na het verplaatsen. Meet de hersteltijd.
IPv6 Transitie
– De bovenstaande testen van multihoming en VM/IP mobility uitvoeren met het ‘internet’ als volledig IPv4 en IPv6 om de overbrugging van een ander netwerk te testen. Dit is minder belangrijk, omdat het in de vorige opstelling vrij veel aan bod komt.

‘
TABEL 6.3 – TESTPLAN OPSTELLING TWEE
Klantnetwerk

Doel Demonstratie van LISP functionaliteiten in een standaard QI ict klantnetwerk

Toelichting Hoewel de technieken in opstelling twee gedemonstreerd zijn, ging het hier wel om een ideale opstelling. Deze opstelling komt normaliter niet voor bij klanten van Qi ict. Het toevoegen van een firewall die eindsystemen verschuilt achter zijn publieke IP-adres is voor Qi ict wel een relevante omgeving.

Benodigdheden – Drie eindsystemen
– Vier componenten met LISP functionaliteit
– Twee switches
– Twee Check Point firewalls

Testomgeving De topologie van de testomgeving is te vinden op pagina zes van het ontwerprapport. De opstelling omvat een volledige geconfigureerd LISP omgeving waarin alle mogelijk LISP componenten aan bod komen (xTR, PxTR, MS, MR), met daarbij ook een Check Point firewall die verkeer voorziet van NAT en inspectie.

Testen Multihoming (IPv4/IPv6)
– Verstuur een ping naar de overzijde met afzenderadres link ‘?n.
– Verstuur een ping naar de overzijde met afzenderadres link twee.
– Ontvang een ping van de overzijde over link ‘?n.
– Ontvang een ping van de overzijde over link twee.
– Ping overzijde constant en verwijder de actieve verbinding. Meet de tijd van connectieherstel, als deze aanwezig is.
– Start een ftp-sessie van het ene eindsysteem naar de ander en verwijder actieve verbinding. Meet de tijd van herstel, als deze aanwezig is.
VM/IP Mobility (IPv4/IPv6)
– Verplaats het ene eindsysteem naar het netwerk aan de overzijde. Meet hoe lang het duurt voordat de mapping-server op de hoogte is van de verandering.
– Hetzelfde als bovenstaand, maar ook met een ping lopend om connectieherstel te meten.
– Ping het verplaatste systeem vanaf een eindsysteem uit beide LISP omgevingen en de niet-LISP omgeving.
– Start een FTP sessie voor het verplaatsen en controleer of de sessie wordt voortgezet na het verplaatsen. Meet de hersteltijd.
IPv6 Transitie
– De bovenstaande testen van multihoming en VM/IP mobility uitvoeren met het ‘internet’ als volledig IPv4 en IPv6 om de overbrugging van een ander netwerk te testen. Dit is minder belangrijk, omdat het in de vorige opstelling vrij veel aan bod komt.

‘
7. IMPLEMENTATIEFASE

In de implementatiefase worden de drie ontwerpen uit het ontwerprapport daadwerkelijk gebouwd. Hier zijn verder geen eisen aan verbonden of keuzes voor gemaakt. In dit hoofdstuk zal per ontwerp de definitieve topologie worden weergeven met daarbij de configuratie die nodig was om het ontwerp te laten werken.
7.1 UITWERKING CONFIGURATIE

Opstelling ‘?n

FIGUUR 7.1 – TOPOLOGIE OPSTELLING ‘?N
Voor het implementeren van opstelling ‘?n (Figuur 7.1) is er weinig configuratie nodig, omdat er gebruik wordt gemaakt van publiek beschikbare componenten voor het mapping-system en proxy-service. Zo blijft alleen de configuratie over van ‘smit-hague-xtr’ en host A. Daar komen drie onderdelen bij kijken.
1. Het configureren van interfaces
2. Het configureren van de locator-set
3. Het aangegeven van het te gebruiken mapping-system en proxy-router
Het eerste onderdeel heeft verder niets met specifieke LISP configuratie te maken. Op de Windows machine kunnen de adressen via de adapterinstellingen statisch worden geconfigureerd en de interfaces van smit-hague-xtr worden via Cisco IOS commando’s ingevoerd. Daarnaast is het aangeven van een default gateway belangrijk.
!
interface GigabitEthernet 1
ip address 46.243.40.166 255.255.255.192
no shutdown
!
!
interface GigabitEthernet 2
ip address 153.16.55.225 255.255.255.255
ipv6 address 2610:D0:21CA::153:16:55:225/128
no shutdown
!
!
ip route 0.0.0.0 0.0.0.0 46.243.40.129
!

Het tweede deel, het configureren van de locator-set, is een belangrijk deel voor de ETR functionaliteit van LISP. Hierin wordt aangegeven welke RLOC’s aanwezig zijn en welke EID-prefix zich achter die RLOC’s bevindt. Deze informatie wordt in een later stadium gedeeld met het mapping-system.
!
router lisp
locator-set BETA
46.243.40.166 priority 1 weight 100
!
!
eid-table default instance-id 0
database-mapping 153.16.55.224/28 locator-set BETA
database-mapping 2610:D0:21CA::/48 locator-set BETA
!

Het laatste deel, het aangeven van het te gebruiken mapping-system en proxy-router, wordt op de volgende wijze geconfigureerd. Deze configuratie is nodig voor de ITR om zijn map-request te versturen en voor de ETR nodig om zijn map-register berichten te versturen.
ipv4 itr
ipv4 etr
ipv4 itr map-resolver 193.162.145.50
ipv4 etr map-server 193.162.145.50 key smit-hague-xtr
ipv4 use-petr 193.162.145.46 priority 1 weight 100

ipv6 itr
ipv6 etr
ipv6 itr map-resolver 193.162.145.50
ipv6 etr map-server 193.162.145.50 key smit-hague-xtr
ipv6 use-petr 193.162.145.46 priority 1 weight 100

De volledige configuratie bevatte extra map-servers en map-resolvers uit redundantie overwegingen, maar dat is voor het toelichten van de configuratie niet relevant. Dat zijn slecht kopie??n van de bovenstaande commando’s met verschillende IP-adressen. ‘
Opstelling twee

FIGUUR 7.2 – TOPOLOGIE OPSTELLING TWEE
De configuratie van opstelling twee (Figuur 7.2) voor de algemene werking van LISP is grotendeels hetzelfde als opstelling ‘?n op de verschillende IP-adressen na. Waar je in opstelling ‘?n aangaf dat het mapping-system een publiek IP-adres op het internet was, is dat nu een IP-adres binnen het zelf opgerichte netwerk. Dat geldt voor beide xTR’s. De configuratie van het mapping-system omvat het aangeven welke ETR’s bij zich mogen registeren door het aangeven van een site-naam, authenticatiesleutel en EID-prefix. Daarnaast moet de map-server en map-resolver functionaliteit aangezet worden.
!
router lisp
site SITE-A
authentication-key SITEAKEY
eid-prefix 192.168.1.0/24 accept-more-specifics
exit
!
site SITE-B
authentication-key SITEBKEY
eid-prefix 192.168.2.0/24
exit
!
ipv4 map-server
ipv4 map-resolver

De configuratie van een PxTR is normaliter wat ingewikkelder, omdat er ook BGP configuratie bij komt kijken om de bekende LISP routes te distribueren in het DFZ. Dat is hier niet nodig, omdat SITE-C direct verbonden is met de PxTR. De resterende configuratie omvat het statisch opslaan van cache-entries, waardoor de PxTR weet dat hij voor die IP-reeksen een map-request-cyclus moet uitvoeren en het aangeven van een map-resolver die daarvoor gebruikt moet worden. Tevens moet net als bij de andere componenten de commando’s om PxTR functionaliteit te starten geactiveerd worden.
!
router lisp
map-cache 192.168.1.0/24 map-request
map-cache 192.168.2.0/24 map-request
ipv4 proxy-etr
ipv4 proxy-itr 14.14.14.2
ipv4 itr map-resolver 12.12.12.2
exit
!

In principe is connectie in het lab op basis van deze configuratie volledig mogelijk. Allen de configuratie om gebruik te maken van multihoming en VM/IP mobility ontbreekt. De configuratie voor multihoming wordt door de ETR geregeld. Waar in de vorige paragraaf een voorbeeld van een locator-set werd gegeven met daarin ‘?n RLOC-adres, is multihoming niets meer dan het aangeven van een extra RLOC-adres. Voor xTR1 is het volgende geconfigureerd.
!
router lisp
locator-set SITE-A
10.10.10.2 priority 1 weight 100
11.11.11.2 priority 1 weight 0
exit
!

Het configureren van VM/IP mobility was een stuk ingewikkelder, omdat er geen concrete voorbeelden te vinden waren. Uiteindelijk is na verschillende pogingen een werkende configuratie geschreven. Het eerste gedeelte van de configuratie is het aangeven van een EID-prefix dat mobiel mag verplaatsen tussen locaties. Dit wordt gerealiseerd door bij beide xTR’s een dynamisch EID aan te geven. Voor het gemak is de volledige prefix mobiel gemaakt. Dit had ook een kleiner onderdeel van het subnet kunnen zijn.
xTR1
!
eid-table default instance-id 0
dynamic-eid MOBILE-SITE
database-mapping 192.168.1.0/24 locator-set SITE-A
exit
!

xTR2
!
eid-table default instance-id 0
database-mapping 192.168.2.0/24 locator-set SITE-B
dynamic-eid MOBILE-SITE
database-mapping 192.168.1.0/24 locator-set SITE-B
map-server 12.12.12.2 key SITEAKEY
exit
!

Zoals te zien is in de bovenstaande configuratie wordt aangegeven dat een dynamisch EID-prefix (192.168.1.0/24) achter zowel SITE-A als SITE-B mag werken. Dit gedrag moet in het mapping-system nog worden bevestigd door ‘accept-more-specifics’ aan te geven bij SITE-A (zie configuratieblok mapping-system). Door dit commando is het voor het mapping-system mogelijk om specifieke /32 routes op te nemen wanneer een host zich verplaatst.
Als laatste rest zich nog het configureren van de xTR’s op een wijze dat een verplaatsing ook daadwerkelijk geregistreerd kan worden. Dit wordt gedaan door een interface op de xTR’s aan te geven als mobility-poort.
!
interface GigabitEthernet0/1
mac-address 0000.0d0e.010c
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
lisp mobility MOBILE-SITE
!

Het commando ‘lisp mobility MOBILE-SITE’ maakt het voor de interface mogelijk om de reageren op arp-berichten van het eerder geconfigureerde dynamische EID MOBILE-SITE. Hiervoor is nog wel nodig dat beide interfaces van zowel xTR1 als xTR2 hetzelfde MAC-adres gebruiken. Hierdoor kunnen beide xTR’s zich voordoen als default gateway, ondanks dat de host zich in een ander subnet bevindt.
Voor een volledig overzicht van de configuratie wordt verwezen naar hoofdstuk acht van ‘Externe bijlagen ‘ VI’
Opstelling drie

FIGUUR 7.3 – TOPOLOGIE OPSTELLING DRIE
De configuratie van opstelling drie (Figuur 7.3) is volledig identiek aan opstelling twee op de configuratie van xTR1 en de extra firewall na. In de extra firewall moeten een aantal NAT-regels (Figuur 7.4) worden opgenomen. Aan de ene kant moet een hide-NAT worden opgenomen om uitgaand verkeer van het interne netwerk te verschuilen achter een bekend EID-adres. Aan de andere kan moeten een aantal statische NAT-regels worden opgenomen om bijvoorbeeld verkeer bestemd voor 192.168.1.3, die niet bestaat, te vertalen naar 172.16.1.3, zodat connectie van buitenaf mogelijk blijft.

FIGUUR 7.4 – VOORBEELD NAT-REGELS
Daarnaast is het nodig voor elke statische NAT-regel een statische route op te nemen op xTR1 die verwijst naar de firewall (192.168.1.2). Dit is nodig omdat bijvoorbeeld 192.168.1.3 officieel niet bestaat. Door het opnemen van een statische route kan verkeer toch worden doorgestuurd naar een niet bestaand adres die de firewall vervolgens ontvangt, transleert op basis van de statisch NAT en doorstuurt naar het eindsysteem.
!
ip route 192.168.1.3 255.255.255.255 192.168.1.2
!

7.2 TOELICHTING CONFIGUREREN
De moeilijkheidsgraad van het configureren verschilt ontzettend per opstelling. Bij opstelling ‘?n was het configureren eenvoudig. Bij het aanvragen van toestemming om aan het b??ta-netwerk deel te nemen werd een voorbeeld configuratie meegestuurd. Opstelling twee was een stuk moeilijker. Voor het implementeren van IPv6 transitie en multihoming was genoeg naslagwerk te vinden, maar voor VM/IP mobility niet. De enige bronnen die te vinden waren hadden betrekking op totaal andere netwerken en/of andere besturingssystemen. Uiteindelijk is het gelukt om een werkende configuratie te maken door verschillende voorbeelden te analyseren en te vertalen naar commando’s die wel aanwezig zijn op het gebruikte besturingssysteem.
‘
8. TESTFASE

De laatste fase van het onderzoek is de testfase. Hierin worden de verschillende testplannen uitgevoerd op de gebouwde opstellingen. Tevens wordt het adviesrapport geschreven die gebruikt gaat worden door Qi ict om een oordeel te vellen over het gebruik van LISP.
8.1 COMBINEREN VAN FASES
Voor het bouwen van de opstellingen waren qua hardware twee Cisco 2900-series routers beschikbaar en drie computers. Op de ESX-server was het mogelijk om twee virtuele routers en ‘?n virtuele computer op te zetten, zonder dat andere gebruikers daar teveel last van hadden. Met deze onderdelen was precies genoeg apparatuur aanwezig om elke opstelling ‘?n maal te bouwen, maar niet tegelijk. Om deze reden is gekozen om de implementatiefase en een deel van de testfase samen te voegen. E??n voor ‘?n zijn de opstelling gebouwd en getest. De resultaten van de testplannen zijn opgeslagen als bijlage in het adviesrapport.
8.2 EISEN
De eisen aan de testfase hebben betrekking op twee onderdelen. Allereerst de eisen die worden gesteld aan de testresultaten en ten tweede de eisen de worden gesteld aan het adviesrapport. Voor de testresultaten zijn de volgende eisen opgesteld:
– Van alle opstellingen dienen verschillende gegevens opgeslagen te worden. De gegevens worden in de laatste fase van het onderzoek gebruikt als bron om het adviesrapport te schrijven. Per opstellingen dienen de volgende gegevens aanwezig te zijn:
o Configuratie van netwerkelementen en de definitieve topologie
o Metingen/resultaten van het testplan
o Eventuele bevindingen die niet tijdens het literatuuronderzoek naar voren zijn gekomen
o Korte conclusie over de werking
Op het adviesrapport zijn de volgende eisen van toepassing:
– Het adviesrapport bevat een algemene beschouwing van LISP op basis van de testresultaten en bevindingen uit het testresultatenrapport. De beschouwing bevat:
o Een analyse van de netwerkcomponenten (xTr, PxTR, MS, MR) die nodig zijn voor het opzetten van een LISP omgeving. Relevante informatie is:
‘ Moeilijkheidsgraad van het opzetten (configuratie)
‘ Hard- en software vereisten
o Een analyse van de technieken multihoming, IPv6 transitie en VM/IP mobility. Hierbij dient vergeleken hoe de technieken zich in de praktijk hebben geuit in tegenstelling tot de theorie uit het onderzoekrapport.
– Het adviesrapport bevat een overzicht van LISP-technologie dat tijdens het onderzoek niet aan bod is gekomen. Dit kunnen technieken zijn waarvoor geen tijd en/of middelen beschikbaar waren, of technologie dat nog in ontwikkeling is.
– Op basis van de resultaten uit het onderzoeksrapport en testresultatenrapport dient een advies te worden opgesteld over de geschiktheid van LISP voor klanten van Qi ict. De partijen wiens netwerk hiervoor bekeken dienen te worden zijn:
o Enterprises (met meerdere vestigingen)
o Internet Service Providers
– De geschiktheid van LISP voor een onderneming dient bepaald te worden aan de hand van:
o De voordelen van LISP adoptie
o De nadelen van LISP adoptie
o Een grove schatting wat de adoptie zou kosten
8.3 TESTEN
Net als de testplannen die in de ontwerpfase zijn opgesteld is het opslaan van resultaten ook gebeurt op basis van het ASL-BISL format. Door middel van dit format zijn de resultaten niet gewoon gegevens, maar is er ook in ‘?n oogopslag te zien in hoeverre de testen een positief of negatief resultaat hebben opgeleverd. De testresultaten zijn verwerkt met de volgende gegevens:
– Projectnaam
– Datum
– Globale beschrijving
– Testnummer
– Testomschrijving
– Verwacht resultaat
– Resultaat
– Ok/Niet-OK
– Opmerkingen
Dit format is bij elke opstellingen en test aangehouden. Een volledig overzicht van de resultaten bevindt zich in hoofdstuk acht van ‘Externe bijlagen ‘ VI’.
8.4 ANALYSE
De uitgevoerde testplannen hebben diverse resultaten en bevindingen opgeleverd die in dit hoofdstuk worden geanalyseerd. Voor de tabellen met meetgegevens wordt verwezen naar hoofdstuk acht van ‘Externe bijlagen ‘ VI’.
8.4.1 ANALYSE TECHNIEKEN
Het eerste gedeelte van het rapport omvat een analyse van de verschillende netwerkcomponenten en technieken die voorgekomen zijn in de gebouwde opstellingen. De reden van deze analyse is het bepalen of de componenten en technieken net zo hebben gereageerd als werd omschreven in het onderzoeksrapport. Oftewel het analyseren of de theorie zich in de praktijk ook zo uit. Het eerste deel van de analyse omvatte een toelichting van de configuratie. Dat onderdeel is in het vorige hoofdstuk, de implementatiefase, al gedaan. Het tweede deel omvat een analyse van de testresultaten van de verschillende technieken die onderzocht zijn.
Multihoming
Multihoming is de eerste techniek die getoetst is. De eerste twee testen zijn uitgevoerd om de beschikbaarheid van de verbindingen te testen. Door middel van traceroutes is bewezen dat verkeer over beide lijnen het achterliggende EID-omgeving kan bereiken. De volgende vier testen zijn gebruikt om connectieherstel te meten. In test drie en vier is een constante stroom van icmp-berichten opgezet tussen overstaande netwerken waarna de actieve lijn werd verwijderd van de xTR. Hetzelfde proces is gevolgd in te testen vijf en zes. Hier is in plaats van een stoom icmp-berichten gebruik gemaakt van een ftp-sessie waarin een download plaatsvindt. Bij test vier en zes was RLOC-probing actief en bij de testen drie en vijf niet. Dit is een techniek om vooraf bekende RLOC’s uit de mapping-cache te peilen op bereikbaarheid. Tabel 8.1 geeft een vereenvoudigde weergave van de testen en resultaten voor multihoming.
TABEL 8.1 – VEREENVOUDIGDE WEERGAVE RESULTATEN MULTIHOMING
Test Resultaat opstelling twee Resultaat opstelling drie

– 1: Traceroute lijn ‘?n
– 2: Traceroute lijn twee – Geslaagd
– Geslaagd – Geslaagd
– Geslaagd

– 3: icmp-stroom
– 4: icmp-stroom (probing) – 4 seconden herstel
– 4 seconden herstel – 4 seconden herstel
– 4 seconden herstel

– 5: ftp-sessie
– 6: ftp-sessie (probing) – 4 seconden herstel
– 4 seconden herstel – 4 seconden herstel
– 4 seconden herstel

Bij de testen drie en vijf werd verwacht dat het hervatten van de constante stroom van icmp-berichten en ftp-sessie maximaal zestig seconden zou duren, omdat de map-server elke zestig seconden wordt voorzien van nieuwe informatie. In de testen vier en zes werd verwacht dat de verbinding sneller zou herstellen doordat RLOC-probing actief was. Verrassend was dat bij test twee en drie slechts ‘?n icmp-timed-out-bericht te zien, wat resulteerde in een gemiddelde onderbreking van vier seconden. Hetzelfde gedrag is gedemonstreerd bij het herstellen van de ftp-sessie. Het bleek dat naast de reguliere zestig seconden vernieuwing van de map-server informatie ook een geforceerde vernieuwing plaatsvindt wanneer een lijn faalt.
Dit geldt niet voor het terugplaatsen van een lijn. Deze informatie wordt wel pas na de zestig seconden periode meegenomen. Tevens is het goed om te weten dat ftp-sessie niet opnieuw opgebouwd is, maar juist werd hervat toen de verbinding herstelde. Dit komt doordat het eindsysteem niet doorheeft dat de lijn waarover het verkeer binnenkomt is gewijzigd. Dit is te danken aan het encapsulationproces dat simpelweg een andere RLOC plaatst in de header.
De focus van de testen met betrekking tot multihoming lagen op de beschikbaarheid en connectieherstel, omdat het gros van de klantnetwerken gebruik maakt van een ‘high avaliability’ modus. Dat wil zeggen dat de tweede lijn pas actief wordt wanneer de eerste lijn faalt. Multihoming met LISP laat ook verdeling en prioriteit van lijnen toe. Deze techniek is zelf niet getoetst, maar een bachelor thesis uit 2013 van de universiteit van Darmstadt, omschrijft het gedrag van deze techniek wel . In deze thesis wordt bewezen dat de verdeling van verkeer op basis van LISP multihoming nagenoeg het optimum van bijvoorbeeld 50/50 bereikt wanneer dit is geconfigureerd. Na een serie testen is gebleken dat een maximale afwijking van 5% voorkomt.
VM/IP Mobility
Voor de testen zeven tot en met negen lag de focus op VM/IP mobility. Voor test nummer zeven was het doel om te meten hoe snel het mapping-system op de hoogte zou zijn van een verplaatst eindsysteem. Om de verplaatsing waar te nemen en te meten werd gebruikt van debuginformatie op de xTR’s en het mapping-system. Daarnaast kan door middel van een ‘show lisp site’ commando elke seconden worden gekeken of een vernieuwing van informatie heeft plaatsgevonden. De testen acht en negen zijn uitgevoerd om de bereikbaarheid voor en na de verplaatsing te testen en hoe snel de verbindingen worden hersteld. Voorafgaand aan de verplaatsing werden diverse icmp-stromen opgezet plus een ftp-sessie waarin een download in plaatsvindt. Vervolgens werd het eindsysteem verplaatst naar het nieuwe netwerk. Tabel 8.2 geeft een vereenvoudigde weergave van de testen en resultaten voor VM/IP Mobility.
‘
TABEL 8.2 – VEREENVOUDIGDE WEERGAVE RESULTATEN VM/IP MOBILITY
Test Resultaat opstelling twee Resultaat opstelling drie

– 7: Updaten mapping-system – Binnen een seconde – Niet kunnen uitvoeren

– 8: icmp-stromen tussen alle drie de omgevingen – Volledige bereikbaarheid voor en na verplaatsing – Niet kunnen uitvoeren

– 9: ftp-sessie download – 6 seconden hersteltijd nodig voor vervolgen van download – Niet kunnen uitvoeren

Bij test zeven werd verwacht dat het resultaat onder een seconde zou zijn, omdat de documentatie omschrijft dat het vernieuwen van de map-server informatie ongeveer binnen anderhalf keer de round-trip-time van de verbinding gebeurt. Bij het verplaatsen van het eindsysteem was in de debuginformatie te zien dat direct een verplaatsing werd gedetecteerd met daarop volgend direct een solicit-map-request om de andere partijen op de hoogte te stellen. De map-server informatie gaf ook aan binnen een seconde de verplaatsing te zien. Dit was waarschijnlijk nog sneller, maar de ‘show lisp site’ informatie werkt alleen in seconden.
Bij de testen acht en negen werd na gemiddeld zes seconden werd de download voortgezet en werden alle icmp-stromen weer actief. Hieruit is te concluderen dat ondanks het verplaatsen naar een subnet waar een ander EID-prefix actief is, nog steeds volledige beschikbaarheid heerst. Daarnaast is het net als bij multihoming slechts een kwestie van een aanpassing van het RLOC-adres in de header, waardoor het eindsysteem zelf niets doorheeft van de wijziging.

FIGUUR 8.1 – MAP-SERVER INFORMATIE
De bovenstaande afbeelding (Figuur 8.1) geeft weer hoe de RLOC van de specifieke /32 route wijzigt wanneer een mobiel eindsysteem (192.168.1.3) verplaatst naar een nieuw netwerk.
Dezelfde testen zijn ook uitgevoerd op opstelling drie, maar VM/IP mobility is hier niet werkend te krijgen. Om mobility te kunnen gebruiken moet de xTR de first-hop router zijn om de verplaatsing te kunnen detecteren. Dat is hier niet het geval. Om dit toch te laten werken is er ‘?n andere mogelijkheid met LISP; Multihop ESM. Hierbij wordt een first-hop LISP-router geplaatst voor de firewall die de verplaatsingen kan detecteren en doorgeven aan de grens xTR. Dit valt niet te testen in de huidige opstelling, omdat een aantal vereisten aan de techniek vastzitten die niet gebouwd kunnen worden, zoals het gebruik van OTV tussen de netwerken. Daarnaast is deze techniek ook niet toepasbaar op omgevingen met NAT waardoor het in opstelling drie niet haalbaar is.
IPv6 Transitie
De laatste techniek die getoetst is was IPv6 transitie. Hierbij lag de focus vooral op de beschikbaarheid van het netwerk na de adoptie van LISP. Om dit te toetsen is een dualstack Windows machine opgezet achter een zelf geconfigureerde xTR met een publiek IPv4-adres. Na het configureren van de opstellingen zijn diverse icmp-berichten verstuurd van en naar de Windows machine over zowel IPv4 als IPv6. Alle testen waren succesvol. Daarnaast is een IPv6-ready test uitgevoerd op het internet om te kijken in hoeverre de omgeving klaar is voor een overstap naar IPv6.

FIGUUR 8.2 – RESULTATEN IPV6-READY TEST
Uit de bovenstaande afbeelding (Figuur 8.2) valt te concluderen dat, mits aan de voorwaarden van LISP wordt voldaan, een maximale score behaald kan worden als LISP wordt geadopteerd als transitietechniek.
Aanvankelijk waren de resultaten van deze testen overtuigend genoeg om te besluiten dat verdere IPv6 transitie testen niet nodig waren. Om die reden zijn deze ook overslagen bij opstelling twee. Met de reden dat na het uitvoeren van alle testen nog een dag overbleef in de planning om te testen is besloten om het centrale netwerk van opstelling drie ook van IPv6-addressen te voorzien, om te bewijzen dat LISP onder alle omstandigheden kan werken. De resultaten waren helaas minder positief. Dit is niet te wijten aan LISP zelf, maar aan de gebruikte Check Point firewall die fungeert als DFZ. Bij het encapsulationproces waarbij IPv4-verkeer wordt ingepakt in een IPv6-pakket wordt een zogeheten ‘zero-checksum’ toegevoegd. Volgens RFC6935 is dit toegestaan op het internet en een veel gebruikte techniek bij tunnelprotocollen. Check Point heeft hierin gefaald door pakketten met een zero-checksum te blokkeren. De fabrikant is op de hoogte gesteld van dit probleem.
De bovenstaande bevinding is niet een reden om te twijfelen aan de mogelijkheden van LISP met betrekking tot IPv6 transitie. De reden dat verkeer werd geblokkeerd komt doordat er als DFZ een Check Point firewall is gebruikt. De kans dat die op het internet ook op die manier wordt gebruikt is klein. Firewalls zullen over het algemeen voor een xTR worden geplaatst. Daarbij kom ook dat in deze specifieke situatie het DFZ was voorzien van IPv6-adressen. Dat is een situatie die voorlopig nog niet aan de orde is.
‘
8.4.2 ALGEMENE BEVINDINGEN
Naast de specifieke bevindingen die per techniek zijn aangetroffen zijn ook nog een aantal algemene bevindingen aangetroffen die niet in het onderzoeksrapport naar voren zijn gekomen.
Globaal unieke adressen
De eerste bevinding is het gebruik van globaal unieke adressen. In de documentatie die gebruikt is tijdens het schrijven van het onderzoeksrapport zijn veel kreten voorbij gekomen waar geroepen werd dat voor het gebruik van LISP het (interne) netwerk niet gewijzigd hoeft te worden. Hierbij is niet duidelijk vermeld dat er vanuit werd gegaan dat ‘?n of meer globaal unieke adressen beschikbaar zijn. Voor het RLOC-adres kan het globale adres gebruikt worden die onder normale omstandigheden wordt ontvangen van een ISP, maar voor de EID-prefix is een globaal uniek adres nodig om achter te verschuilen met NAT of een totale globale EID-reeks om in het interne netwerk te gebruiken. De reden hiervoor is onder andere het verliezen van encapsulation bij het passeren van een PxTR op weg naar een niet-LISP omgeving. Wanneer de encapsulation wordt verwijderd blijft alleen een standaard IP-pakket over. Als hierin private IP-adressen aanwezig zijn, zoals die uit RFC1918, wordt het pakket vernietigd. Deze globale reeks mag zowel provider aggregatable (PA) of provider independent (PI) zijn. Hierbij moet wel vermeld worden dat PI-adressen inmiddels niet langer beschikbaar zijn bij RIPE, dus als een onderneming deze niet al tot haar beschikking heeft is de enige mogelijkheid het kopen van PA-adressen van een RIPE LIR.
Inspectie versus mobility
De tweede bevinding is een beveiligingsaspect van LISP. Veel klanten van Qi ict hebben een firewall geplaatst op de grens van het netwerk met het DFZ. Wanneer encapsulation wordt toegepast en de firewall niet over de mogelijkheid beschikt om LISP te analyseren valt de mogelijkheid tot inspectie weg. Op het moment is er slechts ‘?n firewall, de Cisco ASR1K ZBF, die LISP-verkeer kan inspecteren. Dat geldt ook voor inkomend verkeer. Encapsulation wordt pas verwijderd bij de xTR, dus tot dat moment kan er allerlei malafide content worden verplaatst. Een oplossing hiervoor is het plaatsen van een firewall voor de xTR zoals in opstelling drie, maar zoals bekend verlies je dan ook LISP functionaliteit in de vorm van VM/IP mobility. Dit is op zijn beurt weer te verhelpen met techniek als LISP multihop , maar dat brengt weer extra veranderingen toe aan het netwerk en daarmee ook extra kosten.
Druk op netwerk
De laatste algemene bevinding is een mogelijke druk op het netwerk door de LISP-berichten die elke zestig seconden worden verstuurd. Deze druk is niet waargenomen in de zelf ontwikkelde opstellingen, omdat slechts twee omgevingen die berichten versturen, maar er wordt wel rekening mee gehouden dat dit in een grote omgeving best een probleem kan opleveren. Naar aanleiding van dit vraagstuk is informatie opgevraagd over de invloed van LISP-berichten op de prestaties van een netwerkcomponent. De engineers van Cisco geven aan dat dit niet noemenswaardig is. Map-register berichten zijn effici??nt geprogrammeerd om meerdere registraties tegelijk uit te voeren. Zelf als dit niet het geval was en elk bericht maar ‘?n registratie voltooide, zou dat voor honderd netwerken om honderd pakketten per zestig seconden gaan. De kleinste routers van Cisco die LISP ondersteunen, de ISRG1 800-series, kunnen al tussen de tien- en honderdduizend pakketten per seconden verwerken. Dit is ruim voldoende. Daarbij komt ook elke ETR zijn eigen timer heeft, waardoor het niet zo is dat elke zestig seconden de database wordt overspoeld met registraties. Dit gebeurt redelijk verdeeld.
‘
8.5 ADVISEREN
Informatie uit het onderzoeksrapport en het voorgaande analysehoofdstuk hebben een goed beeld weergeven van de werking van LISP in zowel theorie als praktijk. Deze informatie zegt echter weinig over de geschiktheid van implementatie bij klanten. In dit hoofdstuk worden de diverse adoptiemogelijkheden voor Enterprises en ISP’s uitgewerkt met daarbij de bijbehorende voor- en nadelen om een advies te kunnen geven.
8.5.1 ADOPTIE
Om te kunnen oordelen of het protocol geschikt is voor adoptie bij ‘?n of beide partijen zijn de onderstaande drie criteria opgesteld:
– De manier en in welke mate LISP wordt geadopteerd
– Wat het adopteren ongeveer kost
– Wat de voor- en nadelen zijn van het adopteren
Deze drie criteria zijn voor zowel Enterprises en ISP’s uitgewerkt in dit hoofdstuk. Tevens is gekeken naar de toekomst van LISP zoals het er nu uit ziet. Op basis van deze informatie wordt in hoofdstuk negen een conclusie en aanbeveling gegeven over het gebruik van LISP door Qi ict.
Internet Service Provider
Een ISP heeft de mogelijkheid om LISP te adopteren in drie verschillende vormen van ingrijpbaarheid.
1. Optie ‘?n, minimaal ingrijpend. De eerste vorm is het minst ingrijpend. De ISP kan er voor kiezen om het interne netwerk van de onderneming niet te wijzigen en puur te fungeren als backbone van het internet dat routering verzorgt. De xTR’s van de ondernemingen verzorgen de EID-to-RLOC opzoekopdrachten en andere instanties verzorgen de mapping-systems en proxy-services, waardoor de ISP alleen maar hoeft te zorgen voor routering van verkeer. Het is wellicht niet de meest sociale manier van ondernemen om anderen het werk te laten doen, maar wel aantrekkelijk voor ISP’s die niet over de middelen beschikken om LISP volledig te adopteren.
2. Optie twee, gemiddeld ingrijpend. De tweede vorm van adoptie vereist ook geen ingrijpende wijzigingen. Slechts een aantal componenten worden toegevoegd. Om niet afhankelijk te zijn van een publiek mapping-system en proxy-service kan een ISP er voor kiezen om mee te doen aan de globale adoptie van LISP door een eigen service op te zetten. Hierdoor voorziet de ISP ondernemingen niet langer alleen van routering, maar kan de ISP ook actief meewerken aan de connectiviteit. De ISP kan hierin ook een stap verder gaan door EID-prefixes, oftewel PA-adressen, te gaan uitdelen aan onderneming en deze via haar eigen proxy-service bekend te maken op het internet.
3. Optie drie, zeer ingrijpend. De laatste vorm van adoptie is zeer ingrijpend en vereist wat veranderingen aan het interne netwerk. Dit is tevens een speculatieve adoptie, omdat er alleen theoretische voorbeelden van zijn. In de paper ‘Implementing a BGP-free ISP Core with LISP’ wordt een manier omschreven om de kern van een ISP-netwerk niet langer van (i)BGP te voorzien, door de routers aan de grens van het ISP netwerk te vervangen met xTR’s.
Kosten
Voor alle drie de adoptietechnieken is geprobeerd een inschatting te geven van de kosten bij het adopteren van LISP. Dit is niet mogelijk gebleken. Afgezien van optie ‘?n waarbij de adoptie in theorie niets kost zijn er teveel factoren waarover geen informatie beschikbaar is. Hierdoor is een inschatting maken volledig uit de lucht gegrepen. Om toch wat duidelijkheid te scheppen is de onderstaande opsomming gemaakt. Bij het adopteren van LISP als ISP moet rekening gehouden met de volgende zaken:
– Keuze van adoptietechniek
– Opensource software versus betaalde licenties
– Grootte van de onderneming
– In welke mate apparatuur kan worden hergebruikt
Voor- en nadelen
Voor elke adoptietechniek zijn specifieke voor- en nadelen te benoemen. Deze zijn te vinden in tabel 8.3. De onderstaande opsomming geeft de voor- en nadelen weer die over het algemeen voorkomen bij de adoptie van LISP door een ISP.
Algemene voordelen:
– Verkleining globale routeringtabellen. Het zal nog even duren voordat dit voordeel zichtbaar wordt, maar LISP zorgt voor een verkleining van de routeringstabellen in het DFZ. Een kleinere tabel heeft als voordeel dat routers niet langer constant voorzien moeten worden van nieuwe hardware om het rap groeiende aantal routes te kunnen bijbenen en kunnen de routers minder hard gaan werken, waardoor de levens duur van apparatuur toeneemt.
– Minder BGP kennis. Het internetmodel wordt minder afhankelijk van BGP, doordat veel gebruikte services zoals multihoming nu zonder BGP kunnen worden aangeboden. Daarbij komt ook een kostenverlaging kijken, omdat dure BGP-apparatuur en personeel die verstand van BGP heeft niet meer veelvuldig nodig is.
– IPv4/IPv6 ondersteuning. LISP ondersteund standaard zowel IPv4 als IPv6. Dit kan als ISP gebruikt worden als voordeel in tijdens de transitieperiode naar IPv6 die op het moment bezig is.
– Open source. LISP wordt ontwikkeld als open standaard met implementaties van verschillende partijen en geschreven in verschillende programmeertalen. Hierdoor is het mogelijk om goedkoop gebruikt te maken van de techniek. Hierbij komt ook het feit dat het mogelijk is om ouder apparatuur te voorzien van LISP code, om zo ouder apparatuur nieuw leven in te blazen en kosten te besparen.
Algemene nadelen:
– Protocol in ontwikkeling. Ondanks dat er wereldwijd ruim 100.000 omgevingen zijn die LISP hebben geadopteerd blijft het een experimenteel protocol. Engineers die werken aan LISP noemen het protocol ‘productie kwaliteit’, maar het feit dat er nog technieken zich in de ontwikkelfase bevinden blijft bestaan. Tevens wordt het protocol gedragen door vrijwilligers, waardoor hulp niet gegarandeerd is, tenzij dat wordt afgesloten met een bepaalde partij.
– Globale adoptie. LISP is net als IPv6 een protocol dat globaal geadopteerd moet worden om volledig tot zijn recht te komen en daar is op het moment is er nog weinig draagvlak voor. Bijvoorbeeld in Nederland is er slechts ‘?n ISP bekend die LISP services levert.

TABEL 8.3 – VOOR- EN NADELEN VAN ADOPTIETECHNIEKEN ISP
Optie ‘?n Optie twee Optie drie

Voordelen:
– Goedkope oplossing. Laat andere partijen het werk doen en profiteer van de voordelen. Wanneer een onderneming een xTR aanschaft kan bijvoorbeeld goedkoop multihoming worden gerealiseerd zonder BGP. Hier hoeft de ISP verder niets voor te doen. Slechts het leveren van ‘?n of meer internetlijnen. Voordelen:
– Tevens een goedkope oplossing. Een eigen mapping-system en proxy server kan opensource worden geregeld. Logischerwijs wordt het leveren van zo’n service duurder naarmate meer partijen van de service gebruik maken, maar het verdient zich later ook terug in de verkleining van routetabellen en minder BGP gebruik.
– Niet langer afhankelijk van publieke servers. Het is nu mogelijk om eigen beheer uit te voeren. Voordelen:
– BGP is niet langer verplichte kost binnen een autonomous system. Dit scheelt kosten in de vorm van BGP apparatuur en personeel dat kennis moet hebben van BGP.
– Niet alleen globale, maar ook interne routeringstabellen nemen af in grootte.
– De encapsulation aan de ISP kant laat ook instance ID’s toe die gebruikt kunnen worden voor bijvoorbeeld VPN’s of QoS. Hierdoor kan MPLS wellicht vervangen worden. Dit scheelt ook weer in de kosten aangezien MPLS een ingewikkeld protocol is dat veel geld kost in de vorm van trainingen en MPLS-beschikbaar apparatuur.
– Als er xTR’s worden gebruikt aan de grenzen van een AS betekent dat ook dat multihoming gebruikt kan worden. Hiermee is loadbalancing en prioriteit eenvoudig toe te kennen aan verkeer. Daarnaast zijn er ook snelle fail-overs mogelijk zoals de resultaten hebben laten zien in het testplan.

Nadelen:
– De voordelen van LISP worden groter naar mate meer partijen deelnemen. Als iedereen deze instelling heeft komt er nooit verandering. Nadelen:
– Uiteindelijk verruil je kennis van BGP voor kennis van LISP. Daarnaast komen kosten kijken bij de management van LISP services. Nadelen:
– Het blijft een (risicovolle) investering die uiteindelijk voor niets kan zijn als LISP niet wordt overgenomen op globaal niveau.

Enterprises
De drie manieren van adoptie voor Enterprises worden hieronder opgesomd:
1. Optie ‘?n, minimaal ingrijpend. De eerste adoptietechniek die besproken wordt is een techniek waarbij de xTR aan de kant van een ISP wordt geplaatst en onder het beheer van de ISP valt. Deze adoptietechniek wordt door de IETF aangedragen als optie voor ondernemingen die geen wijzigingen willen doorvoeren aan hun eigen netwerk en om die reden alle verantwoordelijkheid bij de ISP leggen. De interne omgeving van een onderneming staat in direct contact met een xTR bij een LISP-ISP die op al het verkeer encapsulation zal toepassen.
2. Optie twee, minimaal/gemiddeld ingrijpend. De tweede adoptietechniek haalt de verantwoordelijkheid van beheer naar de Enterprise zelf door een xTR te plaatsen aan de grens van het netwerk, maar wel de mapping-system en proxy-services te gebruiken van de LISP-ISP. Dit is de meest gebruikelijke manier van LISP adoptie. Het plaatsen van een xTR aan de grens van het netwerk brengt in principe geen verandering aan het netwerk. Het enige waar rekening mee gehouden moet worden is dat de EID-prefix die gebruikt wordt voor het interne netwerk globaal uniek moet zijn. Dit wordt door bepaalde LISP-ISP’s geregeld door zelf EID-prefixes uit te delen in de vorm van PA-adressen, maar als een Enterprise zelf over een blok PI-adressen beschikt kunnen die ook gebruikt worden. Let wel, het interne netwerk hoeft niet perse omgenummerd te worden. Er kan ook gebruik worden gemaakt van NAT om het bestaande interne netwerk te transleren naar een IP-adres uit de gegeven EID-prefix. Dit is idee is ook ge??ntroduceerd bij thuisgebruikers van LISP. Door een /32 adres toe te kennen aan de xTR en een RFC1918 priv?? reeks te natten achter dat adres kan LISP functionaliteit gerealiseerd worden in een priv??-netwerk zonder dat daar een volledig publieke reeks aan toegekend hoeft te worden.
3. Optie drie, gemiddeld ingrijpend. De laatste adoptietechniek is voor Enterprises die over de middelen beschikken om een geheel eigen LISP omgeving op te zetten. Dit betekent dat naast het gebruikt van xTR’s als grensrouter bij alle vestigingen ook de mapping-system en proxy-router onder de verantwoordelijkheid van de Enterprise vallen. Dit is vergelijkbaar met ondernemingen die tussen alle vestigingen hun eigen private (internet)lijnen hebben.
Kosten
Voor het adopteren van LISP door Enterprises kan iets meer duidelijkheid worden gegeven over een inschatting van de kosten, omdat er ook daadwerkelijk partijen zijn die de service aanbieden in Nederland. Dat geldt alleen voor adoptietechniek twee. Er is ‘?n ISP in Nederland die voor 65 euro per maand een EID-prefix levert met daarbij het gebruik van zijn mapping-system en proxy-service. Wanneer hiervoor gekozen wordt moet nog wel zelf ‘?n of meerdere verbindingen bij ISP’s worden afgesloten. Oftewel de LISP-ISP levert in dit geval wel de EID’s maar niet de RLOC’s. Wanneer verder wordt gekeken naar de adoptie van LISP door Enterprises kom je uit op dezelfde factoren als bij ISP’s:
– Keuze van adoptietechniek
– Opensource software versus betaalde licenties
– Grootte van de onderneming
– In welke mate apparatuur kan worden hergebruikt

‘
Voor- en nadelen
Voor elke adoptietechniek zijn specifieke voor- en nadelen te benoemen. Deze zijn te vinden in tabel 8.4. De onderstaande opsomming geeft de voor- en nadelen weer die over het algemeen voorkomen bij de adoptie van LISP door Enterprises.
Voordelen:
– Geen BGP bij multihoming. Uit een gesprek met de oprichter van de enige LISP-ISP in Nederland is duidelijke geworden dat de grootste motivatie voor onderneming om voor LISP te kiezen het gebrek aan BGP is bij multihoming. Het gebruik van BGP is duur in apparatuur en onderhoud en daar zit niemand op te wachten. Door LISP te gebruiken kunnen die prijzen sterk worden teruggedrongen.
– IPv4/IPv6 support. LISP ondersteund standaard zowel IPv4 als IPv6. Hierdoor is het een interessante techniek voor Enterprises om de transitie naar IPv6 voor te bereiden met een redelijk kleine impact op de bestaande omgeving.
– VPN op basis van instance ID’s. De instance ID’s die standaard door LISP worden ondersteund kunnen worden gekoppeld aan VRF’s. Deze koppeling kan gebruikt worden om eenvoudig VPN’s op te zetten tussen vestigingen. Let wel, deze techniek is niet getest, omdat het buiten de grenzen van het onderzoek viel.
– Host mobility. Zolang aan de voorwaarden van VM/IP mobility wordt voldaan kan het een zeer krachtige techniek zijn voor ondernemingen die eindsystemen willen verplaatsen. Denk hierbij ook aan uitwijksituaties. Sessies blijven bestaan ondanks de (geografische) verplaatsing van een systeem.
Nadelen:
– Weinig ondersteuning. Officieel is er geen ondersteuning voor LISP. Alles gebeurt nog op vrijwillige basis. Dit kan voor partijen als Qi ict goed zijn aangezien zij extra onderhoudspraktijken kunnen verkopen, maar als Qi ict zelf niet het probleem kan oplossen is er geen directe partij waar hulp aan gevraagd kan worden.
– Globale EID-prefix. De prefix die gebruikt wordt moet globaal uniek zijn op het internet. Voorheen konden PI-adressen worden opgevraagd door LIR te worden bij de RIPE, maar dit is niet langer mogelijk. De enige optie is om PA-adressen op te vragen bij een LIR, maar daarvoor zal betaald moeten worden. Daarbij komt ook dat de voorraad PA-adressen snel slinkt. Tevens is het probleem met PA-adressen dat ze niet meegenomen kunnen worden naar een andere ISP. Dit werkt het concept van LISP tegen.
– IPv6. Het omslagpunt naar IPv6 komt steeds dichterbij. Wanneer dat moment komt blijft het hoofddoel van LISP wel relevant, maar zaken als IPv6 transitie en IP mobility worden minder interessant, omdat elke systeem dan een uniek IPv6-adres heeft. Het is de vraag of LISP dan nog wel interessant is om over te nemen.

TABEL 8.4 – VOOR- EN NADELEN VAN ADOPTIETECHNIEKEN ENTERPRISES
Optie ‘?n Optie twee Optie drie

Voordelen:
– Geen beheerverantwoordelijkheden. Die neemt de ISP voor zijn rekening. In theorie veranderd niets aan de manier waarop de onderneming nu een internetverbinding ontvangt. Er wordt slechts een internetverbinding afgenomen.
– Geen wijzigingen aan het netwerk in zowel hardware als software. Voordelen:
– Doordat de xTR nu aan de eigen omgeving is gekoppeld kan eenvoudig multihoming worden ingeregeld. Daarbij komen ook de voordelen van load balancing en prioriteit toekenning.
– Hoeft officieel geen verandering aan het netwerk te betekenen. De xTR kan aan de grens van het netwerk worden geplaatst.
– Intern geen kennis meer nodig van BGP, of apparatuur dat BGP ondersteund. Voordelen:
– Volledig netwerk in eigen hand. Een voorbeeld van de voordeel hiervan zijn uitwijksituaties. Door ‘?n regel te veranderen in de proxy-router en mapping-system kan je verbindingen van buitenaf naar een totaal andere locatie laten gaan.

Nadelen:
– De xTR verzorgt load balancing en prioriteit toekenning aan verkeer dat binnenkomt met een multihomed verbinding. Door de xTR bij de provider te plaatsen verlies je deze mogelijkheid. Hierdoor gaat ‘?n van de grootste voordelen van LISP verloren.
– Kosten zijn waarschijnlijk hoger dan een regulier consumentenlijn, omdat er een extra service geleverd moet worden in de vorm van een mapping-system en proxy-service. Nadelen:
– Geen specifieke nadelen voor deze adoptietechniek. Nadelen:
– Het opzetten van een eigen mapping-system en proxy-service vereist extra apparatuur. Daarnaast vereist het opzetten van een proxy-service ook BGP om routes te distribueren in het DFZ zolang LISP niet op globaal niveau totaal is overgenomen.

8.5.2 TOEKOMST VAN LISP
LISP is in 2006 bedacht als oplossing voor een probleem die de toekomst van het internet in gevaar brengt. Een voorbeeld om te bevestigen dat het probleem inderdaad aanwezig is, is het onlangs voorgekomen 512K-Day. Op 12/09/2014 bereikte het aantal routes in de tabellen van het DFZ een aantal van 512.000. Een aantal dat veel (oudere) TCAM-based netwerkcomponenten niet aan kon . Hierdoor gingen de routers oude routes verwijderen om ruimte te maken voor de nieuwe. Dit resulteerde in grote problemen bij ISP’s als Comcast, AT&T en Verizon. De partijen die verantwoordelijk waren voor de routers hebben het probleem snel weten te verhelpen door ouder apparatuur te vervangen met nieuwe, maar een oplossing als deze is natuurlijk niet permanent. Het is nu slechts een kwestie van tijd voordat het volgende limiet bereikt wordt.
Als we gaan kijken naar wat LISP over de afgelopen negen jaar heeft bereikt lijkt het de goede weg op te gaan. Inmiddels draait al een aantal jaar een stabiel b??ta-netwerk dat de voordelen van LISP demonstreert. Daarnaast wordt de interesse in het protocol op evenementen als CiscoLive steeds groter. Tevens zijn op het moment zeer veel verschillende implementaties van LISP actief, waardoor er voor iedere partij wat is. Een kleine opsomming van LISP implementaties is als volgt:
– Cisco IOS, IOS-XE, NX-OS, IOS-XR en Cat 6K
– LISPMob
– OpenLISP
– LISPLab
– Steffann LISP (Python implementatie)
Hoewel het draagvlak voor LISP in Nederland nog summier is met slechts ‘?n bekende partij die LISP-services levert, neemt het wereldwijd wel toe. Voorbeeld van publieke mapping-systems en proxy-services zijn NJEdge, Intouch, VxNET en het publieke b??ta-netwerk. Aan deze publieke systemen hangen inmiddels ruim honderd duizend LISP omgevingen.
In een gesprek met Cisco technical marketing engineer Gregg Schudel is duidelijk geworden dat LISP op het moment zeer veel aandacht krijgt binnen Cisco na jarenlange ontwikkeling. Daarnaast is onlangs bekend gemaakt dat de non-profit organisatie lispers.net samen met de partijen Arista, HP, Aruba en A10 een open netwerk voor LISP wil cre??ren. Dit is zeer goed nieuws, omdat de afgelopen jaren Cisco de enige netwerkfabrikant was die zich bezighield met LISP.
De bovenstaande berichten lijken een positieve toekomst voor LISP aan te geven. Het zal nog wel even gaan duren voordat de echte voordelen van LISP in het DFZ zichtbaar worden, maar acties zoals de 512K-Day helpen wel bij de bewustwording om het traject te versnellen.
Toch bestaan twijfels over de toekomst van LISP. LISP is een protocol en architectuur die het internet nodig heeft om te blijven werken. Als LISP, of iets soort gelijks, niet wordt ingevoerd neemt het aantal routes alleen maar toe en dat zal met IPv6 niet minder worden. Dit probleem leeft echter niet bij veel mensen. Het negeren van waarschuwingen over de 512K-Day is hiervan het bewijs. Als je dan ook bedenkt dat LISP vooral aan de man wordt gebracht met beloften over goedkope multihoming en IPv6 transitie wordt het hoofddoel van LISP voorbij gestreefd. Dit is erg jammer, want zo lang het probleem niet gaat leven bij ondernemingen zullen veel partijen het protocol niet serieus nemen met de reden dat ‘het bestaande netwerk al goed werkt zoals het is’. Er wordt echter vergeten dat een goed werkende DFZ noodzakelijk is voor het voortbestaan van het internet. Daarbij komt ook dat het internet officieel van niemand is. Het is een collectieve eigendom. Dat betekent dat er ook collectief gewerkt moet worden aan oplossingen.
‘
8.5.3 OORDEEL
LISP is een indrukkend protocol. De configuratie is eenvoudig, de mogelijkheden breed en de resultaten goed. Normaliter zou een bevestiging als deze voldoende zijn om een partij te adviseren het protocol te adopteren, maar dat ligt bij LISP een stuk ingewikkelder.
Technieken als multihoming en IPv6 transitie hebben tijdens het toetsen goede resultaten opgeleverd. Het advies om deze technieken te gebruiken zou dan ook positief zijn. Helaas is het gebruiken van alleen de techniek niet mogelijk. Als ‘?n onderdeel van LISP gebruikt gaat worden en een xTR wordt geplaatst in een netwerk, komt daar de algehele adoptie van LISP bij kijken. Wanneer een xTR wordt geplaatst betekend dat namelijk automatisch ook dat het gebruik van een mapping-system en proxy-service nodig is. Het draagvlak van deze twee onderdelen is op het moment nog summier. Dat geldt vooral voor Nederland waar slechts ‘?n partij deze service aanbiedt. Daarbij komt ook dat voor het protocol geen offici??le ondersteuning aanwezig is, omdat het beheer op het moment gebeurt door vrijwilligers van onder ander LISPMob en Cisco.
Om dit draagvlak te vergroten op de wereld zijn op het moment een aantal initiatieven in gang gezet. Onder andere het open control netwerk (OCN) van lispers.net in samenwerking met verschillende netwerkfabrikanten zal het draagvlak gaan vergroten. Daarbij komt ook dat de verschillende implementaties van LISP die zorgen voor beter hergebruik van apparatuur ook toenemen. Het is echter nog te vroeg om te zeggen of dit netwerk ook een succes wordt.
Een ander belangrijk punt is het feit dat LISP pas echt zin heeft voor het DFZ als het merendeel van de wereld ervan gebruik maakt. Tot die tijd is LISP niets meer dan extra routes die in de tabellen van het DFZ worden gedistribueerd met BGP. Als hierbij het feit wordt betrokken dat publieke IP-adressen nodig zijn voor het gebruik van LISP en deze zo goed als op zijn, is het de vraag of volledige adoptie van LISP ??berhaupt mogelijk is. Daarbij is nog niet eens gesproken over het feit dat alleen PA-adressen beschikbaar zijn, wat betekent dat bij het wijzigen van ISP de adressen niet meegenomen kunnen worden en dat werkt het concept van LISP tegen. Dit zou betekenen dat gewacht moet worden op IPv6, omdat iedereen dan publieke adressen krijgt, maar hoe lang IPv6 nog op zich laat wachten weet niemand.
Met de bovenstaande punten in gedachte kan een tweedelig advies worden gegeven. Het eerste advies is voor netwerken die op voorhand over alle nodige middelen beschikken en geen kritische apparatuur bevatten. Dit kunnen bijvoorbeeld vestigingen zijn van een Enterprise waar geen servers draaien en slechts een aantal werkplekken zijn die niet volledig afhankelijk zijn van een constante internetverbinding. Netwerken als deze zijn prefect voor het proberen van LISP en zullen bijdragen aan de evolutie van het protocol wat uiteindelijk leidt tot een breder draagvlak. Er wordt echter gerealiseerd dat een vestiging die niet afhankelijk is van een constante internetverbinding tegenwoordig niet veel meer voorkomt. Het tweede advies is voor alle andere netwerken waar wel kritische apparatuur draait. Als dit het geval is wordt geadviseerd om LISP niet te implementeren. Althans niet zo lang er geen offici??le ondersteuning bestaat. Als een partij toch LISP wil proberen wordt geadviseerd om een netwerk te gebruiken die schaduw draait. Hierdoor is het altijd mogelijk om terug te vallen op een andere netwerk als het protocol niet geschikt blijkt.
Ondanks dat het advies op het moment vooral nijgt naar het niet adopteren van LISP is het duidelijk dat LISP of een soortgelijke oplossing nodig is. Problemen zoals het 512K-Day bevestigen dat. Toch is LISP op het moment niet de antwoord op het probleem. LISP lijkt op het moment op een driedelig stappenplan waarvan stap twee ontbreekt. LISP heeft de tijd nodig om verder te evolueren en de komende jaren zullen daar een breekpunt voor zijn.

‘
9. CONCLUSIE & AANBEVELING
In hoofdstuk drie is een doelstelling geformuleerd die wordt onderbouwd door een aantal onderzoeksvragen. Deze vragen worden in dit hoofdstuk beantwoord. Aan de hand van deze vragen wordt bepaald of het onderzoek een succes is geweest. Verder wordt ook een aanbeveling voor Qi ict gegeven.
9.1 CONCLUSIE
1. Wat is het LISP protocol en welke problemen lost het op?
Wanneer twee eindsystemen een verbinding opstellen gebeurt dat op basis van IP-adressen. Dat IP-adres bepaald de identiteit van het systeem waarmee verbonden moet worden, maar het bepaald tegelijk ook de locatie, omdat het IP-adres gebruikt wordt om de juiste route te vinden. Dit concept bevat een conflict. Als het ene eindsysteem verplaatst, moet een compleet nieuwe route worden opgenomen, of het IP-adres moet worden veranderd. In een wereld waar eindsystemen per definitie mobiel aan het worden zijn heeft dit conflict voor voldoende problemen gezorgd. Het aantal routes in de BGP-tabellen van het DFZ heeft de 500.000 gepasseerd en dit aantal lijkt alleen maar te groeien. Terugdringen van dit aantal door middel van aggregatie wordt bemoeilijkt door het conflict tussen locatie en identiteit. Voor optimale aggregatie zou je namelijk willen dat identiteit topologie onafhankelijk is en locatie topologie afhankelijk. Wat het Locator/ID Separation Protocol (LISP) voorstelt is precies dat. Het idee is om elk eindsysteem twee adressen te geven, een endpoint identifier (EID) voor het bepalen van de identiteit en een routing locator (RLOC) voor het bepalen van de locatie. Door een koppeling tussen deze twee op te slaan in een database, het mapping-system, kan de druk op de BGP-tabellen worden verlicht door routes optimaal te aggregeren voor routering en niet langer voor identiteit. Naast het helpen bij het terugdringen van het aantal routes in het DFZ heeft LISP nog een aantal extra voordelen in de vorm van effici??nt multihoming, IPv6 transitie, VM/IP mobility en network virutalization.
2. Hoe werkt LISP en wat is nodig om het te kunnen implementeren in een netwerk?
Zoals hierboven is vermeld bestaat het concept voor LISP uit twee adressen. Het EID-adres voor identiteit en het RLOC-adres voor locatie. Wanneer een verbinding moet worden opgesteld met een eindsysteem wordt een IP-pakket aangemaakt zoals dat tegenwoordig ook standaard gebeurd met de EID-adressen als verzender en ontvanger. Wanneer het pakket de LISP-router aan de grens van het netwerk bereikt, wordt dat standaard IP-pakket voorzien van extra informatie. Er wordt door middel van encapsulation extra IP-informatie toegevoegd in de vorm van RLOC-adressen. Wanneer het pakket de router verlaat wordt het door middel van RLOC-adressen (optimaal) gerouteerd. Wanneer het pakket het eindpunt bereikt wordt de encapsulation verwijderd en blijft het standaard IP-pakket over waardoor connectie wordt opgesteld op basis van de EID-adressen. Kort samengevat wordt er connectie opgesteld door middel van EID-adressen, maar routering vindt plaats op basis van de RLOC-adressen. Dit heeft als voordeel dat wanneer een eindsysteem van locatie veranderd slechts een andere RLOC-adres moet worden toegevoegd tijdens het encapsulationproces. Voor de rest blijft het proces hetzelfde.
Om LISP te kunnen implementeren in een netwerk is het gebruik van een LISP-router (xTR) nodig in het netwerk, plus een mapping-system die zich overal op het internet mag bevinden en wordt gebruikt om de juiste RLOC-informatie bij een EID te vinden. Daarnaast is een proxy-LISP-router nodig bij het transitieproces om een verbinding te kunnen opstellen tussen wel- en niet-LISP omgevingen. Tevens is een belangrijk punt het feit dat zowel EID als RLOC-adressen op het moment nog globaal unieke adressen moeten zijn.
3. Wat is het verschil met bestaande routeringprotocollen?
Het grootste verschil met bestaande routeringsprotocollen is het feit dat LISP helemaal geen routeringsprotocol is. Dit is een misconceptie geweest, doordat bepaalde partijen van mening waren dat LISP BGP kon vervangen en daardoor aannamen dat LISP ook een routeringsprotocol was. LISP heeft onderliggende routeringsprotocollen zoals BGP en OSPF nodig om verkeer van A naar B te krijgen.
‘
4. Op welke manier vervangt LISP andere protocollen/tunnel mechanismen in bestaande technieken?
Hoewel LISP geen routeringsprotocol is, zijn tijdens het vergelijken met bestaande protocollen situaties naar voren gekomen waarin LISP bestaande routeringsprotocollen kan vervangen. Een opsomming van deze situaties is:
– LISP kan NAT en BGP vervangen in multihoming situaties door het gebruik van traffic engineering. Een LISP-router kan vooraf bepalen hoe hij verkeer wilt ontvangen als de router over meerdere lijn beschikt.
– LISP kan bestaande dualstack-, tunnel,- en translatietechnieken bij IPv6 transitie vervangen door het gebruikt van encapsulation. LISP ondersteund standaard IPv4-over-IPv6 en IPv6-over-IPv4.
– LISP kan route injection, mobile IPv4/IPv6 en DNS-based-redirection vervangen in bepaald situaties met VM/IP mobility.
– LISP kan MPLS vervangen in bepaalde situaties zoals het leveren van quality of service en opzetten van VPN’s door middel van zogeheten instance-id’s. Die worden toegekend aan netwerken en werken als een soort vlan-tag.
5. Voor welke omgevingen is LISP een geschikt protocol?
In het onderzoek is bekeken of LISP geschikt is voor ISP en Enterprise netwerken, maar daarover kon geen concrete conclusie worden gegeven. Het is wel duidelijk geworden dat de adoptie van LISP afhankelijk is van vier factoren:
– Keuze van adoptietechniek
– Opensource software versus betaalde licenties
– Grootte van de onderneming
– In welke mate apparatuur kan worden hergebruikt
Verder is wel het advies gegeven om LISP nog niet te adopteren in productienetwerken die over kritische apparatuur beschikken. De reden hiervoor is de experimentele aard van het protocol. Hoewel de testen indrukwekkende resultaten hebben opgeleverd is de draagvlak voor LISP nog erg summier. Er is slechts ‘?n partij die LISP services levert in Nederland en van echte ondersteuning is geen sprake, omdat alles nog werkt op basis van vrijwilligers.
– In hoeverre is het LISP protocol een verrijking voor het bestaande internetmodel?
Het huidige internetmodel heeft een serieus probleem. De grootte van BGP-tabellen loopt uit de hand en dat wordt bevestigd door gebeurtenissen zoals het reeds voorgekomen 512k-Day. Op 12 augustus 2014 bereikte de tabellen een grootte van 512.000, wat resulteerde in grote connectieproblemen bij ISP’s, omdat veel (oudere) systemen het aantal niet kon verwerken. Dit is tijdelijk opgelost met het vervangen van apparatuur, maar het is slechts een kwestie van tijd voordat zo’n dag weer voorkomt. Gebeurtenissen als deze bevestigen het feit dat een oplossing als LISP nodig is. Daarnaast is het gebruik van LISP toepasbaar in situaties waar al jarenlang hetzelfde gebeurt. Een voorbeeld is het gebruiken van BGP voor multihoming. Dit is een omslachtig en dure techniek, maar een goed alternatief was niet aanwezig. LISP kan de oplossing zijn en dat geldt voor meer situaties. Het zal dus gegarandeerd een verrijking zijn voor het bestaande internetmodel.
– Is het protocol interessant voor Qi ict en haar klanten?
Nee, dat is het niet. Het volledige advies te vinden in het adviesrapport, maar kort samengevat is het summiere draagvlak in combinatie met de benodigdheden een haast onmogelijk opgave voor Qi ict en haar klanten. De beschikbaarheid van het netwerk komt op de eerste plaatst en werken met LISP in de huidige vorm is niet te aan te raden. LISP moet verder evolueren voordat het een kans maakt.
Aan het begin van het onderzoek is de volgende doelstelling opgesteld:
‘Het doel is om voor 23 maart 2015 een onderzoek te hebben uitgevoerd dat Qi ict inzicht geeft in het gebruik en de implementatie van het LISP protocol in het bestaande internetmodel. Het onderzoek dient rapportage en een testopstelling op te leveren die als basis gaat fungeren voor het beter adviseren van klanten die ge??nteresseerd zijn in deze techniek’
De eerder beantwoorde onderzoeksvragen bewijzen dat het doel met succes is behaald. De rapportage en testopstellingen hebben resultaten opgeleverd die Qi ict beter inzicht geeft in het gebruik en de implementatie van LISP. Dat hieruit een negatief advies is voortgekomen is jammer, maar heeft verder geen invloed op het succes van het onderzoek. Met de gewonnen informatie kunnen klanten nog steeds geadviseerd worden. Het is ten slotte beter om te kunnen onderbouwen waarom een protocol/techniek niet geschikt is, dan zeggen dat je geen idee hebt wat het is. De opdrachtgever is het eens met deze strekking.
9.2 AANBEVELING
Het gegeven advies is duidelijk. LISP is nog niet geschikt voor Qi ict en haar klanten. Dit betekent echter niet dat het protocol volledig moet worden afgeschreven. Tijdens het uitvoeren van het onderzoek is ook bewezen dat LISP een bijzonder protocol is met veel mogelijkheden. Het feit dat er weinig draagvlak is voor het protocol werkt het tegen, maar daar wordt aan gewerkt. De aanbeveling dat uit het onderzoek naar voren komt is om over een half jaar nog eens naar het protocol te kijken. Tegen die tijd is het OCN van lispers.net verder uitgewerkt en zijn er wellicht partijen die officieel het protocol ondersteunen. ‘
10. EVALUATIE
Gedurende een periode van achttien weken heb ik mij bezig gehouden met een onderzoek naar LISP. Dit onderzoek heb ik uitgevoerd voor Qi ict. Het begin van het afstuderen was lastig. Er was binnen de organisatie weinig tot geen kennis over LISP en dat gold ook voor mij. Om die reden heb ik voorafgaand aan het onderzoek een korte voorstudie gedaan om genoeg kennis op te doen voor het opstellen van het probleemdomein. Op basis van deze informatie en wat gesprekken met de opdrachtgever heb ik een afstudeerplan geschreven waarin de probleemstelling en doelstelling van het onderzoek duidelijk zijn gemaakt. Dit is aan het begin van het onderzoek verder uitgewerkt in een plan van aanpak. Hierin heb ik onder andere een stakeholdersanalyse gedaan en aangegeven welke methode ik zou gaan gebruiken voor het onderzoek. Tevens heb ik een planning opgezet met daarbij ook wekelijks ingeplande momenten om met de opdrachtgever te vergaderen. Tijdens deze momenten hebben wij gesproken over de behoeften van Qi ict en indirect die van haar klanten. Deze behoeften zijn later omgezet tot een programma van eisen.
Voor het uitvoeren van het onderzoek heb ik gekozen voor het werken met de watervalmethode. Deze keuze heeft goed uitgepakt, omdat de flexibiliteit van het protocol ruimte bood voor literatuuronderzoek en productontwikkeling. Toch heb ik mijn twijfels of het model van Royce de juiste keus is geweest. Aan de ene kant heeft de methode voldaan aan de eisen, omdat het onderzoek succesvol is afgerond, maar achteraf gezien had het sashimi-model misschien betere keuze geweest. De reden hiervoor is het combineren van de implementatie- en testfase. Officieel laat het model van Royce geen overlap toe, maar omdat er niet meer apparatuur beschikbaar was ben ik gedwongen geweest deze fasen te combineren. Dit was verder geen probleem, omdat de flexibiliteit van de waterwalmethode zulke wijzigingen eenvoudig oplost, maar dit had ik wellicht van te voren moeten zien aankomen.
Over het onderzoek zelf ben ik zeer tevreden. Hoewel het jammer is dat een negatief advies is uitgegeven over het gebruik van LISP was het onderzoek ontzettend interessant. Ik heb ontzettend veel geleerd over LISP en alle zaken die daarbij kwamen, waaronder het werken met Cisco apparatuur. Tevens heb ik veel contact gehad met vakgenoten die werken bij grote bedrijven als Cisco en dat is als starter in het bedrijfsleven natuurlijk nooit verkeerd.
Het afstuderen zelf viel me wel wat tegen. Tijdens mijn opleiding TI heb ik verschillende projecten en onderzoeken uitgevoerd. Bij deze onderzoeken was het eindresultaat vaak al duidelijk en wist je gedurende het project wel redelijk of je op de goede weg zat. Met afstuderen is dat heel anders. Er zijn slechts vier contactmomenten en tijdens die momenten weet je nog steeds niet veel meer over de voortgang. Pas bij het tussentijds assessment wanneer de examinatoren de rapportage voor het eerst lezen krijg je wat duidelijkheid. Hierdoor ben je gewezen op je eigen kunnen en zal je op jezelf moeten vertrouwen dat je goed werk verricht. Dit brengt een onprettig gevoel met zich mee, omdat je constant bezig met idee??n verzinnen om je werk te verbeteren terwijl het eigenlijk al goed kan zijn.
Gedurende het onderzoek heb ik gewerkt aan een vijftal competenties:
– A1 ‘ Analyseren van probleemdomein
– A3 ‘ Achterhalen van behoeften van belanghebbenden
– C9 ‘ Ontwerpen van een infrastructuur
– D18 ‘ Testen van een infrastructuur
– H5 ‘ Zelfstandig werken
De competenties A1 en A3 heb ik bewezen door het schrijven van een plan van aanpak en het wekelijks voeren van diverse gespreken om de behoeften van Qi ict en indirect die van haar klanten te omschrijven in een programma van eisen. De competenties C9 en D18 heb ik bewezen door het schrijven van een ontwerprapport waarin een drietal opstellingen met bijbehorende testplannen zijn omschreven. De laatste competentie, H5, heb ik bewezen door proactief een goede aanpak te schrijven voor het uitvoeren van dit onderzoek. Uiteindelijk is de totale scriptie een toelichting op de manier waarop ik de competenties heb behaald, maar voor een specifieke analyse wordt verwezen naar ‘Externe bijlagen ‘ VII’. Hierin staan de competenties verder uitgewerkt.
‘
LITERATUURLIJST
APNIC, A. P. (2015, 01 01). Growth of the BGP Table – 1994 to Present. Retrieved 01 01, 2015, from http://bgp.potaroo.net/: http://bgp.potaroo.net/
AristaNetworks. (2015, 01 27). Arista Networks and lispers.net: An Open Control Network (OCN). Retrieved 01 27, 2015, from youtube.com: https://www.youtube.com/watch?v=hX4ToD53FRI
ASL BISL Foundation. (2015, 01 01). Template Testplan. Retrieved 01 03, 2015, from http://aslbislfoundation.org/: http://aslbislfoundation.org/?wpfb_dl=207
Cisco Systems. (2011). IPv6 transition and coexistence using LISP. -: Cisco Systems.
Cisco Systems. (2011, 01 01). Locator/ID Separation Protocol (LISP) Virtual Machine Mobility Solution White Paper. Retrieved from http://www.cisco.com: http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-693627.pdf
Cisco Systems. (2013, 03 19). LISP ESM Multihop Mobility. Retrieved 02 02, 2015, from http://www.cisco.com: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_lisp/configuration/15-mt/irl-15-mt-book/irl-lisp-esm-multihop-mobility.html
Cisco Systems. (2014, 04 24). LISP Hardware and Software Support. Retrieved 12 07, 2014, from lisp.cisco.com: http://lisp.cisco.com/lisp_hwsw.html
D. Farinacci, & Cisco Systems. (2013). Locator/ID Separation Protocol (LISP) Map-Server Interface [RFC6833]. -: IETF.
D. Farinacci, C. S. (2013, 01 01). The Locator/ID Separation Protocol (LISP) [RFC6830)]. IETF.
D. Meyer, L. Z. (2007, September 01). Report from the IAB Workshop on Routing and Addressing (RFC4984). Retrieved 12 03, 2014, from http://www.tools.ietf.org: https://tools.ietf.org/html/rfc4984
Florin Coras, D. S.-A.-P. (2012). Implementing a BGP-Free ISP Core with LISP. Global Communications Conference (GLOBECOM), 2012 IEEE (pp. 2772-2778). Anaheim, CA: IEEE.
Haagse Hogeschool. (1995). Ontwerp en ontwikkeling van systeem-/netwerkinfrastructuur. Onbekend: Onbekend.
Herrmann, D. (2013). Incoming Interdomain Traffic Engineering with LISP. Duitsland: Universiteit van Darmstadt.
Lisp4.net. (2015, 01 01). Locator/ID Separation Protocol. Retrieved from lisp4.net: http://www.lisp4.net/beta-network/
LISPMob. (2015, 01 01). An open-source LISP implementation for Linux, Android and OpenWRT. Retrieved 12 01, 2014, from lispmob.org: http://lispmob.org/
Luigi Iannone, D. S. (2011). Implementing the Locator/ID Separation Protocol: Design and Experience. Duitsland: Deutsche Telekom Laboratories.
M. Eubanks, P. C. (2013). IPv6 and UDP Checksums for Tunneled Packets [RFC6935]. -: IETF.
Manders, M. (2013, 10 10). Kwalitatief vs. kwantitatief onderzoek. Retrieved 11 23, 2014, from http://www.scribbr.nl: https://www.scribbr.nl/onderzoeksmethoden/kwalitatief-vs-kwantitatief-onderzoek/
Moreno, V. (2014). LISP – A Next-Generation Networking Architecture. Melbourne, Australie: CiscoLive.
NH Office of Information Technology. (2006). SYSTEM DEVELOPMENT METHODOLOGY (SDM). New Hampshire: NH Office of Information Technology.
Qi ict. (2015, 01 01). Over Qi ict. Retrieved 01 01, 2015, from http://www.qi.nl: https://www.qi.nl/over-qi-ict
Rijksuniversiteit Groningen. (2012, 10 30). Systematisch literatuur zoeken. Retrieved 11 26, 2014, from http://www.rug.nl: http://www.rug.nl/education/other-study-opportunities/hcv/schriftelijke-vaardigheden/voor-studenten/bronnen-literatuur/systematisch-literatuur-zoeken
RIPE, R. I. (2014, 14 17). Requesting Independent Resources. Retrieved 12 04, 2014, from http://www.ripe.net: https://www.ripe.net/lir-services/resource-management/independent-resources
Sogeti. (2014, 01 01). Dynamische Architectuur. Retrieved 11 21, 2014, from http://www.dya.info: http://www.dya.info/
The Open Group. (2014, 01 01). TOGAF?? – the Enterprise Architecture standard used by the world’s leading organizations to improve business efficiency. Retrieved 11 21, 2014, from http://www.opengroup.org: http://www.opengroup.org/subjectareas/enterprise/togaf
Waterfall Model. (2015, 01 01). ADVANTAGES, EXAMPLES, PHASES AND MORE ABOUT SOFTWARE DEVELOPMENT. Retrieved 11 21, 2014, from http://www.waterfall-model.com/: http://www.waterfall-model.com/

‘
BIJLAGEN
De volgende documenten zijn aanwezig in de externe bijlagen van het rapport.
I. Goedgekeurde afstudeerplan
II. Plan van aanpak
III. Programma van eisen
IV. Onderzoeksrapport
V. Ontwerprapport
VI. Adviesrapport + Testresultaten
VII. Aantonen competenties