Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS de engenharia de tráfego

MPLS e engenharia de tráfego

A engenharia de tráfego permite controlar o caminho que os pacotes de dados seguem, burlando o modelo de roteamento padrão, que usa tabelas de roteamento. A engenharia de tráfego move fluxos de links congestionados para links alternativos que não seriam selecionados pelo caminho mais curto baseado em destino com base em destino automaticamente computado. Com a engenharia de tráfego, você pode:

  • Faça uso mais eficiente de fibras de longa distância caras.

  • Controle como o tráfego é rearrafado diante de falhas individuais ou múltiplas.

  • Classifique tráfego crítico e regular por caminho.

O núcleo do design da engenharia de tráfego baseia-se na criação de caminhos comutado por rótulos (LSPs) entre os roteadores. Um LSP é orientado para a conexão, como um circuito virtual no Frame Relay ou no ATM. LSPs não são confiáveis: Os pacotes que entram em um LSP não têm garantias de entrega, embora o tratamento preferencial seja possível. Os LSPs também são semelhantes aos túneis unidirecionais nos pacotes que entram em um caminho são encapsulados em um envelope e alternados por todo o caminho sem serem tocados por nós intermediários. Os LSPs fornecem controle abrangente sobre como os pacotes são encaminhados em uma rede. Para fornecer confiabilidade, um LSP pode usar um conjunto de caminhos principais e secundários.

Os LSPs podem ser configurados apenas para BGP tráfego (tráfego cujo destino está fora de um sistema autônomo [AS]). Nesse caso, o tráfego dentro do AS não é afetado pela presença de LSPs. LSPs também podem ser configurados para tráfego BGP gateway interior e (IGP). portanto, tráfego intra-AS e inter-AS é afetado pelos LSPs.

visão MPLS de protocolos de engenharia de tráfego e sinalização

A engenharia de tráfego facilita operações de rede eficientes e confiáveis, ao mesmo tempo em que otimiza os recursos de rede e o desempenho do tráfego. A engenharia de tráfego oferece a capacidade de afastar o fluxo de tráfego do caminho mais curto selecionado pelo protocolo de gateway interior (IGP) para um caminho físico potencialmente menos congestionado em uma rede. Para dar suporte à engenharia de tráfego, além do roteamento de origem, a rede deve fazer o seguinte:

  • Compute um caminho na origem levando em consideração todas as restrições, como largura de banda e requisitos administrativos.

  • Distribuir as informações sobre a topologia de rede e os atributos de link em toda a rede quando o caminho for computado.

  • Reserve recursos de rede e modifique atributos de enlace.

Quando o tráfego de trânsito é roteado por uma rede IP, MPLS costuma ser usado para engenheiros de sua passagem. Embora o caminho exato pela rede de trânsito seja de pouca importância para o remetente ou o receptor do tráfego, os administradores de rede costumam querer rotear o tráfego com mais eficiência entre determinados pares de endereços de origem e destino. Ao adicionar um rótulo curto com instruções de roteamento específicas a cada pacote, MPLS pacotes de switches do roteador ao roteador pela rede em vez de encaminhamento de pacotes com base em lookups de next-hop. As rotas resultantes são chamadas de caminhos comutado por rótulos (LSPs). Os LSPs controlam a passagem do tráfego pela rede e aceleram o encaminhamento do tráfego.

Você pode criar LSPs manualmente ou por meio do uso de protocolos de sinalização. Protocolos de sinalização são usados em um ambiente MPLS para estabelecer LSPs para tráfego em uma rede de trânsito. O Junos OS tem suporte para dois protocolos de sinalização: LDP e o Protocolo de Reserva de Recursos (RSVP).

engenharia de tráfego de MPLS usa os seguintes componentes:

  • MPLS LSPs para encaminhamento de pacotes

  • IGP extensões para distribuição de informações sobre a topologia de rede e os atributos de enlace

  • Primeiro caminho mais curto restrito (CSPF) para a computação de caminho e a seleção de caminhos

  • Extensões de RSVP para estabelecer o estado de encaminhamento ao longo do caminho e reservar recursos ao longo do caminho

O Junos OS também tem suporte para engenharia de tráfego em diferentes OSPF regiões.

Recursos de engenharia de tráfego

A tarefa de mapear fluxos de tráfego para uma topologia física existente é chamada de engenharia de tráfego. A engenharia de tráfego oferece a capacidade de afastar o fluxo de tráfego do caminho mais curto selecionado pelo protocolo de gateway interior (IGP) e em um caminho físico potencialmente menos congestionado em uma rede.

