Experimentele studie van een NAT dienst met behulp van netwerkprocessoren

Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Experimentele studie van een NAT dienst met behulp van netwerkprocessoren door Wim VAN DE MEERSSCHE

Promotoren: Prof. Dr. Ir. B. DHOEDT & Dr. Ir. F. DE TURCK Scriptiebegeleiders: T. STEVENS & Ir. K. VLAEMINCK

Scriptie ingediend tot het behalen van de academische graad van licenciaat in de Informatica, optie software-ontwikkeling

Academiejaar 2003–2004

Woord vooraf Het programmeren op een interessante onbekende architectuur was zeker niet eenvoudig. Gelukkig stond ik niet alleen voor deze uitdaging, en dus wil ik in dit voorwoord alle mensen bedanken die mij geholpen hebben. In het bijzonder mijn begeleiders Tim Stevens en Koert Vlaeminck, wiens hulp van onschatbare waarde was. Kasper Janssens wil ik bedanken voor de hulp, en Jo Geeraerts voor het verwijderen van vele taalfouten. Verder wil ik mijn promotoren Bart Dhoedt en Filip De Turck, en ook de IBCN groep bedanken. Ook mijn ouders dank ik voor hun steun.

Wim Van de Meerssche, mei 2004

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Wim Van de Meerssche, mei 2004

Experimentele studie van een NAT dienst met behulp van netwerkprocessoren door Wim VAN DE MEERSSCHE Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica, optie software-ontwikkeling Academiejaar 2003–2004 Promotor: Prof. Dr. Ir. B. DHOEDT & Dr. Ir. F. DE TURCK Scriptiebegeleiders: T. STEVENS & Ir. K. VLAEMINCK Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting De IXP1200 netwerkprocessor is door zijn geoptimaliseerde ontwerp zeer efficiënt in pakketverwerking. Het doel van deze thesis is een NAT service op een netwerkprocessor implementeren en de performantie ervan meten. In het inleidende hoofdstuk worden de doelstellingen van deze thesis toegelicht. Het tweede hoofdstuk verklaart de gebruikte technologie, namelijk NAPT, Netfilter, netwerkprocessoren en de IXP1200 netwerkprocessor specifiek. Het derde hoofdstuk schetst de implementatie, en verklaart verschillende implementatiebeslissingen. In het vierde hoofdstuk worden de metingen beschreven en de bekomen resultaten besproken. Ook worden enkele mogelijke uitbreidingen voorgesteld en worden ten slotte de besluiten samengevat. De IXP1200 netwerkprocessor blijkt, zoals te verwachten, een zeer efficiënte pakketverwerker te zijn. Een grote bottleneck blijkt de micro-engine naar core overdracht te zijn. Het toevoegen van de ge¨ımplementeerde NAT service heeft een negatieve invloed op de performantie van de IXP1200, maar dit wordt slechts bij overbelasting duidelijk zichtbaar.

Trefwoorden NAT, IXP1200, netwerkprocessor, ENP-2505

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

2 Technologie

4

2.1

2.2

2.3

2.4

2.5

NetwerkProcessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.3

NP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

IXP1200 Netwerkprocessor & ENP2505 Hardware . . . . . . . . . . . . . . . . .

5

2.2.1

Onderdelen IXP1200 netwerkprocessor . . . . . . . . . . . . . . . . . . . .

5

2.2.2

Onderdelen ENP2505 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Netwerkprocessor Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.1

De IXA software architectuur en het ACE framework . . . . . . . . . . .

8

2.3.2

Programmeren Conventionele ACE’s . . . . . . . . . . . . . . . . . . . . .

9

2.3.3

Programmeren MicroACE’s . . . . . . . . . . . . . . . . . . . . . . . . . .

9

NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.4.1

NAT Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.4.2

Statische NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.4.3

Dynamische NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.4.4

NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.4.5

Enkele NAT problemen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5.1

Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.5.2

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.5.3

Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.5.4

Netfilter en NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

INHOUDSOPGAVE

2.6

ii

Checksum bij IP, TCP, UDP en ICMP . . . . . . . . . . . . . . . . . . . . . . . .

3 Aanpak

17 20

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.2

Vingeroefening: Statische NAT implementatie . . . . . . . . . . . . . . . . . . . .

21

3.3

NAPT implementatie

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.3.1

Connection Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.3.2

NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.3.3

Praktische problemen en oplossingen . . . . . . . . . . . . . . . . . . . . .

30

Beperkingen & tekortkomingen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.4

4 Metingen en resultaten

35

4.1

Theoretische voorspellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.2

Thoughput en pakketgrootte bij verschillende implementaties . . . . . . . . . . .

39

4.3

Latentie en verschillende applicaties . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.4

Latentie en pakketgrootte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.5

Thoughput & latentie bij gebruik van meerdere poorten . . . . . . . . . . . . . .

43

4.6

Throughput bij theoretische grenzen . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.7

Latentie initiële pakketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.8

Wget downloadtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5 Mogelijke uitbereidingen

49

6 Besluit

50

A Starten NAPT Applicatie

51

B NAT configuratie bestand

53

C Overzicht Bestanden

56

INLEIDING

1

Hoofdstuk 1

Inleiding Situering De huidige breedbandinternetverbindingen bieden de gebruikers de mogelijkheid om altijd online te zijn, en ze zijn snel genoeg om met meerdere gebruikers 1 verbinding te delen. Door de lage prijs van PC’s hebben vele klanten meerdere PC’s, die via een thuisnetwerk met elkaar en met internet verbonden zijn. Naast PC’s zijn er tegenwoordig ook allerlei apparaten beschikbaar die van internettoegang gebruik maken, zoals spelconsoles, en zelfs koelkasten. Momenteel is het de klant, die een breedbandverbinding van zijn provider krijgt, die zelf moet zorgen dat er via een NAT router door meerdere gebruikers tegelijkertijd van 1 IP adres gebruik kan gemaakt worden. De provider kan meerdere IP adressen aanbieden, maar in de huidige versie van IP (versie 4) zijn er niet genoeg adressen om elk apparaat van een uniek adres te voorzien. Een provider kan zelf een NAT router bij de klant plaatsen, maar kan naderhand er moeilijk wijzigingen aan aanbrengen. De meest gebruiksvriendelijke oplossing voor de klant is dat NAT, firewall en andere diensten aangeboden worden door de provider, zonder dat er extra hardware of software bij de klant hoeft ge¨ınstalleerd te worden. Dit kan door de diensten binnen het accessnetwerk van de provider te plaatsen, zodat die er volledige controle over heeft. Uiteraard zullen ze verschillende gebruikers tegelijk bedienen, en dus zullen ze zeer performant moeten zijn. Netwerkprocessoren die in het netwerk van de provider worden ingeschakeld, bieden deze mogelijkheden. Ze worden door de fabrikanten aangeprezen als snel, zuinig en flexibel. Deze thesis zal nagaan of een NAT implementatie op netwerkprocessoren een oplossing biedt, en hoe performant deze oplossing is.

INLEIDING

2

Details Doelstelling Het doel van deze thesis is het implementeren van een NAPT service, ge¨ınspireerd op Netfilter, voor de IXP1200 netwerkprocessor en het meten van de performantie ervan. De IXP1200 netwerkprocessor van Intel is geoptimaliseerd voor pakketverwerking. De speciale architectuur die daaruit voorkomt heeft effect op de manier waarop geprogrammeerd wordt. Een deel van de applicatie zal op snelle microengines draaien, en een deel op de StrongArm core. Het is de bedoeling NAPT (Network Adress and Port Translation) te implementeren. Als inspiratiebron en model kan de Netfilter implementatie van NAT gebruikt worden. Omdat IXP applicaties op verschillende processors draaien (core en microengines), en het core gedeelte niet in kernel mode draait is het onmogelijk de netfilter code gewoon om te zetten naar de nieuwe architectuur (cfr. “porten”). Na en tijdens het implementeren zullen enkele testjes gedaan worden die nagaan of het gemaakte programma wel doet wat het moet doen. Dan is het interessant om te meten hoe performant de IXP1200 netwerkprocessor is, en welke invloed de NAT service op de performantie heeft.

Overzicht In het hoofdstuk “Technologie” worden de gebruikte hardware, software en technieken besproken. Netwerkprocessoren worden vergeleken met de alternatieven, dan worden specifiek de details van de IXP1200 harware uit de doeken gedaan. Ook het softwaremodel dat door Intel ontwikkeld werd voor programma’s op netwerkprocessoren wordt kort besproken. Vervolgens worden NAPT, enkele vormen van NAPT en enkele problemen met NAPT geschetst. Het Netfilter model wordt besproken en ten slotte wordt de oplossing voor het probleem van incrementele checksum updates uitgelegd. Het hoofdstuk “Implementatie” schetst eerst hoe het Netfilter model vereenvoudigd kan worden voor de NAPT implementatie. Vervolgens wordt kort een voorbereiding toegelicht, namelijk het implementeren van statische NAT. Daarna wordt in vrij veel detail de werking van de eigenlijk NAPT implementatie toegelicht. Er wordt uitgelegd uit welke delen de implementatie bestaat, wat elk deel doet, en hoe het dat doet. Ook worden de gebruikte geheugenstructuren bekeken, en worden bepaalde ontwerpsbeslissingen toegelicht. Ten slotte worden enkele praktische problemen (en oplossingen) toegelicht, en worden enkele tekortkomingen van de NAPT implementatie

INLEIDING

3

bekeken. Alle bruikbare resultaten bekomen bij het testen/meten van de implementatie zijn opgenomen in het hoofstuk “Metingen & resultaten”. Dit hoofstuk bespreekt afzonderlijk enkele metingen en resultaten. Iedere meting wordt beschreven, de resulaten worden opgesomd en uiteraard wordt indien mogelijk besproken hoe de resulaten te verklaren zijn en wat eruit te besluiten valt. Op het einde van het hoofstuk worden verschillende metingen met elkaar in verband gebracht en besproken, en er wordt een algemene conclusie uit de metingen getrokken. Enkele interessante uitbereidingen worden in het hoofdstuk “Mogelijke Uitbereidingen” toegelicht. Het laatste hoofdstuk, “Besluit” vat ten slotte de conclusies en belangrijkste punten van alle voorgaande hoofstukken samen.

TECHNOLOGIE

4

Hoofdstuk 2

Technologie 2.1

NetwerkProcessors

Om duidelijk te maken wat een netwerkprocessor is, is het handig om eerst enkele andere oplossingen voor pakketverwerking te bekijken, namelijk ASIC’s en GPP’s. De belangrijkste verschillen tussen de 3 soorten zijn verbruik, snelheid en flexibiliteit.

2.1.1

ASIC

ASIC’s, of Application Specific Integrated Circuits, zijn implementaties in hardware van een specifieke netwerkapplicatie. ASIC’s worden veel gebruikt in hoge snelheid routers en switches. Ze kunnen beschouwd worden als de “hardwareversie” van een stuk software. Dit betekent dat ze zeer performant en zuinig zijn, maar ze kunnen slechts 1 welbepaald probleem oplossen. Ze kunnen niet aangepast worden aan een nieuw of licht gewijzigd probleem, en fouten kunnen niet verwijderd worden.

2.1.2

GPP

GPP’s, of General Purpose Processors, zijn softwarematig programmeerbare processors die voor allerlei doeleinden kunnen gebruikt worden, ondermeer voor netwerkapplicaties. Een typisch voorbeeld is de CPU van een PC. Deze processors zijn zeer flexibel. Programmas kunnen snel aangepast worden indien nodig. GPP’s zijn echter veel minder performant dan een gespecialiseerde ASIC die hetzelfde werk doet. Moderne GPP’s draaien echter aan veel hogere klok-

2.2 IXP1200 Netwerkprocessor & ENP2505 Hardware

5

snelheden dan NPP’s en ASIC’s, wat ze een groot performantievoordeel oplevert. Dit zorgt er wel voor dat ze veel meer verbruiken.

2.1.3

NP

NP’s, of Network Processors, zijn softwarematig programmeerbare processors, specifiek ontworpen voor het verwerken van netwerkpakketten. Door hun gespecialiseerde ontwerp zijn ze voor netwerkapplicaties efficiënter en zuiniger dan GPP’s aan dezelfde kloksnelheid. Ze zijn trager dan ASIC’s voor problemen die ASIC’s kunnen oplossen, maar programmeerbaar en dus flexibeler. Van de meest simpele routing tot de meest complexe pakketverwerking is mogelijk met een netwerkprocessor, mits de software wordt geschreven. Nadat de software is geschreven kan deze ook nog aangepast worden. Dit is een enorm voordeel tegenover de kost van het ontwerpen en produceren van een ASIC. Netwerkprocessors zijn dus een middenweg tussen de flexibiliteit van GPP’s en de snelheid en zuinigheid van ASIC’s.

