Configuração da engenharia de tráfego MPLS

Usando LSPs para o encaminhamento de tráfego BGP e IGP

Você pode configurar o BGP e os IGPs para usar LSPs para encaminhar tráfego destinado a roteadores de saída, incluindo a opção bgp-igp para a traffic-engineering declaração. A opção bgp-igp faz com que todas as rotas inet.3 sejam movidas para a tabela de roteamento inet.0.

No roteador de entrada, inclua bgp-igp a opção para a traffic-engineering declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

  Nota:

  A opção bgp-igp pela traffic-engineering declaração não pode ser configurada para VPN). As VPNs exigem que as rotas estejam na tabela de roteamento inet.3.

Usando LSPs para encaminhamento em redes virtuais privadas

As VPNs exigem que as rotas permaneçam na tabela de roteamento inet.3 para funcionar corretamente. Para VPNs, configure a opção bgp-igp-both-ribs da traffic-engineering declaração para fazer com que o BGP e os IGPs usem LSPs para encaminhamento de tráfego destinado a roteadores de saída. A bgp-igp-both-ribs opção instala as rotas de entrada tanto na tabela de roteamento inet.0 (para rotas unicast IPv4) quanto na tabela de roteamento inet.3 (para informações de caminho MPLS).

No roteador de entrada, inclua a traffic-engineering bgp-igp-both-ribs declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Quando você usa a bgp-igp-both-ribs declaração, as rotas da tabela inet.3 são copiadas na tabela inet.0. As rotas copiadas são sinalizadas por LDP ou sinalizadas por RSVP, e provavelmente terão uma preferência inferior à de outras rotas no inet.0. Rotas com preferência inferior são mais propensas a serem escolhidas como rotas ativas. Isso pode ser um problema porque as políticas de roteamento só agem em rotas ativas. Para evitar esse problema, use a opção mpls-forwarding .

Usando rotas de RSVP e LDP para encaminhamento, mas não seleção de rotas

Se você configurar as bgp-igp ou bgp-igp-both-ribs opções para a declaração, os traffic-engineering LSPs de alta prioridade podem sobrepor as rotas de IGP na tabela de roteamento inet.0. As rotas de IGP podem não ser mais redistribuídas, pois não são mais as rotas ativas.

Se você configurar a opção mpls-forwarding para a declaração, os traffic-engineering LSPs serão usados para o encaminhamento, mas serão excluídos da seleção de rota. Essas rotas são adicionadas às tabelas de roteamento inet.0 e inet.3. Os LSPs na tabela de roteamento inet.0 recebem uma preferência inferior quando a rota ativa é selecionada. No entanto, os LSPs na tabela de roteamento inet.3 recebem uma preferência normal e, portanto, são usados para selecionar o encaminhamento de próximos saltos.

Quando você ativa a opção mpls-forwarding , rotas cujo estado é ForwardingOnly preferido para o encaminhamento, mesmo que sua preferência seja inferior à da rota ativa atualmente. Para examinar o estado de uma rota, execute um show route detail comando.

Para usar LSPs para encaminhamento, mas excluí-los da seleção de rotas, inclua a opção mpls-forwarding para a traffic-engineering declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Quando você configura a opção, as mpls-forwarding rotas de atalho de IGP são copiadas apenas para a tabela de roteamento inet.0.

Ao contrário da opção bgp-igp-both-ribs , a opção mpls-forwarding permite que você use as rotas sinalizadas por LDP e sinalizadas por RSVP para encaminhamento, e mantenha as rotas BGP e IGP ativas para fins de roteamento para que as políticas de roteamento possam agir sobre elas.

Por exemplo, suponha que um roteador esteja executando BGP e ele tenha uma rota BGP de 10.10.10.1/32 que ele precisa enviar para outro alto-falante BGP. Se você usar a opção bgp-igp-both-ribs , e seu roteador também tiver um caminho comutada por rótulos (LSP) para 10.10.10.1, a rota MPLS para 10.10.10.1 torna-se ativa na tabela de roteamento inet.0. Isso impede que seu roteador anucie a rota 10.10.10.1 para o outro roteador BGP. Por outro lado, se você usar a opção mpls-forwarding em vez da opção bgp-igp-both-ribs , a rota BGP 10.10.10.1/32 é anunciada para o outro alto-falante BGP, e o LSP ainda é usado para encaminhar o tráfego para o destino 10.10.10.1.

Publicidade da métrica LSP em LSAs sumários

