Início / Notas técnicas / Configuração de roteamento baseado em políticas

Roteamento baseado em políticas: direcionando o tráfego por origem, aplicação ou link

Dois problemas diferentes, a mesma ferramenta — enviar tráfego para um próximo salto específico com base em sua origem ou aplicação, em vez do que a tabela de roteamento escolheria por conta própria — correspondência em nível de interface por origem e por aplicação, um redirecionamento em escala de rede, comandos de verificação, e onde o roteamento baseado em políticas termina e a route-policy começa.

By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026

Por que roteamento baseado em políticas, e quando o roteamento comum não é suficiente

A tabela de roteamento responde a «como chego a este destino». O roteamento baseado em políticas responde a uma pergunta diferente: dado quem está pedindo e o que está pedindo, por onde este tráfego específico deve realmente ir.

Uma tabela de roteamento normal toma uma decisão por destino, e todo host que envia para esse destino recebe a mesma resposta. Isso funciona bem até deixar de funcionar — até que uma origem interna precise de um caminho específico, independentemente do que a tabela de roteamento diga sobre o destino, ou uma aplicação precise de seu próprio caminho por razões de latência ou custo enquanto tudo o mais segue a rota padrão. O roteamento baseado em políticas (PBR) existe exatamente para essa lacuna: ele primeiro combina o tráfego — por endereço de origem, protocolo, porta, qualquer coisa que um classificador de tráfego consiga expressar — e só então decide o próximo salto, à frente e independentemente da própria decisão da tabela de roteamento.

Abaixo estão duas configurações concretas: fazer o tráfego corresponder em uma única interface de entrada por endereço de origem e por aplicação (HTTP), cada uma redirecionada para um próximo salto diferente; e uma política em escala de rede que redireciona o tráfego de um par origem-destino para um roteador específico, independentemente do que a tabela de roteamento normal — construída aqui pelo OSPF — escolheria por conta própria. Se o seu cenário for mais parecido com enviar o tráfego de cada link de internet pelo seu próprio link com failover automático, isso é um problema relacionado mas diferente — veja nossa nota de configuração de failover em dual-WAN e balanceamento de carga para isso.

Plano de tráfego: o que é correspondido e para onde vai

Um roteador, várias interfaces, e duas regras de correspondência independentes decidindo quais pacotes são redirecionados antes mesmo de a tabela de roteamento os ver.

GE2/0/0 — inbound traffic-policy pbr inbound 10.2.1.1 · HTTP · everything else Router traffic policy pbr classifier → behavior by precedence order 10.5.1.2 — source match precedence 5 (highest) 10.4.1.2 — unmatched default route, preference 40 10.3.1.2 — HTTP match precedence 10

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Classificadores de tráfego e destinos de redirecionamento

CorrespondênciaPróximo salto de redirecionamentoPrecedência
ACL 3005 — source 10.2.1.1/3210.5.1.25 — avaliado primeiro
ACL 3006 — destination-port www (HTTP)10.3.1.210
Unmatched traffic10.4.1.2Tabela de roteamento normal — preferência de rota estática 40

Configuração passo a passo

Cinco passos: definir a correspondência, emparelhá-la com um redirecionamento, vincular tudo em uma única política com precedência, aplicá-la à interface e direção corretas, e garantir que o tráfego não correspondido ainda tenha para onde ir.

  1. Identifique o que deve ser direcionado de forma diferente — um endereço de origem, uma aplicação (porta de destino), ou um par origem-destino específico — e escreva uma ACL que corresponda exatamente a esse tráfego, nada mais amplo.
  2. Agrupe cada ACL em seu próprio classificador de tráfego, e emparelhe cada classificador com um comportamento de tráfego que redirecione o tráfego correspondido para um próximo salto específico com redirect ip-nexthop.
  3. Vincule cada par classificador-comportamento em uma única política de tráfego, dando a cada regra uma precedência — o número de precedência mais baixo é avaliado primeiro quando mais de uma regra pode corresponder ao mesmo pacote.
  4. Aplique a política de tráfego no sentido de entrada na interface por onde o tráfego realmente entra no roteador — traffic-policy é uma vinculação por interface e por direção, não global.
  5. Garanta que ainda exista uma rota normal para o tráfego que não corresponde a nenhuma regra da política — o PBR só redireciona o que corresponde explicitamente; todo o resto ainda recai sobre a tabela de roteamento.

