Do s & don ts van Netflow

Do’s & don’ts van Netflow Onderzoek naar Netflow en impact op netwerknodes

St´ efan Deelen System & Network Engineering [email protected]

31 maart 2008

Inhoudsopgave 1 Introductie 1.1 Projectcontext . . 1.2 Doelstelling project 1.3 Onderzoeksaanpak 1.4 Opbouw document

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 1 1 2

2 Netflow achtergronden 2.1 Netflow architectuur . . . . . . . . 2.2 Probes of bestaande nodes? . . . . 2.3 ”Dataflow” vs. ”flow data” . . . . 2.4 Netflow versies en processing . . . 2.5 Netflow presentaties en statistieken 2.6 IPFIX . . . . . . . . . . . . . . . . 2.7 UDP, TCP, SCTP . . . . . . . . . 2.8 Exporteren van flow data . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 3 3 4 5 5 7 7 8

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Performance-impact meetmethode 10 3.1 Stelling: Vergelijkend meten! . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Uitgangspunt voor Netflow metingen . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Meer specifieke Netflow performance-impact metingen . . . . . . . . . . . . . 11 4 Testmiddelen en configuraties 4.1 Netwerknodes . . . . . . . . . 4.1.1 Gigabit router . . . . 4.1.2 Gigabit switch . . . . 4.2 Testservers . . . . . . . . . . 4.3 Software tools . . . . . . . . . 4.3.1 Iperf . . . . . . . . . . 4.3.2 Mgen en Harpoon . . 4.3.3 Ntop als collector . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

12 12 12 12 13 13 13 13 14

5 Resultaten Netflow metingen 5.1 Netflow verschilmeting: Throughput . . . . . . 5.2 Netflow verschilmeting: Jitter en pakketverlies 5.3 Metingen met ”Sampled Netflow” . . . . . . . . 5.4 Interpretatie van meetresultaten . . . . . . . . 5.5 SCTP, UDP en Ntop resultaten . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 15 15 16 16 17

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

6 Conclusies

19

7 Openstaande actiepunten

20

8 Bijlage 1, Voorbereidende performance-impact metingen 8.1 Aanpak verschilmetingen . . . . . . . . . . . . . . . . . . . 8.2 Host’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Router performance . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Forwarden zonder ASIC’s . . . . . . . . . . . . . . . 8.3.2 Performance-impact van kleine pakketten . . . . . . 8.4 Toevoegen van ”dure” router operaties . . . . . . . . . . . . 8.4.1 Toevoegen ”routing on a stick” . . . . . . . . . . . . 8.4.2 Toevoegen 802.1Q VLAN tagging . . . . . . . . . . . 8.4.3 Toevoegen van NAT, Network Address Translation .

1

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

21 21 21 22 23 23 25 25 25 26

9 Bijlage 2, Iperf Udp Netflow metingen 9.1 Pakketverlies zonder Netflow . . . . . 9.2 Pakketverlies met Netflow . . . . . . . 9.3 Pakketverlies met uitgebreide Netflow

en . . . . . .

resultaten 28 . . . . . . . . . . . . . . . . . . . . 28 . . . . . . . . . . . . . . . . . . . . 29 . . . . . . . . . . . . . . . . . . . . 29

10 Bijlage 3, Diverse (Netflow) metingen 10.1 Meetresultaten impact NAT . . . . . . . . . . . . . . 10.2 Config uitgebreide Netflow monitoring . . . . . . . . 10.3 Meetresultaten Netflow sampling . . . . . . . . . . . 10.4 Meetresultaten VLAN tagging . . . . . . . . . . . . . 10.5 Meetresultaten VLAN tagging en ’routing on a stick’ 10.6 Meetresultaten uitgebreide Netflow monitoring . . . 10.7 Fysieke setup . . . . . . . . . . . . . . . . . . . . . .

2

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

31 31 31 31 31 31 31 31

Samenvatting In dit rapport staan de resultaten beschreven van het onderzoek naar Netflow en de performanceimpact van toegevoegde Netflow-processing op bestaande netwerknodes. Dit onderzoek is een belangrijk praktijkonderdeel van het vak ’Large Installation Administration’ (LIA) wat binnen bepaalde kaders een vrije onderwerpkeuze tot onderzoek kent. Het vak LIA is ´e´en van de ’courses’ van de opleiding System and Network Engineering van de Universiteit van Amsterdam. De doelstelling van dit onderzoek is het verkrijgen en verschaffen van meer inzicht in Netflow eigenschappen in grootschalige netwerkomgevingen. Netflow is de industriestandaard waarmee de samenvattingen van dataflows die binnen netwerken verstuurd worden, ge¨exporteerd kunnen worden naar systemen ten behoeve van netwerkmanagement. In de geest van SNE zijn netwerkprotocollen gebaseerd op open standaarden. Daarom is in dit Netflow kader tevens gekeken naar een toekomstige open standaard als alternatief voor Netflow, nl. ”IPFIX” en het bijbehorende Stream Control Transmission Protocol. In het praktijk-deel van dit onderzoek is binnen een testomgeving gekeken naar de performance-impact van toegevoegde Netflow processing. Hieruit is gebleken dat de gevreesde performance-impact mee valt, en zelfs redelijk valt te voorspellen indien tijdens een implementatie een common sense benadering wordt toegepast. Uit het praktijk-deel van dit onderzoek kan geconcludeerd worden dat ”sampling” een geschikt middel is om het risico van een performance-impact te minimaliseren indien Netflow processing in grootschalige omgevingen dient te worden toegevoegd.

1

Introductie

1.1

Projectcontext

Het verkrijgen van inzicht in netwerkverkeer kan in grootschalige omgevingen een behoorlijke uitdaging zijn. De toenemende hoeveelheid dataverkeer binnen de vereiste criteria blijven forwarden is al moeilijk genoeg. Extra middelen toepassen ten behoeve van inzage in het verwerkte dataverkeer zoals bijv. netwerkprobes vormt een extra uitdaging. De netwerkrouters en switches zouden zelf ook deze probe functie kunnen vervullen. Een drempel is dat bestaande netwerken gedimensioneerd zijn op de vereiste netwerkcapaciteit. De kerntaak van netwerknodes, nl. het doorsturen van het dataverkeer, mag uiteraard niet gehinderd worden door dergelijke achteraf toegevoegde managementtoepassingen. Netflow is zo’n managementtoepassing dat ontwikkeld is om informatie over IP dataverkeer te kunnen verzamelen. Het is een open maar van origine proprietary protocol wat door Cisco Systems[4] ontwikkeld is en in de loop van de jaren is ge¨evolueerd tot een industriestandaard. Sinds het ontstaan van Netflow zijn er diverse, vergelijkbare flow monitorings technieken ontstaan, zoals bijv. sFlow [25] wat een vergelijkbare functionaliteit kent. Netflow geeft inzicht in hoeveel data er tussen de poorten van ge¨ıdentificeerde (netwerk)nodes wordt uitgewisseld, wat juist in grootschalige omgevingen een aantrekkelijk middel biedt om het netwerkgebruik inzichtelijk te krijgen. Deze informatie wordt weer voor diverse toepassingen gebruikt, enkele binnen het LIA1 kader relevante toepassing worden hieronder genoemd: • De door Netflow verkregen inzage maakt netwerk-optimalisatie mogelijk, omdat de verantwoordelijke bronnen voor een zekere overbelasting op een netwerk-link of node met Netflow ge¨ıdentificeerd kunnen worden. • Als op meerdere nodes in een netwerkdomein met Netflow inzage wordt verkregen, kan bijv. het gekozen pad door het netwerk in beeld worden gebracht. • En, ”last but not least” hier genoemd, volgende uit het voorgaande: Netflow informatie kan gebruikt worden om routeringsbeslissingen binnen een Traffic Engineered (TE) netwerk op te baseren. Met uiteraard als doel om de netwerkbelasting te distribueren. Deze distributiemethode ten behoeve van opschaling is getekend in fig. 1. Dit laatste punt maakt deze techniek tot een middel om de schaalbaarheid van een netwerkdomein te vergroten.

1.2

Doelstelling project

Het project ”Do’s & don’ts van Netflow” heeft als doelstelling het verkrijgen van meer inzicht in: 1. De werking van Netflow systemen, 2. Performance aspecten van netwerknodes indien met Netflow gerelateerde protocollen gewerkt wordt, 3. Bovenstaande twee punten door het doen van praktisch onderzoek ter beoordeling van Netflow en de performance-impact van toegevoegde Netflow processing.

1.3

Onderzoeksaanpak

In eerste instantie is gezocht naar eerder verricht onderzoek. Wat aan de hand van dit vooronderzoek interessant bleek, was het inzoomen op de laatste Netflow (gerelateerde) ontwikkelingen en deze toe te passen in de praktijk. Daarom wordt stilgestaan bij eigenschappen van SCTP2 , een relatief nieuw transportprotocol voor Netflow en bij IPFIX, de IETF3 standaard die is voortgekomen uit de laatste Netflow versie. 1 Large

Installation Administration, Universiteit van Amsterdam Control Transmission Protocol 3 Internet Engineerings Task Force 2 Stream

1

Figuur 1: sFlow[25] als middel voor opschaling binnen de Amsterdam Internet Exchange[2], om de capaciteit van de blauwe links naar behoefte aan te sturen.

Er is onderzoek gedaan naar Netflow processing en de mogelijke performance gevolgen voor bestaande netwerknodes. Er is getracht dit in de praktijk te onderzoeken binnen een testomgeving. Hierin zijn de volgende technologie¨en toegepast: Ntop[18] als Netflow collector, SCTP, een Cisco router als Netflow generator en gigabit netwerk-switch. Tevens is er NAT4 en een zogenaamde routing on a stick 5 configuratie toegepast. De open source tools Iperf[11], Mgen[13] en Harpoon[10] zijn onderzocht als middel om Netflow data te genereren; deze open source tools draaiden op een drietal servers met Ubuntu server als faciliterend Operating System.

1.4

Opbouw document

In hoofdstuk 1 is de projectcontext, doelstelling, onderzoeksaanpak en opbouw van dit document beschreven. In hoofdstuk 2 is de functionaliteit van Netflow en de evolutie die het heeft doorgemaakt beschreven. Eigenschappen van een Netflow of IPFIX implementatie met SCTP komen hier aan bod. Ook wordt gekeken naar eigenschappen van netwerkhardware en sofware die invloed op performance uitoefenen indien hier Netflow wordt toegevoegd. Hoofdstuk 3 poneert de gekozen meetmethodiek waarmee het praktijk-deel van dit onderzoek ingeluid wordt. Hoofdstuk 4 geeft de hierbij gebruikte tools en de configuraties weer. Hoofdstuk 5 geeft de meetresultaten van de uitgevoerde verschilmetingen weer, de diverse uitwerkingen staan in de bijlagen van dit document. Hoofdstuk 6 bevat de conclusies die volgen uit dit Netflow performance-impact onderzoek.

4 Network 5 Ook

Address Translation wel ’one-armed routing’ genoemd

2

2

Netflow achtergronden

Het lijkt wel of iedere netwerkleverancier een eigen Netflow variant ontwikkeld heeft voor de eigen systemen. Juniper Networks noemt haar oplossing ”Jflow”[12], en Huawei Technologies heeft het over Netstream [21]. Een open IETF[22] standaard, wat IPFIX is, lijkt wenselijk. Het was wenselijk dat deze open standaard centraal kon staan in dit document, echter de meeste apparatuur waarmee getest is, ondersteunde (nog) geen IPFIX. Omdat Netflow de grondlegger van deze technologie is, en ook omdat in dit onderzoek met Netflow getest is, wordt er in dit document voornamelijk bij Netflow stil gestaan. De nieuwste Netflow versie lijkt sterk op IPFIX, wat voornamelijk het gevolg is van het feit dat IPFIX hierop gebaseerd is.

2.1

Netflow architectuur

Het Netflow protocol biedt de mogelijkheid om real-time (bij benadering) te monitoren welke dataflows in het netwerk aanwezig zijn en wat hun status is. In paragraaf 2.4 wordt het Netflow protocol verder uitgelegd. Het protocol is het eenvoudigst uit te leggen indien het als een geheel monitorings-systeem gepresenteerd wordt. Dit Netflow systeem is geillustreerd in figuur 2, en wordt hieronder toegelicht. Het Netflow observatie punt is een locatie in het netwerk waar de IP pakketten gemonitord worden. Een flow record bevat informatie over een specifieke dataflow met daarin gemeten eigenschappen van die dataflow zoals het totaal aantal bytes of het aantal pakketten, etc. Het meetproces inventariseert pakket-headers, time-stamps en houdt zich bezig met het cre¨eren en updaten van flow records, het detecteren en verwijderen van niet meer geldige flow’s of het doorzetten van flow records naar een export proces. Het export proces stuurt gegenereerde flow records naar een collector proces. De collector is een proces wat flow records ontvangt van ´e´en of meerdere export processen. Dit proces krijgt de flow records naar zich toe ”gepushed”. De collector dient daarom over een snelle storage-, en over voldoende processing-capaciteit te beschikken. Dit is vooral gewenst indien de collector ook nog analyse-processing uitvoert zoals het berekenen van correlaties op de door verschillende netwerknodes aangeleverde flow records.