Você pode configurar MPLS e OSPF para tratar um LSP como um link. Essa configuração permite que outros roteadores na rede usem esse LSP. Para atingir esse objetivo, você precisa configurar a engenharia de tráfego MPLS e OSPF para anunciar a métrica LSP em LSAs sumários.

Para MPLS, inclua as e label-switched-path as traffic-engineering bgp-igp declarações:

Você pode incluir essas declarações nos seguintes níveis de hierarquia:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Para OSPF, inclua a lsp-metric-into-summary declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Para obter mais informações sobre a engenharia de tráfego OSPF, consulte a Biblioteca de protocolos de roteamento Junos OS para dispositivos de roteamento.

Requisitos de engenharia de tráfego entre AS

O estabelecimento e o funcionamento adequados dos LSPs projetados por tráfego entre AS dependem dos seguintes requisitos de rede, todos os quais devem ser atendidos:

• Todos os ASs estão sob controle de um único provedor de serviços.

• O OSPF é usado como protocolo de roteamento em cada AS, e o EBGP é usado como protocolo de roteamento entre as ASs.

• As informações do ASBR estão disponíveis em cada AS.

• As informações de roteamento EBGP são distribuídas pelo OSPF, e uma malha completa do IBGP está em vigor dentro de cada AS.

• Os LSPs de trânsito não estão configurados nos links inter-AS, mas estão configurados entre as ASBRs de entrada e ponto de saída em cada AS.

• O enlace EBGP entre ASBRs em diferentes ASs é um link direto e deve ser configurado como um link de engenharia de tráfego passivo sob OSPF. O endereço de link remoto em si, não o loopback ou qualquer outro endereço de link, é usado como identificador de nós remoto para este link passivo. Para obter mais informações sobre a configuração do modo de engenharia de tráfego passiva do OSPF, consulte Configuração do modo TE passivo de OSPF.

Além disso, o endereço usado para o nó remoto do enlace de engenharia de tráfego passivo OSPF deve ser o mesmo que o endereço usado para o link EBGP. Para obter mais informações sobre OSPF e BGP em geral, consulte a Biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.

Limitações de engenharia de tráfego entre AS

Apenas a sinalização hierárquica ou aninhada de LSP é suportada para LSPs projetados em tráfego entre AS. Apenas os LSPs ponto a ponto são suportados (não há suporte de ponto a multiponto).

Além disso, as seguintes limitações se aplicam. Qualquer uma dessas condições é suficiente para inviabilizar os LSPs projetados por tráfego entre AS, mesmo que os requisitos acima sejam atendidos.

• O uso do BGP multihop não é compatível.

• O uso de policiais ou topologias que impedem que as rotas BGP sejam conhecidas dentro do AS não é suportado.

• Vários ASBRs em uma LAN entre os pares EBGP não são suportados. Apenas um ASBR em uma LAN entre os pares EBGP é suportado (outros ASBRs podem existir na LAN, mas não podem ser anunciados).

• Refletores de roteamento ou políticas que ocultam informações do ASBR ou impedem que as informações do ASBR sejam distribuídas dentro das ASs não são suportadas.

• Os LSPs bidirecionais não são suportados (os LSPs são unidirecionais da perspectiva da engenharia de tráfego).

• Topologias com caminhos entre AS e intra-AS para o mesmo destino não são suportadas.

Além disso, vários recursos que são roteamento com todos os LSPs não são suportados com a engenharia de tráfego entre AS:

• As cores do link do grupo Admin não são suportadas.

• O standby secundário não é suportado.

• A reoptimização não é suportada.

• O crankback em roteadores de trânsito não é suportado.

• O cálculo diversificado de caminhos não é suportado.

• A reinicialização graciosa não é suportada.

Essas listas de limitações ou recursos sem suporte com LSPs projetados por tráfego entre AS não são exaustivas.

Configuração do modo TE passivo de OSPF

Normalmente, protocolos de roteamento interior, como o OSPF, não são executados em links entre ASs. No entanto, para que a engenharia de tráfego entre AS funcione corretamente, informações sobre o link entre AS, em particular, o endereço na interface remota devem ser disponibilizadas dentro do AS. Essas informações normalmente não estão incluídas em mensagens de acessibilidade EBGP ou em anúncios de roteamento OSPF.

Para inundar essas informações de endereço de link dentro do AS e torná-la disponível para cálculos de engenharia de tráfego, você deve configurar o modo passivo OSPF para engenharia de tráfego em cada interface inter-AS. Você também deve fornecer o endereço remoto para que o OSPF distribua e inclua no banco de dados de engenharia de tráfego.

