Ruter-ping kontra VLAN-vert: kva PBR-policy gjeld?
Ein ping som rutaren sender, er ikkje ein pakke frå ein VLAN-vert, sjølv med det grensesnittet som kjelde. Test flyten til verten før du utvidar omfanget til policyen.
VLAN 10 skal bruke VPN, og VLAN 20 skal bruke WAN, så den første testen er ein ping frå rutaren med grensesnittadressa til VLAN 10 som kjelde. Han lukkast, route-map-teljarane aukar, og alle konkluderer med at designet verkar. Det gjer det ikkje. Den ping-en vart generert lokalt, og lokalt generert trafikk når eit anna policy-tilknytingspunkt enn ein pakke som kjem inn på VLAN-grensesnittet.
Tre vilkår avgjer kva policy du eigentleg testar: kvar pakken vert oppretta, kvar han kjem inn, og kva han matcher.
Kvar pakken kjem inn, avgjer kva policy som køyrer
Ein grensesnitt-route-map som er tilknytt med ip policy route-map, gjeld for pakkar som kjem inn på det grensesnittet, slik IOS XE PBR-rettleiinga skildrar. Ein vert i VLAN 10 sender førespurnaden sin, ramma kjem inn på VLAN-undergrensesnittet, og rutaren vurderer policyen der. Den eigne pakken til rutaren kjem aldri inn på det grensesnittet, fordi han vart fødd i rutaren.
Å velje VLAN-adressa som kjelde endrar headeren. Det endrar ikkje opphavet.
Kvifor ping-en med kjelde framleis ikkje er verten
Kjeldeadressa har noko å seie for ein ACL-match, og det er nettopp det som gjer testen så overtydande. Pakken matchar ein kjeldeklausul, teljarane aukar, og utdata ser riktige ut. Det testen ikkje kan vise, er inngangsgrensesnittet, ankomstkonteksten eller om ein vertspakke ville ta same greina.
Ein test som attskapar matchen men ikkje konteksten, beviser halve designet, og med eit halvt bevis er det slik design går live med feil policy tilknytt.
Når ein lokal policy er det rette svaret
Cisco dokumenterer ip local policy route-map for trafikk som rutaren genererer sjølv. Det er eit separat omfang, og det er rett verktøy når kravet verkeleg gjeld den eigne trafikken til rutaren. Det er ikkje eit manglande trinn som kvar VLAN-styringsdesign treng. Brei matching der kan også påverke administrasjons- og støttetilkoplingar, noko som er ei mykje større endring enn det ser ut som.
Lokalt generert TCP har ein ekstra føresetnad: det treng ein brukande destinasjonsoppføring i rutetabellen sjølv når policyen vel ein annan veg. Eit ICMP-resultat beviser ikkje same åtferd for TCP.
Kva du i staden bør teste på verten
Køyr testen frå ein autorisert vert i VLAN 10, med den verkelege kjeldeadressa, destinasjonen, protokollen og porten hans. Registrer inngangsgrensesnittet og route-map-matchen saman med resultatet, slik at beviset namngjev policyen som køyrde. Gjenta deretter for ein vert i VLAN 20, og stadfest at han tar den andre vegen.
Begge vegane treng fungerande next hops, returbarheit og, der det er relevant, VPN-dekning. PBR vel eit vidaresendingsvedtak; det opprettar ikkje fjertenesta og gir ikkje applikasjonen løyve.
Kva resultatet kan og ikkje kan bevisa
Ein vellukka vertsflyt beviser at policyen matcha, og at den valde vegen verka i det augneblinken. Det beviser ikkje at den eigne trafikken til rutaren vert styrt, og det beviser ikkje at applikasjonen var autorisert, fordi det er ulike spørsmål med ulike bevis.
Behald ping-en i journalen som bevis om ein lokal pakke. Gå deretter og hent beviset for vertsfløyten, i staden for å utvide omfanget til policyen til dei to testane tilfeldigvis ser like ut.