A engenharia de tráfego fornece os recursos para fazer o seguinte:

  • Rotee caminhos principais em torno de gargalos ou pontos de congestionamento conhecidos na rede.

  • Forneça controle preciso sobre como o tráfego é rearrafado quando o caminho principal enfrenta falhas individuais ou múltiplas.

  • Forneça um uso mais eficiente da largura de banda agregada disponível e da fibra de longa distância, garantindo que os subconjuntos da rede não se tornem superutilizados, enquanto outros subconjuntos da rede ao longo de caminhos alternativos potenciais são subutilizados.

  • Maximize a eficiência operacional.

  • Aprimora as características de desempenho orientadas ao tráfego da rede, minimizando a perda de pacotes, minimizando períodos longos de congestionamento e maximizando a taxa de transferência.

  • Aprimora características de desempenho associadas a estatísticas da rede (como razão de perda, variação de atraso e atraso de transferência) necessárias para dar suporte a uma Internet multisserviço.

Componentes da engenharia de tráfego

No sistema operacional Junos® sistema operacional (OS), a engenharia de tráfego é implementada com MPLS e RSVP. A engenharia de tráfego é formada por quatro componentes funcionais:

Configurando a engenharia de tráfego para LSPs

Quando você configura um LSP, uma rota de host (uma máscara de 32 bits) é instalada no roteador de entrada em direção ao roteador de saída; o endereço da rota do host é o endereço de destino do LSP. A opção para a instrução em nível de hierarquia é ativada por padrão (você também pode configurar explicitamente a opção), permitindo apenas BGP usar LSPs em seus cálculos bgptraffic engineering de [edit protocols mpls]bgp rota. As outras traffic-engineering opções de instrução permitem alterar esse comportamento na instância de roteamento mestre. Essa funcionalidade não está disponível para instâncias de roteamento específicas. Além disso, você pode habilitar apenas uma das opções de declaração traffic-engineeringbgpbgp-igp (, bgp-igp-both-ribsmpls-forwarding ou) de cada vez.

Nota:

A ativação ou desativação de qualquer uma das opções de instrução faz com que todas as MPLS sejam removidas e, em seguida, traffic-engineering reinsertadas nas tabelas de roteamento.

Você pode configurar OSPF engenharia de tráfego para anunciar a métrica LSP em anúncios de estado de enlace resumido (LSAs), conforme descrito na seção Anunciar a métrica de LSP em LSAs resumidos .

As seções a seguir descreverão como configurar a engenharia de tráfego para LSPs:

Usando LSPs para BGP e IGP tráfego

Você pode configurar BGP e os IGPs para usar LSPs para encaminhamento de tráfego destinado a roteadores de saída, incluindo a bgp-igp opção da traffic-engineering declaração. A opção faz com que todas as bgp-igp rotas do inet.3 sejam transferidas 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 bgp-igp opção da declaração não pode ser traffic-engineering configurada para VPN). As VPNs exigem que as rotas sejam fornecidas na tabela de roteamento inet.3.

Usando 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 opção da instrução para fazer com que BGP e os IGPs usem LSPs para encaminhamento de tráfego destinado a roteadores de bgp-igp-both-ribstraffic-engineering saída. A opção instala as rotas de entrada na tabela de roteamento inet.0 (para rotas unicast IPv4) e na tabela de roteamento bgp-igp-both-ribs inet.3 (para MPLS de caminho).

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 instrução, as rotas da tabela inet.3 são copiadas na tabela inet.0. As rotas copiadas são sinaladas por LDP ou sinal de RSVP, e provavelmente têm uma preferência inferior à de outras rotas na inet.0. Rotas com preferência inferior têm mais probabilidade de 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 mpls-forwarding opção.

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

Se você configurar as ou opções da declaração, os LSPs de alta prioridade podem sobressar IGP rotas na tabela de roteamento bgp-igpbgp-igp-both-ribstraffic-engineering inet.0. IGP rotas podem não ser mais redistribuídas, uma vez que elas não são mais as rotas ativas.

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

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

Para usar LSPs para encaminhamento, mas exclui-los da seleção de roteamento, inclua a mpls-forwarding opção da 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]

Ao configurar a opção, IGP rotas de atalho são copiadas apenas para a tabela de roteamento mpls-forwarding inet.0.

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

Por exemplo, imagine que um roteador está em execução BGP e que tenha uma rota BGP de 10.10.10.1/32 que ele precisa enviar para outro BGP alto-falante. Se você usar a opção, e seu roteador tiver um caminho de comutado por bgp-igp-both-ribs rótulos (LSP) até 10.10.10.1, a rota de MPLS para 10.10.10.1 torna-se ativa na tabela de roteamento inet.0. Isso impede o roteador de anunciar a rota 10.10.10.1 para o outro BGP roteador. Por outro lado, se você usar a opção em vez da opção, a rota de BGP 10.10.10.1/32 será anunciada para o outro BGP, e o LSP ainda é usado para encaminhamento do tráfego para o destino mpls-forwardingbgp-igp-both-ribs 10.10.10.10.1.