Para configurar o modo passivo OSPF para engenharia de tráfego em uma interface inter-AS, inclua a passive declaração para o link no [edit protocols ospf area area-id interface interface-name] nível de hierarquia:

O OSPF deve estar configurado corretamente no roteador. O exemplo a seguir configura o link so-1/1/0 entre AS para distribuir informações de engenharia de tráfego com OSPF dentro do AS. O endereço IP remoto é 192.168.207.2.

Encaminhamento de pacotes com base na troca de rótulos

O processo de encaminhamento de pacotes em cada roteador é baseado no conceito de troca de rótulos. Esse conceito é semelhante ao que ocorre em cada switch Asynchronous Transfer Mode (ATM) em um circuito virtual permanente (PVC). Cada pacote MPLS transporta um cabeçalho de encapsulamento de 4 byte que contém um campo de rótulo de comprimento fixo de 20 bits. Quando um pacote contendo um rótulo chega a um roteador, o roteador examina o rótulo e o copia como um índice para sua tabela de encaminhamento MPLS. Cada entrada na tabela de encaminhamento contém um par de rótulos de entrada de interface mapeado para um conjunto de informações de encaminhamento que são aplicadas a todos os pacotes que chegam na interface específica com o mesmo rótulo de entrada.

Como um pacote atravessa um backbone MPLS

Esta seção descreve como um pacote IP é processado enquanto atravessa uma rede de backbone MPLS.

Na borda de entrada do backbone MPLS, o cabeçalho IP é analisado pelo roteador de entrada. Com base nesta análise, o pacote é classificado, atribuído a um rótulo, encapsulado em um cabeçalho MPLS e encaminhado para o próximo salto no LSP. O MPLS oferece um alto grau de flexibilidade na forma como um pacote IP pode ser atribuído a um LSP. Por exemplo, na implementação da engenharia de tráfego Junos, todos os pacotes que chegam ao roteador de entrada destinados a sair do domínio MPLS no mesmo roteador de saída são encaminhados pelo mesmo LSP.

Assim que o pacote começa a atravessar o LSP, cada roteador usa o rótulo para tomar a decisão de encaminhamento. A decisão de encaminhamento do MPLS é tomada independentemente do cabeçalho IP original: a interface e o rótulo de entrada são usados como chaves de busca na tabela de encaminhamento MPLS. O rótulo antigo é substituído por um novo rótulo, e o pacote é encaminhado para o próximo salto ao longo do LSP. Esse processo é repetido em cada roteador no LSP até que o pacote chegue ao roteador de saída.

Quando o pacote chega ao roteador de saída, o rótulo é removido e o pacote sai do domínio MPLS. O pacote é então encaminhado com base no endereço IP de destino contido no cabeçalho IP original do pacote de acordo com o caminho mais curto tradicional calculado pelo protocolo de roteamento IP.

Componente de distribuição de informações

A engenharia de tráfego requer conhecimento detalhado sobre a topologia da rede, bem como informações dinâmicas sobre o carregamento de rede. Para implementar o componente de distribuição de informações, são definidas extensões simples para os IGPs. Os atributos do link estão incluídos como parte do anúncio de estado do link de cada roteador. As extensões IS-IS incluem a definição de novos valores de comprimento de tipo (TLVs), enquanto as extensões OSPF são implementadas com anúncios opacos de estado de enlace (LSAs). O algoritmo de inundação padrão usado pelos IGPs do estado do enlace garante que os atributos de link sejam distribuídos a todos os roteadores no domínio de roteamento. Algumas das extensões de engenharia de tráfego a serem adicionadas ao anúncio de estado do link IGP incluem largura de banda máxima de link, largura de banda de link máximo reservada, reserva de largura de banda atual e coloração de link.

Cada roteador mantém atributos de enlace de rede e informações de topologia em um banco de dados especializado de engenharia de tráfego. O banco de dados de engenharia de tráfego é usado exclusivamente para o cálculo de caminhos explícitos para a colocação de LSPs em toda a topologia física. Um banco de dados separado é mantido para que a computação subsequente de engenharia de tráfego seja independente do IGP e do banco de dados de estado de enlace do IGP. Enquanto isso, o IGP continua sua operação sem modificações, realizando o cálculo tradicional de caminho mais curto com base em informações contidas no banco de dados de estado do roteador.

Componente de seleção de caminhos

