Visão geral do walkup for Route Filters
Use o recurso walkup se tiver preocupações com o desempenho da política devido a filtros de rota divididos em vários termos de política. O recurso walkup permite a consolidação de filtros de rota em um único termo de política.
Por padrão, o Junos avalia vários filtros de rota em um termo de declaração de política, primeiro encontrando o prefixo de correspondência mais longo e, em seguida, avaliando as condições anexadas ao filtro de rota, como o intervalo de prefixo. Se a condição do filtro de rota for falsa (por exemplo, o prefixo não está na faixa especificada), então todo o termo é falso, mesmo que haja prefixos de filtro de rota mais curtos potencialmente verdadeiros. Devido a esse comportamento, pode haver problemas de desempenho se os filtros de rota forem divididos em termos de declaração de política individual. O recurso walkup altera o comportamento padrão do filtro de rota.
Algumas ferramentas de política automatizadas — por exemplo, usadas para roteadores de borda de sistema autônomo no Border Gateway Protocol (BGP) — quebram filtros de rota em vários termos devido ao comportamento padrão do filtro de rota. Os filtros de rota também são usados em protocolos de roteamento que não sejam BGP; o recurso walkup não se limita a filtros de rota BGP.
Tecnicamente, o BGP não lida com rotas da mesma forma que o OSPF ou o IS-IS. As "rotas" BGP são mais adequadamente chamadas de atualizações de informações de alcance de camada de rede (NLRI). No entanto, 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 exemplo)
10.0.0.0/8Uma condição compatível (por exemplo)
exactUma ação que é realizada se ambas as partes anteriores — o prefixo e a condição da correspondência — avaliarem como verdadeiras (por exemplo
accept)
Assim, o 10.0.0.0/8 exact accept filtro de rota tem sucesso se e somente se o prefixo considerado for 10.0.0.0/8 exatamente. Este filtro de rota rejeita rotas com todos os outros prefixos mais longos, como 10.0.0.0/10, por exemplo, embora possa haver outros termos de filtro de rota na cadeia de políticas que aceitam a 10.0.0.0/10 rota.
Embora a rota e as 10.0.0.0/8 variações não estejam especificamente reservadas à documentação, o espaço de endereço RFC 1918 10.0.0.0/8 privado é usado neste tópico devido à flexibilidade e cenários realistas que esses espaços de endereço fornecem.
Os filtros de rota 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 10.0.0.0/16 prefix-length-range /22-/24 filtro em seu escopo. Ou seja, qualquer 10.0.0.0 rota com um prefixo de 8 bits ou mais também pode ser uma rota com um prefixo na faixa entre 22 e 24 bits.
Por padrão, a avaliação de um termo de declaração de política com vários filtros de rota é um processo de duas etapas:
O software de estrutura de políticas realiza uma busca mais longa na lista com base em valores de prefixo e comprimento de prefixo.
O software considera a condição do filtro de rota (
orlongerexacte assim por diante). A rota atende à condição do filtro de rota (sucesso) ou não corresponde à condição do filtro de rota (falha).
Com base nos resultados dessas duas etapas, a ação determinada pela correspondência ou falha é aplicada à rota. Em Route-Filter-A, isso significa que qualquer rota que seja "verdadeira" é aceita e qualquer rota que seja "falsa" no RouteFilter-1 termo é recusada. Essa rota se torna uma rota oculta (filtrada).
Por exemplo, considere o que acontece quando a rota 10.0.0.0/18 é avaliada pela declaração RouteFilter-Ade política:
Primeiro, a 10.0.0.0/18 rota é avaliada pelo RouteFilter-1 termo. Como 10.0.0.0/16 é mais longo do que 10.0.0.0/8, a 10.0.0.0/18 rota corresponde ao prefixo de rota mais longo e específico. Em seguida, a partida falha porque a 10.0.0.0/18 rota não corresponde à prefix-length-range /22-/24 condição. Assim, a correspondência de rota falha no RouteFilter-1 termo, e 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 está 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 descartada. Naturalmente, um filtro de rota com uma 10.0.0.0/18 exact configuração pode ser adicionado. No entanto, em uma tabela de roteamento de backbone com 100.000 ou mais entradas, não é possível configurar um filtro de rota ajustado para todas as rotas possíveis ou todas as possíveis novas rotas adicionadas à rede.
A solução padrão para alcançar o comportamento adequado a partir da política de roteamento de exemplo é configurar um termo separado para cada filtro de rota. 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 10.0.0.0/18 rota é aceita porque, embora ainda não tenha a condição da RouteFilter-1 partida, ela corresponde ao novo RouteFilter-2 prazo (10.0.0.0/8 é a partida mais longa, e a orlonger condição é verdadeira). O problema com essa abordagem é que a política de roteamento completa agora leva mais tempo para avaliar do que quando vários filtros de rota são agrupados. Esse método também torna a manutenção mais complexa.
Os problemas com a abordagem de um termo por filtro de rota são resolvidos com a declaração e o recurso walkup. O Walkup altera o comportamento padrão da avaliação do filtro de rota globalmente ou em uma base por política.
O recurso walkup permite que termos com vários filtros de rota "walk-up" do processo de avaliação incluam rotas menos específicas, bem como a correspondência mais longa. Em outras palavras, o botão walkup altera o comportamento padrão de "se um falhar, então o termo falha" para se "um corresponde, então o termo corresponde".
Considere a aplicação do recurso walkup na declaraçã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;
}
}
Isso é o que acontece quando o prefixo 10.0.0.0/18 de rota é avaliado pela declaração RouteFilter-Ade política:
O comportamento padrão é alterado pelo botão walkup. Como antes, a 10.0.0.0/18 rota corresponde ao prefixo de rota mais longo e específico porque 10.0.0.0/16 é mais longo do que 10.0.0.0/8. Como antes, esta partida falha porque a 10.0.0.0/18 rota não corresponde à prefix-length-range /22-/24 condição. No entanto, desta vez, o processo continua por um "walk up" e examina o filtro de rota menos específico 10.0.0.0/8 . A condição de rota corresponde orlonger a este filtro e, portanto, a rota é aceita pelo RouteFilter-1 termo.
Isso pode ser verificado (para uma rota BGP) pelo show route protocol bgp 10.0.0.0/18 comando. Desta vez, a rota não está oculta.
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.