Ruṭera ping kontraŭ VLAN-gastiganto: kiu PBR-politiko validas?

VLAN 10 devus uzi la VPN kaj VLAN 20 la WAN, do la unua testo estas ping de la ruṭero kun la interfaca adreso de VLAN 10 kiel fonto. Ĝi sukcesas, la route-map-kalkuliloj kreskas kaj ĉiuj konkludas, ke la dezajno funkcias. Ĝi ne funkcias. Tiu ping estis generita loke, kaj loke generita trafiko atingas alian politikan aliĝpunkton ol paketo alvenanta ĉe la VLAN-interfaco.

Tri kondiĉoj decidas, kiun politikon vi vere testas: kie la paketo kreiĝas, kie ĝi eniras kaj al kio ĝi kongruas.

Kie la paketo eniras decidas, kiu politiko ruliĝas

Interfaca route-map alligita per ip policy route-map validas por paketoj alvenantaj ĉe tiu interfaco, kiel priskribas la PBR-gvidilo de IOS XE. Gastiganto en VLAN 10 sendas sian peton, la kadro alvenas ĉe la VLAN-subinterfaco kaj la ruṭero taksas la politikon tie. La propra paketo de la ruṭero neniam alvenas ĉe tiu interfaco, ĉar ĝi naskiĝis en la ruṭero.

Elekti la VLAN-adreson kiel fonton ŝanĝas la kaplinion. Ĝi ne ŝanĝas la originon.

Kial la ping kun fonto ankoraŭ ne estas la gastiganto

La fonta adreso gravas por ACL-kongruo, kaj ĝuste tio igas la teston tiel konvinka. La paketo kongruas kun fonta kondiĉo, la kalkuliloj kreskas kaj la eligo aspektas ĝusta. Kion la testo ne povas montri estas la enira interfaco, la alvena kunteksto aŭ ĉu gastiganta paketo prenus la saman branĉon.

Testo, kiu reproduktas la kongruon sed ne la kuntekston, pruvas duonon de la dezajno, kaj kun duona pruvo la dezajnoj elsendiĝas kun la malĝusta politiko.

Kiam loka politiko estas la ĝusta respondo

Cisco dokumentas ip local policy route-map por trafiko, kiun la ruṭero mem generas. Tio estas aparta amplekso, kaj ĝi estas la ĝusta ilo, kiam la postulo vere koncernas la propran trafikon de la ruṭero. Ĝi ne estas mankanta paŝo, kiun bezonas ĉiu VLAN-direktada dezajno. Larĝa kongruo tie ankaŭ povas efiki al administraj kaj subtenaj konektoj, kio estas multe pli granda ŝanĝo ol ĝi aspektas.

Loke generita TCP havas plian antaŭkondiĉon: ĝi bezonas aplikeblan celan enskribon en la enkursiga tabelo eĉ kiam la politiko elektas alian vojon. ICMP-rezulto ne pruvas la saman konduton por TCP.

Kion anstataŭe testi ĉe la gastiganto

Rulu la teston de rajtigita gastiganto en VLAN 10, kun ĝia reala fonta adreso, celo, protokolo kaj pordo. Registru la eniran interfacon kaj la route-map-kongruon apud la rezulto, por ke la pruvo nomu la politikon, kiu ruliĝis. Poste ripetu por gastiganto en VLAN 20 kaj konfirmu, ke ĝi prenas la alian vojon.

Ambaŭ vojoj bezonas funkciantajn next hops, returnan atingeblon kaj, kie aplikeble, VPN-kovradon. PBR elektas plusendan decidon; ĝi ne kreas la malproksiman servon nek donas permeson al la aplikaĵo.

Kion la rezulto povas kaj ne povas pruvi

Sukcesa gastiganta fluo pruvas, ke la politiko kongruis kaj ke la elektita vojo funkciis tiun momenton. Ĝi ne pruvas, ke la propra trafiko de la ruṭero estas direktata, nek ke la aplikaĵo estis rajtigita, ĉar tiuj estas malsamaj demandoj kun malsamaj pruvoj.

Konservu la ping en la registro kiel pruvon pri loka paketo. Poste iru akiri la pruvon de la gastiganta fluo, anstataŭ vastigi la amplekson de la politiko ĝis la du testoj hazarde aspektos samaj.