Anunciar a métrica de LSP em LSAs resumidos

Você pode configurar MPLS e OSPF tratar um LSP como um enlace. Essa configuração permite que outros roteadores da rede utilizem esse LSP. Para alcançar esse objetivo, você precisa configurar MPLS e OSPF de tráfego para anunciar a métrica LSP em LSAs resumida.

Para MPLS, inclua as traffic-engineering bgp-igp e label-switched-path 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 OSPF engenharia de tráfego, consulte a Biblioteca de Protocolos de Roteamento junos OS para dispositivos de roteamento.

Possibilitando a engenharia de tráfego entre áreas

O Junos OS pode sinalizar um LSP contíguo projetado para tráfego em várias OSPF áreas. A sinalização de LSP deve ser feita usando-se sinalização contígua ou aninhada, como descrito na RFC 4206, Hierarquia de Caminhos Comuados por Rótulos (LSP) com Engenharia de Tráfego generalizada de Rótulos Multi-Protocolo (GMPLS) (TE).. Entretanto, o suporte de sinalização contígua se limita apenas à sinalização básica. A reoptimização não é suportada com sinalização contígua.

Os seguintes recursos de engenharia de tráfego entre áreas são descritos:

  • A engenharia de tráfego Interarea pode ser ativada quando os roteadores de borda da área de salto solto (ABRs) estão configurados no roteador de entrada usando CSPF para o cálculo de ERO (Explicit Route Object) em uma área de OSPF. A expansão de ERO é concluída nas ABRs.

  • A engenharia de tráfego Interarea pode ser habilitada quando o CSPF está ativado, mas sem ABRs especificados na configuração LSP no roteador de ingresso (ABRs podem ser designados automaticamente).

  • A engenharia de tráfego de serviços diferenciados (DiffServ) é suportada desde que os mapeamentos de classe sejam uniformes em várias áreas.

Para habilitar a engenharia de tráfego entre áreas, inclua a expand-loose-hop declaração na configuração de cada roteador de trânsito LSP:

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

  • [edit protocols mpls]

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

Ativação da engenharia de tráfego inter-AS para LSPs

Em geral, a engenharia de tráfego é possível para LSPs que atendem às seguintes condições:

  • Ambas as extremidades do LSP estão na mesma área OSPF ou no mesmo nível IS-IS nível.

  • As duas extremidades do LSP estão em áreas OSPF diferentes dentro do mesmo sistema autônomo (AS). LSPs que terminam em níveis IS-IS diferentes não são suportados.

  • As duas extremidades de um LSP de caminho explícito estão em diferentes OSPF ASs e os roteadores de borda do sistema autônomo (ASBRs) estão configurados estaticamente conforme os hops soltos suportados no LSP do caminho explícito. Para obter mais informações, consulte Configurar LSPs de caminho explícito.

Sem ASBRs definidos estáticamente em LSPs, a engenharia de tráfego não é possível entre um domínio de roteamento ou AS e outro. No entanto, quando os ASs estão sob o controle de um único provedor de serviços, em alguns casos, é possível que LSPs projetados por tráfego abrangem os ASs e descubram dinamicamente os ASBRs OSPF que os vinculam (IS-IS não é suportado por esse recurso).

LSPs de tráfego inter-AS são possíveis, desde que determinados requisitos de rede sejam atendidos, nenhuma das condições limitantes se aplique e OSPF modo passivo está configurado com EBGP. Os detalhes são fornecidos nas seções a seguir:

Requisitos de engenharia de tráfego inter-AS

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

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

  • 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 de ASBR estão disponíveis dentro de cada AS.

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

  • Os LSPs de trânsito não estão configurados nos links inter-AS, mas sim configurados entre ASBRs 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 de engenharia de tráfego passivo em OSPF. O endereço do enlace remoto, não o loopback ou qualquer outro endereço de enlace, é usado como o identificador de nó remoto para este enlace passivo. Para obter mais informações sobre OSPF configuração do modo de engenharia de tráfego passivo, consulte Configurando o OSPF Passivo TE Modo .

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

Limitações da engenharia de tráfego inter-AS

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

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

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

  • O uso de agentes de polícia ou topologias que impedem BGP rotas conhecidas dentro do AS não é suportado.

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

  • Não são suportados refletores ou políticas de roteações que ocultam informações asBR ou impedem que as informações das ASBR sejam distribuídas dentro dos ASs.

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

  • Topologias com caminhos inter-AS e intra-AS até o mesmo destino não são suportadas.

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

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

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

  • Não há suporte para reoptimização.

  • Não há suporte para um rebarbado em roteadores de trânsito.

  • Cálculo de caminho diversificado não é suportado.

  • Não há suporte para reinicialização graciosa.

Essas listas de limitações ou recursos não compatíveis com LSPs inter-AS projetados para tráfego não são exaustivas.