Roteamento baseado em políticas na interface — por endereço de origem e por aplicação

#
 sysname Router
#
acl number 3005
 rule 0 permit ip source 10.2.1.1 0
#
acl number 3006
 rule 0 permit tcp destination-port eq www
#
traffic classifier 10.2.1.1 operator or
 if-match acl 3005
traffic classifier www operator or
 if-match acl 3006
#
traffic behavior 10.2.1.1
 redirect ip-nexthop 10.5.1.2
traffic behavior www
 redirect ip-nexthop 10.3.1.2
#
traffic policy pbr
 classifier 10.2.1.1 behavior 10.2.1.1 precedence 5
 classifier www behavior www precedence 10
#
interface GigabitEthernet2/0/0
 ip address 10.1.2.1 255.255.255.0
 traffic-policy pbr inbound
#
interface GigabitEthernet2/0/1
 ip address 10.3.1.1 255.255.255.0
#
interface GigabitEthernet2/0/2
 ip address 10.4.1.1 255.255.255.0
#
interface GigabitEthernet2/0/3
 ip address 10.5.1.1 255.255.255.0
#
ip route-static 192.168.1.0 24 10.3.1.2
ip route-static 192.168.1.0 24 10.4.1.2 preference 40
ip route-static 192.168.1.0 24 10.5.1.2
#
return

Três rotas estáticas alcançam deliberadamente o mesmo prefixo 192.168.1.0/24 — 10.4.1.2 carrega a preferência mais baixa (40), então vence a própria seleção da tabela de roteamento para o tráfego não correspondido, enquanto 10.3.1.2 e 10.5.1.2 permanecem alcançáveis apenas para que os próximos saltos redirecionados pelo PBR sejam válidos.

Roteamento baseado em políticas em escala de rede — redirecionando um fluxo origem-destino

Uma rede diferente e maior ilustra isso em escala: RouterA, RouterB e RouterC compartilham rotas por OSPF, e a tabela de roteamento sozinha enviaria o tráfego de 10.0.2.0/24 para 10.0.0.0/24 via RouterC. Uma política de tráfego no RouterA redireciona esse único fluxo para o RouterB.

RouterA — a política de tráfego e a camada OSPF subjacente

#
acl number 3001
 rule 5 permit ip source 10.0.2.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#
traffic classifier rdt operator or
 if-match acl 3001
#
traffic behavior rdt
 redirect ip-nexthop 10.181.10.2
#
traffic policy rdt
 classifier rdt behavior rdt
#
interface GigabitEthernet1/0/0
 ip address 10.181.20.1 255.255.255.0
#
interface GigabitEthernet2/0/0
 ip address 10.181.10.1 255.255.255.0
#
interface GigabitEthernet3/0/0
 ip address 10.0.2.1 255.255.255.0
 traffic-policy rdt inbound
#
ospf 1
 area 0.0.0.0
  network 10.0.2.0 0.0.0.255
  network 10.181.20.0 0.0.0.255
  network 10.181.10.0 0.0.0.255
#
return

RouterB — o destino do redirecionamento

#
interface GigabitEthernet1/0/0
 ip address 10.181.10.2 255.255.255.0
#
interface GigabitEthernet2/0/0
 ip address 10.184.10.1 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.181.10.0 0.0.0.255
  network 10.184.10.0 0.0.0.255
#
return

RouterC — o caminho preferido pelo OSPF que é contornado para esse único fluxo

#
interface GigabitEthernet1/0/0
 ip address 10.181.20.2 255.255.255.0
#
interface GigabitEthernet2/0/0
 ip address 10.184.10.2 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.184.10.0 0.0.0.255
  network 10.181.20.0 0.0.0.255
  network 10.0.0.0 0.0.0.255