Após os atributos de enlace de rede e as informações de topologia serem inundados pelo IGP e colocados no banco de dados de engenharia de tráfego, cada roteador de entrada usa o banco de dados de engenharia de tráfego para calcular os caminhos para seu próprio conjunto de LSPs em todo o domínio de roteamento. O caminho para cada LSP pode ser representado por uma rota explícita rigorosa ou frouxa. Uma rota explícita é uma sequência pré-configurada de roteadores que deve fazer parte do caminho físico do LSP. Se o roteador de entrada especificar todos os roteadores do LSP, o LSP será identificado por uma rota explícita rigorosa. Se o roteador de entrada especificar apenas alguns dos roteadores no LSP, o LSP será descrito como uma rota explícita e frouxa. O suporte a rotas explícitas rigorosas e frouxas permite que o processo de seleção de caminhos seja dado a ela sempre que possível, mas seja restringido quando necessário.

O roteador de entrada determina o caminho físico para cada LSP aplicando um algoritmo de caminho mais curto limitado primeiro (CSPF) às informações no banco de dados de engenharia de tráfego. CSPF é um algoritmo de caminho mais curto que foi modificado para levar em conta restrições específicas quando o caminho mais curto em toda a rede é calculado. A entrada no algoritmo de CSPF inclui:

• Informações de estado de enlace de topologia aprendidas com o IGP e mantidas no banco de dados de engenharia de tráfego

• Atributos associados ao estado dos recursos de rede (como largura de banda total do link, largura de banda de link reservada, largura de banda de link disponível e cor do link) que são transportados por extensões de IGP e armazenados no banco de dados de engenharia de tráfego

• Atributos administrativos necessários para oferecer suporte ao tráfego que atravessa o LSP proposto (como requisitos de largura de banda, contagem máxima de saltos e requisitos de políticas administrativas) obtidos na configuração do usuário

Como o CSPF considera cada nó e link do candidato para um novo LSP, ele aceita ou rejeita um componente de caminho específico com base na disponibilidade de recursos ou se a seleção do componente viola as restrições da política do usuário. A saída do cálculo do CSPF é uma rota explícita que consiste em uma sequência de endereços de roteador que fornece o caminho mais curto através da rede que atende às restrições. Essa rota explícita é então passada para o componente de sinalização, que estabelece o estado de encaminhamento nos roteadores ao longo do LSP.

Componente de sinalização

Um LSP não é conhecido por ser viável até que seja realmente estabelecido pelo componente de sinalização. O componente de sinalização, responsável por estabelecer o estado LSP e distribuir rótulos, depende de uma série de extensões para RSVP:

• O objeto de Rota Explícita permite que uma mensagem de caminho RSVP passe por uma sequência explícita de roteadores que é independente do roteamento IP de caminho mais curto convencional. A rota explícita pode ser rigorosa ou frouxa.

• O objeto De solicitação de rótulos permite que a mensagem de caminho RSVP solicite que os roteadores intermediários forneçam uma vinculação de rótulo para o LSP que ele está estabelecendo.

• O objeto Label permite que o RSVP ofereça suporte à distribuição de rótulos sem alterar seus mecanismos existentes. Como a mensagem RSVP Resv segue o caminho inverso da mensagem de caminho RSVP, o objeto Label oferece suporte à distribuição de rótulos de nós downstream a nós upstream.

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
• Implementação

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.

Figura 1: Implementação do Junos OS da distribuição de estado do enlace BGP

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.

Nota:

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

Nota:

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

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.

Figura 2: Roteamento de pacotes de origem de link BGP em redes (SPRING)

• 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.0 partir 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.0 tabela de roteamento. Esta política anuncia uma entrada aprendida com o banco de dados de engenharia de tráfego.

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:

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:

Benefícios dos planos de transporte com classe BGP

• Fatiamento de rede — as camadas de serviço e transporte são desacopladas entre si, estabelecendo as bases para o fatiamento e a virtualização de rede com o fatiamento de ponta a ponta em vários domínios, reduzindo significativamente o CAPEX.

• Interoperabilidade entre domínios — estende a implantação da classe de transporte em domínios de cooperação para que os diferentes protocolos de sinalização de transporte em cada domínio interoperem. Concilia quaisquer diferenças entre namespaces estendidos da comunidade que podem estar em uso em cada domínio.

• Resolução colorida com fallback — permite a resolução sobre túneis coloridos (RSVP, algoritmo flexível IS-IS) com opções flexíveis de fallback em túneis de melhor esforço ou qualquer outro túnel de cor.

• Qualidade de serviço — personaliza e otimiza a rede para alcançar os requisitos de SLA de ponta a ponta.
• Aproveitamento das implantações existentes — oferece suporte a protocolos de tunelamento bem implantados, como o RSVP, juntamente com novos protocolos, como o algoritmo flexível IS-IS, preservando o ROI e reduzindo o OPEX.

Os planos de transporte com classe BGP da OMP

Esta seção fornece um resumo dos termos comumente usados para entender o plano de transporte com classe BGP.

• Nó de serviço — dispositivos de borda de provedor de entrada (PE) que enviam e recebem rotas de serviço (Internet e VPN de Camada 3).

• Nó de borda — Dispositivo no ponto de conexão de diferentes domínios (áreas de IGP ou ASs).

• Nó de transporte — Dispositivo que envia e recebe rotas Unicast (LU) com rótulo BGP.

• BGP-VPN- VPNs criadas usando mecanismos RFC4364.

• Alvo de rota (RT)— Tipo de comunidade estendida usada para definir a associação de VPN.

• Route Distinguisher (RD)— Identificador usado para distinguir qual VPN ou serviço de LAN privada virtual (VPLS) pertence. Cada instância de roteamento deve ter um diferencial de rota único associado a ela.

• Esquema de resolução — usado para resolver o endereço de próximo salto (PNH) de protocolo em RIBs de resolução que fornecem fallback.

  Eles mapeiam as rotas para os diferentes RIBs de transporte no sistema com base na comunidade de mapeamento.

• Família de serviços — família de endereços BGP usada para rotas de publicidade para tráfego de dados, em vez de túneis.

• Família de transporte — família de endereços BGP usada para túneis de publicidade, que por sua vez são usados por rotas de serviço para resolução.

• Túnel de transporte — um túnel sobre o qual um serviço pode colocar tráfego, por exemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

• Domínio de túnel — um domínio da rede que contém nós de serviço e nós de borda sob um único controle administrativo que tem um túnel entre eles. Um túnel de ponta a ponta que abrange vários domínios de túneis adjacentes pode ser criado costurando os nós usando rótulos.

• Classe de transporte — um grupo de túneis de transporte que oferecem o mesmo tipo de serviço.

• Classe de transporte RT- Um novo formato de alvo de rota usado para identificar uma classe de transporte específica.

  Um novo formato de Route Target usado para identificar uma classe de transporte específica.

• Transporte RIB — No nó de serviço e nó de fronteira, uma classe de transporte tem uma RIB de transporte associada que detém suas rotas de túnel.

• Instância de roteamento RTI de transporte; contêiner de transporte RIB, e categoria de transporte associada Route Target e Route Distinguisher.

• Plano de transporte — Conjunto de RTIs de transporte importando RT da mesma classe de transporte. Estes são, por sua vez, costurados para abranger os limites do domínio do túnel usando um mecanismo semelhante à opção-b Inter-AS para trocar rótulos em nós de fronteira (nexthop-self), formando um plano de transporte de ponta a ponta.

• Mapeamento da comunidade — Comunidade em uma rota de serviço que mapeia para resolver em uma aula de transporte.

Entenda os planos de transporte com classe BGP

Você pode usar planos de transporte com classe BGP para configurar aulas de transporte para classificar um conjunto de túneis de transporte em uma rede intra-AS com base nas características de engenharia de tráfego e usar esses túneis de transporte para mapear rotas de serviço com o SLA desejado e o recuo desejado.

Os planos de transporte com classe BGP podem estender esses túneis para redes entre domínios que se estendem por vários domínios (ASs ou áreas de IGP) ao mesmo tempo em que preservam a classe de transporte. Para isso, você deve configurar a família BGP de camada de transporte de transporte com classe BGP entre a borda e os nós de serviço.

Em implementações entre AS e intra-AS, pode haver muitos túneis de transporte (MPLS LSPs, algoritmo flexível IS-IS, SR-TE) criados a partir do serviço e nós de fronteira. Os LSPs podem ser sinalizados usando diferentes protocolos de sinalização em diferentes domínios e podem ser configurados com diferentes características de engenharia de tráfego (classe ou cor). O endpoint do túnel de transporte também atua como endpoint de serviço e pode estar presente no mesmo domínio de túnel que o nó de entrada de serviço, ou em um domínio adjacente ou não adjacente. Você pode usar planos de transporte com classe BGP para redirecionar serviços em LSPs com certas charaterísticas de engenharia de tráfego, seja dentro de um único domínio ou em vários domínios.

Os planos de transporte com classe BGP reutilizam a tecnologia BGP-VPN, mantendo os domínios de tunelamento livremente acoplados e coordenados.

• As informações de alcance da camada de rede (NLRI) são RD:TunnelEndpoint usado para ocultação de caminhos.
• O alvo da rota indica a classe de transporte dos LSPs, e vazamentos de rotas para o RIB de transporte correspondente no dispositivo de destino.
• Cada protocolo de tunelamento de transporte instala uma rota de entrada na tabela de roteamento transport-class.inet.3, modela a classe de transporte de túneis como um alvo de rota VPN e coleta os LSPs da mesma classe de transporte na tabela de roteamento transport-class.inet.3.

• As rotas nesta instância de roteamento são anunciadas no plano de transporte com classe BGP (transporte de inet) AFI-SAFI seguindo procedimentos semelhantes ao RFC-4364.

• Ao cruzar o limite do enlace entre AS, você deve seguir os procedimentos de Opção b para costurar os túneis de transporte nesses domínios adjacentes.

  Da mesma forma, ao atravessar as regiões intra-AS, você deve seguir os procedimentos de Opção b para costurar os túneis de transporte nos diferentes domínios de TE.

• Você pode definir esquemas de resolução para especificar a intenção na variedade de classes de transporte em uma ordem de recuo.

• Você pode resolver rotas de serviço e rotas de transporte com classe BGP nessas aulas de transporte, abordando a comunidade de mapeamento sobre elas.

A família de transporte com classe BGP é operada junto com a família de camada de transporte BGP-LU. Em uma rede MPLS perfeita que executa o BGP-LU, atender a requisitos SLA rigorosos do 5G é um desafio, pois as características de engenharia de tráfego dos túneis não são conhecidas ou preservadas em todos os limites do domínio. Os planos de transporte com classe BGP oferecem meios operacionais fáceis e escaláveis para anunciar vários caminhos para loopbacks remotos, juntamente com as informações da classe de transporte na arquitetura MPLS perfeita. Nas rotas familiares de transporto com classe BGP, diferentes caminhos SLA são representados usando a comunidade estendida Transport Route-Target, que leva a cor da classe de transporte. Este Transport Route-Target é usado pelos roteadores BGP que recebem para associar a rota de transporte com classe BGP à classe de transporte apropriada. Ao anunciar novamente as rotas de transporte com classe BGP, o MPLS troca rotas, inter conecta os túneis intra-AS da mesma classe de transporte, formando assim um túnel de ponta a ponta que preserva a classe de transporte.

Implementação intra-AS de planos de transporte com classe BGP

Figura 4 ilustra uma topologia de rede com cenários de antes e depois da implementação de planos de transporte com classe BGP em um domínio intra-AS. Os dispositivos PE11 e PE12 usam LSPs RSVP como túnel de transporte e todas as rotas de túnel de transporte estão instaladas no inet.3 RIB. A implementação de planos de transort com classe BGP permite que os túneis de transporte RSVP sejam conscientes de cores semelhantes aos túneis de roteamento por segmentos.

Figura 4: Domínio intra-AS: Cenários de antes e depois para a implementação de planos de transporte com classe BGP

Para classificar os túneis de transporte na classe de transporte BGP em uma configuração intra-AS:

1. Defina a classe de transporte no nó de serviço (dispositivos PE de entrada), por exemplo, ouro e bronze, e atribua valores de comunidade de cores à classe de transporte definida.

   Configuração da amostra:

2. Associe o túnel de transporte a uma classe de transporte específica no nó de entrada dos túneis.

   Configuração da amostra:

Funcionalidade de plano de transporte com classe BGP intra-AS:

• O transporte com classe BGP cria RIBs de transporte predefinidos por classe de transporte nomeada (ouro e bronze) e automaticamente deriva a comunidade de mapeamento a partir de seu valor de cor (100 e 200).
• As rotas de transporte intra-AS são povoadas em RIBs de transporte pelo protocolo de tunelamento quando estão associadas a uma classe de transporte.

  Neste exemplo, as rotas RSVP LSP associadas à classe de transporte ouro (cor 100) e bronze da classe de transporte (cor 200) são instaladas no transporte RIBs junos-rti-tc-<100>.inet.3 e junos-rti-tc-<200>.inet.3, respectivamente.

• O nó de serviço (PEs de entrada) combina com a comunidade de cores estendida (cor:0:100 e cor:0:200) da rota de serviço contra a comunidade de mapeamento em RIBs de resolução predefinida e resolve o protocolo next hop (PNH) em RIBs de transporte correspondentes (junos-rti-tc-<100>.inet.3, ou junos-rti-tc-<200>.inet.3).
• As rotas BGP se ligam a um esquema de resolução transportando a comunidade de mapeamento assiocato.
• Cada classe de transporte cria automaticamente dois esquemas de resolução predefinidos e deriva automaticamente da comunidade de mapeamento.

  Um esquema de resolução é para a resolução de rotas de serviço que usam o Color:0:<val> como a comunidade de mapeamento.

  O outro esquema de resolução é para a resolução de rotas de transporte que utilizam o Transport-Target:0:<val> como a comunidade de mapeamento.

• Se o PNH de rota de serviço não puder ser resolvido usando RIBs listados no esquema de resolução predefinido, ele pode voltar à tabela de roteamento inet.3.
• Você também pode configurar o fallback entre diferentes RIBs de transporte coloridos usando esquemas de resolução definidos pelo usuário sob a hierarquia de [edit routing-options resolution scheme] configuração.

Implementação inter-AS de planos de transporte com classe BGP

Em uma rede inter-AS, o BGP-LU é convertido em rede de transporte com classe BGP depois de configurar um mínimo de duas classes de transporte (ouro e bronze) em todos os nós de serviço ou dispositivos PE e nós de borda (ABRs e ASBRs).

Para converter os túneis de transporte em transporte com classe BGP:

1. Defina a classe de transporte nos nós de serviço (dispositivos pe de entrada) e nos nós de borda (ABRs e ASBRs), por exemplo, ouro e broze.

   Configuração da amostra:

2. Associe os túneis de transporte a uma classe de transporte específica no nó de entrada dos túneis (PEs de entrada, ABRs e ASBRs).

   Configuração da amostra:

   Para RSVP LSPs

   Para algoritmos flxáveis IS-IS

3. Habilite uma nova família para o transporte com classe BGP (transporte de inet) e BGP-LU (inet labeled-unicast) na rede.

   Configuração da amostra:

4. Anuncie rotas de serviço a partir do dispositivo PE de saída com a comunidade de cores estendida apropriada.

   Configuração da amostra:

Funcionalidade de plano de transporte com classe BGP entre AS:

1. Os planos de transporte com classe BGP criam RIBs de transporte predefinidos por classe de transporte nomeada (ouro e bronze) e automaticamente derivam a comunidade de mapeamento de seu valor de cor.

2. As rotas de transporte intra-AS são povoadas em RIBs de transporte por protocolos de tunelamento quando associadas a uma classe de transporte.

   Por exemplo, as rotas de túnel de transporte associadas à classe de transporte ouro e bronze estão instaladas no junos-rti-tc-<100>.inet.3 e junos-rti-tc-<200>.inet.3, respectivamente.

3. Os planos de transporte com classe BGP usam o diferencial de rota exclusivo e o alvo de rota quando ele copia as rotas de túnel de transporte de cada RIB de transporte para a tabela de roteamento bgp.transport.3.
4. Nós de fronteira anunciam rotas da tabela de roteamento bgp.transport.3 para seus pares em outros domínios se o transporte de inet familiar for negociado na sessão BGP.
5. Receber nó de borda instala essas rotas bgp-ct na tabela de roteamento bgp.transport.3 e copia essas rotas com base no alvo de rota de transporte para as RIBs de transporte apropriadas.
6. O nó de serviço corresponde à comunidade de cores na rota de serviço em relação a uma comunidade de mapeamento nos esquemas de resolução e resolve PNH na RIB de transporte correspondente ( junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>.inet.3).
7. Os nós de fronteira usam esquemas de resolução predefinidos para a resolução de PNH da rota de transporte.
8. Predefinidos ou definidos pelo usuário, ambos os esquemas de resolução oferecem suporte à resolução de PNH de rota de serviço. O inet.3 predefinido usa como fallback e o esquema de resolução definido pelo usuário permite que a lista de RIBs de transporte seja usada na ordem especificada enquanto resolve o PNH.
9. Se o PNH de rota de serviço não puder ser resolvido usando RIBs listados no esquema de resolução definido pelo usuário, então a rota será descartada.

Transporte classful BGP (BGP-CT) com visão geral dos túneis SR-TE coloridos subjacentes

Benefícios do BGP-CT com túneis SR-TE coloridos subjacentes

• Resolve preocupações de escala que podem surgir no futuro à medida que a rede cresce.
• Oferece interconectividade para domínios que usam tecnologias diferentes.
• Desacopla serviços e as camadas de transporte que resultam em uma rede completamente distribuída.
• Oferece gerenciamento independente de largura de banda por meio de um controlador de engenharia de tráfego intra-domínio para SR-TE.

