Hoe je de netwerkarchitectuur onder controle krijgt. Hoofdstuk twee. Opschonen en documenteren

Dit artikel is de tweede in een reeks artikelen genaamd 'Hoe uw netwerkinfrastructuur onder controle te krijgen'. De inhoud van alle artikelen in de reeks en de links zijn te vinden hier.

Onze doelstelling op dit moment is het ordenen van de documentatie en de configuratie.
U moet aan het einde van dit proces een set documenten en een netwerk hebben dat hiermee is geconfigureerd.

We zullen nu niet praten over de beveiligingsaudit – dit zal het onderwerp zijn van het derde deel.

De complexiteit van de taak die in dit stadium moet worden uitgevoerd varieert sterk van bedrijf tot bedrijf.

De ideale situatie is wanneer

• uw netwerk is opgebouwd volgens het ontwerp en u heeft een complete set documentatie
• er in uw bedrijf een proces voor controle en wijzigingsbeheer is ingevoerd voor het netwerk
• overeenkomstig dit proces heeft u documenten (inclusief alle benodigde schema's) die volledige informatie geven over de actuele stand van zaken

In dat geval is uw taak vrij eenvoudig. U moet de documenten bestuderen en alle wijzigingen doornemen die zijn aangebracht.

In het slechtste geval heeft u een

• netwerk dat zonder ontwerp is opgebouwd, zonder plan, zonder goedkeuring, door ingenieurs zonder voldoende kwalificaties,
• met chaotische, niet-gedocumenteerde wijzigingen, met veel 'rommel' en suboptimale oplossingen

Het is duidelijk dat uw situatie ergens tussenin ligt, maar helaas, op deze schaal van beter – slechter, heeft u een grote kans dichter bij het slechte einde te zijn.

In dit geval zal het ook van u vragen dat u gedachten kunt lezen, omdat u moet leren begrijpen wat de 'ontwerpers' wilden doen, hun logica te reconstrueren, af te maken wat niet was afgerond en de 'rommel' te verwijderen.
En natuurlijk moet u ook hun fouten corrigeren, het ontwerp (in deze fase zo minimaal mogelijk) veranderen en schema's aanpassen of opnieuw creëren.

Dit artikel claimt in geen geval compleet te zijn. Hier zal ik alleen de algemene principes beschrijven en stil staan bij enkele veelvoorkomende problemen die opgelost moeten worden.

Documentenset

Laten we beginnen met een voorbeeld.

Hieronder staan enkele documenten die gebruikelijk zijn om te maken binnen Cisco Systems bij het ontwerpen.

CR – Klantvereisten, klantbehoeften (technische specificaties).
Wordt gezamenlijk met de klant opgesteld en definieert de eisen voor het netwerk.

HLD – High Level Design, een hoog-niveau ontwerp op basis van de netwerkvereisten (CR). Dit document verklaart en rechtvaardigt de aangenomen architectonische beslissingen (topologie, protocollen, apparatuurkeuze, ...). HLD bevat geen ontwerpdétails, zoals de gebruikte interfaces en IP-adressen. Specifieke apparatuurconfiguraties worden hier ook niet besproken. Dit document is eerder bedoeld om het technische management van de klant de belangrijkste ontwerpconcepten uit te leggen.

LLD – Low Level Design, een laag-niveau ontwerp op basis van het hoog-niveau ontwerp (HLD).
Het moet alle details bevatten die nodig zijn voor de uitvoering van het project, zoals informatie over hoe apparatuur aan te sluiten en in te stellen. Dit is een volledige gids voor de implementatie van het ontwerp. Dit document moet voldoende informatie bieden voor de uitvoering, zelfs door minder gekwalificeerd personeel.

Dingen zoals IP-adressen, AS-nummers, en de fysieke bekabelingsschema's kunnen "uitgebreid" worden naar aparte documenten, zoals NIP (Network Implementation Plan).

De bouw van het netwerk begint na het creëren van deze documenten en verloopt strikt in overeenstemming met hen, en wordt vervolgens door de klant gecontroleerd (tests) op overeenstemming met het ontwerp.

Natuurlijk kunnen de vereisten voor projectdocumentatie verschillen per integrator, per klant, en per land. Maar we willen formaliteiten vermijden en het onderwerp inhoudelijk benaderen. Deze fase gaat niet om ontwerpen, maar om het organiseren van zaken, en we hebben een voldoende aantal documenten nodig om onze taken uit te voeren (schema's, tabellen, beschrijvingen, ...).

En naar mijn mening bestaat er een absoluut minimum dat nodig is om het netwerk effectief te kunnen controleren.

Dit zijn de volgende documenten:

• schema (logboek) van de fysieke bekabeling
• schema of schema's van het netwerk met wezenlijke L2/L3-informatie

Fysieke schakelschema

In sommige kleine bedrijven vallen de taken met betrekking tot het installeren van apparatuur en fysieke bekabeling onder de verantwoordelijkheid van netwerkingenieurs.

In dit geval wordt het probleem gedeeltelijk opgelost met de volgende benadering.

• gebruik de beschrijving op de interface om te beschrijven wat eraan is verbonden
• schakel administratief alle ongebruikte poorten van netwerkapparatuur uit (shutdown)

Dit stelt je in staat om, zelfs in het geval van een probleem met de verbinding (wanneer cdp of lldp niet werkt op deze interface), snel te bepalen wat er op deze poort is aangesloten.
Daarnaast kun je eenvoudig zien welke poorten bezet zijn en welke vrij, wat nodig is voor het plannen van de aansluitingen van nieuwe netwerkapparatuur, servers of werkstations.

Maar het is duidelijk dat als je de toegang tot de apparatuur verliest, je ook de toegang tot deze informatie verliest. Bovendien kun je op deze manier geen belangrijke informatie vastleggen, zoals welk soort apparatuur, het stroomverbruik, het aantal poorten, in welke rack het zich bevindt, welke patchpanelen daar zijn, en naar welke rack/patchpaneel ze zijn geslacht. Daarom is aanvullende documentatie (niet alleen beschrijvingen op de apparatuur) erg nuttig.

De ideale optie is het gebruik van applicaties die zijn ontworpen voor het werken met dit soort informatie. Maar je kunt ook volstaan met eenvoudige tabellen (bijvoorbeeld in Excel) of de informatie die je nodig vindt, weergeven in L1/L2-schema's.

Belangrijk!

Een netwerkingenieur kan natuurlijk voldoende goed op de hoogte zijn van de nuances en normen van Systeem- en Kabelinfrastructuren, soorten racks, soorten ononderbroken stroomvoorzieningen, wat een koude en warme gang is, correct aarden,… evenals in principe de fysica van elementaire deeltjes of C++. Maar ze moeten toch begrijpen dat dit allemaal niet hun kennisgebied is.

Daarom is het een goede praktijk om voor de taken met betrekking tot de installatie, aansluiting, ondersteuning van apparatuur, en ook de fysieke schakeling ofwel gespecialiseerde afdelingen ofwel toegewezen mensen te hebben. Meestal zijn dit datacenter ingenieurs voor datacenters en help-desk voor kantoren.

Als dergelijke afdelingen in jouw bedrijf zijn voorzien, dan is het bijhouden van een logboek van fysieke verbindingen niet jouw taak, en kun je je beperken tot alleen de beschrijving op de interface en het administratief uitschakelen van ongebruikte poorten.

Netwerkschema's

Er is geen universele aanpak voor het tekenen van schema's.

Het belangrijkste is dat de schema's een begrip moeten geven van hoe het verkeer zal stromen, door welke logische en fysieke elementen van jouw netwerk.

Met fysieke elementen bedoelen we

• actieve apparatuur
• interfaces/poorten van actieve apparatuur

Onder logische —

• logische apparaten (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLANs
• subinterfaces
• tunnels
• zones
• …

Als uw netwerk niet helemaal eenvoudig is, zal het uit verschillende segmenten bestaan.
Bijvoorbeeld

• datacenter
• internet
• WAN
• externe toegang
• kantoor LAN
• DMZ
• …

Het is verstandig om verschillende schema's te hebben die zowel een algemeen overzicht geven (hoe het verkeer tussen al deze segmenten beweegt) als een gedetailleerde uitleg van elk afzonderlijk segment.

Aangezien moderne netwerken veel logische niveaus kunnen hebben, kan het een goed (maar niet verplicht) idee zijn om verschillende schema's voor verschillende niveaus te maken; bijvoorbeeld in het geval van een overlay-aanpak kunnen de volgende schema's gelden:

• overlay
• L1/L2 onderlaag
• L3 onderlaag

Natuurlijk is het belangrijkste schema, zonder hetwelk je het idee van je ontwerp niet kunt begrijpen, het routeringsschema.

Routeringsschema

Minimaal moet dit schema weergeven

• welke routeringsprotocollen waar worden gebruikt
• basisinformatie over de configuratie van het routeringsprotocol (gebied/AS-nummer/router-id/…)
• op welke apparaten herdistributie plaatsvindt
• waar filtering en aggregatie van routes plaatsvindt
• informatie over de standaard route

Een L2-schema (OSI) is ook vaak nuttig.

L2-schema (OSI)

Dit schema kan de volgende informatie bevatten:

• welke VLAN's
• welke poorten trunkpoorten zijn
• welke poorten zijn samengevoegd in ether-channel (port channel), virtual port channel
• welke STP-protocollen op welke apparaten worden gebruikt
• basisinstellingen van STP: root/root backup, STP-kosten, poortprioriteit
• aanvullende instellingen van STP: BPDU guard/filter, root guard…

Typische ontwerpfouten

Voorbeeld van een slechte benadering bij het bouwen van een netwerk.

Laten we een eenvoudig voorbeeld nemen van het opzetten van een eenvoudige kantoor-lokale netwerk.

Met ervaring in het onderwijzen van telecom aan studenten kan ik zeggen dat feitelijk elke student halverwege het tweede semester over de nodige kennis beschikt (binnen de cursus die ik gaf) om een eenvoudige kantoor-LAN te configureren.

Wat is er moeilijk aan het met elkaar verbinden van switches, instellen van VLAN, SVI-interfaces (in het geval van L3-switches) en het invoeren van statische routing?

Alles zal werken.

Maar daarmee blijven vragen over

• veiligheid
• redundantie
• netwerk schaalbaarheid
• prestaties
• doorvoersnelheid
• betrouwbaarheid
• …

Soms hoor ik de bewering dat een kantoorlokale netwerken (LAN) iets heel eenvoudigs is, en ik hoor dit meestal van ingenieurs (en managers) die met van alles bezig zijn, behalve netwerken. Ze zeggen dit zo vol vertrouwen dat je je niet zult verbazen als een LAN wordt opgezet door mensen met onvoldoende ervaring en kennis, met vele van de fouten die ik hieronder zal beschrijven.

Kenmerkende ontwerpfouten op L1-niveau (OSI)

• Als je ook verantwoordelijk bent voor het bekabelingsnetwerk, dan is een van de meest onaangename nalatenschappen die je kunt krijgen, slordige en niet doordachte schakelingen.

Ook zou ik fouten, gerelateerd aan de middelen van de gebruikte apparatuur, tot het L1-type rekenen, bijvoorbeeld,

• onvoldoende bandbreedte
• onvoldoende TCAM op de apparatuur (of inefficiënt gebruik daarvan)
• onvoldoende prestaties (vaak gerelateerd aan firewalls)

Kenmerkende ontwerpfouten op L2-niveau (OSI)

Vaak, als er geen goed begrip is van hoe STP werkt, welke potentiële problemen het met zich meebrengt, worden switches chaotisch aangesloten, met standaardinstellingen, zonder extra tuning van STP.

Als gevolg hiervan hebben we vaak het volgende

• een grote STP-diameter van het netwerk, wat kan leiden tot broadcaststorms
• STP-root wordt willekeurig bepaald (op basis van mac-adres) en de traffiekroute zal suboptimaal zijn
• poorten die zijn aangesloten op hosts, zullen niet zijn ingesteld als edge (portfast), wat zal leiden tot herberekening van STP bij het in- of uitschakelen van eindstations
• het netwerk zal niet zijn gesegmenteerd op L1/L2-niveau, waardoor problemen met een switch (bijvoorbeeld overbelasting van voeding) zullen leiden tot herberekening van de STP-topologie en stopzetting van het verkeer in alle VLAN's op alle switches (inclusief in segmenten die kritiek zijn voor continuïteit van de service)

Voorbeelden van ontwerpfouten op L3-niveau (OSI)

Verschillende kenmerkende fouten van beginnende netwerkbeheerders:

• frequent gebruik (of alleen gebruik) van statische routing
• gebruik van suboptimale routingprotocollen voor dit ontwerp
• suboptimale logische segmentatie van het netwerk
• suboptimaal gebruik van adresruimte, waardoor aggregatie van routes niet mogelijk is
• afwezigheid van back-uproutes
• afwezigheid van redundantie voor de default gateway
• asymmetrisch routeren bij herstructurering van routers (kan kritiek zijn in het geval van NAT/PAT, stateful firewalls)
• problemen met MTU
• bij het herstructureren van routes gaat het verkeer via andere beveiligingszones of zelfs andere firewalls, wat ertoe leidt dat dit verkeer wordt gedropt
• slechte schaalbaarheid van de topologie

Criteria voor de kwaliteitsbeoordeling van het ontwerp

Wanneer we het hebben over optimaliteit/onoptimaliteit, moeten we begrijpen vanuit welk criteria we dit kunnen beoordelen. Vanuit mijn perspectief zijn de meest significante (maar niet alle) criteria (en de uitleg met betrekking tot routingprotocollen):

• schaalbaarheid (scalability)
  Bijvoorbeeld, als u besluit om een extra datacenter toe te voegen. Hoe gemakkelijk kunt u dit doen?
• gebruiksgemak (manageability)
  Hoe gemakkelijk en veilig kunnen operationele wijzigingen worden doorgevoerd, zoals het aankondigen van een nieuw netwerk of het filteren van routes
• beschikbaarheid (availability)
  Wat is het percentage tijd dat uw systeem het vereiste serviceniveau biedt
• beveiliging (security)
  Hoe veilig zijn de verzonden gegevens
• price

Wijzigingen

Het belangrijkste principe in deze fase kan worden samengevat met de formule 'do not harm'.
Daarom, zelfs als u het niet helemaal eens bent met het ontwerp en de gekozen implementatie (configuratie), is het niet altijd zinvol om wijzigingen aan te brengen. Een verstandige aanpak is om alle geïdentificeerde problemen te rangschikken op basis van twee parameters:

• hoe gemakkelijk deze probleem kan worden opgelost
• hoe groot het risico is dat het met zich meebrengt

Voornamelijk moet u alles verhelpen wat op dit moment het niveau van de geboden service onder het toelaatbare niveau brengt, bijvoorbeeld problemen die leiden tot pakketverlies. Verhelp daarna datgene wat het gemakkelijkst en veiligst kan worden opgelost, in volgorde van afnemende ernst van het risico (van problemen in ontwerp of configuratie met grotere risico's naar kleinere).

Perfectionisme kan in deze fase schadelijk zijn. Breng het ontwerp in een bevredigende staat en synchroniseer de netwerkconfiguratie daarmee.

Bron: habr.com