#
return

Roteamento baseado em políticas vs Route-Policy — duas camadas diferentes de «política»

Apesar do nome parecido, route-policy é um mecanismo completamente diferente, operando em um plano diferente. Route-policy (configurada com route-policy ... permit/deny node ...) filtra e modifica as próprias rotas à medida que são aprendidas ou anunciadas entre protocolos de roteamento — por exemplo, aplicando um atributo local-preference ou community a rotas BGP, ou controlando quais rotas são redistribuídas de um protocolo para outro. O roteamento baseado em políticas, por outro lado, nunca toca na tabela de roteamento nem nas rotas nela contidas — ele intercepta pacotes que já chegaram a uma interface e os encaminha para um próximo salto específico com base em um classificador de tráfego, independentemente do que a tabela de roteamento diga. Uma route-policy muda quais rotas existem e como são rotuladas; uma política de tráfego com PBR muda para onde pacotes já decididos realmente vão. Um detalhe que vale a pena tomar emprestado da configuração de route-policy: uma route-policy precisa de um nó permit explícito e vazio no final, ou rotas que não corresponderam a nenhum nó anterior são silenciosamente filtradas — um modo de falha diferente do próprio comportamento do PBR com tráfego não correspondido, mas um instinto parecido a se verificar.

Projetos de soluções relacionados

Solução de segurança de borda de internet empresarialA camada de firewall e políticas que costuma acompanhar um roteador orientado por PBR quando o projeto de borda cresce além de um único roteador redirecionando tráfego. Solução de interconexão VPN multifilialProjetos para redes de lojas e multissites onde diferentes filiais, ou diferentes tipos de tráfego dentro de uma mesma filial, precisam ser direcionados por caminhos diferentes.

Como confirmar que está realmente redirecionando

Verifique o classificador, o comportamento e a política de forma independente, e depois confirme com um traço que o tráfego realmente sai pelo próximo salto redirecionado.

  1. Execute display traffic classifier user-defined [classifier-name] — confirme que cada classificador corresponde à ACL esperada.
  2. Execute display traffic behavior {system-defined | user-defined} [behavior-name] — confirme que o próximo salto de redirecionamento de cada comportamento está correto.
  3. Execute display traffic policy user-defined [policy-name [classifier classifier-name]] — confirme a ordem de precedência dentro da política vinculada.
  4. Execute display traffic-policy applied-record [policy-name] — confirme que a política está realmente aplicada na interface e direção pretendidas.
  5. A partir de uma origem correspondente, execute um traço até o destino e confirme que o caminho realmente passa pelo próximo salto redirecionado, não pelo que a tabela de roteamento sozinha teria escolhido.
<Host> tracert -a 10.0.2.1 10.0.0.1

 1  10.181.20.1     3 ms  2 ms  1 ms
 2  10.181.10.2     4 ms  3 ms  3 ms
 3  10.184.10.1     5 ms  4 ms  4 ms
 4  10.0.0.1        6 ms  5 ms  5 ms

O segundo salto (10.181.10.2) é o endereço do RouterB — confirmando que a política de tráfego redirecionou esse fluxo para lá em vez do caminho preferido pelo OSPF via RouterC. Seus próprios endereços de salto e tempos serão diferentes; o que importa é por qual roteador o traço passa.

4 armadilhas de configuração

As que transformam um redirecionamento funcional em tráfego que silenciosamente vai pelo caminho errado, ou para lugar nenhum.

1. Uma política de tráfego sem correspondência ainda precisa de um lugar para onde cair

SINTOMAO tráfego que claramente não corresponde a nenhum classificador da política acaba sendo descartado ou roteado incorretamente, em vez de simplesmente seguir a tabela de roteamento normal.

CAUSAAplicar traffic-policy no sentido de entrada em uma interface não cria uma negação padrão como certa lógica de ACL faz — mas se a rota normal da interface para esse destino estiver ausente ou errada, não há nada sensato para onde o tráfego não correspondido possa recorrer. O PBR só decide para o que corresponde explicitamente; todo o resto precisa de uma entrada de tabela de roteamento funcional para começar.