2.2 2.2.1

IXP1200 Netwerkprocessor & ENP2505 Hardware Onderdelen IXP1200 netwerkprocessor

De IXP1200 is een netwerkprocessor van Intel. Hij bestaat uit een centrale processor en 6 microengines. De processor zelf bevat geen netwerkpoorten of geheugen, en maakt in de praktijk dus deel uit van een groter geheel. Een schematische voorstelling van de processor is weegegeven is Figuur 2.1

StrongARM core Processor De IXP1200 bevat een StrongArm processor die aan 166, 200 of 232 Mhz draait als ’core’ processor. op deze RISC processor draait onder andere het besturingssyteem.

Micro-engines De IXP 1200 heeft zes micro-engines (MEs). Deze draaien elk aan dezelfde snelheid als de core processor. Elke ME heeft een instructieopslagcapaciteit van 2K en kan dus een programma van


6

Figuur 2.1: IXP1200

maximaal 2048 lijnen microcode uitvoeren. Elke ME draait afzonderlijk van de andere en heeft zelf 4 threads. Deze threads hebben elk hun eigen hardwareregisters, waardoor context switching geen tijd kost. Context switches moeten expliciet door de programmeur worden opgeroepen, en dit gebeurt in de praktijk vooral bij geheugenopdrachten. De hardware zorgt ervoor dat er in dat geval niet terug geswitched wordt naar een thread totdat de geheugenopdracht afgerond is. Er zijn 128 “general-purpose” registers, 64 sram transfer registers en 64 sdram transferregisters per micro-engine, en dus een vierde daarvan per thread. Registers kunnen ook eventueel door alle 4 threads gebruikt worden ipv enkel door 1 thread. General-purpose registers zijn onderverdeeld in 2 banken, de A en B bank. Bepaalde operandi van microcodeinstructies moeten verplicht uit een van beide banken komen.


7

De microinstructies zijn gespecialiseerd in pakket processing. Dit houdt in dat makkelijk bytes kunnen gemanipuleerd worden en vele shift operaties mogelijk zijn, in dezelfde instructiecyclus als ALU instructies. Enkele voorbeeldinstructies: ld_field[target, 0010, source, >>8] alu_shf[target, regA, +, regB, <<16] De eerste instructie vervangt de 2de laagste byte in target door de 2de laagste byte in source, dus door de 3de laagste byte in source. De tweede instructie telt regA op bij regB nadat het 16 bit naar links geschift is en bewaart het resultaat in target. De micro-engines kennen geen virtueel geheugen, en spreken het geheugen (SDRAM, SRAM of scratchpad) aan via het fysieke adres. De micro-engines kennen ook geen geheugenbeheer. Het is de taak van de core processor om het nodige geheugen te alloceren, het fysieke adres te bepalen en de programmacode op de micro-engines hiermee aan te passen (“patchen”) alvorens ze te starten.

Scratchpad geheugen De IXP1200 heeft 4Kb scratchpad geheugen ingebouwd. Dit geheugen is ingebouwd in de processor en daardoor zeer snel. Het kan door applicaties gebruikt worden om tijdelijke gegevens op te slaan, of om te communiceren tussen de core en de micro-engines. Het wordt in vele applicaties voor debug data gebruikt.

Hardware hash unit Het gebruik van hashtabellen in het geheugen wordt versneld door een hardware hash unit die 48of 64-bit “adaptive polynomial hash keys” genereert. Dit is handig aangezien het sneller is dan softwarematig de hashkeys te genereren en omdat de micro-engines ook geen vermenigvuldiging intructie bevatten terwijl die voor het genereren van hash keys wordt gebruikt.

2.2.2

Onderdelen ENP2505

De ENP-2505 kaart is een kaart die de IXP1200 bevat. Deze PCI kaart kan in PC’s ingebouwd worden. Communicatie met de IXP1200 netwerkprocessor verloopt dan via de PCI interface van de PC.

2.3 Netwerkprocessor Software

8

Geheugen De ENP2505 kaart bevat 256 Mb SDRAM geheugen en 8 Mb SRAM geheugen. Het SRAM geheugen is sneller en kan dus de geheugen-bottleneck van programma’s verlagen. Het SDRAM geheugen is groter (en goedkoper). Het SDRAM geheugen is quadword (64-bit) adresseerbaar, het SRAM geheugen is longword (32-bit) adresseerbaar.

Poorten De kaart bevat slechts 4 10/100Mbit ethernet poorten. Dit is minder dan wat de IXP1200 aankan.

2.3 2.3.1

Netwerkprocessor Software De IXA software architectuur en het ACE framework

Het “ACE(Active Computing Element) programming framework” is een onderdeel van “IXA (Intel Internet eXchange Architecture)”. Deze architectuur is een model op hoog niveau om applicaties voor netwerkprocessoren te ontwikkelen. Applicaties gemaakt met de IXA API, en met hulp van de IXA SDK, worden IXA applicaties genoemd. De architectuur definieert 3 niveaus aanwezig in netwerkapplicaties: data processing niveau, controle niveau en management niveau. Neem bijvoorbeeld een router applicatie. Hier zal het data processing niveau pakketten ontvangen en doorsturen. Het controle niveau zal opzoeken waar een pakket heen moet indien het data processing niveau dit niet uit de cache kon halen. Het management niveau zal bijvoorbeeld een GUI zijn die toelaat de instellingen van de router aan te passen. Binnen dit model is een ACE een component die 1 specifieke taak aankan. Er zijn 2 soorten ACEs gedefinieerd, conventionele ACEs (draait volledig op de core processor) en geaccelereerde ACEs (draait ook op andere processors). Voor de IXP1200 zijn die laatste MicroACEs, componenten waarvan een deel draait op de micro-engines. Er zijn verschillende library en system ACEs voorzien door Intel die kunnen samengevoegd worden, samen met zelfgeschreven ACEs tot een IXA applicatie.


2.3.2

9

Programmeren Conventionele ACE’s

Op de StrongArm core draait het besturingssysteem, Linux (of eventueel VxWorks). Hierop draait het hoofdprogramma van elke IXA applicatie, het conventionele ACE gedeelte van een microACE. Applicaties kunnen geschreven worden in C of C++ en kunnen met de gcc compiler gecompileerd worden. Een core programma heeft verschillende taken: • Het reserveren van het nodige geheugen. • Het “patchen” van micro-engines, dit is geheugenadressen (fysieke adressen) doorgeven aan de microcode van de micro-engines. • Het starten en configureren van alle gebruikte ACE’s. • Het laden van de microcode op de micro-engines en het starten van de micro-engines. • Pakketten verwerken die door de micro-engines naar de core worden gestuurd (“uitzonderingspakketten”) • Het vrijgeven van gereserveerd geheugen en het stoppen van de micro-engines als de gebruiker erom vraagt. Er zijn verscheidene hulpmiddelen om het programmeren te vereenvoudigen: • Een Resource Manager die helpt met het reserveren van geheugen, het omzetten van virtuele naar fysieke adressen (en omgekeerd) en het opnieuw vrijgeven van geheugen. • Een uitgebreide softwarebibliotheek, met onder andere functies voor pakketverwerking. • De hulpprogrammas ixstart (en ixstop), die de microcode laden, en de nodige ACEs starten en configureren (en later stoppen). In een configuratiefile wordt gespecifieerd wat deze programmas moeten doen.

2.3.3

Programmeren MicroACE’s

Het programmeren van de micro-engines gebeurt in microcode. Een microcode compiler met vele handige functies helpt bij het programmeren van de micro-engines. Een micro-engine programma bestaat typisch uit 2 delen: de dispatchloop en het eigenlijk programma (microace-gedeelte).


10

Microcode compiler De microcompiler bevat vele functies om het gebruik van de nogal programmeer-onvriendelijke microcode makkelijker te maken: • Een krachtige preprocessor, vergelijkbaar met de C preprocessor. • Labels die bruikbaar zijn ipv microcode-instructie-adressen bij branches. • control flow codes om onder andere if, while en repeat toe te laten. • “.local” blokken, die toelaten dat de gebruiker registers reserveert voor een bepaald stuk code. De registers mogen voor en na dat blok code voor andere doeleinden gebruikt worden. Op deze manier moet men zelf niet in de gaten houden hoeveel en welke registers men gebruikt. Men hoeft ook geen rekening te houden met het verschil tussen blok A en blok B general purpose registers. De compiler zal alle registers zelf alloceren. Dit is natuurlijk niet altijd mogelijk (A-B conflicten, teveel registers gebruikt), en in dat geval geeft de compiler foutmeldingen. Dit is te vergelijken met het gebruik van variabelen bij andere talen. Variabelen zullen echter ook in het geheugen opgeslaan worden als alle register volzet zijn, terwijl hier enkel registers worden gebruikt.

Dispatchloop Dit deel van het programma voegt de microcode van de verschillende ACE-componenten samen. Elke component die gebruikt wordt moet eerst worden ge¨ınitialiseerd, door middel van een macro. Daarna wordt een oneindige lus gestart. Het eerste wat in deze lus gedaan wordt is typisch het ophalen van pakketten, ofwel van de netwerkpoorten (via de Ingress ACE), ofwel van een andere micro-engine. In beide gevallen wordt meestal ook gekeken of er pakketten van de core komen. Daarna worden de pakketten van de ene ACE naar de andere gebracht. Bij het buitengaan uit een ACE wordt nagekeken welke toestand deze ACE geeft. Is die 1, dan wordt het pakket gewoon naar de volgende ACE gestuurd. Is die “IX EXCEPTION”(voorgedefieneerde waarde) dan wordt het pakket naar de core gestuurd. Is die een andere waarde dan laat men het pakket typisch vallen (DROP). Uiteindelijk zullen de pakketten ofwel naar de volgende micro-engine gestuurd worden, ofwel via de Egress ACE verstuurd worden langs de netwerkpoorten.

2.4 NAT

2.4 2.4.1

11

NAT NAT Algemeen

Network Address Translation bestaat eruit het bron- en/of doeladres van pakketten aan te passen als ze door een (NAT-)router gaan. De reden om NAT te gebruiken is meestal om een gebrek aan IP adressen op te vangen (bevoorbeeld publieke internet adressen). In de rest van dit hoofdstuk worden de verschillende soorten NAT verduidelijkt adhv het netwerk uit Figuur 2.2.

Figuur 2.2: Voorbeeld netwerk

2.4.2

Statische NAT

Bij statische NAT wordt een N-N mapping gemaakt tussen de adressen van 2 netwerken. Deze mapping is vast. In het voorbeeld netwerk heeft netwerk A dan N clients (bijvoorbeeld 255 in netwerk A). In netwerk B heeft men (minstens) N vrije IP adressen, bevoorbeeld 192.168.1.0/8. De NAT router kent een statische mapping van lokale IP adressen op adressen van het andere netwerk. Alle clients uit netwerk A zijn dus bereikbaar via hun lokale IP adres (10.1.0.x) vanuit netwerk A, en via het gemapte IP adres (192.168.1.x) vanuit netwerk B. Verbindingen kunnen dus nog steeds uit beide richtingen opgezet worden. Het voordeel van statische NAT is ook dat men 2 netwerken aan elkaar kan koppelen zonder veel wijzigingen aan een van beide netwerken te maken. Enkel de NAT router die beide netwerken verbindt, “weet” dat er 2 netwerken zijn, en wat de mapping is. Statische NAT is vrij simpel en dus efficiënter dan dynamische NAT of NAPT. Als er genoeg IP adressen beschikbaar zijn is statische NAT daarom een goede oplossing.

2.4 NAT

12

Figuur 2.3: Statische NAT

2.4.3

Dynamische NAT

Bij dynamische NAT wordt een M-N mapping gemaakt tussen de adressen van 2 netwerken, waarbij M groter is dan N. Deze mapping is niet vast. In het voorbeeld is het verschil met statische NAT dan dat de IP adressen uit netwerk A geen vast overeenkomstig IP adres hebben op netwerk B. Pas als een PC uit netwerk A een pakket stuurt naar een PC uit netwerk B, wordt er een vrij IP adres uit netwerk B verbonden met het IP adres uit netwerk A. Als er geen verbindingen meer zijn tussen de client uit netwerk A en clients uit netwerk B wordt het IP adres weer vrijgegeven. Het is mogelijk dat alle adressen gebruikt zijn, en dan kunnen geen extra clients uit netwerk A toegang krijgen tot netwerk B. Ook weten gebruikers uit netwerk B nooit zeker via welk IP adres ze een bepaalde PC in netwerk A kunnen bereiken. Verbindingen kunnen dus enkel door PC’s uit netwerk A opgezet worden.