Figuur 2: Architectuur van Netflow / IPFIX

2.2

Probes of bestaande nodes?

Het observatiepunt kan een aparte netwerkprobe zijn, of een bestaande netwerknode die een extra functie nl. de monitoring en eventueel het exporteren van de waargenomen data, uitvoert. Een netwerkprobe inzetten vereist extra hardware, specifiek voor monitoring. Indien in een grootschalig netwerkdomein IP verkeer gemonitord moet worden, zijn er nogal wat probes nodig voor een totaaloverzicht van het dataverkeer in een domein. De gewenste implementatie zal afhankelijk zijn van het doel waar Netflow monitoring voor wordt ingezet.

3

Een aanpak waarin bestaande nodes worden uitgebreid met Netflow functionaliteit in de software, waarbij flow records worden ge¨exporteerd naar een centraal punt, schaalt beter dan het decentraal houden van flow data. Deze aanpak schaalt ook beter dan het toevoegen en toepassen van probe hardware. In figuur 3 is een oplossing ge¨ıllustreerd waarin flow data decentraal wordt gehouden en waarin dedicated probe hardware aan een bestaande netwerk node wordt toegevoegd. Het betreft een netwerk core-node waarin het collectieen exportproces intern plaats vindt, en van waaruit ook de presentatie vanuit de node zelf plaats vindt.

Figuur 3: Netflow monitoring per node

De node is hiertoe met extra hardware uitgerust, wat in feite een losstaand ge¨ıntegreerd Netflow systeem is. Deze probe monitor module heeft in dit geval (het betreft in figuur 3 een Cisco 650x multi-layer core-switch) een ingebouwde Http(s) daemon draaien ten behoeve van de presentatie van netwerkstatistieken. In het gepresenteerde overzicht wordt bijv. weergegeven welke IP adressen de toptalkers zijn die door deze node geforward worden. Door het beperkte perspectief van deze ene node wordt hier geen totaaloverzicht van dataflows in het netwerkdomein gepresenteerd. In dit document wordt hoofdzakelijk stilgestaan bij Netflow implementaties en effecten op netwerknodes zonder aparte probe hardware.

2.3

”Dataflow” vs. ”flow data”

Het is wenselijk om de exacte definitie van een dataflow te kennen. Deze definitie wordt gehanteerd door de IPFIX IETF werkgroep, en is leesbaar in diverse Netflow documentatie. Een dataflow is een unidirectionele verkeersstroom tussen een afzenderadres en een bestemmingsadres. Om preciezer te zijn, een dataflow wordt uniek gedefinieerd door de volgende zeven kenmerken: 1) 2) 3) 4) 5) 6) 7)

IP adres afzender, IP adres bestemming, Poortnummer afzender, Poortnummer bestemming, Laag 3 protocol type, TOS byte (Type Of Service), Logische inkomende interface.

Flow data bestaat uit ge¨exporteerde flow records die de oorspronkelijke dataflow beschrijven. Een toepassing van Netflow hoeft niet noodzakelijk flow data te exporteren. Netwerknodes bewaren dataflow informatie lokaal in een cachegeheugen, die lokaal uitgelezen kan worden door een System Administrator.

4

Indien er wel een export proces is toegepast, worden de gegevens in de vorm van flow records in een geconfigureerd interval ge¨exporteerd. Een collector verzamelt deze records die minimaal uit deze zeven kenmerken bestaan. Er kan ook extra info ge¨exporteerd worden, waaronder bijv. eigenschappen van de dataflow zoals het inmiddels verstuurde aantal pakketten, het aantal bytes, etc. De mate waarin extra aanvullende info exportabel is, is mede afhankelijk van de versie van Netflow.

2.4

Netflow versies en processing

Het belangrijkste verschil tussen de Netflow versies zijn de uitbreidingen in de nieuwere versies, waardoor meer informatie ge¨exporteerd kon worden. Enkele versies die voorafgegaan zijn aan de huidige Netflow v9, maar nooit zijn uitgebracht of uit de testfase zijn gekomen, zijn v2 tot en met v4, en v6. De laatste versie werkt ’template-based’ waarmee bedoeld wordt dat niet steeds nieuwe versies nodig zijn als er nieuwe informatie uit dataflows ge¨exporteerd moet kunnen worden. Een ander subtiel verschil bestaat uit de uitvoering van het exportproces en de wijze waarop het cachegeheugen[15] gebruikt wordt. De performance-impact zal dus per Netflow versie kunnen verschillen. Dit blijkt ook uit een performance analysis onderzoek [14] van Cisco Systems waarin de impact op de belasting van de router-CPU is onderzocht met verschillende Netflow versies. Er is in dit onderzoek niet gekeken naar de performanceimpact vanuit het gebruikersperspectief. Dataflows worden in netwerknodes vaak met behulp van ASIC[24] hardware geforward wat grote performance voordelen biedt. Dit is pas mogelijk indien aan de hand van het eerste datapakket het pad is opgezocht in de routetabel. Deze initi¨ele bewerking vereist de hulp van de ’general-purpose’ router-CPU. Indien dataflows steeds uniek van aard en kortdurend zijn, zal daarom de forwarding veel meer rekenkracht van netwerknodes vragen dan wanneer dit niet het geval is. In dit onderzoek wordt aangenomen dat een dergelijke manier van het afhandelen van dataflows ook bij Netflow processing geldt. Het eerste pakket van een dataflow vereist een detectie die een registratie tot gevolg heeft. De Netflow metingen die volgen ten behoeve van het bijhouden van de dataflow administratie, worden waarschijnlijk met behulp van ASIC’s uitgevoerd. Hoe dit precies in zijn werk gaat, is afhankelijk van interne processen die bepaald zijn door leveranciers van de apparatuur. Voor zover mogelijk valt het buiten het doel van dit onderzoek om de wijze van Netflow processing voor een specifiek apparaat van een specifieke leverancier te onderzoeken. Dat Netflow performance-impact hebben kan, blijkt uit de mogelijkheid die leveranciers bieden tot het toepassen van ”sampled Netflow”. Niet van ieder pakket worden dan de eigenschappen geadministreerd, maar alleen van ieder ”n”-de pakket waarbij ”n” een instelbaar getal is. Ook bestaat er de mogelijkheid om Netflow een beperkt, geselecteerd aantal interfaces van de netwerknode te laten monitoren. Uit eerder verricht performance impact onderzoek, [14], blijkt logischerwijs dat het activeren van Netflow processing zonder dataverkeer enkele procenten router-CPU vereist. Naarmate er meer simultane dataflows geforward dienen te worden, zal de belasting op de router-CPU toenemen, maar indien tevens Netflow processing is geactiveerd, neemt de belasting op de router-CPU dubbel zo snel toe. Er is in dit [14] onderzoek niet gekeken naar de uiteindelijke performance-impact vanuit het gebruikersperspectief.

2.5

Netflow presentaties en statistieken

In de introductie is traffic engineering genoemd waar Netflow monitoring een handig middel voor is. Monitoring kan allerlei doeleinden dienen, vari¨erend van security, planning, accounting, etc. Doordat het export proces van Netflow het mogelijk maakt om vanuit een gecentraliseerd punt te overzien via welke nodes individuele dataflows gerouteerd worden, en wat de hoeveelheid data is, kunnen netwerkpaden en routes geoptimaliseerd worden. Er zijn vele andere large scale toepassing mogelijk.

5

Figuur 4: Mogelijk met Netflow

De ge¨ınventariseerde dataflow informatie kan bijvoorbeeld, zoals in fig 4 zichtbaar is, op kunstzinnige wijze gepresenteerd worden, of voorzien in allerlei management rapportages. De illustratie in figuur 4 is een voorbeeld van een grootschalige publieke toepassing, waarin Netflow kan bijdragen. Het betreft de New York Talk Exchange[16] expositie. Dit is een promotieproject van AT&T wat weergeeft met welke steden New York ’Voice over IP’ telefoongesprekken onderhoudt.

Figuur 5: Flowscan en Netflow maken korte- en lange termijn trends inzichtelijk

Indien de juiste presentatie-tools gebruikt worden, kunnen de mooiste plaatjes gegenereerd worden. Figuur 5 geeft een voorbeeld van ”Flowscan”[8] waarmee het effect van de lunchtijd en de vakantieperiode op het netwerkgebruik zichtbaar is gemaakt door het aantal dataflows in een grafiek uit te zetten. Wat allemaal gepresenteerd kan worden met Netflow informatie, is afhankelijk van wat Netflow exporteert naar de collector. Zoals in paragraaf 2.4 beschreven stond, is Netflow v9 template-based en dus in staat datgene te exporteren wat door de probe of exporter aan informatievelden kan worden ge¨exporteerd. De mogelijke flow records zijn tenslotte uitbreidbaar. De documentatie van de applicatie ”nProbe”, [17], die als losstaande exporter fungeert, geeft een uitgebreid overzicht van ruim 100 denkbare, te exporteren flow records, vari¨erende van MAC adressen tot TCP fingerprints. De uiteindelijke functionaliteit die Netflow monitoring biedt, wordt dus niet begrensd door beperkingen van het Netflow v9 protocol, maar door

6

de presentatie-beperkingen van de collector-applicatie of van export beperkingen. Vandaar ook dat er zo’n ruime keuze, (zie [9] of [1]), uit verschillende Netflow monitor applicaties bestaat: Deze dienen elk vaak een ander, specifiek doel. De applicatie ”Ntop” [17] fungeert als centrale collector voor aangeleverde Netflow flowdata en is tevens in staat volledige monitoring toe te passen op (”gemirrord”) dataverkeer. Met Ntop kunnen zodoende meerdere netwerkomgevingen gemonitord worden op ´e´en centrale plaats met per netwerkomgeving (of netwerkzone) een specifieke, gekozen fijnheidsgraad. Een voorbeeld hiervan is te zien in figuur 6 waarin iedere taartpunt de netwerkload per omgeving aangeeft. Deze Ntop resultaten zijn verkregen als gevolg van testen die later in dit document beschreven worden.

Figuur 6: Collector Ntop, linksboven: load per zone, onder: toptalkers per zone, rechtsboven: specifieke toptalker.

2.6

IPFIX

”IPFIX”staat voor Internet Protocol Flow Information eXport en is de gestandaardizeerde versie van Netflow v9. Het heeft alle eigenschappen van Netflow v9 en op het vlak van security en transport enkele extra richtlijnen. In dit kader is een opmerkelijk item in de IETF IPFIX beschrijvingen de verwijzing naar het SCTP transport protocol, daarom wordt in de volgende paragraaf dieper op SCTP ingegaan. De in paragraaf 2.1 en 2.4 beschreven Netflow architectuur en eigenschappen zijn dus ook op IPFIX van toepassing. In dit IETF document, [6], is een vraag en antwoord dialoog tussen de IPFIX IETF werkgroep en Cisco Systems weergegeven waaruit blijkt dat voor de IPFIX standaard Netflow v9 als uitgangspunt gebruikt is.

2.7

UDP, TCP, SCTP

Naast UDP en TCP is er een relatief nieuw transportprotocol beschikbaar, nl. het Stream Control Transport Protocol [26]. De IETF IPFIX werkgroep stelt dat IPFIX implementaties 7

met zowel UDP, TCP of met SCTP mogelijk zou moeten zijn, maar geeft aan dat SCTP preferabel is. Veel software ondersteunt nog geen SCTP, maar indien dit wel het geval is kan er een keuze gemaakt worden. Dit SCTP protocol is ontwikkeld als general-purpose ”message oriented” protocol wat voor signaling protocollen die bijv. binnen Voice over IP[3] toegepast worden, een onmisbare eigenschap is. Een eigenschap van ”message oriented” is dat indien een berichtje van slechts enkele bytes door een applicatie verstuurd wordt, dit berichtje niet eerst geaggregeerd wordt, voordat deze door het netwerk wordt verstuurd en afgeleverd. Er vindt bij SCTP in principe geen aggregatie plaats voordat de informatie het netwerk opgestuurd wordt. Dit mechanisme is vergelijkbaar met UDP.

