Problemen oplossen bij OMP-falen en TLOC-Action

Inleiding

Dit document beschrijft scenario's en best practices van Overlay Management Protocol (OMP) voor netwerkveerkracht in Cisco SD-WAN.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van de Cisco Software Defined Wide Area Network (SD-WAN) oplossing.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco IOS Catalyst SD-WAN Manager ook bekend als vManager
• Cisco IOS Catalyst SD-WAN validator ook bekend als vBond
• Cisco IOS Catalyst SD-WAN controller, ook bekend als vSmart
• vEdge-apparaten

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, zorg er dan voor dat u de potentiële impact van een opdracht begrijpt.

OMP - Overzicht

Zoals u weet, deelt het Cisco SD-WAN Edge-apparaat alleen de routes met de Catalyst SD-WAN controller. Voor een route om geldig te zijn en in zijn Forwarding tabel te installeren:

• De volgende hop Transport Locator (TLOC) moet bereikbaar zijn, dat wil zeggen dat het Edge-apparaat een geldige route moet hebben voor de TLOC.
• De TLOC waarop het wijst is actief. Een TLOC kan alleen actief zijn als een actieve Bidirectionele Forwarding (BFD)-sessie aan die TLOC is gekoppeld. BFD-sessies worden ingesteld door elk apparaat dat met elk van de externe TLOC's een afzonderlijke BFD-sessie maakt. Als een BFD-sessie inactief wordt, verwijdert de Cisco Catalyst SD-WAN controller alle OMP-routes die naar die TLOC wijzen uit de tabel met doorsturen.
• De OMP-route moet op de beste manier worden berekend.

Alhoewel al deze verklaringen logisch en ongecompliceerd zijn, is er een aanzienlijk verschil tussen OMP en traditionele routeringsprotocollen zoals Enhanced Interior Gateway Routing Protocol (EIGRP) en Open Shortest Path First (OSPF) tijdens storingsscenario's.

EIGRP-mislukkingsscenario

In het volgende netwerk zijn er drie sites, namelijk Site1, Site3 en Site4, die respectievelijk routers RTR1/RTR2, RTR3 en RTR4 hebben met één WAN-verbinding. Het traditionele routeringsprotocol EIGRP wordt via IPSec uitgevoerd en IP1, IP2, IP3 en IP4 zijn de WAN-interface en IP-adressen op de desbetreffende locaties.

Het netwerk moet worden opgesplitst, met een focus op RTR3 en RTR4 voor nu. Op RTR3, is de route om 10.1.4.0/24 te bereiken via een directe tunnel tussen RTR3-RTR4. Als de tunnel daalt, hoe reageert EIGRP in dit geval? Zodra de tunnel daalt, zal EIGRP in werking stellen en een vraag naar naburige routers voor het 10.1.4.0/24 netwerk verzenden, en gebaseerd op ontvangen antwoorden, onderzoekt het en installeert de nieuwe weg voor de bestemming in de routeringstabel post de beste wegberekening.

Dit is een zeer eenvoudige verklaring van het traditionele proces van de routingprotocolconvergentie. Over het algemeen kunnen traditionele routeringsprotocollen zoals EIGRP netwerkrecompute uitvoeren:

• Wanneer de huidige route naar een bestemming daalt
• Als er geen haalbare opvolgers zijn voor een bestemming
• Wanneer een topologiewijziging optreedt

OMP-foutenscenario

De twee faalscenario's voor OMP worden hier besproken:

1. Directe fout
2. Indirecte fout

Directe fout

In de volgende Topologie zijn er drie sites met een enkele transportverbinding.

Ga ervan uit dat alles op de Catalyst SD-WAN controller standaard is ingesteld. De vEdge-apparaten delen de routeringsinformatie rechtstreeks met de Catalyst SD-WAN controller en de controller deelt deze met alle vEdge-apparaten. De volgende topologie toont de routeringstabel voor alle routers:

Op dit moment zijn alle BFD-sessies actief.

vEdge-DC1# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME          TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls             60.1.1.1                        20.1.1.1                        12346       ipsec  7           1000           0:00:03:12      0
2.2.2.2                 1        up          mpls             mpls             60.1.1.1                        10.10.20.2                    12406       ipsec  7           1000           0:06:28:51      0
4.4.4.4                 2        up          mpls             mpls             60.1.1.1                        30.1.1.1                        12386       ipsec  7           1000           0:00:00:51      0
                    