2.4.4

NAPT

Bij NAPT wordt naast het IP adres ook nog de TCP/UDP poort aangepast om een unieke mapping te krijgen. Op deze manier kunnen in het voorbeeld verschillende PC’s in netwerk A hetzelfde IP adres in netwerk B delen. Ook voor ICMP kan dit meestal (onder andere voor ping query en reply) door het ID aan te passen. Typisch gebruikt men NAT zoals bij statische en dynamisch NAT voor masquerading Er zijn echter ook andere toepassingen, zoals port forwarding en transparent proxy.

2.4 NAT

13

masquerading Zoals bij statische en dynamische NAT is het de bedoeling een netwerk toegang te geven tot een ander netwerk, zonder dat het netwerk de IP adressen uit het toegevoegde netwerk hoeft te kennen. In het voorbeeld kan men dan bijvoorbeeld netwerk A toegang geven tot netwerk B, en hiervoor slechts 1 IP adres van netwerk B gebruiken (192.168.0.1, het adres van de router). Als een pakket van A naar B gestuurd wordt zal de NAT router zowel het IP adres als de poort wijzigen. Het teruggestuurde pakket van B naar A kan dan analoog gewijzigd worden zodat zowel A en B niet weten dat er iets aan het pakket veranderd is. De NAT router moet hiervoor een tabel bijhouden met de gebruikte poorten. Het is mogelijk dat er zoveel verbindingen vanuit netwerk A met netwerk B zijn dat er geen vrije poorten meer zijn. In dat geval zullen geen nieuwe verbindingen meer kunnen opgezet worden. Men kan eventueel ook meerdere adressen uit netwerk B gebruiken om dit probleem te vermijden. Het voordeel tegenover statische en dynamisch NAT is dat er veel minder IP-adressen nodig zijn, het nadeel dat NAPT veel complexer is, en dus trager.

Figuur 2.4: Masquerading

port forwarding Bij port forwarding gaat men pakketten die naar een bepaalde poort van de router gaan omleiden naar een machine in het achterliggende netwerk. Een voorbeeld is poort 80(www) van de router omleiden naar een (of meerdere) lokale webserver(s).

2.4 NAT

14

Figuur 2.5: Port forwarding

transparent proxying Bij transparent proxy zal men bepaalde datastromen verplicht via een bepaalde applicatie omleiden. Typisch leidt men bijvoorbeeld alle tcp pakketten met poort 80 om naar een transparentproxyserver. Meestal staat die server op de router zelf.

Figuur 2.6: Transparent proxying

2.4.5

Enkele NAT problemen

NAT kan verscheidene problemen veroorzaaken, hieronder staan 2 typische problemen beschreven. Het eerste toont aan dat ook boven TCP niveau aanpassingen kunnen vereist zijn. Het tweede probleem toont aan dat NAT vrij complex kan worden om simpele problemen op te lossen.

2.5 Netfilter

15

FTP Bij active FTP wordt over de FTP controle-connectie het IP adres gestuurd waarmee de server de data-connectie moet opzetten. Dit IP adres is het lokale IP adres van de client, aangezien NAT voor zowel server als client transparant gebeurt. De NAT implementatie zal het IP adres in het “PORT” FTP pakket dus moeten wijzigen. Dit is moeilijk, aangezien het IP adres in ASCII wordt verstuurd, en er dus bytes kunnen verwijderd of toegevoegd worden! De lengte van het pakket moet dan aangepast worden. De volgende pakketten moeten dan op TCP niveau allemaal aangepast worden, omdat het sequence nummer zal wijzigen! Indien dit gedaan wordt moet er nog een probleem opgelost worden: de FTP server zal de verbinding maken met de client, nu met het IP adres van de NAT router, dus in de omgekeerde richting. De NAT router moet bij het wijzigen van het PORT commando dus onthouden dat er een connectie zal opgezet worden in de andere richting. Dit gehele probleem kan ook opgelost worden door passive FTP te gebruiken.

Forwarding binnen lokaal netwerk Stel dat een NAT router in het voorbeeldnetwerk alle pakketten van netwerk A die naar netwerk B poort 80 gaan moet omleiden naar 10.1.0.2, poort 8080. De server 10.1.0.2 zal dan een antwoord sturen naar de oorspronkelijke client, maar zonder langs de NAT router te gaan! De client zal het antwoord dus niet herkennnen als een antwoord op zijn oorspronkelijk pakket. Dit probleem kan opgelost worden door ook masquerading toe te passen, zodat niet alleen het doeladres gewijzigd wordt naar 10.1.0.2, maar het bronadres ook gewijzigd wordt naar 10.1.0.1 (de NAT router zelf). Als de server dan antwoordt, zal het antwoordpakket wel via de NAT router gaan.

2.5

Netfilter

2.5.1

Algemeen

Netfilter is een onderdeel van de linux 2.4 en 2.6 kernels. Het is een framework dat toegang tot de pakketten toelaat op verschillende punten in de “pakketstroom” doorheen de linux kernel.

2.5 Netfilter

16

Figuur 2.7: Transparent proxying binnen lokaal netwerk (correcte en foutieve manier)

2.5.2

Architectuur

Netfilter definieert voor elk protocol enkele “hooks”. Dit zijn punten waar pakketten onderschept kunnen worden door kernel modules die daarom vragen. In Figuur 2.8 staan de 5 netfilter hooks voor IPv4.

Figuur 2.8: De 5 netfilter hooks

In elke hook kan een kernel module zich registreren om de pakketten op te vangen. De module kan als het met een pakket klaar is, beslissen wat Netfilter ermee doet (doorlaten naar de volgende hook, laten vallen, verder negeren, ...)

2.5.3

Onderdelen

Netfilter bevat 4 onderdelen die gebruik maken van de hooks die het netfilter framework aanbiedt.

2.6 Checksum bij IP, TCP, UDP en ICMP

17

• iptables (packet classificatie en firewall) • NAT • Connection tracking (gebruikt door stateful firewall en NAT) • Backward-compatability naar vroegere linux firewall en NAT implementatie.

2.5.4

Netfilter en NAT

Het NAT gedeelte van netfilter maakt gebruik van het connection tracking gedeelte van netfilter. Dit gedeelte bepaalt tot welke bestaande connectie een pakket behoort. Voor NAT is dit nuttig, omdat alle pakketten van een connectie op dezelfde wijze behandeld moeten worden. NAT en connection tracking gebruiken de volgende Netfilter hooks: • PreRouting hook: connection tracking + opzoeken toe te passen NAT regel + wijzigen doel door NAT • Local out hook: wijzigen doel door NAT • PostRouting hook: wijzigen bron door NAT Het feit dat de bron na de forward hook gewijzigd wordt heeft te maken met de firewall die in de forwarding hook ingrijpt. Deze moet het gewijzigde doel zien, maar niet de gewijzigde bron. Ook het routing onderdeel moet uiteraard altijd het gewijzigde doel zien.

2.6

Checksum bij IP, TCP, UDP en ICMP

Vele internet protocollen bevatten een “checksum” field, om fouten in pakketten te kunnen opsporen. Bij NAT worden veranderingen aangebracht aan velden, en moet deze checksum dus worden aangepast. De velden die NAT kan wijzigen zijn: • IP bron- of doeladres • TCP (of UDP) bron- of doelpoort • ICMP ID


18

De checksum is altijd het 1-complement van de 1-complement som van alle betrokken 16-bit velden. De checksum zelf wordt niet meegerekend. Dit komt neer op het op 0 zetten van de checksum voor de berekening. De velden die gebruikt worden voor de berekening zijn: • IPv4: Alle velden van de IPv4 header. • TCP: TCP header + data + pseudoheader met bron IP adres, doel IP adres, protocol en lengte. • UDP: analoog TCP • ICMP: ICMP header + “data” (geen pseudoheader) Als NAT bijvoorbeeld het source IPadres aanpast, of een router vermindert de IP TTL, moeten de checksums van IP, TCP en UDP dus worden aangepast. Dit volledig herberekenen is inefficiënt. Het is mogelijk om de nieuwe checksum te berekenen door enkel gebruik te maken van de oude checksum en het gewijzigde veld voor een na de wijziging. Dit komt neer op: HC’ =

~(~HC - m + m’)

met: HC = oude header checksum HC’= nieuwe header checkum m

= oude waarde van het gewijzigde veld

m’ = nieuwe waarde van het gewijzigde veld ~

= 1-complement operator

Deze simpele methode in de praktijk niet bruikbaar. Er zijn 2 problemen. Om te beginnen gebruiken hedendaagse processoren 32 bit waarden ipv 16 bit waarden. Daarnaast gebruiken ze ook 2 complement ipv de 1 complement. Het bepalen van een formule om de 1 complement som te bepalen via 2 complement, is niet simpel. Er stellen zich onder andere problemen in randgevallen zoals de negatieve en positieve nul bij 1 complement. Volgens RFC 1624 [7] is de juiste formule: HC‘ = ~(~HC + ~m + m’)


19

Indien deze berekening wordt toegepast in 32-bit registers is er nog steeds een probleem, bij overflow zal de overflowbit verloren gaan. Hij zal in de eerste 16 bits van het 32 bit register terechtkomen. Om dit probleem op te lossen moeten we gebruik maken van “bit-folding”. Dit komt erop neer dat de eerste 16 bit van een 32 bit register bij de laatste worden opgeteld. In (pseudo-)C code komt dit neer op: checksum = (checksum & 0xffff) + (checksum >> 16); Door deze 2 methodes te combineren kan de checksum snel aangepast worden aan de nieuwe waarden.

AANPAK

20

Hoofdstuk 3

Aanpak 3.1

Inleiding

Van alle “hooks” die netfilter definieert zijn voor de implementatie van een NAPT component op de IXP slechts 2 hooks nodig. Namelijk de postrouting en de prerouting hook. De local in en de local out hook worden weggelaten aangezien er geen pakketten lokaal op de router mogen toekomen. Het lokaal verwerken van pakketten door de router is enkel nuttig als de router buiten routering andere diensten aanbiedt, en dus zelf IP-pakketten moet kunnen verzenden en ontvangen. De forward hook heeft dan geen nut meer, aangezien hij dan als enige juist voor de postrouting hook staat. Ook wordt de forwarding hook in het Netfilter model noch voor NAT, noch voor connection tracking gebruikt. Voor de IXP is een router component beschikbaar die dan tussen de 2 hooks in kan geschakeld worden. De prerouting hook zal eerst connection tracking doen, dan NAT toepassen voor alle NAT-manipulaties die het doel IP adres wijzigen. De postrouting hook zal NAT toepassen voor alle NAT manipulaties die het bron IP adres wijzigen. De 2 componenten van netfilter die verantwoordelijk zijn voor NAT, zijn het connection tracking gedeelte, en het eigenlijke NAT gedeelte. Connection tracking is belangrijk omdat elk pakket van een connectie op dezelfde manier gewijzigd moet worden. Bij het eerste pakket zal dus opgezocht worden wat er gedaan moet worden, bij de volgende pakketten van een connectie zal dezelfde manipulatie op het pakket worden toegepast. Om NAPT te implementeren op de IXP moet beslist worden hoe de taken tussen de core

3.2 Vingeroefening: Statische NAT implementatie

21

processor en de micro-engines verdeeld worden. Het initialiseren en reserveren van geheugen zal op de core gebeuren. Het eerste pakket van een connectie zal veel werk veroorzaken, en er zal een conntrack structuur in het geheugen moeten gealloceerd worden die onder andere bijhoudt hoe de pakketten gemanipuleerd worden (in beide richtingen van de connectie). Men kan dit werk best op de core doen. De volgende pakketten van een connectie kunnen dan volledig op de micro-engines afgehandeld worden. In Figuur 3.1 wordt schematisch weergegeven hoe de applicatie eruit zal zien. Bovenaan staan de netfilter hooks uitgebeeld, met daaronder de overeenkomstige delen van de core en micro-engine programma’s.

3.2

Vingeroefening: Statische NAT implementatie

Om het programmeren op de IXP1200 onder de knie te krijgen werd begonnen met het programmeren van een simpelere applicatie. Een implementatie van statische NAT was perfect als oefening. Statische NAT is veel minder complex als NAPT, maar toch veel complexer dan de “count” applicatie die Intel die als voorbeeld in de SDK opneemt. De implementatie van statische NAT is eenvoudiger dan die van NAPT. Voor statische NAT is geen connection tracking vereist. Ook is het nooit nodig om pakketten naar de core te sturen, zodat de core na het initiele configureren en starten niets meer doet. Een inkomend pakket komt via de ingress-ace in de statische NAT microcode terecht. De eerste stap is het lezen van de belangrijkste IP velden, zoals bron- en doeladres. Indien het pakket geen IP pakket is wordt het ongewijzigd naar de volgende ACE doorgestuurd. Hierna wordt in het geheugen opgezocht wat met dit pakket moet gebeuren. Het geheugen bevat een tabel die ge¨ınitialiseerd is door de core, en om beurten het originele adres en de vertaling bevat. Hieruit wordt afgeleid hoe het pakket gewijzigd moet worden. Vervolgens wordt het bron- of doeladres effectief aangepast, samen met de IP checksum die door de wijziging moet aangepast worden. Daarna wordt eventueel ook de TCP of UDP checksum aangepast. Ten slotte wordt het pakket doorgestuurd naar de volgende microACE, die het routeren zal doen. De geheugenstructuur die in de statische NAT implementatie gebruikt wordt om de vertaaltabellen in op te slaan, is zeer simpel. De micro-engine zal bij elk pakket de lijst in het geheugen moeten overlopen tot er een pakket gevonden werd, of het einde van de lijst bereikt wordt. Dit is inefficiënt bij grotere tabellen.

3.2 Vingeroefening: Statische NAT implementatie

Figuur 3.1: Schematische voorstelling NAPT applicatie

22

3.3 NAPT implementatie

23

Bij het implementeren werden reeds enkele pijnpunten van de IXP1200 micro-engines duidelijk. Zo wordt bij leesopdrachten niet automatisch het leesregister naar het schrijfregister getransfereerd. Bij het gebruik van de instructie ld field moet daar rekening mee gehouden worden. Ook is het zo dat een registervariabele die niet als local gedefinieerd wordt, automatisch als global beschouwd wordt. Dit levert bij tikfouten zeer moeilijk te ontdekken bugs op. Over het algemeen werd duidelijk dat het debuggen van de microcode zeer moeilijk is, wat het ontwikkelen erop vertraagt. Om deze reden werd er debug code ge¨ımplementeerd, alhoewel dit enige tijd kostte heeft het uiteindelijk veel tijd bespaard.

3.3

NAPT implementatie

De NAPT component is deels op de core geimplementeerd en deels op de micro-engines. Het deel op de core doet de initialisatie en verwerkt de eerste pakketten van connecties, het micro-engine deel doet de verwerkingen van normale (niet eerste) pakketten. Een deel van de implementatie doet connection tracking, en het andere deel implementeert met behulp hiervan effectief NAPT.

3.3.1

Connection Tracking

Met elke connectie is een structuur in het geheugen verbonden. Deze structuur (in C struct ip conntrack) houdt verschillende gegevens over de connectie bij: tupels van pakketten die tot de connectie behoren: • de status van de connectie • gegevens voor het opsporen van een timeout van de connectie • welke NAPT manipulaties er op deze connectie toegepast moeten worden

Opzoeken of pakket tot reeds bestaande connectie behoort Om efficient de conntrack structuur die bij een connectie hoort te kunnen opsporen, is er gebruik gemaakt van een hashtable in het SRAM geheugen.


24

Figuur 3.2: ip conntrack structuur

Het bron IP adres, het doel IP adres, de bronpoort(tcp/udp), de doelpoort en het protocolnummer van een pakket zijn voor elk pakket van een connectie hetzelfde. Deze gegevens vormen tesamen een ‘tupel’. Van deze tupel wordt via de hardware hashengine van de IXP1200 de hashkey gemaakt. Op elke plaats in de hashtabel staat het hoofd van een dubbelgelinkte lijst. Het eerste element van deze lijst bevat enkel een verwijzing naar het volgende en vorige (laatste) element van de lijst. Als deze beide naar het eerste element van de lijst verwijzen is de lijst leeg. De volgende elementen van de lijst zijn onderdelen van een ip conntrack structuur. Ze bevatten de verwijzingen naar volgende en vorige, een tupel en een verwijzing naar het begin van de conntrack structuur. Als in de via de hashkey gevonden lijst geen tupel voorkomt dat gelijk is aan van een pakket, dan is het pakket het eerste pakket van een nieuwe connectie. Dit algoritme is zowel op de micro-engines als op de core geimplementeerd. Op de core wordt namelijk nogmaals nagekeken of het pakket wel echt het eerste van een nieuwe connectie is. Indien dit pakket tot een reeds bestaande connectie behoort is er iets misgelopen. Het was ook mogelijk een enkelgelinkte lijst te gebruiken ipv een dubbelgelinkte. Een element toevoegen aan een enkelgelinkte lijst is even makkelijk, maar om een element te verwijderen,


25

moet de ganse lijst worden doorlopen. Het enige voordeel zou minder geheugengebruik zijn. Geheugengebrek is echter helemaal geen probleem. Het is ook mogelijk ipv de kop van een dubbelgelinkte lijst op elke plaats in de hashtabel te zetten, overal plaats te voorzien voor een vast aantal elementen. Deze aanpak biedt als nadeel tegenover een gelinkte lijst dat er een maximaal aantal elementen is. Als er meer elementen in de lijst moeten komen zal de nieuwe connectie geweigerd moeten worden. Naast het vermijden van wat overhead voor geheugenallocatie heeft deze aanpak geen echte voordelen. Het algoritme zal even efficient zijn als een dubbelgelinkte lijst , aangezien nog steeds alle elementen moeten overlopen worden tot een overeenkomstig element wordt gevonden.

Figuur 3.3: Voorbeeld Hashtabel

Verbinden connection tracking gegevens met pakket Op de micro-engines wordt bij elk pakket eerst opgezocht bij welke connectie het hoort. Indien de micro-engines geen bijhorende connectie vinden sturen ze het pakket naar de core die dan de connectie moet initialiseren. Tussen de verschillende stukken code op de micro-engine moet kunnen uitgewisseld worden tot welke connectie het huidige pakket behoort. Hiervoor wordt een vast micro-engine register gebruikt, waarin het adres van de ip conntrack structuur wordt bijgehouden. Er stelt zich hierdoor een probleem als een pakket door de router naar de core wordt gestuurd. Als dit pakket teruggestuurd wordt naar de micro-engines, is het register dat naar de conntrack


26

structuur verwijst niet meer ge¨ınitialiseerd. Er moet dus nogmaals voor het pakket opgezocht worden tot welke connectie het behoort. Om dit te vermijden wordt een achterpoort gebruikt, die het ACE model niet respecteert. Als het pakket door het micro-engine van de router naar de core moet worden gestuurd, wordt dit versturen uitgesteld, tot het pakket eerst door de postrouting hook op de micro-engine is gegaan. Aangezien de router geen probleem maakt van de gewijzigde source is dit in praktijk een bruikbare oplossing. Ditzelfde probleem zou ook optreden indien de verschillende netfilter hooks op verschillende micro-engines zouden lopen. In de huidige implementatie is dit echter (gelukkig) niet het geval. Allerlei trukjes kunnen gevonden worden om in dat geval het probleem op te lossen, maar in principe is er geen mooie oplossing. De oplossing die netfilter gebruikt in linux om het adres van de ip conntrack structuur met een pakket te verbinden, is het adres opslaan in een speciaal daarvoor voorziene plaats in de pakketbuffer. Op de IXP is dit niet mogelijk zonder de ingress en egress ACE zelf te schrijven. Ook de routercomponent zou in dat geval waarschijnlijk aangepast moeten worden. Daarom is het makkelijker een truk te gebruiken dan zelf reeds bestaande componenten te herschrijven.

Initialiseren van de conntrack structuur Bij het initialiseren van de ip conntrack structuur wordt eerst uitgezocht hoe het pakket in de antwoordrichting van de connectie eruit zal zien. Dit gebeurt door bron en doel adres om te draaien en ook de bron en doelpoort om te draaien. Vervolgens wordt de ip conntrack structuur ge¨ınitialiseerd en worden de tupels overeenkomstig met beide richtingen toegevoegd aan de hashtabel.

Verwijderen conntrack structuur Als een connectie ten einde is, moet de conntrack structuur verwijderd worden. Indien dit niet gedaan wordt, zal de hashtabel steeds voller raken, waardoor het opzoeken vertraagt. Ook zal NAPT de poorten uiteindelijk allemaal gebruiken, waardoor geen nieuwe connecties mogelijk zijn. Het verwijderen gebeurt door eerst de conntrack uit de hashtabel te verwijderen, en daarna het geheugen vrij te geven. Dit zal op de core gebeuren.


27

Weten wanneer een connectie ten einde is, is vrij moeilijk. Zelfs als men het laatste TCP pakket ziet (FIN ACK) mag men niet aannemen dat de connectie gedaan is (er is nog een ruime timeout tijd voorzien in het TCP protocol). Het is belangrijk te weten hoe lang geleden het laatste pakket van een connectie is gezien. Als dat langer is dan een bepaalde timeout-waarde mag men aannemen dat de connectie ten einde is. Op de IXP vormt is dit echter een probleem. Op een normale PC houdt men dit bij door bij elk pakket in de bijhorende ip conntrack structuur een timestamp te vernieuwen. Op de micro-engines van de IXP heeft men echter geen toegang tot zo’n timestamp. Veiligheid vormt een bijkomende moeilijkheid. Een aanvaller kan een hele hoop connecties initialiseren, maar nooit verder gebruiken. Op deze manier belast hij de IXP1200, omdat elk van zijn pakketten naar de core zal moeten. Dit is niet onmiddelijk te vermijden. Het is echter belangrijk dat deze nooit gebruikte connecties snel verwijderd worden. Zoniet zal het opzoeken in de hashtabel vertragen, en is de aanval dus nog effectiever. Een firewall op de IXP die aanvallen opspoort en aanvallers al op de micro-engines kan negeren zou een oplossing kunnen zijn. Er is in de implementatie wel een simpel protocol voorzien dat garandeerd dat, minimum 1 minuut en maximum 2 minuten na het laatste pakket van een connectie, de conntrack structuur wordt opgeruimd. Dit is niet ideaal, maar bruikbaar voor testdoeleinden. Slechts bij zware belasting is dit niet ideaal. Aanvallen worden hierdoor ook niet tegengehouden.

3.3.2

NAPT

Manipuleren pakket De ip conntrack structuur bevat onder andere 2 ip nat info structuren. Eén voor de originele richting van pakketten in de connectie, en één voor de antwoordrichting. Hierin worden volgende dingen bijgehouden: • Of er een manipulatie gedaan moet worden, en welke (bron of doel wijzigen) • Het nieuwe IP adres en de nieuwe poort nodig voor de wijziging. De microcode zal een manipulatie van het doel uitvoeren voor het routeren, zodat het pakket door de router naar de juiste plaats wordt gestuurd. Een manipulatie van de bron zal na het


28

routeren gebeuren. De router houdt geen rekening met het bronadres, dus zou deze manipulatie ook voor het routen mogen. Voor een eventuele firewall die in het netfilter model wordt ingeschakeld is dit echter wel belangrijk. De firewall mag niet zien dat het bronadres van een pakket gewijzigd wordt door NAT. Bij een firewall in het netfilter model wordt daarom gefilterd in de forwarding hook, dit is na het routeren, maar voor de postrouting hook. Subroutines zijn praktisch niet erg bruikbaar op de micro-engines. Daarom is het hele stuk microcode dat de manipulatie doet gekopieerd. Hetzelfde stuk code staat dus zowel voor als na de oproep van de router. Door middel van een register weet dit stuk code of het voor of na het routeren komt, en dus welke manipulatie het moet uitvoeren.

Opzoeken toe te passen regel Op de core zal bij het verwerken van het eerste pakket van een connectie de NAT regel die erop toegepast wordt, opgezocht worden. De NAT regels staan in het geheugen opgeslagen nadat ze, bij de initialisatie van het programma, uit een bestand zijn ingelezen. Voor elke regel zijn er voorwaarden, die bepalen wanneer hij wordt toegepast, en een actie, die bepaalt wat er precies moet gedaan worden. Als er geen voorwaarden zijn, wordt de regel altijd toegepast. Als er meerdere voorwaarden zijn wordt de regel enkel toegepast als aan allen voldaan is. De voorwaarden zijn: • Via een bepaalde interface de IXP binnenkomen • Een bepaald doel of bron IP adres hebben (1 bepaald adres, of een adres dat in een bereik valt) • Een bepaalde doel- of bronpoort hebben (tcp of udp) Er is code voorzien om ook de interface langs waar het pakket zal buitengaan na het routen als voorwaarde te gebruiken. De implementatie daarvan ontbreekt nog een (inefficiënte) cross-call naar de router ACE. De acties zijn SNAT of DNAT. Er is ook statische en dynamisch NAT voorzien, maar enkel als illustratie dat dat ook kan, zonder veel code te wijzigen. Er moet nog code bijgeschreven worden op de core om alle mogelijkheden van statische en dynamische NAT te kunnen gebruiken. Met SNAT wordt bedoeld dat de bron van het eerste pakket van een connectie wordt gewijzigd. Dit