SOLUÇÃOConfirme a alcançabilidade normal (uma rota em display ip routing-table) para o destino antes de sobrepor o PBR — o PBR substitui o próximo salto do tráfego correspondido, não cria alcançabilidade do nada.

2. O próximo salto de redirecionamento não precisa vencer na tabela de roteamento — só precisa ser alcançável

SINTOMAExiste uma rota estática para o endereço do próximo salto de redirecionamento, mas display ip routing-table mostra uma rota completamente diferente vencendo para esse mesmo prefixo.

CAUSAredirect ip-nexthop encaminha diretamente os pacotes correspondidos para esse endereço — não exige que a rota desse endereço seja o melhor caminho da própria tabela de roteamento. Na configuração de trabalho aqui, três rotas estáticas para o mesmo prefixo coexistem deliberadamente: uma vence a própria seleção da tabela de roteamento (menor valor de preferência) para o tráfego não correspondido, enquanto as outras duas existem apenas para que os próximos saltos redirecionados pelo PBR sejam alcançáveis.

SOLUÇÃONão presuma que o próximo salto de redirecionamento precisa «vencer» qualquer comparação de rotas — verifique a alcançabilidade diretamente (faça ping, ou verifique a rota estática específica), não observando qual rota a tabela prefere atualmente.

3. A precedência decide qual classificador vence quando um pacote poderia corresponder a mais de um

SINTOMAUm pacote que claramente deveria acionar a regra mais específica — digamos, uma que corresponde a um endereço de origem específico — em vez disso é redirecionado pela regra mais ampla baseada em aplicação, ou vice-versa.

CAUSAUma política de tráfego avalia seus pares classificador-comportamento em ordem de precedência — o número de precedência mais baixo primeiro — e para na primeira correspondência, da mesma forma que uma ACL para na sua primeira regra correspondente. Se a regra mais geral tiver um número de precedência mais baixo que a mais específica, a regra geral vence mesmo quando ambas poderiam corresponder.

SOLUÇÃODê à correspondência mais específica o número de precedência mais baixo, exatamente como na configuração de trabalho — a correspondência por endereço de origem fica na precedência 5, à frente da correspondência por aplicação na precedência 10.

4. traffic-policy no sentido de entrada só vê o tráfego que entra por aquela interface, não o tráfego já dentro do roteador

SINTOMAO tráfego que claramente corresponde à ACL usada em um classificador ainda assim não é redirecionado.

CAUSAA política está vinculada com uma direção — entrada em uma interface específica. Ela só avalia o tráfego quando chega por essa interface exata nessa direção; o tráfego originado em outro lugar do roteador, ou que chega por uma interface diferente, nunca passa por essa política.

SOLUÇÃOConfirme por qual interface física o tráfego em questão realmente entra, e garanta que essa é a interface — e direção — à qual o traffic-policy está aplicado, não qualquer interface no caminho.

5. PBR e route-policy resolvem problemas diferentes mesmo que ambos digam «política»

SINTOMAAlguém tenta direcionar o tráfego de uma origem específica para um próximo salto específico editando uma route-policy aplicada a um protocolo de roteamento, e isso não faz nada para esse tráfego.

CAUSARoute-policy molda quais rotas existem e seus atributos no plano de controle — não tem noção de «pacotes desta origem específica», apenas de rotas e seus atributos conforme trocados pelos protocolos. Direcionar o tráfego de uma origem para um próximo salto específico, independentemente da melhor rota normal do destino, é uma decisão do plano de dados, por pacote — é para isso que serve o PBR.

SOLUÇÃOUse PBR quando o fator decisivo for algo sobre o próprio pacote (origem, protocolo, porta); use route-policy quando o fator decisivo for algo sobre a rota (qual protocolo a aprendeu, seus atributos, se deve ser redistribuída).

Limites honestos desta nota

Limites honestos desta nota