vEdge-DC1# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
20     10.1.1.0/24        2.2.2.2          43     1005        C,I,R          installed      1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R            installed     2.2.2.2                  mpls                           ipsec  -
20     10.1.3.0/24        0.0.0.0          66     1005     C,Red,R        installed      3.3.3.3                  mpls                           ipsec  -
20     10.1.4.0/24        2.2.2.2          45     1006         C,I,R          installed       4.4.4.4                 mpls                           ipsec  - 

Als de connectiviteit tussen vEdge3 en vEdge4 is uitgeschakeld, worden de BFD-sessies van zowel vEdge3 als vEdge4 ook verlaagd als de tunnel uitvalt. Dit zorgt ervoor dat ze de respectievelijke routes markeren als 'Ongeldig' en 'TLOC Onopgelost'. Dat kun je in de volgende output zien:

vEdge3# show bfd sessions
                                      SOURCE TLOC      REMOTE TLOC                                      DST PUBLIC                      DST PUBLIC         DETECT      TX           
SYSTEM IP        SITE ID  STATE       COLOR            COLOR            SOURCE IP                       IP                              PORT        ENCAP  MULTIPLIER  INTERVAL(msec) UPTIME           
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1                 1        up          mpls             mpls                     60.1.1.1                         20.1.1.1                      12386       ipsec          7                    1000                0:05:57:27                         
2.2.2.2                 1        up          mpls             mpls                     60.1.1.1                         10.10.20.2                  12426       ipsec           7                   1000               0:05:57:27                         
4.4.4.4                 4        down     mpls             mpls                     60.1.1.1                         30.1.1.1                      12406       ipsec          7                    1000                 NA                                     



vEdge3# show omp routes vpn 20 | t
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                            PATH                      ATTRIBUTE
VPN    PREFIX              FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1     10.1.1.0/24          2.2.2.2          43     1005        C,I,R                installed       1.1.1.1                  mpls                           ipsec  -
                                      2.2.2.2          37     1006        C,I,R                installed       2.2.2.2                  mpls                          ipsec  -
1    10.1.3.0/24           0.0.0.0          66     1005        C,Red,R           installed       3.3.3.3                 mpls                           ipsec  -
1     10.1.4.0/24          2.2.2.2          45     1006        Inv,U                installed       4.4.4.4                 mpls                           ipsec  - 

Indirecte fout

Om 'Indirect Failure' te begrijpen, ga ervan uit dat het controlebeleid is gedefinieerd om de volgende hop op vEdge3 voor route 10.1.4.0/24 via vEdge2 te wijzigen, en op vEdge4 wordt de volgende hop voor 10.1.3.0/24 gewijzigd in vEdge1. Met andere woorden, voor verkeer tussen vEdge 3 en vEdge 4 zijn vEdge 2 en vEdge 1 ingevoegd als tussenliggende hop. U kunt dat zien in het volgende diagram:

Als er sprake is van een netwerkstoring die leidt tot het verlies van connectiviteit tussen vEdge2 en vEdge4, terwijl de overlay-tunnel tussen T2-T4 niet meer werkt, heeft vEdge3 nog steeds een geldige route voor 10.1.4.0 via T2. Daarom wordt verkeer naar vEdge2 verzonden. vEdge2 heeft geen geldige Tunnel met vEdge4, dus routes zijn niet meer actief op vEdge2 en laten daarom het verkeer vallen.

Op basis van de eerdere logbestanden en tests kan worden geconcludeerd dat:

• Met OMP is er geen automatische detectie van routing tussen peers en next-hops 
• Er is geen topologie herberekening wanneer een tunnel daalt
• De OMP-routes naar een bestemmingsprefix veranderen nooit als een tunnel instort. De enige verandering die gebeurt is bereikbaarheid naar de volgende hop, dat wil zeggen TLOC.
• In het geval van directe overlay-uitval, moet een tunnelredundantie met Meerdere tunnels naar dezelfde bestemming worden voorzien.
• Bij de invoering van de tussenliggende hop/hop in de overlay-out moet extra zorg worden betracht en moet worden gezorgd voor overtolligheid in de tunnel om te voorkomen dat er te weinig verkeer is.

Dus nu weet je dat OMP standaard niet recomputing of routewijziging uitvoert bij overlay-out. Om dit probleem te overwinnen, kunt u een functie genaamd 'TLOC-Action' inschakelen via een Control Policy.

