Ping de pe router sau gazdă VLAN: ce politică PBR se aplică?

VLAN 10 ar trebui să folosească VPN-ul, iar VLAN 20 WAN-ul, așa că primul test este un ping de pe router cu adresa interfeței VLAN 10 ca sursă. Reușește, contoarele route-map cresc și toată lumea concluzionează că proiectul funcționează. Nu funcționează. Acel ping a fost generat local, iar traficul generat local ajunge la un punct de atașare a politicii diferit de un pachet care sosește pe interfața VLAN.

Trei condiții decid ce politică testezi de fapt: unde este creat pachetul, unde intră și cu ce se potrivește.

Locul unde intră pachetul decide ce politică rulează

Un route-map de interfață atașat cu ip policy route-map se aplică pachetelor care sosesc pe acea interfață, așa cum descrie ghidul PBR pentru IOS XE. O gazdă din VLAN 10 își trimite cererea, cadrul sosește pe subinterfața VLAN, iar routerul evaluează politica acolo. Pachetul propriu al routerului nu sosește niciodată pe acea interfață, pentru că s-a născut în router.

Alegerea adresei VLAN ca sursă schimbă antetul. Nu schimbă originea.

De ce pingul cu sursă nu este încă gazda

Adresa sursă contează pentru o potrivire ACL, și exact asta face testul atât de convingător. Pachetul se potrivește cu o clauză de sursă, contoarele cresc și rezultatul arată corect. Ce nu poate arăta testul este interfața de intrare, contextul sosirii sau dacă un pachet al gazdei ar lua aceeași ramură.

Un test care reproduce potrivirea, dar nu contextul, dovedește jumătate din proiect, iar cu o jumătate de dovadă ajung proiectele în producție cu politica greșită atașată.

Când o politică locală este răspunsul corect

Cisco documentează ip local policy route-map pentru traficul pe care routerul îl generează singur. Aceasta este o sferă separată și este instrumentul corect atunci când cerința privește într-adevăr traficul propriu al routerului. Nu este un pas lipsă de care să aibă nevoie fiecare proiect de direcționare VLAN. O potrivire largă acolo poate afecta și conexiunile de management și de suport, ceea ce este o schimbare mult mai mare decât pare.

TCP generat local are o condiție prealabilă suplimentară: are nevoie de o intrare de destinație aplicabilă în tabela de rutare chiar și atunci când politica selectează o altă cale. Un rezultat ICMP nu dovedește același comportament pentru TCP.

Ce să testezi pe gazdă în schimb

Rulează testul de pe o gazdă autorizată din VLAN 10, cu adresa sa reală de sursă, destinație, protocol și port. Înregistrează interfața de intrare și potrivirea route-map lângă rezultat, astfel încât dovada să numească politica ce a rulat. Apoi repetă pentru o gazdă din VLAN 20 și confirmă că ia cealaltă cale.

Ambele căi au nevoie de next hop-uri funcționale, accesibilitate de retur și, unde este cazul, acoperire VPN. PBR alege o decizie de forwarding; nu creează serviciul la distanță și nu acordă permisiunea aplicației.

Ce poate și ce nu poate dovedi rezultatul

Un flux de gazdă reușit dovedește că politica s-a potrivit și că calea aleasă a funcționat în acel moment. Nu dovedește că traficul propriu al routerului este direcționat și nu dovedește că aplicația era autorizată, pentru că sunt întrebări diferite cu dovezi diferite.

Păstrează pingul în registru ca dovadă despre un pachet local. Apoi du-te și obține dovada fluxului gazdei, în loc să lărgești sfera politicii până când cele două teste ajung să semene.