Esta nota é baseada em duas configurações concretas: PBR em nível de interface correspondendo por endereço de origem e por porta de destino HTTP com dois destinos de redirecionamento independentes, e um redirecionamento PBR em escala de rede sobreposto a uma rede roteada por OSPF. Ela não cobre PBR baseado em comprimento de pacote ou marcação DSCP/precedência, balanceamento de carga do tráfego entre mais de um próximo salto de redirecionamento, nem a aplicação do roteamento baseado em políticas no sentido de saída em vez de entrada. Também não cobre route-policy em profundidade — route-policy molda rotas, não pacotes, e merece seu próprio tratamento; o que está aqui é apenas a distinção necessária para escolher a ferramenta certa.

Cinco perguntas que merecem uma resposta

Extraídas dos mesmos casos de configuração nos quais esta nota se baseia.

O roteamento baseado em políticas substitui a tabela de roteamento?

Não — ele só se antepõe para o tráfego correspondido. Tudo o que um classificador de tráfego não corresponde explicitamente ainda recai na tabela de roteamento normal, exatamente como se o PBR não estivesse configurado.

Posso corresponder a mais do que endereço de origem e porta de destino?

Sim — qualquer coisa que uma ACL (ou um classificador de tráfego mais complexo) consiga expressar vale: origem, destino, protocolo, faixas de porta, e mais. Os dois exemplos aqui — endereço de origem e porta de destino HTTP — são simplesmente os que a configuração de trabalho subjacente ilustra.

Qual é a diferença real em relação à route-policy?

Route-policy atua sobre as próprias rotas — filtrando ou rotulando o que um protocolo de roteamento aprende ou anuncia. O PBR atua sobre pacotes que já chegaram — redirecionando-os para um próximo salto específico com base em um classificador de tráfego, sem alterar nenhuma rota ou atributo de rota. Veja a comparação na seção de configuração acima para a distinção completa.

Quero que cada link de internet carregue seu próprio tráfego com failover automático — isso é a mesma coisa desta nota?

Está relacionado, mas é distinto. Isso costuma ser construído com rotas estáticas de preferência igual ou desigual (para balanceamento de carga ou primário/backup) em vez de um redirecionamento de política de tráfego — veja nossa nota de configuração de failover em dual-WAN e balanceamento de carga para esse projeto específico.

Preciso de uma rota estática para o próximo salto de redirecionamento mesmo que o PBR esteja decidindo o caminho?

Sim — redirect ip-nexthop ainda precisa que esse endereço de próximo salto seja genuinamente alcançável; o PBR decide que um pacote correspondido vai para lá, mas não fabrica alcançabilidade. Como mostrado na armadilha 2 acima, essa rota não precisa ser o caminho preferido da própria tabela de roteamento para o prefixo, só precisa existir.

O roteamento baseado em políticas pode ser aplicado no sentido de saída em vez de entrada?

A palavra-chave de configuração suporta ambas as direções, mas o sentido de entrada na interface por onde o tráfego realmente se origina da fonte que você está correspondendo é, de longe, o posicionamento mais comum e previsível — ele captura o tráfego no ponto mais precoce, antes que qualquer outra decisão de encaminhamento tenha chance de se aplicar.

Precisa enviar um tráfego específico por um caminho específico?

Diga-nos qual tráfego — por origem, aplicação ou link — precisa ir para onde, e ajudaremos você a escrever corretamente o classificador e a ordem de precedência.

WhatsApp com um engenheiro →

Leituras relacionadas

Solução de segurança de borda de internet empresarialA camada de firewall e políticas que costuma se juntar a um roteador orientado por PBR conforme o projeto de borda cresce. Solução de interconexão VPN multifilialProjetos para redes de lojas e multissites onde diferentes filiais ou tipos de tráfego precisam de seus próprios caminhos direcionados. Configuração de failover em dual-WAN e balanceamento de cargaO projeto relacionado mas distinto para enviar a cada link de internet seu próprio tráfego com failover automático.
Usamos cookies apenas para análises anônimas — sem anúncios, sem rastreamento entre sites.Política de privacidade