Dit artikel is het tweede in een reeks artikelen “Hoe u de controle over uw netwerkinfrastructuur overneemt.” De inhoud van alle artikelen in de serie en links zijn te vinden .
Ons doel in deze fase is om orde te brengen in de documentatie en configuratie.
Aan het einde van dit proces moet u beschikken over de benodigde set documenten en een netwerk dat in overeenstemming daarmee is geconfigureerd.
Nu zullen we het niet hebben over beveiligingsaudits - dit zal het onderwerp zijn van het derde deel.
De moeilijkheidsgraad bij het voltooien van de taak die in dit stadium is toegewezen, varieert uiteraard sterk van bedrijf tot bedrijf.
De ideale situatie is wanneer
- uw netwerk is gecreëerd in overeenstemming met het project en u beschikt over een complete set documenten
- in uw bedrijf is geïmplementeerd voor netwerk
- conform dit proces beschikt u over documenten (inclusief alle benodigde schema’s) die volledige informatie geven over de huidige stand van zaken
In dit geval is uw taak vrij eenvoudig. U dient de documenten te bestuderen en alle aangebrachte wijzigingen te bekijken.
In het ergste geval zul je dat wel hebben
- een netwerk gecreëerd zonder project, zonder plan, zonder goedkeuring, door ingenieurs die niet over voldoende kwalificaties beschikken,
- met chaotische, ongedocumenteerde veranderingen, met veel ‘rommel’ en suboptimale oplossingen
Het is duidelijk dat uw situatie zich daar ergens tussenin bevindt, maar helaas is de kans op deze schaal van beter en slechter groot dat u dichter bij het slechtste einde zult zijn.
In dit geval heb je ook het vermogen nodig om gedachten te lezen, omdat je zult moeten leren begrijpen wat de ‘ontwerpers’ wilden doen, hun logica moeten herstellen, afmaken wat nog niet was voltooid en ‘afval’ moeten verwijderen.
En natuurlijk zul je hun fouten moeten corrigeren, het ontwerp (in dit stadium zo minimaal mogelijk) moeten veranderen en de schema's moeten veranderen of opnieuw moeten maken.
Dit artikel pretendeert geenszins volledig te zijn. Hier zal ik alleen de algemene principes beschrijven en me concentreren op enkele veelvoorkomende problemen die moeten worden opgelost.
Set documenten
Laten we beginnen met een voorbeeld.
Hieronder vindt u enkele documenten die gewoonlijk tijdens het ontwerp bij Cisco Systems worden gemaakt.
CR – Klantvereisten, klantvereisten (technische specificaties).
Het wordt samen met de klant gemaakt en bepaalt de netwerkvereisten.HLD – High Level Design, high-level ontwerp op basis van netwerkvereisten (CR). Het document legt de genomen architecturale beslissingen uit en rechtvaardigt deze (topologie, protocollen, hardwareselectie,...). HLD bevat geen ontwerpdetails, zoals de gebruikte interfaces en IP-adressen. Ook wordt de specifieke hardwareconfiguratie hier niet besproken. Dit document is veeleer bedoeld om de belangrijkste ontwerpconcepten uit te leggen aan het technisch management van de klant.
LLD – Low Level Design, low-level design gebaseerd op high-level design (HLD).
Het moet alle details bevatten die nodig zijn om het project uit te voeren, zoals informatie over het aansluiten en configureren van de apparatuur. Dit is een complete handleiding voor het implementeren van het ontwerp. Dit document moet voldoende informatie bieden voor de implementatie ervan, zelfs door minder gekwalificeerd personeel.Iets, bijvoorbeeld IP-adressen, AS-nummers, fysiek schakelschema (bekabeling), kan in aparte documenten worden ‘uitgezet’, zoals NIP (Netwerkimplementatieplan).
De aanleg van het netwerk begint na het aanmaken van deze documenten en gebeurt in strikte overeenstemming hiermee en wordt vervolgens door de klant gecontroleerd (testen) op overeenstemming met het ontwerp.
Uiteraard kunnen verschillende integrators, verschillende klanten en verschillende landen verschillende eisen stellen aan projectdocumentatie. Maar ik wil graag formaliteiten vermijden en de kwestie op zijn merites bekijken. Deze fase gaat niet over ontwerp, maar over het op orde brengen van de zaken, en we hebben voldoende documenten nodig (diagrammen, tabellen, beschrijvingen...) om onze taken te voltooien.
En naar mijn mening is er een bepaald absoluut minimum, zonder welk het onmogelijk is om het netwerk effectief te controleren.
Dit zijn de volgende documenten:
- schema (log) van fysieke schakeling (bekabeling)
- netwerkdiagram of diagrammen met essentiële L2/L3-informatie
Fysiek schakelschema
In sommige kleine bedrijven is het werk met betrekking tot de installatie van apparatuur en het fysiek schakelen (bekabeling) de verantwoordelijkheid van netwerkingenieurs.
In dit geval wordt het probleem gedeeltelijk opgelost door de volgende aanpak.
- gebruik een beschrijving op de interface om te beschrijven wat ermee is verbonden
- alle niet-verbonden netwerkapparatuurpoorten administratief afsluiten
Dit geeft je de mogelijkheid om, zelfs in het geval van een probleem met de link (wanneer cdp of lldp niet werkt op deze interface), snel te bepalen wat er op deze poort is aangesloten.
Ook kunt u eenvoudig zien welke poorten bezet zijn en welke vrij zijn, wat nodig is voor het plannen van aansluitingen van nieuwe netwerkapparatuur, servers of werkstations.
Maar het is duidelijk dat als u de toegang tot de apparatuur verliest, u ook de toegang tot deze informatie verliest. Bovendien kun je op deze manier niet zulke belangrijke informatie vastleggen als wat voor soort apparatuur, welk stroomverbruik, hoeveel poorten, in welk rack het zit, welke patchpanelen er zijn en waar (in welk rack/patchpaneel ) ze zijn verbonden. Daarom is aanvullende documentatie (niet alleen beschrijvingen van de apparatuur) nog steeds erg nuttig.
De ideale optie is om applicaties te gebruiken die zijn ontworpen om met dit soort informatie te werken. Maar u kunt zich beperken tot eenvoudige tabellen (bijvoorbeeld in Excel) of de informatie die u nodig acht in L1/L2-diagrammen weergeven.
Belangrijk!
Een netwerkingenieur kan natuurlijk heel goed de fijne kneepjes en standaarden van SCS kennen, de soorten racks, de soorten ononderbroken stroomvoorzieningen, wat een koud en warm gangpad is, hoe hij een goede aarding moet uitvoeren... net zoals hij dat in principe kan. ken de fysica van elementaire deeltjes of C++. Maar je moet nog steeds begrijpen dat dit allemaal niet zijn kennisgebied is.
Daarom is het een goede gewoonte om speciale afdelingen of toegewijde mensen te hebben om problemen op te lossen die verband houden met installatie, aansluiting, onderhoud van apparatuur en fysiek schakelen. Meestal zijn dit voor datacenters datacenteringenieurs, en voor een kantoor is dit een helpdesk.
Als dergelijke divisies in uw bedrijf aanwezig zijn, zijn de problemen met het loggen van fysieke schakelingen niet uw taak, en kunt u zich alleen beperken tot een beschrijving van de interface en het administratief afsluiten van ongebruikte poorten.
Netwerkdiagrammen
Er bestaat geen universele benadering voor het tekenen van diagrammen.
Het belangrijkste is dat de diagrammen inzicht moeten geven in hoe het verkeer zal stromen, via welke logische en fysieke elementen van uw netwerk.
Met fysieke elementen bedoelen we
- actieve uitrusting
- interfaces/poorten van actieve apparatuur
Onder logisch -
- logische apparaten (N7K VDC, Palo Alto VSYS, ...)
- VRF-extensie
- Vilans
- subinterfaces
- tunnels
- zone
- ...
Als uw netwerk niet volledig elementair is, zal het uit verschillende segmenten bestaan.
Bij voorbeeld
- datacentrum
- Internet
- WAN
- toegang op afstand
- kantoor-LAN
- DMZ
- ...
Het is verstandig om meerdere diagrammen te hebben die zowel het grote beeld weergeven (hoe het verkeer tussen al deze segmenten stroomt) als een gedetailleerde uitleg van elk afzonderlijk segment.
Omdat er in moderne netwerken veel logische lagen kunnen zijn, is het misschien een goede (maar niet noodzakelijke) aanpak om verschillende circuits voor verschillende lagen te maken. In het geval van een overlay-benadering kunnen dit bijvoorbeeld de volgende circuits zijn:
- bedekking
- L1/L2-ondervloer
- L3-ondervloer
Het belangrijkste diagram, zonder welke het onmogelijk is om het idee van uw ontwerp te begrijpen, is natuurlijk het routeringsdiagram.
Routeringsschema
Dit diagram zou op zijn minst moeten reflecteren
- welke routeringsprotocollen worden gebruikt en waar
- basisinformatie over routeringsprotocolinstellingen (gebied/AS-nummer/router-id/…)
- op welke apparaten vindt herverdeling plaats?
- waar filtering en routeaggregatie plaatsvindt
- standaard route-informatie
Ook is het L2-schema (OSI) vaak nuttig.
L2-schema (OSI)
Dit diagram kan de volgende informatie tonen:
- welke VLAN's
- welke poorten zijn trunkpoorten
- welke poorten zijn samengevoegd in etherkanaal (poortkanaal), virtueel poortkanaal
- welke STP-protocollen worden gebruikt en op welke apparaten
- basis STP-instellingen: root/root-back-up, STP-kosten, poortprioriteit
- aanvullende STP-instellingen: BPDU guard/filter, root guard…
Typische ontwerpfouten
Een voorbeeld van een slechte aanpak bij het opbouwen van een netwerk.
Laten we een eenvoudig voorbeeld nemen van het bouwen van een eenvoudig kantoor-LAN.
Omdat ik ervaring heb met het lesgeven in telecom aan studenten, kan ik zeggen dat vrijwel elke student halverwege het tweede semester over de nodige kennis beschikt (als onderdeel van de cursus die ik gaf) om een eenvoudig kantoor-LAN op te zetten.
Wat is er zo moeilijk aan het met elkaar verbinden van switches, het opzetten van VLAN's, SVI-interfaces (in het geval van L3-switches) en het opzetten van statische routing?
Alles zal werken.
Maar tegelijkertijd zijn er vragen die verband houden met
- veiligheid
- reservering
- netwerk schaalvergroting
- productiviteit
- doorvoer
- betrouwbaarheid
- ...
Van tijd tot tijd hoor ik de uitspraak dat een kantoor-LAN iets heel eenvoudigs is en ik hoor dit meestal van ingenieurs (en managers) die alles behalve netwerken doen, en zij zeggen dit zo zelfverzekerd dat het niet verbaasd hoeft te zijn als het LAN dat wel zal zijn gemaakt door mensen met onvoldoende praktijk en kennis en zal worden gemaakt met ongeveer dezelfde fouten die ik hieronder zal beschrijven.
Veel voorkomende L1 (OSI)-ontwerpfouten
- Als u toch ook verantwoordelijk bent voor SCS, dan is een van de meest onaangename erfenissen die u kunt ontvangen een onzorgvuldige en slecht doordachte overstap.
Ik zou ook fouten van het type L1 classificeren die verband houden met de bronnen van de gebruikte apparatuur, bijvoorbeeld
- onvoldoende bandbreedte
- onvoldoende TCAM op apparatuur (of ineffectief gebruik ervan)
- onvoldoende prestaties (vaak gerelateerd aan firewalls)
Veel voorkomende L2 (OSI)-ontwerpfouten
Als er geen goed begrip is van hoe STP werkt en welke potentiële problemen het met zich meebrengt, worden schakelaars vaak chaotisch aangesloten, met standaardinstellingen, zonder extra STP-afstemming.
Als gevolg hiervan hebben we vaak het volgende
- grote STP-netwerkdiameter, wat kan leiden tot uitzendstormen
- De STP-root wordt willekeurig bepaald (op basis van het Mac-adres) en het verkeerspad zal niet optimaal zijn
- poorten die met hosts zijn verbonden, worden niet geconfigureerd als edge (portfast), wat zal leiden tot herberekening van STP bij het in- en uitschakelen van eindstations
- het netwerk zal niet op L1/L2-niveau worden gesegmenteerd, waardoor problemen met welke switch dan ook (bijvoorbeeld stroomoverbelasting) zullen leiden tot een herberekening van de STP-topologie en het stoppen van verkeer in alle VLAN’s op alle switches (inclusief de één van cruciaal belang vanuit het oogpunt van het continuïteitsdienstensegment)
Voorbeelden van fouten in L3 (OSI)-ontwerp
Een paar typische fouten van beginnende netwerkers:
- Frequent gebruik (of alleen gebruik) van statische routing
- gebruik van suboptimale routeringsprotocollen voor een bepaald ontwerp
- suboptimale logische netwerksegmentatie
- suboptimaal gebruik van adresruimte, waardoor routeaggregatie niet mogelijk is
- geen back-uproutes
- geen reservering voor standaardgateway
- asymmetrische routering bij het opnieuw opbouwen van routes (kan van cruciaal belang zijn in het geval van NAT/PAT, statefull firewalls)
- problemen met MTU
- wanneer routes opnieuw worden opgebouwd, gaat het verkeer door andere beveiligingszones of zelfs door andere firewalls, waardoor dit verkeer wordt verwijderd
- slechte schaalbaarheid van de topologie
Criteria voor het beoordelen van de ontwerpkwaliteit
Als we het hebben over optimaliteit/niet-optimaliteit, moeten we begrijpen vanuit het gezichtspunt van welke criteria we dit kunnen evalueren. Hier zijn, vanuit mijn oogpunt, de belangrijkste (maar niet alle) criteria (en uitleg met betrekking tot routeringsprotocollen):
- schaalbaarheid
U besluit bijvoorbeeld nog een datacenter toe te voegen. Hoe gemakkelijk kun je het doen? - gebruiksgemak (beheersbaarheid)
Hoe gemakkelijk en veilig zijn operationele veranderingen, zoals het aankondigen van een nieuw netwerk of het filteren van routes? - beschikbaarheid
Hoeveel procent van de tijd levert uw systeem het vereiste serviceniveau? - beveiliging
Hoe veilig zijn de verzonden gegevens? - prijs
Veranderingen
Het basisprincipe kan in dit stadium worden uitgedrukt met de formule ‘doe geen schade’.
Ook als u het niet helemaal eens bent met het ontwerp en de gekozen uitvoering (configuratie), is het daarom niet altijd raadzaam om wijzigingen aan te brengen. Een redelijke aanpak is om alle geïdentificeerde problemen te rangschikken op basis van twee parameters:
- hoe gemakkelijk kan dit probleem worden opgelost
- Hoeveel risico loopt zij?
In de eerste plaats is het noodzakelijk om een einde te maken aan wat momenteel het niveau van de geleverde diensten onder het aanvaardbare niveau brengt, bijvoorbeeld problemen die tot pakketverlies leiden. Repareer vervolgens wat het gemakkelijkst en veiligst kan worden opgelost, in afnemende volgorde van de ernst van het risico (van ontwerp- of configuratieproblemen met een hoog risico tot problemen met een laag risico).
Perfectionisme in dit stadium kan schadelijk zijn. Breng het ontwerp in een bevredigende staat en synchroniseer de netwerkconfiguratie dienovereenkomstig.
Bron: www.habr.com