Roeteerder-ping versus VLAN-gasheer: watter PBR-beleid geld?

VLAN 10 moet die VPN gebruik en VLAN 20 die WAN, dus die eerste toets is ’n ping vanaf die roeteerder met VLAN 10 se koppelvlakadres as bron. Dit slaag, die route-map-tellers styg en almal kom tot die gevolgtrekking dat die ontwerp werk. Dit werk nie. Daardie ping is plaaslik gegenereer, en plaaslik gegenereerde verkeer bereik ’n ander beleidsaanhegtingspunt as ’n pakket wat by die VLAN-koppelvlak aankom.

Drie voorwaardes bepaal watter beleid jy werklik toets: waar die pakket geskep word, waar dit inkom en waarmee dit ooreenstem.

Waar die pakket inkom, bepaal watter beleid loop

’n Koppelvlak-route-map wat met ip policy route-map geheg is, geld vir pakkette wat by daardie koppelvlak aankom, soos die IOS XE PBR-gids beskryf. ’n Gasheer in VLAN 10 stuur sy versoek, die raam kom by die VLAN-subkoppelvlak aan en die roeteerder evalueer die beleid daar. Die roeteerder se eie pakket kom nooit by daardie koppelvlak aan nie, want dit is in die roeteerder gebore.

Om die VLAN-adres as bron te kies, verander die opkop. Dit verander nie die oorsprong nie.

Waarom die ping met bron steeds nie die gasheer is nie

Die bronadres maak saak vir ’n ACL-ooreenkoms, en dit is juis wat die toets so oortuigend maak. Die pakket stem ooreen met ’n bronklousule, die tellers styg en die uitset lyk korrek. Wat die toets nie kan wys nie, is die inkomende koppelvlak, die aankomskonteks of of ’n gasheerpakket dieselfde tak sou neem.

’n Toets wat die ooreenkoms maar nie die konteks weergee nie, bewys die helfte van die ontwerp, en dit is met ’n half bewys dat ontwerpe uitgelewer word met die verkeerde beleid geheg.

Wanneer ’n plaaslike beleid die regte antwoord is

Cisco dokumenteer ip local policy route-map vir verkeer wat die roeteerder self genereer. Dit is ’n aparte omvang, en dit is die regte instrument wanneer die vereiste werklik die roeteerder se eie verkeer raak. Dit is nie ’n ontbrekende stap wat elke VLAN-stuurontwerp nodig het nie. Breë ooreenkoms daar kan ook bestuurs- en ondersteuningsverbindings raak, wat ’n veel groter verandering is as wat dit lyk.

Plaaslik gegenereerde TCP het ’n bykomende voorvereiste: dit benodig ’n toepaslike bestemminginskrywing in die routingtabel selfs wanneer die beleid ’n ander pad kies. ’n ICMP-resultaat bewys nie dieselfde gedrag vir TCP nie.

Wat om eerder op die gasheer te toets

Voer die toets uit vanaf ’n gemagtigde gasheer in VLAN 10, met sy werklike bronadres, bestemming, protokol en poort. Teken die inkomende koppelvlak en die route-map-ooreenkoms langs die resultaat aan, sodat die bewyse die beleid noem wat geloop het. Herhaal dit dan vir ’n gasheer in VLAN 20 en bevestig dat dit die ander pad neem.

Beide paaie benodig werkende next hops, terugkeerbereikbaarheid en, waar van toepassing, VPN-dekking. PBR kies ’n aanstuur-besluit; dit skep nie die afgeleë diens nie en gee nie die toepassing toestemming nie.

Wat die resultaat kan en nie kan bewys nie

’n Suksesvolle gasheervloei bewys dat die beleid ooreengestem het en dat die gekose pad op daardie oomblik gewerk het. Dit bewys nie dat die roeteerder se eie verkeer gestuur word nie, en dit bewys nie dat die toepassing gemagtig is nie, want dit is verskillende vrae met verskillende bewyse.

Hou die ping in die rekord as bewyse oor ’n plaaslike pakket. Gaan haal dan die bewyse vir die gasheervloei, eerder as om die beleid se omvang te verbreed tot die twee toetse toevallig eenders lyk.