29

is het geval bij masquerading. Met DNAT wordt bedoeld dat het doel van het eerste pakket van een connectie wordt gewijzigd. Dit is het geval bij port forwarding en transparent proxy. Als er voor een eerste pakket van een connectie meerdere toe te passen regels zouden zijn, wordt enkel de eerste regel toegepast. De volgorde van de regels is de volgorde zoals ze in de configuratie-bestand staan. Het is mogelijk bij SNAT een gans bereik IP adressen op te geven. Deze worden dan het bron IP adres van pakketten die door de NAPT router gaan. De NAPT implementatie behandelt dit geval zonder probleem, maar men moet de router in dit geval wel anders instellen. De router moet namelijk weten dat hij meerdere IP adressen heeft op dezelfde poort.

Parsen NAPT regels Het inlezen van de regels uit een bestand gebeurt met behulp van een door flex gegenereerde parser. Met behulp van een simpele LL(1) taal worden de regels geparsed. Spaties en newlines worden voor het grootste deel genegeerd, om het de gebruiker makkelijk te maken. De parser is wel hoofdlettergevoelig. Meer details over de syntax zijn te vinden in het voorbeeldbestand dat bij de implementatie zit (NAT.rules). Hieronder een voorbeeld van een regel:

RULE TARGET destip=ip10.1.0.15 dstTCPport=port2121 ACTION DNAT targetip=ip10.1.0.2 targetTCPport=port21 In dit voorbeeld zullen alle pakketten die naar 10.1.0.15:2121 gaan herleid worden zodat ze naar 10.1.0.2:21 gaan. In bijlage B is de configuratiefile weergegeven. Deze file bevat meer details ivm de syntax.


30

Opzoeken vrije poorten Bij het bepalen hoe SNAT op een regel moet toegepast worden, moet een vrije poort op een IP adres van de router gevonden worden. Hiervoor is een hashtabel voorzien die bijhoudt welke poorten door de NAPT implementatie gebruikt worden. Als een poort niet in de hashtabel voorkomt, wordt ze niet gebruikt. Bij het zoeken van een ongebruikte poort wordt begonnen met zoeken bij de gebruikte poort van het pakket. Als die bezet is, wordt de volgende poort onderzocht, tot er zo een ongebruikte wordt gevonden. In de NAT informatie in de ip conntrack structuur wordt een plaats voorzien die een link naar de gebruikte poort in deze hash bijhoudt. Op deze manier kan zeer snel de verwijzing uit de hash genomen worden als de connectie afgelopen is.

3.3.3

Praktische problemen en oplossingen

Virtueel geheugen en fysische offsets De programma’s die op de core draaien, maken gebruik van virtueel geheugen. Deze adressen zijn totaal verschillend van de fysische offsets die de micro-engines gebruiken om toegang tot het geheugen te krijgen. Dit verschil moet opgevangen worden op de core, door voor elk adres dat ook door de micro-engines gebruikt moet worden, de fysische offset te gebruiken. De dubbelgelinkte lijsten die door onder andere het connection tracking gedeelte gebruikt worden, zullen dus als referentie naar het volgende element een fysische offset bevatten, en geen virtueel geheugenadres. Op de core kan gebruik gemaakt worden van functies van de Resource Manager , die onderdeel is van de SDK, om de omzetting van virtueel geheugen naar fysische offset te doen (en omgekeerd). In de praktijk blijkt dat voor bijvoorbeeld SRAM geheugen het offset 1 altijd overeenkomt met virtueel geheugen adres 0xf4000000 + 4. De offset, die in longwords is, wordt eerst naar bytes omgezet, dus met 4 vermenigvuldigd. Dan wordt hij opgeteld bij de start van het SRAM virtueel geheugen. Deze berekening wordt intern door de functies van de Resource Manager gedaan.

Variabele headerlengte IP De IP headerlengte is in principe niet vast bij IPv4. In de microcode is een punt voorzien om daar rekening mee te houden, maar de code om hier rekening mee te houden (een tiental lijnen) is niet geschreven. In de praktijk komt een afwijkende headerlengte dan ook uiterst


31

zelden voor. In het nieuwe IPv6 protocol komt zelfs nooit meer een variabele headerlengte voor. In de huidige implementatie zou een niet standaard IP headerlengte problemen geven ivm de localisatie van UDP, TCP en ICMP velden. Aangezien de checksum velden ook niet goed zullen worden aangepast zullen pakketten met variabele headerlengte verloren gaan.

Checksums bij IP, TCP en UDP Zowel het IPv4 protocol, het TCP protocol en het UDP protocol houden in hun checksum rekening met het IP bron- en doeladres. Deze checksum is met andere woorden ongeldig als een IP adres wijzigt. In microcode wordt de nieuwe checksum herberekend aan de hand van de oude checksum en de gewijzigde waarden.

ICMP ipv TCP of UDP In de ganse uitleg gaat het bij connecties altijd over de TCP en UDP poorten. Als men ook ICMP ping wilt kunnen gebruiken doorheen de NAPT router, volstaat het om in de bestaande algoritmes de TCP doel poort te vervangen door de ICMP ID en de TCP bronpoort door ICMP type en code (samen 16 bit). In plaats van een unieke poort moet dan gezorgd worden voor een uniek ID, aangezien door de ID’s verschillende “ping connecties” onderscheiden kunnen worden. Als een ICMP echo request pakket naar de core gestuurd wordt, om er masquerading op toe te passen, zal de core applicatie een uniek ongebruikt ID opzoeken. Het pakket zal dan een gewijzigd bron IP adres krijgen, en de oorspronkelijke ID zal vervangen worden door de nieuwe unieke ID. Bij het antwoord, een echo reply pakket, zal het doel IP adres en het ID gewijzigd worden.

Synchronisatie Het is mogelijk dat verschillende core threads, en verschillende micro-engines tegelijkertijd hetzelfde geheugen gebruiken en manipuleren. Dit kan tot vreemde bugs en crashes leiden. Kritieke punten in de implementatie zijn hier het toevoegen en verwijderen aan de conntrack hashtabel. Een probleem ontstaat wanneer een UDP connectie start, en meerdere pakketten achtereenvolgens naar het doel stuurt, zonder op een antwoord te wachten. Terwijl het eerste pakket op weg is naar de core, zal het volgende pakket onderzocht worden door de micro-engines en ook naar de core gestuurd worden, aangezien de core de nieuwe connectie nog niet heeft ge¨ınitialiseerd. Dit


32

kan vermeden worden door de linkedlist in de hashtabel te locken als een pakket naar de core gestuurd wordt, en te unlocken als de core het terugstuurt nadat de connectie ge¨ınitialiseerd is. Deze oplossing geeft echter problemen, omdat alle threads op de micro-engine geblokkeerd zullen worden, terwijl ze wachten op het vrijgeven van het lock op de core. Op dat moment wordt de verwerking van pakketten alsnog vertraagd. Om dit probleem echt op te lossen moet de vertraging om een pakket naar de core te sturen verminderd worden. Het probleem doet zich overigens nooit voor bij TCP connecties, aangezien daar een 3-way handshake wordt gebruikt en het eerste pakket al verwerkt moet zijn voor het 2de, in de antwoordrichting, wordt verstuurd. Bij het verwijderen van een connectie is er ook een probleem ivm synchronisatie. Alle problemen die hier kunnen voorkomen, zijn zeer subtiel en zullen slechts zeer zelden voorkomen. Aangezien ze echter kunnen voorkomen, is het beter om de linkedlist te locken voor er items uit verwijderd worden. Alle code is hiervoor voorzien, maar in de praktijk moet dit locken op de core gebeuren, en dat blijkt niet praktisch mogelijk, met de hardware CAM locks. In theorie is het mogelijk om de hardware locks van de IXP te gebruiken vanop de core, maar in de praktijk werd geen mogelijkheid gevonden om dit te doen. Een oplossing voor dit probleem is het creëren van eigen locks via atomaire geheugenacties die wel vanop de core gebruikt kunnen worden. Synchronizatie is in de NAPT implementatie onvolledig ge¨ımplementeerd, waardoor bepaalde UDP connecties problemen kunnen opleveren. De problemen zullen meestal beperkt blijven tot vertragingen bij het initialiseren van connecties maar kunnen ook aanleiding geven tot pakket loss bij het begin van een connectie. In extreme gevallen crasht de IXP1200 ook door de grote hoeveelheid pakketten die naar de core gestuurd worden! Een connectie die eenmaal ge¨ınitialiseerd is zal geen hinder ondervinden door dit probleem. Qua veiligheid biedt synchronisatie geen oplossing. Het kan enkel zorgen dat pakketten van dezelfde connectie geen problemen veroorzaken. Een aanvaller hoeft dus maar verschillende connecties te gebruiken.

Debugmogelijkheden op de micro-engines Het is niet makkelijk om de code op de micro-engines te debuggen. De enige manier om te zien wat er gebeurt is te kijken naar de pakketten die de IXP1200 verlaten, of naar de pakketten die naar de core gestuurd worden.

3.4 Beperkingen & tekortkomingen

33

Om het debuggen te vergemakkelijken heb ik daarom een beperkt boodschappen systeem uitgewerkt dat de micro-engines toelaat boodschappen of zelfs info over pakketten door te sturen naar de core zonder het volledige pakket door te sturen. De code maakt gebruik van scratchpad geheugen. Dit geheugen wordt door de core gereserveerd, en de core zal geregeld nakijken of er berichten in opgeslaan werden door de micro-engines. Indien een bericht van de micro-engines naar de core werd gestuurd wordt dit gewoon op het scherm uitgeschreven. De berichten die de micro-engines versturen bestaan uit slechts enkele 32-bit getallen, en een identificatiecode. Het is ook mogelijk om pakketinfo door te sturen. Na het versturen van een bericht zal de micro-engine de normale verwerking gewoon kunnen verderzetten. Als de core niet op tijd oude berichten verwijdert, zullen nieuwe berichten verloren gaan. Dit systeem laat toe makkelijker fouten in de microcode op te sporen, maar werd in de finale versie van de applicatie volledig uitgeschakeld om onnodige vertragingen te vermijden.

3.4

Beperkingen & tekortkomingen

De NAPT implementatie zelf kan veel maar is toch beperkt in functionaliteit en gebruikt niet de volledige capaciteit van de IXP1200. Ook zijn er nog enkele kleine problemen en schoonheidsfoutjes. Hieronder een opsomming: • Het is voor het ogenblik enkel mogelijk 1 NAT regel toe te passen per connectie. Voor ingewikkeldere netwerkopstellingen zijn soms meerdere regels vereist. Dit vereist een wijziging in de nat info structuur van de conntrack structuur. Ook moeten regels op het ogenblik ingevoerd worden voor de applicatie gestart wordt, en kunnen ze daarna niet meer gewijzigd worden. Beide beperkingen zijn zeker wegwerkbaar zonder veel problemen. • Er zit ook nog een probleem in de huidige implementatie dat veroorzaakt wordt door het trage doorsturen van pakketten naar de core. Deze geeft extra vertraging aan alle eerste pakketten van connecties die met meerdere pakketten beginnen. Dit probleem kan niet echt verholpen worden maar kan met behulp van onder andere synchronisatie misschien kleiner worden. • De gehele implementatie zou veel “mooier” zijn, moest het mogelijk zijn extra info bij een pakket bij te houden die zowel op de micro-engines als op de core processor toegankelijk zijn zonder veel overhead. De info die bijgehouden moet worden is het adres van de ip conntrack

3.4 Beperkingen & tekortkomingen

34

structuur behorende bij het pakket, en omwille van kleine optimalisaties misschien nog wat extra data. Het opvragen van die informatie moet efficiënt zijn op zowel de micro-engines als de core, en de extra informatie mag de werking van de bestaande ingress, egress en router component niet verstoren. Dit is een zware eis, en er is niet direct een oplossing te vinden die hieraan voldoet. Voor het toevoegen van functionaliteit zoals een firewall zal dit probleem zeer waarschijnlijk opgelost moeten worden. • Een andere verbetering zou het opsplitsen van de code over meerdere micro-engines zijn. Dit is niet mogelijk zolang het vorige punt niet opgelost wordt. Het opsplitsen over meerdere micro-engines zou de performantie verbeteren, omdat de volledige capaciteit van de IXP1200 gebruikt zou worden. Het gebruiken van meer dan 2 micro-engines blijkt met de beschikbare SDK niet triviaal te zijn. De beschikbare ixstart applicatie zal ervoor moeten gewijzigd, of zelfs opnieuw geschreven, worden.

