Faculteit Toegepaste Wetenschappen
Vakgroep Informatietechnologie (INTEC) Voorzitter: Prof. Dr. Ir. P. Lagasse
Evaluatie van een VLAN registratie protocol in Ethernet Bjorn Nuyttens
Promotor: Prof. Dr. Ir. I. Moerman Begeleiders: Ir. F. De Greve, Ir. F. Van Quickenborne
Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica optie informatie- en communicatietechnologie
Academiejaar 2003-2004
1. Woord vooraf
Dit eindwerk was er niet gekomen zonder het begrip en de steun van prof. Moerman die onder alle omstandigheden haar objectiviteit bewaarde waarbij dit stilzwijgend zeer werd geapprecieerd. Gedurende de tussentijdse evaluaties werd ik bijzonder gemotiveerd door de realistische visie van prof. Demeester.
Ook mijn begeleiders, Filip De Greve en Frederic Van Quickenborne wil ik bij deze bedanken voor hun steun. In het bijzonder voor het opzetten en onderhouden van de VNC verbinding waardoor ik van thuis uit kon werken. Filip was als dagelijkse begeleider van het werk steeds beschikbaar voor alle mogelijke vragen en softwareverwikkelingen. Van de eenvoudigste tot de meest complexe vraagstukken, hij probeerde steeds een antwoord of oplossing te vinden. De gesprekken die ik met mijn begeleiders had over de concrete implementatie hebben zeker een substantiële bijdrage geleverd tot dit eindwerk.
i
1. 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.
ii
1. Overzicht Evaluatie van een VLAN registratie protocol in Ethernet Bjorn Nuyttens
Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica optie informatie- en communicatietechnologie
Academiejaar 2003-2004
Promotor: Prof. Dr. Ir. I. Moerman Begeleiders: Ir. F. De Greve, Ir. F. Van Quickenborne Faculteit Toegepaste Wetenschappen Universiteit Gent
Vakgroep Informatietechnologie (INTEC) Voorzitter: Prof. Dr. Ir. P. Lagasse
In deze thesis wordt een protocol voor de registratie van virtuele locale netwerken geëvalueerd, met name het Generic VLAN Registration Protocol. (GVRP). Dit protocol is een toepassing van het meer algemene Generic Attribute Registration Protocol (GARP) dat tevens als basis dient voor een reeks andere (toekomstige) protocollen. GVRP biedt de mogelijkheid om virtuele locale netwerken netwerken in functie van de gebruikers op een dynamische manier te beheren in plaats van de gebruikelijke statische configuratie door de netwerkbeheerder. In een inleidend theoretisch hoofdstuk worden de nodige concepten aangehaald die nodig zijn voor het begrijpen van GVRP. Na deze synthese van verschillende IEEE standaarden volgt een korte schets van de gebruikte simulatiesoftware (Opnet Modeler 9.0A) en een uitgebreide bespreking van de implementatie. Trefwoorden:
Virtual Local Area Network (VLAN), Generic Attribute Registration Protocol (GARP), Generic VLAN Registration Protocol (GVRP), Opnet Modeler
iii
1. Inhoudstafel Voorwoord
i
Overzicht
ii
Toelating tot bruikleen
iii
Inhoudstafel
iv
Lijst van afkortingen
vi
I. Inleiding
1
1.1. Achtergrond 1.2. Doel 1.3. Structuur 1.4. Nut
1 1 2 3
II. Theoretische basis
4
2.1. Medium Access Control 2.1.1. Switches, hubs en bridges 2.1.2. Poort toestand 2.1.3. Learning 2.1.4. Forwarding & filtering 2.2. Spanning Tree Protocol 2.2.1. Overzicht 2.2.2. Varianten 2.3. Generic Attribute Registration Protocol 2.3.1 Pakketformaat 2.4. Virtual Local Area Network 2.4.1. Principe 2.4.2. Praktische toepassingen 2.4.3. Frames 2.4.4. Topologie en werking 2.5. GARP VLAN Registration Protocol
III. Implementatie
4 5 5 6 7 8 8 9 10 12 14 14 15 15 16 17
19
3.1. Opnet Modeler 3.1.1. Netwerkniveau 3.1.2. Knoopniveau 3.1.3. Procesniveau 3.2. Opnet Implementatie 3.2.1. Switch 3.1.2. GVRP proces model 3.3. Click/Linux code
19 19 20 22 26 26 28 32
iv
IV. Simulatie
35
V. Conclusie
36
Referenties
37
v
1. Lijst van afkortingen • BPDU
Bridge Procol Data Unit
• EM
End Mark
• FIFO
First In First Out
• FSD
Finite State Diagram
• GARP
Generic Attritbute Registration Protocol
• GPDU
GARP/GVRP Protocol Data Unit
• GVRP
Generic VLAN Registration Protocol
• ICI
Interrupt Control Information
• IEEE
Institute for Electrical and Electronics Engineers
• ISO
International Standards Organisation
• LIFO
Last In First Out
• LAN
Local Area Network
• LLC
Logical Link Control
• MAC
Media Access Control
• MSTP
Multiple Spanning Tree Protocol
• PID
Protocol IDentifier
• QoS
Quality of Service
• RED
Random Early Detection
• RSTP
Rapid Spanning Tree Protocol
• STP
Spanning Tree Protocol
• VID
VLAN Identifier
• VLAN
Virtual Local Area Network
vi
Evaluatie van een VLAN Registratie Protocol in Ethernet
1. Inleiding 1 Achtergrond Het routeren van verschillende soorten verkeer over de Ethernet gebaseerde access netwerken van Service Providers brengt de nood aan een dynamische configuratie van de netwerktopologie met zich mee. Het GVRP protocol kan hieraan deels voldoen door het opzetten van Virtuele Local Area Netwerken waarbij aan het begin van het access netwerk een pakket wordt bestempeld als behorende tot een bepaald VLAN op basis van het type informatie dat het met zich meedraagt. Het protocol kan uiteraard ook voor andere soorten netwerken gebruikt worden waarbij één fysisch LAN opgesplitst wordt in logisch van elkaar gescheiden VLANs met het oog op veiligheid, Quality of Service (QoS) e.a. Het GVRP protocol in elk netwerk dat verschillende categorieën verkeer transporteert. Hierbij maakt het weinig uit of de categorieën bepaald worden door het eigenlijke gegevenstype (data, audio, video, …) of door de afzender en/of ontvanger van een pakket. Het Generic Attribute Registration Protocol (GARP) biedt de mogelijkheid om attributen op een dynamische wijze in een netwerkknoop te registreren. Meer in het bijzonder zal het Generic VLAN Registration Protocol (GVRP) dat een afgeleide vormt van GARP de taak van de netwerkbeheerder deels overnemen en zelf aanpassingen in de VLAN configuratie van elke switch doorvoeren. Het mag duidelijk zijn dat een dergelijke geautomatiseerde (her)configuratie stukken sneller zal zijn dan de manuele aanpassing door de netwerkbeheerder. De VLAN configuratie in het netwerk muteert van een louter statisch gegeven naar een combinatie van statische en dynamische configuratieregels die enerzijds bepaald worden door de netwerkbeheerder en anderzijds door de werking van het GVRP protocol. 2 Doel Het doel van deze thesis is een duidelijker beeld te krijgen van o.a. de performantie van GVRP als ISO Layer-2 netwerkprotocol. Dit zullen we trachten te bereiken door middel van simulatie (m.b.v. Opnet Modeler softwarepakket). Hierdoor wordt het mogelijk om het -1-
Evaluatie van een VLAN Registratie Protocol in Ethernet gedrag van GVRP voor omvangrijke en in de praktijk moeilijk te realiseren testnetwerken in detail te bestuderen. De implementatie van het protocol voor het simulatiepakket heeft het ontegensprekelijke voordeel dat het testnetwerk gemakkelijk uitgebreid kan worden zonder het opzetten van omvangrijke fysische netwerken. Het simulatiepakket Opnet Modeler kan gebruikt worden om het geïmplementeerde protocol te vergelijken met een al eerder uitgevoerde praktijktest op een relatief klein testnetwerk. Op deze manier zal de correctheid van de implementatie al dan niet bevestigd of ontkend worden. Tijdens de simulaties wordt gepoogd om de werking van GVRP zo efficiënt mogelijk te laten verlopen met als uiteindelijke doel het verkrijgen van optimale parameters voor dit specifiek netwerk. Vertrekkende van deze resultaten is het mogelijk deze te extrapoleren voor omvangrijke netwerken die (vanuit praktisch standpunt) slechts met een grote kost fysisch geïmplementeerd kunnen worden. Met de implementatie van het GVRP protocol in het simulatiepakket wordt de basis gelegd voor latere uitbreidingen (andere bestaande of nieuwe GARP gebaseerde protocollen) en wordt eveneens de mogelijkheid geboden aan netwerkadministrators en service providers de werking van hun netwerk te simuleren alvorens over te gaan tot fysische wijzigingen. 3 Structuur De eerste stap bestaat erin voldoende theoretische achtergrond te voorzien door het doornemen van de officiële IEEE standaarden en andere opzoekingen. Een synthese van deze standaarden is te vinden in hoofdstuk 2. De aangebrachte ideeën geven het verband weer tussen de verschillende concepten en zijn cruciaal voor de interpretatie van de volgende hoofdstukken. In een volgende stap wordt de theorie omgezet in de praktijk: het implementeren van het GVRP model dat gebruikt zal worden tijdens de simulaties. De gebruikte programmeertaal is C. Hoewel het Opnet Modeler simulatiepakket ook de mogelijkheid biedt om C++ te gebruiken, werd niet voor C++ gekozen omdat bestaande implementaties – waarop deze gebaseerd is – in C geprogrammeerd zijn. Daardoor is de analogie tussen de bestaande implementaties duidelijker. Er wordt vertrokken vanaf een reeds bestaand implementatie van GVRP voor een click/linux gebaseerde omgeving en gepoogd deze te converteren naar Opnet Modeler. -2-
Evaluatie van een VLAN Registratie Protocol in Ethernet Na de implementatie volgt de simulatie waarbij eerst de correctheid van de implementatie wordt getest aan de hand van eenvoudige modellen waarna een uitbreiding naar omvangrijker netwerken gemaakt kan worden. Het testen van deze grotere realistische modellen zal de basis vormen voor de uiteindelijke conclusie over de performantie van GVRP. 4 Nut Enerzijds zal een simulatie – zeker voor relatief grote netwerken – kostenbesparend zijn. Het opzetten van een netwerk kan immers met enkele muisklikken gebeuren. De aankoop van de nodige hard- en software is niet nodig, deze worden vervangen door het Opnet Modeler simulatiepakket en de geïmplementeerd modellen. Een ander voordeel is de gebruikte tijd om het netwerk op te zetten en te testen. Het spreekt voor zich dat een simulatie niet 1 op 1 real time hoeft te gebeuren. Zo worden uren in enkele minuten gesimuleerd. Lange simulaties van bijvoorbeeld enkele dagen om de betrouwbaarheid te testen kunnen dus in een veel kortere periode gebeuren. Het aanpassen van het netwerk is vrij eenvoudig en behoeft in principe geen grondige kennis van het onderliggende GVRP model. De mogelijkheden van een simulatie zijn dito. Netwerken die in de praktijk moeilijk haalbaar zijn – door kostprijs, tijdsgebrek of andere redenen - kunnen eventueel wel gemodelleerd worden en zo kan alsnog door onderzoek een duidelijker beeld gevormd worden van deze gevallen.
-3-
Evaluatie van een VLAN Registratie Protocol in Ethernet
2. Theoretische achtergrond 1 Medium Access Control De werking van de Medium Access Control service (MAC [1]) is belangrijk omdat alle verdere onderwerpen hiervan gebruik zullen maken. In het bijzonder het Spanning Tree Protocol (STP) en het Generic Attribute Registration Protocol (GARP). Onrechtstreeks zal dus ook het GARP VLAN Registration Protocol (GVRP) van deze basis gebruik maken. Verder vertoont de werking van STP en GARP een grote analogie met deze van het MAC Relay Entity proces.
Figuur 1: Inwendige bridge
Een schematisch overzicht van het inwendige van een bridge wordt in figuur 1 gegeven. Twee netwerksegmenten zijn verbonden met de bridge, elk met één poort. Indien er een “normaal” frame binnenkomt wordt het via de MAC Entity doorgegeven aan de MAC Relay Entity die zal beslissen wat ermee moet gebeuren. Onder een “normaal” frame verstaan we een frame dat niet bestemd is voor de switch zelf, het moet dus niet -4-
Evaluatie van een VLAN Registratie Protocol in Ethernet doorgestuurd worden naar hogere lagen zoals de Logical Link Control (LLC) laag. Een bridge gedefinieerd volgende de IEEE standaard heeft volgende functionaliteit: MAC Bridges interconnect the separate IEEE 802 LANs that comprise a Bridged LAN by relaying and filtering frames between the separate MACs of the Bridged LAN. Een deel van de pakketten zijn bestemd voor de bridge zelf. Dit wordt beslist op basis van het doeladres van het frame. De volgende tabel geeft een overzicht van de gereserveerde adressen en hun bijhorende toepassing. De gebruikte adressen zijn allen 48 bits adressen, gereserveerd of niet. Tabel 1: Protocol Group Address
Bridge Group Address
01-80-C2-00-00-00 STP
GARP Application Addresses
01-80-C2-00-00-20 t.e.m. 01-80-C2-00-00-2F 01-80-C2-00-00-20 GMRP 01-80-C2-00-00-21 GVRP
Bridge Management Addresses 01-80-C2-00-00-10 (voor alle bridges in het LAN) MAC adres van de poort (voor één bridge)
1.1
Switches, hubs en bridges
Switches en hubs kunnen beide beschouwd worden als bridges, zij het dan met meerdere MAC interfaces (poorten). Ze onderscheiden zich enkel van elkaar door hun werking. De functionaliteit, nl. het verbinden van twee of meer LAN segmenten, is dezelfde. Daar waar hubs enkel frames doorstuurt, zullen switches de frames ook filteren.
1.2
Poort toestand
Een poort kan uitgeschakeld (disabled) worden door de netwerk manager. Als gevolg hiervan worden er geen frames via deze poort verzonden of ontvangen. Is de poort actief (forward) dan worden frames verzonden, ontvangen en naar de gepaste entiteit doorgestuurd wordt. De actieve topologie van een netwerk wordt gevormd door de verzameling links tussen de actieve poorten. Enkel indien anders vermeld verstaan we -5-
Evaluatie van een VLAN Registratie Protocol in Ethernet onder de netwerktopologie de actieve netwerktopologie en alle poorten zijn de poorten in actieve toestand (forward). Deze begrippen zullen uitgebreid worden in de paragraaf over het Spanning Tree Protocol. Frames die wachten om verstuurd te worden op een poort in de “forward” toestand zullen bij overgang van de poort naar de “disable” toestand verwijderd worden.
1.3
Learning
Figuur 2: Bridge learning
We gaan ervan uit dat frames geen gereserveerd doeladres hebben (zie tabel 1), m.a.w. frames die bestemd zijn om te worden doorgestuurd naar een ander netwerksegment. Indien zo’n frame aankomt en het adres komt nog niet voor in de database van de switch dan wordt onthouden op welke poort het frame is toegekomen. Op die manier weten we tot welk netwerksegment dat adres behoort. Het koppel (adres, poort) wordt opgeslagen in de databank.
-6-
Evaluatie van een VLAN Registratie Protocol in Ethernet Indien een adres gedurende een arbitraire periode in geen enkel frame voorkomt (als bronof doeladres) wordt het adres geschrapt en ervan uitgegaan dat de host met het desbetreffende adres zich van het segment heeft verwijderd of zich naar een ander segment heeft verplaatst. De zogenaamde “ageing timer” zorgt ervoor dat adressen niet eeuwig worden bewaard. De “ageing time” varieert tussen 10 en 1.000.000 seconden (ongeveer 12 dagen). De aanbevolen waarde is 300 s (5 minuten).
1.4
Forwarding & filtering
Figuur 3: Bridge forwarding & filtering
Inkomende frames waarvan het doeladres reeds in de databank voorkomt worden doorgestuurd naar de correct poort. Frames waarvan het doeladres niet voorkomt in de databank naar alle poorten doorgestuurd behalve de poort waarop het frame werd ontvangen (broadcast). Indien het bronadres en het doeladres zich op dezelfde poort bevinden wordt het frame gedumpt. De beide hosts bevinden zich dan immers in hetzelfde netwerksegment en er is dus geen nood aan het doorsturen van het frame (frame relay).
-7-
Evaluatie van een VLAN Registratie Protocol in Ethernet Voordat frames doorgestuurd kunnen worden, moeten ze door een filter passeren. Deze filter – onder de vorm van een databank – kan zowel statisch als dynamisch bepaald worden. Statische filterregels liggen zoals de naam het zelf zegt vast en kunnen enkel door het management gewijzigd of verwijderd worden. De dynamische regels daarentegen kunnen niet door het management aangemaakt of gewijzigd worden en zijn het gevolg van de werking protocollen zoals het Spanning Tree Protocol. Filterregels kunnen gebruik maken van het bronadres en doeladres om een beslissing te nemen. Indien een statische regels wordt gewijzigd of toegevoegd die in strijd is met één of meerdere bestaande dynamische filterregels dan worden de dynamische regels sowieso geschrapt. Met andere woorden: statische filterregels staan boven dynamische filterregels. 2 Spanning Tree Protocol
2.1
Overzicht
Het Spanning Tree Protocol (STP [1]) is een laag 2 protocol (ISO referentiemodel) en wordt gebruikt om een netwerk gegarandeerd lusvrij te houden. Een lus in een netwerk zorgt in vele gevallen voor een oneindige verveelvoudiging van elk pakket. Hierdoor zal het netwerk verzadigd geraken en wordt communicatie over het netwerk uiteindelijk onmogelijk wegens de overvloed aan gedupliceerde pakketten. Eerst en vooral merken we op dat STP enkel zin heeft bij redundante netwerken, i.e. netwerken waar tussen twee hosts verschillende netwerkpaden mogelijk zijn. Een eenvoudig voorbeeld van zo’n netwerk vindt u hieronder.
Figuur 4: Redundant netwerk
-8-
Evaluatie van een VLAN Registratie Protocol in Ethernet Twee hosts A en B zijn met elkaar verbonden. Elk pad van A naar B (en omgekeerd) gaat over een hub, een switch en nog een hub. De hubs worden voorgesteld door cirkels, de switches door rechthoeken. Indien A een pakket verzend naar B wordt het in de onderste hub doorgestuurd naar beide switches. We hebben dus 2 kopieën van het oorspronkelijk pakket. Elk van deze pakketten wordt doorgestuurd naar de bovenste hub waar opnieuw een verdubbeling ontstaat. Één kopie gaat naar de bestemming B, het tweede gaat naar de andere switch. Op dat moment heeft B twee identieke pakketten ontvangen en worden twee kopieën in elke van de switches bewaard. Telkens een switch een pakket verstuurd zal er een verdubbeling plaatsvinden in een hub. We krijgen dus een situatie waarin kopieën heen en weer gestuurd worden tussen switches onderling en tussen de switches en de bestemming (broadcast storm). We krijgen een pingpong effect over de bovenste link tussen beide switches: telkens een pakket door de hub passeert zal het afgeleverd worden in B. Veronderstel dat u pingpong speelt en dat telkens het balletje over het net gaat er door één of andere magische kracht een tweede balletje in de emmer naast het net terechtkomt. Wanner uw partner het balletje terugspeelt gebeurt hetzelfde. Op het moment dat u het balletje voor de eerste keer terugkrijgt bevat de emmer al twee balletjes. U blijft verder spelen met hetzelfde balletje waardoor de emmer langzaam aan gevuld geraakt. Het Spanning Tree Protocol voorziet een lusvrij netwerk door alle paden behalve één tussen twee hosts te blokkeren. Zonder in te gaan op de details van STP kunnen we zeggen dat in bovenstaand voorbeeld het netwerkpad dat over de linkerswitch loopt uitgeschakeld zal worden waardoor enkel nog communicatie mogelijk is via de rechterswitch. Naast het voorzien van een lusvrij netwerk heeft STP nog een andere functie: het opvangen van fouten in het netwerk zonder tussenkomst van het management. M.a.w. indien een link van de actieve topologie faalt, zal dit gedetecteerd worden en treedt een automatische herconfiguratie in werking. De tijd die verloopt tussen het optreden van een fout (falen van een link) is afhankelijk van de gebruikte variant van het Spanning Tree Protocol.
2.2
Varianten
Rapid Spanning Tree Protocol (RSTP [2]) is een variant van het gewone Spanning Tree Protocol. De tijd die STP nodig heeft om onverwachte wijzigingen in het netwerk op te -9-
Evaluatie van een VLAN Registratie Protocol in Ethernet vangen (kabelbreuk e.a.) is vrij lang (in de ordegrootte van enkele minuten). Daarentegen biedt STP wel de garantie dat geen enkel pakket verdubbeld zal worden. RSTP herconfigureert het netwerken sneller bij onverwachte wijzigingen maar heeft als nadeel dat niet meer gegarandeerd kan worden dat sommige pakketten niet verdubbeld worden. Broadcast storms, zoals beschreven in het deel over STP zijn in beide gevallen uitgesloten. Het Multiple Spanning Tree Protocol (MSTP [3]) komt verder niet ter sprake maar wordt hier toch vermeld daar het bij uitbreidingen naar meerdere spanning trees van belang kan zijn. 3 Generic Attribute Registration Protocol Het Generic Attribute Registration Protocol (GARP) is een louter theoretisch protocol dat gebruikt wordt om attribuutwaarden tussen netwerkelementen, zoals bridges en terminals, te registreren en “deregistreren”. GARP definieert dus enkel een algemeen model voor de werking van afgeleide protocollen. Er zijn vier bewerkingen gedefinieerd: − declareren van attributen (“declare”) − opzeggen van de declaratie (“undeclare”) − registratie van attributen (“register”) − opzeggen van de registratie (“unregister”)
- 10 -
Evaluatie van een VLAN Registratie Protocol in Ethernet Figuur 5: Werking GARP
Beschouw bovenstaand netwerk. De grote rechthoeken zijn switches, de kleine vierkanten zijn netwerkterminals. Om het principe te demonstreren zal enkel de terminal bij nummer 1 een attribuut declareren, m.n. attribuut A. Deze declaratie wordt geregistreerd in de verbonden switch (2). De switch stuurt de declaratie door naar alle poorten uitgezonderd de poort waarop de declaratie werd ontvangen (3). Op deze manier propageert het attribuut zich naar de terminal bij 4 en over LAN 3 naar een van de bovenste rij switches. Deze switch stuurt de informatie terug verder over LAN 1 (5) waardoor het attribuut geregistreerd wordt bij de overige switches in de bovenste rij en de enige host rechtstreeks verbonden op LAN 1 (6). De verdere stappen zijn analoog: ze vormen telkens een opeenvolging van declaratie en registratie tot het attribuut zich over gans het netwerk verspreid heeft.
Figuur 6: declare
Figuur 7: undeclare
Deze werkwijze kan volledig worden overgenomen in het geval van een “undeclare” en “unregister”. Hierbij moet wel in acht genomen worden dat een “undeclare” slechts zal doorgestuurd worden indien geen enkele poort van de switch nog geregistreerd is op het desbetreffende attribuut. Beschouw figuur 6 waarin twee netwerkterminals attribuut A hebben gedeclareerd. Indien de linker terminal het attribuut opzegt dan wordt het gederegistreerd op de desbetreffende poort in de switch en zet deze “undeclare” zich verder naar de andere terminal. Omdat het attribuut nog op een poort geregistreerd is zal de “undeclare” zich niet verder propageren naar andere gedeelten van het netwerk. We krijgen de situatie in de rechterfiguur. Merk op dat het attribuut nog steeds geregistreerd is in de linker terminal. Deze registratie is afkomstig van de declaratie door de rechterterminal. Indien de declaratie van het attribuut A in deze laatste situatie wordt opgezegd, dan zal deze “undeclare” zich wel door - 11 -
Evaluatie van een VLAN Registratie Protocol in Ethernet het afgebeelde segment van het netwerk voortplanten vermits de “undeclare” gebeurt op de laatste geregistreerde poort. Het Generic Attribute Registration Protocol kent een aantal afgeleiden waaronder: − GVRP: Generic VLAN Registration Protocol
[3]
− GMRP: Generic Multicast Registration Protocol [1] Het Generic VLAN Registration Protocol (GVRP) is een in de praktijk toepasbare afgeleide van het theoretische GARP. De attributen bestaan uit de VLAN groepsnummers. Door gebruik te maken van GVRP kan de VLAN configuratie dynamisch aangepast worden. Voor de volledigheid vermelden we nog kort GMRP. De werking en functie van dit protocol is te vergelijken met die van IGMP (Internet Group Management Protocol). Het voorziet een mechanisme om netwerkelementen dynamisch bij een bepaalde groep te registreren. Een groep heeft één bron en meerdere doelen, in tegenstelling tot GVRP dat meerdere bronnen en doelen kan hebben.
3.1
Pakketformaat
GARP Protocol Data Units of GPDUs [1] (naar analogie met BPDU [1]) hebben een structuur bestaande uit meerdere lagen. We vermelden eerst nog dat de IEEE standaard de Little Endian notatie voorschrijft (minst beduidende byte eerst), bits worden genummerd van rechts naar links, van 1 tot 8. Dit is vooral belangrijk voor praktische implementaties van GARP en afgeleiden in switches e.d. Bij de implementatie in Opnet werd rekening gehouden met de volgorde van de velden, maar worden de waarden in de notatie eigen aan de machine opgeslagen. Op een i386 architectuur resulteert dit dus in een Big Endian notatie. Dit feit heeft behalve een afwijking t.o.v. de officiële standaard geen enkel ander gevolg, noch voor de verdere implementatie, noch voor de simulatie. PID
berichten…
EM
In de eerste laag van een GARP pakket bevinden zich een protocol identificatie (PID), een variabel aantal berichten (minstens 1) en een eindmarkering (end mark, EM). De protocol identificatie beslaat 2 bytes en heeft de vaste waarde 0x0001 ter aanduiding van het GARP - 12 -
Evaluatie van een VLAN Registratie Protocol in Ethernet protocol. De eindmarkering bestaat slechts uit één byte met als waarde nul (0x00). Op het hoogste niveau bevinden zich daartussen de berichten. TYPE
attributen…
EM
Op de tweede laag situeren zich de berichten waarvan zowel het aantal als hun lengte variabel is. Een bericht bestaat uit een attribuut type, een variabel aantal attributen en een eindmarkering. Geldige waarden voor het type gaan van 1 tot en met 255, type 0 is gereserveerd. In het geval van GVRP krijgt het type de waarde 1 mee. De eindmarkering bestaat opnieuw uit een byte met waarde 0. LENGTE
EVENT
waarden…
Het laagste niveau, de attributen zelf, zijn tripletten bestaande uit de lengte van het volledige attribuut, de gebeurtenis en de waarde. Indien geen waarden ingevuld worden is de lengte 2 (bytes), het absolute minimum. Per ingevulde waarde komt daar voor GVRP één byte bij. De gebeurtenissen nemen vooraf gedefinieerde waarden aan: − 0 = LeaveAll − 1 = JoinEmpty − 2 = JoinIn − 3 = LeaveEmpty − 4 = LeaveIn − 5 = Empty De lengte van de waardevelden varieert en is afhankelijk van het type gebeurtenis. Voor GVRP ligt de lengte van deze waarde vast op 1 byte. Er kunnen dus maximaal 253 GVRP waarden in één attribuut voorkomen. Indien de attribuutwaarde uit meerdere bytes bestaan het mogelijk is dat de laatste attribuutwaarden slechts gedeeltelijk in het pakket past. De standaard laat toe om onvolledige waardevelden mee te sturen. Bij ontvangst wordt het laatste veld genegeerd indien het onvolledig is. Deze mogelijkheid kunnen we bij GVRP uitsluiten vermits de waarden uit de kleinst mogelijk eenheid bestaan (byte).
- 13 -
Evaluatie van een VLAN Registratie Protocol in Ethernet 4 Virtual Local Area Network Virtuele Local Area Netwerken (VLAN’s) zijn – zoals uit de naam kan afgeleid worden geen fysische netwerken. VLAN’s laten echter wel toe om een fysisch netwerk onder te verdelen in verschillende virtuele netwerken. Deze virtuele netwerken bestaan dus enkel op logisch niveau, het zijn op zich geen tastbare netwerken. Men zou kunnen stellen dat ze enkel bestaan in de geest van de netwerkbeheerder. Op deze manier wordt het gehele netwerk gepartitioneerd en wordt aan elke netwerkterminal een VLAN nummer toegekend. Netwerkterminals met hetzelfde nummer behoren tot een VLAN groep en kunnen onderling vrij communiceren. Indien twee netwerkterminals uit verschillende groepen met elkaar willen communiceren moet het verkeer door een router of gateway passeren die de pakketten van het ene naar het andere VLAN gerouteerd. Bridges sturen enkel pakketten door van en naar het VLAN vermeld in het pakket. Vermeldenswaardig is de “geschiedenis” van de Virtuele Locale Netwerken: deze officiële standaard kan u nalezen in [3] die gebaseerd is op [1] met [4], [5] en [6] als amendementen.
4.1
Principe
Om het principe van VLAN’s te verduidelijken zullen we gebruik maken van volgend voorbeeld: beschouw een gebouw waarin drie afdelingen van een bedrijf ondergebracht zijn: Aan- en verkoop, Boekhouding en de Computer/informatica-afdeling. De terminals van de afdelingen zijn verbonden op een bestaand fysisch netwerk. We willen deze drie afdelingen gescheiden houden, ondanks dat ze op hetzelfde netwerk zitten. Indien we aan elk van de afdelingen een VLAN groepnummer toekennen wordt het mogelijk om gegevensstromen van de boekhoudafdeling gescheiden te houden van deze van de computerafdeling. Deze gegevensstromen (in concreto de pakketten) zullen gemerkt worden met het nummer van de VLAN groep waartoe ze behoren. Merk op dat er een speciaal nummer bestaat waarbij de gegevensstroom behorende tot deze “groep” behandeld wordt alsof er geen VLAN’s aanwezig zijn. Hoewel dit nummer afhangt van de configuratie gebruiken we hier het cijfer 0 om de speciale groep aan te duiden. Alle terminals kunnen pakketten met dit groepsnummer verzenden en ontvangen. Indien de configuratie dit voorziet is er op deze manier communicatie mogelijk tussen de - 14 -
Evaluatie van een VLAN Registratie Protocol in Ethernet verschillende afdelingen. Men is dus vrij om een pakket met groepsnummer 0 of met het eigen groepsnummer van de afdeling te markeren. Deze keuze hangt af van de bestemming: behoort deze tot een ander VLAN dan moeten we 0 als groepsnummer gebruiken. Behoort de bestemming tot dezelfde afdeling (zelfde VLAN) dan kunnen we onze gegevens afschermen en het groepsnummer van de eigen afdeling gebruiken of onze gegevensstroom voor iedereen beschikbaar maken (VLAN 0).
4.2
Praktische toepassingen
Er zijn verschillende denkbare redenen om gebruik te maken van VLAN’s. Een voor de hand liggende is beveiliging: een pakket verandert in principe niet van VLAN en kan dus niet bij een gebruiker in een ander VLAN terechtkomen (met uitzondering van VLAN 0). Bij het uitzenden met één bron en meerdere bestemmingen (broadcast) van bijvoorbeeld video kan men elke kijker het groepsnummer van het video VLAN toekennen. Op deze manier belast de videostroom enkel de delen van het netwerk waar daadwerkelijk gekeken wordt. De videogegevens worden dus gescheiden van data en andere stromen. Een derde voordeel is het configureren van het netwerk. Men kan het fysisch in- en uitpluggen van netwerkkabels vermijden. Indien een gebruiker op een ander netwerk moet aangesloten worden is het voldoende om zijn/haar terminal in een ander VLAN onder te brengen. De terminal blijft verbonden met dezelfde fysische switch (of ander netwerkelement) maar behoort tot een ander logisch LAN. Ander voorbeeld: audio/video/data/telefonie in access netwerk.
4.3
Frames
A tagged frame is a frame that contains a tag header immediately following the Source MAC Address field of the frame or, if the frame contained a Routing Information field, immediately following the Routing Information field. There are two types of tagged frames: VLAN-tagged frames and priority tagged frames. We onderscheiden drie soorten frames: − priority tagged: prioriteit en geen VLAN id
- 15 -
Evaluatie van een VLAN Registratie Protocol in Ethernet − VLAN tagged: prioriteit en VLAN id − untagged: geen van beide
4.4
Topologie en werking
De eerste stap in het opzetten van een VLAN aware netwerk bestaat uit het berekenen van een actieve lusvrije topologie door het Spanning Tree Protocol (of aanverwante). Dit impliceert dat de actieve topologie op elk moment kan wijzigen door het optreden van een fout. Doordat VLAN’s statisch zijn (vast geconfigureerd door het management) en STP een dynamische actieve topologie bepaalt, bestaat er het risico dat bij herconfiguratie van die actieve topologie VLAN’s gedisconnecteerd geraken m.a.w. een VLAN wordt opgesplitst in één of meer segmenten die niet (meer) onderling verbonden zijn. Statische VLAN’s in combinatie met STP zijn dus bijzonder foutgevoelig, men kan immers niet op voorhand voorspellen welke links zullen breken en hoe bijgevolg de nieuwe actieve topologie er zal uitzien. Volgende tabel geeft een overzicht van de mogelijke combinaties en hun onderlinge compatibiliteit. statisch netwerk (MAC)
VLAN +++
statisch netwerk (MAC)
GVRP +++
dynamisch netwerk (STP)
VLAN ---
dynamisch netwerk (STP)
GVRP +++
Het leren van MAC adressen door de bridges is gelijkaardig aan *paragraaf MAC* met dat verschil dat er eveneens een VID moet worden bijgehouden. De VLAN IDentifier kan gezien worden als een uitbreiding/extensie van het MAC adres. Dus i.p.v. 48-bit (6 bytes) krijgen we een “virtueel” adres van 56-bit (7bytes). waarbij de laatste byte wordt geïnterpreteerd als het VLAN groepsnummer. De werking van een VLAN aware bridge bestaat voornamelijk uit het filteren en doorsturen van frames en het bijhouden van informatie noodzakelijk voor het nemen van deze beslissingen. De benodigde informatie wordt deels voorzien door het management (statische VLAN configuratie) en deels door het leren van MAC adressen (dynamisch).
- 16 -
Evaluatie van een VLAN Registratie Protocol in Ethernet Alle frames – tagged of untagged – worden enkel over de actieve topologie doorgestuurd en kunnen slechts tot één VLAN behoren Een VLAN kan maximaal de volledige actieve topologie omvatten. Het verwerken van frames in een bridge verloopt in drie stadia: − toepassen van de “ingress rules” − forwarding − toepassen van de “egress rules” Bij het toepassen van de “ingress rules” wordt elk frame in een bepaalde VLAN klasse ondergebracht. Onder een VLAN klasse verstaan we een verzameling van alle pakketten met eenzelfde VLAN groepsnummer (VID). Deze classificatie kan eventueel gebeuren op basis van het nummer van de inkomende poort of het door het MAC frame meegedragen protocol (port/protocol based classification). Op basis van het type frame (zie 3) en de informatie meegedragen door het specifieke type wordt dan beslist of het pakket aanvaard of verworpen wordt. Een frame kan bijvoorbeeld geweigerd worden omdat het VLAN in kwestie niet wordt ondersteund door de poort waarop het ontvangen werd. 5 GARP VLAN Registration Protocol Het GARP VLAN Registratie Protocol (GVRP [3]) is voor VLAN wat STP is voor MAC: een
automatische/dynamische configuratie
zonder
directe tussenkomst
van
het
management. Er zijn verschillende mogelijkheden voor de configuratie die per poort gebeurt: − statische configuratie: geen GVRP, enkel VLAN − dynamische configuratie: geen VLAN, enkel GVRP − een combinatie van voorgaande In het laatste geval kan de statische configuratie o.a. gebruikt worden om restricties op te leggen aan de mogelijke operaties van GRVP op een bepaalde poort. Een voorbeeld voor één poort is het beperken van de registraties tot een beperkt aantal – door het management bepaalde – VLAN’s. Voor de werking van GVRP verwijzen we naar de paragraaf over GARP met dien verstande dat de GVRP waarden 12bit lang zijn en dat het attribuut type voor GVRP 0x01
- 17 -
Evaluatie van een VLAN Registratie Protocol in Ethernet is. GVRP PDUs worden altijd in untagged frames [zie VLAN paragraaf] verstuurd. Hieronder volgt een voorbeeld van een minimaal GARP/GVRP frame, i.e. het bevat slecht één bericht, één attribuut en één waarde. GARP
GVRP
lengte
EVENT
VID
EM
EM
(8bit)
(8bit)
(8bit)
(8bit)
(12bit)
(8bit)
(8bit)
0x01
0x01
0x03
0x02 (join) var
0x00
0x00
0x04 (leave)
- 18 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
3. Implementatie 1 Opnet Modeler Zoals reeds eerder vermeld werd van de Opnet Modeler simulatiesoftware gebruik gemaakt om de simulatie te implementeren en uit te voeren. Het simulatiemodel bestaat uit verschillende lagen: − netwerk & subnetwerk(en) − knopen (nodes) & links − processen
1.1
Netwerkniveau
Figuur 8: Netwerk met 3 switches
Een netwerk of network model bestaat uit aantal subnetwerken die eventueel onderling verbonden zijn. Een subnetwerk is een verzameling van knopen en links die deze knopen verbinden. Elke knoop behoort tot een bepaald type. Bijvoorbeeld: een 16-poorts 10/100Mb Ethernet switch, een ftp server, een netwerkclient, etc. Deze types worden
- 19 -
Evaluatie van een VLAN Registratie Protocol in Ethernet binnen Opnet “node models” genoemd. De implementatie van de switches in figuur 4 zijn dus gelijk, ze verschillen enkel in hun configuratie die voor de start van de simulatie wordt ingesteld. Voorbeelden van zo’n instellingen zijn de naam of in het specifieke geval van de switches de mogelijkheid om al dan niet VLAN’s te ondersteunen. De functionaliteit van het netwerkelement hangt dus voor het grootste deel af van de onderliggende implementatie. Tot zover is de analogie met de realiteit overduidelijk.
1.2
receiver
Knoopniveau
transmitter
processor
Figuur 9: Standaardcomponenten
- 20 -
wachtrij
Evaluatie van een VLAN Registratie Protocol in Ethernet Figuur 10: Knoopmodel van een 16-ports switch
Een netwerkelement of knoop is op z’n beurt opgebouwd uit een aantal standaard componenten: wachtrijen, processors, transmitters, receivers, … Onderling zijn deze componenten verbonden door “packet streams” die men kan beschouwen als links binnenin knopen. Ze maken het mogelijk om pakketten van de ene component naar de andere te verplaatsen. In tegenstelling tot links tussen knopen (internodelinks), hebben links binnenin knopen (intranodelinks) een oneindige bandbreedte en geen enkele latentie. Een pakket verstuurd aan één kant van een componentlink zal dus ongeacht de grootte ogenblikkelijk aan de andere kant beschikbaar zijn. Bij het implementeren van een knoop moet hiermee rekening gehouden worden. Het is immers mogelijk dat een pakket in “no time” verwerkt wordt, wat in de meeste gevallen niet overeenstemt met de realiteit en een kunstmatige vertraging vereist is. Een typische configuratie is deze waarbij een wachtrij (queue) wordt verbonden met een processor en een transmitter/receiver paar. De receiver staat in voor het ontvangen van de pakketten waarna deze over een intranode link in de buffer (de wachtrij) terechtkomen. De processor beslist dan wat er met de pakketten in de wachtrij gebeurt. De informatie over het pakket kan gebruikt worden door de processor, waarna het pakket meestal vernietigd wordt indien het bestemd is voor het netwerkelement waarin het zich bevindt. Het kan uiteraard ook doorgestuurd worden via de transmitter naar een andere netwerkknoop (over een internode link). Receivers en transmitters zijn standaard componenten en staan enkel in voor het verzenden en ontvangen van gegevens. Ze kunnen slechts op een beperkt aantal punten aangepast worden. De wachtrij- en processorcomponenten echter bezitten een gebruikerseigen implementatie. Deze bestaat uit een Finite State Diagram (FSD) met per toestand twee blokken C/C++ code: één voor het betreden (enter) en één voor het verlaten (exit) van de toestand. Het FSD in de figuur zal dus met 4 toestanden (auto_addr, wait, init, idle) 8 blokken code tellen. De initiële toestand wordt aangeduid door de zwarte pijl. De mogelijke overgangen worden – zoals gebruikelijk – aangeduid door eenrichtingspijlen, eventueel voorzien van een voorwaarde waaronder die overgang mag gebeuren. Voorwaarden zijn zeker nodig indien vanuit een toestand meerdere overgangen mogelijk zijn. Een voorbeeld van zo’n voorwaarde is het al dan niet leeg zijn van een wachtrij of het - 21 -
Evaluatie van een VLAN Registratie Protocol in Ethernet vrij zijn van een processor in het netwerkelement. De voorwaarde default in de figuur is waar indien er geen andere overgangen waar zijn. In dit geval is deze voorwaarde altijd waar en in feite overbodig, de figuur komt uit een bestaande implementatie. Belangrijker zijn de processor componenten die de eigenlijke logica bevatten. Elke processor behoort tot een bepaald “process model” dat bestaat uit een finite state diagram en blokken C/C++ code. Over deze component valt relatief weinig te vertellen. Het is het werkpaard van de netwerkcomponent maar op dit niveau is het niet veel meer dan een black box waarvan enkel de naam van het process model iets over de functionaliteit prijsgeeft. Wachtrijen zijn in dit geval van minimaal belang en we zullen er hier dan ook niet veel verder op ingaan. Qua gebruik en achtergrond zijn ze gelijkaardig aan processors. Er bestaan immers verschillende wachtlijndisciplines die elk een andere implementatie vereisen (FIFO, LIFO, RED, …). Achter elke wachtlijn bevindt zich ook een process model. Dit feit benadrukt de analogie tussen de processor component en de wachtrij component.
1.3
Procesniveau
Zoals eerder vermeld bevindt de logica zich in de proces modellen (process models). Zo’n model bestaat uit een finite state diagram waarbij elke toestand voorzien wordt van twee blokken C/C++ code. Het enter blok wordt uitgevoerd bij het betreden van de toestand en het exit blok bij het verlaten van de toestand. Vanuit een toestand zijn meerdere overgangen mogelijk. Indien dit het geval is worden ze voorzien van een voorwaarde om uit te maken welke de volgende toestand zal zijn. Het spreekt voor zich dat deze voorwaarden niet mogen conflicteren, i.e. ze moeten mutueel exclusief zijn. In veel gevallen moeten ze ook compleet zijn. M.a.w. ze moeten alle mogelijke gevallen dekken. Een speciaal geval echter is de “default” voorwaarde die waar is als en slechts als alle andere beschouwde voorwaarden vals zijn. Er bestaan twee types toestanden: de “unforced” en “forced” toestanden. De overgang vanuit een groen gekleurde unforced toestand gebeurt zonder externe tussenkomst. I.e. de toestand wordt betreden waarbij de code in het enter-blok wordt uitgevoerd en wordt onmiddellijk verlaten (de code in het exit-blok wordt uitgevoerd). Het netwerkelement zal - 22 -
Evaluatie van een VLAN Registratie Protocol in Ethernet zich dus nooit gedurende een langere periode in een unforced toestand bevinden. De rode forced toestanden daarentegen vereisen een externe tussenkomst om de toestand te verlaten. De forced toestanden blokkeren dus in tegenstelling tot hun unforced soorgenoten. De simulatie kernel zal indien dit opportuun is een onderbreking naar het netwerkelement sturen die wordt opgevangen door de huidige toestand van het finite state diagram. Opnet Modeler bevat verschillende types onderbrekingen waaronder stream interrupts voor pakketaankomsten, het starten en beëindigen van de simulatie en self interrupts. Dit laatste type wordt verder in het voorbeeld verduidelijkt. Elke interrupt kan voorzien worden van een zogenaamde ICI object (Interrupt Control Information) dat meer uitgebreide informatie bevat. Een ICI object kan men nog het beste vergelijken met een klassieke struct in C. Uiteraard bestaan hier ook meerdere types, veel meer dan het aantal interrupttypes. Er bestaan ongeveer een tiental interrupt types. Dit aantal is vast. Er kunnen daarentegen wel ICIs worden bijgemaakt door de gebruiker. Hun aantal is dus (in theorie althans) onbeperkt.
Figuur 11: Finite State Diagram
In het eenvoudig proces model van figuur 6 wordt eerst een initialisatiefase voltooid waarna onmiddellijk wordt overgegaan naar de inactieve (idle) toestand. De init toestand is immers unforced. De processor blijft in de inactieve toestand tot er een onderbreking optreedt die de aankomst van een pakket signaleert. De overgang is voorzien van een voorwaarde die op het eerste zicht niet nodig is, er is immers maar één mogelijke volgende toestand (busy). Deze voorwaarde vormt echter een controle dat de interrupt wel degelijk een stream interrupt is. Merk hierbij op dat het optreden van een ander type interrupt tot een runtime fout zal leiden: er is in voorkomend geval geen overgang mogelijk gezien de - 23 -
Evaluatie van een VLAN Registratie Protocol in Ethernet enige voorwaarde niet voldaan zal zijn waardoor de simulatiekernel onmogelijk kan uitmaken welke de volgende toestand is. In de busy toestand zal er een self interrupt worden geprogrammeerd die voor een kunstmatige vertraging in de verwerking van het pakket zal zorgen. Indien dit niet geval is, zou het pakket in geen tijd worden afgewerkt wat niet echt overeenstemt met de realiteit. Op die manier zou het netwerkelement een oneindig aantal pakketten per tijdseenheid kunnen behandelen. Bij het optreden van de self interrupt, typisch een aantal milliseconden later, wordt een pakket uit de wachtrij gehaald en in geen tijd afgewerkt. Er zijn nu twee mogelijke overgangen. Ofwel is de wachtrij leeg en keren we naar de inactieve toestand terug, ofwel bevinden er zich nog pakketten in de wachtrij die op service wachten en keren we terug naar de “busy” toestand. Tot zover het Finite State Diagram van het voorbeeld proces model. Over naar het andere aspect van de interne keuken: de blokken C/C++ code. Voor de implementatie van de blokken code wordt vooral gesteunde op de ingebouwde kernel procedures van Opnet Modeler. Deze worden onderverdeeld in een twintigtal categoriën (packages). De meest relevante hiervan zijn: − ev: Event package − ici: Interface Control package − id: Identification package − ima: Internal Model Attribute package − intrpt: Interrupt package − pk: Packet package − pro: Process package − sub(q): (Sub)Queue package − sim: Simulation package − stm: Stream package − topo: Topology package Alle ingebouwde procedures zijn van de vorm op_afk_procedurenaam. Het “op” deel wijst erop dat het een Opnet eigen procedure is en afk staat voor de afkorting van de desbetreffende categorie. Eenvoudige voorbeelden hiervan zijn: op_pk_create() om een pakket te creëren of op_sim_end() om de simulatie vroegtijdig te beëindigen. Andere
- 24 -
Evaluatie van een VLAN Registratie Protocol in Ethernet (combinaties van) procedures voorzien in het uitlezen van pakketten in een wachtrij, het versturen van pakketten, het bepalen van het interrupttype etc… Bij de eigen implementatie van procedures werd dezelfde conventie gehanteerd. Bijvoorbeeld stb_gvrp_process waarbij stb staat voor “spanning tree bridge”. Het hoeft eigenlijk niet gezegd te worden dat dit de leesbaarheid en duidelijkheid van de code aanzienlijk verbetert. Het thuisbrengen van een ongekende functie wordt op deze manier een stuk eenvoudiger. Het is immers geen sinecure om in een ongekend model de implementatie van een functie terug te vinden in het grote aantal codeblokken of geïncludeerde header bestanden. Meer details over de kernel procedures kan gevonden worden in de uitstekende Opnet Modeler documentatie. Informatie over de zelfgeschreven procedures bevindt zich deels in de code zelf en in het hoofdstuk over de implementatie van GVRP. Over de bestaande nietkernel procedures is er helaas weinig documentatie te vinden. Normaal vormt dit geen probleem aangezien de samenwerking tussen modellen op hoger niveau via onderbrekingen en pakketten verloopt. Er wordt in principe niet rechtstreeks in het geheugen van andere proces modellen geschreven. Bij de implementatie van de eigen module moest echter rekening gehouden worden met de drie bestaande proces modellen die samen een gemeenschappelijk geheugen delen. Het was dus belangrijk om het nieuwe model volledig compatibel te maken zonder de bestaande modellen substantieel te wijzigen. Door de extra informatie die het nieuwe model met zich meebracht waren toch wijzigingen noodzakelijk aan de structuur van het gemeenschappelijk geheugen. Er is hierbij enkel functionaliteit toegevoegd. In één van de bestaande modules werden enkele regels code aangepast om de toegang tot de nieuwe functionaliteit te verhinderen. Behalve deze regels zijn de modules onveranderd gebleven. Voor de compilatie van de C/C++ code wordt gebruik gemaakt van de compiler uit Microsoft Visual C++. De samenwerking met deze externe compiler loopt niet altijd even vlot. Er traden een groot aantal problemen op die gerelateerd waren aan deze samenwerking.
- 25 -
Evaluatie van een VLAN Registratie Protocol in Ethernet 2 Opnet implementatie
2.1
Switch
Er werd gestart vanaf een bestaande 16-poorts switch. Elke poort bestaat uit een receiver/transmitter paar en een wachtrij. Centraal bevindt zich nog een wachtrij die verbonden is met alle andere en opgebouwd is uit verschillende “subqueues”. Deze centrale wachtrij zorgt voor het toekennen van de pakketten aan het gepaste proces. Het achterliggende model bridge_dispatch_VLAN biedt ondersteuning voor datapakketten en pakketten van het Spanning Tree Protocol. Hiertoe bestaat de wachtrij uit twee subwachrijen: één voor datapakketten, één voor de STP pakketten.
Figuur 12: Standaard switch
Op basis van het oude knoop model (ethernet16_bridge_VLAN) werd er een nieuw knoop model (ethernet16_bridge_gvrp) gecreëerd dat de bestaande functionaliteit integraal overnam en tegelijk ook in de nieuwe GVRP functionaliteit moest voorzien. Het standaard dispatcher proces model werd hernoemt naar bridge_dispatch_gvrp en zoals de naam reeds doet vermoeden uitgebreid met ondersteuning voor GVRP pakketten. Door het toevoegen van een derde “subqueue” voor GVRP pakketten werd de modulaire opbouw van het standaard model bewaard. Uiteraard werd de routeringslogica van de wachtrij aangepast zodat deze ook GVRP pakketten kan herkennen. Naast de uitbreiding voor het routeren van GVRP pakketten werd tijdelijk een interface voorzien voor het handmatig bijsturen van het GVRP protocol, maar deze werd later terug verwijderd omdat deze voorziening gezien de beoogde doelstelling overbodig was.
- 26 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
Figuur 13: Uitgebreide switch
Bij een eventuele verdere uitbreiding voor andere GARP protocollen volstaat het om een subqueue toe te voegen en de logica uit te breiden naar analogie van het GVRP geval. Het is ook mogelijk om alle GARP pakketten in dezelfde subqueue te plaatsen maar hierdoor zou er een deel modulariteit verloren gaan en zal het proces model voor GVRP pakketten (dat verder aan bod komt) aangepast moeten worden. Uiteraard moet voor elke subqueue een achterliggend proces model worden gecreëerd dat de pakketten verder afhandelt.
Figuur 14: Proces model van dispatcher
De werking van het dispatcher proces model is vrij eenvoudig. Na de opstartfase waarin gemeenschappelijk geheugen wordt geïnitialiseerd bevindt het proces zich in de idle toestand. Bij aankomst van een pakket wordt de code in het exit-blok van de idle toestand uitgevoerd. Deze bepaald het type van het pakket en plaatst het in de correcte subqueue. Indien het geen GVRP pakket of STP pakket is, wordt het als een gewoon datapakket beschouwd. Dit heeft als gevolg dat pakketten van niet geïmplementeerde protocollen transparant behandeld worden. In het specifieke geval van de standaard 16-poorts switch zal een GVRP pakket als datapakket behandeld worden, zoals in de IEEE standaard wordt voorzien. Nadat het pakket in de gepaste subqueue geplaatst is wordt gecontroleerd of het achterliggende proces actief is. Indien nodig wordt het geactiveerd.
- 27 -
Evaluatie van een VLAN Registratie Protocol in Ethernet De enige functie van de dispatcher bestaat er dus uit de pakketten te herkennen en in de gepaste wachtrij te plaatsen waarbij eventueel een aanroep ter activering van het achterliggende proces nodig is.
2.2
GVRP proces model
Voor we overgaan tot de bespreking van het toegevoegde proces model merken we op dat één bestaand proces model (bridge_protocol_entity) werd aangepast met betrekking tot de toegang van het gemeenschappelijk geheugen. Dit proces houdt de VLAN tabel bij met alle geregistreerde VLAN’s. Er wordt echter geen onderscheid gemaakt tussen records afkomstig van GVRP of records die werden toegevoegd door het management. De structuur van het gemeenschappelijk geheugen werd aangepast zodat er onderscheid gemaakt kon worden tussen dynamische en statisch records, i.e. GVRP of management records. Records toegevoegd door het STP proces model (bridge_protocol_entity) worden als statisch gemerkt, records toegevoegd door het GVRP proces model als dynamisch. Deze aanpassing was noodzakelijk omdat het STP proces records afkomstig van het GVRP protocol zou verwijderen. Zoals eerder vermeld werd een nieuw proces toegevoegd aan de bestaande switch. Het bridge_gvrp_entity proces handelt de GVRP pakketten of GVRP Protocol Data Units (GPDU’s) af. De interface van dit model naar het bridge_dispatch_gvrp proces lijkt sterk op de interfaces van de andere twee proces modellen.
- 28 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
Figuur 15: Finite State Diagram bridge_gvrp_entity
Het Finite State Diagram FSD van het bridge_gvrp_entity proces wordt hierboven gegeven. Bij het opstarten van de Opnet simulator wordt de code in de init toestand uitgevoerd waarna een onmiddellijke overgang volgt naar de idle toestand. Herinner dat de init toestand een unforced toestand is, de toestandsovergang vindt zonder externe onderbreking plaats. In deze toestand wordt het gemeenschappelijk geheugen gelezen en geschreven. Ook de service tijd nodig voor het afhandelen van een GVRP pakket wordt berekend op basis van een door de gebruiker opgegeven verwerkingssnelheid (in pakketten per seconde). Het proces blijft in de “idle” toestand totdat een onderbreking wordt opgevangen. Bij het verlaten van de idle toestand wordt een vlag aangezet die een indicatie vormt dat de switch GPDUs aan het afhandelen is. Deze vlag wordt gelezen door het dispatcher proces (zie vorige paragraaf). Er zijn twee mogelijkheden voor het verlaten van de idle toestand: ofwel komt de onderbreking van de console (management), ofwel komt de onderbreking van een aankomst van een pakket (interface). In het eerste geval wordt een tussenstap gemaakt via de toestand console waar aan de hand van de Opnet onderbreking informatie een nieuw GVRP pakket wordt aangemaakt en achteraan de wachtrij toegevoegd wordt, alsof het uit een (virtuele) interface ontstaat. De busy toestand maakt dus geen onderscheid tussen de
- 29 -
Evaluatie van een VLAN Registratie Protocol in Ethernet kunstmatig door de gebruiker gecreëerde pakketten of de pakketten die op “natuurlijke” wijze door het GVRP protocol worden doorgestuurd. We komen dus sowieso in de “busy” toestand terecht die de GPDUs verwerkt. Na het afhandelen van een GVRP pakket zijn er twee mogelijke overgangen: ofwel is de wachtrij met GPDUs leeg en gaat het proces over naar de idle toestand, ofwel wordt het volgende pakket uit de wachtrij genomen en afgehandeld. Merk hierbij op dat de wachtrij voor GPDUs zich niet in het FSD bevindt maar wel in het model van de switch. Bij het registreren van een VLAN wordt de informatie vervat in het pakket opgeslagen in een filter database waarna indien nodig kopieën van dit pakket doorgestuurd naar alle poorten van de actieve topologie zodat de informatie zich verder kan propageren. Een belangrijk gegeven bij het afhandelen van de registratie en deregistratie van VLAN’s is de gebruikte datastructuur van de filter database. Deze is reeds aanwezig in Opnet voor de bestaande MAC en STP modules. We moeten dus gebruik maken van deze datastructuur indien we de bestaande implementatie zo veel mogelijk willen behouden. De datastructuur bestaat enerzijds uit een hashtabel met eenvoudige hashfunctie die gebruik maakt van het MAC adres en de wiskundige modulo operator. Elk element van deze hashtabel (standaard 100 elementen) is een gelinkte lijst (linked list) met volgende datastructuren: /* Structure that defines the a filtering database entry.
*/
typedef struct StbT_Filtering_Info { int
type;
int
station_address;
int
VLAN_id;
int
port_no;
double
time_stamp;
struct StbT_Filtering_Info* next; } StbT_Filtering_Info;
Het type duidt op een statisch of dynamisch record, al naargelang het om een record ingevoerd door ofwel MAC address learning of statische VLAN’s, ofwel door de werking van de GVRP module. Het station_address is het MAC adres waarover het gaat. Merk op dat dit (48bits) adres opgeslagen wordt in een 32bits integer! De veranderlijken VLAN_id - 30 -
Evaluatie van een VLAN Registratie Protocol in Ethernet en port_no bevatten respectievelijk het VLAN nummer (indien aanwezig) en het nummer van de poort waarop de informatie van toepassing is. De time_stamp informatie wordt gebruikt voor het verlopen van de informatie (ageing timers) en wordt op een eenvoudige maar efficiënte manier afgehandeld. De verwijzing naar het volgend element in de gelinkte lijst is opgeslagen in next. Eerst en vooral iets over de elegante oplossing voor de “ageing timers”. Er wordt niet gewerkt met timers die bij het aflopen het desbetreffende record uit de filter database verwijderen. Dit zou ook niet efficiënt zijn, gezien we voor elk record een afzonderlijke timer zouden moeten bijhouden. In plaats hiervan wordt bij het wegschrijven van een record de huidige tijd meegegeven (time_stamp). Bij het opzoeken wordt het verschil berekent tussen de huidige tijd en het tijdstip opgeslagen in het record zelf. Indien dit tijdsverschil aangeeft dat het record verlopen is, dan wordt het als ongeldig beschouwd en verwijderd. Dit vermijd het gebruik van “echte” timers, maar heeft wel als nadeel dat de filter database niet altijd in een consistente toestand is. Bij elke benadering van de filter database moet dus rekening gehouden worden met eventueel verlopen records. In de bestaande implementatie wordt met 32bits lange MAC adressen gewerkt. Hoewel dit niet direct voor problemen hoeft te zorgen zou het toch handig zijn om - met het oog op een meer realistische simulatie – met 48bits MAC adressen te werken. Hiervoor zou een afzonderlijke C++ klasse bijzonder geschikt zijn. Het gevaar dat het bereik van 32bit MAC adressen in een Opnet simulatie zou opgebruikt raken is minimaal, we hebben nog altijd keuze uit ruwweg 4 miljard MAC adressen. Daarentegen is er een veel belangrijker nadeel van het kunstmatig inkorten van MAC adressen. Het probleem ontstaat nadat een interface het 32bit adres C2-00-00-21 toegekend krijgt (adressen worden automatisch toegekend). Indien dan een GVRP pakket met broadcast(!) adres 01-80-C2-00-00-21 wordt verstuurd zal het door de inkorting worden afgehandeld worden als een pakket bestemd voor de interface met adres C2-00-00-21! De kans is klein, maar niet onbestaande. De keuze om de MAC adressen als 32bits integers op te slaan ligt in de oorspronkelijke implementatie en is in mijn ogen een groot hiaat in de implementatie. Hoewel de filtering database efficiënt kan opzoeken op basis van MAC adres d.m.v. de hashfunctie, is het veel moeilijker om op een efficiënte manier te bepalen welke poorten geregistreerd zijn in een VLAN. Indien we enkel gebruik maken van de bestaande - 31 -
Evaluatie van een VLAN Registratie Protocol in Ethernet implementatie en deze niet (substantieel) aanpassen worden we genoodzaakt om record per record te bekijken. Statische records kunnen we onmiddellijk overslaan, dynamische records moeten in detail ontleed worden. Aangezien het hier om een simulatie gaat werden geen optimalisaties met betrekking tot deze opzoeking geïmplementeerd. Volgende voorstellen zijn evenwel het overwegen waard voor toekomstige verbeteringen: − bijhouden van het aantal geregistreerde poorten per VLAN, indien maar 1 poort geregistreerd is en deze de registratie opzegt hoeven we de gehele database niet te doorzoeken (we kennen immers de poort waarop het unregister pakket binnengekomen is) − een overspannende datastructuur die de records per VLAN of per poort ordent, bij het benaderen van de filter database moeten we dan wel telkens in twee datastructuren wijzigingen aanbrengen De feitelijke logica voor het verwerken van de pakketten bevindt zich in het zogenaamde “header block” van het proces model. Vanuit de “busy” toestand wordt de functie stb_process_gpdu aangeroepen. In eerste instantie werd een eenvoudige logica voorzien: elk pakket wordt doorgestuurd naar elke poort van de actieve topologie, behalve naar de poort waarop het pakket ontvangen werd. Op deze manier propageert de informatie zich over gans het netwerk. Er werd ook een afzonderlijke functie voorzien voor het verzenden van GVRP pakketten. Daarnaast werden met het oog om de integratie van de bestaande click/linux code functies voorzien die de gemeenschappelijke VLAN tabel aanspreken. Door deze eenvoudige logica kon de correcte werking van de bestaande implementatie geverifieerd worden. Na het opzetten van deze structuur was het enkel een kwestie van de eenvoudige logica te vervangen door de click/linux logica. 3 Click/linux code In de prille beginfase was het de bedoeling om de click/linux code als een black box te behandelen en deze quasi integraal in het Opnet model op te nemen. Eenmaal de structuur in Opnet duidelijker vormen aannam, bleek het een omslachtige taak te worden om de eigenschappen van Opnet met die van de click code te verenigen. Zoals reeds eerder vermeld gebruikt Opnet de compiler van Visual Studio die niet onder Linux draait.
- 32 -
Evaluatie van een VLAN Registratie Protocol in Ethernet In een eerste poging werd geprobeerd om de click code rechtstreeks in het Opnet model op te nemen d.m.v. C-header files. Dit mislukt door de aanwezigheid van de linux specifieke code. De herwerkte compiler output die door Opnet Modeler getoond werd maakte het onbegonnen werk om op deze manier de “fouten” op te sporen. Het voornaamste probleem op dat moment waren de linux specifieke eigenschappen van de code die onverenigbaar waren met de gebruikte compiler. We merken hierbij op dat het überhaupt niet mogelijk is om van een andere compiler gebruik te maken. De click/linux code werd opgenomen in een Visual Studio “project” dat compleet losstond van Opnet. We vervingen de Linux code waar mogelijk door de Windows variant of implementeerden zelf een gelijkaardige functie. De ontbrekende definities van constanten werden opgezocht en overgenomen uit de Linux header files. De interface naar de netwerklaag, gerepresenteerd door de Berkley socket functieaanroepen zoals connect, closesocket, e.d. werden uitgecommentarieerd. Deze moesten sowieso vervangen worden door aanroepen naar Opnet eigen functies. Het idee om via een interface de click code aan de Opnet code te koppelen leek tijdens het wijzigen van de click code steeds verder en verder van de realiteit weg te drijven. In dit stadium hadden we het idee van de “black box” volledig laten varen, één interface, hoe ingewikkeld ook, zou de klus niet kunnen klaren. De structurele verschillen tussen beide modellen waren te groot. Een tweede poging om het Opnet model met de click code samen te voegen en te compileren lukte na wat last met header files wel. We hadden een model met alle beschikbare functionaliteit, maar de structuur was niet volledig. De Opnet stuctuur was gerealiseerd, de click/linux structuur bestond al, maar beide samen wilde maar niet lukken. Merk hierbij op dat bij de implementatie van de Opnet structuur rekening moest gehouden worden met de reeds bestaande proces modellen. Ondertussen werd de gebruikte pc (Helena) steeds onstabieler waardoor ze regelmatig crashte. Er werd beslist om over te stappen naar een andere pc (Hesperia). Helena was tijdelijk ontoegankelijk, maar er werd verder gebouwd van een back-up. Hoewel Hesperia volledig stabiel was, zat er duidelijk een kink in de kabel bij de samenwerking van Opnet en de Visual Studio compiler. Header files werden bij compilatie niet gevonden, ook niet na aanpassing van de compiler argumenten of de windows path variabelen.
- 33 -
Evaluatie van een VLAN Registratie Protocol in Ethernet Een probleem van andere aard was het gebruik van real time timers in de click code. Perfect voor een real time praktijksimulatie gesteund op de tijdsindicatie van de pc, maar ongeschikt voor een software implementatie die op elk moment door de gebruiker onderbroken kan worden. Een mogelijk oplossing hiervoor bestond erin om de timer de Opnet “tijd” voor te spiegelen. Deze oplossing kon evenwel niet getest worden omdat de vorige fase niet gecompleteerd was. Een andere mogelijkheid hieromtrent was het gebruik van de Opnet voorzieningen voor timers, i.e. Finite State Diagramma’s en self interrupts. De structuur van de click code is heel verschillend van een Opnet simulatie in het algemeen en de implementatie van het simulatiemodel in het bijzonder. In die mate zelfs dat een behandeling als “black box” absoluut niet mogelijk is. De functionaliteit zou uit de click structuur moeten gesneden worden en overgeplaatst worden naar de Opnet structuur. Vermits de logica achter GVRP voornamelijk bestaat uit het bijhouden van toestanden en het verwerken van berichten biedt een Finite State Diagram binnen Opnet waarschijnlijk de beste oplossing. Maar dit is mijlenver verwijderd van de oorspronkelijke doelstelling om de click code zo goed mogelijk over te nemen.
- 34 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
4. Simulatie Er werd geëxperimenteerd met een eenvoudig netwerk, ter controle van de correcte werking van de basisfunctionaliteit zoals het verzenden, ontvangen en verder afhandelen van pakketten. De Opnet debugger werd gebruikt om het proces tot in het kleinste detail te bestuderen en alles te verifiëren. Dit experiment toont de operationele basisfunctionaliteit van het model aan zonder de integrale logica van het GVRP protocol die zich in de click/linux code bevindt. De niet voltooide integratie van de click/linux code in het Opnet model verhinderde een simulatie in een uitgebreider netwerk waarbij de volledige logica van het click/linux GVRP protocol kon worden betrokken en het model uitgebreid getoetst kon worden aan eerdere praktijktests met het click/linux model.
- 35 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
5. Conclusie Het gebruik van Opnet Modeler als simulatiepakket lijkt tot op zekere hoogte voor de hand liggend. De basisprincipes zijn eenvoudig en vergen geen dieper inzicht in de feitelijke implementatie en de werking van de simulator. Het opbouwen van een netwerk aan de hand van reeds bestaande modellen gaat vlot. Eens men dieper gaat graven komt men terecht in een onoverzichtelijk kluwen van code. Het ontwarren en begrijpen van deze quasi ongedocumenteerde code vergt behoorlijk wat tijd waardoor het rendement minimaal is. De kennis van de volledige interne werking van de bestaande modellen is echter nodig om het nieuwe model er naadloos mee te laten samenwerken. Alhoewel geen concreet cijfermateriaal werd bekomen, is er toch een brede basis gelegd voor de verdere integratie van het GVRP protocol. Qua functionaliteit kan de herwerkte click code als basis dienen. Een andere optie is het over boord gooien van het idee om de click code te gebruiken en een 100% Opnet model te creëren. De modulaire implementatie laat sowieso uitbreidingen toe naar andere GARP protocollen, voor welke van de voorgaande opties ook gekozen wordt. Door het botsen van de structuur van enerzijds de click code en anderzijds de Opnet Modeler implementatie is de integratie van de click/linux code als black box niet gelukt. Ook na aanpassing bleef de structuur van beide stukken code botsen. De correcte werking van de nieuw geïmplementeerde structuur werd reeds in detail geverifieerd met behulp van de Opnet debugger en kan dienst doen als structuur voor de afzonderlijke functionaliteit uit de click code.
- 36 -
Evaluatie van een VLAN Registratie Protocol in Ethernet
Referenties
[1]
IEEE, Media Access Control (MAC) Bridges, IEEE 802.1d, 1998
[2]
IEEE, Rapid Reconfiguration of Spanning Tree, IEEE 802.1w, 2001
[3]
IEEE, Virtual Bridged Local Area Networks, IEEE 802.1q, 2003
[4]
IEEE, Technical and editorial comments, IEEE 802.1u, 2001
[5]
IEEE, VLAN Classification by Protocol and Port, IEEE 802.1v, 2001
[6]
IEEE, Multiple Spanning Trees, IEEE 802.1s, 2002
Voor een niet limitatieve lijst van geraadpleegde websites verwijzen we naar de cd-rom.
- 37 -