Figuur 7: SCTP vs. TCP handshake en SCTP multi-homing SCTP is een betrouwbaar transportprotocol omdat het verloren gegane en gedupliceerde pakketten detecteert en volgorde garantie voor bezorgde pakketten biedt. Naast deze eigenschap biedt het ook flow-, en congestie-controle mechanismen die ook in TCP terug te vinden zijn. SCTP verenigt dus eigenschappen van UDP en TCP, maar biedt ook extra’s zoals multi-homing en multi-streaming [3] waarmee de beschikbaarheid van netwerktoepassingen vergroot wordt. Binnen TCP geldt dat een connectie bestaat tussen sockets - een combinatie van IP adres met een TCP poort - maar binnen SCTP wordt een connectie-eindpunt geassocieerd met een cookie. De connectie is als gevolg van deze associatie niet meer gebonden aan een IP adres waardoor fail-over naar een aanwezig secondairy IP adres van een multi-homed host zonder connectieverlies mogelijk wordt. Figuur 7 verduidelijkt dit. Hierin is ook te zien dat de connectie-setup uit een 4-way handshake bestaat, in tegenstelling tot de 3-way handshake van TCP. SCTP ondersteunt meerdere streams per eindpunt associatie. Deze streams zijn onafhankelijk van elkaar en allen gerelateerd aan de associatie (cookie). Als een stream faalt, bijv. blokkeert, dan heeft binnen TCP dit tot gevolg dat een volledig nieuwe connectie opgezet dient te worden. SCTP zal een dergelijk probleem effici¨enter kunnen oplossen door de bredere interactie die mogelijk is door bijv. op een andere stream over te stappen. SCTP kent ook een nadeel indien het toegepast wordt in de Netflow context: De protocoloverhead is groter in vergelijking tot TCP of UDP. Dit kan relevant zijn indien enorme hoeveelheden dataverkeer gemonitord worden door Netflow en vervolgens via IPFIX of Netflow ge¨exporteerd naar een collector.

2.8

Exporteren van flow data

Het exporteren van flow records heeft tot gevolg dat er naast de Netflow monitoring, weer extra processing plaats vindt op een netwerknode. Ook heeft dit tot gevolg dat er extra dataverkeer gegenereerd wordt welke een belasting op het netwerk vormt. In eerder verricht onderzoek[7] is gekeken naar de verhouding tussen het gemonitorde dataverkeer vs. de ge¨exporteerde Netflow - ’samenvatting’ daarvan. In figuur 8 staan meetresultaten die weergegeven dat Netflow v5 meer verkeer genereert dan Netflow v9. Ook blijkt dat IPFIX nagenoeg dezelfde hoeveelheid verkeer genereerd als Netflow v9, waaruit mede blijkt hoe dicht die versies bij elkaar liggen. Deze metingen betreffen verschilmetingen waarin alle 8

factoren zijn vastgezet, met als variatie alleen de Netflow versies. Wat tevens interessante

Figuur 8: Dataflow vs. flow records, verschillende Netflow versies.

metingen in het kader van dit onderzoek zijn geweest, is het effect van de grootte van de datapakketten van de gemonitorde dataflow op de hoeveelheid ge¨exporteerde IPFIX data. In figuur 9 staan meetresultaten van drie metingen met dataflow pakketten van 45, 90 en 450 bytes, waaruit blijkt dat naarmate de pakketten van de dataflows kleiner zijn, er meer flow data ge¨exporteerd wordt.

Figuur 9: Verhouding tussen hoeveelheid flow data en pakketgrootte van dataflows.

De gemeten overhead is mede afhankelijk van het gebruikte transport protocol. TCP kent meer overhead dan UDP, maar SCTP kent nog meer overhead dan TCP. Deze metingen zijn uitgevoerd op UDP verkeer tussen de IPFIX exporter en collector. Indien SCTP was toegepast, was deze overhead factor (laatste kolom) nog meer toegenomen. Door dit onderzoek is er meer inzicht verkregen in de effecten waar rekening mee moet worden gehouden indien een groot aantal netwerknodes flow data exporteren naar een centrale collector. In sommige grootschalige omstandigheden zal het daarom wenselijk zijn om de flow data out-of-band [19] te exporteren.

9

3

Performance-impact meetmethode

In dit onderzoek is de performance-impact van Netflow processing binnen een testopstelling onderzocht. In dit hoofdstuk wordt de toegepaste meet-methodiek binnen deze opstelling beschreven, waarmee de impact op het functioneren van een router inzichtelijk gemaakt is. Een geschikte meet-methodiek maakt verschilmetingen tussen onderling verschillende Netflow configuraties mogelijk.

3.1

Stelling: Vergelijkend meten!

Een netwerkgebruiker ervaart het netwerk als een ”black box”, en daarom wordt er gemeten aan de voor netwerkgebruikers meetbare performance-indicatoren ”delay”, ”jitter”6 , pakketverlies en ”throughput”7 van het netwerk. Gesteld wordt, dat een methode met verschilmetingen tussen omstandigheden zonder vs. met Netflow nodig is, om inzicht te krijgen in de performance-impact van toegevoegde Netflow processing. Performance-degradatie (zichtbaar vanuit het gebruikersperspectief), zal in het praktijkdeel van dit project onderzocht en- bewezen worden gedurende verschilmetingen aan de hand van de ”delay”, ”jitter”, pakketverlies en ”throughput” indicatoren. Uitgangspunt is, dat vanuit het gebruikersperspectief er pas echt performancedegradatie waarneembaar wordt, indien de toegevoegde Netflow processing tot een significant hogere en een (bijna) volledige router-CPU belasting leidt, omdat dat zich mogelijk vertaald in een waarneembare verandering van de genoemde performance indicatoren. In hoofdstuk 8 (bijlage 1) wordt de zoektocht naar een geschikt uitgangspunt beschreven. In deze bijlage staan voorbereidende metingen en resultaten beschreven die uitgevoerd zijn, om inzage in het effect van extra processing op de router performance te begrijpen. Deze extra processing maakt de uiteindelijke Netflow metingen makkelijker omdat de rekenkracht van traffic generators niet op kunnen tegen de capaciteit van de gigabit router wat wordt beschreven in paragraaf 8.2 en 8.3.2. Het voorgestelde startpunt voor de verschilmetingen is dus in feite een netwerkomgeving die al flink (over)belast is. Door de router voor ieder datapakket bewerkingen zoals NAT en VLAN tagging uit te laten voeren, is dit uiteindelijk bereikt. Indien Netflow processing impact heeft, wordt het in deze omstandigheden in dit gevonden uitgangspunt snel zichtbaar. Het mag duidelijk zijn dat indien een router in een productie-omgeving zich in dergelijke omstandigheden bevindt, het tijd is voor een (hardware) upgrade.

3.2

Uitgangspunt voor Netflow metingen

Als uitgangspunt is de meetopstelling die weergegeven wordt in hoofdstuk 4 in fig. 10 gebruikt. In de meting in figuur 22 blijkt een NAT configuratie een startsituatie mogelijk te maken voor de gewenste Netflow verschilmetingen. Dit blijkt uit meetresultaten, weergegeven in de bijlage in fig. 3.1. De impact van NAT blijkt een handig middel om de impact van toegevoegde Netflow processing zichtbaar te maken vanuit het gebruikersperspectief. De tijdens de voorbereidende metingen gerapporteerde TCP throughput door het meettool Iperf8 , blijkt nu als gevolg van NAT gedaald te zijn van gigabit lijnsnelheid tot rond de 590Mbps, zie paragraaf 26. De router-CPU is tijdens deze meting in deze configuratie volledig belast, ondanks dat er in ASIC’s9 geforward wordt. De throughput is desondanks nog aanzienlijk. 6 Jitter

is de onderlinge variatie in de transmissietijd tussen de verstuurde datapakketten of doorvoer, die beperkt wordt door de lijnsnelheid of door de processing capaciteit van

7 Throughput

nodes 8 Iperf wordt beschreven in par. 4.3.1 9 Application Specific Integrated Circuit, gespecialiseerde hardware

10

Een typisch praktijkscenario van een overbelaste router die (bijna) aan vervanging toe is. Extra operaties toevoegen, waaronder bijv. Netflow monitoring, kan in dit uitgangspunt een hevige performance impact tot gevolg hebben.

3.3

Meer specifieke Netflow performance-impact metingen

Het dataverkeer wat door routers geforward wordt, is divers van aard en bestaat meestal niet uit ´e´en dataflow. Stress-testen zouden deze diversiteit moeten simuleren om de werkelijke performance-impact van Netflow processing nog beter waar te kunnen nemen. Een dergelijke diversiteit biedt, vergeleken met de belasting door ´e´en enkele dataflow, een betere real-life benadering omdat de vereiste ”lookups” in de routing tabel door verschillende simultane dataflows de router-CPU belasting extra opvoeren. Dergelijke complexe simulatie-metingen kosten echter veel tijd, maar de meetresultaten zijn dan wel representatiever. Indien Netflow in zo’n situatie tevens actief is, zullen deze vari¨erende lookups waarschijnlijk ook extra belastend zijn door de extra Netflow processing die er dan nog eens bij komt. Een meting van het pakketverlies en van de ontstane jitter is waarschijnlijk ook wenselijk in diverse Netflow omstandigheden. Hier is het tool Iperf wel zeer geschikt voor: Zo’n Iperf meting bestaat uit het uitsturen van UDP pakketjes met een afgemeten snelheid van Iperf client naar server, waarbij de Iperf server aan de hand van het tijdstip van de binnenkomende pakketten de jitter waarneemt. Deze test is misschien interessant in combinatie met de veroorzaakte stress door Netflow en andere processing. Afhankelijk van de beschikbare tijd wordt er naar andere tools naast Iperf gekeken om real-life scenario’s meer te kunnen benaderen.

11

4

Testmiddelen en configuraties

Voor het praktische gedeelte van het onderzoek naar performance implicaties, wat in de volgende hoofdstukken bewchreven staat, staan diverse middelen ter beschikking. In dit hoofdstuk worden deze middelen genoemd en de functie die ze in de testomgeving zullen vervullen.

4.1

Netwerknodes

Het onderwerp waarop de testen van toepassing zijn, zijn de netwerknodes waar de Netflow processen geactiveerd zijn. In dit praktijkdeel is er met ´e´en node getest van het type Cisco 3825. Dit apparaat is anno 2008 nog in Cisco’s productenportfolio aanwezig. Deze router beschikt niet over specifieke probe hardware zoals weergegeven in figuur 3. Het apparaat is met twee gigabit interfaces uitgevoerd, echter de routing processing capaciteit is beperkt tot een maximum forwarding snelheid van 179,20Mbps van datapakketten met een grootte van 64 bytes. Bron Cisco, [5]. De uitgevoerde performance testen hebben een relatief karakter en geenszins als doel om de meegeleverde specificaties te verifi¨eren. De wijze waarop de testen zijn uitgevoerd, levert ook een ongeldige verificatie op: Er worden in dit kader dus geen conclusies getrokken. Het ge¨ınstalleerde IOS10 beschikt over ondersteuning voor Netflow v9 en SCTP. In de bijlage in figuur 34 en 35 is de fysieke apparatuur weergegeven. 4.1.1

Gigabit router

Router>sh ver Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(15)T3, RELEASE SOFTWARE (fc1) ***skipped*** Compiled Thu 24-Jan-08 23:00 by prod_rel_team ***skipped*** System image file is "flash:c3825-advipservicesk9-mz.124-15.T3.bin" ***skipped*** Cisco 3825 (revision 1.1) with 224256K/37888K bytes of memory. Processor board ID FCZ103373F5 4 FastEthernet interfaces 2 Gigabit Ethernet interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity enabled. 479K bytes of NVRAM. 62720K bytes of ATA System CompactFlash (Read/Write) ***skipped*** 4.1.2

Gigabit switch

Een gigabit switch is gebruikt om het testen makkelijker te maken. Van de 2 gigabit koppelingen van bovengenoemde router diende er ´e´en via fiber ontsloten te worden om de gigabit speed beschikbaar te krijgen. De gigabit interface kaarten in de Vigor servers zijn UTP gebaseerd, de switch heeft dit probleem overbrugd. Ook geeft de inzet van de switch meer configuratie flexibiliteit wat zal worden beschreven in paragraaf 8.4. Switch>sh ver Cisco IOS Software, Catalyst 4000 L3 Switch Software (cat4000-I9S-M), Version 12.2(25)EWA11, RELEASE SOFTWARE (fc1) ***skipped*** Compiled Thu 25-Oct-07 16:10 by kellythw ***skipped*** 10 Internetworking