Configurando o OSPF Passivo TE Modo

Normalmente, protocolos de roteamento interior, como OSPF, não são executados em links entre ASs. Entretanto, para que a engenharia de tráfego inter-AS funcione corretamente, as informações sobre o enlace inter-AS, em especial, o endereço na interface remota, devem ser disponibilizadas dentro do AS. Normalmente, essas informações não são incluídas nas mensagens de alcance do EBGP ou OSPF anúncios de roteamento.

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

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

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

Componente de Encaminhamento de Pacotes

O componente de encaminhamento de pacotes da arquitetura de engenharia de tráfego junos é MPLS, que é responsável por direcionar um fluxo de pacotes IP ao longo de um caminho pré-determinado em uma rede. Esse caminho é chamado de caminho comutado por rótulos (LSP). LSPs são simples; ou seja, o tráfego flue em uma direção, desde o roteador de entrada (entrada) até um roteador de saída (saída). O tráfego duplex requer dois LSPs: um LSP para transportar tráfego em cada direção. Um LSP é criado pela concatenação de um ou mais hops comutado por rótulos, permitindo que um pacote seja encaminhado de um roteador para outro no domínio MPLS.

Quando um roteador de entrada recebe um pacote IP, ele adiciona um MPLS ao pacote e o encaminha ao próximo roteador no LSP. O pacote rótulo é encaminhado ao longo do LSP por cada roteador até chegar à ponta traseira do LSP, o roteador de saída. Nesse ponto, o MPLS de segurança é removido e o pacote é encaminhado com base em informações da Camada 3, como o endereço de destino IP. O valor desse esquema é que o caminho físico do LSP não se limita ao que a IGP escolheria como o caminho mais curto para chegar ao endereço IP de destino.

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 Assíncrono de Modo de Transferência (ATM) em um circuito virtual permanente (PVC). Cada MPLS de pacote transporta um encarte de encapsulamento de 4 byte que contém um campo de rótulos de comprimento fixo de 20 bits. Quando um pacote contendo um rótulo chega em um roteador, o roteador examina o rótulo e o copia como um índice para sua tabela de MPLS de encaminhamento. Cada entrada na tabela de encaminhamento contém um par de rótulos de interface de entrada mapeado para um conjunto de informações de encaminhamento aplicadas a todos os pacotes que chegam à interface específica com o mesmo rótulo de entrada.

Como um pacote atravessa uma base MPLS backbone

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

Na borda de entrada do MPLS backbone, o header IP é analisado pelo roteador de entrada. Com base nesta análise, o pacote é classificado, atribuído a um rótulo, encapsulado em um MPLS e encaminhado em direção ao próximo hop no LSP. MPLS fornece um alto grau de flexibilidade na forma como um pacote DE IP pode ser atribuído a um LSP. Na implementação da engenharia de tráfego Junos, por exemplo, 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 ao longo do 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 MPLS de encaminhamento é tomada independentemente do header IP original: a interface e o rótulo de entrada são usados como chaves de MPLS de encaminhamento. 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é o pacote chegar 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 de saída. Em seguida, o pacote é encaminhado com base no endereço IP de destino contido no header 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 de rede e informações dinâmicas sobre o carregamento da rede. Para implementar o componente de distribuição das informações, são definidas extensões simples para os IGPs. Os atributos de enlace são incluídos como parte do anúncio do estado de enlace de cada roteador. IS-IS extensões incluem a definição de novos valores de comprimento do tipo (TLVs), enquanto OSPF extensões são implementadas com anúncios opacos de estado de enlace (LSAs). O algoritmo de inundação padrão usado pelos IGPs de estado de enlace garante que os atributos de enlace sejam distribuídos a todos os roteadores do domínio do roteamento. Algumas das extensões de engenharia de tráfego a serem adicionadas ao IGP de estado de enlace incluem largura de banda máxima do enlace, largura de banda de enlace reserva, reserva de largura de banda atual e coloração de enlace.

Cada roteador mantém atributos de enlace de rede e informações de topologia em um banco de dados de engenharia de tráfego especializado. 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 a computação de engenharia de tráfego posterior seja independente da IGP e do IGP de estados de enlace. Enquanto isso, a IGP continua sua operação sem modificação, realizando o cálculo tradicional do caminho mais curto com base nas informações contidas no banco de dados de estados de enlace do roteador.

Componente de seleção de caminho

Depois que atributos de enlace de rede e informações de topologia são inundadas pelo IGP e colocadas 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 de seu próprio conjunto de LSPs no domínio do roteamento. O caminho de cada PSL pode ser representado por uma rota explícita rigorosa 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 do LSP, o LSP deve ser identificado por uma rota rigorosa e explícita. Se o roteador de entrada especificar apenas alguns dos roteadores no LSP, o LSP será descrito como uma rota explícita frouxa. O suporte a rotas explícitas rigorosas e soltas permite que o processo de seleção de caminhos seja dado a uma ampla latitude sempre que possível, mas que seja limitado quando necessário.

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

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

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

  • Atributos administrativos necessários para dar suporte ao tráfego que atravessa o LSP proposto (como requisitos de largura de banda, contagem máxima de hop e requisitos de política administrativa) obtidos da configuração do usuário

