Metrica maximă OSPF: descurajarea tranzitului prin sucursală fără a o elimina

Două birouri se conectează printr-o sucursală care ar trebui să transporte propriul trafic și foarte puțin altceva. Sucursala are nevoie de rute către ambele locații, iar niciuna dintre cele două locații nu ar trebui să o prefere ca drum între ele. Eliminarea sucursalei din topologie ar rezolva problema tranzitului și ar încălca cerința, pentru că sucursala tot trebuie să ajungă la ambele locații, iar ambele locații tot trebuie să ajungă la sucursală.

Ceea ce doriți este o preferință, exprimată în protocolul de rutare, care lasă sucursala complet accesibilă și o face o alegere slabă pentru tot ce trece prin ea. Parcurgeți problema în ordinea în care routerele o văd.

Începeți cu calea pe care doriți să o evitați

Desenați topologia așa cum o vede protocolul, nu așa cum o vede diagrama. Ce interfețe formează adiacențe, care sunt în aceeași zonă și care dintre acele adiacențe ar transporta trafic între cele două birouri dacă sucursala ar fi preferată? Sunt trei întrebări separate, iar o diagramă nu răspunde în mod fiabil la niciuna dintre ele.

Apoi găsiți calea alternativă. Dacă singura rută între birouri trece prin sucursală, nicio metrică nu poate muta traficul de acolo, pentru că traficul nu are unde să meargă. Redundanța nu este un detaliu al acestui proiect; este condiția prealabilă. O a doua cale care există doar pe hârtie nu se pune.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Aceste trei vederi răspund la întrebări diferite: cine este adiacent, ce interfețe participă și cu ce cost, și ce cale selectează dispozitivul în acest moment. O desfășurare cu tunel adaugă una a patra: o linie pe o diagramă nu este dovada că adiacența s-a format prin ea, iar o adiacență formată nu este dovada că forwardingul urmează aceeași cale. În proiectele cu tunel această diferență apare cel mai des.

Ce anunță metrica maximă

RFC 6987 descrie un router care anunță legăturile sale non-stub cu metrica maximă de legătură, definită ca 0xffff. Routerul continuă să se descrie pe sine și legăturile sale; doar le stabilește prețul la capătul superior al intervalului, astfel încât fiecare alt router calculează un drum prin el ca fiind scump.

Aceasta este o modificare a router-LSA, nu o eliminare a topologiei. Distincția contează: golirea router-LSA retrage informația de topologie în sine, ceea ce poate retrage și relațiile necesare pentru a ajunge la router și la prefixele din spatele lui. Păstrarea anunțului și creșterea prețului său păstrează acele relații. Aceasta este toată diferența dintre această tehnică și eliminare.

Mecanismul RFC 6987 nu are nicio legătură nici cu tipurile de zonă, nici cu alegerea routerului desemnat. O zonă stub blochează o categorie de anunțuri de stare a legăturii la o frontieră de zonă, iar un router stub își stabilește prețul propriilor legături. Cuvinte similare, mașinărie fără legătură.

De ce accesibilitatea supraviețuiește iar tranzitul nu

Celelalte routere au în continuare o rută către prefixele conectate ale sucursalei, pentru că sucursala le anunță în continuare și legăturile există în continuare. Ceea ce se schimbă este costul total al oricărei căi care trece prin sucursală în drum spre altundeva. Prefixele nu se mută; se schimbă doar prețul traversării routerului.

Pentru traficul a cărui sursă sau destinație este sucursala însăși, legătura scumpă este în continuare pe singura cale rezonabilă, deci este folosită. Pentru traficul între cele două birouri, calea alternativă câștigă acum la cost, iar sucursala iese din decizia de forwarding fără a dispărea din topologie. Două direcții, două răspunsuri diferite, și ambele sunt mecanismul care funcționează.

Acesta este comportamentul de verificat în loc de presupus. Uitați-vă la router-LSA generat de sucursală, apoi la calea pe care alt router o selectează pentru o destinație din spatele sucursalei și pentru o destinație din celălalt birou. Cele două răspunsuri ar trebui să difere, iar dacă nu diferă, modificarea de metrică nu ajunge la decizia la care vă gândiți.

Problema ultimei căi

Același RFC este explicit că tehnica nu interzice utilizarea. Când calea alternativă eșuează, routerele revin la calea scumpă prin sucursală, pentru că este în continuare o cale validă și protocolul preferă o rută costisitoare în locul niciunei rute.

Dacă această revenire este acceptabilă este o întrebare de politică la care trebuie să răspundeți înainte de implementare. O sucursală pe un uplink mic care transportă brusc trafic între birouri poate fi mai rea decât o întrerupere și poate fi exact ceea ce doriți într-o fereastră de mentenanță. Ambele răspunsuri sunt legitime; tăcerea nu.

Dacă cerința este o interdicție strictă și nu o preferință, proiectarea metricii singură nu o va produce. Aveți nevoie de aplicarea forwardingului care corespunde intenției, plus un comportament definit pentru cazul în care traficul ajunge oricum. Anunțarea unei căi ca utilizabile și apoi aruncarea traficului creează o gaură neagră mai greu de diagnosticat decât o buclă de rutare.

Pentru OSPFv3, RFC discută bitul R ca o altă modalitate de a exclude participarea la tranzit. Nu presupuneți că moștenește același comportament al ultimei căi ca tehnica metricii maxime și nu copiați setări între cele două familii de adrese ca și cum ar fi aceeași funcție.

Dovediți-o în condiții normale și de defect

Testați de două ori: o dată cu ambele căi disponibile și o dată cu calea preferată eliminată. Primul test arată preferința funcționând, iar al doilea arată ce face rețeaua atunci când preferința nu poate fi respectată. Sărirea celui de-al doilea test lasă jumătatea importantă neexaminată.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Vederea bazei de date arată metrica anunțată, căutarea rutei arată următorul salt selectat, iar urmărirea arată unde au mers de fapt pachetele. Când aceste trei coincid, aveți un proiect verificat și nu o configurație care pare corectă.

Apoi restabiliți calea preferată și confirmați că sucursala revine la a transporta doar propriul trafic. Pasul de restabilire aparține testului, nu curățării, pentru că un proiect care funcționează doar până la următoarea modificare nu este un proiect. Notați ambele rezultate, inclusiv revenirea, pentru că al doilea este răspunsul de care cineva va avea nevoie la trei dimineața.