METINGEN EN RESULTATEN

35

Hoofdstuk 4

Metingen en resultaten Overzicht In dit hoofdstuk worden de metingen en resultaten besproken. Het doel van de metingen is meer te weten te komen over de performantie van de IXP1200 netwerkprocessor, en van de NAPT implementatie. Interessante data zijn de veroorzaakte latentie en de pakketratio, dit is de maximum hoeveelheid pakketten die per seconde kan verstuurd worden. Eerst wordt nagegaan, met behulp van de specificaties van de IXP1200 netwerkprocessor, welke performantie er theoretisch verwacht mag worden. Dit zal eerder een bovengrens zijn, die het ideale geval beschouwt. Vele metingen werden uitgevoerd met behulp van de Smartbits 2000 netwerktester. De Smartbits 2000 is een apparaat dat samen met de bijhorende software testen kan uitvoeren op een netwerk, en de resultaten gedetailleerd in grafieken en tabellen kan weergeven. Testen bestaan erin een serie (ip) pakketten van de ene kant naar de andere te sturen en de latentie en het eventueel pakketverlies te meten. Dit soort testen zijn niet ideaal om de NAPT implementatie te testen, aangezien het niet om echte connecties gaat. Dit veroorzaakt een probleem omdat alle testen starten met het sturen van meerdere pakketten. De NAPT implementatie zal die allemaal naar de core sturen zolang op de core het eerste pakket niet aangekomen en verwerkt is. Dit geeft een onrealistische vertraging die er bij normale TCP-connecties niet is. Om dit op te lossen werden bij het testen de functies die connecties verwijderen als ze inactief zijn uitgeschakeld, en werd de eerste test onmiddellijk afgebroken op het moment dat de test-connecties door de core verwerkt zijn. De gebruikte resultaten zijn de resultaten van de tweede test.

4.1 Theoretische voorspellingen

36

Voor alle testen op de Smartbits werd de “burst size” op 1 gezet, aangezien dit de meest stabiele oplossingen blijkt te geven. De default instelling is 24, maar de resultaten die daarmee bekomen worden verschillen van test tot test en zijn soms totaal onverklaarbaar. Verder werd TCP gebruikt als het protocol bovenop IP. Dit betekent niet dat er TCP-connecties opgezet worden. Dit houdt enkel in dat elk pakket dezelfde TCP header bevat. De instelbare pakketgrootte bij de Smartbits moet volgens de helpfunctie van de Smartflow software ge¨ınterpreteerd worden als de ethernet framegrootte, inclusief “CRC en header data”. De Smartflow software die gebruikt werd om met de Smartbits tester te werken bleek niet geheel conform aan RFC 1242 [1] te testen. Deze RFC definieert latentie bij “cut-through” en bij “store-and-forward” netwerkapperatuur. De Smartflow software test enkel “cut-through”. Om deze resultaten om te zetten naar “storeand-forward” resultaten moet van de resultaten nog de transfertijd over een 100mbit lijn worden afgetrokken, dit is

p·8 100·1024·1024

met p de pakketgrootte.

Met de Smartbits kan niets getest worden ivm de latentie van het eerste pakket van een connectie. Er is wel een serieuze extra vertraging als de eerste pakketten van een Smartbits “Smartflow” naar de core worden gestuurd, maar door overbelasting is die groter dan de vertraging die 1 pakket zou veroorzaken. Het is trouwens ook niet mogelijk enkel de resultaten van die eerste pakketten te achterhalen. Daarom werd dit niet gestest met de Smartbits 2000, maar met de ping applicatie, die de retourtijd van elk pakket weergeeft. Er werd ook een simpele test uitgevoerd met behulp van wget. Deze test gaat na of de downloadsnelheid over een FTP verbinding invloed ondervindt van de applicaties op de IXP1200 netwerkprocessor.

4.1

Theoretische voorspellingen

Beschrijving Uit de specificaties van de IXP1200 netwerkprocessor kunnen we theoretisch afleiden wanneer de NAPT implementatie de toevoer aan pakketten niet meer kan bijhouden en dus pakketverlies zal veroorzaken. Onderstaande berekeningen zullen een ruwe schatting opleveren, door middel van tests zal de nauwkeurigheid ervan moeten worden nagegaan. Omdat vele veronderstellingen in deze berekening van het ideale geval uitgaan zal de uitkomst een bovengrens vormen. We nemen voor de berekening aan dat er geen pakketten naar de core gestuurd worden, en de


37

conntrack structuren behorende bij de connecties al ge¨ınitialiseerd zijn. De NAPT implementatie is vooral op 1 microengine van de IXP1200 werkzaam. Als deze overbelast is zullen de binnenkomende pakketten niet op tijd verwerkt worden, zullen de buffers overlopen en zullen er pakketten verloren gaan. We kunnen berekenen wanneer dit zal gebeuren. Het aantal microcode lijnen dat een programma lang is kan dmv de output van de microcode assembler worden gemeten. Het programma wordt gecompiled zonder router en NAPT implementatie, vervolgens met enkel router en vervolgens met router en NAPT. Telkens kijken we naar het totaal aantal lijnen microcode. Op deze manier kan het aantal lijnen microcode per onderdeel afgeleid worden. Merk op dat in de NAPT code 2 vrij identieke stukken code bevat, waarvan er per pakket maximum 1 wordt uitgevoerd. Bij het tellen van het aantal lijnen microcode werd daarom 1 van beide stukken niet meegerekend. Het aantal microcode lijnen is samengevat in Tabel 4.1 Ingress ACE

Router ACE

NAPT ACE

Totaal

611

177

286

1074

Tabel 4.1: Aantal microcode lijnen per ACE

Elke microengine draait aan 233Mhz, dat is 4 ns per klokcycle. De meeste instructies duren slechts 1 klokcycle. Spronginstructies en geheugenopdrachten zullen langer duren maar worden in deze berekeningen buiten beschouwing gelaten. Bij geheugentoegang moet eerst de microcode instructie worden uitgevoerd, dit duurt minstens 1 klokcycle. Vervolgens moet de geheugenaanvraag gedaan worden en moet gewacht worden op het antwoord van het geheugen, dit duurt bij SDRAM minstens 6 ns volgens de specificaties. Daarna moet de data ook nog getransfereerd worden. Geheugentoegang zal de microengines echter niet veel vertragen, aangezien er naar een andere thread geswitched wordt en een andere thread kan voortwerken terwijl uit het geheugen wordt gelezen. De ingress ACE zal onder andere het pakket naar het SDRAM geheugen kopiëren, en deze operatie neemt enige tijd in beslag. Bij een 64 byte pakket is dit te verwaarlozen, maar bij een 1500 byte pakket niet. Volgens de specificaties van de IXP1200 bedraagt de piekbandbreedte van het SDRAM geheugen zo’n 928 Mbytes per seconde. In het beste geval duurt het transporteren van 1500 bytes dus 1541 ns, of zo’n 385 klokcycli. 64 bytes vereist zo slechts 66 ns, of 17 clockcycli.


38

Als we het aantal klokcycli nodig bij 1 pakket dan schatten, en naar boven afronden komen we aan zo’n 1200 klokcycli. Daarbij tellen we dan de 400 klokcycli van de geheugentranfer bij op. In formulevorm wordt dit: Pakketgrootte: Klokcycli per pakket:

ps cpp

Aantal pakketten per seconde (packetrate):

pr =

Overeenkomstige bandbreedte(M bit/s):

bb =

232·1024·1024 cpp pr·ps·8 1024·1024

Resultaten De formule levert Tabel 4.2 op. Enkele interessante pakketgroottes werden weergegeven. pakketgrootte (bytes)

pakketratio (pakketten/s)

bandbreedte (M bit/s)

64

199401

97

76

198790

115

512

178875

699

1024

160046

1250

1408

148335

1593

1500

145780

1668

Tabel 4.2: Theoretische pakketratio en bandbreedte

Bespreking Het is belangrijk op te merken dat deze resultaten zeker moeten nagegaan worden aan de hand van metingen. Deze resultaten zijn namelijk slechts een ruwe schatting. Het is hierbij duidelijk dat bij de normale pakketgrootte van 1500 bytes, het onmogelijk is de NAPT implementatie te overbelasten op de ENP-2505 kaart. Zelfs indien er 2 gigabit poorten verbonden zouden zijn met de IXP1200 zou de datastroom daardoor (1 gigabit) zeker verwerkt kunnen worden. Bij pakketten van 64 byte ligt de pakketratio hoger, maar de bandbreedte zal uiteraard sterk dalen. Deze test zou verifierbaar moeten zijn op de ENP-2505 kaart.

4.2 Thoughput en pakketgrootte bij verschillende implementaties

4.2

39

Thoughput en pakketgrootte bij verschillende implementaties

Beschrijving De Smartbits kan adhv testen automatisch de throughput berekenen. Onder throughput wordt verstaan de belasting waarbij er geen pakketverlies optreedt. Bij de test werd gebruik gemaakt van 2 van de 4 poorten van de ENP-2505 kaart. De throughput werd bij verschillende pakketgroottes en verschillende IXP programma’s getest. De pakketgrootte varieerde, in stappen van 128 byte, van 128 tot 1408 bytes. De geteste programma’s zijn: • De alleenstaande router • De router en NAPT implementatie, zonder NAT regel toe te passen, dus enkel connection tracking. • De router en NAPT implementatie, met een toegepaste SNAT regel. Tijdens het testen bleek de waarde van de throughput bij pakketgrootte 1152 (9,4375) altijd een tiende van de waarde bij 1024 (94,375) te zijn. Bij een afzonderlijke test van de throughput bij pakketgrootte 1152 bleek de waarde echter tussen de waarden van 1024 en 1280 te liggen, namelijk 95,078. Het is daarom waarschijnlijk dat die afwijkende waarde aan een software bug in de Smartflow applicatie te wijten is. In de grafiek werden daarom de waarden van de naderhand gedane tests voor pakketgrootte 1152 gebruikt.

Resultaten Bespreking De throughput stijgt duidelijk bij toenemende pakketgrootte, en dat is logisch omdat er overhead verdwijnt. De resultaten liggen allemaal zeer dicht bij de theoretische bovengrens van een 100mbit ethernetverbinding bij de verschillende pakketgroottes. De resultaten van de verschillende programma’s liggen bijna even dicht bijeen als de nauwkeurigheid van de resultaten. Zowel de schommeling tussen verschillende testen, als de nauwkeurigheid waarmee de Smartflow applicatie de throughput test, liggen in de buurt van het verschil tussen de

4.2 Thoughput en pakketgrootte bij verschillende implementaties

40

Figuur 4.1: Throughput vs pakketgrootte

resultaten. Aangezien de waarden tussen verschillende tests schommelen kan de nauwkeurigheid niet verhoogd worden. Het is wel te zien dat, zoals te verwachten, de alleenstaande router meestal een iets hogere throughput haalt. Bij stijgende pakketgrootte komen de resultaten dichter bijeen. Er kan niet gezegd worden dat de resultaten precies samenvallen omdat de meting niet zo nauwkeurig is, maar het is zeer waarschijnlijk dat bij hogere pakketgrootte de verschillende throughput waarden dichter bij elkaar komen. Dit is logisch aangezien er minder pakketten zijn, en dus minder tijdsverschil tussen de router en de NAPT implementatie. Ook vergt het transfereren van pakketten van en naar het geheugen meer tijd, en dit gebeurt bij zowel de alleenstaande router als bij de NAPT implementatie. Deze test was volkomen voorspelbaar, aangezien er zoals te verwachten geen overbelasting van de IXP1200 optreed en de 100mbit lijn dus de bottleneck vormt.

4.3 Latentie en verschillende applicaties

4.3

41

Latentie en verschillende applicaties

Beschrijving De latentie werd gemeten bij verschillende applicaties, bij een pakketgrootte van 1408 byte en een variable belasting van 10% tot 100%, in stappen van 10%.

Resultaten De gemeten latentie was onafhankelijk van de belasting (behalve bij 100% belasting, waar de grenzen worden bereikt van de 100mbit ethernetlijn). De gemiddelden van de gemiddelde latentie bij belasting tot 90% weergegeven in Tabel 4.3 Applicatie

gemiddelde latentie (µs)

Router

23.89

Router + Conntrack

27.96

Router + Conntrack + NAPT

27.92

Tabel 4.3: Latentie bij verschillende applicaties

