Configuração da engenharia de tráfego MPLS

Uso de LSPs para encaminhamento de tráfego BGP e IGP

Você pode configurar o BGP e os IGPs para usar LSPs para encaminhar o tráfego destinado a roteadores de saída, incluindo a bgp-igp opção para a traffic-engineering declaração. A bgp-igp opção 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 instrução nos seguintes níveis de hierarquia:

• [edit protocols mpls]

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

  Observação:

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

Uso de LSPs para encaminhamento em redes privadas virtuais

As VPNs exigem que as rotas permaneçam na tabela de roteamento inet.3 para funcionar corretamente. Para VPNs, configure a bgp-igp-both-ribs opção da declaração para fazer com que o traffic-engineering BGP e os IGPs usem LSPs para encaminhar o tráfego destinado a roteadores de saída. A bgp-igp-both-ribs opção instala as rotas de entrada na tabela de roteamento inet.0 (para rotas unicast IPv4) e 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 instruçã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 instrução, as rotas da tabela inet.3 são copiadas para a tabela inet.0. As rotas copiadas são sinalizadas por LDP ou RSVP e provavelmente terão uma preferência inferior às outras rotas em inet.0. Rotas com preferência inferior têm maior probabilidade de serem escolhidas como rotas ativas. Isso pode ser um problema porque as políticas de roteamento agem apenas em rotas ativas. Para evitar esse problema, use a mpls-forwarding opção.

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

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

Se você configurar a mpls-forwarding opção para a declaração, os traffic-engineering LSPs serão usados para 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 dos próximos hops.

Quando você ativa a opção, as mpls-forwarding rotas cujo estado é ForwardingOnly são preferidas para encaminhamento, mesmo que sua preferência seja inferior à da rota ativa no momento. 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 rota, inclua a mpls-forwarding opção para a traffic-engineering declaração:

Você pode incluir essa instruçã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 do IGP são copiadas apenas para a tabela de roteamento inet.0.

Ao contrário da bgp-igp-both-ribs opção, a mpls-forwarding opção permite que você use as rotas sinalizadas por LDP e 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 o BGP e tenha uma rota BGP de 10.10.10.1/32 que precisa enviar para outro roteador BGP. Se você usar a bgp-igp-both-ribs opção e seu roteador também tiver um caminho comutado por rótulos (LSP) para 10.10.10.1, a rota MPLS para 10.10.10.1 se tornará ativa na tabela de roteamento inet.0. Isso impede que o roteador anuncie a rota 10.10.10.1 para o outro roteador BGP. Por outro lado, se você usar a mpls-forwarding opção em vez da bgp-igp-both-ribs opção, a rota BGP 10.10.10.1/32 será anunciada para o outro roteador BGP, e o LSP ainda será usado para encaminhar o tráfego para o destino 10.10.10.1.

Anunciando a métrica LSP em LSAs resumidos

Você pode configurar o MPLS e o 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 resumidos.

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

Você pode incluir essas instruçõ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 instruçã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 do Junos OS para dispositivos de roteamento.

Requisitos da engenharia de tráfego Inter-AS

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

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

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

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

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

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

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

Além disso, o endereço usado para o nó remoto do enlace de engenharia de tráfego passivo do OSPF deve ser o mesmo que o endereço usado para o enlace 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 da engenharia de tráfego Inter-AS

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

Além disso, as seguintes limitações se aplicam. Qualquer uma dessas condições é suficiente para impossibilitar os LSPs de engenharia de tráfego inter-AS, mesmo que os requisitos acima sejam atendidos.

• O uso de BGP multihop não é suportado.

• Não há suporte para o uso de policiais ou topologias que impedem que as rotas BGP sejam conhecidas dentro do AS.

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

• Não há suporte para refletores de rota ou políticas que ocultam informações ASBR ou impedem que informações ASBR sejam distribuídas dentro dos ASs.

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

• Não há suporte para topologias com caminhos inter-AS e intra-AS para o mesmo destino.

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

• Não há suporte para cores de link do grupo de administradores.

• Não há suporte para o modo de espera secundário.

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

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

• Não há suporte para cálculos de caminhos diversos.

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

Essas listas de limitações ou recursos não suportados com LSPs de engenharia de tráfego inter-AS não são exaustivas.

Configurando o modo TE passivo OSPF

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

Para inundar essas informações de endereço de link dentro do AS e disponibilizá-las 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 o OSPF distribuir e incluir 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 enlace no nível de [edit protocols ospf area area-id interface interface-name] hierarquia:

O OSPF deve ser configurado corretamente no roteador. O exemplo a seguir configura o enlace so-1/1/0 inter-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 de modo de transferência assíncrona (ATM) em um circuito virtual permanente (PVC). Cada pacote MPLS carrega um cabeçalho de encapsulamento de 4 bytes 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 é aplicado 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 à medida que atravessa uma rede de backbone MPLS.

Na borda de entrada do backbone MPLS, o cabeçalho IP é examinado pelo roteador de entrada. Com base nessa 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 maneira como um pacote IP pode ser atribuído a um LSP. Por exemplo, na implementação de engenharia de tráfego do Junos, todos os pacotes que chegam ao roteador de entrada que são destinados a sair do domínio MPLS no mesmo roteador de saída são encaminhados ao longo do mesmo LSP.

Quando 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 MPLS é tomada independentemente do cabeçalho IP original: a interface de entrada e o rótulo são usados como chaves de pesquisa 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 da rede. Para implementar o componente de distribuição de informações, são definidas extensões simples para os IGPs. Os atributos de enlace são incluídos como parte do anúncio de estado de enlace 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 de estado de enlace (LSAs) opacos. O algoritmo de flooding padrão usado pelos IGPs de estado de enlace garante que os atributos do enlace 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 enlace do IGP incluem largura de banda máxima do enlace, largura de banda máxima do enlace reservada, reserva de largura de banda atual e coloração do enlace.

Cada roteador mantém atributos de link de rede e informações de topologia em um banco de dados especializado em engenharia de tráfego. O banco de dados de engenharia de tráfego é usado exclusivamente para calcular caminhos explícitos para a colocação de LSPs na topologia física. Um banco de dados separado é mantido para que o cálculo de engenharia de tráfego subsequente 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 do caminho mais curto com base nas informações contidas no banco de dados de estado do enlace do roteador.

Componente de seleção de caminho

Depois que os atributos do link de rede e as informações de topologia são 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 estrita ou solta. 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 no LSP, o LSP será identificado por uma rota explícita estrita. Se o roteador de entrada especificar apenas alguns dos roteadores no LSP, o LSP será descrito como uma rota explícita solta. O suporte para rotas explícitas estritas e soltas permite que o processo de seleção de caminho tenha ampla latitude sempre que possível, mas seja restrito quando necessário.

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

• Informações de estado do 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 reservada do link, largura de banda disponível do link e cor do link) que são transportados por extensões IGP e armazenados no banco de dados de engenharia de tráfego

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

Como o CSPF considera cada nó e link 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 pela 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, que é responsável por estabelecer o estado do LSP e distribuir rótulos, depende de várias extensões para RSVP:

• O objeto Explicit Route permite que uma mensagem de caminho RSVP atravesse uma sequência explícita de roteadores que é independente do roteamento IP convencional de caminho mais curto. A rota explícita pode ser estrita ou flexível.

• O objeto Label Request permite que a mensagem de caminho RSVP solicite que os roteadores intermediários forneçam uma ligação de rótulos para o LSP que está estabelecendo.

• O objeto Label permite que o RSVP dê 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 dá suporte à distribuição de rótulos de nós downstream para nós upstream.

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 conectados diretamente 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
• 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] . 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.

Figura 1: Implementação do Junos OS da distribuição 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 lsdist.0 tabela para o banco de dados de engenharia de 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.

Observação:

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

Observação:

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

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.

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

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

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:

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:

Benefícios dos planos de transporte com classe BGP

• Fatiamento de rede — As camadas de serviço e transporte são desacopladas umas das outras, estabelecendo as bases para o fatiamento de rede e a virtualização 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 cooperativos para que os diferentes protocolos de sinalização de transporte em cada domínio interoperem. Reconcilia quaisquer diferenças entre namespaces de comunidade estendidos que possam estar em uso em cada domínio.

• Resolução colorida com fallback — Permite a resolução em 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 colorido.

• Qualidade de serviço — Personaliza e otimiza a rede para atender aos requisitos do SLA de ponta a ponta.
• Aproveitando as implantações existentes — oferece suporte a protocolos de tunelamento bem implantados, como RSVP, juntamente com novos protocolos, como o algoritmo flexível IS-IS, preservando o ROI e reduzindo as despesas operacionais.

Terminologia dos planos de transporte com classe BGP

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 do 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) rotuladas de BGP.

• BGP-VPN — VPNs criadas usando mecanismos RFC4364.

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

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

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

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

• Família de serviços — família de endereços BGP usada para anunciar rotas para tráfego de dados, em oposição a túneis.

• Família de transporte – família de endereços BGP usada para anunciar túneis, 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 abrangendo vários domínios de túnel adjacentes pode ser criado unindo 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 destino 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.

• RIB de transporte — No nó de serviço e no nó de borda, uma classe de transporte tem um RIB de transporte associado que mantém suas rotas de túnel.

• Instância de roteamento RTI de transporte — A; contêiner de transporte RIB e classe de transporte associada Route Target e Route Distinguisher.

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

• Comunidade de mapeamento — Comunidade em uma rota de serviço que mapeia para resolver em uma classe de transporte.

Entender os planos de transporte com classe BGP

Você pode usar planos de transporte com classe BGP para configurar classes 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 fallback pretendido.

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 IGP), preservando a classe de transporte. Para fazer isso, você deve configurar a família BGP de camada de transporte com classe BGP entre a borda e os nós de serviço.

Em implementações inter-AS e intra-AS, pode haver muitos túneis de transporte (LSPs MPLS, algoritmo flexível IS-IS, SR-TE) criados a partir dos nós de serviço e borda. 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 o 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 resolver serviços sobre LSPs com certas características de engenharia de tráfego 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 fracamente acoplados e coordenados.

• As informações de alcance da camada de rede (NLRI) são RD:TunnelEndpoint usadas para ocultar caminhos.
• O destino da rota indica a classe de transporte dos LSPs e vaza 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 do túnel como um alvo de rota VPN e coleta os LSPs da mesma classe de transporte na tabela de roteamento transport-class.inet.3 transport-rib.

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

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

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

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

• Você pode resolver rotas de serviço e rotas de transporte com classe BGP sobre essas classes de transporte, transportando a comunidade de mapeamento nelas.

A família de transporte com classe BGP corre ao lado da família de camadas de transporte BGP-LU. Em uma rede MPLS perfeita que executa BGP-LU, atender aos requisitos SLAs rigorosos do 5G é um desafio, pois as características de engenharia de tráfego dos túneis não são conhecidas ou preservadas além dos limites do domínio. Os planos de transporte com classe BGP fornecem meios operacionalmente fáceis e escaláveis para anunciar vários caminhos para loopbacks remotos junto com as informações de classe de transporte na arquitetura MPLS perfeita. Nas rotas da família de transporte com classe BGP, diferentes caminhos SLA são representados usando a comunidade estendida Transport Route-Target, que carrega a cor da classe de transporte. Esse destino de rota de transporte é usado pelos roteadores BGP receptores 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 de rotas, interconecta 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

A 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 o túnel de transporte e todas as rotas do túnel de transporte são instaladas no inet.3 RIB. A implementação de planos de classificação com classe BGP permite que os túneis de transporte RSVP tenham reconhecimento de cores, semelhante aos túneis de roteamento por segmentos.

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

Para classificar 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 de exemplo:

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

   Configuração de exemplo:

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

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

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

• O nó de serviço (PEs de entrada) faz a correspondência da comunidade de cores estendida (cor:0:100 e cor:0:200) da rota de serviço com a comunidade de mapeamento em RIBs de resolução predefinida e resolve o próximo salto do protocolo (PNH) nas RIBs de transporte correspondentes (junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>.inet.3).
• As rotas BGP se vinculam a um esquema de resolução carregando a comunidade de mapeamento assiocaited.
• Cada classe de transporte cria automaticamente dois esquemas de resolução predefinidos e deriva automaticamente a comunidade de mapeamento.

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

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

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

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

Em uma rede inter-AS, o BGP-LU é convertido em uma rede de transporte com classe BGP após a configuração de 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 de exemplo:

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 de exemplo:

   Para LSPs RSVP

   Para o algoritmo flxible IS-IS

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

   Configuração de exemplo:

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

   Configuração de exemplo:

Funcionalidade do plano de transporte com classe Inter-AS BGP:

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

2. As rotas de transporte intra-AS são preenchidas 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 gold e bronze são instaladas nos RIBs de transporte junos-rti-tc-<100>.inet.3 e junos-rti-tc-<200>.inet.3, respectivamente.

3. Os planos de transporte com classe BGP usam o Diferenciador de Rota e o Destino de Rota exclusivos quando copiam as rotas do túnel de transporte de cada RIB de transporte para a tabela de roteamento bgp.transport.3.
4. Os nós de borda anunciam rotas da tabela de roteamento bgp.transport.3 para seus pares em outros domínios se o transporte inet familiar for negociado na sessão BGP.
5. O nó de borda receptor instala essas rotas bgp-ct na tabela de roteamento bgp.transport.3 e copia essas rotas com base no destino da rota de transporte para os RIBs de transporte apropriados.
6. O nó de serviço combina a comunidade de cores na rota de serviço com uma comunidade de mapeamento nos esquemas de resolução e resolve a PNH no RIB de transporte correspondente ( junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>.inet.3).
7. Os nós de borda usam esquemas de resolução predefinidos para resolução de PNH de rota de transporte.
8. Predefinidos ou definidos pelo usuário, ambos os esquemas de resolução suportam a resolução PNH da rota de serviço. Predefinido usa inet.3 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 durante a resolução de HPN.
9. Se o PNH da rota de serviço não puder ser resolvido usando RIBs listados no esquema de resolução definido pelo usuário, a rota será descartada.

Mensagens do PathErr

As mensagens 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 PathErr no 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 PathErr, que representam especificamente falhas de link, são examinadas:

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

  Esse tipo de mensagem PathErr representa um problema global que afeta todos os LSPs que transitam pelo link. Eles indicam que a largura de banda real do link é 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 de engenharia de tráfego local, afetando todos os cálculos futuros de LSP.

• Link indisponível para este LSP:

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

  • Falhas de controle de política — código 2

  • Service Preempted — código 12

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

  Esses tipos de mensagens PathErr geralmente são pertinentes ao LSP especificado. O fracasso deste 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 (iniciada manualmente pelo operador ou por outro LSP com prioridade mais alta), que um link de próximo salto está inativo, que um vizinho de próximo salto está inativo ou rejeição de serviço devido a considerações de política. É melhor direcionar esse LSP específico para longe do link.

Identificando o link do problema

Cada mensagem 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 PathErr.

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

Configurando o roteador para melhorar a precisão do banco de dados de 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 essa declaração é configurada, um nó de origem (entrada de um LSP RSVP) aprende com as falhas de seu LSP monitorando mensagens PathErr transmitidas de nós downstream. As informações das mensagens do PathErr são incorporadas aos cálculos LSP subsequentes, o que pode melhorar a precisão e a velocidade da configuração do LSP. Algumas mensagens PathErr também são usadas para atualizar as informações de largura de banda do banco de dados de engenharia de tráfego, reduzindo as inconsistências entre o banco de dados de engenharia de tráfego e a rede.

Para configurar por 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 instruçã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 é 25 segundos. A configuração de um valor de 0 desabilita o monitoramento de mensagens PathErr.