Como as comunidades BGP e comunidades estendidas são avaliadas em condições de correspondência de políticas de roteamento
Quando você usa comunidades BGP e comunidades estendidas como condições de correspondência em uma política de roteamento, o software de estrutura de políticas as avalia da seguinte forma:
Cada rota é avaliada em relação a cada comunidade nomeada em uma declaração de política
from
de roteamento. Se uma rota corresponde a uma das comunidades nomeadas nafrom
declaração, a avaliação do termo atual continua. Se uma rota não corresponder, a avaliação do termo atual termina.A rota é avaliada em relação a cada membro de uma comunidade nomeada. A avaliação de todos os membros deve ser bem sucedida para que a avaliação nomeada da comunidade seja bem sucedida.
Cada membro em uma comunidade nomeada é identificado por um valor literal da comunidade ou por uma expressão regular. Cada membro é avaliado em relação a cada comunidade associada à rota. (As comunidades são uma propriedade desordenada de uma rota. Por exemplo, 1:2 3:4 é o mesmo que 3:4 1:2.) Apenas uma comunidade da rota é necessária para combinar para que a avaliação dos membros seja bem sucedida.
As expressões regulares da comunidade são avaliadas de caráter por personagem. Por exemplo, se uma rota contém a comunidade 1234:5678, as expressões regulares veem nove caracteres discretos, incluindo o cólon (:), em vez de dois conjuntos de números (1234 e 5678) separados por um cólon. Por exemplo:
[edit] policy-options { policy-statement one { from { community [comm-one comm-two]; } } community comm-one members [ 1:2 "^4:(5|6)$" ]; community comm-two members [ 7:8 9:10 ]; }
Se um membro da comunidade for uma expressão regular, uma combinação de cordas é feita em vez de uma correspondência numérica.
Por exemplo:
community example1 members 100:100 community example2 members 100:1..
Dada uma rota com um valor de comunidade de 1100:100, esta rota corresponde
community example2
, mas nãoexample1
.Para combinar com a política
one
de roteamento, a rota deve corresponder a amboscomm-one
oucomm-two
.Para combinar
comm-one
, o percurso deve ter uma comunidade que corresponda a 1:2 e uma comunidade que corresponda a 4:5 ou 4:6.Para combinar
comm-two
, a rota deve ter uma comunidade que corresponda a 7:8 e uma comunidade que corresponda às 9h10.
Várias partidas
Quando vários fósforos são encontrados, a agregação de rótulos não acontece. Considere a configuração a seguir:
family inet-vpn { unicast { aggregate-label { community community-name; } } }
family inet-vpn { labeled-unicast { aggregate-label { community community-name; } } }
Suponha, por exemplo, que duas rotas sejam recebidas com atributos target:65000:1000 origin:65200:2000
da comunidade e que o nome da comunidade seja "5...:.*"
. Neste caso, ambos os atributos estendidos target:65000:1000
da comunidade e origin:65200:2000
correspondem à expressão regular do nome da comunidade. Neste caso, a agregação de rótulos não ocorre. No exemplo a seguir, o Label operation
campo mostra que os rótulos não são agregados.
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: target:65000:1000 origin:65200:2000
Você pode resolver esse problema de qualquer uma das seguintes maneiras:
Seja mais específico na expressão regular se o atributo da comunidade estendida do site de origem não se sobrepor ao alvo.
Especifique o local de origem no nome da comunidade.
Ambos os métodos são mostrados nos seguintes exemplos.
Seja mais específico na expressão regular
user@host# set policy-options community community-name members "52..:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
Especifique o site de origem no nome da comunidade
user@host# set policy-options community community-name members "origin:65...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000
Invertendo partidas da comunidade
A community
condição da correspondência define uma expressão regular e se corresponder ao atributo da comunidade do prefixo recebido, o Junos OS retorna um resultado TRUE. Caso contrário, o Junos OS retorna um resultado FALSO. A invert-match
declaração faz com que o Junos OS se comporte em contrário. Se houver correspondência, o Junos OS retorna um resultado FALSO. Se não houver correspondência, o Junos OS retorna um resultado TRUE. Para inverter os resultados da correspondência da expressão da comunidade, inclua a invert-match
declaração na configuração da comunidade.
[edit policy-options community name] invert-match;
Tipo de comunidade estendida
O tipo de comunidade estendida não é levado em conta por expressões regulares. Considere, por exemplo, os seguintes atributos da comunidade e o nome da comunidade.
Comunidades:
-
5200:1000
-
target:65000:1000
-
origin:65200:2000
Atributo da comunidade:
-
membros de nome da comunidade "5...:.*"
Neste caso, tanto o atributo estendido da comunidade quanto 5200:1000
o atributo estendido da comunidade correspondem origin:65200:2000
à expressão regular do nome da comunidade. Portanto, a agregação de rótulos não ocorre, como mostrado aqui:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101056 Push 101056 Communities: 5200:1000 target:65000:1000 origin:65200:2000
Você pode resolver esse problema usando uma expressão regular mais específica. Por exemplo, você pode usar o caractere âncora (^
) para vincular a localização dos dígitos, conforme mostrado aqui:
user@host# set policy-options community community-name members "^5...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: 5200:1000 target:65000:1000 origin:65200:2000
Com a implementação do recurso da grande comunidade no lançamento do 17.3, o Junos OS verifica para evitar a correspondência de comunidades estendidas ou grandes contra a BASE BGP ou comunidades de expressão regular BGP base. Em outras palavras, uma comunidade recebida só pode ser combinada com o padrão adequado da comunidade selvagem, como comunidades normais contra comunidades simples-selvagens e estendidas contra comunidades extensas e grandes contra padrões de grande natureza. Por exemplo, para permitir que o anúncio de rotas que transportam a comunidade de origem estendida, use a origin:*:65020
expressão.
Várias comunidades são combinadas com a lógica ex-OR
Isso difere da lógica de correspondência E usada para comunidades não estendidas no BGP.
Se, por exemplo, quatro rotas forem recebidas com dois conjuntos de atributos da comunidade, a expressão regular pode corresponder a ambos os atributos da comunidade. Considere o exemplo a seguir:
Comunidades — 5200:1000 target:65000:1000
Comunidades — target:65000:1000 origin:65200:2000
Atributo da comunidade — membro de nome da comunidade [ "^5...:.*" origem:65.*:.* ]
Ambas as etiquetas são agregadas, como mostrado aqui:
user@host> show route table VPN detail | match "^10 | Communities | Push" 10.1.1.0/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.4/30 (1 entry, 1 announced) Label operation: Push 101040 Push 101040 Communities: target:65000:1000 origin:65200:2000 10.1.1.16/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000 10.1.1.20/30 (1 entry, 1 announced) Label operation: Push 121104 Push 101104 Communities: 5200:1000 target:65000:1000
Um exemplo mais completo dos valores da comunidade é mostrado aqui:
user@host> show policy-options community community-name members [ "(^1...:*)|(^3...:*)|(^4...:*)" origin:2.*:* origin:3.*:* origin:6.*:* ]
Essa expressão regular corresponde aos valores da comunidade a partir de 1, 3 ou 4, e corresponde aos valores estendidos da comunidade de origem do tipo cujo valor administrativo começa com 2, 3 ou 6.
Incluindo comunidades BGP e comunidades estendidas em condições de correspondência de políticas de roteamento
Para incluir uma comunidade BGP ou uma comunidade estendida em uma condição de correspondência de política de roteamento, inclua a community
condição na from
declaração de um termo de política:
from { community [ names ]; }
Além disso, você pode excluir explicitamente as informações da comunidade BGP com uma rota estática usando a opção none
. Inclua essa opção ao configurar uma rota individual na porção para substituir uma opção route
de comunidade especificada na defaults
porção.
Você pode incluir os nomes de várias comunidades na condição de community
jogo. Se você fizer isso, apenas uma comunidade precisa combinar para que uma correspondência ocorra (a correspondência é efetivamente uma operação or lógica).