Operating System, OS van de router.

12

System image file is "bootflash:cat4000-i9s-mz.122-25.EWA11.bin" cisco WS-C4948 (MPC8245) processor (revision 0) with 262144K bytes of memory. Processor board ID FOX1203G905 MPC8245 CPU at 266Mhz, Fixed Module Last reset from Reload 3 Virtual Ethernet interfaces 48 Gigabit Ethernet interfaces 511K bytes of non-volatile configuration memory. ***skipped***

4.2

Testservers

Een drietal servers zijn gedurende de testen als testmiddel gebruikt voor het genereren en aanbieden van dataflows via een gigabit koppeling. Van de onderstaande servers, nl. Vigor157, Vigor158 en Vigor159 is de lichtste, Vigor157, niet als traffic generator geschikt gebleken. Deze is als Netflow collector geconfigureerd. hostname=vigor159, distro=gutsy-server, 2.6.22-14-server HP proliant system dl360 G3, cpu: 2,4ghz/533Mhz, (p4) 512kb cache gig_eth0= dhcp internet/management, gig_eth1 = productie hostname=vigor158, distro=gutsy-server, 2.6.22-14-server COMPAQ proliant 4Gig DRam, 2 cpu’s: 1,4ghz/133mhz, (p4) 512kb cache gig_eth4 = dhcp internet/management (slot 3 -niet de poort aan de buitenkant-, gig_eth5 = productie hostname=vigor157, distro=gutsy-server, 2.6.22-14-server COMPAQ proliant 3Gig DRam, cpu: 1,4ghz/133mhz, (p3!) 512kb cache gig_eth0 = dhcp internet/management, gig_eth1 = productie

4.3

Software tools

De volgende open source tools zijn gebruikt om dataverkeer te genereren of ge¨exporteerde flow records te collecteren. 4.3.1

Iperf

”Iperf” [11] is een veel gebruikt testtool wat TCP en UDP datastreams kan genereren en de throughput meet van het tussenliggende netwerk. Iperf is in C++ geschreven en bestaat uit een client en server deel. Met Iperf kan de grootte van TCP en UDP datapakketten ingesteld worden. Iperf wordt in dit onderzoek gebruikt voor maximum throughput en jitter metingen. Om in deze context een preciezere inzage in performance impact te verkrijgen is uiteindelijk een real-life benadering wenselijk waarin simultane -, en onderlinge verschillende dataflows aan een router worden aageboden. 4.3.2

Mgen en Harpoon

”Mgen” [13] is een testtool wat UDP traffic patronen via scripts kan aanbieden. Mgen’s voordeel ten opzichte van Iperf is dat het script gescheduled de belasting kan opvoeren. Mgen is in staat op gecontroleerde wijze variatie aan te brengen in de frequentie en in de pakketgroottes van de verstuurde pakketten. Ook simultane dataflows zijn mogelijk die weliswaar elk handmatig in het script geconfigureerd moeten worden. Het gemeten resultaat kan vervolgens (real-time) geplot worden in grafiekjes. Een resultaat van een verschilmeting zou zo mooi gepresenteerd kunnen worden. ”Harpoon” [10] is een ”flow-level” traffic generator. Dit geavanceerde tool kan real-life verkeerspatronen benaderen door vari¨erende dataflows te genereren. Deze variatie kan bereikt worden door als input Harpoon van historische Netflow logdata te voorzien. Een alternatief

13

is om deze ”self-configuration” mogelijkheid niet te gebruiken, maar XML scripts te gebruiken als input voor Harpoon. Als hier tijd voor is, zal onderzocht worden of dit tool nieuwe inzichten kan opleveren. 4.3.3

Ntop als collector

Ntop [18] is ´e´en van de vele open source Netflow presentatie-tools waarmee inzage in het netwerkgebruik wordt geboden via een Web server. Ntop ondersteunt o.a. Netflow v9, IPv6 en IPFIX. De flow records worden vanuit de netwerknodes gepushed naar de Ntop collector. Voor de opslag van de aangeboden data wordt RRDtool 11 [20] gebruikt wat voorziet in ”high performance data logging”.

Figuur 10: Configuratie van ingezette testmiddelen

11 RRD-tool:

Round-Robin Database tool

14

5

Resultaten Netflow metingen

In dit hoofdstuk worden de uitgevoerde Netflow verschilmetingen en de resultaten daarvan beschreven. Eerst worden metingen beschreven zonder Netflow, vs. met Netflow, vs. het toevoegen van ”uitgebreide” Netflow monitoring. Vervolgens worden metingen en resultaten van ”sampled” Netflow beschreven. In deze metingen is er niet gesampled en is er niet ge¨exporteerd. Nadien volgen metingen met sampelen en exporteren in paragraaf 5.3 en 5.5.

5.1

Netflow verschilmeting: Throughput

In het vorige hoofdstuk in par. 3.2 en in fig. 26, zagen we max. throughput resultaten zonder Netflow in de NAT context met een gemiddelde van ongeveer 590Mbps. Netflow wordt nu geactiveerd door op de router-interfaces ”ip route-cache flow” toe te passen. Tijdens de througput-meting wordt deze Netflow activatie toegepast hetgeen de degradatie meteen zichtbaar maakt. In fig. 11 is in de Iperf rapportage zichtbaar dat ruim 12% throughput in deze TCP meting in deze NAT omstandigheid verloren gaat doordat op de 7e seconde Netflow geactiveerd wordt. root@Vigor159:~# iperf -c 100.0.0.158 -t 9000 -m -i 2 -----------------------------------------------------------Client connecting to 100.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 43875 connected with 100.0.0.158 port 5001 [ 3] 0.0- 2.0 sec 141 MBytes 593 Mbits/sec [ 3] 2.0- 4.0 sec 141 MBytes 593 Mbits/sec [ 3] 4.0- 6.0 sec 140 MBytes 587 Mbits/sec [ 3] 6.0- 8.0 sec 128 MBytes 535 Mbits/sec [ 3] 8.0-10.0 sec 123 MBytes 515 Mbits/sec [ 3] 10.0-12.0 sec 123 MBytes 514 Mbits/sec [ 3] 12.0-14.0 sec 123 MBytes 517 Mbits/sec [ 3] 14.0-16.0 sec 123 MBytes 517 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) Figuur 11: Impact door activeren Netflow (in de 7e sec.)

Vervolgens wordt op de router de Netflow monitoring uitgebreid, door extra eigenschappen van de dataflows te monitoren. Deze Netflow configuratie die aan de router is toegevoegd, is te lezen in bijlage 10 in paragraaf 10.2. Deze extra Netflow monitoring zorgt opnieuw voor impact met wederom een verminderde throughput tot gevolg. De meetrapporten staan in deze bijlage in figuur 29. De met Iperf gemeten throughput is inmiddels in deze TCP testen (refererende aan de uitgangssituatie in paragraaf 26), als gevolg van de Netflow monitoring inmiddels verminderd in twee stappen van 593Mbps naar 517Mps, en door de Netflow uitbreiding vervolgens naar 452Mbps. Deze Netflow processing heeft een vermindering van de maximale throughput veroorzaakt van 593Mbps tot 452Mbps, ofwel in totaal ruim -23%.

5.2

Netflow verschilmeting: Jitter en pakketverlies

Drie metingen worden wederom uitgevoerd, nu met een Iperf UDP test waarbij Iperf opgedragen wordt om 1000Mbps UDP verkeer te gegeneren. De configuratie detailles staan beschreven in bijlage 9. Eerst wordt zonder Netflow, dan met Netflow, en vervolgens weer met uitgebreide Netflow monitoring gemeten. Deze resultaten worden onderling vergeleken. NAT is nu niet actief op de router, CEF12 is de forwardings-methode (CEF wordt in par. 8.3.1 beschreven). Dat NAT niet actief is, is irrelevant want NAT processing op UDP 12 Cisco

Express Forwarding, een ASIC gebaseerde forwardings-methode

15

verkeer is niet te vergelijken met TCP verkeer. De in deze meetresultaten gerapporteerde throughput is dus niet vergelijkbaar met de eerder verrichte TCP throughput metingen. (Deze info valt buiten de context: NAT processing is het middel, maar het beoordelen van NAT processing valt buiten het doel van dit onderzoek.) Zonder Netflow wordt nu gigabit lijnsnelheid zonder pakketverlies bereikt (zie bijlage 9, par. 23), met Netflow gaat gem.7% van de UDP pakketten verloren (zie par. 24), en met uitgebreide Netflow 16%, (zie paragraaf 25 voor de configuratie). Deze meetmethode geeft ook de hoeveelheid jitter in elke omstandigheid aan. Echter, aan de hand van deze Iperf meetresultaten zijn er geen onderlinge verschillen in de jitter resultaten waar te nemen. Mogelijk zal een jitter-verschilmeting wel resultaten opleveren indien er een gevari¨eerder verkeersaanbod zou zijn. In par. 3.3 wordt de methode en in par. 4.3.2 het tool Harpoon als middel hiervoor beschreven.

5.3

Metingen met ”Sampled Netflow”

In deze meting is er gekeken of er voordeel te behalen is door met Netflow sampling functionaliteit te werken. Bij de uitvoering van deze Iperf TCP throughput meting was het weer noodzakelijk NAT processing actief te hebben, omdat anders in alle gevallen de gigabit lijnsnelheid werd behaald. Een daadwerkelijke NAT translatie werd niet toegepast (i.t.t. tot eerdere metingen), alleen NAT inspectie. De reden hiervoor is dat de combinatie van Netflow sampling en NAT voor problemen zorgde, door tijdsgebrek kon dit niet opgelost worden. Met alleen deze NAT inspectie wordt het gewenste doel ook bereikt, alleen laat het resultaat zich nu niet vergelijken met de meetresultaten zonder sampling die beschreven staan in par. 5.1. De router heeft in deze meting uitgebreide Netflow uitgevoerd, zie paragraaf 10.2, en heeft nu een zgnde. ”flow-sampler” op beide interfaces geactiveerd, in figuur 30 in paragraaf 10.3 wordt dit ge¨ıllustreerd. Bij iedere throughput meting is de sample-rate aangepast, waarbij 1:1 samplen staat voor het registreren van de eigenschappen van alle datapakketten. In figuur 32 en 30 staan de Iperf meetrapporten. De resultaten staan in het overzicht in fig. 12 en worden in fig. 13 grafisch weergegeven. Sample rate 1:1 1:2 1:3 1:4 1:5 1:10 1:100

Throughput Mbps 511 561 582 601 607 624 644

Figuur 12: Performance winst door sampling.

1:1 Sampling vs. 1:100 sampling heeft een vermeerdering van de max. throughput veroorzaakt van 511Mbps tot 644Mbps, ofwel in totaal ruim +26%. In veel omstandigheden zal een dergelijk lage sample rate niet volstaan omdat daardoor teveel informatie wordt gemist. Maar bijv., een 1:5 sample rate benadering zal voor het registreren en monitoren van de meeste netwerk-sessies weer wel volstaan.

5.4

Interpretatie van meetresultaten

De gemeten -23% en +26% resultaten, kunnen de nodige vragen oproepen. Deze waarden laten zich echter onderling niet vergelijken omdat de NAT configuraties verschillen. Het doel van deze metingen is slechts om een indicatie te geven: iedere andere hardware-, 16

Figuur 13: Performance winst sampling gevisualiseerd.

en software configuratie zullen weer andere meetresulaten opleveren. Het uitgangspunt bij deze metigen is steeds een volledig verzadigde router-CPU, iets wat in de doorsnee ICT praktijk andere prioriteiten aan een Netwerk Engineer stelt, dan het optimaliseren van de Netflow sample rate. Waarschijnlijk zal dit aanleiding zijn tot vervanging van, of upgraden van hardware, dan wel het oplossen van de oorzaak van deze ”storing”.

5.5

SCTP, UDP en Ntop resultaten

Voor het zichtbaar maken van de daadwerkelijke flowdata is de collector Ntop gebruikt, zoals is weergegeven in fig. 6 in par. 2.5. Deze collector is IPFIX/Netflow collector, maar kan gelijktijdig ook als collector voor gedupliceerd verkeer van ”gemirrorde” netwerkpoorten13 fungeren. Al het verkeer wordt dan aangeboden wat maximale rapportage mogelijkheden biedt. Voor de resulaten van de applicatie Ntop is het gekozen transportprotocol niet relevant. Er is uiteraard wel gekeken naar de mogelijkheid om SCTP tussen exporter en collector te activeren. Die mogelijkheid bleek inmiddels beschikbaar want het IOS (zeer recente 12.4 versie) van de gigabit router ondersteunt SCTP. Ook Ntop ondersteunt SCTP, echter dient dit dan wel specifiek mee gecompileerd te worden. Helaas bleek in een te laat stadium achteraf dat dit niet gebeurd was. Wel is er een moment (de tijd was beperkt) debugging verricht om te ontdekken wat de reden van het niet functioneren van SCTP was. Voor een indruk van de onderhandelingen binnen SCTP sessies is dat hieronder weergegeven: Router initieert: *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar *Mar

28 28 28 28 28 28 28 28 28

13 Ook

18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991:

SCTP: Assoc 2192453361: Send Init SCTP: INIT_CHUNK, len 90 SCTP: Initiate Tag: 82AE2EF1, Initial TSN: 71DA8EA8,rwnd 9000 SCTP: Streams Inbound: 20, Outbound: 20 SCTP: Forward TSN (PR-SCTP) Supported SCTP: Unknown param type 32776 (0x8008) of len 8 SCTP: RANDOM, 32 bytes SCTP: HMAC Identifiers, 2 algorithms SCTP: Auth Chunks List, 2 chunks

wel SPAN, Switched Port Analyzer poort, definitie van Cisco

17

*Mar *Mar *Mar *Mar

28 28 28 28

18:33:45.991: 18:33:45.991: 18:33:45.991: 18:33:45.991:

SCTP: Supported addr types: 5 SCTP: Assoc 2192453361: state CLOSED -> COOKIE_WAIT SCTP: Assoc 2192453361: state COOKIE_WAIT -> FAILED SCTP: Assoc 2192453361: state FAILED -> CLOSED

Maar Ntop mist SCTP: HAVE_SCHED_H.....yes HAVE_SCHED_YIELD.....yes HAVE_SCTP.....no HAVE_SECURITY_PAM_APPL_H.....no HAVE_SELECT.....yes De Ntop applicatie is dus onderzocht met aangeleverde flowdata via UDP. Ntop heeft als collector Netflow v9 flowdata aangeboden gekregen, en gelijktijdig een interface toegekend gekregen waarop gedupliceerd verkeer van een perimeter Internet router werd aangeboden. Ntop monitort op deze wijze meerdere omgevingen met verschillende methodes. Enkele screenshots van de Ntop collector in deze opstelling zijn weergegeven in fig. 6 in par. 2.5. De diverse netwerksessies zijn hier zichtbaar. Tevens is dataverkeer van een netwerkzone elders zichtbaar. (Deze netwerkzone bevatte het Iperf dataverkeer van de diverse metingen waarvan de resultaten in dit hfdst. beschreven staan).

18

6

Conclusies

De beschreven resultaten in dit rapport maken duidelijk dat IPFIX, de open standaard van Netflow v9, een geschikt middel is voor diverse netwerkmanagement doeleinden. Deze doeleinden kunnen vari¨eren van traffic engineering ten behoeve van optimalisatie en opschaling, tot inzage in de gebruikswijze van het datanetwerk ten behoeve van security. In dit onderzoek is aangetoond dat het toevoegen van Netflow processing aan bestaande netwerkomgevingen geen - voor netwerkgebruikers waarneembare - degradatie van netwerk performance hoeft te betekenen. Het impact-risico kan verlaagd worden door een common sense benadering toe te passen die eerst bestaat uit een analyse van de huidige performance, met navolgens een stapsgewijze invoering. Daarbij is het zeer verstandig van start te gaan met een minimale hoeveelheid Netflow processing door middel van sampling. Kortom, er kan worden gesteld dat: • Netflow/IPFIX ingezet kan worden voor accountability, security en diverse planning en controle doeleinden, zie par. 2.5, • Het toevoegen van Netflow/IPFIX processing in de meeste omstandigheden een niet waarneembare performance-impact voor netwerkgebruikers cre¨eert: De implementatieaanpak en het uitgangspunt maken het verschil, zie par. 5.3, • Het exporteren van de flowdata naar een centraal IPFIX/Netflow collector-systeem in veel omstandigheden schaalbaarheidsvoordelen biedt, zie fig. 6, • Het out-of-band exporteren van Netflow/IPFIX flowdata omwille van security-, of performance-redenen een aantrekkelijke mogelijkheid zijn kan, zie fig. 3 in par. 2.2, • De hoeveelheid flowdata die ge¨exporteerd wordt door IPFIX, kan vari¨eren van 1,91% tot 14,44% ten opzichte van de originele dataflows. De hoeveelheid zal in de praktijk sterk afhankelijk zijn van de grootte van de datapakketten waaruit de dataflows bestaan, zie fig. 8 in par. 2.8. De uitgevoerde metingen volgens de in hfdst. 3 beschreven meetmethode hebben ook diverse inzichten opgeleverd, en nemen door het indicatieve karakter enige onduidelijkheid of onzekerheid weg: • Netflow/IPFIX processing heeft in deze context, met max. verzadigde router-CPU, een throughput verandering oorzaakt van -23% als gevolg van toegevoegde Netflow processing, en een toename van +26% als gevolg van het toepassen van sampling, zie hfdst. 5, • Toegevoegde Netflow/IPFIX processing heeft op gigabit lijnsnelheid voor max. 17% verlies van de aangeboden UDP datapakketten kunnen zorgen, zie sectie 9 (bijlage 2), • Exporteren van Netflow/IPFIX door middel van het Stream Control Transmission Protocol verdient door haar positieve eigenschappen de voorkeur, maar kan in veel bestaande netwerkomgevingen te voortvarend zijn. Veel software ondersteunt het SCTP transport protocol nog niet: Firmware van netwerknodes dient daarvoor te worden geupgrade. Ook IPFIX wordt vaak nog niet ondersteund, maar het gebruik van bijv. Netflow v9 biedt echter een gelijkwaardige functionaliteit. Het gebruik van het traditionele UDP in plaats van SCTP biedt minder robuustheid en is minder veilig, zoals in fig. 7 en in par. 2.7 is beschreven.

19

7

Openstaande actiepunten

De manier waarop de metingen verricht zijn is in veel opzichten niet geheel representatief voor de praktijk. De resultaten gaven weliswaar het bewijs van-, en inzicht in de performanceimpact, maar de impact zal hier in de praktijk mogelijk behoorlijk van kunnen afwijken. Daarom zou, zoals ook beschreven in paragraaf 4.3.2 en 3.2, getest moeten worden met de tools die de grillige praktijk meer benaderen dan Iperf. In paragraaf 3.3 wordt dit uitgelegd. Het op deze wijze correct uitvoeren van performance-metingen is een tijdrovende zaak. Dit zou evt. als vervolgonderzoek uitgevoerd kunnen worden. Ook is de presentatie van de resultaten momenteel nogal ’droog’. Mgen, genoemd in 4.3.2, rapportages kunnen met bijv. het hulpmiddel ”TRace Plot Real-time” [23] een meer laagdrempeligere presentatie van rapportages bieden.

20

8

Bijlage 1, Voorbereidende performance-impact metingen

In dit hoofdstuk wordt de zoektocht naar een meet-methodiek voor het meten van de impact van Netflow op de performance van een router beschreven. Indien eenmaal een geschikte methodiek is gevonden, kunnen daarmee verschillende Netflow configuraties getest worden voor het verkrijgen van meer inzicht. Deze stellingen zijn al eerder genoemd, maar voor het belang van dit onderzoek hier herhaald:

8.1

Aanpak verschilmetingen

Zoals beschreven wordt er in de metingen gekeken naar de netwerk-impact vanuit het gebruikersperspectief. Een netwerkgebruiker ervaart het netwerk als een ”black box”, en daarom wordt er gemeten aan de voor netwerkgebruikers meetbare performance-indicatoren ”delay”, ”jitter”14 , pakketverlies en ”throughput”15 van het netwerk. Gesteld wordt dat vanuit het gebruikersperspectief er pas echt performancedegradatie waarneembaar wordt, indien de toegevoegde Netflow processing tot een significant hogere en een (bijna) volledige router-CPU belasting leidt, omdat dat zich vertaald in meer netwerk-delay, pakketverlies en een lagere throughput. De metingen worden toegepast op de in paragraaf 4.1.1 beschreven router. Deze router is steeds in ge¨ısoleerde testopstellingen als bottleneck getest. In deze bijlage zijn voorbereidende metingen en resultaten daarvan beschreven. In deze testen wordt het effect van extra processing op de router performance onderzocht. Deze extra processing maakt de uiteindelijke Netflow metingen hopelijk makkelijker omdat de rekenkracht van traffic generators niet op kunnen tegen de capaciteit van de gigabit router. Het voorgestelde startpunt voor de verschilmetingen, is dus in feite een netwerkomgeving die al flink (over)belast is. Door de router voor ieder datapakket bewerkingen zoals NAT en VLAN tagging uit te laten voeren, wordt dit bereikt. Indien Netflow impact heeft, wordt het in deze omstandigheden snel zichtbaar. Het mag duidelijk zijn dat indien een router in een productie-omgeving zich in dergelijke omstandigheden bevindt, het tijd is voor een hardware upgrade. Dit voorbereidende hoofdstuk is dus informatief van aard en kan door lezers die uitsluitend in Netflow impact ge¨ınteresseerd zijn, overgeslagen worden. In hoofdstuk 5 zijn de daadwerkelijke Netflow metingen en resultaten beschreven waaruit zal blijken of het toevoegen van Netflow processing zichtbaar wordt aan de hand van de indicatoren, en in welke mate.

8.2

Host’s

Allereerst is het nodig om uit te sluiten of de host’s een bottleneck kunnen vormen. Wat zijn hun beperkingen als traffic generator voor een gigabitnetwerk? Door de host’s aan een gigabit switch te koppelen wordt met het tool Iperf hun maximum throughput gemeten. De switch is ontworpen om op ”line rate” het verkeer te forwarden. Het gemeten maximum blijkt naast de link capaciteit van meerdere combinatiefactoren afhankelijk. Met de in figuur 14 weergegeven en uitgevoerde testen zijn de gigabit links volledig geutilizeerd, terwijl er op beide host’s CPU ruimte over blijft. In het overzicht in figuur 15 zijn de resultaten zichtbaar van max. throughput metingen met Iperf tussen Vigor158 (Iperf server) en Vigor159 (Iperf client). In de linkerkolom staat de aan Iperf gevraagde ”MSS”16 vermeld, daarna de door Iperf gemeten en gerapporteerde throughput. In de laatste kolom zijn de met ”top” waargenomen 14 Jitter

is de onderlinge delay-variatie in transmissietijd van de verstuurde pakketten of doorvoer, die beperkt wordt door de lijnsnelheid of door de processing capaciteit van

15 Throughput

nodes 16 Maximum Segment Size, de uiteindelijke pakketgrootte is hier een afgeleide van.

21

Figuur 14: Vigor host’s als traffic generators -M MSS auto 1300 1200 1100 1000 900 800 700 600 500 300 200 150 120 100 64

doorvoer Mbps 941 934 930 924 910 810 30-70 13-50 17-50 18-23 80-180 226 165 136 110 68

cpu s% , c% 15 , 13 10 , ? 7,? 0,? 0,? 0,? 10 , 50 10 , 50 10 , 50 10 , 50 0 , 30 1,0 3,0 2 , 0.2 2 , 0.2 23 , 0

Figuur 15: Performance beperkingen host’s

CPU idle waarden van de Iperf client en de Iperf server zichtbaar. Niet alle CPU idle waarden zijn waargenomen, vandaar de vraagtekens. Deze resultaten zijn indicatief, en uitsluitend bedoeld als eerste voorbereiding om meer inzage in de materie te verkrijgen. Uit deze test is gebleken dat er rekening moet worden gehouden met de CPU beperkingen van de traffic generatoren. Tevens is er TCP verkeer gebruikt wat in de resultaten een ongewenst effect kan hebben: Pakket-groottes in de range van 500 tot 800 bytes blijken een negatief effect op throughput te hebben zonder dat CPU’s volledig geutilizeerd zijn. Het vermoeden bestaat dat dit het gevolg is van eigenschappen van TCP algoritmen en sub-optimale TCP window sizing. Het verder uitdiepen van deze effecten valt buiten de scope van dit onderzoek.

8.3

Router performance

Tussen de host’s wordt nu een router geplaatst: De IP configuratie van de host’s wordt aangepast zodat het verkeer via de router gerouteerd wordt. Om een indruk van de capaciteit van de router te krijgen wordt eerst deze standaard Iperf test verricht waarbij de router-CPU

22

belasting en data throughput, zie figuur 17, bekeken worden.

Figuur 16: Performance meting router

Router’s CPU impact op lijnsnelheid: 5555555555555555555 666666666555555555577777111111111111111111111111111111111111 100 90 80 70 60 ******************* 50 ******************* 40 ******************* 30 ******************* 20 ******************* 10 ************************ 0....5....1....1....2....2....3....3....4....4....5....5....6 0 5 0 5 0 5 0 5 0 5 0 CPU% per second (last 60 seconds) Figuur 17: Matige impact router-CPU door CEF op gigabit lijnsnelheid Uit deze Iperf meting blijkt dat de router moeiteloos op lijnsnelheid het verkeer forward, met gemiddeld 60% CPU load. 8.3.1

Forwarden zonder ASIC’s

De router kan toch bottleneck gemaakt worden door de interne methode van forwarding te wijzigen en het zgnde ”process-switching” te forceren in de plaats van de CEF17 methode. Ieder aangeboden en te forwarden pakket heeft nu een lookup in de routetabel tot gevolg: De forwarding wordt nu niet meer met ondersteuning van ASIC’s verricht. In de volgende meting, zie figuur 18 blijkt de max. throughput als gevolg hiervan met een factor 10 te dalen. Deze blijkt daarbij ook enigzins variabel door de volledige CPU verzadiging, en nabij de 100Mbps begrensd. In deze meting is na 15 seconden omgeschakeld naar process-switching, wat te zien is aan de CPU history. (De Iperf resultaten laten alleen process-switching throughput waarden zien). 8.3.2

Performance-impact van kleine pakketten

Het Iperf tool heeft in de voorgaande meting de optimale pakketgrootte (door Iperf werd 1448bytes gerapporteerd) uitgezocht. De Iperf host’s kunnen de snelheid nu gemakkelijk aan. 17 Cisco

Express Forwarding, ´ e´ en van de forwardings-methodes van een Cisco node

23

Impact op router-CPU (router#show proc cpu history): 99999999999999999999999999999999999999999999996666666666 99999999999999999999988888999999999988888999990000000000 100 ********************************************** 90 ********************************************** 80 ********************************************** 70 ********************************************** 60 ********************************************************** 50 ********************************************************** 40 ********************************************************** 30 ********************************************************** 20 ********************************************************** 10 ********************************************************** 0....5....1....1....2....2....3....3....4....4....5....5....6 0 5 0 5 0 5 0 5 0 5 0 CPU% per second (last 60 seconds) root@Vigor159:~# iperf -c 10.0.0.158 -t 9000 -m -i 2 WARNING: attempt to set TCP maximum segment size to 80, but got 536 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 51529 connected with 10.0.0.158 port 5001 [ 3] 282.0-284.0 sec 23.9 MBytes 100 Mbits/sec [ 3] 284.0-286.0 sec 22.5 MBytes 94.4 Mbits/sec [ 3] 290.0-292.0 sec 24.1 MBytes 101 Mbits/sec [ 3] 292.0-294.0 sec 22.7 MBytes 95.1 Mbits/sec Figuur 18: Maximale impact router-CPU door ’process-switching’

Maar Netflow blijkt niet gecombineerd te kunnen worden met deze forwardings-methode: De Netflow administratie wordt net als bij ”CEF”, blijkbaar grotendeels met behulp van hardware gedaan. We schakelen daarom noodgedwongen om naar de standaard forwardings methode CEF, waardoor process-switching zoveel mogelijk voorkomen wordt. Het gevolg hiervan is dat de CPU belasting van de router daalt van 99% naar 60% en dat de throughput weer bijna vertienvoudigd tot bijna lijnsnelheid, nl. 936,6Mbps. Door Iperf kleinere pakketjes aan te laten bieden wordt gekeken of de router zo gemakkelijker in een stress-situatie is te brengen, zie tabel 19. Iperf pakketgrootte (bytes) 128 76 74 64 54

throughput Mbps 140 121 116 100 83

Figuur 19: Iperf TCP meting: Resultaten met kleinere pakketten De belasting van de router-CPU blijkt bij kleinere pakketgrootten toch nog steeds maximaal 85% te bedragen, want de Iperf host’s blijken nu de bottleneck. Kleine pakketjes kosten blijkbaar niet alleen de router maar ook de host’s veel meer werk. 24

De tot nu toe bekeken configuraties blijken niet geschikt voor de in paragraaf 3.1 beschreven gewenste Netflow verschilmetingen. Gezocht wordt naar een mogelijkheid om de router meer in het nadeel te brengen zodat de traffic generators de belasting met de juiste meettools op kunnen voeren zonder het risico te lopen zelf door resources heen te raken.

8.4

Toevoegen van ”dure” router operaties

Door de router extra bewerkingen op de pakketten uit te laten voeren kan dit doel misschien bereikt worden. 8.4.1

Toevoegen ”routing on a stick”

Als eerste wordt gekeken, zie figuur 20, naar de performance-impact van VLAN tagging in een ”one armed routing” of ”routing on a stick” scenario, wat in veel netwerkomgevingen toegepast wordt voor het besparen op uitbreidingen van kostbare gigabit routerpoorten. De router zal nu voor ieder te forwarden pakket extra werk moeten verrichten door deze

Figuur 20: Performance meting ”router on a stick”

een zgnde ”802.1Q VLAN tag” te laten schrijven. De impact van VLAN tagging wordt bewezen in het overzicht in de bijlage in figuur 27, waarbij in process-switching de maximale throughput met kleine pakketjes wordt gemeten, eerst in een situatie zonder-, dan met VLAN tagging. De kleine pakketgrootte als gevolg van de ingestelde MSS waarde, zorgt mede voor de lage gemeten maximale throughput waarde. Uit de waarneming blijkt dat de router-CPU maximaal belast is en de conclusie is dat die de bottleneck vormt in deze test. Eigenlijk is precies zo’n verschilmeting voor de gezochte Netflow verschilmeting ook gewenst. Echter, Netflow vereist CEF, dus bestaat er de moeilijkheid dat er straks op hogere snelheden met CEF geactiveerd, aan de router gemeten dient te worden. In de test in figuur 28 is door Iperf de TCP pakketgrootte geoptimaliseerd en wordt halverwege de Iperf test teruggeschakeld van process-switching naar CEF. (Het gaat uiteindelijk om CEF, maar process-switching is een handig middel om de zwaarte van de operatie te beoordelen). Uit het eindresultaat (in de bijlage) in figuur 28 met CEF blijkt, dat de throughput in vergelijking zonder tagging maar iets lager is, maar een veel belangrijker resultaat is dat de router-CPU nu zwaar belast wordt, soms maximaal. Een probleem is echter dat de gigabit link nu door de Iperf client en de server gedeeld worden wat eventuele Netflow verschilmetingen onbetrouwbaar zou maken. Deze benadering vervalt daarom. Daarom wordt de impact van VLAN tagging op de throughput in de volgende meting, zie fig. 21 nu zonder ”routing on a stick” bekeken. 8.4.2

Toevoegen 802.1Q VLAN tagging

Dezelfde meting wordt herhaald, nu met fysiek gescheiden gigabit interfaces op de router. ´ en interface is via fiber ontsloten, de andere via UTP (koper), beiden zijn ingesteld op E´

25

gigabit speed.

root@Vigor159:~# iperf -c 10.0.0.158 -t 9000 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 48643 connected with 10.0.0.158 port 5001 [ 3] 0.0- 2.0 sec 23.0 MBytes 96.6 Mbits/sec [ 3] 8.0-10.0 sec 23.1 MBytes 96.7 Mbits/sec [ 3] 10.0-12.0 sec 171 MBytes 717 Mbits/sec [ 3] 12.0-14.0 sec 224 MBytes 939 Mbits/sec [ 3] 14.0-16.0 sec 224 MBytes 938 Mbits/sec Figuur 21: Performance meting en resultaat van 802.1Q (VLAN tagging zonder ”routing on a stick”), halverwege omschakelen naar CEF

Het valt nu op dat de gemeten throughput de lijnsnelheid benaderd, i.t.t. de ’routing on a stick’ meting die is weergegeven in figuur 28. Er wordt hier halverwege overgeschakeld naar CEF. De router-CPU blijkt nu bij volledig geutilizeerde gigabitlinks echter niet boven de 65% utilization uit te komen. De CPU blijkt zelfs niet eens extra belast dan de situatie zonder tagging, zoals gemeten en weergegeven in figuur 17. Tagging is met deze router blijkbaar als operatie toch niet ”duur” genoeg voor het gewenste doel, genoemd in paragraaf 3.1. 8.4.3

Toevoegen van NAT, Network Address Translation

NAT wordt vaak toegepast als quick fix om overlappende IP adressen te voorkomen. Bevorderlijk voor de router performance schijnt het niet te zijn, wat hopelijk zal blijken de volgende meting waarvan de testopstelling in figuur 22 staat weergegeven. Het meetresultaat is zichtbaar in de bijlage in overzicht 26 waarbij gedurende de meting de router-CPU steeds max. belast bleek te zijn. Halverwege de Iperf meting wordt weer overgeschakeld naar proces switching om de impact van NAT met eerdere metingen te kunnen vergelijken. Van lijnsnelheid is door de NAT operatie geen sprake meer: De throughput blijkt nu enorm gedaald: Van lijnsnelheid naar een kleine 590Mbps.

26

Figuur 22: Iperf performance meting met Network Address Translation

27

9

Bijlage 2, Iperf Udp Netflow metingen en resultaten

In deze bijlage zijn drie metingen in drievoud uitgevoerd om de resultaten te verifi¨eren. Eerst het Iperf server rapport van een UDP meting op gigabit snelheid zonder Netflow, zie figuur 23. Dan wordt basic Netflow geactiveerd, en de meting opnieuw uitgevoerd. In figuur 24 staan de Iperf server rapporten. Vervolgens wordt uitgebreide Netflow monitoring toegeapst, in figuur 25, staan de resultaten. Duidelijk is te zien in het Iperf resultaat, dat door de verminderde capaciteit een percentage UDP pakketten verloren gaan.

9.1

Pakketverlies zonder Netflow

[ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [

local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 0.0- 1.0 sec 114 MBytes 954 Mbits/sec 0.006 ms 0/81132 1.0- 2.0 sec 114 MBytes 954 Mbits/sec 0.005 ms 0/81147 2.0- 3.0 sec 114 MBytes 955 Mbits/sec 0.008 ms 0/81179 3.0- 4.0 sec 114 MBytes 955 Mbits/sec 0.016 ms 0/81178 4.0- 5.0 sec 114 MBytes 954 Mbits/sec 0.009 ms 15/81163 5.0- 6.0 sec 114 MBytes 954 Mbits/sec 0.016 ms 32/81174 6.0- 7.0 sec 114 MBytes 955 Mbits/sec 0.019 ms 0/81176 7.0- 8.0 sec 114 MBytes 953 Mbits/sec 0.014 ms 128/81191 8.0- 9.0 sec 114 MBytes 954 Mbits/sec 0.005 ms 63/81184 9.0-10.0 sec 114 MBytes 955 Mbits/sec 0.006 ms 0/81175 0.0-10.0 sec 1.11 GBytes 954 Mbits/sec 0.010 ms 238/813871 local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 0.0- 1.0 sec 113 MBytes 948 Mbits/sec 0.006 ms 483/81126 1.0- 2.0 sec 114 MBytes 954 Mbits/sec 0.023 ms 12/81126 2.0- 3.0 sec 114 MBytes 955 Mbits/sec 0.017 ms 0/81177 3.0- 4.0 sec 114 MBytes 953 Mbits/sec 0.009 ms 180/81197 4.0- 5.0 sec 113 MBytes 951 Mbits/sec 0.005 ms 291/81170 5.0- 6.0 sec 114 MBytes 955 Mbits/sec 0.007 ms 0/81182 6.0- 7.0 sec 114 MBytes 953 Mbits/sec 0.021 ms 119/81186 7.0- 8.0 sec 114 MBytes 954 Mbits/sec 0.018 ms 54/81180 8.0- 9.0 sec 114 MBytes 954 Mbits/sec 0.007 ms 55/81175 9.0-10.0 sec 114 MBytes 954 Mbits/sec 0.007 ms 73/81185 0.0-10.0 sec 1.11 GBytes 953 Mbits/sec 0.019 ms 1266/813858 0.0-10.0 sec 1 datagrams received out-of-order WARNING: ack of last datagram failed after 10 tries. local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 0.0- 1.0 sec 114 MBytes 953 Mbits/sec 0.014 ms 134/81129 1.0- 2.0 sec 114 MBytes 955 Mbits/sec 0.014 ms 0/81167 2.0- 3.0 sec 114 MBytes 955 Mbits/sec 0.013 ms 0/81183 3.0- 4.0 sec 114 MBytes 953 Mbits/sec 0.005 ms 112/81180 4.0- 5.0 sec 114 MBytes 955 Mbits/sec 0.010 ms 0/81187 5.0- 6.0 sec 114 MBytes 954 Mbits/sec 0.006 ms 33/81176 6.0- 7.0 sec 114 MBytes 955 Mbits/sec 0.013 ms 0/81177 7.0- 8.0 sec 114 MBytes 954 Mbits/sec 0.007 ms 40/81189 8.0- 9.0 sec 114 MBytes 954 Mbits/sec 0.006 ms 78/81182 9.0-10.0 sec 114 MBytes 954 Mbits/sec 0.014 ms 26/81178 0.0-10.0 sec 1.11 GBytes 954 Mbits/sec 0.007 ms 423/813865

4] 4] 4] 4] 4] 4] 4] 4] 4] 4] 4] 4] 3] 3] 3] 3] 3] 3] 3] 3] 3] 3] 3] 3] 3] 3] 4] 4] 4] 4] 4] 4] 4] 4] 4] 4] 4] 4]