TLOC-Action

• In Cisco SD-WAN maakt een 'TLOC Action' binnen een controlebeleid het mogelijk om een intermediaire hop (TLOC) in te voegen voor het doorsturen van verkeer, terwijl de zichtbaarheid in het volledige pad van bron naar bestemming behouden blijft. Dit betekent dat het instellen van de TLOC-actieoptie de Cisco Catalyst SD-WAN Controller in staat stelt om end-to-end tracking van het pad naar het uiteindelijke doelapparaat uit te voeren. Als die weg daalt, informeert het controlemechanisme de de randrouters van WAN die deze OMP route ontvingen.
• Het biedt een back-uppad in geval van primaire link-uitval, waardoor de veerkracht van het netwerk en de fouttolerantie binnen het SD-WAN overlay-netwerk worden verbeterd. Het is een manier om te controleren hoe het verkeer door het netwerk wordt geleid door de TLOCs te manipuleren die voor het bereiken van een bestemming worden gebruikt.
• Wanneer een TLOC-actie is gedefinieerd in een beleid, geeft het de SD-WAN controller de opdracht om een TLOC tussentijds in de routeberekening te plaatsen, wat betekent dat het verkeer eerst naar deze gespecificeerde 'back-up'-locatie zal gaan voordat het de eindbestemming indien nodig bereikt.
• Dit is met name handig voor scenario's waarin u de connectiviteit wilt verzekeren, zelfs als een primaire link naar beneden gaat, door automatisch verkeer door een ander pad te leiden (via de gespecificeerde TLOC).

Laten we ons bij de volgende topologie richten op vEdge2, vEdge3 en vEdge4 om deze beter te begrijpen. Op dit moment is er geen beleid gedefinieerd en wordt het dataverkeer voor 10.1.4.0/24 op vEdge3 via een directe tunnel tussen T3 en T4 verplaatst.

Om fouttolerantie en netwerkveerkracht te bieden, is het Control-beleid geconfigureerd om verkeer via een ander pad (via de gespecificeerde TLOC) om te leiden.

• vEdge4 stuurt OMP-update voor het direct aangesloten netwerk 10.1.4.0/24 met next-hop T4 naar Catalyst SD-WAN Controller als '10.1.4.0/24 via T4'.
• Deze route past een controlebeleid aan dat op de SD-WAN controller is geconfigureerd en stelt een nieuwe TLOC en TLOC-Actions in overeenstemming met het beleid dat erop is gedefinieerd, dat wil zeggen, het voegt de nieuwe 'tussenliggende TLOC' in.
• De controller adverteert de OMP-route naar vEdge1 met nu twee next-hops - TLOC (T3, 3.3.3.3) en ultieme TLOC (next-hop-T4 van de originele route). Dit geeft intelligentie aan vEdge1 dat het doelprefix 10.1.4.0/24 bereikbaar is via T2 en T4.

Gebaseerd op de TLOC-Action gedefinieerde vEdge1 voorwaarts het verkeer voor 10.1.4.0/24. Dus u kunt deze vier soorten TLOC-acties definiëren in besturingsplane Beleid:

1. Streng (standaard) - De 'TLOC-Action striction' definieert dat het verkeer tussen vEdge1 en vEdge4 via T3 (tussentijdse hop) moet worden uitgevoerd en dat het verkeer moet worden verbroken als de tunnel tussen vEdge1 en vEdge4 instort.
2. Primair - De 'TLOC-Action Primary' definieert dat het verkeer tussen vEdge1 en vEdge4 door de intermediaire hop T3 (3.3.3.3) gaat en als deze overlay tunnel naar beneden gaat, informeert SD-WAN Controller vEdge1 en verkeer via de directe tunnel naar T4.
3. Back-up - De 'TLOC-Action Backup' definieert dat het verkeer tussen vEdge1 en vEdge4 rechtstreeks naar de ultieme LOC gaat (next-hop -T4 van de originele route) en als de directe overlay tunnel tussen vEdge1 en vEdge4 uitvalt, de SD-WAN Controller informeert vEdge1 en het verkeer gaat via Intermediate hop T3.
4. Equal-Cost Multi-Path (ECMP) - De 'TLOC-Action ECMP' specificeert dat onder normale omstandigheden de communicatie tussen vEdge1 en vEdge4 taakverdeling heeft via de intermediaire hop T3 en de Ultimate-hop T4.