Validação da origem do BGP
Entendendo a validação de origem para BGP
A validação de origem ajuda a evitar o anúncio involuntário das rotas. Às vezes, os administradores de rede anunciam erroneamente rotas para redes que não controlam. Você pode resolver esse problema de segurança configurando a validação de origem (também conhecida como roteamento seguro entre domínios). A validação de origem é um mecanismo pelo qual os anúncios de rota podem ser autenticados como originários de um sistema autônomo (AS) esperado. A validação de origem usa um ou mais servidores de cache de infraestrutura de chave pública (RPKI) para realizar autenticação para prefixos BGP especificados. Para autenticar um prefixo, o roteador (speaker BGP) consulta o banco de dados de mapeamentos validados de prefixo para AS, que são baixados do servidor de cache e garante que o prefixo tenha se originado de um AS esperado.
Quando você habilita a autenticação de RPKI, o Junos OS abre automaticamente a porta TCP 2222 sem qualquer aviso. Você pode aplicar um filtro para bloquear e proteger essa porta.
O Junos OS oferece suporte à validação de origem para prefixos IPv4 e IPv6.
Figura 1 mostra uma topologia de amostra.
- Padrões suportados
- Como funciona a validação da origem
- Interação do BGP com o banco de dados de validação de rotas
- Atributo da comunidade para anunciar o estado de validação de RPKI aos vizinhos do IBGP
- Validação ininterrupta de roteamento ativo e origem
- Marcando um intervalo de prefixo como nunca permitido
Padrões suportados
A implementação da validação de origem pelo Junos OS oferece suporte aos seguintes RFCs e rascunho:
RFC 6810, a infraestrutura de chave pública de recursos (RPKI) para o protocolo de roteador
RFC 6811, validação de origem de prefixo BGP
Rascunho da Internet draft-ietf-sidr-origin-validation-signaling-00, BGP Prefix Origin Validation State Extended Community (suporte parcial)
A comunidade estendida (estado de validação de origem) é apoiada na política de roteamento do Junos OS. A mudança especificada no procedimento de seleção de rota não é suportada.
Como funciona a validação da origem
O RPKI e a validação de origem utilizam certificados X.509 com extensões especificadas nas extensões RFC 3779, X.509 para endereços IP e identificadores AS.
O RPKI consiste em uma coleção distribuída de informações. Cada Autoridade de Certificação publica seus certificados de entidade final (EE), listas de revogação de certificados (CRLs) e objetos assinados em um local específico. Todos esses repositórios formam um conjunto completo de informações que está disponível para todos os servidores de cache RPKI.
Cada servidor de cache RPKI mantém um cache local de toda a coleta distribuída de repositórios sincronizando regularmente cada elemento no cache local em relação ao ponto de publicação original do repositório.
No roteador, as entradas de banco de dados são formatadas como registros de validação de rota (RV). Um registro de RV é um triplo (prefixo, comprimento máximo, origem AS). Ele corresponde a qualquer rota cujo prefixo corresponde ao prefixo de RV, cujo comprimento de prefixo não excede o comprimento máximo dado no registro de RV, e cuja origem AS é igual à origem COMO dada no registro de RV.
Um registro de RV é uma versão simplificada de uma autorização de origem de rota (ROA). Um ROA é um objeto assinado digitalmente que fornece um meio de verificar se um titular de bloco de endereço IP autorizou um AS a originar rotas para um ou mais prefixos dentro do bloco de endereços. Os ROAs não são usados diretamente na validação de rota. O servidor de cache exporta uma versão simplificada do ROA para o roteador como um registro de RV.
O valor máximo de comprimento deve ser maior ou igual ao comprimento do prefixo autorizado e menor do que ou igual ao comprimento (em bits) de um endereço IP na família de endereços (32 para IPv4 e 128 para IPv6). O comprimento máximo define o prefixo de endereço IP que o AS está autorizado a anunciar.
Por exemplo, se o prefixo de endereço IP for de 200,4,66/24, e o comprimento máximo for de 26, o AS está autorizado a anunciar 200,4,66,0/24, 200,4,66,0/25, 200,4,66,128/25, 200,4,66,0/26, 200,4,66,64/26, 200,4,66,128/26 e 200,46,192/26. Quando o comprimento máximo não estiver presente, o AS só está autorizado a anunciar exatamente o prefixo especificado no RV.
Como outro exemplo, um RV pode conter o prefixo 200.4.66/24 com um comprimento máximo de 26, bem como o prefixo 200.4.66.0/28 com um comprimento máximo de 28. Este RV autorizaria o AS a anunciar qualquer prefixo a partir de 200,4,66 com comprimento de pelo menos 24 e não superior a 26, bem como o prefixo específico 200.4.66.0/28.
A origem de uma rota é representada pelo número de AS mais correto no atributo AS_PATH. A validação de origem opera comparando a origem AS em uma atualização de roteamento com o AS de origem autorizado publicado em registros de RV.
A segurança fornecida pela validação de origem por si só é conhecida por ser fraca contra um invasor determinado porque não há proteção contra tal invasor spoofing do AS fonte. Dito isto, a validação de origem oferece proteção útil contra anúncios acidentais.
Embora a validação de origem possa ser implementada tendo cada roteador participando diretamente do RPKI, isso é visto como muito intensivo em recursos (porque muitas operações de criptografia de chave pública são necessárias para validar os dados RPKI) bem como operacionalmente intensivas para configurar e manter uma configuração RPKI em cada roteador. Por esse motivo, um servidor de cache RPKI separado realiza validações de chave pública e gera um banco de dados validado de mapeamentos de prefixo para AS. O banco de dados validado é baixado em um roteador cliente por uma conexão TCP segura. Assim, o roteador requer poucas informações sobre a infraestrutura RPKI e não tem requisitos de criptografia de chave pública, além da senha de transporte criptografada. Posteriormente, o roteador usa os dados baixados para validar as atualizações de rota recebidas.
Ao configurar sessões de servidor, você pode agrupar as sessões e configurar parâmetros de sessão para cada sessão no grupo. O roteador tenta periodicamente configurar um número máximo configurável de conexões para servidores de cache. Se a configuração da conexão falhar, uma nova tentativa de conexão é feita periodicamente.
Enquanto isso, após a política de importação de validação ser aplicada à sessão BGP, a validação de rota é realizada independentemente do estado de sessão de cache (para cima ou para baixo) e banco de dados de RV (vazio ou não). Se o banco de dados de RV estiver vazio ou nenhuma das sessões de servidor de cache estiver ativada, o estado de validação para cada rota será definido como desconhecido, porque não existe registro de RV para avaliar um prefixo BGP recebido.
O período de tentativa de nova tentativa é configurável. Depois de se conectar com sucesso a um servidor de cache, o roteador consulta o número de série do banco de dados mais recente e solicita que o cache RPKI transmita todas as entradas de RV pertencentes a essa versão do banco de dados.
Cada mensagem de entrada reinicia um temporizador de linha de entrada para o servidor de cache RPKI. Depois que todas as atualizações são aprendidas, o roteador realiza verificações de liveliness periódicas com base em um intervalo configurável. Isso é feito enviando uma unidade de dados de protocolo de consulta de série (PDU) com o mesmo número de série que o servidor de cache relatou em sua mais recente PDU de notificação. O servidor de cache responde com zero ou mais atualizações e uma PDU de fim de dados (EOD), que também atualiza o estado de livelines do servidor de cache e reinicia um temporizador de vida recorde.
Quando um prefixo é recebido de um peer BGP externo (EBGP), ele é analisado por uma política de importação e marcado como válido, inválido, desconhecido ou não verificado:
Válido — indica que o prefixo e o par AS são encontrados no banco de dados.
Inválido — indica que o prefixo foi encontrado, mas o AS correspondente recebido do peer EBGP não é o AS que aparece no banco de dados, ou o comprimento do prefixo na mensagem de atualização BGP é mais longo do que o comprimento máximo permitido no banco de dados.
Desconhecido — indica que o prefixo não está entre os prefixos ou intervalos de prefixo no banco de dados.
Não verificado — indica que a origem do prefixo não está verificada no banco de dados. Isso porque o banco de dados foi preenchido e a validação não é exigida na política de importação do BGP, embora a validação de origem esteja habilitada ou a validação de origem não esteja habilitada para os pares BGP.
Se houver alguma correspondência em potencial para a rota no banco de dados de validação, a rota precisa combinar com uma delas para ser válida. Caso contrário, é inválido. Qualquer correspondência é adequada para tornar a rota válida. Não precisa ser o melhor jogo. Somente se não houver correspondências potenciais é a rota considerada desconhecida. Para obter mais informações sobre a lógica do banco de dados de mapeamento prefixo para AS, consulte a Seção 2 do rascunho da Internet draft-ietf-sidr-pfx-validado-01, validação de origem de prefixo BGP.
A validação de RPKI está disponível apenas na instância primária. Se você configurar a validação de RPKI para uma instância de roteamento, a validação de RPKI falhará com a seguinte mensagem de erro.RV instance is not running
Interação do BGP com o banco de dados de validação de rotas
O banco de dados de validação de rota (RV) contém uma coleção de registros de RV que o roteador baixa do servidor de cache RPKI. Após o banco de dados de RV ser preenchido com registros de RV, o banco de dados de RV verifica a tabela de roteamento RIB-Local para determinar se há algum prefixo no RIB-Local que possa ser afetado pelos registros de RV no banco de dados. (RIB-Local contém as rotas IPv4 e IPv6 mostradas na saída do comando.)show route protocol bgp
Esse processo desencadeia uma reavaliação bgp de políticas de importação BGP (não políticas de exportação).
Figura 2 mostra o processo.
As políticas de importação são aplicadas à RIB-In. Outra maneira de entender isso é que as políticas de importação são aplicadas às rotas que são mostradas na saída do comando, enquanto as políticas de exportação são aplicadas a rotas que são mostradas pelo comando.show route receive-protocol bgp
show route advertising-protocol bgp
Como mostrado , você usa políticas de roteamento de importação para controlar quais rotas o BGP coloca na tabela de roteamento e políticas de roteamento de exportação para controlar quais rotas o BGP anuncia da tabela de roteamento para seus vizinhos.Figura 3
Quando você configura uma política de importação de validação de rota, a configuração da política usa uma condição de correspondência.validation-database
Essa condição de correspondência desencadeia uma consulta no banco de dados de RV para o estado de validação de um prefixo em uma determinada instância de roteamento. A operação padrão é consultar o banco de dados de validação correspondente à instância de roteamento. Se nenhuma instância de validação de rota for encontrada, a instância primária será consultada.
Na política de importação BGP a seguir, a condição desencadeia uma pesquisa no banco de dados de RV do roteador.from validation-database
Uma ação é tomada se o estado de validação for válido. A ação é aceitar a rota e definir a tabela de roteamento válida.validation-state
[edit protocols bgp] import validation;
[edit policy-options] policy-statement validation-1 { term valid { from { protocol bgp; validation-database valid; # Triggers a lookup in the RV database } then { validation-state valid; # Sets the validation state in the routing table accept; } } }
Atributo da comunidade para anunciar o estado de validação de RPKI aos vizinhos do IBGP
A validação de prefixo é feita apenas para atualizações externas do BGP (EBGP). Dentro de um AS, é provável que você não queira ter uma sessão de RPKI em execução em todos os roteadores BGP (IBGP) internos. Em vez disso, você precisa de uma maneira de transportar o estado de validação por toda a malha do IBGP para que todos os palestrantes do IBGP tenham informações consistentes. Isso é feito transportando o estado de validação em uma comunidade estendida não transitiva. O atributo da comunidade anuncia e recebe o estado de validação de um prefixo entre os vizinhos do IBGP.
O Junos OS oferece suporte às seguintes comunidades estendidas bem conhecidas para validação de rotas:
validação de origem-estado válido
inválido em estado de validação de origem
origem-validação-estado desconhecido
A política de importação BGP da amostra a seguir está configurada no roteador que tem uma sessão com um servidor RPKI.
Roteador com sessão RPKI
policy-statement validation-1 { term valid { from { protocol bgp; validation-database valid; } then { validation-state valid; community add origin-validation-state-valid; accept; } } }
A política de importação BGP da amostra a seguir está configurada em um roteador peer IBGP que não tem uma sessão com um servidor RPKI.
Roteador de peer IBGP sem sessão RPKI
policy-statement validation-2 { term valid { from community origin-validation-state-valid; then validation-state valid; } }
Validação ininterrupta de roteamento ativo e origem
Quando você configura a validação de origem em um roteador que tem mecanismos de roteamento duplos e o roteamento ativo ininterrupto é habilitado, tanto os mecanismos primários quanto os mecanismos de roteamento de espera têm uma cópia do banco de dados de RV. Esses dois bancos de dados de RV permanecem sincronizados entre si.
O roteador não mantém duas sessões idênticas com o servidor RPKI. O protocolo RPKI-RTR é executado apenas no mecanismo de roteamento primário. No mecanismo de roteamento de espera, a sessão do servidor de cache RPKI está sempre baixa.
O banco de dados de RV é mantido ativamente pelo mecanismo de roteamento primário por meio de sua sessão com o servidor RPKI. Este banco de dados é replicado no mecanismo de roteamento em standby. Embora a sessão esteja no standby Routing Engine, o banco de dados de RV replicado contém registros de RV. Quando o mecanismo de roteamento de espera se transforma e se torna o mecanismo de roteamento principal, ele já tem um banco de dados de RV totalmente preenchido.
Para visualizar o conteúdo dos dois bancos de dados, use e comandos.show validation database
show validation replication database
Marcando um intervalo de prefixo como nunca permitido
O modelo de validação de rota tem uma grande deficiência: Ele só fornece atualizações positivas. Ele pode declarar qual AS é o proprietário legítimo de um prefixo. No entanto, ela não pode transmitir explicitamente uma atualização negativa, como em: Este prefixo nunca foi originado por um determinado AS. Essa funcionalidade pode ser fornecida até certo ponto usando uma solução alternativa AS 0.
A implementação do Junos OS não tenta restringir suas entradas do cache. Por exemplo, um registro de RV com o as 0 de origem é instalado e combinado como qualquer outro. Isso permite uma solução alternativa para marcar um intervalo de prefixo, pois o AS 0 não é um AS válido. O AS no registro de RV nunca corresponde ao AS recebido do peer EBGP. Assim, qualquer prefixo correspondente é marcado como inválido.
Consulte também
Caso de uso e validação do benefício de origem para BGP
Se um administrador de um sistema autônomo (AS) começar a anunciar toda ou parte da rede atribuída de outra empresa, o BGP não tem um método integrado para reconhecer o erro e responder de uma maneira que evitaria interrupções de serviço.
Suponha, por exemplo, que um administrador em uma rede de clientes anuncie erroneamente uma rota (digamos 10.65.153.0/24) direcionando o tráfego para o provedor de serviços do cliente AS 1. Esta rota /24 é uma rota mais específica do que a usada pelo provedor de conteúdo real (10.65.152.0/22) que direciona o tráfego para AS 2. Devido à maneira como os roteadores funcionam, a maioria dos roteadores seleciona a rota mais específica e envia tráfego para AS 1 em vez de AS 2.
O prefixo seqüestrado é visto amplamente em toda a Internet à medida que os roteadores de trânsito propagam as informações de caminho atualizadas. As rotas inválidas podem ser distribuídas amplamente pela Internet, pois os roteadores da zona livre padrão (DFZ) transportam a rota seqüestrada. Eventualmente, o caminho de AS correto é restaurar para os pares BGP, mas, enquanto isso, espera-se que as interrupções de serviços sejam esperadas.
Como o BGP depende de um modelo de confiança transitivo, a validação entre o cliente e o provedor é importante. No exemplo acima, o provedor de serviços AS 1 não validou o anúncio defeituoso para 10,65.153,0/24. Ao aceitar este anúncio e readvertê-lo para seus pares e provedores, o AS 1 estava propagando o caminho errado. Os roteadores que receberam essa rota do AS 1 a selecionaram porque era uma rota mais específica. O provedor de conteúdo real estava anunciando 10.65.152.0/22 antes do erro ocorrer. O /24 era um anúncio menor (e mais específico). De acordo com o processo habitual de seleção de rotas BGP, o /24 foi então escolhido, completando efetivamente o seqüestro.
Mesmo com a detecção rápida e a reação do provedor de conteúdo e a cooperação com outros provedores, o serviço para seu prefixo pode ser interrompido por muitos minutos até várias horas. A duração exata da interrupção depende do seu ponto de vista na Internet. Quando esses tipos de eventos ocorrem, há um interesse renovado em soluções para essa vulnerabilidade. O BGP é fundamental para as relações com provedores e não desaparecerá tão cedo. Este exemplo demonstra uma solução que usa validação de origem. Essa solução conta com extensões criptográficas para BGP e um modelo de servidor de cliente distribuído que evita o excesso de limites de CPUs do roteador.
A validação de origem ajuda a superar a vulnerabilidade da confiança transitiva, permitindo que um provedor limite os anúncios que aceita de um cliente. A mecânica envolve a comunicação de políticas de roteamento com base em um atributo estendido da comunidade BGP.
Consulte também
Exemplo: Configuração da validação de origem para BGP
Este exemplo mostra como configurar a validação de origem entre os pares BGP, garantindo que os anúncios de rota recebidos sejam enviados (originados) do sistema autônomo esperado (AS). Se o AS de origem for validado, uma política pode especificar que os prefixos são anunciados por sua vez.
Requisitos
Este exemplo tem os seguintes requisitos de hardware e software:
-
Servidor de cache de infraestrutura de chave pública de recursos (RPKI), usando software de terceiros para autenticar prefixos BGP.
-
Junos OS Release 12.2 ou posterior no dispositivo de roteamento que se comunica com o servidor de cache por uma conexão TCP.
Visão geral
Às vezes, as rotas são anunciadas involuntariamente devido a erro do operador. Para evitar esse problema de segurança, você pode configurar o BGP para validar o AS de origem e rejeitar esses anúncios inválidos. Esse recurso usa um servidor de cache para autenticar prefixos ou intervalos de prefixo.
As seguintes declarações de configuração permitem a validação AS de origem:
[edit routing-options] validation { group group-name { max-sessions number; session address { hold-time seconds; local-address local-ip-address; port port-number; preference number; record-lifetime seconds; refresh-time seconds; traceoptions { file filename <files number> <size size> <(world-readable | no-world-readable)>; flag flag { disable; flag-modifier; } } } static { record destination { maximum-length prefix-length { origin-autonomous-system as-number { validation-state (invalid | valid); } } } } traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag { disable; flag-modifier; } } }
Este exemplo usa configurações padrão para os parâmetros de validação.
A maioria das declarações de configuração disponíveis são opcionais. As configurações necessárias são as seguintes:
validation { group group-name { session address { } } }
O nível de hierarquia permite configurar registros estáticos em um dispositivo de roteamento, substituindo assim os registros recebidos de um servidor de cache RPKI.[edit routing-options validation static]
Por exemplo:
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
Você pode configurar uma política de roteamento que opera com base no estado de validação de um prefixo de rota. Você pode usar um atributo da comunidade para anunciar e receber o estado de validação de um prefixo entre os pares BGP (EBGP) externos e BGP interno (IBGP). Usar uma política de roteamento pode ser mais conveniente em alguns roteadores do que configurar uma sessão com um servidor RPKI. Este exemplo demonstra o uso do atributo da comunidade de estado de validação entre os pares do IBGP.
Figura 4 mostra a topologia da amostra.
Neste exemplo, o Dispositivo R0 tem uma conexão IBGP com o dispositivo R1 e uma conexão EBGP com o dispositivo R2. O R0 do dispositivo recebe registros de validação de rota (RV) do servidor de cache usando o protocolo definido no rascunho da Internet draft-ietf-sidr-rpki-rtr-19, O Protocolo RPKI/Roteador para enviar os registros de RV. O protocolo RPKI-Router ultrapassa o TCP. Os registros de RV são usados pelo Dispositivo R0 para construir um banco de dados local de RV. No Dispositivo R1, o estado de validação é definido com base na comunidade BGP chamada estado de validação, que é recebida com a rota.
Configuração
- Configuração rápida da CLI
- Configuração do dispositivo R0
- Configuração do dispositivo R1
- Configuração do dispositivo R2
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de hierarquia.[edit]
Dispositivo R0
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 0 description to-R2 set interfaces ge-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 0 description to-cache set interfaces ge-1/2/2 unit 0 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 10.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 10.1.1.1 set protocols bgp group ext type external set protocols bgp group ext import validation set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65200 set protocols bgp group ext neighbor 10.0.0.6 set protocols ospf area 0.0.0.0 interface ge-1/2/0.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set policy-options policy-statement validation term valid from protocol bgp set policy-options policy-statement validation term valid from validation-database valid set policy-options policy-statement validation term valid then validation-state valid set policy-options policy-statement validation term valid then community add origin-validation-state-valid set policy-options policy-statement validation term valid then accept set policy-options policy-statement validation term invalid from protocol bgp set policy-options policy-statement validation term invalid from validation-database invalid set policy-options policy-statement validation term invalid then validation-state invalid set policy-options policy-statement validation term invalid then community add origin-validation-state-invalid set policy-options policy-statement validation term invalid then reject set policy-options policy-statement validation term unknown from protocol bgp set policy-options policy-statement validation term unknown then validation-state unknown set policy-options policy-statement validation term unknown then community add origin-validation-state-unknown set policy-options policy-statement validation term unknown then accept set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100 set routing-options validation group test session 10.0.0.10
Dispositivo R1
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 10.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement validation-ibgp term valid from community origin-validation-state-valid set policy-options policy-statement validation-ibgp term valid then validation-state valid set policy-options policy-statement validation-ibgp term invalid from community origin-validation-state-invalid set policy-options policy-statement validation-ibgp term invalid then validation-state invalid set policy-options policy-statement validation-ibgp term unknown from community origin-validation-state-unknown set policy-options policy-statement validation-ibgp term unknown then validation-state unknown set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100
Dispositivo R2
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set interfaces lo0 unit 0 family inet address 192.168.2.3/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65100 set protocols bgp group ext neighbor 10.0.0.5 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from protocol local set policy-options policy-statement send-direct then accept set routing-options autonomous-system 65200
Configuração do dispositivo R0
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar o dispositivo R0:
-
Configure as interfaces.
[edit interfaces] user@R0# set ge-1/2/0 unit 0 description to-R1 user@R0# set ge-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 0 description to-R2 user@R0# set ge-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 0 description to-cache user@R0# set ge-1/2/2 unit 0 family inet address 10.0.0.9/30 user@R0# set lo0 unit 0 family inet address 10.0.1.1/32
-
Configure BGP.
Aplique a política de exportação para que as rotas diretas sejam exportadas da tabela de roteamento para o BGP.
send-direct
Aplique a política de importação para definir os atributos de estado de validação e da comunidade BGP para todas as rotas importadas (ou recebidas) dos pares EBGP do Dispositivo R0.
validation
Configure uma sessão do IBGP com o Dispositivo R1. Configure uma sessão de EBGP com o dispositivo R2.
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 10.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 10.1.1.1 user@R0# set group ext type external user@R0# set group ext import validation user@R0# set group ext export send-direct user@R0# set group ext peer-as 65200 user@R0# set group ext neighbor 10.0.0.6
-
Configure o OSPF (ou outro protocolo de gateway interior [IGP]) na interface que enfrenta o peer IBGP e na interface de loopback.
Nota:Se você usar o endereço da interface de loopback na declaração do IBGP , você deve habilitar um IGP na interface de loopback.
neighbor
Caso contrário, a sessão do IBGP não está estabelecida.[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.0 user@R0# set interface lo0.0 passive
-
Configure a política de roteamento que exporta rotas diretas da tabela de roteamento para o BGP.
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
-
Configure a política de roteamento que especifica atributos a serem modificados com base no estado de validação de cada rota BGP.
[edit policy-options policy-statement validation] user@R0# set term valid from protocol bgp user@R0# set term valid from validation-database valid user@R0# set term valid then validation-state valid user@R0# set term valid then community add origin-validation-state-valid user@R0# set term valid then accept user@R0# set term invalid from protocol bgp user@R0# set term invalid from validation-database invalid user@R0# set term invalid then validation-state invalid user@R0# set term invalid then community add origin-validation-state-invalid user@R0# set term invalid then reject user@R0# set term unknown from protocol bgp user@R0# set term unknown then validation-state unknown user@R0# set term unknown then community add origin-validation-state-unknown user@R0# set term unknown then accept [edit policy-options] user@R0# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R0# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R0# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Configure a sessão com o servidor de cache RPKI.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
Configure o número do sistema autônomo (AS).
[edit routing-options] user@R0# set autonomous-system 65100
Resultados
A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfaces
show protocols
show policy-options
show routing-options
Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@R0# show interfaces ge-1/2/0 { unit 0 { description to-R1; family inet { address 10.0.0.2/30; } } } ge-1/2/1 { unit 0 { description to-R2; family inet { address 10.0.0.5/30; } } } ge-1/2/2 { unit 0 { description to-cache; family inet { address 10.0.0.9/30; } } } lo0 { unit 0 { family inet { address 10.0.1.1/32; } } }
user@R0# show protocols bgp { group int { type internal; local-address 10.0.1.1; export send-direct; neighbor 10.1.1.1; } group ext { type external; import validation; export send-direct; peer-as 65200; neighbor 10.0.0.6; } } ospf { area 0.0.0.0 { interface ge-1/2/0.0; interface lo0.0 { passive; } } }
user@R0# show policy-options policy-statement send-direct { from protocol direct; then accept; } policy-statement validation { term valid { from { protocol bgp; validation-database valid; } then { validation-state valid; community add origin-validation-state-valid; accept; } } term invalid { from { protocol bgp; validation-database invalid; } then { validation-state invalid; community add origin-validation-state-invalid; reject; } } term unknown { from protocol bgp; then { validation-state unknown; community add origin-validation-state-unknown; accept; } } } community origin-validation-state-invalid members 0x4300:0.0.0.0:2; community origin-validation-state-unknown members 0x4300:0.0.0.0:1; community origin-validation-state-valid members 0x4300:0.0.0.0:0; }
user@R0# show routing-options autonomous-system 65100; validation { group test { session 10.0.0.10; } }
Se você terminar de configurar o dispositivo, entre no modo de configuração.commit
Configuração do dispositivo R1
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar o dispositivo R1:
-
Configure as interfaces.
[edit interfaces] user@R1# set ge-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set lo0 unit 0 family inet address 10.1.1.1/32
-
Configure BGP.
Aplique a política de importação para definir os atributos do estado de validação e da comunidade BGP para todas as rotas recebidas dos pares do IBGP do Dispositivo R1.
validation-ibgp
Configure uma sessão do IBGP com o Dispositivo R0.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 10.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 10.0.1.1
-
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.0 user@R1# set interface lo0.0 passive
-
Configure a política de roteamento que especifica atributos a serem modificados com base no atributo da comunidade BGP de estado de validação das rotas BGP recebidas do Dispositivo R0.
[edit policy-options policy-statement validation-ibgp] user@R1# set term valid from community origin-validation-state-valid user@R1# set term valid then validation-state valid user@R1# set term invalid from community origin-validation-state-invalid user@R1# set term invalid then validation-state invalid user@R1# set term unknown from community origin-validation-state-unknown user@R1# set term unknown then validation-state unknown [edit policy-options] user@R1# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R1# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R1# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Configure o número do sistema autônomo (AS).
[edit routing-options] user@R1# set autonomous-system 65100
Resultados
A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfaces
show protocols
show policy-options
show routing-options
Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@R1# show interfaces ge-1/2/0 { unit 0 { family inet { address 10.0.0.1/30; } } } lo0 { unit 0 { family inet { address 10.1.1.1/32; } } }
user@R1# show protocols bgp { group int { type internal; local-address 10.1.1.1; import validation-ibgp; neighbor 10.0.1.1; } } ospf { area 0.0.0.0 { interface ge-1/2/0.0; interface lo0.0 { passive; } } }
user@R1# show policy-options policy-statement validation-ibgp { term valid { from community origin-validation-state-valid; then validation-state valid; } term invalid { from community origin-validation-state-invalid; then validation-state invalid; } term unknown { from community origin-validation-state-unknown; then validation-state unknown; } } community origin-validation-state-invalid members 0x4300:0.0.0.0:2; community origin-validation-state-unknown members 0x4300:0.0.0.0:1; community origin-validation-state-valid members 0x4300:0.0.0.0:0; }
user@R1# show routing-options autonomous-system 65100;
Se você terminar de configurar o dispositivo, entre no modo de configuração.commit
Configuração do dispositivo R2
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar o dispositivo R2:
-
Configure as interfaces.
Vários endereços estão configurados na interface de loopback para servir como rotas para fins de demonstração.
[edit interfaces] user@R2# set ge-1/2/0 unit 0 family inet address 10.0.0.6/30 user@R2# set lo0 unit 0 family inet address 172.16.1.1/32 user@R2# set lo0 unit 0 family inet address 192.168.2.3/32
-
Configure BGP.
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 65100 user@R2# set group ext neighbor 10.0.0.5
-
Configure a política de roteamento.
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
-
Configure o número do sistema autônomo (AS).
[edit routing-options] user@R2# set autonomous-system 65200
Resultados
A partir do modo de configuração, confirme sua configuração entrando no, e comandos.show interfaces
show protocols
show policy-options
show routing-options
Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@R2# show interfaces ge-1/2/0 { unit 0 { family inet { address 10.0.0.6/30; } } } lo0 { unit 0 { family inet { address 172.16.1.1/32; address 192.168.2.3/32; } } }
user@R2# show protocols bgp { group ext { export send-direct; peer-as 65100; neighbor 10.0.0.5; } }
user@R2# show policy-options policy-statement send-direct { from protocol [ direct local ]; then accept; }
user@R2# show routing-options autonomous-system 65200;
Se você terminar de configurar o dispositivo, entre no modo de configuração.commit
Verificação
Confirme se a configuração está funcionando corretamente.
- Verificando se os atributos modificados são exibidos nas tabelas de roteamento
- Usando operações de rastreamento
- Exibindo informações de validação
Verificando se os atributos modificados são exibidos nas tabelas de roteamento
Propósito
Verifique se as rotas BGP no Dispositivo R0 e no Dispositivo R1 têm os estados de validação esperados e as preferências locais esperadas.
Ação
A partir do modo operacional, entre no comando.show route
user@R0> show route inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.1.1/32 *[Direct/0] 04:53:39 > via lo0.1 10.1.1.1/32 *[OSPF/10] 04:50:53, metric 1 > to 10.0.0.1 via lt-1/2/0.2 10.0.0.0/30 *[Direct/0] 04:51:44 > via lt-1/2/0.2 10.0.0.2/32 *[Local/0] 04:51:45 Local via lt-1/2/0.2 10.0.0.4/30 *[Direct/0] 04:51:44 > via lt-1/2/0.5 [BGP/170] 02:24:57, localpref 100 AS path: 65200 I, validation-state: valid > to 10.0.0.6 via lt-1/2/0.5 10.0.0.5/32 *[Local/0] 04:51:45 Local via lt-1/2/0.5 10.0.0.8/30 *[Direct/0] 03:01:28 > via lt-1/2/0.9 10.0.0.9/32 *[Local/0] 04:51:45 Local via lt-1/2/0.9 172.16.1.1/32 *[BGP/170] 02:24:57, localpref 100 AS path: 65200 I, validation-state: invalid > to 10.0.0.6 via lt-1/2/0.5 192.168.2.3/32 *[BGP/170] 02:24:57, localpref 100 AS path: 65200 I, validation-state: validation-state: unknown > to 10.0.0.6 via lt-1/2/0.5 224.0.0.5/32 *[OSPF/10] 04:53:46, metric 1 MultiRecv
user@R1> show route inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1 AS path: 65200 I, validation-state: invalid > to 10.0.0.2 via lt-1/2/0.1 192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1 AS path: 65200 I, validation-state: unknown > to 10.0.0.2 via lt-1/2/0.1 224.0.0.5/32 *[OSPF/10] 04:57:09, metric 1 MultiRecv
Significado
As rotas têm os estados de validação esperados e os valores de preferência local, com base em informações recebidas do servidor de cache RPKI.
Usando operações de rastreamento
Propósito
Configure operações de rastreamento para validação de origem e monitore os resultados de uma rota recém-anunciada.
Ação
-
No dispositivo R0, configure o rastreamento.
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
-
No dispositivo R2, adicione uma rota adicionando outro endereço na interface de loopback.
[edit interfaces lo0 unit 0 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
-
No dispositivo R0, verifique o arquivo de rastreamento.
user@R0> file show /var/log/rv-tracing Jan 27 11:27:43.804803 rv_get_policy_state: rt 10.4.4.4/32 origin-as 65200, validation result valid Jan 27 11:27:43.944037 task_job_create_background: create prio 7 job Route-validation GC for task Route Validation Jan 27 11:27:43.986580 background dispatch running job Route-validation GC for task Route Validation Jan 27 11:27:43.987374 task_job_delete: delete background job Route-validation GC for task Route Validation Jan 27 11:27:43.987463 background dispatch completed job Route-validation GC for task Route Validation
Significado
A validação da rota está operando como esperado.
Exibindo informações de validação
Propósito
Execute os vários comandos de validação.
Ação
user@R0> show validation statistics Total RV records: 2 Total Replication RV records: 2 Prefix entries: 2 Origin-AS entries: 2 Memory utilization: 9789 bytes Policy origin-validation requests: 114 Valid: 32 Invalid: 54 Unknown: 28 BGP import policy reevaluation notifications: 156 inet.0, 156 inet6.0, 0
user@R0> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation group master Group: test, Maximum sessions: 2 Session 10.0.0.10, State: Connect, Preference: 100
user@R0> show validation session Session State Flaps Uptime #IPv4/IPv6 records 10.0.0.10 Up 0 00:02:28 1/0
user@R0> request validation policy Enqueued 2 IPv4 records Enqueued 0 IPv6 records