Figuur 23: Server rapport UDP Iperf gigabit meting zonder Netflow

28

(0%) (0%) (0%) (0%) (0.018%) (0.039%) (0%) (0.16%) (0.078%) (0%) (0.029%) (0.6%) (0.015%) (0%) (0.22%) (0.36%) (0%) (0.15%) (0.067%) (0.068%) (0.09%) (0.16%)

(0.17%) (0%) (0%) (0.14%) (0%) (0.041%) (0%) (0.049%) (0.096%) (0.032%) (0.052%)

9.2

Pakketverlies met Netflow

Nu met Netflow montioring op gigabit interfaces toegepast: [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [

3] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 3] 0.0- 1.0 sec 106 MBytes 886 Mbits/sec 0.008 ms 5677/81052 (7%) 3] 1.0- 2.0 sec 106 MBytes 887 Mbits/sec 0.009 ms 5743/81199 (7.1%) 3] 2.0- 3.0 sec 106 MBytes 887 Mbits/sec 0.020 ms 5750/81176 (7.1%) 3] 3.0- 4.0 sec 106 MBytes 891 Mbits/sec 0.009 ms 5449/81184 (6.7%) 3] 4.0- 5.0 sec 106 MBytes 887 Mbits/sec 0.012 ms 5775/81183 (7.1%) 3] 5.0- 6.0 sec 105 MBytes 883 Mbits/sec 0.011 ms 6101/81182 (7.5%) 3] 6.0- 7.0 sec 106 MBytes 885 Mbits/sec 0.008 ms 5924/81182 (7.3%) 3] 7.0- 8.0 sec 106 MBytes 887 Mbits/sec 0.012 ms 5776/81167 (7.1%) 3] 8.0- 9.0 sec 105 MBytes 881 Mbits/sec 0.009 ms 6264/81187 (7.7%) 3] 9.0-10.0 sec 106 MBytes 886 Mbits/sec 0.023 ms 5873/81184 (7.2%) 3] 0.0-10.0 sec 1.03 GBytes 886 Mbits/sec 0.011 ms 58474/813862 (7.2%) 4] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 4] 0.0- 1.0 sec 106 MBytes 891 Mbits/sec 0.017 ms 5300/81081 (6.5%) 4] 1.0- 2.0 sec 106 MBytes 886 Mbits/sec 0.030 ms 5792/81167 (7.1%) 4] 2.0- 3.0 sec 105 MBytes 882 Mbits/sec 0.006 ms 6230/81193 (7.7%) 4] 3.0- 4.0 sec 104 MBytes 871 Mbits/sec 0.012 ms 7119/81175 (8.8%) 4] 4.0- 5.0 sec 104 MBytes 876 Mbits/sec 0.016 ms 6695/81180 (8.2%) 4] 5.0- 6.0 sec 104 MBytes 873 Mbits/sec 0.013 ms 6932/81178 (8.5%) 4] 6.0- 7.0 sec 106 MBytes 886 Mbits/sec 0.007 ms 5808/81185 (7.2%) 4] 7.0- 8.0 sec 106 MBytes 885 Mbits/sec 0.027 ms 5882/81173 (7.2%) 4] 8.0- 9.0 sec 106 MBytes 886 Mbits/sec 0.008 ms 5867/81179 (7.2%) 4] 9.0-10.0 sec 106 MBytes 887 Mbits/sec 0.023 ms 5789/81174 (7.1%) 4] 0.0-10.0 sec 1.03 GBytes 882 Mbits/sec 0.026 ms 61638/813867 (7.6%) 3] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 3] 0.0- 1.0 sec 106 MBytes 890 Mbits/sec 0.019 ms 5386/81034 (6.6%) 3] 1.0- 2.0 sec 106 MBytes 885 Mbits/sec 0.010 ms 5913/81197 (7.3%) 3] 2.0- 3.0 sec 106 MBytes 885 Mbits/sec 0.015 ms 5915/81193 (7.3%) 3] 3.0- 4.0 sec 106 MBytes 885 Mbits/sec 0.018 ms 5895/81186 (7.3%) 3] 4.0- 5.0 sec 105 MBytes 879 Mbits/sec 0.011 ms 6439/81178 (7.9%) 3] 5.0- 6.0 sec 106 MBytes 886 Mbits/sec 0.011 ms 5871/81189 (7.2%) 3] 6.0- 7.0 sec 105 MBytes 884 Mbits/sec 0.009 ms 6015/81160 (7.4%) 3] 7.0- 8.0 sec 106 MBytes 887 Mbits/sec 0.010 ms 5775/81197 (7.1%) 3] 8.0- 9.0 sec 106 MBytes 887 Mbits/sec 0.009 ms 5766/81165 (7.1%) 3] 9.0-10.0 sec 106 MBytes 885 Mbits/sec 0.007 ms 5912/81181 (7.3%) 3] 0.0-10.2 sec 1.03 GBytes 866 Mbits/sec 13.674 ms 59085/813852 (7.3%) 3] 0.0-10.2 sec 1 datagrams received out-of-order Figuur 24: Iperf server rapport UDP gigabit meting met Netflow

