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 filtro de rota tem sucesso se e somente se o prefixo considerado for exatamente.10.0.0.0/8 exact accept10.0.0.0/8 Este 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 a rota.10.0.0.0/1010.0.0.0/10
Embora a rota e as variações não estejam especificamente reservadas à documentação, o espaço de endereço RFC 1918 privado é usado neste tópico devido à flexibilidade e cenários realistas que esses espaços de endereço fornecem.10.0.0.0/810.0.0.0/8
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 filtro inclui o filtro em seu escopo.10.0.0.0/8 orlonger10.0.0.0/16 prefix-length-range /22-/24 Ou seja, qualquer 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.10.0.0.0
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 (e assim por diante).
orlongerexactA 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 , isso significa que qualquer rota que seja "verdadeira" é aceita e qualquer rota que seja "falsa" no termo é recusada.Route-Filter-ARouteFilter-1 Essa rota se torna uma rota oculta (filtrada).
Por exemplo, considere o que acontece quando a rota é avaliada pela declaração de política:10.0.0.0/18RouteFilter-A
Primeiro, a rota é avaliada pelo termo.10.0.0.0/18RouteFilter-1 Como é mais longo do que , a rota corresponde ao prefixo de rota mais longo e específico.10.0.0.0/1610.0.0.0/810.0.0.0/18 Em seguida, a partida falha porque a rota não corresponde à condição.10.0.0.0/18prefix-length-range /22-/24 Assim, a correspondência de rota falha no termo, e a política examina o próximo termo, o termo padrão.RouteFilter-1 A rota é recusada pelo termo padrão.10.0.0.0/18
Como resultado, a rota está oculta (filtrada).10.0.0.0/18 (A rota ainda pode ser encontrada com o comando.)10.0.0.0/18show route hidden
O problema é que o usuário pode realmente querer que a rota seja aceita, não descartada.10.0.0.0/18 Naturalmente, um filtro de rota com uma configuração pode ser adicionado.10.0.0.0/18 exact 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 rota é aceita porque, embora ainda não tenha a condição da partida, ela corresponde ao novo prazo ( é a partida mais longa, e a condição é verdadeira).10.0.0.0/18RouteFilter-1RouteFilter-210.0.0.0/8orlonger 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 de rota é avaliado pela declaração de política:10.0.0.0/18RouteFilter-A
O comportamento padrão é alterado pelo botão walkup. Como antes, a rota corresponde ao prefixo de rota mais longo e específico porque é mais longo do que .10.0.0.0/1810.0.0.0/1610.0.0.0/8 Como antes, esta partida falha porque a rota não corresponde à condição.10.0.0.0/18prefix-length-range /22-/24 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 a este filtro e, portanto, a rota é aceita pelo termo.orlongerRouteFilter-1
Isso pode ser verificado (para uma rota BGP) pelo comando.show route protocol bgp 10.0.0.0/18 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 declaração.[edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup]