Distribuição de estado de enlace usando BGP
Distribuição de estado de enlace usando a visão geral do BGP
- Função de um protocolo de gateway interior
- Limitações de um protocolo de gateway interior
- Necessidade de distribuição de estado de enlace abrangente
- Usando o BGP como uma solução
- Recursos com e sem suporte
- Extensões de estado de enlace BGP para roteamento de pacotes de origem em redes (SPRING)
- Verificando o nó NLRI aprendido por meio do BGP com OSPF como IGP
- Verificando o prefixo NLRI aprendido por meio de BGP com OSPF como IGP
Função de um protocolo de gateway interior
Um interior gateway protocol (IGP) é um tipo de protocolo usado para trocar informações de roteamento entre dispositivos dentro de um sistema autônomo (AS). Com base no método de cálculo do melhor caminho para um destino, os IGPs são divididos em duas categorias:
-
Protocolos de estado do enlace — Anunciam informações sobre a topologia da rede (links diretamente conectados e o estado desses enlaces) para 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 enlace tenham informações idênticas sobre o conjunto de redes. O melhor caminho para um destino é calculado com base em restrições como atraso máximo, largura de banda mínima disponível e afinidade de classe de recurso.
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.
RIP é um exemplo de protocolo de vetor de distância.
Como o nome indica, a função de um IGP é fornecer conectividade de roteamento dentro ou dentro 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 que anunciam a acessibilidade de um determinado prefixo. O IGP executa um algoritmo de seleção de rota para selecionar o melhor caminho entre o roteador local e cada destino, e fornece conectividade total entre os roteadores que compõem um domínio de roteamento.
Além de anunciar a acessibilidade da rede interna, os IGPs são frequentemente usados para anunciar informações de roteamento externas ao domínio de roteamento desse 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 desempenho e escalabilidade.
Os IGPs são 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 funcionado bem, os IGPs têm limitações de escalabilidade inerentes quando se trata de distribuir grandes bancos de dados. Os IGPs podem detectar automaticamente vizinhos, com os quais adquirem informações de topologia de rede intraárea. No entanto, o banco de dados de estado de enlace ou um banco de dados de engenharia de tráfego tem o escopo de uma única área ou AS, limitando assim as aplicações, como a engenharia de tráfego de ponta a ponta, o benefício de ter visibilidade externa para tomar melhores decisões.
Para redes com comutação de rótulos, como MPLS e MPLS generalizada (GMPLS), a maioria das soluções de engenharia de tráfego existentes funciona em um único domínio de roteamento. Essas soluções não funcionam quando uma rota do nó de entrada para o nó de saída deixa a área de roteamento ou AS do nó de entrada. Nesses casos, o problema de computação de caminho torna-se 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 restrições de escalabilidade e questões de confidencialidade.
Necessidade de distribuição de estado de enlace abrangente
Uma das limitações do IGP é sua incapacidade de abranger a distribuição de estado do enlace fora de uma única área ou AS. No entanto, a abrangência de informações de estado do enlace adquiridas por um IGP em várias áreas ou ASs tem as seguintes necessidades:
-
Computação de caminho LSP — Essas informações são usadas para calcular o caminho para LSPs MPLS em vários domínios de roteamento, por exemplo, um LSP TE inter-área.
-
Entidades de computação de caminho externo — entidades de computação de caminho externas, como ALTO (Otimização de Tráfego de Camada de Aplicativo) e Elementos de Computação de Caminho (PCE), executam cálculos de caminho com base na topologia da rede e no estado atual das conexões dentro da rede, incluindo informações de engenharia de tráfego. Essas informações são normalmente distribuídas por IGPs dentro da rede.
No entanto, como as entidades de computação de caminhos externas não podem extrair essas informações dos IGPs, elas realizam o monitoramento da rede para otimizar os serviços de rede.
Usando o BGP como uma solução
Visão geral
Para atender às necessidades de abranger a distribuição de estado de enlace em vários domínios, um protocolo de gateway exterior (EGP) é necessário para coletar informações de estado de enlace e engenharia de tráfego de uma área de IGP, compartilhá-las com componentes externos e usá-las para caminhos de computação para LSPs MPLS entre domínios.
O 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 melhores propriedades de escalabilidade 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 que é adequado para transportar todas as rotas na Internet. Isso ocorre principalmente porque o BGP é executado sobre o TCP e pode fazer uso do controle de fluxo 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 se agitar. Quando o BGP tem um alto-falante vizinho que está enviando informações muito rapidamente, o BGP pode limitar o vizinho atrasando as confirmações de TCP.
Outro benefício do BGP é que ele usa tuplas de tipo, comprimento, valor (TLV) e informações de alcance de camada de rede (NLRI) que fornecem extensibilidade aparentemente infinita sem a necessidade de alterar o protocolo subjacente.
A distribuição de informações de estado do enlace entre domínios é regulada por 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íticas implementada, atua bem na distribuição de rotas entre domínios. No Junos OS, o BGP é totalmente orientado por políticas. O operador deve configurar explicitamente os vizinhos para emparelhar e aceitar explicitamente as rotas no BGP. Além disso, a política de roteamento é usada para filtrar e modificar as informações de roteamento. Assim, as políticas de roteamento fornecem 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 escalabilidade herdadas do protocolo BGP padrão. Isso torna o BGP-TE uma opção mais escalável para adquirir informações de topologia multiárea/multias.
Ao usar o BGP como solução, as informações adquiridas pelo IGP são usadas para distribuição no BGP. Os ISPs podem expor seletivamente essas informações 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 pelo IGP em várias áreas e ASs, de modo que uma entidade de computação de caminho externa 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] . O mecanismo para distribuir informações de estado do enlace usando o BGP inclui o processo de anunciar o banco de dados de engenharia de tráfego no BGP-TE (importação) e instalar entradas do BGP-TE no banco de dados de engenharia de tráfego (exportação).
Você pode configurar a engenharia de tráfego IS-IS para armazenar informações IPv6 no banco de dados de engenharia de tráfego (TED), além dos endereços IPv4. BGP-LS distribui essas informações como rotas do banco de dados de engenharia de tráfego para o lsdist.0 tabela de roteamento 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 alcance de camada de rede (NLRI) com tipo, comprimento e valor de ID de roteador IPv6 (TLV). Com a adição das informações IPv6, você pode se beneficiar da obtenção da topologia de rede completa no banco de dados de engenharia de tráfego.
de estado de enlace BGP
BGP-LS NLRI e ID da confederação
O Junos OS permite que as informações de alcance da camada de rede (NLRI) do estado do enlace BGP (BGP-LS) carreguem o ID de confederação no TLV 512 quando a confederação BGP está habilitada. O NLRI carrega o ID da confederação junto com o número do sistema autônomo do membro (número AS) no TLV 517, conforme definido no RFC 9086. O módulo de banco de dados de engenharia de tráfego do Junos OS faz as mudanças necessárias para codificar o ID da confederação e o número AS do membro em TLV 512 e TLV 517, respectivamente, enquanto origina o NLRI BGP-LS (que é injetado na tabela de roteamento lsdist.0). Em versões anteriores ao Junos OS Release 23.1R1, o BGP-LS NLRI transporta apenas o número AS do membro no TLV 512 e o ID da confederação não é codificado 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 no 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 ao usuário chamada lsdist.0, em condições sujeitas a políticas de rota. O procedimento de vazamento de entradas do banco de dados de engenharia de tráfego é lsdist.0 chamado de importação de banco de dados de engenharia de tráfego, conforme ilustrado na Figura 1.
Há políticas para governar o processo de importação do banco de dados de engenharia de tráfego. Por padrão, nenhuma entrada é vazada do banco de dados de engenharia de tráfego para a lsdist.0 tabela.
O banco de dados de engenharia de tráfego instala informações de topologia do interior gateway protocol (IGP), além das informações de topologia RSVP-TE na tabela de roteamento lsdist.0, conforme ilustrado na Figura 1. Você pode monitorar as informações de topologia de engenharia de tráfego e IGP. O BGP-LS lê IGP entradas de lsdist.0 e anuncia essas entradas para os pares BGP. Para importar informações de topologia de IGP para o [edit protocols mpls traffic-engineering database import igp-topology] BGP-LS de lsdist.0, use a set bgp-ls declaração de configuração no nível de hierarquia.
Exportação de banco de dados de engenharia de tráfego
O BGP pode ser configurado para exportar ou anunciar rotas da lsdist.0 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 selecione rotas para redistribuição no BGP.
O BGP então propaga essas rotas como qualquer outro NLRI. Os peers BGP que têm a família BGP-TE configurada e negociada recebem NLRIs BGP-TE. O BGP armazena os NLRIs BGP-TE recebidos na forma de rotas na lsdist.0 tabela, que é a mesma tabela que armazena as rotas BGP-TE originadas localmente. As rotas instaladas no lsdist.0 BGP são então distribuídas para outros peers como qualquer outra rota. Assim, o procedimento de seleção de rota padrão se aplica a NLRIs BGP-TE recebidos de vários alto-falantes.
Para alcançar o TE entre domínios, as rotas lsdist.0 são vazadas para o 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 na Figura 1.
Há políticas para controlar o processo de exportação do banco de dados de engenharia de tráfego. Por padrão, nenhuma entrada é vazada da tabela para o banco de dados de engenharia de lsdist.0 tráfego.
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 do enlace BGP coleta as informações relacionadas às políticas de TE, para que os controladores externos possam executar ações como computação de caminho, re-otimização e visualização de rede dentro e entre domínios.
Configure set protocols source-packet-routing traffic-engineering database para permitir que as políticas de roteamento 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 para o banco de dados de engenharia de tráfego de um roteador. Nesses casos, um servidor externo que emparelha com os roteadores usando BGP-TE é usado para mover as informações de topologia para o sistema de céu/orquestração que abrange a rede. Esses servidores externos podem ser considerados consumidores BGP-TE, onde recebem rotas BGP-TE, mas não as anunciam.
Atribuindo valores de credibilidade
Depois que as entradas são instaladas no banco de dados de engenharia de tráfego, as informações aprendidas do BGP-TE são disponibilizadas para o cálculo do caminho 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 é preferível a um protocolo com um valor de credibilidade mais baixo. O BGP-TE tem a capacidade de anunciar informações aprendidas de vários protocolos ao mesmo tempo e, portanto, além das entradas instaladas pelo 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 um nível de credibilidade para cada protocolo compatível com o BGP-TE. 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
-
IS-IS Nível 1 — 82
-
IS-IS Nível 2 — 83
-
Estático - 84
-
Direto - 85
Computação de caminho de credibilidade cruzada
Depois de atribuir valores de credibilidade, cada nível de credibilidade é tratado como um plano individual. O algoritmo Constrained Shorted Path First começa com a credibilidade atribuída mais alta para a mais baixa, encontrando um caminho dentro desse nível de credibilidade.
Com o BGP-TE, é essencial calcular caminhos entre níveis de credibilidade para calcular caminhos inter-AS. Por exemplo, diferentes configurações de credibilidade são vistas em um dispositivo da área 0 que calcula o caminho pela área 1, porque as entradas da área 0 são instaladas pelo OSPF e as entradas da área 1 são instaladas pelo BGP-TE.
Para habilitar a computação de caminho entre níveis de credibilidade, inclua a cross-credibility-cspf edit protocols mplsinstrução nos níveis , [edit protocols mpls label-switched-path lsp-name]e [edit protocols rsvp] hierarquia. No nível da hierarquia, os [edit protocols rsvp] impactos de habilitação cross-credibility-cspf ignoram LSPs e soltam a expansão de saltos em trânsito.
A configuração cross-credibility-cspf permite a computação de caminho em níveis de credibilidade usando o algoritmo Constrained Shortest Path First, em que a restrição não é executada em uma base de credibilidade por credibilidade, mas como uma única restrição ignorando os valores de credibilidade atribuídos.
BGP-TE, NLRIs e TLVs
Como outras rotas BGP, os NLRIs BGP-TE também podem ser distribuídos por meio de um refletor de rota que fala BGP-TE NLRI. O Junos OS implementa o suporte à reflexão de rota para a família BGP-TE.
Veja a seguir uma lista de NLRIs compatíveis:
-
Link NLRI
-
NLRI do nó
-
Prefixo IPv4 NLRI (receber e propagar)
-
Prefixo IPv6 NLRI (receber e propagar)
-
Política de TE NLRI
O Junos OS não oferece suporte para a forma de distinção de rota dos NRLIs acima.
Veja a seguir uma lista de campos compatíveis em NLRIs de link e nó:
-
Protocol-ID — o NLRI se origina com os seguintes valores de protocolo:
-
IS-IS-L1
-
IS-IS-L2
-
OSPF
-
PRIMAVERA-TE
-
-
Identificador — Este valor é configurável. Por padrão, o valor do identificador é definido como
0. -
Descritor de nó local/remoto — incluem:
-
Sistema autônomo
-
Identificador BGP-LS — esse valor é configurável. Por padrão, o valor do identificador BGP-LS é definido como
0 -
ID de área
-
ID do roteador IGP
-
-
Descritores de link (somente para NLRI de link) — Isso inclui:
-
Vincular identificadores locais/remotos
-
Endereço da interface IPv4
-
Endereço de vizinho IPv4
-
Endereço de vizinho/interface IPv6 — Os endereços de vizinho e interface IPv6 não são originados, mas apenas armazenados e propagados quando recebidos.
-
ID de multitopologia — esse valor não é originado, mas armazenado e propagado quando recebido.
-
Veja a seguir uma lista de TLVs de atributo LINK_STATE compatíveis:
-
Atributos de link:
-
Grupo administrativo
-
Largura de banda máxima do link
-
Largura de banda máxima reservável
-
Largura de banda não reservada
-
Métrica padrão do TE
-
SRLG
-
Os seguintes TLVs, que não são originados, mas apenas armazenados e propagados quando recebidos:
-
Atributos de link opacos
-
Máscara de protocolo MPLS
-
Métrica
-
Tipo de proteção de link
-
Atributo de nome do link
-
-
-
Atributos de nó:
-
ID do roteador IPv4
-
Bits de sinalizador de nó — Somente o bit de sobrecarga é definido.
-
Os seguintes TLVs, que não são originados, mas apenas armazenados e propagados quando recebidos:
-
Multitopologia
-
Propriedades do nó específicas do OSPF
-
Propriedades do nó opaco
-
Nome do nó
-
Identificador de área IS-IS
-
ID do roteador IPv6
-
-
Atributos de prefixo — esses TLVs são armazenados e propagados como quaisquer outros TLVs desconhecidos.
-
Recursos com e sem suporte
O Junos OS oferece suporte aos seguintes recursos com distribuição de estado de enlace usando BGP:
-
Anúncio de capacidade de encaminhamento garantido multiprotocolo
-
Transmissão e recepção de NLRIs BGP e BGP-TE de nó e estado de enlace
-
Roteamento ativo ininterrupto para NLRIs BGP-TE
-
Políticas
O Junos OS oferece not suporte à seguinte funcionalidade para distribuição de estado de enlace usando BGP:
-
Topologias, links ou nós agregados
-
Suporte a diferenciador de rota para NLRIs BGP-TE
-
Identificadores de várias topologias
-
Identificadores de várias instâncias (excluindo o ID de instância padrão 0)
-
Anúncio do link e da área do nó TLV
-
Anúncio de protocolos de sinalização MPLS
-
Importação de informações de nó e link com endereço sobreposto
Extensões de estado de enlace BGP para roteamento de pacotes de origem em redes (SPRING)
A família de endereços de estado de enlace BGP é estendida para distribuir as informações de topologia de roteamento de pacotes de origem em redes (SPRING) para controladores de redes definidas por software (SDN). O BGP normalmente aprende as informações de estado do enlace do IGP e as distribui para os pares do BGP. Além do BGP, o controlador SDN pode obter informações de estado do enlace diretamente do IGP se o controlador fizer parte de um domínio IGP. No entanto, a distribuição de estado do 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 entre domínios.
- Roteamento de pacotes de origem em redes (SPRING)
- Fluxo de dados SPRING de estado do enlace BGP
- Atributos de estado de enlace BGP e TLVs suportados e recursos não suportados para estado de enlace BGP com SPRING
Roteamento de pacotes de origem em redes (SPRING)
O SPRING é uma arquitetura de plano de controle que permite que um roteador de entrada direcione um pacote por um conjunto específico de nós e links na rede sem depender dos nós intermediários na rede para decidir o caminho real que ele deve seguir. A SPRING contrata IGPs, como IS-IS e OSPF, para anunciar segmentos de rede. Os segmentos de rede podem representar qualquer instrução, baseada em topologia ou serviço. 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 custo igual, com reconhecimento de multipath para um prefixo, de acordo com o estado da topologia do IGP |
Quando o SPRING é habilitado 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 do IGP e anuncia segmentos na forma de identificadores de segmento (SIDs). A família de endereços de estado do enlace BGP foi estendida para transportar SIDs e outras informações relacionadas ao SPRING para pares BGP. O refletor de rota pode direcionar um pacote através de um conjunto desejado de nós e links, precedendo o pacote com uma combinação apropriada de túneis. Esse recurso permite que a família de endereços de estado de enlace BGP também anuncie as informações SPRING para pares BGP.
Fluxo de dados SPRING de estado do enlace BGP
A Figura 2 mostra o fluxo de dados dos dados SPRING de estado do enlace BGP que o IS-IS envia para o banco de dados de engenharia de tráfego.
-
O IGP envia os atributos SPRING para o banco de dados de engenharia de tráfego.
-
Os recursos do SPRING e as informações do algoritmo são transportados como atributos de nó para o banco de dados de engenharia de tráfego.
-
As informações de SID adjacentes e SID adjacentes de LAN são transportadas como atributos de link.
-
As informações de SID de prefixo ou SID de nó são transportadas como atributos de prefixo.
-
Um novo conjunto ou uma alteração nos atributos existentes aciona atualizações de IGP no banco de dados de engenharia de tráfego com novos dados.
ATENÇÃO:Se a engenharia de tráfego estiver desabilitada no nível do IGP, nenhum dos atributos será enviado para o banco de dados de engenharia de tráfego.
-
Todos os parâmetros no 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 entradas de rota para a
lsdist.0tabela de roteamento do IGP sujeitas à 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. Essa política anuncia uma entrada aprendida com o banco de dados de engenharia de tráfego.
Atributos de estado de enlace BGP e TLVs suportados e recursos não suportados para estado de enlace BGP com SPRING
O estado de enlace BGP com SPRING suporta os seguintes atributos e tipo, comprimento e valores (TLVs) que são 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 acessibilidade de IP
Prefix attributes
-
SID de prefixo
A lista a seguir oferece suporte a TLVs que não são originados, mas apenas recebidos e propagados na rede:
Prefix descriptors
-
ID de multitopologia
-
Tipo de rota OSPF
Prefix attributes
-
Variação
-
SID de associação
O Junos OS não oferece suporte aos seguintes recursos com o estado de enlace BGP com extensões SPRING:
-
Origem de prefixo IPv6
-
Identificadores de multitopologia
-
Exportação de banco de dados de engenharia de tráfego para parâmetros SPRING
-
Novos TLVs com tcpdump (TLVs existentes também não são suportados).
-
SPRING sobre IPv6
Verificando o nó NLRI aprendido por meio do BGP com OSPF como IGP
Veja a seguir um exemplo de saída para verificar o nó NLRI aprendido por meio do BGP com OSPF como IGP:
Finalidade
Verifique as entradas da tabela de roteamento lsdist.0.
Ação
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: 143
Significado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Verificando o prefixo NLRI aprendido por meio de BGP com OSPF como IGP
Veja a seguir um exemplo de saída para verificar o prefixo NLRI aprendido por meio do BGP com OSPF como IGP:
Finalidade
Verifique as entradas da tabela de roteamento lsdist.0.
Ação
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: 143
Significado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Exemplo: configurar a distribuição de estado do enlace usando o BGP
Este exemplo mostra como configurar o BGP para transportar informações de estado do enlace em vários domínios, que são usadas para caminhos de computação para LSPs MPLS abrangendo vários domínios, como TE LSP inter-área, 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.
Requerimentos
Este exemplo usa os seguintes componentes de hardware e software:
-
Quatro roteadores da Série MX
-
Junos OS versão 14.2 ou posterior em execução 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
Um novo mecanismo para distribuir informações de topologia em várias áreas e sistemas autônomos (ASs) é introduzido pela extensão do protocolo BGP para transportar informações de estado do link, que foram inicialmente adquiridas usando o IGP. Os protocolos 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 multiAS, mas também fornece os controles de política que podem ser úteis para a distribuição de topologia multiAS. As informações de topologia de estado de enlace BGP são usadas para computar caminhos para caminhos comutados por rótulos (LSPs) MPLS abrangendo vários domínios, como TE LSP inter-área, e fornecer um meio escalável e controlado por políticas para entidades de computação de caminhos externos, como ALTO e PCE, adquirirem topologia de rede.
A distribuição de estado do enlace usando BGP é suportada em switches QFX10000.
Topologia
Na Figura 3, os Roteadores R0 e R1 e os Roteadores R2 e R3 pertencem a sistemas autônomos diferentes. 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 comandos a seguir, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para corresponder à sua configuração de rede, copie e cole os comandos na CLI no nível de [edit] hierarquia e, em seguida, entre commit no 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
Tramitação processual
Procedimento passo a passo
O exemplo a seguir requer 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 do roteador R1.
[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 o 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 (excluindo 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 (excluindo 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 emparelhar 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 as informações de alcance da camada de rede (NLRI) de sinalização BGP-TE para o grupo BGP do IBGP.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
Habilite a exportação da política nlri2bgp no Roteador R1.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
Configure o grupo BGP para o Roteador R1 emparelhar 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 NLRI de sinalização BGP-TE 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 enlace inter-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 os 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 enlace inter-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
No modo de configuração, confirme sua configuração inserindo os show interfacescomandos , show routing-options, , show protocolse show policy-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-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;
}
}
}
Tramitação processual
Procedimento passo a passo
O exemplo a seguir requer 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 do roteador R2.
[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 o 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 (excluindo 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 (excluindo 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 emparelhar 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 as informações de alcance da camada de rede (NLRI) de sinalização BGP-TE para o grupo BGP do IBGP.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
Habilite a exportação da política nlri2bgp no Roteador R2.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
Configure o grupo BGP para o Roteador R2 emparelhar com o Roteador R1.
[edit protocols]user@R2# set bgp group ebgp type external -
Inclua o NLRI de sinalização BGP-TE 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 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 da 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 ao Roteador R3 e à 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 ao 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 a capacidade 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 o tráfego do NLRI do BGP-TE.
[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
No modo de configuração, confirme sua configuração inserindo os show interfacescomandos , show routing-options, , show protocolse show policy-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-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
- Verificando as entradas da tabela de roteamento lsdist.0
- Verificando as entradas do banco de dados de engenharia de tráfego
Verificando o status do resumo do BGP
Finalidade
Verifique se o BGP está ativo e em execução nos roteadores R0 e R1.
Ação
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/0
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/0
Significado
O roteador R0 é emparelhado com o roteador R1.
Verificando o status do MPLS LSP
Finalidade
Verifique o status do LSP MPLS no roteador R0.
Ação
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 LSP MPLS do Roteador R0 ao Roteador R3 é estabelecido.
Verificando as entradas da tabela de roteamento lsdist.0
Finalidade
Verifique as entradas da tabela de roteamento lsdist.0 nos roteadores R0, R1 e R2.
Ação
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.0
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.0
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
Fictitious
Significado
As rotas estão aparecendo na tabela de roteamento lsdist.0.
Verificando as entradas do banco de dados de engenharia de tráfego
Finalidade
Verifique as entradas do banco de dados de engenharia de tráfego no Roteador R0.
Ação
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: 0
Significado
As rotas estão aparecendo no banco de dados de engenharia de tráfego.
Configuração da distribuição de estado do enlace 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 do enlace, que foram inicialmente adquiridas usando o IGP. Os protocolos 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 multiAS, mas também fornece os controles de política que podem ser úteis para a distribuição de topologia multiAS. As informações de topologia de estado de enlace BGP são usadas para computar caminhos para LSPs MPLS abrangendo vários domínios, como TE LSP inter-área, e fornecendo um meio escalável e controlado por políticas para entidades de computação de caminhos externos, como ALTO e PCE, para adquirir topologia de rede.
Antes de começar:
-
Configure as interfaces do dispositivo.
-
Configure o 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 de estado de enlace usando BGP:
Distribuição de estado de enlace de SIDs SRv6 usando BGP-LS
Extensões de estado de enlace BGP para SRv6
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 por meio do BGP-LS. BGP LS fornece um mecanismo escalável para exportar as informações de topologia. Ele também pode ser usado para redes entre domínios. Além disso, agora você pode filtrar o NLRI com base no prefixo IPv6 (localizador SRv6) e no NLRI SID SRv6.
Fluxo de dados SRv6 de estado de enlace BGP
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 suas entradas de 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 por meio do IGP IS-IS agora são suportados no Junos, conforme descrito no padrão IETF [3].
-
Os atributos SRv6 são adicionados ao banco de dados de engenharia de tráfego (TED).
-
Os atributos SRv6 aprendidos via IGP IS-IS são armazenados no TED à medida que 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, elas são instaladas em uma tabela de roteamento chamada lsdist.0.
-
O BGP pode ser configurado para "exportar" ou anunciar rotas da tabela lsdist.0 sujeitas à 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 NLRs BGP-LS. O BGP armazena os NLRIs BGP-LS recebidos na forma de rotas na tabela "lsdist.0", que é a mesma tabela que armazena as rotas BGP-LS originadas localmente. As informações SRv6 recém-adicionadas são propagadas para o BGP como atributos de NLRIs já existentes (nó, link e prefixo) e um novo NLRI localizador SRv6.
-
Os NLRIs BGP-LS recebidos que são instalados na forma de rotas na tabela "lsdist.0" podem estar sujeitos à política de exportação TED e, se a política permitir, os atributos SRv6 dessas rotas são adicionados à instância local do banco de dados TE.
Prefixos IPv6 e SIDs de adjacência IPv6 Suporte a MPLS no banco de dados de engenharia de tráfego e estado de enlace BGP
Fizemos os seguintes aprimoramentos do IPv6.
- Suporte para adicionar atributos e informações IPv6 ao banco de dados de engenharia de tráfego (TED) do Sistema Intermediário para o Sistema Intermediário (IS-IS).
- Suporte para importação de atributos IPv6 do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0.
- Suporte para exportação de atributos IPv6 para BGP Link-State (BGP-LS).
- Suporte para exportação de atributos e informações de alcance de camada de rede (NLRIs) BGP-LS IPv6 da tabela de roteamento lsdist.0 para o banco de dados de engenharia de tráfego.
Oferecemos suporte apenas ao protocolo de gateway interior (IGP) IS-IS.
- Benefícios dos prefixos IPv6 e do SID de adjacência IPv6 Suporte a MPLS no banco de dados de engenharia de tráfego e BGP-LS
- Implementação
- Suporte para adicionar atributos e informações IPv6 ao banco de dados de engenharia de tráfego do IS-IS
- Suporte para importação de atributos IPv6 do banco de dados de engenharia de tráfego para a tabela de roteamento lsdist.0
- Suporte para exportação de atributos IPv6 para BGP-LS
- Suporte para exportação de atributos e NLRIs IPv6 BGP-LS da tabela de roteamento lsdist.0 para o banco de dados de engenharia de tráfego
- Comando de configuração
Benefícios dos prefixos IPv6 e do SID de adjacência IPv6 Suporte a MPLS no banco de dados de engenharia de tráfego e BGP-LS
Aprimoramos as saídas dos comandos operacionais existentes e adicionamos os comandos show para exibir a lista de prefixos IPv6 e IPv4, respectivamente, no banco de dados de engenharia de tráfego.
show ted database extensive— Aprimorada a saída para incluir os atributos IPv6 Segment Routing (SR)-MPLS.show ted link detail— Aprimorada a saída para incluir os atributos SR-MPLS IPv6 correspondentes aos links do banco de dados de engenharia de tráfego.show route table lsdist.0 [extensive | detail]— Aprimorada a saída para incluir atributos IPv6 NLRIs e IPv6 SR-MPLS.show route— Incluídos 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-addrete-ipv6-prefix-node-iso.show ted ipv6-prefix— Adicionado o comando show para exibir a lista de prefixos IPv6 no banco de dados de engenharia de tráfego.show ted ipv4-prefix— Adicionado o comando show para exibir a 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 conseguir isso, o banco de dados de engenharia de tráfego converte seus links, nós e entradas de prefixo (IPv4 e IPv6) na forma de rotas. A figura a seguir mostra o fluxo de informações do BGP-LS para o BGP-LS.
Suporte para adicionar 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 o plano de dados IPv6, trocados através do IGP IS-IS. Como resultado desse aprimoramento, os atributos e informações IPv6 podem ser adicionados ao banco de dados de engenharia de tráfego (TED).
Suporte para 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 IGP IS-IS 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 do 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 para exportação de atributos IPv6 para BGP-LS
O BGP está configurado para exportar ou anunciar rotas da tabela lsdist.0, sujeito à política. É um cenário de rotina para qualquer origem de rota no BGP. O BGP então propaga essas rotas como qualquer outro NLRI para os pares com BGP-LS configurado e vizinhança BGP estabelecida. O BGP armazena os NLRIs BGP-LS recebidos na forma de rotas na tabela lsdist.0, que é a mesma tabela que armazena as rotas BGP-LS originadas localmente. Como resultado dessa funcionalidade, as informações IPv6 recém-adicionadas são propagadas para o BGP como atributos de NLRI de link já existente e como um novo NLRI de prefixo IPv6.
Suporte para exportação de atributos e NLRIs IPv6 BGP-LS da tabela de roteamento lsdist.0 para o banco de dados de engenharia de tráfego
No Junos OS, os NLRIs BGP-LS recebidos instalados na forma de rotas na tabela lsdist.0 estão sujeitos à política de exportação do 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 BGP-TE policy foi aprimorado para permitir a filtragem de NLRIs com base no prefixo IPv6 NLRI. Consulte prefixo ipv6.
Veja também
Tabela de histórico de alterações
A compatibilidade com recursos é determinada pela plataforma e versão utilizada. Use o Explorador de recursos para determinar se um recurso é compatível com sua plataforma.