9.3

Pakketverlies met uitgebreide Netflow

Zie paragraaf 10.2 voor de toegevoegde configuratie.

29

[ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [

4] 0.0-10.0 sec 1 datagrams received out-of-order 3] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 3] 0.0- 1.0 sec 94.6 MBytes 794 Mbits/sec 0.009 ms 13573/81056 (17%) 3] 1.0- 2.0 sec 96.3 MBytes 808 Mbits/sec 0.035 ms 12448/81176 (15%) 3] 2.0- 3.0 sec 95.8 MBytes 803 Mbits/sec 0.021 ms 12872/81178 (16%) 3] 3.0- 4.0 sec 95.9 MBytes 804 Mbits/sec 0.025 ms 12808/81188 (16%) 3] 4.0- 5.0 sec 95.8 MBytes 804 Mbits/sec 0.012 ms 12847/81183 (16%) 3] 5.0- 6.0 sec 95.9 MBytes 804 Mbits/sec 0.013 ms 12796/81180 (16%) 3] 6.0- 7.0 sec 95.6 MBytes 802 Mbits/sec 0.022 ms 12940/81162 (16%) 3] 7.0- 8.0 sec 95.9 MBytes 805 Mbits/sec 0.011 ms 12766/81193 (16%) 3] 8.0- 9.0 sec 95.9 MBytes 805 Mbits/sec 0.015 ms 12764/81194 (16%) 3] 9.0-10.0 sec 95.1 MBytes 798 Mbits/sec 0.009 ms 13336/81178 (16%) 3] 0.0-10.0 sec 959 MBytes 803 Mbits/sec 0.026 ms 129482/813865 (16%) 3] 0.0-10.0 sec 1 datagrams received out-of-order 4] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 4] 0.0- 1.0 sec 95.7 MBytes 803 Mbits/sec 0.012 ms 12783/81053 (16%) 4] 1.0- 2.0 sec 95.8 MBytes 804 Mbits/sec 0.017 ms 12849/81177 (16%) 4] 2.0- 3.0 sec 95.5 MBytes 801 Mbits/sec 0.014 ms 13034/81187 (16%) 4] 3.0- 4.0 sec 95.5 MBytes 801 Mbits/sec 0.010 ms 13076/81175 (16%) 4] 4.0- 5.0 sec 96.0 MBytes 805 Mbits/sec 0.013 ms 12697/81183 (16%) 4] 5.0- 6.0 sec 95.6 MBytes 802 Mbits/sec 0.009 ms 12989/81180 (16%) 4] 6.0- 7.0 sec 95.8 MBytes 804 Mbits/sec 0.010 ms 12844/81178 (16%) 4] 7.0- 8.0 sec 95.8 MBytes 803 Mbits/sec 0.013 ms 12873/81184 (16%) 4] 8.0- 9.0 sec 95.7 MBytes 803 Mbits/sec 0.014 ms 12881/81177 (16%) 4] 9.0-10.0 sec 95.5 MBytes 801 Mbits/sec 0.015 ms 13077/81179 (16%) 4] 0.0-10.0 sec 960 MBytes 803 Mbits/sec 0.014 ms 129439/813869 (16%) 3] local 10.0.0.158 port 5001 connected with 9.0.0.159 port 32768 3] 0.0- 1.0 sec 95.0 MBytes 797 Mbits/sec 0.018 ms 13267/81049 (16%) 3] 1.0- 2.0 sec 95.5 MBytes 801 Mbits/sec 0.013 ms 13052/81175 (16%) 3] 2.0- 3.0 sec 95.3 MBytes 799 Mbits/sec 0.021 ms 13208/81179 (16%) 3] 3.0- 4.0 sec 95.5 MBytes 801 Mbits/sec 0.016 ms 13077/81185 (16%) 3] 4.0- 5.0 sec 95.0 MBytes 797 Mbits/sec 0.011 ms 13451/81189 (17%) 3] 5.0- 6.0 sec 95.5 MBytes 801 Mbits/sec 0.022 ms 13091/81182 (16%) 3] 6.0- 7.0 sec 95.7 MBytes 803 Mbits/sec 0.010 ms 12925/81177 (16%) 3] 7.0- 8.0 sec 95.3 MBytes 799 Mbits/sec 0.011 ms 13217/81187 (16%) 3] 8.0- 9.0 sec 95.2 MBytes 798 Mbits/sec 0.012 ms 13293/81168 (16%) 3] 9.0-10.0 sec 94.8 MBytes 795 Mbits/sec 0.019 ms 13538/81180 (17%) 3] 0.0-10.0 sec 955 MBytes 799 Mbits/sec 0.020 ms 132483/813859 (16%) Figuur 25: Server rapport UDP Iperf gigabit meting met uitgebreide Netflow

30

10 10.1

Bijlage 3, Diverse (Netflow) metingen Meetresultaten impact NAT

Nat configuratie router: ip nat outside + ip nat inside ip nat outside source static 10.0.0.158 100.0.0.158 Zie 26 voor meetresultaten.

10.2 ip ip ip ip ip ip ip ip ip

Config uitgebreide Netflow monitoring

flow-capture flow-capture flow-capture flow-capture flow-capture flow-capture flow-capture flow-capture flow-capture

10.3

vlan-id ip-id mac-add mac-addresses packet-lengt packet-length icmp fragment fragment-offset

Meetresultaten Netflow sampling

Zie 30

10.4

Meetresultaten VLAN tagging

Zie 27

10.5

Meetresultaten VLAN tagging en ’routing on a stick’

Zie 28

10.6

Meetresultaten uitgebreide Netflow monitoring

Zie rate 29 vs. resultaten throughput 32.

10.7

Fysieke setup

Zie 34 en 35. Als gevolg van het toevoegen van de config in paragraaf 29.

31

root@Vigor159:~# iperf -c 100.0.0.158 -t 9000 -m -i 2 -----------------------------------------------------------Client connecting to 100.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 41553 connected with 100.0.0.158 port 5001 [ 3] 0.0- 2.0 sec 140 MBytes 587 Mbits/sec [ 3] 2.0- 4.0 sec 140 MBytes 586 Mbits/sec [ 3] 4.0- 6.0 sec 140 MBytes 588 Mbits/sec [ 3] 6.0- 8.0 sec 139 MBytes 584 Mbits/sec [ 3] 8.0-10.0 sec 136 MBytes 572 Mbits/sec [ 3] 10.0-12.0 sec 32.9 MBytes 138 Mbits/sec [ 3] 12.0-14.0 sec 17.2 MBytes 72.3 Mbits/sec [ 3] 14.0-16.0 sec 17.2 MBytes 72.0 Mbits/sec [ 3] 16.0-18.0 sec 17.4 MBytes 72.8 Mbits/sec [ 3] 18.0-20.0 sec 17.1 MBytes 71.6 Mbits/sec [ 3] 20.0-22.0 sec 17.2 MBytes 72.1 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# Figuur 26: Impact van NAT op throughput (en van CEF naar process-switching).