Conforme o CSPF considera cada nó e link de candidato para um novo LSP, ele aceita ou recusa um componente de caminho específico com base na disponibilidade do recurso 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

Sabe-se que um LSP pode funcionar até que ele seja estabelecido pelo componente de sinalização. O componente de sinalização, responsável por estabelecer o estado do LSP e distribuir rótulos, depende de várias extensões para RSVP:

  • O objeto Roteamento Explícito permite que uma mensagem de caminho RSVP atravesse uma sequência explícita de roteadores que é independente do roteamento IP de menor caminho convencional. A rota explícita pode ser rigorosa ou frouxa.

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

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

Planejamento e análise de caminhos offline

Apesar do esforço de gerenciamento reduzido decorrente do cálculo do caminho on-line, uma ferramenta de planejamento e análise offline ainda é necessária para otimizar a engenharia de tráfego globalmente. O cálculo online leva em consideração as restrições dos recursos e calcula um LSP por vez. O desafio dessa abordagem é que ela não é determinística. A ordem na qual os LSPs são calculados desempenha um papel crítico na determinação do caminho físico de cada LSP pela rede. LSPs que são calculados no início do processo têm mais recursos disponíveis do que LSPs calculados mais tarde no processo porque LSPs previamente calculados consomem recursos de rede. Se a ordem na qual os LSPs são calculados for alterada, o conjunto de caminhos físicos resultantes para os LSPs também pode mudar.

Uma ferramenta de planejamento e análise offline examina simultaneamente as restrições de recursos de cada enlace e os requisitos de cada LSP. Embora a abordagem offline possa levar várias horas para ser concluída, ela realiza cálculos globais, compara os resultados de cada cálculo e escolhe a melhor solução para a rede como um todo. A saída do cálculo offline é um conjunto de LSPs que otimiza a utilização de recursos de rede. Após o cálculo offline ser concluído, os LSPs podem ser estabelecidos em qualquer ordem, porque cada um é instalado de acordo com as regras da solução globalmente otimizada.

Cálculo e configuração flexíveis de LSP

A engenharia de tráfego envolve o mapeamento do fluxo de tráfego em uma topologia física. Você pode determinar os caminhos on-line usando o roteamento baseado em restrições. Independentemente de como o caminho físico é calculado, o estado de encaminhamento é instalado na rede por meio de RSVP.

O Junos OS tem suporte para as seguintes maneiras de rotear e configurar um LSP:

  • Você pode calcular o caminho completo para o LSP offline e configurar individualmente cada roteador no LSP com o estado de encaminhamento estático necessário. Isso é análogo à maneira como alguns provedores de serviços de Internet (ISPs) configuram seus núcleos IP-over-ATM.

  • Você pode calcular o caminho completo para o LSP offline e configurar estáticamente o roteador de entrada com o caminho completo. O roteador de entrada usa RSVP como um protocolo de sinalização dinâmica para instalar um estado de encaminhamento em cada roteador ao longo do LSP.

  • Você pode confiar no roteamento baseado em restrições para realizar cálculos dinâmicos de LSP on-line. Você configura as restrições de cada LSP; e a própria rede determina o caminho que melhor atende a essas restrições. Especificamente, o roteador de entrada calcula todo o LSP com base nas restrições e inicia a sinalização em toda a rede.

  • Você pode calcular um caminho parcial para um LSP offline e configurar estaticamente o roteador de entrada com um subconjunto dos roteadores no caminho; então você pode permitir o cálculo on-line para determinar o caminho completo.

    Por exemplo, considere uma topologia que inclui dois caminhos leste-oeste nos Estados Unidos: uma no norte, passando por Chicago e outra no sul por Dallas. Se você quiser estabelecer um LSP entre um roteador em Nova York e um em São Francisco, você pode configurar o caminho parcial para o LSP incluir um único hop de roteador com roteamento frouxo em Dallas. O resultado é um LSP roteado pelo caminho sul. O roteador de entrada usa CSPF para calcular o caminho completo e o RSVP para instalar o estado de encaminhamento ao longo do LSP.

  • Você pode configurar o roteador de entrada sem qualquer restrição. Nesse caso, o roteamento IGP caminho mais curto é usado para determinar o caminho do LSP. Essa configuração não fornece nenhum valor em termos de engenharia de tráfego. No entanto, é fácil e pode ser útil em situações em que serviços como VPNs (Virtual Private Networks, redes privadas virtuais) são necessários.

