Resumo geral dos filtros de rotas
Use o recurso walkup se tiver dúvidas sobre o desempenho da política por causa dos filtros de roteagem divididos em vários termos de política. O recurso walkup permite a consolidação de filtros de roteamento em um único termo de política.
Por padrão, o Junos avalia vários filtros de roteamento em um termo de declaração de política encontrando primeiro o prefixo de combinação mais longo e avaliando as condições conectadas ao filtro de roteamento, como intervalo de prefixo. Se a condição do filtro de rotear for falsa (por exemplo, o prefixo não está no intervalo especificado), todo o termo é falso, mesmo se houver prefixos de filtro de rota potencialmente verdadeiros mais curtos. Devido a esse comportamento, pode haver problemas de desempenho se os filtros de rotear são divididos em termos individuais de declaração de política. O recurso walkup muda o comportamento padrão do filtro de rota.
Algumas ferramentas de política automatizadas — por exemplo, aquelas usadas para roteadores de borda de sistema autônomos no protocolo de gateway de borda (BGP) — rompem os filtros de rota em vários termos por causa do comportamento padrão do filtro de rota. Filtros de roteamento também são usados em protocolos de roteamento que não sejam BGP; o recurso de walkup não se limita a BGP filtros de rotear.
Tecnicamente, BGP lida com rotas da mesma maneira que OSPF ou IS-IS. BGP "rotas" são atualizações mais adequadas de informações de alcance da camada de rede (NLRI). Entretanto, o termo "rota" é usado na maioria da documentação e é usado aqui.
Os filtros de rota consistem em três partes principais:
Um comprimento de prefixo e prefixo (por
10.0.0.0/8exemplo)Uma condição de combinação (por
exactexemplo)Uma ação que é realizada se ambas as partes anteriores — o prefixo e a condição da combinação — avaliarem a verdade (por
acceptexemplo)
Assim, 10.0.0.0/8 exact accept o filtro de rota é bem-sucedido se e somente se o prefixo considerado for 10.0.0.0/8 exatamente. Esse filtro de rota rejeita rotas com todos os outros prefixos mais longos, como, por exemplo, embora possa haver outros termos de filtro de rota na cadeia de políticas que aceitam 10.0.0.0/10 a 10.0.0.0/10 rota.
Embora a rota e as variações não sejam especificamente reservados para documentação, o espaço de endereços privado RFC 1918 é usado neste tópico devido à flexibilidade e aos cenários realistas que esses espaços de endereço 10.0.0.0/810.0.0.0/8 proporcionam.
Os filtros de roteação podem ser combinados em um único termo de declaração de política. Nesse caso, a avaliação se torna mais complexa. Considere a seguinte política de roteamento:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Observe que o 10.0.0.0/8 orlonger filtro inclui o filtro em seu 10.0.0.0/16 prefix-length-range /22-/24 escopo. Ou seja, qualquer rota com prefixo de 8 bits ou mais também pode ser uma rota com um prefixo na faixa entre 10.0.0.0 22 e 24 bits.
Por padrão, a avaliação de um termo de declaração de política com vários filtros de roteamento é um processo de duas etapas:
O software da estrutura de política realiza uma busca mais longa da lista com base nos valores de prefixo e comprimento do prefixo.
O software considera a condição do filtro de rota
orlongerexact(, etc.). A rota cumpre a condição do filtro de rota (sucesso) ou não atende à condição do filtro de rota (falha).
Com base nos resultados dessas duas etapas, a ação determinada pela combinação ou falha é aplicada à rota. Isso significa que qualquer rota que seja "verdadeira" é aceita e qualquer rota que seja Route-Filter-A "falsa" RouteFilter-1 no termo é recusada. Essa rota torna-se uma rota oculto (filtrada).
Por exemplo, considere o que acontece quando a rota 10.0.0.0/18 é avaliada pela instrução de RouteFilter-A política:
Primeiro, a 10.0.0.0/18 rota é avaliada pelo RouteFilter-1 termo. Como 10.0.0.0/16 é mais longa do que, a rota combina com o prefixo de rota mais 10.0.0.0/8 longo e 10.0.0.0/18 específico. Em seguida, a combinação falha porque 10.0.0.0/18 a rota não combina com a prefix-length-range /22-/24 condição. Assim, a combinação de rota falha no termo, e RouteFilter-1 a política examina o próximo termo, o termo padrão. A 10.0.0.0/18 rota é recusada pelo termo padrão.
Como resultado, a 10.0.0.0/18 rota fica oculta (filtrada). (A 10.0.0.0/18 rota ainda pode ser encontrada com o show route hidden comando.)
O problema é que o usuário pode realmente querer que a 10.0.0.0/18 rota seja aceita, não rejeitada. Naturalmente, um filtro de rota com 10.0.0.0/18 exact uma configuração pode ser adicionado. Mas, em uma tabela de roteamento de backbone com mais de 100.000 entradas, não é possível configurar um filtro de roteamento sintonizado em todas as rotas ou todas as novas rotas possíveis adicionadas à rede.
A solução alternativa padrão para obter o comportamento apropriado da política de roteamento de exemplo é configurar um termo separado para cada filtro de roteamento. Isso é feito com frequência, da seguinte forma:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
}
then accept;
}
term RouteFilter-2 {
from {
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
Agora, a rota é aceita porque, embora ele ainda não tenha a condição da combinação, ele combina com o novo termo ( é o mais longo jogo, e a condição 10.0.0.0/18RouteFilter-1 é RouteFilter-210.0.0.0/8orlonger verdadeira). O problema dessa abordagem é que a política de roteamento completa agora leva mais tempo para avaliar do que quando vários filtros de roteamento são agrupados. Esse método também torna a manutenção mais complexa.
Os problemas com a abordagem de filtros de um termo por rota são resolvidos com a declaração e o recurso de walkup. O walkup altera o comportamento padrão da avaliação do filtro de roteamento globalmente ou de acordo com a política.
O recurso walkup permite que termos com vários filtros de roteamento "walk-up" do processo de avaliação incluam rotas menos específicas e a combinação mais longa. Em outras palavras, o botão de walkup muda o comportamento padrão de "se um falha, então o termo falha" para se "um bate, o termo bate".
Considere a aplicação do recurso de walkup na instrução de política de exemplo (você também pode aplicar o walk-up globalmente a todas as políticas configuradas):
[edit policy-options]
policy-statement RouteFilter-A {
defaults {
route-filter walkup;
}
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
É o que acontece quando o prefixo de 10.0.0.0/18 rota é avaliado pela instrução de RouteFilter-A política:
O comportamento padrão é alterado pelo botão de walkup. Como antes, a rota combina com o prefixo de rota mais longo e 10.0.0.0/18 específico, porque 10.0.0.0/16 é mais longo do que 10.0.0.0/8 . Como antes, esta combinação falha porque 10.0.0.0/18 a rota não combina com a prefix-length-range /22-/24 condição. Entretanto, desta vez o processo continua por um "walk up" e examina o filtro de roteamento menos 10.0.0.0/8 específico. A condição da rota combina com esse filtro e, portanto, a rota orlonger é aceita pelo RouteFilter-1 termo.
Isso pode ser verificado (para uma BGP de BGP) pelo show route protocol bgp 10.0.0.0/18 comando. Desta vez, a rota não está escondida.
Se você habilitar o recurso walkup globalmente, você pode substituí-lo localmente por política com a [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] declaração.