Ping z routeru versus hostitel VLAN: která politika PBR platí?
Ping odeslaný routerem není paket od hostitele VLAN, ani když je jako zdroj použitá adresa tohoto rozhraní. Otestujte tok hostitele, než rozšíříte rozsah politiky.
VLAN 10 by měla používat VPN a VLAN 20 WAN, takže prvním testem je ping z routeru se zdrojovou adresou rozhraní VLAN 10. Vyhoví, počítadla route-map rostou a všichni usoudí, že návrh funguje. Nefunguje. Tento ping byl vygenerován lokálně a lokálně generovaný provoz dorazí k jinému bodu připojení politiky než paket přicházející na rozhraní VLAN.
Tři podmínky rozhodují, kterou politiku skutečně testujete: kde paket vzniká, kde vstupuje a čemu odpovídá.
Místo vstupu paketu rozhoduje, která politika se spustí
Route-map rozhraní připojená pomocí ip policy route-map platí pro pakety přicházející na toto rozhraní, jak popisuje průvodce PBR pro IOS XE. Hostitel ve VLAN 10 odešle svůj požadavek, rámec dorazí na podrozhraní VLAN a router tam politiku vyhodnotí. Vlastní paket routeru na toto rozhraní nikdy nedorazí, protože vznikl v routeru.
Volba adresy VLAN jako zdroje mění hlavičku. Nemění původ.
Proč ping se zdrojem stále není hostitel
Zdrojová adresa je důležitá pro shodu ACL, a právě proto je test tak přesvědčivý. Paket odpovídá klauzuli zdroje, počítadla rostou a výstup vypadá správně. Test nemůže ukázat vstupní rozhraní, kontext příchodu ani to, zda by paket hostitele zvolil stejnou větev.
Test, který reprodukuje shodu, ale ne kontext, dokazuje polovinu návrhu, a právě s polovičním důkazem se návrhy dostávají do provozu se špatnou politikou.
Kdy je lokální politika správnou odpovědí
Cisco dokumentuje ip local policy route-map pro provoz, který router sám generuje. To je samostatný rozsah a správný nástroj, když se požadavek skutečně týká provozu samotného routeru. Není to chybějící krok, který by potřeboval každý návrh řízení VLAN. Široká shoda tam může ovlivnit také správu a podpůrná připojení, což je mnohem větší změna, než se zdá.
Lokálně generovaný TCP má další předpoklad: potřebuje použitelnou položku cíle ve směrovací tabulce, i když politika volí jinou cestu. Výsledek ICMP nedokazuje stejné chování pro TCP.
Co místo toho otestovat na hostiteli
Spusťte test z autorizovaného hostitele ve VLAN 10 s jeho skutečnou zdrojovou adresou, cílem, protokolem a portem. Zaznamenejte vstupní rozhraní a shodu route-map vedle výsledku, aby důkaz pojmenoval politiku, která běžela. Poté postup opakujte pro hostitele ve VLAN 20 a ověřte, že volí druhou cestu.
Obě cesty potřebují funkční next hop, zpětnou dostupnost a případně pokrytí VPN. PBR volí rozhodnutí o předávání; nevytváří vzdálenou službu ani neuděluje aplikaci oprávnění.
Co výsledek může a nemůže dokázat
Úspěšný tok hostitele dokazuje, že politika odpovídala a že zvolená cesta v danou chvíli fungovala. Nedokazuje, že je provoz samotného routeru směrován, ani že aplikace byla autorizována, protože to jsou jiné otázky s jinými důkazy.
Zachovejte ping v záznamu jako důkaz o lokálním paketu. Poté jděte získat důkaz toku hostitele, místo abyste rozšiřovali rozsah politiky, dokud dva testy nezačnou vypadat stejně.