Em todos esses casos, você pode especificar qualquer número de LSPs como backups para o LSP principal, permitindo que você combine mais de uma abordagem de configuração. Por exemplo, você pode calcular explicitamente o caminho principal offline, definir o caminho secundário como baseado em restrições e não restringir o caminho do terciário. Se um circuito no qual o LSP principal é roteado falhar, o roteador de entrada notará a paralisação das notificações de erro recebidas de um roteador downstream ou pelo expiramento de informações de estado mole do RSVP. Em seguida, o roteador encaminha o tráfego dinamicamente para um LSP de espera quente ou solicita que RSVP crie um estado de encaminhamento para um novo LSP de backup.

BGP visão geral dos planos de transporte com classe

Benefícios dos BGP de transporte com classe

  • Fatiamentode rede – Camadas de serviço e transporte são desconectadas umas das outras, estabelecendo a base para o fatiamento e a virtualização de rede com o fatiamento completo em vários domínios, reduzindo significativamente o CAPEX.

  • Interoperabilidade entre domínios– Amplia a implantação da classe de transporte em domínios co-operacionais para que os diferentes protocolos de sinalização de transporte em cada domínio interoperem. Reconcilia quaisquer diferenças entre espaços de nome de comunidade estendidos que possam estar em uso em cada domínio.
  • Resolução colorida com repercussão– Permite a resolução sobre túneis coloridos (RSVP, IS-IS algoritmo flexível) com opções de retorno flexíveis em túneis de melhor esforço ou em qualquer outro túnel de cores.

  • Qualidade de serviço– Personaliza e otimiza a rede para atingir os requisitos completos de SLA.
  • Aproveitar as implantações existentes – Aceita protocolosde tunelamento bem implantados, como RSVP, junto com novos protocolos, como um algoritmo IS-IS flexível, preservando ROI e reduzindo o OPEX.

Terminologia dos BGP de transporte com classe

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

  • Nó deserviço –Dispositivos de borda do provedor de entrada (PE) que enviam e recebem rotas de serviço (Internet e VPN de Camada 3).

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

  • Nó detransporte – Dispositivo que envia e recebe BGP rotas Unicast (LU) etiquetadas.

  • BGP-VPN –VPNscriadas usando mecanismos RFC4364.

  • Rotear Target (RT)– Tipo de comunidade estendida usada para definir filiação a VPN.

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

  • Esquema deresolução – Usado para resolver o endereço de next-hop (PNH) na resolução de RIBs que fornece retorno.

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

  • Família deserviços – BGP endereço da família usado para rotas de publicidade para tráfego de dados, em vez de túneis.

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

  • Túnel detransporte – Um túnel no qual um serviço pode colocar tráfego, por exemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

  • Domínio detú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únel adjacentes pode ser criado unindo os nós usando rótulos.

  • Classe detransporte – Um grupo de túneis de transporte que oferece a mesma 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 do Route Target usado para identificar uma classe de transporte específica.
  • RIB detransporte – No nó de serviço e no nó de borda, uma classe de transporte tem uma RIB de transporte citada que mantém suas rotas de túnel.

  • RTI detransporte – uma instância de roteamento; contêiner de transporte RIB e diferencial de rota de classe de transporte associado.

  • Plano detransporte – Conjunto de RTIs de transporte que importa a mesma classe de transporte RT. Eles são, por sua vez, costurados para atravessar os limites do domínio do túnel usando um mecanismo semelhante à opção Inter-AS-b para trocar rótulos nos nós de borda (nexthop-self), formando um plano de transporte de ponta a ponta.

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

Compreender BGP de transporte com classe

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

BGP de transporte com classe podem estender esses túneis até redes entre domínios que abrangem vários domínios (ASs ou IGP áreas) enquanto preservam a classe de transporte. Para isso, você deve configurar a BGP de transporte com classe BGP família entre a borda e os nós de serviço.

Nas implementações inter-AS e intra-AS, pode haver muitos túneis de transporte (MPLS LSPs, IS-IS algoritmo flexível, SR-TE) criados a partir dos nós de serviço e de borda. Os LSPs podem ser sinalizedos 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 funciona como o endpoint do serviço e pode estar presente no mesmo domínio de túnel do nó de entrada do serviço ou em um domínio adjacente ou não adjacente. Você pode usar BGP de transporte com classe para reaperperar serviços em LSPs com determinadas caráterísticas de engenharia de tráfego, seja em um único domínio ou em vários domínios.

