Entendendo as subrotinas de políticas em condições de correspondência de políticas de roteamento
Você pode usar uma política de roteamento chamada de outra política de roteamento como condição compatível. Esse processo torna a chamada política uma subroutina.
De certa forma, a estrutura de políticas do Junos OS é semelhante a uma linguagem de programação. Essa semelhança inclui o conceito de aninhar políticas em uma subroutina de políticas. Uma subroutina em um programa de software é uma seção de código que você faz referência regularmente. Uma subrotina de política funciona da mesma forma — você faz referência a uma política existente como critério de correspondência em outra política. O dispositivo de roteamento avalia primeiro a subrotina e depois avalia a política principal. A avaliação da subroutina devolve um resultado booleano verdadeiro ou falso à política principal. Como você está fazendo referência à subroutina como um critério de correspondência, um resultado real significa que a política principal tem correspondência e pode realizar qualquer ação configurada. Um resultado falso da subroutina, no entanto, significa que a política principal não tem correspondência.
Configuração de subroutines
Para configurar uma subroutina em uma política de roteamento a ser chamada de outra política de roteamento, crie a subroutina e especifique seu nome usando a policy condição de correspondência na from ou to declaração de outra política de roteamento.
Não avalie uma política de roteamento em si mesma. O resultado é que nenhum prefixo corresponde à política de roteamento.
A ação especificada em uma subroutina é usada para fornecer uma condição de correspondência à política de chamada. Se a subroutina especificar uma ação de aceitação, a política de chamada considera a rota compatível. Se a subroutina especificar uma ação de rejeição, a política de chamada considera a rota não compatível. Se a subroutina especificar uma ação destinada a manipular as características da rota, as alterações serão feitas.
Possíveis consequências das ações de rescisão em subroutines
Uma subroutina com declarações específicas pode se comportar de forma diferente de uma política de roteamento que contém as mesmas declarações. Com uma subroutina, você deve lembrar que as possíveis ações de rescisão de aceitar ou rejeitar especificadas pela subroutina ou pela política padrão podem afetar muito os resultados esperados.
Em particular, você deve considerar o que acontece se uma correspondência não ocorrer com rotas especificadas em uma subroutina e se a ação de política padrão que é tomada é a ação que você espera e deseja.
Por exemplo, imagine que você é um administrador de rede em um provedor de serviços de Internet (ISP) que fornece serviços ao Cliente A. Você configurou várias políticas de roteamento para as diferentes classes de vizinhos que o Cliente A apresenta em vários links. Para economizar tempo mantendo as políticas de roteamento para o Cliente A, você configurou uma subroutina que identifica suas rotas e várias políticas de roteamento que chamam de subroutine, conforme mostrado abaixo:
[edit]
policy-options {
policy-statement customer-a-subroutine {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
}
policy-options {
policy-statement send-customer-a-default {
from {
policy customer-a-subroutine;
}
then {
set metric 500;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-primary {
from {
policy customer-a-subroutine;
}
then {
set metric 100;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-secondary {
from {
policy customer-a-subroutine;
}
then {
set metric 200;
accept;
}
}
}
protocols {
bgp {
group customer-a {
export send-customer-a-default;
neighbor 10.1.1.1;
neighbor 10.1.2.1;
neighbor 10.1.3.1 {
export send-customer-a-primary;
}
neighbor 10.1.4.1 {
export send-customer-a-secondary;
}
}
}
}
Os resultados a seguir ocorrem com esta configuração:
A declaração de nível
exportde grupo redefiniu a métrica para 500 ao anunciar todas as rotas BGP para os vizinhos 10.1.1.1 e 10.1.2.1, em vez de apenas as rotas que correspondem aos filtros de rota subroutina.As declarações de nível
exportvizinho redefiniram a métrica para 100 e 200 quando anunciam todas as rotas BGP para os vizinhos 10.1.3.1 e 10.1.4.1, respectivamente, em vez de apenas as rotas BGP que combinam com os filtros de rota subroutina.
Esses resultados inesperados ocorrem porque a política de subroutina não especifica uma ação de rescisão para rotas que não correspondam ao filtro de rota e, portanto, a política de exportação BGP padrão de aceitar todas as rotas BGP é tomada.
Se as declarações incluídas nesta subroutina em particular tivessem sido contidas dentro das próprias políticas de chamada, apenas as rotas desejadas teriam suas métricas redefinidas.
Este exemplo ilustra as diferenças entre políticas de roteamento e subroutines e a importância da ação de rescisão em uma subroutina. Aqui, a ação padrão da política de exportação bgp para a subroutina não foi cuidadosamente considerada. Uma solução a este exemplo em particular é adicionar mais um termo à subroutina que rejeita todas as outras rotas que não correspondem aos filtros de rota:
[edit]
policy-options {
policy-statement customer-a-subroutine {
term accept-exact {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
term reject-others {
then reject;
}
}
}
As estratégias de ação de rescisão para subroutines em geral incluem:
Dependa da ação padrão da política para lidar com todas as outras rotas.
Adicione um termo que aceita todas as outras rotas.
Adicione um termo que rejeita todas as outras rotas.
A opção que você escolhe depende do que deseja alcançar com sua subroutina. Planeje suas subrotinas com cuidado.