Redes de grande porte que estão crescendo e evoluindo continuamente exigem uma arquitetura de roteamento por segmentos consistente. A partir do Junos OS Release 21.2,R1 oferecemos suporte ao BGP-CT com transporte subjacente como túneis SR-TE coloridos. O BGP-CT pode resolver rotas de serviço usando as RIBs de transporte e computar o próximo salto. Os serviços que atualmente são suportados no BGP-CT também podem usar os túneis coloridos SR-TE subjacentes para resolução de rotas. Os serviços agora podem usar os túneis coloridos SR-TE subjacentes, como os túneis coloridos estáticos, BGP SR-TE, rpd programável e túneis coloridos de PCEP. O BGP-CT usa a acessibilidade de próximo salto para resolver rotas de serviço na classe de transporte desejada.

Para permitir a resolução de rota de serviço BGP-CT em túneis coloridos sr-TE subjacentes, inclua a use-transport-class declaração no nível de [edit protocols source-packet-routing] hierarquia.

Mensagens do PathErr

As mensagens do PathErr relatam uma ampla variedade de problemas por meio de diferentes números de código e subcódigo. Você pode encontrar uma lista completa dessas mensagens do PathErr na RFC 2205, Resource Reservation Protocol (RSVP), Versão 1, Especificação funcional e RFC 3209, RSVP-TE: Extensões para RSVP para túneis LSP.

Quando você configura a rsvp-error-hold-time declaração, duas categorias de mensagens do PathErr, que representam especificamente falhas de link, são analisadas:

• A largura de banda do link é baixa para este LSP: Largura de banda solicitada indisponível — código 1, subcódigo 2

  Esse tipo de mensagem do PathErr representa um problema global que afeta todos os LSPs que transitam pelo link. Eles indicam que a largura de banda do link real é menor do que a exigida pelo LSP, e que é provável que as informações de largura de banda no banco de dados de engenharia de tráfego sejam superestimadas.

  Quando esse tipo de erro é recebido, a largura de banda do link disponível é reduzida no banco de dados local de engenharia de tráfego, afetando todas as computação LSP futuras.

• Link indisponível para este LSP:

  • Falha no controle de admissão — código 1, qualquer subcódigo, exceto 2

  • Falhas no controle de políticas — código 2

  • Serviço antecipado — código 12

  • Problema de roteamento — sem rota disponível para o destino — código 24, subcódigo 5

  Esses tipos de mensagens do PathErr geralmente são pertinentes ao LSP especificado. A falha desse LSP não implica necessariamente que outros LSPs também possam falhar. Esses erros podem indicar problemas de unidade de transferência máxima (MTU), preempção de serviço (seja iniciado manualmente pelo operador ou por outro LSP com maior prioridade), que um link de próximo salto está desativado, que um vizinho de próximo salto está desativado ou rejeição de serviços por causa de considerações de políticas. É melhor encaminhar esse LSP específico para longe do link.

Identificação do link do problema

Cada mensagem do PathErr inclui o endereço IP do remetente. Essas informações são propagadas inalteradas em direção ao roteador de entrada. Uma pesquisa no banco de dados de engenharia de tráfego pode identificar o nó que originou a mensagem do PathErr.

Cada mensagem do PathErr traz informações suficientes para identificar a sessão de RSVP que desencadeou a mensagem. Se este é um roteador de trânsito, ele simplesmente encaminha a mensagem. Se este roteador é o roteador de entrada (para esta sessão de RSVP), ele tem a lista completa de todos os nós e links que a sessão deve percorrer. Juntamente com as informações de nó de origem, o link pode ser identificado de forma exclusiva.

Configuração do roteador para melhorar a precisão do banco de dados da engenharia de tráfego

Para melhorar a precisão do banco de dados de engenharia de tráfego, configure a rsvp-error-hold-time declaração. Quando esta declaração é configurada, um nó de origem (entrada de um RSVP LSP) aprende com as falhas de seu LSP monitorando as mensagens PathErr transmitidas de nós downstream. As informações das mensagens do PathErr são incorporadas em cálculos LSP subsequentes, o que pode melhorar a precisão e a velocidade da configuração do LSP. Algumas mensagens do PathErr também são usadas para atualizar informações de largura de banda do banco de dados de engenharia de tráfego, reduzindo inconsistências entre o banco de dados de engenharia de tráfego e a rede.

Para configurar quanto tempo o MPLS deve se lembrar das mensagens RSVP PathErr e considerá-las na computação CSPF, inclua a rsvp-error-hold-time declaração:

Você pode incluir essa declaração nos seguintes níveis de hierarquia:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

O tempo pode ser um valor de 1 a 240 segundos. O padrão é de 25 segundos. Configurar um valor de 0 desativa o monitoramento das mensagens do PathErr.