Do s & don ts van Netflow

Transcriptie

1 Do s & don ts van Netflow Onderzoek naar Netflow en impact op netwerknodes Stéfan Deelen System & Network Engineering stefan.deelen@os3.nl 31 maart 2008

2 Inhoudsopgave 1 Introductie Projectcontext Doelstelling project Onderzoeksaanpak Opbouw document Netflow achtergronden Netflow architectuur Probes of bestaande nodes? Dataflow vs. flow data Netflow versies en processing Netflow presentaties en statistieken IPFIX UDP, TCP, SCTP Exporteren van flow data Performance-impact meetmethode Stelling: Vergelijkend meten! Uitgangspunt voor Netflow metingen Meer specifieke Netflow performance-impact metingen Testmiddelen en configuraties Netwerknodes Gigabit router Gigabit switch Testservers Software tools Iperf Mgen en Harpoon Ntop als collector Resultaten Netflow metingen Netflow verschilmeting: Throughput Netflow verschilmeting: Jitter en pakketverlies Metingen met Sampled Netflow Interpretatie van meetresultaten SCTP, UDP en Ntop resultaten Conclusies 19 7 Openstaande actiepunten 20 8 Bijlage 1, Voorbereidende performance-impact metingen Aanpak verschilmetingen Host s Router performance Forwarden zonder ASIC s Performance-impact van kleine pakketten Toevoegen van dure router operaties Toevoegen routing on a stick Toevoegen 802.1Q VLAN tagging Toevoegen van NAT, Network Address Translation

3 9 Bijlage 2, Iperf Udp Netflow metingen en resultaten Pakketverlies zonder Netflow Pakketverlies met Netflow Pakketverlies met uitgebreide Netflow Bijlage 3, Diverse (Netflow) metingen Meetresultaten impact NAT Config uitgebreide Netflow monitoring Meetresultaten Netflow sampling Meetresultaten VLAN tagging Meetresultaten VLAN tagging en routing on a stick Meetresultaten uitgebreide Netflow monitoring Fysieke setup

4 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 één 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ëxporteerd 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.

5 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ëvolueerd 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 LIA 1 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 SCTP 2, een relatief nieuw transportprotocol voor Netflow en bij IPFIX, de IETF 3 standaard die is voortgekomen uit de laatste Netflow versie. 1 Large Installation Administration, Universiteit van Amsterdam 2 Stream Control Transmission Protocol 3 Internet Engineerings Task Force 1

6 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ën toegepast: Ntop[18] als Netflow collector, SCTP, een Cisco router als Netflow generator en gigabit netwerk-switch. Tevens is er NAT 4 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 Address Translation 5 Ook wel one-armed routing genoemd 2

7 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ëren 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 één 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

8 Een aanpak waarin bestaande nodes worden uitgebreid met Netflow functionaliteit in de software, waarbij flow records worden geëxporteerd 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) IP adres afzender, 2) IP adres bestemming, 3) Poortnummer afzender, 4) Poortnummer bestemming, 5) Laag 3 protocol type, 6) TOS byte (Type Of Service), 7) Logische inkomende interface. Flow data bestaat uit geëxporteerde 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

9 Indien er wel een export proces is toegepast, worden de gegevens in de vorm van flow records in een geconfigureerd interval geëxporteerd. Een collector verzamelt deze records die minimaal uit deze zeven kenmerken bestaan. Er kan ook extra info geëxporteerd 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ëxporteerd 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ëxporteerd 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ële 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ërend 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

10 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ëxporteerd. 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ërende 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

11 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 één 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

12 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ënter 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ëxporteerd 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ëxporteerde 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

13 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ëxporteerde 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ëxporteerd 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

14 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 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 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 Iperf 8, 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 s 9 geforward wordt. De throughput is desondanks nog aanzienlijk. 6 Jitter is de onderlinge variatie in de transmissietijd tussen de verstuurde datapakketten 7 Throughput of doorvoer, die beperkt wordt door de lijnsnelheid of door de processing capaciteit van nodes 8 Iperf wordt beschreven in par Application Specific Integrated Circuit, gespecialiseerde hardware 10

15 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 één 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 één 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ërende 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

16 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 één node getest van het type Cisco 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ëren. 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 IOS 10 beschikt over ondersteuning voor Netflow v9 en SCTP. In de bijlage in figuur 34 en 35 is de fysieke apparatuur weergegeven 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 t3.bin" ***skipped*** Cisco 3825 (revision 1.1) with K/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 K bytes of ATA System CompactFlash (Read/Write) ***skipped*** Gigabit switch Een gigabit switch is gebruikt om het testen makkelijker te maken. Van de 2 gigabit koppelingen van bovengenoemde router diende er één 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

17 System image file is "bootflash:cat4000-i9s-mz ewa11.bin" cisco WS-C4948 (MPC8245) processor (revision 0) with K 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, 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, 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, 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ëxporteerde flow records te collecteren 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 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ërende dataflows te genereren. Deze variatie kan bereikt worden door als input Harpoon van historische Netflow logdata te voorzien. Een alternatief 13

18 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 Ntop als collector Ntop [18] is één 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

19 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ëxporteerd. Nadien volgen metingen met sampelen en exporteren in paragraaf 5.3 en 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. iperf -c t m -i 2 Client connecting to , TCP port 5001 TCP window size: 16.0 KByte (default) [ 3] local port connected with port 5001 [ 3] sec 141 MBytes 593 Mbits/sec [ 3] sec 141 MBytes 593 Mbits/sec [ 3] sec 140 MBytes 587 Mbits/sec [ 3] sec 128 MBytes 535 Mbits/sec [ 3] sec 123 MBytes 515 Mbits/sec [ 3] sec 123 MBytes 514 Mbits/sec [ 3] sec 123 MBytes 517 Mbits/sec [ 3] 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 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, CEF 12 is de forwardings-methode (CEF wordt in par beschreven). Dat NAT niet actief is, is irrelevant want NAT processing op UDP 12 Cisco Express Forwarding, een ASIC gebaseerde forwardings-methode 15

20 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ëerder verkeersaanbod zou zijn. In par. 3.3 wordt de methode en in par 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 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 Throughput rate Mbps 1: : : : : : : 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

21 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 Deze collector is IPFIX/Netflow collector, maar kan gelijktijdig ook als collector voor gedupliceerd verkeer van gemirrorde netwerkpoorten 13 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 28 18:33:45.991: SCTP: Assoc : Send Init *Mar 28 18:33:45.991: SCTP: INIT_CHUNK, len 90 *Mar 28 18:33:45.991: SCTP: Initiate Tag: 82AE2EF1, Initial TSN: 71DA8EA8,rwnd 9000 *Mar 28 18:33:45.991: SCTP: Streams Inbound: 20, Outbound: 20 *Mar 28 18:33:45.991: SCTP: Forward TSN (PR-SCTP) Supported *Mar 28 18:33:45.991: SCTP: Unknown param type (0x8008) of len 8 *Mar 28 18:33:45.991: SCTP: RANDOM, 32 bytes *Mar 28 18:33:45.991: SCTP: HMAC Identifiers, 2 algorithms *Mar 28 18:33:45.991: SCTP: Auth Chunks List, 2 chunks 13 Ook wel SPAN, Switched Port Analyzer poort, definitie van Cisco 17

22 *Mar 28 18:33:45.991: SCTP: Supported addr types: 5 *Mar 28 18:33:45.991: SCTP: Assoc : state CLOSED -> COOKIE_WAIT *Mar 28 18:33:45.991: SCTP: Assoc : state COOKIE_WAIT -> FAILED *Mar 28 18:33:45.991: SCTP: Assoc : 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 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

23 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ëren 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ëert: 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ëxporteerd wordt door IPFIX, kan variëren 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 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

24 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 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

25 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 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 15 Throughput of doorvoer, die beperkt wordt door de lijnsnelheid of door de processing capaciteit van nodes 16 Maximum Segment Size, de uiteindelijke pakketgrootte is hier een afgeleide van. 21

26 Figuur 14: Vigor host s als traffic generators -M doorvoer cpu MSS Mbps s%, c% auto , ,? ,? ,? ,? ,? , , , , , , , , , , 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

27 belasting en data throughput, zie figuur 17, bekeken worden. Figuur 16: Performance meting router Router s CPU impact op lijnsnelheid: ******************* 50 ******************* 40 ******************* 30 ******************* 20 ******************* 10 ************************ 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 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 CEF 17 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) 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, één van de forwardings-methodes van een Cisco node 23

28 Impact op router-cpu (router#show proc cpu history): ********************************************** 90 ********************************************** 80 ********************************************** 70 ********************************************** 60 ********************************************************** 50 ********************************************************** 40 ********************************************************** 30 ********************************************************** 20 ********************************************************** 10 ********************************************************** CPU% per second (last 60 seconds) root@vigor159:~# iperf -c t m -i 2 WARNING: attempt to set TCP maximum segment size to 80, but got 536 Client connecting to , TCP port 5001 TCP window size: 16.0 KByte (default) [ 3] local port connected with port 5001 [ 3] sec 23.9 MBytes 100 Mbits/sec [ 3] sec 22.5 MBytes 94.4 Mbits/sec [ 3] sec 24.1 MBytes 101 Mbits/sec [ 3] 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 throughput (bytes) Mbps 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

29 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 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 Toevoegen 802.1Q VLAN tagging Dezelfde meting wordt herhaald, nu met fysiek gescheiden gigabit interfaces op de router. Één interface is via fiber ontsloten, de andere via UTP (koper), beiden zijn ingesteld op 25

30 gigabit speed. iperf -c t m -i 2 Client connecting to , TCP port 5001 TCP window size: 16.0 KByte (default) [ 3] local port connected with port 5001 [ 3] sec 23.0 MBytes 96.6 Mbits/sec [ 3] sec 23.1 MBytes 96.7 Mbits/sec [ 3] sec 171 MBytes 717 Mbits/sec [ 3] sec 224 MBytes 939 Mbits/sec [ 3] 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 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