BGP de transporte com classe reutilizar a tecnologia BGP-VPN, mantendo os domínios de tunelamento vagamente a par e coordenados.

  • As informações de alcance da camada de rede (NLRI) são RD:TunnelEndpoint usado para ocultar o caminho.
  • O alvo da rota indica a classe de transporte dos LSPs e as rotas de fuga para o RIB de transporte correspondente no dispositivo de destino.
  • Cada protocolo de túnel de transporte instala uma rota de entrada na tabela de roteamento.inet.3 da categoria de transporte, modela a classe de transporte de túnel como um alvo de rota DE VPN e coleta os LSPs da mesma classe de transporte na tabela de roteamento transport-rib.inet.3.
  • As rotas nesta instância de roteamento são anunciadas no plano de transporte BGP classe AFI-SAFI seguindo procedimentos semelhantes a RFC-4364.

  • Ao atravessar a fronteira do enlace 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 atravessar regiões intra-AS, você deve seguir os procedimentos da Opção-b para costurar os túneis de transporte nos TE domínios diferentes.

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

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

A BGP de transporte de classe é gerenciada junto à família BGP-LU de transporte. Em uma rede MPLS contínua em execução BGP-LU, atender aos requisitos rigorosos de SLA do 5G é um desafio, pois as características de engenharia de tráfego dos túneis não são conhecidas ou preservadas entre os limites do domínio. BGP de transporte com classe fornecem meios operacionalmente fáceis e escaláveis para anunciar vários caminhos para loopbacks remotos, juntamente com as informações de classe de transporte na arquitetura MPLS contínua. Em BGP de família de transporte com classe, diferentes caminhos de SLA são representados usando a comunidade estendida Transport Route-Target, que transporta a cor da classe de transporte. Esse Rote-Target de transporte é usado pelos roteadores BGP recebimento para associar a BGP de transporte com a classe de transporte adequada. Ao re-anunciar as BGP de transporte com classe, MPLS troca de rotas, a inter conecta os túneis intra-AS da mesma classe de transporte, formando um túnel de ponta a ponta que preserva a classe de transporte.

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

Figura 4 ilustra uma topologia de rede com cenários antes e depois da implementação de BGP de transporte com classe em um domínio intra-AS. Os dispositivos PE11 e PE12 usam LSPs de RSVP, pois o túnel de transporte e todas as rotas de túnel de transporte estão instaladas no inet.3 RIB. A implementação BGP planos de transort com classe permite que 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 antes e depois para uma implementação BGP de transporte com classe Domínio intra-AS: Cenários antes e depois para uma implementação BGP de transporte com classe Domínio intra-AS: Cenários antes e depois para uma implementação BGP de transporte com classe

Para classificar túneis de transporte em BGP classe de transporte 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 da comunidade de cores à classe de transporte definida.

    Configuração de amostra:

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

    Configuração de amostra:

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

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

    Neste exemplo, as rotas de RSVP LSP associadas a ouro de classe de transporte (cor 100) e classe de transporte (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 ingresso) combina com a comunidade de cores estendida (cores: 0:100 e cores: 0:200) da rota de serviço contra a comunidade de mapeamento em RIBs de resolução predefinida e resolve o próximo hop (PNH) do protocolo nos RIBs de transporte correspondentes (junos-rti-tc-<100>.inet.3, ou junos-rti-tc-<200>.inet.3).
  • BGP rotas se unem a um esquema de resolução transportando 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 é a resolução de rotas de serviço que usam Color:0:<val> como a comunidade de mapeamento.

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

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

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

Em uma rede inter-AS, a BGP-LU é convertida em uma rede de transporte com classe BGP configurando 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 BGP transporte com classe:

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

    Para LSPs de RSVP

    Para IS-IS algoritmo flxible

  3. Habilitar uma nova família para BGP transporte classful (transporte de inet) e BGP-LU (inet labeled-unicast) na rede.

    Configuração de amostra:

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

    Configuração de amostra:

Funcionalidade de plano de transporte BGP Inter-AS:

  1. BGP de transporte com classe criam RIBs de transporte predefinidos por categoria 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 por RIBs de transporte por meio de tunelamento de protocolos quando associados a uma classe de transporte.

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

  3. BGP de transporte com classe usam o Exclusivo Route Distinguisher e o Route Target quando copia as rotas de túnel de transporte de cada RIB de transporte até a tabela de roteamento bgp.transport.3.
  4. Nós de borda anunciam rotas da tabela de roteamento bgp.transport.3 para seus colegas em outros domínios, caso o transporte de inet da família seja negociado na sessão de BGP de segurança.
  5. O nó de borda de recebimento instala essas rotas bgp-ct na tabela de roteamento bgp.transport.3 e copia essas rotas com base no alvo da rota de transporte para os RIBs de transporte apropriados.
  6. O nó de serviço combina a comunidade de cores da 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. Nós de borda usam esquemas de resolução predefinidos para resolução de PNH da rota de transporte.
  8. Predefinidos ou definidos pelo usuário, ambos os esquemas de resolução suportam a resolução da PNH da rota de serviço. Os usos predefinidos do inet.3 como reação, e o esquema de resolução definida pelo usuário permite que a lista de RIBs de transporte seja usada na ordem especificada enquanto resolve a PNH.
  9. Se a PNH da rota de serviço não puder ser solucionada usando RIBs listados no esquema de resolução definido pelo usuário, a rota será descartada.

