Reitittimen ping vai VLAN-isäntä: mikä PBR-käytäntö pätee?

VLAN 10:n pitäisi käyttää VPN:ää ja VLAN 20:n WAN:ia, joten ensimmäinen testi on ping reitittimeltä VLAN 10:n liitäntäosoite lähteenä. Se onnistuu, route-map-laskurit kasvavat ja kaikki päättelevät, että suunnittelu toimii. Se ei toimi. Ping luotiin paikallisesti, ja paikallisesti luotu liikenne saavuttaa eri käytännön liityntäpisteen kuin VLAN-liitännälle saapuva paketti.

Kolme ehtoa ratkaisee, mitä käytäntöä todella testaat: missä paketti syntyy, mihin se saapuu ja mitä se vastaa.

Paketin saapumiskohta ratkaisee, mikä käytäntö suoritetaan

Liitännän route-map, joka on liitetty komennolla ip policy route-map, koskee kyseiselle liitännälle saapuvia paketteja, kuten IOS XE PBR -opas kuvaa. VLAN 10:n isäntä lähettää pyyntönsä, kehys saapuu VLAN-aliliitännälle ja reititin arvioi käytännön siellä. Reitittimen oma paketti ei koskaan saavu tuolle liitännälle, koska se syntyi reitittimessä.

VLAN-osoitteen valitseminen lähteeksi muuttaa otsaketta. Se ei muuta alkuperää.

Miksi lähteellinen ping ei vieläkään ole isäntä

Lähdeosoite on tärkeä ACL-vastineelle, ja juuri se tekee testistä niin vakuuttavan. Paketti vastaa lähde-ehtoa, laskurit kasvavat ja tuloste näyttää oikealta. Testi ei voi näyttää saapumisliitäntää, saapumiskontekstia tai sitä, valitsisiko isännän paketti saman haaran.

Testi, joka toistaa vastineen mutta ei kontekstia, todistaa puolet suunnittelusta, ja juuri puolikkaalla todisteella suunnitelmat lähtevät tuotantoon väärällä käytännöllä.

Milloin paikallinen käytäntö on oikea vastaus

Cisco dokumentoi ip local policy route-map-komennon liikenteelle, jonka reititin itse tuottaa. Se on erillinen laajuus ja oikea työkalu, kun vaatimus todella koskee reitittimen omaa liikennettä. Se ei ole puuttuva vaihe, jonka jokainen VLAN-ohjauksen suunnittelu tarvitsee. Laaja vastine voi siellä vaikuttaa myös hallinta- ja tukiyhteyksiin, mikä on paljon suurempi muutos kuin miltä näyttää.

Paikallisesti luodulla TCP:llä on lisäedellytys: se tarvitsee soveltuvan kohdemerkinnän reititystaulussa, vaikka käytäntö valitsisi toisen polun. ICMP-tulos ei todista samaa käyttäytymistä TCP:lle.

Mitä sen sijaan testata isännällä

Suorita testi valtuutetulta VLAN 10:n isännältä sen todellisella lähdeosoitteella, kohteella, protokollalla ja portilla. Kirjaa saapumisliitäntä ja route-map-vastine tuloksen viereen, jotta todiste nimeää suoritetun käytännön. Toista sitten VLAN 20:n isännälle ja vahvista, että se valitsee toisen polun.

Molemmat polut tarvitsevat toimivat next hopit, paluusaavutettavuuden ja tarvittaessa VPN-kattavuuden. PBR valitsee välityspäätöksen; se ei luo etäpalvelua eikä anna sovellukselle lupaa.

Mitä tulos voi ja mitä ei voi todistaa

Onnistunut isännän kulku todistaa, että käytäntö vastasi ja valittu polku toimi sillä hetkellä. Se ei todista, että reitittimen oma liikenne ohjataan, eikä sitä, että sovellus oli valtuutettu, koska ne ovat eri kysymyksiä eri todisteilla.

Säilytä ping tiedostossa todisteena paikallisesta paketista. Hae sitten isännän kulun todiste, sen sijaan että laajennat käytännön laajuutta, kunnes kaksi testiä sattuvat näyttämään samanlaisilta.