Distribuição de estado do enlace usando BGP
Distribuição de estado do link usando visão geral do BGP
- Função de um protocolo de gateway interior
- Limitações de um protocolo de gateway interior
- Necessidade de abranger a distribuição do estado do enlace
- Usando o BGP como solução
- Recursos suportados e sem suporte
- Extensões de estado de enlace BGP para roteamento de pacotes de origem em redes (SPRING)
- Verificando o nó NLRI aprendido através do BGP com OSPF como IGP
- Verificando o Prefix NLRI aprendido através do BGP com OSPF como IGP
Função de um protocolo de gateway interior
Um protocolo de gateway interior (IGP) é um tipo de protocolo usado para a troca de informações de roteamento entre dispositivos dentro de um sistema autônomo (AS). Com base no método de computação do melhor caminho para um destino, os IGPs são divididos em duas categorias:
Protocolos de estado de enlace — Anuncie informações sobre a topologia de rede (links conectados diretamente e o estado desses links) a todos os roteadores usando endereços multicast e atualizações de roteamento acionadas até que todos os roteadores que executam o protocolo de estado do link tenham informações idênticas sobre a internet. O melhor caminho para um destino é calculado com base em restrições como atraso máximo, largura de banda disponível mínima e afinidade de classe de recursos.
OSPF e IS-IS são exemplos de protocolos de estado de enlace.
Protocolos de vetor de distância — Anuncie informações completas da tabela de roteamento para vizinhos conectados diretamente usando um endereço de broadcast. O melhor caminho é calculado com base no número de saltos para a rede de destino.
O RIP é um exemplo de um protocolo de vetor de distância.
Como o nome indica, a função de um IGP é fornecer conectividade de roteamento dentro ou interna de um determinado domínio de roteamento. Um domínio de roteamento é um conjunto de roteadores sob controle administrativo comum que compartilham um protocolo de roteamento comum. Um AS pode consistir em vários domínios de roteamento, onde o IGP funciona para anunciar e aprender prefixos de rede (rotas) de roteadores vizinhos para construir uma tabela de rotas que, em última análise, contém entradas para todas as fontes de acessibilidade de publicidade para um determinado prefixo. O IGP executa um algoritmo de seleção de rotas para selecionar o melhor caminho entre o roteador local e cada destino, e fornece conectividade completa entre os roteadores que compõem um domínio de roteamento.
Além de anunciar a acessibilidade interna da rede, os IGPs são frequentemente usados para anunciar informações de roteamento externas ao domínio de roteamento do IGP por meio de um processo conhecido como redistribuição de rotas. A redistribuição de rotas é o processo de troca de informações de roteamento entre protocolos de roteamento distintos para unir vários domínios de roteamento quando a conectividade intra-AS é desejada.
Limitações de um protocolo de gateway interior
Embora cada IGP individual tenha suas próprias vantagens e limitações, as maiores limitações do IGP em geral são o desempenho e a escalabilidade.
Os IGPs foram projetados para lidar com a tarefa de adquirir e distribuir informações de topologia de rede para fins de engenharia de tráfego. Embora esse modelo tenha servido bem, os IGPs têm limitações de escalação inerentes quando se trata de distribuir grandes bancos de dados. Os IGPs podem autodetectar vizinhos, com os quais eles adquirem informações de topologia de rede intraárea. No entanto, o banco de dados de estado de link ou um banco de dados de engenharia de tráfego tem o escopo de uma única área ou AS, limitando assim aplicativos, como a engenharia de tráfego de ponta a ponta, o benefício de ter visibilidade externa para tomar melhores decisões.
Para redes comutada por rótulos, como MPLS e MPLS generalizada (GMPLS), a maioria das soluções de engenharia de tráfego existentes funcionam em um único domínio de roteamento. Essas soluções não funcionam quando uma rota do nó de entrada até o nó de saída deixa a área de roteamento ou AS do nó de entrada. Nesses casos, o problema de computação de caminhos se torna complicado devido à indisponibilidade das informações completas de roteamento em toda a rede. Isso ocorre porque os provedores de serviços geralmente optam por não vazar informações de roteamento além da área de roteamento ou AS para obter restrições de escalabilidade e preocupações de confidencialidade.
Necessidade de abranger a distribuição do estado do enlace
Uma das limitações do IGP é sua incapacidade de abranger a distribuição de estado de enlace fora de uma única área ou AS. No entanto, abranger as informações de estado de enlace adquiridas por um IGP em várias áreas ou ASs tem as seguintes necessidades:
Computação de caminhoSP — essas informações são usadas para computar o caminho para LSPs MPLS em vários domínios de roteamento, por exemplo, um LSP TE interárea.
Entidades externas de computação de caminhos — Entidades externas de computação de caminhos, como a Otimização de tráfego de camada de aplicativos (ALTO) e elementos de computação de caminho (PCE), executam computação de caminhos baseadas na topologia de rede e no estado atual das conexões dentro da rede, incluindo informações de engenharia de tráfego. Essas informações normalmente são distribuídas por IGPs dentro da rede.
No entanto, como as entidades de computação de caminho externo não conseguem extrair essas informações dos IGPs, elas executam monitoramento de rede para otimizar os serviços de rede.
Usando o BGP como solução
Visão geral
Para atender às necessidades de distribuição de estado de enlace em vários domínios, é necessário um protocolo de gateway exterior (EGP) para coletar informações de estado de enlace e engenharia de tráfego de uma área de IGP, compartilhá-la com componente externo e usá-la para caminhos de computação para interdomain MPLS LSPs.
BGP é um EGP padronizado projetado para trocar informações de roteamento e acessibilidade entre sistemas autônomos (ASs). O BGP é um protocolo comprovado que tem propriedades de escalonamento melhores porque pode distribuir milhões de entradas (por exemplo, prefixos vpn) de forma escalável. O BGP é o único protocolo de roteamento em uso hoje adequado para transportar todas as rotas da Internet. Isso ocorre em grande parte porque o BGP é executado em cima do TCP e pode fazer uso do controle de fluxo de TCP. Por outro lado, os protocolos de gateway interno (IGPs) não têm controle de fluxo. Quando os IGPs têm muitas informações de rota, eles começam a agitar. Quando o BGP tem um alto-falante vizinho que está enviando informações muito rapidamente, o BGP pode reduzir o vizinho atrasando os reconhecimentos do TCP.
Outro benefício do BGP é que ele usa tuples de tipo, comprimento, valor (TLV) e informações de acessibilidade de camada de rede (NLRI) que fornecem extensibilidade aparentemente infinita sem a necessidade de que o protocolo subjacente seja alterado.
A distribuição de informações de estado de enlace entre domínios é regulamentada usando políticas para proteger os interesses do provedor de serviços. Isso requer um controle sobre a distribuição de topologia usando políticas. O BGP com sua estrutura de política implementada serve bem na distribuição de rotas entre domínios. No Junos OS, o BGP é completamente orientado por políticas. O operador deve configurar explicitamente os vizinhos para peer com e aceitar rotas explicitamente para o BGP. Além disso, a política de roteamento é usada para filtrar e modificar informações de roteamento. Assim, as políticas de roteamento oferecem controle administrativo completo sobre as tabelas de roteamento.
Embora, dentro de um AS, tanto o IGP-TE quanto o BGP-TE forneçam o mesmo conjunto de informações, o BGP-TE tem melhores características de escala que são herdadas do protocolo BGP padrão. Isso torna o BGP-TE uma escolha mais escalável para a aquisição de informações de topologia multiárea/multi-AS.
Ao usar o BGP como solução, as informações adquiridas pelo IGP são usadas para distribuição em BGP. Os ISPs podem expor essas informações seletivamente com outros ISPs, provedores de serviços e redes de distribuição de conteúdo (CDNs) por meio de peering BGP normal. Isso permite a agregação das informações adquiridas por IGP em várias áreas e ASs, de modo que uma entidade de computação de caminhos externos possa acessar as informações ouvindo passivamente um refletor de rota.
Implementação
No Junos OS, os IGPs instalam informações de topologia em um banco de dados chamado banco de dados de engenharia de tráfego. O banco de dados de engenharia de tráfego contém as informações agregadas de topologia. Para instalar informações de topologia de IGP no banco de dados de engenharia de tráfego, use a set igp-topology declaração de configuração nos [edit protocols isis traffic-engineering] níveis de hierarquia e [edit protocols ospf traffic-engineering] hierarquia. O mecanismo para distribuir informações de estado do enlace usando BGP inclui o processo de publicidade do banco de dados de engenharia de tráfego no BGP-TE (importação) e a instalação de entradas do BGP-TE no banco de dados de engenharia de tráfego (exportação).
A partir do Junos OS Release 20.4R1, você pode configurar a engenharia de tráfego IS-IS para armazenar informações de IPv6 no banco de dados de engenharia de tráfego (TED), além de endereços IPv4. O BGP-LS distribui essas informações como rotas do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0 usando as políticas de importação do banco de dados de engenharia de tráfego. Essas rotas são anunciadas aos pares BGP-TE como informações de acessibilidade de camada de rede (NLRI) com tipo, comprimento e valor (TLV) do roteador IPv6. Além das informações do IPv6, você pode se beneficiar da obtenção da topologia de rede completa no banco de dados de engenharia de tráfego.
ID da NLRI e confederação BGP-LS
A partir do Junos OS Release 23.1R1, o Junos OS permite que as informações de acessibilidade de camada de rede (NLRI) do BGP Link State (BGP-LS) carreguem o ID da confederação no TLV 512 quando a confederação BGP estiver habilitada. A NLRI leva a ID da confederação junto com o número do sistema autônomo membro (número AS) no TLV 517, conforme definido na RFC 9086. O módulo de banco de dados de engenharia de tráfego do Junos OS faz alterações necessárias para codificar o ID da confederação e o número AS do membro no TLV 512 e TLV 517, respectivamente, ao mesmo tempo em que origina o BGP-LS NLRI (que é injetado na tabela de roteamento lsdist.0). Em lançamentos antes do Junos OS Release 23.1R1, o BGP-LS NLRI transporta apenas o número AS do membro no TLV 512 e a ID da confederação não está codificada na tabela de roteamento lsdist.0.
Importação de banco de dados de engenharia de tráfego
Para anunciar o banco de dados de engenharia de tráfego em BGP-TE, as entradas de link e nó no banco de dados de engenharia de tráfego são convertidas na forma de rotas. Essas rotas convertidas são então instaladas pelo banco de dados de engenharia de tráfego em nome do IGP correspondente, em uma tabela de roteamento visível do usuário chamada lsdist.0, em condições sujeitas a políticas de rota. O procedimento de vazamento de entradas do banco de dados lsdist.0 de engenharia de tráfego é chamado de importação de banco de dados de engenharia de tráfego, conforme ilustrado em Figura 1.
Há policiais para governar o processo de importação de banco de dados de engenharia de tráfego. Por padrão, não há vazamento de entradas do banco de dados de engenharia de tráfego na lsdist.0 tabela.
A partir do Junos OS Release 17.4R1, o banco de dados de engenharia de tráfego instala informações de topologia de protocolo de gateway interior (IGP), além de informações de topologia RSVP-TE na tabela de roteamento lsdist.0 conforme ilustrado em Figura 1. Antes do Junos OS Release 17.4R1, o banco de dados de engenharia de tráfego exportava apenas informações de topologia RSVP-TE. Agora você pode monitorar as informações de topologia de IGP e engenharia de tráfego. O BGP-LS lê as entradas IGP do lsdist.0 e anuncia essas entradas para os pares BGP. Para importar informações de topologia de IGP para BGP-LS do lsdist.0, use a set bgp-ls declaração de configuração no nível hierárquico [edit protocols mpls traffic-engineering database import igp-topology] .
Exportação de banco de dados de engenharia de tráfego
O BGP pode ser configurado para exportar ou anunciar rotas a lsdist.0 partir da tabela, sujeito à política. Isso é comum para qualquer tipo de origem de rota no BGP. Para anunciar o BGP-TE no banco de dados de engenharia de tráfego, o BGP precisa ser configurado com a família de endereços BGP-TE e uma política de exportação que seleciona rotas para redistribuição em BGP.
O BGP então propaga essas rotas como qualquer outro NLRI. Os pares BGP que tiverem a família BGP-TE configurada e negociada recebem NLRIs BGP-TE. O BGP armazena as NLRIs BGP-TE recebidas na forma de rotas na lsdist.0 tabela, que é a mesma tabela que armazena rotas BGP-TE originadas localmente. As rotas instaladas no lsdist.0 BGP são então distribuídas para outros pares, como qualquer outra rota. Assim, o procedimento padrão de seleção de rotas se aplica às NLRIs BGP-TE recebidas de vários alto-falantes.
Para alcançar o TE interdomínio, as rotas estão sendo divulgadas no lsdist.0 banco de dados de engenharia de tráfego por meio de uma política. Esse processo é chamado de exportação de banco de dados de engenharia de tráfego, conforme ilustrado em Figura 1.
Há policiais para governar o processo de exportação de banco de dados de engenharia de tráfego. Por padrão, nenhuma entrada é divulgada da tabela no banco de lsdist.0 dados de engenharia de tráfego.
A partir do Junos OS Release 22.4R1, você pode distribuir as políticas de engenharia de tráfego (TE) que se originam do protocolo de roteamento por segmentos para o banco de dados de engenharia de tráfego (TED) e para o estado de enlace BGP como rotas. O estado de enlace BGP coleta as informações relacionadas às políticas de TE para que os controladores externos possam realizar ações como computação de caminhos, re-otimização e visualização de rede dentro e entre domínios.
Configure para permitir que as políticas de roteamento set protocols source-packet-routing traffic-engineering database por segmentos (SR) sejam armazenadas no TED.
Para aplicativos SDN, como PCE e ALTO, as informações anunciadas pelo BGP-TE não podem vazar no banco de dados de engenharia de tráfego de um roteador. Nesses casos, um servidor externo que está em pares com os roteadores que usam BGP-TE é usado para mover as informações de topologia para o sistema sky/orquestração que abrange a rede. Esses servidores externos podem ser considerados como consumidores BGP-TE, onde recebem rotas BGP-TE, mas não os anunciam.
Atribuição de valores de credibilidade
Assim que as entradas forem instaladas no banco de dados de engenharia de tráfego, as informações aprendidas pelo BGP-TE serão disponibilizadas para computação de caminhos CSPF. O banco de dados de engenharia de tráfego usa um esquema de preferência de protocolo baseado em valores de credibilidade. Um protocolo com um valor de credibilidade mais alto é preferido em vez de um protocolo com menor valor de credibilidade. O BGP-TE tem a capacidade de anunciar informações aprendidas com vários protocolos ao mesmo tempo e, por isso, além das entradas instaladas em IGP no banco de dados de engenharia de tráfego, pode haver entradas instaladas no BGP-TE que correspondem a mais de um protocolo. O componente de exportação de banco de dados de engenharia de tráfego cria um protocolo de banco de dados de engenharia de tráfego e nível de credibilidade para cada protocolo que o BGP-TE oferece suporte. Esses valores de credibilidade são configuráveis na CLI.
A ordem de credibilidade para os protocolos BGP-TE é a seguinte:
-
Desconhecido — 80
-
OSPF — 81
-
Nível 1 do ISIS — 82
-
Nível 2 do ISIS — 83
-
Estático — 84
-
Direto — 85
Computação entre caminhos de credibilidade
Depois de atribuir valores de credibilidade, cada nível de credibilidade é tratado como um plano individual. O algoritmo De Caminho Curto Restringido Primeiro começa com a mais alta credibilidade atribuída aos mais baixos, encontrando um caminho dentro desse nível de credibilidade.
Com o BGP-TE, é essencial computar caminhos entre níveis de credibilidade para computar caminhos entre AS. Por exemplo, diferentes configurações de credibilidade são vistas em um dispositivo da área 0 que computa o caminho até a área 1, porque as entradas de área 0 são instaladas pelo OSPF, e as entradas de área 1 são instaladas pelo BGP-TE.
Para permitir a computação de caminhos em níveis de credibilidade, inclua a cross-credibility-cspf declaração nos edit protocols mplsníveis de hierarquia [edit protocols mpls label-switched-path lsp-name]e [edit protocols rsvp] . No nível hierárquicos [edit protocols rsvp] , permitindo cross-credibility-cspf que os impactos contornem os LSPs e a expansão de salto solto em trânsito.
A configuração cross-credibility-cspf permite a computação de caminhos em níveis de credibilidade usando o algoritmo De caminho mais curto limitado, no qual a restrição não é realizada em uma base de credibilidade por credibilidade, mas como uma única restrição ignorando os valores de credibilidade atribuídos.
NLRIs e TLVs BGP-TE
Como outras rotas BGP, as NLRIs BGP-TE também podem ser distribuídas por um refletor de rota que fala BGP-TE NLRI. O Junos OS implementa o suporte de reflexão de rota para a família BGP-TE.
A seguir, uma lista de NLRIs suportadas:
-
Link NLRI
-
NLRI de nós
-
PV4 Prefix NLRI (receber e propagar)
-
IPv6 Prefix NLRI (receber e propagar)
-
NLRI da política de TE
O Junos OS não oferece suporte para a forma de distinção de rota das NRLIs acima.
A seguir, uma lista de campos suportados em NLRIs de link e nós:
-
ID de protocolo — o NLRI se origina com os seguintes valores de protocolo:
-
ISIS-L1
-
ISIS-L2
-
OSPF
-
SPRING-TE
-
-
Identificador — Esse valor é configurável. Por padrão, o valor do identificador é definido para
0. -
Descrição de nós local/remoto — estes incluem:
-
Sistema autônomo
-
Identificador BGP-LS — Esse valor é configurável. Por padrão, o valor do identificador BGP-LS é definido para
0 -
ID da área
-
ID do roteador IGP
-
-
Descriptores de link (Somente para link NLRI)— Isso inclui:
-
Conecte identificadores locais/remotos
-
Endereço de interface IPv4
-
Endereço vizinho IPv4
-
Endereço vizinho/interface IPv6 — os endereços de interface e vizinhos IPv6 não são originados, mas apenas armazenados e propagados quando recebidos.
-
ID multi-topologia — esse valor não é originado, mas armazenado e propagado quando recebido.
-
A seguir, uma lista de TLVs de atributos LINK_STATE suportados:
-
Atributos do link:
-
Grupo administrativo
-
Largura de banda de enlace máximo
-
Máximo de largura de banda reservada
-
Largura de banda sem reservas
-
Métrica padrão de TE
-
SRLG
-
As TLVs a seguir, que não são originadas, mas apenas armazenadas e propagadas quando recebidas:
-
Atributos de enlaces opacos
-
Máscara de protocolo MPLS
-
Métrica
-
Tipo de proteção de enlaces
-
Atributo de nome do link
-
-
-
Atributos de nós:
-
ID do roteador IPv4
-
Bits de bandeira de nó — apenas o bit de sobrecarga está definido.
-
As TLVs a seguir, que não são originadas, mas apenas armazenadas e propagadas quando recebidas:
-
Multi-topologia
-
Propriedades de nós específicas do OSPF
-
Propriedades de nó opaco
-
Nome do nó
-
Identificador de área IS-IS
-
IPv6 Router-ID
-
-
Atributos de prefixo — essas TLVs são armazenadas e propagadas como qualquer outra TLVs desconhecidas.
-
Recursos suportados e sem suporte
O Junos OS oferece suporte aos seguintes recursos com distribuição de estado do link usando BGP:
Anúncio do recurso de encaminhamento garantido multiprotocol
Transmissão e recepção de nós e BGP de estado do link e NLRIs BGP-TE
Roteamento ativo sem parar para NLRIs BGP-TE
Políticas
O Junos OS oferece not suporte à seguinte funcionalidade para distribuição de estado de enlace usando BGP:
Topologias agregadas, links ou nós
Suporte de diferenciador de rotas para NLRIs BGP-TE
Identificadores multi-topologia
Identificadores de várias instâncias (excluindo a ID de instância padrão 0)
Anúncio da área de link e nó TLV
Anúncio de protocolos de sinalização MPLS
Importação de informações de nós e links com endereço sobreposto
Extensões de estado de enlace BGP para roteamento de pacotes de origem em redes (SPRING)
A partir do Junos OS Release 17.2R1, a família de endereços de estado de enlace BGP é estendida para distribuir o roteamento de pacotes de origem em informações de topologia de rede (SPRING) para controladores de redes definidas por software (SDN). O BGP normalmente aprende as informações de estado do link do IGP e as distribui para os pares BGP. Além do BGP, o controlador SDN pode obter informações de estado de enlace diretamente do IGP se o controlador fizer parte de um domínio IGP. No entanto, a distribuição de estado de enlace BGP fornece um mecanismo escalável para exportar as informações de topologia. As extensões de estado de enlace BGP para SPRING são suportadas em redes interdomain.
- Roteamento de pacotes de origem em redes (SPRING)
- Fluxo de dados SPRING do BGP Link-State
- Atributos e TLVs de estado do link BGP suportados e recursos não suportados para o estado do link BGP com SPRING
Roteamento de pacotes de origem em redes (SPRING)
SPRING é uma arquitetura de plano de controle que permite que um roteador de entrada guie um pacote através de um conjunto específico de nós e links na rede sem depender dos nós intermediários da rede para decidir o caminho real que deve tomar. A SPRING envolve IGPs, como IS-IS e OSPF, para segmentos de rede de publicidade. Os segmentos de rede podem representar qualquer instrução, topologia ou baseada em serviços. Dentro das topologias de IGP, os segmentos de IGP são anunciados pelos protocolos de roteamento de estado de enlace. Existem dois tipos de segmentos de IGP:
| Adjacency segment |
Um caminho de um salto sobre uma adjacência específica entre dois nós no IGP |
| Prefix segment |
Um caminho mais curto multi-hop, de igual custo e multicaminho para um prefixo, conforme o estado da topologia do IGP |
Quando a SPRING é habilitada em uma rede BGP, a família de endereços de estado de enlace BGP aprende as informações de SPRING dos protocolos de roteamento de estado de enlace IGP e anuncia segmentos na forma de identificadores de segmentos (SIDs). A família de endereços de estado de enlace BGP foi estendida para transportar SIDs e outras informações relacionadas à PRIMAVERA para os pares BGP. O refletor de rota pode direcionar um pacote através de um conjunto desejado de nós e links preparando o pacote com uma combinação apropriada de túneis. Esse recurso permite que a família de endereços de estado do link BGP também anuncie as informações de SPRING aos pares BGP.
Fluxo de dados SPRING do BGP Link-State
Figura 2 mostra o fluxo de dados dos dados spring de estado do link BGP que o IS-IS empurra para o banco de dados de engenharia de tráfego.
-
O IGP empurra os atributos SPRING para o banco de dados de engenharia de tráfego.
-
Recursos de SPRING e informações de algoritmos são levados adiante como atributos de nó no banco de dados de engenharia de tráfego.
-
As informações adjacentes de SID e LAN adjacentes são transportadas como atributos de link.
-
As informações de SID de prefixo ou nó-SID são realizadas como atributos de prefixo.
-
Um novo conjunto ou uma mudança nos atributos existentes desencadeia atualizações de IGP no banco de dados de engenharia de tráfego com novos dados.
CUIDADO:Se a engenharia de tráfego for desabilitada no nível IGP, nenhum dos atributos será empurrado para o banco de dados de engenharia de tráfego.
-
Todos os parâmetros da NLRI de engenharia de tráfego BGP, incluindo os descritores de link, nó e prefixo são derivados de entradas no banco de dados de engenharia de tráfego.
-
O banco de dados de engenharia de tráfego importa as entradas de rota na tabela de roteamento a
lsdist.0partir do IGP sujeito à política. -
A política padrão do BGP é exportar rotas, que são conhecidas apenas pelo BGP. Você configura uma política de exportação para rotas não BGP na
lsdis.0tabela de roteamento. Esta política anuncia uma entrada aprendida com o banco de dados de engenharia de tráfego.
Atributos e TLVs de estado do link BGP suportados e recursos não suportados para o estado do link BGP com SPRING
O estado de enlace BGP com SPRING oferece suporte aos seguintes atributos e tipos, comprimento e valores (TLVs) originados, recebidos e propagados na rede:
Node attributes
-
Recursos de roteamento por segmentos
-
Algoritmo de roteamento por segmentos
Link attributes
-
SID adjacente
-
LAN Adjacente-SID
Prefix descriptors
-
Informações de alcance IP
Prefix attributes
-
SID prefixo
A lista a seguir oferece suporte a TLVs que não são originadas, mas apenas recebidas e propagadas na rede:
Prefix descriptors
-
ID multitopologia
-
Tipo de rota OSPF
Prefix attributes
-
Gama
-
SID de ligação
O Junos OS não oferece suporte aos seguintes recursos com o estado de enlace BGP com extensões SPRING:
-
Origem do prefixo IPv6
-
Identificadores multitopologia
-
Exportação de banco de dados de engenharia de tráfego para parâmetros SPRING
-
Novas TLVs com tcpdump (TLVs existentes também não são suportadas).
-
PRIMAVERA sobre IPv6
Verificando o nó NLRI aprendido através do BGP com OSPF como IGP
A seguir, uma saída de amostra para verificar o nó NLRI aprendido por BGP com OSPF como IGP:
Propósito
Verifique as entradas da tabela de roteamento lsdist.0.
Ação
A partir do modo operacional, execute o show route table lsdist.0 comando.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced)
TSI:
LINK-STATE attribute handle 0x61d5da0
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State:<Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:22 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
Announcement bits (1): 0-TED Export
AS path: I
Accepted
Area border router: No
External router: No
Attached: No
Overload: No
SPRING-Capabilities:
- SRGB block [Start: 900000, Range: 90000, Flags: 0x00]
SPRING-Algorithms:
- Algo: 0
Localpref: 100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Significado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Verificando o Prefix NLRI aprendido através do BGP com OSPF como IGP
A seguir, uma saída de amostra para verificar o prefixo NLRI aprendido através do BGP com OSPF como IGP:
Propósito
Verifique as entradas da tabela de roteamento lsdist.0.
Ação
A partir do modo operacional, execute o show route table lsdist.0 comando.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:51 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
AS path: I
Accepted
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0
Localpref: 65100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Significado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Exemplo: Configuração da distribuição de estado do link usando BGP
Este exemplo mostra como configurar o BGP para transportar informações de estado de enlace em vários domínios, que é usado para caminhos de computação para LSPs MPLS que abrangem vários domínios, como o TE LSP entre áreas, e fornecendo um meio escalável e controlado por políticas para entidades externas de computação de caminhos, como ALTO e PCE, adquirirem topologia de rede.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
-
Quatro roteadores que podem ser uma combinação de roteadores série M, Série MX ou Série T
-
Junos OS Release 14.2 ou posterior em todos os roteadores
Antes de começar:
-
Configure as interfaces do dispositivo.
-
Configure os números do sistema autônomo e os IDs do roteador para os dispositivos.
-
Configure os seguintes protocolos:
-
RSVP
-
MPLS
-
BGP
-
IS-IS
-
OSPF
-
Visão geral
A partir do Junos OS Release 14.2, um novo mecanismo para distribuir informações de topologia em várias áreas e sistemas autônomos (ASs) é introduzido ao estender o protocolo BGP para transportar informações de estado do link, que foi inicialmente adquirida usando IGP. Os protocolos de IGP têm limitações de escala quando se trata de distribuir grandes bancos de dados. O BGP não é apenas um veículo mais escalável para transportar informações de topologia multiárea e multi-AS, mas também fornece os controles de políticas que podem ser úteis para a distribuição de topologia multi-AS. As informações de topologia de estado de enlace BGP são usadas para caminhos de computação para caminhos comutados por rótulos MPLS (LSPs) que abrangem vários domínios, como o TE LSP entre áreas, e fornecem um meio escalável e controlado por políticas para entidades externas de computação de caminhos, como ALTO e PCE, adquirirem topologia de rede.
Começando pelo Junos OS Release 17.1R1, a distribuição de estado do link usando BGP é suportada em switches QFX10000.
Topologia
Em Figura 3, os roteadores R0 e R1 e roteadores R2 e R3 pertencem a diferentes sistemas autônomos. Os roteadores R0 e R1 executam OSPF, e os roteadores R2 e R3 executam IS-IS.
Configuração
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com a configuração da sua rede, copiar e colar os comandos na CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Procedimento
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.
Para configurar o roteador R1:
-
Configure as interfaces R1 do roteador.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Configure a ID do roteador e o sistema autônomo do Roteador R1.
[edit routing-options]user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Habilite o RSVP em todas as interfaces do Roteador R1 (sem a interface de gerenciamento).
[edit protocols]user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Habilite o MPLS em todas as interfaces do Roteador R1 (sem a interface de gerenciamento).
[edit protocols]user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Configure o grupo BGP para o Roteador R1 para peer com o Roteador R0 e atribua o endereço local e o endereço vizinho.
[edit protocols]user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Inclua o BGP-TE sinalizando informações de alcance da camada de rede (NLRI) para o grupo BGP ibgp.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
Habilite a exportação de política nlri2bgp no Roteador R1.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
Configure o grupo BGP para o Roteador R1 para peer com o Roteador R2 e atribua o endereço local e o sistema autônomo vizinho ao grupo BGP ebgp.
[edit protocols]user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Inclua o BGP-TE sinalizando NLRI para o grupo BGP ebgp.
[edit protocols]user@R1# set bgp group ebgp family traffic-engineering unicast -
Habilite a engenharia de tráfego passiva no link entre AS.
[edit protocols]user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Habilite o OSPF na interface que conecta o Roteador R1 ao Roteador R0 e na interface de loopback do Roteador R1, e habilite recursos de engenharia de tráfego.
[edit protocols]user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Habilite a engenharia de tráfego passiva no link entre AS.
[edit protocols]user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Configure políticas para aceitar tráfego do BGP-TE NLRI.
[edit policy-options]user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Resultados
A partir do modo de configuração, confirme sua configuração entrando noshow interfaces, show routing-optionsshow protocolse show policy-options comandos. 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-0/0/0 {
unit 0 {
family inet {
address 10.8.31.103/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.102/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.141/32;
family iso {
address 47.0005.0102.5501.8181:00;
}
}
}
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.141;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.137;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
neighbor 10.8.42.104 {
local-address 10.8.42.102;
peer-as 65534;
}
}
}
isis {
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5502.4211;
remote-node-id 10.8.42.104;
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.104;
remote-node-router-id 10.255.105.139;
}
}
}
}
}
user@R1# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
Procedimento
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.
Para configurar o roteador R2:
-
Configure as interfaces R2 do roteador.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Configure a ID do roteador e o sistema autônomo do Roteador R2.
[edit routing-options]user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Habilite o RSVP em todas as interfaces do Roteador R2 (sem a interface de gerenciamento).
[edit routing-options]user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Habilite o MPLS em todas as interfaces do Roteador R2 (sem a interface de gerenciamento).
[edit routing-options]user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Habilite a importação de parâmetros de banco de dados de engenharia de tráfego usando a política ted2nlri.
[edit protocols]user@R2# set mpls traffic-engineering database import policy ted2nlri -
Configure o grupo BGP para o Roteador R2 para peer com o Roteador R3 e atribua o endereço local e o endereço vizinho.
[edit protocols]user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Inclua o BGP-TE sinalizando informações de alcance da camada de rede (NLRI) para o grupo BGP ibgp.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
Habilite a exportação de política nlri2bgp no Roteador R2.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
Configure o grupo BGP para o Roteador R2 para peer com o Roteador R1.
[edit protocols]user@R2# set bgp group ebgp type external -
Inclua o BGP-TE sinalizando NLRI para o grupo BGP ebgp.
[edit protocols]user@R2# set bgp group ebgp family traffic-engineering unicast -
Atribua o endereço local e o sistema autônomo vizinho ao grupo BGP do ebgp.
[edit protocols]user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Habilite a exportação de política nlri2bgp no Roteador R2.
[edit protocols]user@R2# set bgp group ebgp export nlri2bgp -
Habilite o IS-IS na interface que conecta o Roteador R2 com o Roteador R3 e a interface de loopback do Roteador R2.
[edit protocols]user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Habilite apenas a publicidade IS-IS na interface que conecta o Roteador R2 com o Roteador R1.
[edit protocols]user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Configure o recurso de engenharia de tráfego no Roteador R2.
[edit protocols]user@R2# set ospf traffic-engineering -
Habilite apenas anúncios OSPF na interface que conecta o Roteador R2 ao Roteador R1.
[edit protocols]user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Configure políticas para aceitar tráfego do BGP-TE NLRI.
[edit policy-options]user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Resultados
A partir do modo de configuração, confirme sua configuração entrando noshow interfaces, show routing-optionsshow protocolse show policy-options comandos. 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-0/0/0 {
unit 0 {
family inet {
address 10.8.64.104/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.104/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.139/32;
family iso {
address 47.0005.0102.5502.4211.00;
}
family iso;
}
}
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
traffic-engineering {
database {
import {
policy ted2nlri;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.139;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.135;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
export nlri2bgp;
peer-as 65533;
neighbor 10.8.42.102;
}
}
isis {
level 1 disable;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5501.8181;
remote-node-id 10.8.42.102;
}
}
interface lo0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.102;
remote-node-router-id 10.255.105.141;
}
}
}
}
}
user@R2# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
policy-statement ted2nlri {
term 1 {
from protocol [ isis ospf ];
then accept;
}
term 2 {
then reject;
}
}
Verificação
Verifique se a configuração está funcionando corretamente.
- Verificando o status do resumo do BGP
- Verificando o status do MPLS LSP
- Verificação das entradas da tabela de roteamento lsdist.0
- Verificação das entradas do banco de dados de engenharia de tráfego
Verificando o status do resumo do BGP
Propósito
Verifique se o BGP está funcionando nos roteadores R0 e R1.
Ação
A partir do modo operacional, execute o show bgp summary comando.
user@R0> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.255.105.141 65533 20 14 0 79 5:18 Establ
lsdist.0: 10/10/10/0A partir do modo operacional, execute o show bgp summary comando.
user@R1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.8.42.104 65534 24 17 0 70 6:43 Establ
lsdist.0: 10/10/10/0
10.255.105.137 65533 15 23 0 79 6:19 Establ
lsdist.0: 0/0/0/0Significado
O roteador R0 é peered com o Roteador R1.
Verificando o status do MPLS LSP
Propósito
Verifique a situação do MPLS LSP no roteador R0.
Ação
A partir do modo operacional, execute o show mpls lsp comando.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
O MPLS LSP do roteador R0 para o roteador R3 está estabelecido.
Verificação das entradas da tabela de roteamento lsdist.0
Propósito
Verifique as entradas da tabela de roteamento lsdist.0 nos roteadores R0, R1 e R2.
Ação
A partir do modo operacional, execute o show route table lsdist.0 comando.
user@R0> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:03, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0A partir do modo operacional, execute o show route table lsdist.0 comando.
user@R1> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:19, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0A partir do modo operacional, execute o show route table lsdist.0 comando.
user@R2> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[IS-IS/18] 1d 00:24:39
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[OSPF/10] 1d 00:24:39
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:58
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:02:34
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[OSPF/10] 00:20:57
FictitiousSignificado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Verificação das entradas do banco de dados de engenharia de tráfego
Propósito
Verifique as entradas do banco de dados de engenharia de tráfego no Roteador R0.
Ação
A partir do modo operacional, execute o show ted database comando.
user@R0> show ted database
TED database: 5 ISIS nodes 5 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0)
To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8181.00 --- 1033 1 0
0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
Exported OSPF(2)
To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1)
To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0)
To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0)
To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104
Local interface index: 0, Remote interface index: 0
To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0Significado
As rotas estão aparecendo no banco de dados de engenharia de tráfego.
Configuração da distribuição de estado do link usando BGP
Você pode habilitar a distribuição de informações de topologia em várias áreas e sistemas autônomos (ASs) estendendo o protocolo BGP para transportar informações de estado de enlace, que foi inicialmente adquirida usando IGP. Os protocolos de IGP têm limitações de escala quando se trata de distribuir grandes bancos de dados. O BGP não é apenas um veículo mais escalável para transportar informações de topologia multiárea e multi-AS, mas também fornece os controles de políticas que podem ser úteis para a distribuição de topologia multi-AS. As informações de topologia de estado de enlace BGP são usadas para caminhos de computação para LSPs MPLS que abrangem vários domínios, como o TE LSP entre áreas, e fornecem um meio escalável e controlado por políticas para entidades externas de computação de caminhos, como ALTO e PCE, adquirirem topologia de rede.
Antes de começar:
Configure as interfaces do dispositivo.
Configure a ID do roteador e o número do sistema autônomo para o dispositivo.
Configure os seguintes protocolos:
RSVP
MPLS
IS-IS
OSPF
Para habilitar a distribuição do estado do enlace usando o BGP:
Distribuição de estado do enlace usando SRv6
Extensões de estado de enlace BGP para SRv6
A partir do Junos OS Release 21.3R1, oferecemos suporte ao SRv6 no BGP-LS e no banco de dados de engenharia de tráfego (TED). As extensões BGP-LS exportam as informações de topologia SRv6 para os controladores SDN. Os controladores recebem as informações de topologia fazendo parte de um domínio IGP ou através do BGP-LS. O BGP LS fornece um mecanismo escalável para exportar as informações de topologia. Ele também pode ser usado para as redes inter domínio. Além disso, agora você pode filtrar o NLRI com base no prefixo IPv6 (SRv6 Locator) e SRv6 SID NLRI.
Fluxo de dados bgp link-state SRv6
O BGP LS recupera os dados de engenharia de tráfego (TE) do banco de dados te (TED) e os distribui para os alto-falantes BGP peer. Para isso, o TED converte seus links, nós e prefixos (IPv4 e IPv6) na forma de rotas. A figura a seguir mostra o fluxo de dados no BGP-LS.
-
Os atributos SRv6 trocados pelo IGP do ISIS agora são suportados no Junos, conforme descrito no padrão IETF [3].
-
Os atributos SRv6 são adicionados no banco de dados de engenharia de tráfego (TED).
-
Os atributos SRv6 aprendidos via ISIS IGP são armazenados no TED, pois nós e links são convertidos em rotas. Essas rotas são então submetidas à política de importação ted e, se a política permitir, estas estão instaladas em uma tabela de roteamento chamada lsdist.0.
-
O BGP pode ser configurado para "exportar" ou anunciar rotas a partir da tabela lsdist.0 sujeita à política. O BGP então propaga essas rotas como qualquer outro NLRI. Ou seja, os pares que têm a família BGP-LS configurada e negociada recebem NLRIs BGP-LS. O BGP armazena as NLRIs BGP-LS recebidas na forma de rotas na tabela "lsdist.0", que é a mesma tabela que armazena rotas BGP-LS originadas localmente. As informações de SRv6 recém-adicionadas são propagadas no BGP como atributos de NLRIs já existentes (Nós, Link e Prefixo) e um novo SRv6 Locator NLRI.
-
As NLRIs BGP-LS recebidas que estão instaladas na forma de rotas na tabela "lsdist.0" podem ser submetidas à política de exportação TED e, se a política permitir, os atributos SRv6 dessas rotas são adicionados na instância local do banco de dados TE.
Prefixos IPv6 e IPv6 Adjacency SIDs MPLS Suporte em banco de dados de engenharia de tráfego e BGP Link-State
Fizemos os seguintes aprimoramentos no IPv6.
- Suporte para a inclusão dos atributos e informações do IPv6 ao banco de dados de engenharia de tráfego (TED) do Sistema Intermediário ao Sistema Intermediário (IS-IS).
- Suporte para a importação de atributos IPv6 do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0.
- Suporte à exportação de atributos IPv6 para o BGP Link-State (BGP-LS).
- Suporte para as informações de alcance da camada de rede (NLRIs) BGP-LS IPv6 e a exportação de atributos da tabela de roteamento lsdist.0 para o banco de dados de engenharia de tráfego.
Oferecemos suporte apenas ao protocolo de gateway interior IS-IS (IGP).
- Benefícios dos prefixos IPv6 e suporte a SID MPLS de Adjacência IPv6 no banco de dados de engenharia de tráfego e BGP-LS
- Implementação
- Suporte para adicionar os atributos e informações IPv6 ao banco de dados de engenharia de tráfego do IS-IS
- Suporte à importação de atributos IPv6 do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0
- Suporte à exportação de atributos IPv6 para BGP-LS
- Suporte para BGP-LS IPv6 NLRIs e atributos Exportação da tabela de roteamento lsdist.0 para banco de dados de engenharia de tráfego
- Comando de configuração
Benefícios dos prefixos IPv6 e suporte a SID MPLS de Adjacência IPv6 no banco de dados de engenharia de tráfego e BGP-LS
Aprimoramos as saídas dos comandos operacionais existentes e adicionamos os comandos de exibição para exibir a lista de prefixos IPv6 e IPv4, respectivamente, no banco de dados de engenharia de tráfego.
show ted database extensive— Melhorou a saída para incluir os atributos IPv6 de roteamento por segmentos (SR)-MPLS.show ted link detail— Melhorou a saída para incluir os atributos IPv6 SR-MPLS correspondentes aos links de banco de dados de engenharia de tráfego.show route table lsdist.0 [extensive | detail]— Melhorou a saída para incluir os atributos IPv6 NLRIs e IPv6 SR-MPLS.show route— Incluímos parâmetros adicionais para filtrar entradas para visualização na tabela lsdist.0. Adicionamos opções adicionais para incluir prefixos IPv6. As opções sãote-ipv6-prefix-ipv6-addr...te-ipv6-prefix-node-isoshow ted ipv6-prefix— Adicionou o comando de exibição da lista de prefixos IPv6 no banco de dados de engenharia de tráfego.show ted ipv4-prefix— Adicionou o comando de exibição da lista de prefixos IPv4 no banco de dados de engenharia de tráfego.
Implementação
O BGP-LS recupera os dados de engenharia de tráfego (TE) do banco de dados de engenharia de tráfego e distribui os dados para seus pares BGP. Para isso, o banco de dados de engenharia de tráfego converte suas entradas de links, nós e prefixo (IPv4 e IPv6) na forma de rotas. A figura a seguir mostra o fluxo de informações do BGP-LS e em direção ao BGP-LS.
Suporte para adicionar os atributos e informações IPv6 ao banco de dados de engenharia de tráfego do IS-IS
O Junos OS oferece suporte a atributos SR-MPLS para plano de dados IPv6, trocados pelo IS-IS IGP. Como resultado desse aprimoramento, atributos e informações do IPv6 podem ser adicionados ao Banco de Dados de Engenharia de Tráfego (TED).
Suporte à importação de atributos IPv6 do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0
Os atributos IPv6 recebidos do IS-IS IGP e armazenados no banco de dados de engenharia de tráfego como nós, links e prefixos são convertidos em rotas. Essas rotas são então submetidas à política de importação de banco de dados de engenharia de tráfego. Se a política permitir, as rotas serão instaladas em uma tabela de roteamento chamada lsdist.0.
Suporte à exportação de atributos IPv6 para BGP-LS
O BGP está configurado para exportar ou anunciar rotas a partir da tabela lsdist.0, sujeito à política. É um cenário roteamento para qualquer origem de rota no BGP. O BGP então propaga essas rotas como qualquer outro NLRI para os pares com a vizinhança BGP-LS configurada e estabelecida. O BGP armazena as NLRIs BGP-LS recebidas na forma de rotas na tabela lsdist.0, que é a mesma tabela que armazena rotas BGP-LS originadas localmente. Como resultado dessa funcionalidade, as informações IPv6 recém-adicionadas são propagadas para BGP como atributos do Enlace NLRI já existente, e como um novo IPv6 Prefix NLRI.
Suporte para BGP-LS IPv6 NLRIs e atributos Exportação da tabela de roteamento lsdist.0 para banco de dados de engenharia de tráfego
No Junos OS, as NLRIs BGP-LS recebidas instaladas na forma de rotas na tabela lsdist.0 são submetidas à política de exportação de banco de dados de engenharia de tráfego. Se a política permitir, os atributos IPv6 e as informações dessas rotas serão adicionados à instância local do banco de dados de engenharia de tráfego.
Comando de configuração
O comando de política BGP-TE é aprimorado para permitir a filtragem de NLRIs com base no NLRI de prefixo IPv6. Veja ipv6-prefix.
Consulte também
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.