A VLAN 10 deve usar a VPN e a VLAN 20 a WAN, por isso o primeiro teste é um ping do router com o endereço de interface da VLAN 10 como origem. Passa, os contadores do route-map aumentam e todos concluem que o desenho funciona. Não funciona. Esse ping foi gerado localmente, e o tráfego gerado localmente chega a um ponto de ligação da política diferente de um pacote que chega à interface VLAN.

Três condições decidem qual política está realmente a testar: onde o pacote é criado, onde entra e com o que corresponde.

O local onde o pacote entra decide qual política é executada

Um route-map de interface associado com ip policy route-map aplica-se aos pacotes que chegam a essa interface, como descreve o guia PBR do IOS XE. Um host na VLAN 10 envia o seu pedido, a trama chega à subinterface VLAN e o router avalia a política aí. O pacote do próprio router nunca chega a essa interface, porque nasceu no router.

Escolher o endereço VLAN como origem altera o cabeçalho. Não altera a origem.

Porque o ping com origem ainda não é o host

O endereço de origem importa para uma correspondência ACL, e é exatamente isso que torna o teste tão convincente. O pacote corresponde a uma cláusula de origem, os contadores aumentam e a saída parece correta. O que o teste não pode mostrar é a interface de entrada, o contexto de chegada ou se um pacote do host seguiria o mesmo ramo.

Um teste que reproduz a correspondência mas não o contexto prova metade do desenho, e é com meia prova que os desenhos são entregues com a política errada associada.

Quando uma política local é a resposta certa

A Cisco documenta ip local policy route-map para o tráfego que o router gera ele próprio. Esse é um âmbito separado, e é a ferramenta correta quando o requisito diz realmente respeito ao tráfego do próprio router. Não é um passo em falta de que todos os desenhos de encaminhamento VLAN precisem. Uma correspondência ampla aí também pode afetar ligações de gestão e de suporte, o que é uma alteração muito maior do que parece.

O TCP gerado localmente tem um pré-requisito adicional: precisa de uma entrada de destino aplicável na tabela de encaminhamento mesmo quando a política seleciona outro caminho. Um resultado ICMP não prova o mesmo comportamento para TCP.

O que testar no host em vez disso

Execute o teste a partir de um host autorizado na VLAN 10, com o seu endereço de origem, destino, protocolo e porta reais. Registe a interface de entrada e a correspondência do route-map ao lado do resultado, para que a prova nomeie a política que foi executada. Depois repita para um host na VLAN 20 e confirme que segue o outro caminho.

Ambos os caminhos precisam de next hops funcionais, acessibilidade de retorno e, quando aplicável, cobertura VPN. O PBR escolhe uma decisão de encaminhamento; não cria o serviço remoto nem concede autorização à aplicação.

O que o resultado pode e não pode provar

Um fluxo de host bem-sucedido prova que a política correspondeu e que o caminho escolhido funcionou nesse momento. Não prova que o tráfego do próprio router seja encaminhado, nem prova que a aplicação estivesse autorizada, porque são perguntas diferentes com provas diferentes.

Guarde o ping no registo como prova sobre um pacote local. Depois vá buscar a prova do fluxo do host, em vez de alargar o âmbito da política até os dois testes parecerem iguais.

Artigos relacionados