Er dient ook opgemerkt te worden dat het verschil tussen de minimum en maximum latentie bijna altijd zo’n 10µs bedraagt. Het verschil tussen de gemiddelde latentie bij verschillende tests loopt soms op tot 2.5µs.

Bespreking Het valt op dat het al dan niet toepassen van een NAPT regel geen verschil maakt. De NAPT code is dan ook vrij klein, en kent weinig geheugentoegangen (ongeveer 3). De conntrack code uitvoeren blijkt 4 µs te duren, en dit is vrij veel. Uit de theoretische berekeningen blijkt een veel lager getal (286 · 4, 11ns = 1, 18µs). Dit getal is uiteraard slechts een ruwe schatting, en eerder een ondergrens. Alhoewel de gemiddelde latentie vrij stabiel bleek, is deze test toch niet erg betrouwbaar. De schommelingen tussen verschillende tests zijn te groot.

4.4 Latentie en pakketgrootte

4.4

42

Latentie en pakketgrootte

Beschrijving Bij deze test werd met de Smartbits de latentie gemeten bij verschillende pakketgroottes. Er werd enkel gebruik gemaakt van de router ACE. De belasting was elke keer 10%.

Resultaten De resulaten zijn samengevat in Figuur 4.2

Figuur 4.2: Latentie vs pakketgrootte

Ook bij deze latentie test was het verschil tussen de minimum en maximum latentie bijna altijd zo’n 10µs. Het verschil tussen verschillende tests was ook enkele µs.

Bespreking De stijging in de grafiek is zeer miniem, 4 µs meer bij pakketten van 1408 byte dan bij pakketten van 128 byte. De stijging in tijd wordt veroorzaakt door het kopieren van het pakket van

4.5 Thoughput & latentie bij gebruik van meerdere poorten

43

de IX bus naar het geheugen. De IXP1200 is geoptimaliseerd voor deze bewerking, en dit blijkt ook uit deze test. Per pakket moet ze 2 maal gebeuren, 1 maal van de bus naar het geheugen (bij het ontvangen), en eenmaal van het geheugen naar de bus (bij het verzenden). Als we van de latentie bij 1408 byte de latentie bij 128 byte aftrekken bekomen we een schatting voor de tijd nodig om 1280 byte 2 maal te transfereren. Hieruit kunnen we een schatting voor de geheugentransfersnelheid bekomen, namelijk 610 MB/s. Dit is zeer hoog voor kleine hoeveelheden data, aangezien de piek bandbreedte van het geheugen is 928MB/s. De verwerkingstijd, zonder geheugentransfer is 18 µs. In deze tijd wordt het pakket volledig afgehandeld door de IXP1200. Het wordt op de bus gezet, in het geheugen gebuffered, door de ingress ACE gelezen, door de router ACE verwerkt, door de volgende microengine gezien, door de egress ACE verwerkt, op de bus gezet en weer verzonden.

4.5

Thoughput & latentie bij gebruik van meerdere poorten

Beschrijving Bij de vorige test werden slechts 2 poorten van de ENP-2505 gebruikt. Het is interessant om dezelfde tests uit te voeren op 4 poorten, en de throughput en latentie te vergelijken. Bij de throughputtest test werd de throughput gemeten bij een pakketgrootte van 1408 bytes, en bij een datastroom (enkelrichting) van poort 0 naar poort 1. Bij de test met 4 poorten kwam er een datastroom van poort 2 naar poort 3 bij. De latentie van de pakketten werd gemeten bij een pakketgrootte van 1408 bytes. Zoals bij de throughput-test ging een datastroom (enkelrichting) van poort 0 naar poort 1. Bij de test met 4 poorten kwam er een datastroom van poort 2 naar poort 3 bij.

Resultaten De latentie bleef constant tot 90%. De resultaten tot 90% belasting zijn: • Latentie bij gebruik 2 poorten: gemiddeld 26.6 µs. • Latentie bij gebruik 4 poorten: gemiddeld 29.0 µs. De latentie stijgt dus bijna 3 µs.

4.6 Throughput bij theoretische grenzen

44

De throughputberekeningen kwamen uit op: • Throughput bij gebruik 2 poorten: 97.19 % maximum. (pakketratio 8 507 pakketten per seconde) • Throughput bij gebruik 4 poorten: 95.78 % maximum. (pakketratio 16 768 pakketten per seconde)

Bespreking De extra latentie kan verklaard worden door het gebruik van een gezamelijke IX bus voor de poorten. Het parallel verwerken van 2 pakketten op de microengines zal ook beide pakketten vertragen. Ook het gebruik van het geheugen zal een vertraging veroorzaken. Bij het gebruik van slechts 2 poorten, heeft elk pakket de volledige IXP1200 voor zich alleen. Als er 4 poorten gebruikt worden zullen 2 pakketten de IXP1200 moeten delen, en dat veroorzaakt lichte vertragingen bij het wachten op gedeelde resources. De throughput daalt bij dubbele belasting, maar de daling is vrij klein. De verklaring ligt waarschijnlijk in het gedeelde gebruik van gezamelijke bronnen (IX bus, geheugen, e.d.) op de IXP1200. Dit gedeelde verbruik vertraagt de pakketten, en samen met de maximaal belaste 100mbit lijnen veroorzaakt dit pakketverlies. Het is duidelijk dat de 100mbit poorten de beperkende factor zijn bij deze testen. De pakketratio van bijna 17 000 pakketten per seconde kan zonder probleem door de IXP1200 worden bijgehouden. Dit is logisch aangezien er volgens de theoretische voorspellingen pas problemen optreden bij een 10 keer hogere belasting.

4.6

Throughput bij theoretische grenzen

Beschrijving Volgens de theoretische berekening ligt bij pakketten van 64 byte de maximum capaciteit bij een bandbreedte van 97 Mbit/s. Deze bandbreedte kan op de ENP-2505 gehaalt worden als alle 4 poorten worden gebruikt. Bij deze meting werd de throughput berekend bij de alleenstaande router, en bij de NAPT applicatie. Er werden pakketten van 76 byte gebruikt, de minimum pakketgrootte die de Smartflow

4.7 Latentie initiële pakketten

45

software toelaat. Bij de bereikte throughputwaarde werd afgelezen met hoeveel pakketten per seconde dit overeenkomt.

Resultaten De resultaten zijn weergegeven in Tabel 4.4. Applicatie

maximum pakketratio (pakketten/s)

Router

175000

Router, Conntrack & NAPT

125000

Tabel 4.4: Latentie bij verschillende applicaties

Bespreking Uit deze resultaten blijkt dat het verschil met de theoretische waarden zeer groot is. Het is mogelijk uit deze resultaten te berekenenen hoeveel tijd per pakket er nodig is in de bottleneck van de IXP1200. Bij 175 000 pakketten per seconde is dit dan 5.7 µs. Bij 125 000 pakketten per seconde is dit 8 µs. Het verschil bedraagt dan 2.3 µs. Dit betekent dus dat connection tracking + NAPT samen 2.3 µs per pakket duren.

4.7

Latentie initi¨ ele pakketten

Beschrijving Zonder gebruik te maken van gespecialiseerde testers, kunnen ook enkele testen gedaan worden door aan beide kanten van de IXP een linux PC te plaatsen. De PC’s zijn snel, en er werd voor gezorgd dat geen andere gebruiker was ingelogd, en er geen zware taken draaiden tijdens het testen. Dit om te voorkomen dat er vertragingen optreden door belasting van de CPU van de PC. Het ping programma, dat in bijna elk operating systeem aanwezig is, kan gebruikt worden om de retourtijd van een pakket tussen de 2 PC’s te meten. Merk op dat de retourtijd een heel ander gegeven is dan de latentie. Bij de retourtijd wordt de transfertijd over de de 2 100mbit

4.7 Latentie initiële pakketten

46

lijnen meegerekend. Ook zullen beide PC’s een extra vertraging veroorzaken. En zoals de naam doet vermoeden wordt bij de retourtijd de tijd om heen en weer te gaan genomen. Aangezien de retourtijd per pakket wordt weergegeven, kunnen we afzonderlijk de retourtijd voor het eerste pakket meten. De ICMP connecties worden namelijk ook als connecties gezien door de NAPT implementatie. Het eerste pakket wordt dus naar de core gestuurd en krijgt een extra vertraging, de volgende pakketten niet.

Resultaten De resultaten zijn weergegeven in Tabel 4.5. Applicatie

Retourtijd eerste (ms)

Retourtijd niet-eerste (ms)

Router

nvt.

0.247

Router & Conntrack

9.87

0.222

Router, Conntrack & NAPT

10.53

0.202

Tabel 4.5: Latentie eerste pakketten van connectie

Het viel ook op dat het verschil tussen de maximum(15.6) en minimumtijd(6.90) bij de eerste pakketten 8.70 milliseconden bedraagt. De afwijkingen van de volgende pakketten was 0.200 (0.350 - 0.150).

Bespreking De retourtijd van de niet-eerste pakketten heeft een bijna even grootte afwijking als de gemiddelde retourtijd. De afwijking wordt waarschijnlijk veroorzaakt door de 2 PC’s, en niet door de IXP of het netwerk. Het is niet mogelijk uit de gemiddelde retourtijden af te leiden welke van de 3 applicaties het snelst is. De retourtijd van de eerste pakketten schommelt ook sterk. Hierdoor kunnen we geen verschil afleiden tussen de gemmidelde tijd van de applicatie met of zonder NAT. De oorzaak van de schommeling is hier duidelijk. De schommeling bedraagt zo’n 10 ms, en dat is het tijdsinterval waarmee de core nagaat of er pakketten van de microengines doorgestuurd worden. In het beste geval zal deze vertraging 0 zijn, in het slechtse geval 10 ms. De tijd om het pakket op de core te

4.8 Wget downloadtest

47

verwerken zal blijkbaar zo’n 5 ms zijn. Het pakket wordt in userspace op een 233Mhz processor verwerkt, waardoor enige vertraging aanneembaar is, maar 5 ms is toch vrij lang. Het is uit deze test duidelijk dat het doorsturen van pakketten naar de core een zeer grote bottleneck vormt.

4.8

Wget downloadtest

Beschrijving Het programma “wget” kan gebruikt worden om automatisch een bestand van een ftp of http server te halen. Het berekent tijdens het downloaden de gemiddelde downloadsnelheid. Met het programma “time” werd de totale tijd die nodig is om de totale transactie te voltooien weergegeven. De testen werden uitgevoerd door op de ene PC de proftpd FTP server te draaien, en er vanop de andere PC met wget een file van 130 Mb (precies 131727360 bytes) te downloaden. Er werd getest met de volgende IXP applicaties: • Router (standalone l3fwd ACE) • Statische NAT implementatie • NAPT implementatie, zonder actieve NAT regel (dus enkel connection tracking) • NAPT implementatie, met actieve NAT regel (masquerading)

Resultaten De resultaten zijn zo eenvoudig dat ze niet in een tabel samengevat moeten worden: bij elke test was de transactietijd gelijk, en de downloadsnelheid was telkens zo’n 10.94 MB/s (dus zo’n 92 mbit/s).

Bespreking De extra vertraging, is dus duidelijk niet in staat om de snelheid van een TCP dataconnectie merkbaar te verlagen. Andere factoren, zoals de vertraging van de IXP kaart in het geheel, de

4.8 Wget downloadtest

48

vertraging van de 100mbit lijnen en de vertraging veroorzaakt door beide PC’s hebben een veel grotere invloed.

Conclusie In totaal werd op 3 manieren berekend hoe lang een pakket nodig heeft om door de NAPT implementatie op de microengines verwerkt te worden. De resultaten waren 1µs, 2, 3µs en 4µs. De meest betrouwbare meting is 2, 3µs, aangezien de eerste waarde theoretisch werd bekomen en bij de laatste de nauwkeurigheid twijfelachtig is. Hoedanook is de verwerkingstijd maximaal een vierde van de totale verwerkingstijd van 20µs. Verder valt op dat er 50 000 pakketten per seconde minder verwerkt kunnen worden met NAPT dan zonder. Dit betekent dus dat bij zware belasting het performantieverlies door het toevoegen van de NAPT implementatie duidelijk wordt. Het is ook duidelijk dat de tijd om een pakket naar de core te sturen zeer groot is in vergelijking met de tijd om een pakket lokaal op de micro-engines te verwerken. Dit is een zwak punt van de IXP1200. Verder werd duidelijk dat de impact van IXP1200 applicaties op het netwerk miniem is, behalve bij zeer zware balasting. Downloadsnelheid en throughput ondervinden geen nadeel. Bij extra belasting (maar zonder overbelasting), is er nauwelijks een daling in prestatie merkbaar. De geoptimaliseerde architectuur van de IXP1200 werkt dus uitstekend. Ten laatste valt op te merken dat ondanks het feit dat 1 derde van de micro-engines niet ingeschakeld is, het bij normaal (1500 bytes) netwerkverkeer onmogelijk is de ENP-2505 te overbelasten. Dit toont aan dat de IXP1200 zeker meer poorten aankan.