Zonder VLAN tagging: root@Vigor158:~# iperf -c 9.0.0.159 -t 600 -M 80 -m -i 2 WARNING: attempt to set TCP maximum segment size to 80, but got 536 -----------------------------------------------------------Client connecting to 9.0.0.159, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 10.0.0.158 port 60267 connected with 9.0.0.159 port 5001 [ 3] 0.0- 2.0 sec 1.65 MBytes 6.91 Mbits/sec [ 3] 2.0- 4.0 sec 1.57 MBytes 6.59 Mbits/sec [ 3] 12.0-14.0 sec 1.59 MBytes 6.65 Mbits/sec Met VLAN tagging: root@Vigor158:~# iperf -c 9.0.0.159 -t 600 -M 80 -m -i 2 Client connecting to 9.0.0.159, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 10.0.0.158 port 60267 connected with 9.0.0.159 port 5001 [ 3] 226.0-228.0 sec 944 KBytes 3.87 Mbits/sec [ 3] 244.0-246.0 sec 928 KBytes 3.80 Mbits/sec [ 3] 246.0-248.0 sec 960 KBytes 3.93 Mbits/sec Figuur 27: Impact van VLAN tagging op router throughput (gemeten in process-switching).

32

root@Vigor158:~# iperf -c 9.0.0.159 -t 90000 -m -i 2 -----------------------------------------------------------Client connecting to 9.0.0.159, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 10.0.0.158 port 57339 connected with 9.0.0.159 port 5001 [ 3] 38.0-40.0 sec 23.1 MBytes 97.1 Mbits/sec [ 3] 42.0-44.0 sec 23.0 MBytes 96.3 Mbits/sec [ 3] 48.0-50.0 sec 56.5 MBytes 237 Mbits/sec [ 3] 50.0-52.0 sec 204 MBytes 854 Mbits/sec [ 3] 52.0-54.0 sec 216 MBytes 907 Mbits/sec [ 3] 56.0-58.0 sec 217 MBytes 910 Mbits/sec [ 3] 58.0-60.0 sec 215 MBytes 903 Mbits/sec Figuur 28: Impact van VLAN tagging met ’routing on a stick’ op router throughput (van process-switching naar CEF).

root@Vigor159:~# iperf -c 100.0.0.158 -t 9000 -m -i 2 -----------------------------------------------------------Client connecting to 100.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 37910 connected with 100.0.0.158 port 5001 [ 3] 20.0-22.0 sec 123 MBytes 514 Mbits/sec [ 3] 64.0-66.0 sec 123 MBytes 515 Mbits/sec [ 3] 66.0-68.0 sec 122 MBytes 513 Mbits/sec [ 3] 68.0-70.0 sec 122 MBytes 513 Mbits/sec [ 3] 70.0-72.0 sec 121 MBytes 507 Mbits/sec [ 3] 72.0-74.0 sec 108 MBytes 451 Mbits/sec [ 3] 74.0-76.0 sec 107 MBytes 451 Mbits/sec **skipped** [ 3] 84.0-86.0 sec 109 MBytes 457 Mbits/sec [ 3] 86.0-88.0 sec 109 MBytes 456 Mbits/sec [ 3] 88.0-90.0 sec 108 MBytes 452 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) Figuur 29: Impact door uitbreiden van Netflow monitoring.)

33

Router(config)# *Mar 17 16:42:55.387: Flow: sampler stefan updated *Mar 17 16:42:55.387: Flow: sampler mode : Random. Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 1 Router(config-sampler)#exit Router(config)# *Mar 17 16:43:10.515: Flow: sampler stefan updated *Mar 17 16:43:10.515: Flow: sampler mode : Random. Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 100 Router(config-sampler)#exit Router(config)# *Mar 17 16:44:03.523: Flow: sampler stefan updated *Mar 17 16:44:03.523: Flow: sampler mode : Random. Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 200 Router(config-sampler)#exit Router(config)# *Mar 17 16:44:25.879: Flow: sampler stefan updated *Mar 17 16:44:25.879: Flow: sampler mode : Random. Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 10 Router(config-sampler)#exit Router(config)# *Mar 17 16:44:59.603: Flow: sampler stefan updated *Mar 17 16:44:59.603: Flow: sampler mode : Random. Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 5 Router(config-sampler)#exit Router(config)# *Mar 17 16:45:37.887: Flow: sampler stefan updated *Mar 17 16:45:37.887: Flow: sampler mode : Random. Router(config)#

Random interval: 1000

Random interval: 1

Random interval: 100

Random interval: 200

Random interval: 10

Random interval: 5

Figuur 30: Router logging sample metingen (wordt vervolgd)

34

Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 4 Router(config-sampler)#exit Router(config)# *Mar 17 16:46:15.347: Flow: sampler stefan updated *Mar 17 16:46:15.347: Flow: sampler mode : Random. Random interval: 4 Router(config)# Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 3 Router(config-sampler)#exit Router(config)# *Mar 17 16:46:35.315: Flow: sampler stefan updated *Mar 17 16:46:35.315: Flow: sampler mode : Random. Random interval: 3 Router(config)# Router(config)#flow-sampler-map stefan Router(config-sampler)#mode random one-out-of 2 Router(config-sampler)#exit Router(config)# *Mar 17 16:47:04.551: Flow: sampler stefan updated *Mar 17 16:47:04.551: Flow: sampler mode : Random. Random interval: 2 Router(config)# Deze resultaten zijn samengevat in het hoofdstuk "Resultaten Netflow metingen". Figuur 31: Router logging sampling (resultaat: zie onder)

35

root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 51507 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 122 MBytes 512 Mbits/sec [ 3] 2.0- 4.0 sec 122 MBytes 510 Mbits/sec [ 3] 4.0- 6.0 sec 122 MBytes 510 Mbits/sec [ 3] 0.0- 6.0 sec 365 MBytes 511 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 51508 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 154 MBytes 645 Mbits/sec [ 3] 2.0- 4.0 sec 153 MBytes 642 Mbits/sec [ 3] 0.0- 6.0 sec 460 MBytes 643 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57527 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 153 MBytes 643 Mbits/sec [ 3] 2.0- 4.0 sec 154 MBytes 646 Mbits/sec [ 3] 4.0- 6.0 sec 138 MBytes 580 Mbits/sec [ 3] 0.0- 6.0 sec 445 MBytes 623 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57528 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 149 MBytes 627 Mbits/sec [ 3] 2.0- 4.0 sec 149 MBytes 626 Mbits/sec [ 3] 4.0- 6.0 sec 147 MBytes 619 Mbits/sec [ 3] 0.0- 6.0 sec 446 MBytes 623 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# root@Vigor159:~#

5001

5001

5001

5001

Deze resultaten zijn samengevat in het hoofdstuk "Resultaten Netflow metingen". Figuur 32: Router throughput vs. sample rate (wordt vervolgd)

36

root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57529 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 143 MBytes 600 Mbits/sec [ 3] 2.0- 4.0 sec 145 MBytes 608 Mbits/sec [ 3] 4.0- 6.0 sec 145 MBytes 608 Mbits/sec [ 3] 0.0- 6.0 sec 433 MBytes 606 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57530 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 143 MBytes 599 Mbits/sec [ 3] 2.0- 4.0 sec 143 MBytes 599 Mbits/sec [ 3] 4.0- 6.0 sec 143 MBytes 602 Mbits/sec [ 3] 0.0- 6.0 sec 429 MBytes 600 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57531 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 139 MBytes 585 Mbits/sec [ 3] 2.0- 4.0 sec 139 MBytes 581 Mbits/sec [ 3] 4.0- 6.0 sec 139 MBytes 584 Mbits/sec [ 3] 0.0- 6.0 sec 417 MBytes 583 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~# root@Vigor159:~# iperf -c 10.0.0.158 -t 6 -m -i 2 -----------------------------------------------------------Client connecting to 10.0.0.158, TCP port 5001 TCP window size: 16.0 KByte (default) -----------------------------------------------------------[ 3] local 9.0.0.159 port 57532 connected with 10.0.0.158 port [ 3] 0.0- 2.0 sec 134 MBytes 562 Mbits/sec [ 3] 2.0- 4.0 sec 134 MBytes 560 Mbits/sec [ 3] 4.0- 6.0 sec 134 MBytes 562 Mbits/sec [ 3] 0.0- 6.0 sec 402 MBytes 561 Mbits/sec [ 3] MSS size 1448 bytes (MTU 1500 bytes, ethernet) root@Vigor159:~#

5001

5001

5001

5001

Deze resultaten zijn samengevat in het hoofdstuk "Resultaten Netflow metingen". Figuur 33: Router throughput vs. sample rate

37

Figuur 34: Equipment

Figuur 35: Poorten

38

Referenties [1] A Survey of Network Traffic Monitoring and Analysis Tools. http://www.cse.wustl.edu/~cs5/567/traffic/index.html. [2] Amsterdam Internet Exchange. http://www.ams-ix.net/. [3] Better Networking with SCTP. http://www.ibm.com/developerworks/linux/library/l-sctp/. [4] Cisco Systems Inc. http://www.cisco.com. [5] Cisco Systems, Portable Product Sheet - Router Perf. http://www.cisco.com/web/partners/downloads/765/tools/quickreference/ routerperformance.pdf. [6] Evaluation Of NetFlow Version 9 Against IPFIX Requirements, IETF & Cisco Systems. http://tools.ietf.org/html/draft-claise-ipfix-eval-netflow-01. [7] Exporting IP flows using IPFIX, Per Juvhaugen, University of Oslo. http://research.iu.hio.no/theses/pdf/master2007/per.pdf. [8] Flowscan, A Network Traffic Flow Reporting and Visualization Tool. http://www.usenix.org/events/lisa2000/full_papers/plonka/plonka_html/ index.html. [9] Free Netflow Tools. http://www.networkuptime.com/tools/netflow/. [10] Harpoon, A Flow-level Traffic Generator. http://pages.cs.wisc.edu/~jsommers/harpoon/. [11] Iperf, The TCP/UDP Bandwidth Measurement Tool. http://dast.nlanr.net/Projects/Iperf/. [12] J-Flow Statistics, Juniper.net. http://www.juniper.net/techpubs/software/erx/junose73/ swconfig-ip-services/html/ip-jflow-stats-config2.html. [13] Multi-Generator, MGEN. http://cs.itd.nrl.navy.mil/work/mgen/index.php. [14] Netflow Performance Analysis, Cisco Systems, Inc. http://www.cisco.com/en/US/technologies/tk543/tk812/technologies_white_ paper0900aecd802a0eb9.pdf. [15] Netflow Services Solutions Guide, Pagina 14: Figure 7, Cisco Systems, Inc. http://www.cisco.com/en/US/docs/ios/solutions_docs/netflow/nfwhite.pdf. [16] New York Talk Exchange, ’How does the city of New York connect to other cities?’, AT&T. http://senseable.mit.edu/nyte/. [17] nProbe, An Extensible NetFlow v5/v9/IPFIX GPL Probe for IPv4/v6. http://www.ntop.org/nProbe.html/. [18] Ntop, a collector and analyser for NetFlow v5/v9/IPFIX flows. http://www.ntop.org/ntop-overview.pdf. [19] ”Out-of-band”, Wikipedia definitie. http://en.wikipedia.org/wiki/Out-of-band. 39

[20] Round Robin Database, Rrdtool-tutorial. http://www.photonway.net/Rrdtool-Tutorial-jp.html/. [21] Technical White Paper for NetStream, Huawei Technologies Co., Ltd. http://www.huawei.com/products/datacomm/pdf/view.do?f=65. [22] The IPFIX charter, ’IP Flow Information Export’ IETF Werkgroep. http://www.ietf.org/html.charters/ipfix-charter.html. [23] TRace Plot Real-time. http://pf.itd.nrl.navy.mil/protools/trpr.html. [24] Wikipedia: ”Application-specific integrated circuit”. http://en.wikipedia.org/wiki/Application-specific_integrated_circuit. [25] P. Phaal, S. Panchen, and N. McKee. InMon Corporation’s sFlow: A Method for Monitoring Traffic in Switched and Routed Networks. RFC 3176 (Informational), September 2001. [26] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol. RFC 2960 (Proposed Standard), October 2000. Obsoleted by RFC 4960, updated by RFC 3309.

40