Welkom bij The Perfect Storm!
In deze serie kijken we naar de Niet zo voor de hand liggend scenario's waarbij de "juiste" combinatie van "verkeerde" dingen is gebeurd, en het resultaat leidt tot verlies van bereikbaarheid, connectiviteit, enz. Nadat we de storing hebben besproken, gaan we terug en bepalen wat er is gebeurd (Waarom is het mislukt?). We zullen ook kijken hoe de storing kan worden voorkomen of geminimaliseerd met behulp van NetBrain.
Laten we beginnen!!
In dit scenario ontdekken we dat een deel van het netwerk niet kan communiceren met een cloudgebaseerde bron tijdens acceptatietesten.
Dit is de netwerkomgeving waarmee we werken:
Afbeelding 1: Datacenterconnectiviteit met AWS Cloud
RT1 en RT2 peeren elk via BGP in een AWS-omgeving en hebben elk een andere fysiek weg naar AWS. Deze twee routers hebben een iBGP-relatie met elkaar over het 172.16.110.0-netwerk. Bovendien draaien RT1 en RT2 OSPF op twee afzonderlijke netwerken: het 172.16.110.0-netwerk en op het 10.70.28.0-netwerk. Verkeer op het 10.70.28.0-netwerk (van RT1 en RT2) passeert een firewall om bij een derde OSPF-buurman, RT3, te komen, die de Layer-3-routering/-verkeer voor datacenter-subnetten afhandelt.
De afgelopen twee avonden om 11 uur voert een netwerkbeheerstation op het 10.17.1.0-netwerk prestatietests uit naar een AWS-host in het 10.192.16.0-netwerk. De tests duren normaal gesproken 10-15 minuten. Op de derde en laatste nacht van testen worden de tests uitgesteld tot @2am, in het midden van het onderhoudsvenster van de AWS Circuit-provider (waar onderhoud wordt uitgevoerd op Fysiek pad A). Hoewel er geen connectiviteitsproblemen werden gemeld door een van de hosts in het datacenter, mislukten de prestatietests die vanaf het netwerkbeheerstation werden uitgevoerd. Waarom is het mislukt?
PROBLEMEN OPLOSSEN METHODOLOGIE
Laten we de omgeving eens nader bekijken, kijken wat er is veranderd en bepalen hoe die veranderingen de omgeving hebben beïnvloed. Wat gebeurde er tijdens de eerste en tweede testnacht? Laten we kijken:
Kijk NU specifiek naar wat er gebeurde op de Derde Nacht!! Ten eerste kunnen we beginnen met het identificeren van wat we weten: de primaire ISP-verbinding is verbroken.
Afbeelding 2: het probleem laten zien, dwz de primaire verbinding van de ISP uitschakelen
Laten we het vervolgens hebben over hoe de breuk in het circuit de routeringstabellen beïnvloedde... specifiek op RT1. Voorafgaand aan het ISP-onderhoudsvenster had RT1 een eBGP-route in de tabel van de eBGP-peer van VPC F.
RT1#scheepsroute 10.192.16.0
Routeringsinvoer voor 10.192.16.0/24
Bekend via “bgp 65535”, afstand 20, metrisch 0
Tag 7224, type extern
Herdistribueren via ospf 1
Geadverteerd door ospf 1 subnetten routekaart DENY-SUMM
Laatste update van 192.168.8.6 00:04:10 geleden
Routeringsbeschrijvingsblokken:
* 192.168.8.6, van 192.168.8.6, 00:04:10 geleden
Routemetriek is 0, aantal verkeersaandelen is 1
AS Hop 1
Routelabel 7224
MPLS-label: geen
RT1#
Na de stroomonderbreking ziet de routeringstabel van RT1 er echter heel anders uit. RT1s tafel heeft nu twee vermeldingen voor het 10.192.16.0-netwerk, één richting RT2 op zijn GigabitEthernet 0/3-interface en een andere richting RT2 op zijn GigabitEthernet 0/1-interface.
RT1#scheepsroute 10.192.16.0
Routeringsinvoer voor 10.192.16.0/24
Bekend via "ospf 1", afstand 110, metrisch 400
Tag 7224, type extern 2, voorwaartse metriek 1
Herdistribueren via bgp 65535
Laatste update van 10.170.28.12 op GigabitEthernet0/1, 00:00:37 geleden
Routeringsbeschrijvingsblokken:
* 172.16.110.12, van 10.70.28.12, 00:00:41 geleden, via GigabitEthernet0/3
Routemetriek is 400, aantal verkeersaandelen is 1
Routelabel 7224
10.70.28.12, van 10.70.28.12, 00:00:37 geleden, via GigabitEthernet0/1
Routemetriek is 400, aantal verkeersaandelen is 1
Routelabel 7224
VIRL-PHX-AWS-RT1#
Maar hoe zou dit een storing kunnen veroorzaken? Hoe zou een extra geldig route ervoor zorgen dat de verbinding van het beheerstation met VPC F mislukt? Om dit te begrijpen, moet u kijken hoe het verkeer tussen VPC F en het Management-subnet stroomt. Inkomend verkeer stroomt van VPC F naar R2 (het enige beschikbare pad) en vervolgens naar het beheersubnet.
Figuur 3: Inzicht in de inkomende verkeersstromen
Uitgaand verkeer neemt een andere weg. Dit uitgaande pad wordt aanvankelijk bepaald door het actieve HSRP-lid voor het 10.17.1.0-subnet. Hij staat nog steeds op RT1. Hoewel verkeer nu uitgaand via RT2 stroomt, blijft RT1 de actieve router (standaardgateway) voor het 10.17.1.0-subnet. Volg met dit in gedachten de onderstaande uitgaande stroom:
Figuur 4: Inzicht in de uitgaande verkeersstromen
We kunnen zien dat het eerste pad naar de standaardgateway gaat (weergegeven door RT1), maar die zijn er twee gelijke hops vertegenwoordigd op het tweede pad! Eén naar RT2 via het 172.16.110.0-netwerk en één naar RT2 via het 10.70.28.0-netwerk. Met twee gelijke Layer3-routes naar RT2 beschikbaar is, zal RT1 de belasting verdelen en een deel van het verkeer over het Firewall-pad (2B) sturen. De firewall ziet een onvolledig gesprek en roept "Asymmetrische routering" en verbreekt het.
ROOT OORZAAK ANALYSE
Nu we een beter begrip hebben van wat er is gebeurd, is het misschien een goed moment om jezelf af te vragen:Hoe had ik dit kunnen zien aankomen?" Welke vragen moet ik mezelf stellen om me beter voor te bereiden op dit soort situaties, en welke tools zullen meer inzicht geven in mijn netwerkinfrastructuur-onderlaag/-overlay? Hoe word ik een betere “netwerk probleemoplosser' en niet alleen een 'shooter'?
In het bovenstaande voorbeeld werd het probleem geïdentificeerd toen we het in kaart brachten traffic path. Hieronder gebruikte ik NetBrain grafisch weergeven a traffic path door de routers te vragen hoe ze van de bron (in dit geval gebruikte ik RT1...) naar de bestemming kunnen komen:
Afbeelding 5: Maak de traffic path gebruik NetBrain
hieronder NetBrain presenteert ons de werkelijke pre/post-onderhoudsgegevens uit RT1s-routingtabellen, die de daadwerkelijke "besluitvormings"-gegevens voor de traffic paths die we hierboven hebben bekeken.
Afbeelding 6: De routeringstabel van router 1 die is gebruikt om de traffic paths
En tot slot zien we (door gebruik te maken van NetBrain om de BGP-buurstatussen voor en na het onderhoud van RT1 te vergelijken) BGP een Peer-status die de oorzaak is van alle gebeurtenissen in dit scenario... Inactief (of andere niet-gevestigde staten) versus gevestigde staten tussen RT1's BGP-buurlanden.
Afbeelding 7: Vergelijking van de "voor" en "na" configuraties
gebruik NetBrain met VIRL op Pakket is een onverslaanbare combinatie voor het simuleren en bewaken/opnemen van netwerkprestaties en -kenmerken in realtime, met behulp van echte "productie-achtige" buildouts, op een manier die gemakkelijk kan worden gedocumenteerd en overgedragen (configuraties, monitoring, enz.) naar een productieomgeving.
Om meer te leren over NetBrain, bezoek https://www.netbraintech.com/platform/