Aprimorando a precisão do banco de dados de engenharia de tráfego com mensagens do RSVP PathErr

Um elemento essencial da engenharia de tráfego baseada em RSVP é o banco de dados de engenharia de tráfego. O banco de dados de engenharia de tráfego contém uma lista completa de todos os nós e links de rede participantes da engenharia de tráfego, e um conjunto de atributos que cada um desses links pode manter. (Para obter mais informações sobre o banco de dados de engenharia de tráfego, consulte Computação LSPde caminho restrito.) Um dos atributos de enlace mais importantes é a largura de banda.

A disponibilidade de largura de banda nos links muda rapidamente conforme os LSPs de RSVP são estabelecidos e encerrados. É provável que o banco de dados de engenharia de tráfego desenvolva inconsistências em relação à rede real. Essas inconsistências não podem ser corrigidas pelo aumento da taxa de IGP atualizações.

A disponibilidade do link pode compartilhar o mesmo problema de inconsistência. Um enlace que fica indisponível pode quebrar todos os LSPs de RSVP existentes. Entretanto, sua indisponibilidade pode não ser prontamente conhecida pela rede.

Quando você configura a instrução, um nó de origem (entrada de um RSVP LSP) aprende com as falhas de seu LSP monitorando mensagens PathErr transmitidas de nós rsvp-error-hold-time downstream. As informações das mensagens do PathErr são incorporadas às computação LSP posteriores, o que pode melhorar a precisão e a velocidade da configuração de 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.

Você pode controlar a frequência de IGP atualizações usando a update-threshold declaração. Consulte Configurar o limiar de atualização do RSVP em uma interface.

Esta seção discute os seguintes tópicos:

Mensagens pathErr

As mensagens do PathErr informam uma grande 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.

Ao configurar a declaração, duas categorias de mensagens do PathErr, que representam especificamente falhas de rsvp-error-hold-time enlace, são analisadas:

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

    Esse tipo de mensagem pathErr representa um problema global que afeta todos os LSPs que transitam no enlace. Eles indicam que a largura de banda do enlace real é inferior à exigida pelo LSP, e que é provável que as informações de largura de banda no banco de dados de engenharia de tráfego seja um superestimado.

    Quando esse tipo de erro é recebido, a largura de banda do enlace disponível é reduzida no banco de dados de engenharia de tráfego local, afetando todas as computação de 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

    • Pré-requisito de serviço — código 12

    • Problema no roteamento — nenhuma rota disponível em direção ao destino — código 24, subcódigo 5

    Esses tipos de mensagens pathErr são geralmente pertinentes ao LSP especificado. A falha deste LSP não significa necessariamente que outros LSPs também poderiam falhar. Esses erros podem indicar problemas máximos na unidade de transferência (MTU), pré-adição de serviço (iniciados manualmente pelo operador ou por outro LSP com uma prioridade maior), que um enlace de next-hop está inativa, um vizinho de next-hop derrubado ou uma recusa do serviço por causa de considerações de política. É melhor afastar esse LSP específico do enlace.

Identificar o enlace de problemas

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

Cada mensagem pathErr transporta informações suficientes para identificar a sessão de RSVP que acionou a mensagem. Se 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 os links que a sessão deve atravessar. Juntamente com as informações do nó de origem, o enlace pode ser identificado com exclusividade.

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 instrução está configurada, um nó de origem (entrada de um RSVP LSP) 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 às computação LSP posteriores, o que pode melhorar a precisão e a velocidade da configuração de 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 por quanto tempo MPLS lembrar as mensagens do 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 de 1 a 240 segundos. O padrão é de 25 segundos. Configurar um valor de 0 desativa o monitoramento de mensagens PathErr.

Tabela de histórico de liberação
Versão
Descrição
20.4R1
A partir da versão 20.4R1 Junos OS, você pode configurar IS-IS engenharia de tráfego para armazenar informações IPv6 no banco de dados de engenharia de tráfego (TED), além de endereços IPv4.
17.4R1
A partir do Junos OS Release 17.4R1, o banco de dados de engenharia de tráfego instala informações de topologia do protocolo gateway interior (IGP), além de informações de topologia RSVP-TE na tabela de roteamento lsdist.0
17.2R1
A partir da versão 17.2R1 Junos OS, BGP família de endereços de estado de enlace é estendida para distribuir o roteamento de pacotes de origem em informações de topologia de rede (SPRING) para controladores de rede definidas por software (SDN).
17.1R1
A começar pela versão do Junos OS 17.1R1, a distribuição do estado do enlace BGP é suportada em QFX10000 switches.