BGP a învățat prefixul, dar traficul ocolește în continuare tunelul

Gatewayul sucursalei afișează prefixul cloudului în tabela sa BGP, sesiunea cu furnizorul este stabilită, și totuși cererea unui utilizator către acel prefix iese prin interfața greșită. Nimic nu este stricat așa cum sugerează monitorizarea, pentru că „BGP l-a învățat” este o afirmație despre planul de control. Între acea tabelă și pachet se află patru tranziții separate, iar fluxul se oprește exact la una dintre ele. Parcurgeți porțile în ordine și opriți-vă la prima care eșuează.

Prima poartă: ce a trimis de fapt vecinul

Începeți cu prefixul așa cum a fost primit, nu rezumat. Căutați rețeaua și masca exacte în tabela BGP și notați următorul salt, calea AS și orice comunitate pe care o politică de import ar putea-o potrivi. O rută rezumată într-un panou poate ascunde faptul că prefixul concret nu a fost niciodată acceptat.

Politica de import este locul obișnuit unde o rută dispare fără eroare. O listă de prefixe, un filtru de comunități sau o hartă de rute de intrare pot elimina actualizarea în timp ce sesiunea rămâne sus și sănătoasă, și de aceea un bec verde de vecin dovedește atât de puțin. Absența unei linii de log nu înseamnă absența unei decizii. De obicei înseamnă că decizia a fost luată în tăcere, exact cum este configurat.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Citiți ieșirea în acea ordine. Primele două comenzi spun dacă informația a ajuns și ce afirmă partenerul că a trimis; ultimele două spun dacă ceva a ajuns în tabelele de rutare și de forwardare. Un prefix prezent în prima comandă și absent în a treia este o problemă de selecție sau de instalare, nu de conectivitate.

A doua poartă: selecție, apoi instalare

BGP alege cea mai bună cale, iar calea aleasă nu este instalată automat. Următorul salt trebuie rezolvat, iar o altă sursă de rute poate deja deține prefixul cu o distanță administrativă mai bună. O rută statică rămasă de la migrare va învinge ușor o cale BGP validă și va trimite traficul în altă parte.

RFC 4271 ține trei idei separate: ce a trimis un partener, ce a ales acest vorbitor ca fiind cel mai bun și ce va anunța mai departe. Acestea sunt roluri conceptuale, nu trei baze de date fizice pe care un furnizor trebuie să le expună, dar exact această separare face din „este în BGP” un răspuns incomplet.

Verificați și ce context de rutare citiți. O rută instalată într-o VRF căreia nu îi aparține interfața utilizatorului este invizibilă pentru pachetele acelui utilizator, iar tabela pare corectă tot timpul.

A treia poartă: căutarea care se aplică acestui flux

Acum opriți-vă din întrebat despre rută și începeți să întrebați despre pachet. Notați adresa sursă a utilizatorului, destinația, protocolul, portul și interfața de intrare, pentru că fiecare dintre ele poate selecta o politică diferită. Apoi priviți căutarea care se aplică acelei combinații în locul tabelei generale de rutare.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Un prefix mai specific este surpriza cea mai frecventă aici, iar o rută de politică este a doua. Ambele suprascriu agregatul la care vă uitati, și niciuna nu este vizibilă într-un rezumat al tabelei BGP.

Un ping trimis chiar de pe gateway nu este o dovadă despre sesiunea unui utilizator. Altă adresă sursă, altă cale de politică și adesea alt rezultat. Testați cu aceeași sursă pe care o folosește aplicația, sau acceptați că testul răspunde la altă întrebare.

A patra poartă: jumătatea îndepărtată a căii

Dacă interogarea locală selectează într-adevăr tunelul, pachetul trebuie totuși acceptat de politica de protecție, permis de regula de forwardare și primit un răspuns de la ceva de cealaltă parte. Un ACL cripto care nu include perechea de adrese va arunca traficul în timp ce tunelul se raportează sus, ceea ce produce un timeout imposibil de distins de o defecțiune de rutare.

Calea de întoarcere contează la fel de mult ca cea de ieșire. Partea cloud trebuie să știe cum să ajungă la sursa sucursalei, fie printr-o rută, fie printr-o traducere configurată deliberat. Căile de întoarcere asimetrice sunt frecvente în proiectele testate doar dintr-o direcție.

Corelați o conexiune autorizată proaspătă cu trei observații: politica locală care s-a potrivit, contoarele tunelului care s-au mișcat și recepția de partea îndepărtată acolo unde este vizibilă. Dacă contoarele nu se mișcă, pachetul nu a intrat niciodată în tunel, orice ar spune tabela de rute. Dacă se mișcă și nimic nu ajunge, partea îndepărtată îl elimină sau îl rutează greșit. Aceste două rezultate duc la echipe complet diferite.

Numiți tranziția care a eșuat

Scrieți rezultatul ca una dintre cinci stări: neprimit, neacceptat de politică, neselectat, neinstalat sau nepotrivit de acest flux. Adăugați o a șasea pentru cazul în care calea locală este corectă și capătul îndepărtat nu poate răspunde. Acea propoziție este livrabilul și este mult mai utilă decât o captură de ecran cu un vecin stabilit.

Păstrați și un test negativ în planul de acceptare: o destinație care nu trebuie să traverseze tunelul, verificată după modificare. O listă de verificare care dovedește doar calea fericită nu va prinde regula largă de politică pe care cineva o adaugă în următoarea fereastră de mentenanță.