Visão geral do Walkup for Route Filters
Use o recurso walkup se tiver preocupações com o desempenho da política por causa de 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 faixa de prefixo. Se a condição do filtro de rota for falsa (por exemplo, o prefixo não estiver na faixa especificada), o termo inteiro é falso, mesmo que haja prefixos de filtro de rota potencialmente mais curtos. Devido a esse comportamento, pode haver problemas de desempenho se os filtros de rota forem divididos em termos de declaração de políticas individuais. 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 Protocolo de Gateway de Fronteira (BGP) — quebram filtros de rota em vários termos por causa do 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 da camada de rede (NLRI). No entanto, o termo "rota" é usado na maior parte da documentação e é usado aqui.
Os filtros de rota consistem em três partes principais:
Um prefixo e um comprimento de prefixo (por exemplo)
10.0.0.0/8Uma condição de correspondência (por exemplo)
exactUma ação que é realizada se ambas as partes anteriores — o prefixo e a condição de 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 for 10.0.0.0/8 considerado exatamente. Esse filtro de rota rejeita rotas com todos os outros prefixos mais longos, como 10.0.0.0/10, 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 sejam 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 oferecem.
Os filtros de rota podem ser combinados em um único termo de declaração de política. Nesse caso, a avaliação torna-se 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 em 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 (
orlongerexactetc. 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. Isso Route-Filter-Asignifica que qualquer rota que seja "verdadeira" é aceita e qualquer rota que seja "falsa" no RouteFilter-1 termo é rejeitada. 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. Por 10.0.0.0/16 ser mais longa 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 rotas 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 é rejeitada 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 rejeitada. Naturalmente, um filtro de rota com uma 10.0.0.0/18 exact configuração poderia 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 a todas as rotas possíveis ou a todas as novas rotas possíveis 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 falhe na condição da RouteFilter-1 partida, ela corresponde ao novo RouteFilter-2 termo (10.0.0.0/8 é a partida mais longa, e a orlonger condição é verdadeira). O problema com essa abordagem é que a política completa de roteamento 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 filtros de um termo por rota são resolvidos com a declaração e o recurso walkup. O Walkup altera o comportamento padrão da avaliação de filtros de rota globalmente ou por política.
O recurso walkup permite que termos com vários filtros de rota "andem" o processo de avaliação incluam rotas menos específicas, bem como a combinação mais longa. Em outras palavras, o botão walkup muda o comportamento padrão de "se um falha, então o termo falha" para se "um corresponde, então o termo corresponde".
Considere a aplicação do recurso walkup para a declaração de política de exemplo (você também pode aplicar o walk-up global 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 esse 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á 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.