MOGELIJKE UITBEREIDINGEN

49

Hoofdstuk 5

Mogelijke uitbereidingen Er zijn enkele interessante uitbreidingen mogelijk op de huidige implementatie. Om te beginnen kan geprobeerd worden de verwerking van initiële pakketten volledig op de micro-engines af te handelen. Dit zou een enorme performantieverbetering betekenen, aangezien dit dé bottleneck vormt, maar er zijn enkele praktische problemen. Om te beginnen hebben de micro-engines geen geheugenbeheer en zou een (mogelijk zeer beperkt) geheugenbeheer uitgebouwd moeten worden. Een moeilijker probleem vormt de grens van 2048 lijnen microcode per micro-engine. De huidige verwerking van initiële pakketten gebeurt in vele lijnen C code, en dit zal overeenkomen met mogelijk nog meer lijnen microcode. Het zou eventueel mogelijk zijn 1 of meerdere micro-engines voor deze taak op te offeren. Aangezien het netfilter model gevolgd is, is het mogelijk een firewall toe te voegen, door de netfilter “forward hook” toe te voegen. Dit betekent dat op de micro-engines, in de dispatchloop, een stukje code moet toegevoegd worden dat de firewall implementatie oproept. Dit stuk code zal toegevoegd worden tussen de code die de router oproept en de code die de “postrouting hook” oproept. Een andere mogelijke uitbereiding is het NAT’ten van active FTP connecties. Dit is 1 van de pijnpunten van NAT, aangezien het enorm geknoei op pakketniveau vereist. Er bestaat natuurlijk ook passive FTP, waardoor FTP ook zonder deze functionaliteit kan gebruikt worden. Dit gaat echter ten koste van de transparantie van NAT, aangezien de gebruiker dit zelf moet instellen.

BESLUIT

50

Hoofdstuk 6

Besluit Gebaseerd op het Netfilter model, maar minder uitgebreid, is een NAPT implementatie geschreven voor de IXP1200 netwerkprocessor. De applicatie is beperkt tov Netfilter, maar implementeert basis NAPT volledig en is representatief voor een volledige implementatie met alle toeters en bellen. Het micro-engine gedeelte van de applicatie verwerkt alle pakketten, en gebruikt de core om de eerste pakketten van een connectie te verwerken. Programmeren op een netwerkprocessor bleek complexer te zijn dan op een GPP, onder andere door de speciale hardware-optimalisaties. Uit de metingen is gebleken dat het “connection tracking” gedeelte van de code het meest doorweegt op de performantie. Uit metingen werd verder afgeleid dat de gehele verwerking door de NAPT implementatie van een normaal pakket slechts 2 á 3 microseconden duurt, terwijl het eerste pakket van een connectie er honderden keren langer over doet. Gelukkig zal deze vertraging nauwelijks merkbaar zijn bij gewoon netwerkgebruik. De NAPT implementatie bleek in zijn huidige vorm zo’n 125 000 (kleine) pakketten per seconde te kunnen verwerken. Het was ook duidelijk dat de performantie door het toevoegen van de NAPT implementatie daalde, maar dit werd pas duidelijk bij overbelasting met kleine pakketten. De IXP1200 netwerkprocessor komt zeer goed uit de testen. Bij een normale pakketgrootte van 1500 byte is gebleken dat het onmogelijk was de IXP1200 te belasten op de ENP-2505 kaart. Verdere tests deden vermoeden dat de grens van de IXP1200 bij grote pakketten de snelheid van het geheugen, en bij kleine pakketten de verwerkingscapaciteit van de micro-engines is. Bij grote pakketten komt dit erop neer dat de IXP1200 gebruikt kan worden in een configuratie met 2 maal een 1 gigabit poort. Het werd ook duidelijk uit de tests dat het doorsturen van een pakket naar de core een enorme bottleneck vormt.

STARTEN NAPT APPLICATIE

51

Bijlage A

Starten NAPT Applicatie Eerst moet de microcode geassembleerd worden. Dit moet op Windows gebeuren. Deze stap is al gedaan in de versie die op de thesis CD staat. Het komt neer op cygwin starten, en dan: cd /opt/ixasdk/src/microace/aces/NetfilterNAT/ucbuild make -f Makefile.win Om alle core-files te compileren en alles naar de juiste map te kopiëren is een script voorzien. Dit script moet uitgevoerd worden vanop het host OS. cd /opt/ixasdk/src/microace/aces/NetfilterNAT/ sh install.sh Dit script voert een hoop stappen uit die bij het bewerken van de code manueel gebeuren. Het starten van de NAPT applicatie gebeurt vanop de StrongARM core. De volgende stappen zijn nodig om de applicatie te starten: Op de host PC, de PC die de ENP2505 kaart bevat:

/opt/ixasdk/bin/arm-be/bootixp Gebruik het bootscript om de IXP1200 te booten, of: minicom ixp

STARTEN NAPT APPLICATIE

indien het booten al gebeurd was, log in met minicom. Vervolgens op de IXP1200 core: • cd /nfs/ixasdk/bin/arm-be Ga naar de map met alle tools en executables. • ./ixstart ixsys_NFNAT.config Start de ixstart tool met de juiste configuratiefile. • De applicatie loopt nu. • ./ixstop Stopt de applicatie. Met de toetsencombinatie CTRL-A Q kan men minicom verlaten.

52

NAT CONFIGURATIE BESTAND

53

Bijlage B

NAT configuratie bestand Deze bijlage bestaat uit de helptekst uit het NAT configuratiebestand. Deze file definieert de NAT regels die toegepast worden.

Dit is de configuratiefile voor mijn NAPT implementatie.

Deze file bevat regels (RULE). Spaties en newlines worden voor het grootste deel genegeerd. Alles is hoofdlettergevoelig!

Een regel (RULE) bestaat uit 2 delen: - een TARGET deel, dat aanduid welke pakketen gemanipuleerd moeten worden. - een ACTION deel, dat aanduid welke de mogelijke manipulaties zijn.

Beide delen hebben verschillende argumenten: TARGET: - inputinterface= - sourceip= - destip= - {dst|src}{TCP|UDP}port=

Geen enkel argument is verplicht. Geen argumenten betekent alle pakketten. Indien er verschillende argumenten zijn moet het pakket aan alle voldoen indien mogelijk (TCP port kan niet bij bv ICMP of UDP en wordt dus ook niet


54

getest).

ACTION: - SNAT: - localSNATip=

*verplicht*

- availableSNATports= - STANAT - availableSTANATip=

*verplicht*

*opmerking*

- DNAT: - targetip=

*verplicht*

- target{TCP|UDP}port=

Sommige argumenten zijn verplicht, onmiddellijk na ACTION volgt SNAT, STANAT of DNAT.

: ip<enkel ip>

bv

ip10.0.0.1

ipmask<enkelip>/<mask>

bv

ipmask10.0.0.0/8

iprange<enkelip>-<enkelip>

bv

iprange10.0.0.1-10.0.0.64

: port<enkele poort>

bv

port21

portrange<enkele poort>-<enkele poort>

bv

portrange1024-65535

*opmerking* Statische NAT is enkel een "proof of concept", om aan te tonen dat het kan. Slechts 1 IP is toegelaten wat het praktisch nogal onbruikbaar maakt.

C-stijl commentaar is toegelaten.

Voorbeelden:

RULE TARGET destip=ip10.1.0.1 ACTION SNAT localSNATip=ip10.1.0.1


availableSNATports=portrange1024-65535

RULE TARGET destip=ip10.1.0.15 dstTCPport=port2121 ACTION DNAT targetip=ip10.1.0.2 targetTCPport=port21

55

OVERZICHT BESTANDEN

56

Bijlage C

Overzicht Bestanden Deze bijlage biedt een overzicht van de belangrijkste bestanden van de applicatie. Bij files zonder uitleg spreekt de naam voor zich.

NAT.rules Het configuratiebestand voor de NAT regels. Makefile Deze Makefile beperkt zich tot het kopiëren van NAT.rules en ixsys NFNAT.config naar de juiste locatie. ixsys NFNAT.config Configuratiefile voor de ixstart applicatie. install.sh Script om files naar juiste locatie te kopiëren. ucbuild/Makefile.win Makefile voor het microcode gedeelte. ucbuild/SlowIngressNFNAT.uof Gecompileerde microcode voor Ingress deel. ucbuild/SlowEgressRR.uof Gecompileerde microcode voor Egress deel. NFNAT ace2 onbelangrijke ACE voor debuggen en enkele trukjes. NFNAT ace1/Makefile Makefile voor het StrongARM core gedeelte NFNAT ace1/include/Conntrack hashtable.h NFNAT ace1/include/NFNATImportVars.h Definitie van importvariabelen. Belangrijk voor microcode. NFNAT ace1/include/ip conntrack tuple.h Definitie onderdeel ip conntrack.

OVERZICHT BESTANDEN

57

NFNAT ace1/include/ip nat info.h Definitie onderdeel ip conntrack. NFNAT ace1/include/list.h Implementatie van dubbelgelinkte lijst met physieke offsets. NFNAT ace1/include/NFNATControlBlock.h Definieert enkele structuren voor het debugsysteem. NFNAT ace1/include/NFNATMicroAce.h Definieert microace structuur. NFNAT ace1/include/ip conntrack.h Definitie de belangrijke ip conntrack structuur. NFNAT ace1/include/ip nat hash.h NFNAT ace1/include/ip nat rule.h NFNAT ace1/include/reallist.h Implementatie van dubbelgelinkte lijst met virtueel geheugen (normale dubbelgelinkte lijst). NFNAT ace1/microblock/CheckSums.uc Microcode voor incrementele update checksums. NFNAT ace1/microblock/IPv4UnicastFwd Stub.uc Microcode voor router. NFNAT ace1/microblock/NAT.uc Microcode voor NAPT. NFNAT ace1/microblock/NFNAT IngressDispatch.uc Microcode dispatchloop voor Ingress microACE. NFNAT ace1/microblock/IPv4UnicastFwd.uc Microcode voor router. NFNAT ace1/microblock/MyDebug.uc Microcode voor debuginstructies NFNAT ace1/microblock/NFNAT.uc Microcode voor connection tracking en Netfilter hooks. NFNAT ace1/microblock/RR EgressDispatch.uc Microcode voor Egress dispatchloop. NFNAT ace1/shared/Hash.h C en microcode voor hashfunctie. NFNAT ace1/shared/Locks.h C en microcode voor locks (werkt helaas niet). NFNAT ace1/source/Conntrack hashtable.c NFNAT ace1/source/NAT hashtables.c NFNAT ace1/source/NAT rules.c Toepassen NAT rules op eerste pakket verbinding.

OVERZICHT BESTANDEN

NFNAT ace1/source/NatruleParser.l lex file voor NAT rule parser. NFNAT ace1/source/action.c Ontvangst van pakketten vanuit core of andere ACE’s. NFNAT ace1/source/init.c Initialisatie en periodieke functies applicatie. NFNAT ace1/source/ip conntrack.c Verwerken eerste pakketten verbinding. NFNAT ace1/source/lex.yy.c Door lex gegenereerd uit NatruleParser.l

58

BIBLIOGRAFIE

59

Bibliografie [1] S. Bradner, “ Benchmarking terminology for network interconnection devices”, RFC 1242, July 1991. [2] Intel, “Intel IXP1200 Network Processor Datasheet”, December 2001. [3] Intel, “IXA SDK 2.01 Developers Guide”, December 2001. [4] Intel, “Microcode Programmer’s Reference Manual”, March 2002. [5] Erik J. Johnson, Aaron R. Kunze, “IXP1200 programming”, Intel Press, February 2002. [6] Radisys, “ENP-2505 Hardware Reference”, March 2002. [7] A. Rijsinghani,

“Computation of the Internet Checksum via Incremental Update”,

RFC 1624, May 1994. [8] Rusty Russell, “Linux netfilter hacking HOWTO”, July 2002. [9] Rusty Russell, “Linux 2.4 NAT HOWTO”, January 2002. [10] “Internet Protocol”, RFC 791, September 1981. [11] “Transmission Control Protocol”, RFC 793, September 1981.

Experimentele studie van een NAT dienst met behulp van netwerkprocessoren

Recommend Documents