Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração de RSVP

Configuração de RSVP mínima

Para habilitar o RSVP em uma interface única, inclua a rsvp instrução e especifique a interface usando a interface instrução. Essa é a configuração de RSVP mínima. Todas as outras declarações de configuração de RSVP são opcionais.

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

  • [edit protocols]

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

Para habilitar o RSVP em todas as interfaces, substituir all a interface-name variável.

Se você tiver configurado as propriedades da interface em um grupo de interfaces e quiser desativar o RSVP em uma das interfaces, inclua a disable declaração:

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

  • [edit protocols rsvp interface interface-name ]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name ]

Configuração de RSVP e MPLS

O principal objetivo do software Junos RSVP é dar suporte à sinalização dinâmica nos caminhos comutado por rótulos (LSPs). Quando você habilita MPLS e RSVP em um roteador, MPLS torna-se um cliente de RSVP. Nenhuma configuração adicional é necessária para vincular MPLS e RSVP.

Você pode configurar MPLS para configurar caminhos sinalados usando a label-switched-path instrução no nível [edit protocols mpls] da hierarquia. Cada LSP se traduz em uma solicitação de RSVP para iniciar uma sessão de RSVP. Essa solicitação é passada pela interface interna entre a complicação de rótulos e o RSVP. Depois de examinar as informações de solicitação, verificar os estados do RSVP e verificar as tabelas de roteamento locais, o RSVP inicia uma sessão para cada LSP. A sessão é origem do roteador local e destina-se ao alvo do LSP.

Quando uma sessão de RSVP é criada com sucesso, a LSP é configurada ao longo dos caminhos criados pela sessão RSVP. Caso a sessão de RSVP não seja bem-sucedida, o RSVP notifica MPLS de seu status. É preciso MPLS iniciar os caminhos de backup ou continuar a tentar o caminho inicial.

Para transmitir informações de sinalização de com switching de rótulos, o RSVP tem suporte para quatro outros objetos: Label Request object, Label Object, Explicit Route object e Record Route Object. Para que um LSP seja criado com sucesso, todos os roteadores ao longo do caminho devem ter suporte para MPLS, RSVP e os quatro objetos. Dos quatro objetos, o objeto Rota de registro não é obrigatório.

Para configurar MPLS e torná-la um cliente de RSVP, faça o seguinte:

  • Habilita MPLS todos os roteadores que participarão da comação de rótulos (ou seja, em todos os roteadores que podem fazer parte de um caminho de com switching de rótulos).

  • Ative o RSVP em todos os roteadores e em todas as interfaces de roteador que formam o LSP.

  • Configure os roteadores no início do LSP.

Exemplo: Configuração de RSVP e MPLS

A seguir mostra uma configuração de amostra para um roteador no início de um LSP:

A seguir mostra uma configuração de amostra para todos os outros roteadores que formam o LSP:

Configuração de interfaces de RSVP

As seções a seguir descreverão como configurar interfaces de RSVP:

Configurando a redução de atualização do RSVP

Você pode configurar a redução de atualização de RSVP em cada interface incluindo as seguintes declarações na configuração da interface:

  • aggregate e — Ative todos os recursos de redução de atualização do reliable RSVP: A mensagem de RSVP é abrangente, ID de mensagem de RSVP, entrega confiável de mensagens e atualização de resumo.

    Para ter redução de atualização e entrega confiável, você deve incluir aggregate os e reliable declarações.

  • no-aggregate— Desative a atualização da mensagem de RSVP e o resumo.

  • no-reliable— Desative a ID da mensagem de RSVP, entrega confiável de mensagens e atualização de resumo.

Para obter mais informações sobre a redução de atualização do RSVP, consulte RSVP Refresh Reduction.

Se a instrução estiver configurada no roteador (a entrega de mensagens confiável está desabilitada), o roteador aceitará mensagens de RSVP que incluem o objeto ID da mensagem, mas ignora o objeto ID da mensagem e continua realizando o processamento padrão da no-reliable mensagem. Nenhum erro é gerado neste caso, e o RSVP opera normalmente.

No entanto, nem todas as combinações entre dois vizinhos com diferentes recursos de redução de atualização funcionam corretamente. Por exemplo, um roteador está configurado com a aggregate instrução e a no-reliable declaração ou com as e reliableno-aggregate declarações. Se um vizinho RSVP enviar um objeto Resumo Atualizar para este roteador, nenhum erro será gerado, mas o objeto Resumo Atualizar não pode ser processado. Portanto, os estados de RSVP podem ter um tempo livre neste roteador se o vizinho depender apenas do Resumo Atualizar para atualizar esses estados de RSVP.

Recomendamos, a menos que haja requisitos específicos, que você configure a redução de atualização do RSVP de maneira semelhante a cada vizinho RSVP.

Para habilitar todos os recursos de redução de atualização de RSVP em uma interface, inclua a aggregate declaração:

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

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para desativar a inclusão de mensagens de RSVP e a atualização do resumo, inclua a no-aggregate declaração:

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

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para habilitar a ID da mensagem de RSVP e a entrega confiável de mensagens em uma interface, inclua a reliable declaração:

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

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para desativar a ID da mensagem de RSVP, entrega confiável de mensagens e atualização de resumo, inclua a no-reliable declaração:

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

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Determinar a capacidade de redução de atualização dos vizinhos de RSVP

Para determinar a capacidade de redução de atualização de RSVP de um vizinho RSVP, você precisa das seguintes informações:

  • O bit RR anunciado pelo vizinho

  • A configuração local da redução de atualização do RSVP

  • As mensagens de RSVP reais recebidas pelo vizinho

Para obter essas informações, você pode emitir um show rsvp neighbor detail comando. A saída da amostra é a seguinte:

Para obter mais informações sobre o show rsvp neighbor detail comando.

Configurando o intervalo de olá do RSVP

O RSVP monitora o status dos vizinhos (IGP) (IS-IS ou OSPF) e confia nos protocolos de IGP para detectar quando um nó falha. Se um IGP de segurança declarar um vizinho para baixo (porque os pacotes de olá não estão mais sendo recebidos), o RSVP também derrubará esse vizinho. Entretanto, os protocolos IGP e o RSVP ainda agem independentemente ao trazer um vizinho.

Para Juniper Networks roteadores, configurar um intervalo de olá de RSVP mais curto ou maior não afeta a reação de uma sessão de RSVP ou não. As sessões de RSVP são mantidas mesmo que os pacotes de olá do RSVP não sejam mais recebidos. As sessões de RSVP são mantidas até que o roteador pare de receber IGP pacotes hello ou o tempo de saída do caminho do RSVP e das mensagens de resv. No entanto, a partir da versão 16.1 do Junos OS, quando o RSVP receber mensagens de texto, as sessões de RSVP são enviadas.

O intervalo de olá do RSVP também pode ser impactado quando o equipamento de outro fornecedor derrubar uma sessão de RSVP. Por exemplo, um roteador não Juniper Networks vizinho pode estar configurado para monitorar pacotes de olá RSVP.

Para modificar a frequência com que O RSVP envia pacotes hello, inclua a hello-interval declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essa declaração, consulte a seção resumo da declaração.

Configuração da autenticação de RSVP

Todas as trocas de protocolo RSVP podem ser autenticadas para garantir que somente os vizinhos confiáveis participem da configuração de reserva. Por padrão, a autenticação de RSVP está desabilitada.

A autenticação de RSVP usa um digerir baseado em mensagens Hashed Message Authentication Code (HMAC)-MD5. Esse esquema produz uma digestão de mensagens com base em uma chave de autenticação secreta e no conteúdo da mensagem. (O conteúdo da mensagem também inclui um número de sequência.) A digestão computada é transmitida com mensagens de RSVP. Depois de configurar a autenticação, todas as mensagens de RSVP enviadas e recebidas por todos os vizinhos serão autenticadas nesta interface.

A autenticação MD5 fornece proteção contra falsificação e modificação de mensagens. Ele também pode evitar ataques de replay. No entanto, ele não fornece confidencialidade, porque todas as mensagens são enviadas em texto claro.

Por padrão, a autenticação está desabilitada. Para habilitar a autenticação, configure uma chave em cada interface incluindo a authentication-key declaração:

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

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Configuração da assinatura de largura de banda para tipos de classe

Por padrão, o RSVP permite que 100 por cento da largura de banda para um tipo de classe seja usado para reserva de RSVP. Quando você sobrescreve um tipo de classe para um LSP multiclasse, a demanda agregada de todas as sessões de RSVP pode exceder a capacidade real do tipo de classe.

Para obter instruções detalhadas sobre como configurar a assinatura da largura de banda para tipos de classe, consulte Configurando a porcentagem de assinatura da largura de banda para LSPs.

Configurando o limiar de atualização do RSVP em uma interface

Os protocolos de gateway interior (IGPs) mantêm o banco de dados de engenharia de tráfego, mas a largura de banda disponível atual nos links do banco de dados de engenharia de tráfego é proveniente do RSVP. Quando a largura de banda de um enlace muda, o RSVP informa os IGPs, que podem atualizar o banco de dados de engenharia de tráfego e encaminhá-las a todos os nós de rede. Os nós de rede saberão a largura de banda disponível no enlace do banco de dados de engenharia de tráfego (local ou remoto), e o CSPF pode computar os caminhos corretamente.

Entretanto, IGP atualizações podem consumir excesso de recursos do sistema. Dependendo do número de nós em uma rede, talvez não seja desejável realizar uma atualização IGP para pequenas mudanças de largura de banda. Configurando a instrução em nível de hierarquia, você pode ajustar o limiar no qual uma mudança na largura de banda reserva update-threshold[edit protocols rsvp] aciona uma atualização IGP de segurança.

Você pode configurar um valor de 0,001 por cento a 20 por cento (o padrão é de 10 por cento) para quando acionar uma atualização IGP de segurança. Se a mudança na largura de banda reserva for maior ou igual à porcentagem de limiar configurada da largura de banda estática nessa interface, uma atualização IGP ocorrerá. Por exemplo, se você configurou a declaração como sendo de 15 por cento e o roteador descobrir que a largura de banda reserva em um enlace mudou em 10 por cento da largura de banda do enlace, o RSVP não aciona uma atualização IGP update-threshold de segurança. Entretanto, se a largura de banda reserva em um enlace mudar em 20 por cento da largura de banda do enlace, o RSVP aciona uma atualização IGP de segurança.

Você também pode configurar o limiar como um valor absoluto usando threshold-value a opção na update-threshold instrução.

Se o valor do limiar estiver configurado para mais de 20% da largura de banda nesse enlace, o valor do limiar será limitado a 20% da largura de banda.

Por exemplo, se a largura de banda em uma interface for de 1 Gbps, e a configuração for superior a 200 Mbps, a largura de banda é limitada a threshold-valuethreshold-value 200 Mbps. O limiar por cento é exibido como 20.000% e os threshold-value 200 Mbps.

Nota:

As duas opções, limiar por cento e , são threshold-value mutuamente exclusivas. Você pode configurar apenas uma opção em um determinado ponto no tempo para gerar uma atualização IGP para reserva de largura de banda mais baixa. Como resultado, quando uma opção está configurada, a outra opção é calculada e visualizada na CLI.

Por exemplo, em um enlace de 1 Gbps, se o limiar por cento estiver configurado para 5%, ele será calculado e exibido como threshold-value 50 Mbps. Da mesma forma, se o estiver configurado para 50m, o limiar por cento é calculado e threshold-value exibido como 5%.

Para ajustar o limiar no qual uma mudança na largura de banda reserva aciona uma atualização IGP, inclua a instrução update-threshold. Devido ao limiar de atualização, é possível que o CSPF (Shortest Path First, caminho mais curto restrito) compute um caminho usando informações de largura de banda de banco de dados de engenharia de tráfego ultrapassadas em um enlace. Se o RSVP tentar estabelecer um LSP por esse caminho, pode ser que haja largura de banda insuficiente nesse enlace. Quando isso acontece, o RSVP aciona uma atualização IGP banco de dados de engenharia de tráfego, inundando as informações de largura de banda atualizadas na rede. Em seguida, o CSPF pode recompuir o caminho usando as informações de largura de banda atualizadas e tentar encontrar um caminho diferente, evitando o enlace congestionado. Observe que essa funcionalidade é o padrão e não precisa de nenhuma configuração adicional.

Você pode configurar a declaração em nível de hierarquia ou em nível de hierarquia para melhorar a precisão do banco de dados de engenharia de tráfego (incluindo a precisão das estimativas de largura de banda para LSPs) usando informações fornecidas pelas mensagens rsvp-error-hold-time[edit protocols mpls] do [edit logical-systems logical-system-name protocols mpls] PathErr. Consulte a melhoria da precisão do banco de dados de engenharia de tráfego com mensagens do RSVP PathErr.

Configuração de RSVP para interfaces sem número

O Junos OS tem suporte para engenharia de tráfego RSVP em interfaces sem número. As informações de engenharia de tráfego sobre links sem número são transportadas nas extensões de engenharia de tráfego IGP para OSPF e IS-IS, conforme descrito no RFC 4203, extensões de OSPF em suporte à Computação generalizada de rótulos multi-protocolo (GMPLS)e RFC 4205, Sistema Intermediário para Sistema Intermediário (IS-IS) em suporte à Computação Generalizada de Rótulos Multi-Protocolo (GMPLS). Links sem número também podem ser especificados na sinalização engenharia de tráfego de MPLS como descrito na RFC 3477, sinalização de links não numerados no protocolo de reservação de recursos - Engenharia de tráfego (RSVP-TE). Esse recurso permite evitar a configuração de endereços IP para cada interface participante da rede com sinal de RSVP.

Para configurar RSVP para interfaces sem número, você deve configurar o roteador com uma ID de roteador usando a instrução especificada router-id no nível da [edit routing-options] hierarquia. A ID do roteador deve estar disponível para o roteamento (normalmente você pode usar o endereço de loopback). As mensagens de controle do RSVP para os links sem número são enviadas usando o endereço ID do roteador (em vez de um endereço selecionado aleatoriamente).

Para configurar a proteção de enlace e reroute rápido em um roteador com interfaces sem número habilitadas, é necessário configurar pelo menos dois endereços. Recomendamos configurar uma interface secundária no loopback, além de configurar a ID do roteador.

Configurando Olás de ID de nó RSVP

Você pode configurar olás de RSVP baseados em nó-ID para garantir que Juniper Networks roteadores possam operar com o equipamento de outros fornecedores. Por padrão, o Junos OS usa RSVP baseado na interface. Olás RSVP baseados em nó-ID são especificados em RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Olá: Uma declaração de esclarecimento. Olás de ID de nó RSVP são úteis se você tiver configurado BFD para detectar problemas por meio de interfaces RSVP, permitindo que você desative os olás da interface para essas interfaces. Você também pode usar o node-ID hellos para procedimentos de reinicialização graciosos.

Os hellos node-ID podem ser ativados globalmente para todos os vizinhos de RSVP. Por padrão, o suporte a olá do nó-ID está inválido. Caso você não tenha ativado IDs de nó RSVP no roteador, o Junos OS não aceitará nenhum pacote hello de ID de nó.

Para habilitar a ID de nó RSVP globalmente no roteador, inclua a instrução node-hello nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Você também pode desativar explicitamente a interface de RSVP globalmente. Esse tipo de configuração pode ser necessário em redes nas quais o roteador Juniper Networks tenha várias conexões RSVP com equipamentos de outros fornecedores. No entanto, se você desativar a interface RSVP globalmente, você também pode configurar um intervalo de olá em uma interface RSVP usando a instrução hello-interval. Essa configuração desativa a interface de RSVP globalmente, mas permite que a interface RSVP seja atualizada na interface especificada (a interface RSVP na onde você configura a hello-interval instrução). Essa configuração pode ser necessária em uma rede heterogênea na qual alguns dispositivos suportam olás de ID de nó RSVP e outros dispositivos que suportam olás à interface RSVP.

Para desativar a interface de RSVP globalmente no roteador, inclua a instrução sem interface-hello nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

Exemplo: Configuração de LSPs com sinal de RSVP

Este exemplo mostra como criar um LSP entre roteadores em uma rede IP usando RSVP como protocolo de sinalização.

Requisitos

Antes de começar, elimine serviços de segurança do dispositivo. Veja o exemplo: Exclusão dos serviços de segurança.

Visão geral e topologia

Usando RSVP como protocolo de sinalização, você pode criar LSPs entre roteadores em uma rede IP. Neste exemplo, você configura uma rede de amostra conforme mostrado em Figura 1 .

Topologia

Figura 1: LSP típico com sinal de RSVPLSP típico com sinal de RSVP

Para estabelecer um LSP entre roteadores, você deve habilitar MPLS família MPLS e configurar RSVP em cada uma das interfaces de trânsito na MPLS rede. Este exemplo mostra como habilitar MPLS e configurar RSVP na interface de trânsito ge-0/0/0. Além disso, você deve habilitar o MPLS de rede em todas as MPLS da rede.

Este exemplo mostra como definir um LSP de R1 a R7 no roteador de entrada (R1) usando o endereço de loopback de R7 (10.0.9.7). A configuração reserva 10 Mbps de largura de banda. Além disso, a configuração desativa o algoritmo CSPF, garantindo que os hosts C1 e C2 usem o LSP com sinal de RSVP que correspondem ao caminho mais curto da IGP rede.

Configuração

Procedimento

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar o RSVP:

  1. Ative a MPLS de segurança em todas as interfaces de trânsito da MPLS rede.

  2. Ative o RSVP em cada interface de trânsito na MPLS rede.

  3. Ative o MPLS de segurança na interface de trânsito na MPLS rede.

  4. Defina o LSP no roteador de entrada.

  5. Reserve 10 Mbps de largura de banda no LSP.

Resultados

Confirmar sua configuração inserindo o show comando no modo de configuração. Se a saída não apresentar a configuração pretendido, repetirá as instruções de configuração neste exemplo para corrigi-la.

Para a brevidade, essa show saída de comando inclui apenas a configuração relevante para este exemplo. Qualquer outra configuração do sistema foi trocada por elipses (...).

Caso você não configure o dispositivo, entre commit no modo de configuração.

Verificação

Para confirmar se a configuração está funcionando corretamente, realize essas tarefas:

Verificar os vizinhos do RSVP

Propósito

Verifique se cada dispositivo mostra os vizinhos RSVP apropriados, por exemplo, que o roteador R1 lista o Roteador R3 e o Roteador R2 como Figura 1 vizinhos de RSVP.

Ação

Da CLI, insira o show rsvp neighbor comando.

A saída mostra os endereços IP dos roteadores vizinhos. Verificar se cada endereço de loopback do roteador RSVP vizinho está listado.

Verificar sessões de RSVP

Propósito

Verificar se uma sessão de RSVP foi estabelecida entre todos os vizinhos de RSVP. Além disso, verifique se o valor da reserva de largura de banda está ativo.

Ação

Da CLI, insira o show rsvp session detail comando.

A saída mostra as informações detalhadas, incluindo IDs de sessão, reserva de largura de banda e endereços de next-hop, para cada sessão de RSVP estabelecida. Verificar as seguintes informações:

  • Cada endereço vizinho RSVP tem uma entrada para cada vizinho, listada por endereço de loopback.

  • O estado de cada sessão de LSP é Up .

  • Para, Tspec aparece o valor de largura de banda 10Mbps apropriado.

Verificar a presença de LSPs com sinal de RSVP

Propósito

Verificar se a tabela de roteamento do roteador de entrada (entrada) tem um LSP configurado para o endereço de loopback do outro roteador. Por exemplo, verificar se a tabela de roteamento do roteador de entrada R1 tem um LSP configurado para o endereço inet.3Figura 1 de loopback do roteador R7.

Ação

Da CLI, insira o show route table inet.3 comando.

A saída mostra as rotas de RSVP existentes na tabela inet.3 de roteamento. Verificar se um LSP com sinal de RSVP está associado ao endereço de loopback do roteador de saída (saída, R7) na rede MPLS de saída.

Exemplo: Configuração de malha automática de RSVP

Os provedores de serviços costumam usar BGP e MPLS VPNs para dimensionar a rede com eficiência enquanto entregam serviços que geram receita. Nesses ambientes, BGP é usado para distribuir as informações de roteamento vpn pela rede do provedor de serviços, enquanto MPLS é usado para encaminhamento desse tráfego de VPN de um site de VPN para outro.

Ao adicionar um novo roteador PE que participará de VPNs BGP e MPLS, todos os roteadores PE existentes anteriormente precisam ser configurados para peerar com o novo roteador PE para BGP e MPLS. Conforme cada novo roteador PE é adicionado à rede do provedor de serviços, a carga de configuração logo se torna muito grande para lidar.

Os requisitos de configuração para BGP peering podem ser reduzidos com o uso de refletores de roteamento. Nas redes MPLS RSVP MPLS, a malha automática de RSVP pode minimizar a carga de configuração para MPLS porção da rede. Configurar em todos os roteadores PE permite que RSVP crie automaticamente rsvp-te os LSPs necessários quando um novo roteador PE é adicionado.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um roteador executando o Junos OS Release 10.1 ou mais tarde.

  • Uma BGP e MPLS VPN usando RSVP como o MPLS de sinalização de caminho comutado por rótulos (LSP).

Visão geral

Este exemplo mostra como configurar a malha automática de RSVP em um roteador PE usando a instrução rsvp-te de configuração. Para que a malha automática de RSVP funcione corretamente, todos os roteadores PE do configuração de malha completa devem ter rsvp-te a instrução configurada. Isso garante que quaisquer novos roteadores PE adicionados mais tarde também se beneficiem do recurso de malha automática, desde que eles também sejam configurados com a rsvp-te instrução.

Dado esse requisito, este exemplo mostra apenas a configuração no roteador PE recém-adicionado. Assume-se que a malha automática de RSVP já tenha sido configurada nos roteadores PE existentes.

Topologia

Existem Figura 2 três roteadores PE existentes, PE1, PE2 e PE3, na topologia. O PE4 foi adicionado, e a malha automática de RSVP estará configurada. A nuvem representa a rede do provedor de serviços, e o endereço de rede, 192.0.2.0/24, é mostrado no centro da figura.

Figura 2: Provedor de serviços rede com roteadores PEProvedor de serviços rede com roteadores PE

Configuração

Configurar a malha automática de RSVP envolve a execução dessas tarefas:

  • Ativação da rsvp-te instrução de configuração em [edit routing-options dynamic-tunnels dynamic-tunnel-name] nível de hierarquia.

  • Configurando o elemento destination-networks necessário.

    Esse elemento de configuração especifica a faixa de prefixo IPv4 para a rede de destino. Somente túneis dentro do intervalo de prefixo especificado podem ser criados.

  • Configurando o elemento label-switched-path-template necessário.

    Esse elemento de configuração toma como argumento o nome de um modelo default-template LSP pré-configurado. Esse default-template é um modelo definido pelo sistema que não requer configuração do usuário.

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar com a configuração da rede e, em seguida, copie e copie e colar os comandos na CLI no nível da [edit] hierarquia.

Roteador PE4

Configuração de malha automática de RSVP

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário cli.

Para habilitar a malha automática de RSVP:

  1. Configurar rsvp-te em nível de [edit routing-options dynamic-tunnels] hierarquia.

  2. Configurar destination-networks em nível de [edit routing-options dynamic-tunnels] hierarquia.

Resultados

Emito show o comando do nível da hierarquia para ver os resultados da sua [edit routing-options dynamic-tunnels] configuração:

Verificação

Verificação da existência de túneis de malha automáticaS RSVP no Roteador PE4

Propósito

Para verificar a operação do roteador PE4 recém-configurado, emito show dynamic-tunnels database o comando do modo operacional. Esse comando mostrará a rede de destino para a qual túneis dinâmicos podem ser criados.

Ação

Verificar a existência de LSPs MPLS no roteador PE4

Propósito

Para verificar a existência de MPLS LSPs no roteador PE4, emito show mpls lsp o comando do modo operacional. Esse comando mostrará o estado dos MPLS LSPs.

Ação

Configuração de reconhecimentos do Hello para vizinhos de RSVP não-sesion

A declaração controla o comportamento de reconhecimento de olá entre os vizinhos RSVP, independentemente de eles estão ou não hello-acknowledgements na mesma sessão.

As mensagens de olá dos vizinhos de RSVP que não fazem parte de uma sessão de RSVP comum são descartadas. Se você configurar a declaração em nível de hierarquia, as mensagens de olá de vizinhos não-sesion são hello-acknowledgements[edit protocols rsvp] reconhecidas com uma mensagem de agradecimento. Quando são recebidos cumprimentos de vizinhos não-sesion, um relacionamento com os vizinhos do RSVP é criado e mensagens periódicas de olá agora podem ser recebidas do vizinho da não-isessão. A hello-acknowledgements declaração está desabilitada por padrão. Configurar essa instrução permite que roteadores com capacidade de RSVP sejam descobertos usando pacotes hello e verifica se a interface é capaz de receber pacotes RSVP antes de enviar quaisquer mensagens de configuração MPLS LSP.

Depois de habilitar reconhecimentos de olá para vizinhos RSVP não sesession, o roteador continua a reconhecer mensagens de olá de quaisquer vizinhos RSVP não-estaission a menos que a interface vá abaixo ou você altere a configuração. Os vizinhos baseados na interface não estão automaticamente idosos.

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

  • [edit protocols rsvp]

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

Comando LSPs para longe de um nó de rede

Você pode configurar o roteador para comunar LSPs ativos de distância de um nó de rede usando um LSP de bypass ativado para uma interface. Esse recurso pode ser usado para manter redes ativas quando um dispositivo precisa ser substituído sem interromper o tráfego que transita pela rede. Os LSPs podem ser estáticos ou dinâmicos.

  1. Primeiro, você precisa configurar a proteção de enlace ou nó para o tráfego que precisa passar pelo dispositivo de rede que você pretende desativar. Para funcionar corretamente, o LSP de bypass deve usar uma interface lógica diferente da LSP protegida.
  2. Para preparar o roteador para começar a comunar o tráfego de um nó de rede, configure a always-mark-connection-protection-tlv declaração:

    Em seguida, o roteador marca todo o tráfego OAM que transita nesta interface, preparando-se para comutar o tráfego para um caminho alternativo com base na funcionalidade OAM.

    Esta instrução pode ser configurada nos seguintes níveis de hierarquia:

    • [edit protocols mpls interface interface-name]

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

  3. Em seguida, você precisa configurar a instrução para mudar o tráfego do LSP protegido para o LSP de bypass, desviando-se efetivamente do dispositivo de rede switch-away-lsps downstream padrão. O próprio enlace real não é derrubado por esta configuração.

    Para configurar o roteador para afastar o tráfego de um nó de rede, configure a switch-away-lsps declaração:

    Esta instrução pode ser configurada nos seguintes níveis de hierarquia:

    • [edit protocols mpls interface interface-name]

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

Observe as seguintes limitações relacionadas à comação de LSPs ativos longe de um nó de rede:

  • O recurso de "switch-away" é suportado apenas em roteadores da série MX.

  • O recurso de switch-away não é suportado para comutar tráfego de LSPs principais de ponto a multipoint para desviar LSPs de ponto a multipoint. Se você configurar switch-away-lsps a instrução para um LSP ponto-a-multipoint, o tráfego não será comutado para o LSP ponto de bypass para multipoint.

  • Se você configurar o recurso de switch-away em uma interface ao longo do caminho de um LSP dinâmico, novos LSPs dinâmicos não podem ser estabelecidos nesse caminho. O recurso de switch-away impede o comportamento de make-before-break de LSPs sinalados por RSVP. Normalmente, o comportamento de make-before-break faz com que o roteador faça a primeira tentativa de re-sinalização de um LSP dinâmico antes de derrubar o original.

Configurando a proteção de configuração de RSVP

Você pode configurar o mecanismo de reroute rápido de backup para instalações para fornecer proteção de configuração para LSPs que estão em processo de sinalização. Ambos os LSPs ponto a ponto e LSPs point-to-multipoint são suportados. Esse recurso é aplicável no cenário a seguir:

  1. Um enlace ou nó com falha está presente no caminho explícito rigoroso de um LSP antes da sinalização do LSP.

  2. Também existe um LSP de bypass que protege o enlace ou nó.

  3. RSVP indica o LSP pelo LSP de bypass. O LSP aparece como se originalmente estivesse definido ao longo de seu caminho principal e depois falhasse no bypass LSP por causa da falha do enlace ou do nó.

  4. Quando o enlace ou nó foi recuperado, o LSP pode ser automaticamente revertido para o caminho principal.

Você deve configurar a instrução em cada um dos roteadores ao longo do caminho LSP no qual deseja setup-protection[edit protocols rsvp] habilitar a proteção de configuração LSP. Você também deve configurar IGP engenharia de tráfego em todos os roteadores do caminho LSP. Você pode emitir um comando para determinar se o LSP tem ou não a proteção de configuração ativada em um roteador que funciona como um ponto de reparo local (PLR) ou um ponto show rsvp session de fusão.

Para habilitar a proteção de configuração de RSVP, inclua a setup-protection declaração

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

  • [edit protocols rsvp]

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

Configurando o balanceamento de carga em LSPs de RSVP

Por padrão, quando você configura vários LSPs de RSVP no mesmo roteador de saída, o LSP com a métrica mais baixa é selecionado e transporta todo o tráfego. Se todos os LSPs têm a mesma métrica, um dos LSPs é selecionado aleatoriamente e todo o tráfego é encaminhado por ela.

Como alternativa, você pode equilibrar o tráfego em todos os LSPs permitindo o balanceamento de carga por pacote.

Para habilitar o balanceamento de carga por pacote em um LSP de entrada, configure a policy-statement instrução da seguinte forma:

Em seguida, você precisa aplicar essa declaração como uma política de exportação à tabela de encaminhamento.

Uma vez que o balanceamento de carga por pacote é aplicado, o tráfego é distribuído igualmente entre os LSPs (por padrão).

Você precisa configurar o balanceamento de carga por pacote se quiser habilitar o reroute rápido do PFE. Para habilitar o reroute rápido de PFE, inclua a declaração de balanceamento de carga por pacote mostrada nesta seção na configuração de cada um dos roteadores onde um policy-statement reroute pode ocorrer. Consulte também Como configurar o fast reroute.

Você também pode equilibrar o tráfego entre os LSPs na proporção da largura de banda configurada para cada LSP. Essa capacidade pode distribuir melhor o tráfego em redes com recursos de largura de banda assimétricos em links externos, uma vez que a largura de banda configurada de um LSP normalmente reflete a capacidade de tráfego desse LSP.

Para configurar o balanceamento de carga de RSVP LSP, inclua a load-balance instrução com a bandwidth opção:

Esta instrução pode ser configurada nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

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

Lembre-se das seguintes informações ao usar a load-balance declaração:

  • Se você configurar a declaração, o comportamento dos LSPs em execução no load-balance momento não será alterado. Para obrigar os LSPs em execução a usar o novo comportamento, você pode emitir um clear mpls lsp comando.

  • A load-balance instrução só se aplica a LSPs de entrada que tenham o balanceamento de carga por pacote ativado.

  • Para LSPs com conhecimento de tráfego diferenciado, a largura de banda de um LSP é calculada somando a largura de banda de todos os tipos de classe.

Configuração de malha automática de RSVP

Você pode configurar o RSVP para estabelecer caminhos comutado de rótulo (LSPs) ponto a ponto automaticamente para qualquer novo roteador PE adicionado a uma malha completa de LSPs. Para habilitar esse recurso, você deve configurar a instrução em todos os rsvp-te roteadores PE na malha completa.

Nota:

Você não pode configurar a malha automática de RSVP junto com o CCC. O CCC não pode usar os LSPs gerados dinamicamente.

Para configurar a malha automática de RSVP, inclua a rsvp-te declaração:

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

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

Você também deve configurar as declarações a seguir para habilitar a malha automática RSVP:

  • destination-networks— Especifique o intervalo de prefixo de IP versão 4 (IPv4) para a rede de destino. Túneis dinâmicos dentro do intervalo de prefixo IPv4 especificado podem ser iniciados.

  • label-switched-path-template (Multicast)— Você pode configurar o modelo padrão explicitamente usando a opção ou configurar um modelo LSP usando default-template a template-name opção. O modelo LSP funciona como uma configuração de modelo para LSPs gerados dinamicamente.

Configuração de temporizadores para mensagens de atualização de RSVP

O RSVP usa dois parâmetros de tempo relacionados:

  • refresh-time— O tempo de atualização controla o intervalo entre a geração de mensagens de atualização sucessivas. O valor padrão do tempo de atualização é de 45 segundos. Esse número é obtido do valor padrão da declaração de 30, multiplicado por um refresh-time valor fixo de 1,5. Essa computação difere da RFC 2205, que determina que o tempo de atualização deve ser multiplicado por um valor aleatório na faixa de 0,5 a 1,5.

    As mensagens de atualização incluem mensagens de caminho e resv. Mensagens de atualização são enviadas periodicamente para que os estados de reserva nos nós vizinhos não se estendo. Cada mensagem do caminho e do Resv transporta o valor do temporizador de atualização, e o nó de recebimento extrai esse valor das mensagens.

  • keep-multiplier— O multiplicador de manter é um inteiro pequeno e localmente configurado de 1 a 255. O valor padrão é 3. Ele indica o número de mensagens que podem ser perdidas antes de um estado específico ser declarado estagnado e deve ser excluído. O multiplicador de manter afeta diretamente a vida útil de um estado RSVP.

Para determinar a vida útil de um estado de reserva, use a seguinte fórmula:

Na pior das hipóteses, ( – 1) mensagens de atualização sucessivas devem ser perdidas antes que um estado keep-multiplier de reserva seja excluído.

Não recomendamos configurar um pequeno relógio de olá RSVP. Se for necessário uma rápida descoberta de um vizinho com falha, configure os IGP de OSPF ou IS-IS olá).

Por padrão, o valor do tempo de atualização é de 30 segundos. Para modificar esse valor, inclua a refresh-time declaração:

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

  • [edit protocols rsvp]

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

O valor padrão do multiplicador de manter é 3. Para modificar esse valor, inclua a keep-multiplier declaração:

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

  • [edit protocols rsvp]

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

Sessões de RSVP antecipadas

Sempre que a largura de banda é insuficiente para lidar com todas as sessões de RSVP, você pode controlar a pré-adição de sessões de RSVP. Por padrão, uma sessão de RSVP é antecipada apenas por uma nova sessão de maior prioridade.

Para sempre pré-se uma sessão quando a largura de banda é insuficiente, inclua a preemption declaração com a aggressive opção:

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

  • [edit protocols rsvp]

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

Para desativar a pré-configuração da sessão de RSVP, inclua a preemption instrução com a disabled opção:

Para retornar ao padrão (ou seja, antes de uma sessão apenas para uma nova sessão de maior prioridade), inclua a preemption instrução com a normal opção:

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

  • [edit protocols rsvp]

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

Configurando MTU de sinalização em RSVP

Para configurar unidade de transmissão máxima sinalização (MTU) em RSVP, você precisa configurar MPLS para permitir que pacotes IP sejam fragmentados antes de serem encapsulados em MPLS. Você também precisa configurar MTU sinalização em RSVP. Para fins de solução de problemas, você pode configurar MTU sinalização sozinho sem permitir a fragmentação de pacotes.

Para configurar MTU sinalização em RSVP, inclua a path-mtu 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]

As seções a seguir descreverão como habilitar fragmentação de pacotes e MTU sinalização em RSVP:

Habilitando MTU sinalização em RSVP

Para habilitar MTU sinalização em RSVP, inclua a rsvp mtu-signaling declaração:

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

  • [edit protocols mpls path-mtu]

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

Depois de ter comprometido a configuração, as alterações no MTU de sinalização para RSVP surtiram efeito na próxima vez que o caminho for atualizado.

Você pode configurar a mtu-signaling declaração sozinha no nível da [edit protocols mpls path-mtu rsvp] hierarquia. Isso pode ser útil para solucionar problemas. Se você configurar apenas a instrução, você pode usar o comando para determinar qual a menor MTU mtu-signalingshow rsvp session detail em um LSP. O show rsvp session detail comando exibe o valor MTU valor recebido e enviado no objeto Adspec.

Ativação da fragmentação de pacotes

Para permitir que pacotes de IP sejam fragmentados antes de serem encapsulados MPLS, inclua a allow-fragmentation declaração:

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

  • [edit protocols mpls path-mtu]

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

    Nota:

    Não configure a allow-fragmentation declaração sozinho. Configure-a sempre juntamente com a mtu-signaling declaração.

Configurando o Ultimate-Hop Popping para LSPs

Por padrão, LSPs com sinal de RSVP usam penultimate-hop popping(PHP).Figura 3 ilustra um penúltimo salto entre o roteador PE1 e o roteador PE2. O roteador CE1 encaminha um pacote para seu próximo hop (Roteador PE1), que também é a entrada LSP. O roteador PE1 envia o rótulo 1 ao pacote e encaminha o pacote identificado ao roteador P1. O roteador P1 conclui a operação MPLS padrão de troca de rótulos, trocando o rótulo 1 pelo rótulo 2 e encaminha o pacote ao roteador P2. Como o roteador P2 é o penúltimo roteador de hop do LSP para o roteador PE2, primeiro ele pops o rótulo e depois encaminha o pacote para o roteador PE2. Quando o Roteador PE2 o recebe, o pacote pode ter um rótulo de serviço, um rótulo explicit-null ou apenas um pacote de IP ou VPLS simples. O roteador PE2 encaminha o pacote sem rótulo para o roteador CE2.

Figura 3: Penultimate-Hop Popping para um LSPPenultimate-Hop Popping para um LSP

Você também pode configurar o ultimate-hop popping(UHP)(como mostrado) para LSPs com sinal Figura 4 de RSVP. Alguns aplicativos de rede podem exigir que os pacotes cheguem ao roteador de saída (Roteador PE2) com um rótulo externo não nulo. Para um LSP de salto final, o penúltimo roteador (Roteador P2 in) realiza a operação de troca de rótulos padrão MPLS (neste exemplo, rótulo 2 para o rótulo 3 ) antes de encaminhá-lo ao roteador Figura 4 de saída PE2. O roteador PE2 revela o rótulo externo e realiza uma segunda busca no endereço do pacote para determinar o destino final. Em seguida, ele encaminha o pacote ao destino apropriado (roteador CE2 ou Roteador CE4).

Figura 4: Ultimate-Hop Popping para um LSPUltimate-Hop Popping para um LSP

Os seguintes aplicativos de rede exigem que você configure LSPs uhp:

  • MPLS-TP para monitoramento de desempenho e OAM dentro da banda

  • Circuitos virtuais de proteção de borda

Os seguintes recursos não suportam o comportamento do UHP:

  • LSPs com sinal LDP

  • LSPs estáticos

  • Point-to-multipoint LSPs

  • Ccc

  • traceroute Comando

Para obter mais informações sobre comportamento de UHP, consulte o draft da Internet-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, comportamento não PHP e Mapeamento fora da banda para LSPs RSVP-TE.

Para LSPs sinalização de RSVP ponto a ponto, o comportamento de UHP é sinalização da entrada LSP. Com base na configuração do roteador de entrada, o RSVP pode sinalizar o LSP do UHP com o conjunto de bandeiras não PHP. As mensagens RSVP PATH transportam as duas bandeiras no objeto LSP-ATTRIBUTES. Quando o roteador de saída recebe a mensagem PATH, ele atribua um rótulo não nulo ao LSP. O RSVP também cria e instala duas rotas na tabela de roteamento mpls.0. S refere-se ao bit S do rótulo MPLS, que indica se a base da pilha de rótulos foi alcançada ou não.

  • Rota S=0 — Indica que há mais rótulos na pilha. O próximo salto desta rota indica a tabela de roteamento mpls.0, acionando uma busca MPLS rótulos de MPLS encadeados para descobrir os rótulos de MPLS restantes na pilha.

  • Rota S=1 — Indica que não há mais rótulos. O próximo hop indica a tabela de roteamento inet.0 se a plataforma tiver suporte para a análise encadeada e multi-família. Como alternativa, a rota de rótulos pode apontar para uma interface VT para iniciar o encaminhamento ip.

Se você habilitar LSPs de UHP, MPLS aplicativos como VPNs de Camada 3, VPLS, VPNs de Camada 2 e circuitos de Camada 2 podem usar os LSPs do UHP. A seguir explica como os LSPs de UHP afeta os diferentes tipos de MPLS aplicativos:

  • Circuitos VPNs de Camada 2 e Camada 2 — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo (S=0) é o rótulo UHP, e o rótulo interno (S=1) é o rótulo VC. Uma pesquisa baseada no rótulo de transporte resulta em uma pega de tabela para a tabela de roteamento mpls.0. Existe uma rota adicional na tabela de roteamento mpls.0 correspondente ao rótulo interno. Uma pesquisa baseada no rótulo interno resulta no roteador CE próximo hop.

  • VPN de Camada 3 — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo (S=0) é o rótulo UHP, e o rótulo interno é o rótulo VPN (S=1). Uma pesquisa baseada no rótulo de transporte resulta na pega da tabela para a tabela de roteamento mpls.0. Existem dois casos nesse cenário. Por padrão, as VPNs de Camada 3 anunciam o rótulo por próximo hop. Uma pesquisa baseada no rótulo interno resulta no próximo salto em direção ao CE roteador. Entretanto, se você tiver configurado a instrução para a instância de roteamento VPN de Camada 3, o rótulo LSI interno indica a tabela de roteamento vrf-table-label VRF. Uma busca por IP também é concluída para a tabela de roteamento VRF.

    Nota:

    O UHP para VPNs de camada 3 configurados com a instrução é suportado apenas em redes vrf-table-label 5G da Série MX Plataformas de roteamento universal.

  • VPLS — Um pacote chega ao roteador PE (saída do LSP do UHP) com dois rótulos. O rótulo externo é o rótulo de transporte (S=0) e o rótulo interno é o rótulo VPLS (S=1). Uma pesquisa baseada no rótulo de transporte resulta na pega da tabela para a tabela de roteamento mpls.0. Uma pesquisa baseada no rótulo interno na tabela de roteamento mpls.0 resulta na interface de túnel LSI da instância de roteamento VPLS se os serviços de túnel não estão configurados (ou uma interface VT não disponível). Os roteadores da Série MX 3D são suportados por uma olhada encadeada e uma olhada em várias famílias.

    Nota:

    O UHP para VPLS configurado com a declaração é suportado apenas em roteadores da Série no-tunnel-service MX 3D.

  • IPv4 por MPLS — Um pacote chega ao roteador PE (saída do LSP do UHP) com um rótulo (S=1). Uma olhada com base nesse rótulo retorna uma interface de túnel VT. Outra busca por IP é concluída na interface VT para determinar onde encaminha o pacote. Se a plataforma de roteamento tiver suporte para buscas em várias famílias e cadeias (por exemplo, roteadores MX 3D e série PTX Roteadores de transporte de pacotes), a busca baseada na rota de rótulos (S=1) indica a tabela de roteamento inet.0.

  • IPv6 sobre MPLS — para o tunelamento IPv6 sobre MPLS, os roteadores PE anunciam rotas IPv6 entre si com um valor de rótulo de 2. Esse é o rótulo explicit null para IPv6. Como resultado, os próximos saltos de encaminhamento para rotas IPv6 que são aprendidas com roteadores PE remotos normalmente empurram dois rótulos. O rótulo interno é 2 (pode ser diferente se o roteador PE de publicidade for de outro fornecedor), e o rótulo do roteador é o rótulo LSP. Os pacotes chegam ao roteador PE (saída do UHP LSP) com dois rótulos. O rótulo externo é o rótulo de transporte (S=0), e o rótulo interno é o rótulo explicit-null IPv6 (rótulo 2). A busca baseada no rótulo interno da tabela de roteamento mpls.0 é redirecionada de volta para a tabela de roteamento mpls.0. Nos roteadores da Série MX 3D, o rótulo interno (rótulo 2) é retirado e uma busca no IPv6 é feita usando a tabela de roteamento inet6.0.

  • Ativação de LSPs PHP e UHP — Você pode configurar LSPs PHP e UHP pelos mesmos caminhos de rede. Você pode separar o tráfego PHP e o UHP selecionando o encaminhamento de LSP nos próximos hops usando uma expressão regular com a install-nexthop declaração. Você também pode separar o tráfego nomeando os LSPs de maneira adequada.

As declarações a seguir permitem a popping ultimate-hop para um LSP. Você pode habilitar esse recurso em um LSP específico ou para todos os LSPs de entrada configurados no roteador. Configure essas declarações no roteador na entrada LSP.

  1. Para habilitar o ultimate-hop popping, inclua a ultimate-hop-popping declaração:

    Inclua essa instrução no nível [edit protocols mpls label-switched-path label-switched-path-name] da hierarquia para permitir a adoção de ultimate-hop em um LSP específico. Inclua essa instrução no nível da hierarquia para permitir o estouro de ultimate-hop em todos os LSPs de entrada [edit protocols mpls] configurados no roteador. Você também pode configurar a ultimate-hop-popping declaração nos níveis de hierarquia [edit logical-routers] equivalentes.

    Nota:

    Ao habilitar o ultimate-hop popping, o RSVP tenta ressignificar os LSPs existentes como LSPs de salto final, de forma make-before-break. Se um roteador de saída não tiver suporte para popping ultimate-hop, o LSP existente será eliminado (O RSVP envia uma mensagem PathTear ao longo do caminho de um LSP, removendo o estado do caminho e o estado da reserva dependente e liberando os recursos de rede associados).

    Se você desativar o estouro de ultimate-hop, o RSVP renuncia aos LSPs existentes como penúltimo salto com LSPs estourando de forma make-before-break.

  2. Se você quiser habilitar os próximos saltos ultimate-hop-popping e encadeados apenas em roteadores da série MX 3D, você também precisa configurar a opção para a enhanced-ipnetwork-services instrução:

    Você configura essa instrução em nível [edit chassis] de hierarquia. Depois de configurar a network-services declaração, você precisa reinicializar o roteador para habilitar o comportamento do UHP.

Configuração de RSVP para pop the Label no roteador Ultimate-Hop

Você pode controlar o valor do rótulo anunciado no roteador de saída de um LSP. O rótulo anunciado padrão é o rótulo 3 (rótulo Implicit Null). Se o rótulo 3 for anunciado, o roteador penúltimo-hop remove o rótulo e envia o pacote para o roteador de saída. Quando o ultimate-hop popping está ativado, o rótulo 0 (rótulo Explicit Null versão 4 [IPv4] IP) é anunciado. O ultimate-hop popping garante que todos os pacotes que atravessem uma MPLS de rede incluam um rótulo.

Nota:

Juniper Networks pacotes de fila de roteadores com base no rótulo de entrada. Roteadores de outros fornecedores podem enfileiror pacotes de maneira diferente. Tenha isso em mente ao trabalhar com redes contendo roteadores de vários fornecedores.

Para configurar o ultimate-hop popping para RSVP, inclua a explicit-null 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]

Ativação do Ultimate-Hop Popping em LSPs point-to-multipoint

Por padrão, para LSPs ponto a ponto e ponto-a-multipoint, o penultimate-hop popping é usado para MPLS tráfego. MPLS rótulos são removidos dos pacotes no roteador pouco antes do roteador de saída do LSP. Os pacotes IP simples são encaminhados para o roteador de saída. Para o ultimate-hop popping, o roteador de saída é responsável por remover o rótulo MPLS e processar o pacote IP simples.

Pode ser vantajoso permitir a estouro ultimate-hop em LSPs point-to-multipoint, especialmente quando o tráfego de trânsito está atravessando o mesmo dispositivo de saída. Se você habilitar o ultimate-hop popping, uma única cópia do tráfego pode ser enviada pelo enlace de entrada, economizando largura de banda significativa. Por padrão, o popping ultimate-hop está desabilitado.

Você habilita o ultimate-hop popping para LSPs point-to-multipoint configurando a tunnel-services declaração. Quando você habilita popping ultimate-hop, o Junos OS escolhe uma das interfaces de túnel de loopback virtual (VT) disponíveis para reenviá-los ao PFE para encaminhamento de IP. Por padrão, o processo de seleção da interface VT é realizado automaticamente. O controle de admissão de largura de banda é usado para limitar o número de LSPs que podem ser usados em uma interface VT. Uma vez que toda a largura de banda é consumida em uma interface, o Junos OS escolhe outra interface VT com largura de banda suficiente para controle de admissão.

Se um LSP exigir mais largura de banda do que está disponível em qualquer uma das interfaces VT, o popping ultimate-hop não pode ser ativado e o penultimate-hop popping está ativado.

Para que os LSPs de ponta a multipoint funcionem corretamente, o roteador de saída deve ter uma PIC que fornece serviços de túnel, como os serviços de túnel PIC ou os serviços adaptáveis PIC. Os serviços de túnel são necessários para MPLS rótulo final e para devolução de pacotes para buscas de endereços IP.

Você pode configurar explicitamente quais interfaces VT lidam com o tráfego de RSVP incluindo a devices opção da tunnel-services instrução. A devices opção permite especificar quais interfaces de VT devem ser usadas pelo RSVP. Caso você não configure essa opção, todas as interfaces de VT disponíveis para o roteador podem ser usadas.

Para habilitar o popping ultimate-hop para LSPs de saída point-to-multipoint em um roteador, configure a tunnel-services declaração:

Esta instrução pode ser configurada nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

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

Para habilitar o popping ultimate-hop para LSPs de saída ponto a multipoint, você também deve configurar interface a instrução com a all opção:

Você deve configurar essa instrução em nível [edit protocols rsvp] de hierarquia.

Rastreamento de tráfego de protocolo RSVP

Para rastrear o tráfego de protocolo RSVP, inclua a traceoptions declaração:

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

  • [edit protocols rsvp]

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

Você pode especificar os seguintes sinalizadores específicos de RSVP na instrução traceoptions RSVP:

Use a file instrução para especificar o nome do arquivo que recebe a saída da operação de rastreamento. Todos os arquivos são colocados no /var/log diretório. Recomendamos que você coloque a saída de rastreamento de RSVP no rsvp-log arquivo.

  • all— Todas as operações de rastreamento.

  • error— Todas as condições de erro detectadas

  • event— eventos relacionados ao RSVP (ajuda a rastrear eventos relacionados ao reinicialização graciosa do RSVP)

  • lmp—Interações RSVP-Link Management Protocol (LMP)

  • packets— Todos os pacotes de RSVP

  • path— Todas as mensagens de caminho

  • pathtear— Mensagens do PathTear

  • resv— Resv mensagens

  • resvtear— ResvTear mensagens

  • route—Informações de roteamento

  • state— Transições de estado de sessão, incluindo quando LSPs com sinal de RSVP chegam e vão para baixo.

Nota:

Use o all sinal de rastreamento e o modificador de bandeira com cautela, porque isso pode fazer com que a detail CPU se torne muito ocupada.

Para exibir o arquivo de log gerado ao habilitar rastreamentos de RSVP, emita o comando e onde está o arquivo especificado show log file-namefile-name usando a traceoptions instrução.

Para informações gerais sobre opções de rastreamento e rastreamento global, consulte a Biblioteca de Protocolos de Roteamento junos OS para dispositivos de roteamento.

Exemplos: Rastreamento de tráfego de protocolo RSVP

Rastrear mensagens de caminho do RSVP em detalhes:

Rastrear todas as mensagens de RSVP:

Rastrear todas as condições de erro do RSVP:

Rastrear transições de estado de RSVP:

Saída de arquivo de log RSVP

A seguir é a saída de amostra gerada pela emissão do comando em um roteador no qual as opções de rastreamento de RSVP foram ativadas com o show log file-namestate sinal configurado. O LSP E-D com sinal de RSVP é mostrado sendo derrubado em 11 de março de 14:04:36.707092. Em 11 de março de 14:05:30.101492, ele aparece de volta.

RSVP Graceful Reboot

O reinicialização graciosa de RSVP permite que um roteador em fase de reinicialização informe seus vizinhos adjacentes de sua condição. O roteador de reinicialização solicita um período de carência do vizinho ou peer, que pode colaborar com o roteador de reinicialização. O roteador de reinicialização ainda pode MPLS tráfego durante o período de reinicialização; a convergência na rede não é rompida. A reinicialização não é visível para o resto da rede, e o roteador de reinicialização não é removido da topologia de rede. O reinicialização graciosa de RSVP pode ser ativado em roteadores de trânsito e roteadores de entrada. Ele está disponível para LSPs ponto a ponto e LSPs point-to-multipoint.

O reinicialização graciosa do RSVP é descrito nas seções a seguir:

Terminologia de reinicialização graciosa de RSVP

Tempo de reinicialização (em milissegundos)

O valor padrão é de 60.000 milissegundos (1 minuto). O tempo de reinicialização é anunciado na mensagem olá. O tempo indica quanto tempo um vizinho deve esperar para receber uma mensagem de olá de um roteador de reinicialização antes de declarar que o roteador está morto e estados de purgação.

O Junos OS pode substituir o tempo de reinicialização anunciado pelo vizinho se o tempo for maior que um terço do tempo de reinicialização local. Por exemplo, dado o tempo de reinicialização padrão de 60 segundos, um roteador esperaria 20 segundos ou menos para receber uma mensagem de olá de um vizinho reinício. Se o tempo de reinicialização for zero, o vizinho de reinicialização pode ser imediatamente declarado morto.

Tempo de recuperação (em milissegundos)

Aplica-se somente quando o canal de controle estiver aberto (a troca de olá está concluída) antes do tempo de reinicialização. Aplica-se apenas a falhas nodal.

Quando um reinício está em andamento, é anunciado o tempo de conclusão de uma recuperação. Em outras ocasiões, esse valor é zero. O tempo máximo de recuperação anunciado é de 2 minutos (120.000 milissegundos).

Durante o tempo de recuperação, um nó reinício tenta recuperar seus estados perdidos com a ajuda de seus vizinhos. O vizinho do nó de reinicialização deve enviar as mensagens de caminho com os rótulos de recuperação para o nó de reinicialização em um período de uma metade do tempo de recuperação. O nó de reinicialização considera sua reinicialização completa após seu tempo de recuperação anunciado.

Operação de reinicialização graciosa RSVP

Para o RSVP retomar a função, o recurso precisa ser ativado na instância de roteamento global. A reinicialização graciosa de RSVP pode ser desabilitada no nível do protocolo (apenas para RSVP) ou em nível global para todos os protocolos.

O reinicialização graciosa de RSVP requer o seguinte: um roteador reinicializado e os vizinhos do roteador:

  • Para o roteador de reinicialização, o RSVP tenta reinicializar as rotas instaladas pelo RSVP e pelos rótulos alocados, para que o tráfego continue a ser encaminhado sem interrupções. O reinicialização simples do RSVP é feito rapidamente o suficiente para reduzir ou eliminar o impacto nos nós vizinhos.

  • Os roteadores vizinhos devem ter o modo de ajuda de reinicialização de RSVP habilitado, permitindo que eles assistam um roteador que tenta reinicializar RSVP.

Um objeto chamado Reboot Cap enviado em mensagens de olá do RSVP anuncia a capacidade de reinicialização de um nó. O nó vizinho envia um objeto Recuperar rótulo para o nó de reinicialização para recuperar seu estado de encaminhamento. Esse objeto é essencialmente o rótulo antigo anunciado pelo nó de reinicialização antes do nó ser lançado.

A seguir lista os comportamentos de reinicialização graciosa do RSVP, que variam dependendo da configuração e de quais recursos estão ativados:

  • Caso você desative o modo de ajuda, o Junos OS não tenta ajudar um vizinho a reinicializar o RSVP. Qualquer informação que chegue com um objeto Reboot Cap de um vizinho é ignorada.

  • Ao habilitar a reinicialização graciosa na configuração da instância de roteamento, o roteador pode ser reinicializado com a ajuda de seus vizinhos. RSVP anuncia um objeto Reboot Cap (RSVP REBOOT) em mensagens de olá nas quais os tempos de reinicialização e recuperação são especificados (nenhum valor é 0).

  • Caso você desative explicitamente o RSVP e reinicie o RSVP no nível da hierarquia, o objeto Reboot Cap será anunciado com tempos de reinicialização e recuperação especificados [protocols rsvp] como 0. A reinicialização dos roteadores vizinhos é suportada (a menos que o modo de ajuda seja desabilitado), mas o roteador não preserva o estado de encaminhamento RSVP e não consegue recuperar seu estado de controle.

  • Se, após um RSVP reinicializado, perceber que nenhum estado de encaminhamento foi preservada, o objeto Reboot Cap será anunciado com tempos de reinicialização e recuperação especificados como 0.

  • Se o modo de reinicialização e o modo de ajuda não estiver funcionando, a reinicialização graciosa do RSVP será completamente desabilitada. O roteador não reconhece nem anuncia os objetos de reinicialização graciosos do RSVP.

Você não pode configurar explicitamente valores para os tempos de reinicialização e recuperação.

Ao contrário de outros protocolos, não há maneira de RSVP determinar se ele concluiu um procedimento de reinicialização, além de um tempo de saída fixo. Todos os procedimentos de reinicialização de RSVP são baseados em temporizador. Um comando pode indicar que a reinicialização ainda está em andamento, mesmo que todas as sessões de show rsvp version RSVP sejam repostas e as rotas sejam restabelecidas.

Processamento do objeto Reboot Cap

As seguintes hipóteses são feitas sobre um vizinho com base no objeto Reboot Cap (assumindo que uma falha no canal de controle possa ser destacada sem qualquer problema de reinicialização do nó):

  • Um vizinho que não anuncia o objeto Reboot Cap em suas mensagens de olá não pode ajudar um roteador com recuperação de estado ou rótulos, nem realizar um reinicialização graciosa de RSVP.

  • Depois de reinicializar, um vizinho anunciando um objeto Reboot Cap com um tempo de reinicialização igual a qualquer valor e um tempo de recuperação igual a 0 não preservou seu estado de encaminhamento. Quando um tempo de recuperação é igual a 0, o vizinho é considerado morto e todos os estados relacionados a esse vizinho são eliminados, independentemente do valor do tempo de reinicialização.

  • Depois de reinicializar, um vizinho anunciando seu tempo de recuperação com um valor diferente de 0 pode manter ou manter o estado de encaminhamento. Se o roteador local está ajudando seu vizinho com procedimentos de reinicialização ou recuperação, ele enviará um objeto Recovery Label para esse vizinho.

Configuração do RSVP Graceful Reboot

As seguintes configurações de reinicialização graciosa do RSVP são possíveis:

  • O modo de reinicialização e o helper estão ativados (o padrão).

  • O modo de reinicialização graciosa está ativado, mas o modo de ajuda está desabilitado. Um roteador configurado dessa forma pode ser reinicializado de maneira graciosa, mas não pode ajudar um vizinho com seus procedimentos de reinicialização e recuperação.

  • A reinicialização graciosa está desabilitada, mas o modo de ajuda está ativado. Um roteador configurado dessa forma não pode ser reinicializado de maneira graciosa, mas pode ajudar um vizinho a reinicializar.

  • O modo de reinicialização e o helper estão desabilitados. Essa configuração desativa completamente o RSVP (incluindo procedimentos de reinicialização e recuperação e modo de ajuda). O roteador se comporta como um roteador que não tem suporte para RSVP reinicializar.

Nota:

Para ativar o RSVP, você precisa definir o tempo de reinicialização global em pelo menos 180 segundos.

As seções a seguir descreverão como configurar o RSVP como reinicialização graciosa:

Ativação do Graceful Reboot para todos os protocolos de roteamento

Para habilitar a reinicialização graciosa para RSVP, você precisa habilitar a reinicialização graciosa para todos os protocolos que suportam reinicialização graciosa no roteador. Para obter mais informações sobre o reinicialização graciosa, consulte a Biblioteca de Protocolos de Roteamento do Junos OS para dispositivos de roteamento.

Para habilitar a reinicialização graciosa no roteador, inclua a graceful-restart declaração:

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

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

Desativação do Graceful Reboot para RSVP

Por padrão, o RSVP é reinicializado e o modo de ajuda do RSVP é ativado quando você ativa a reinicialização graciosa. No entanto, você pode desativar um ou dois desses recursos.

Para desativar o RSVP como reinicialização e recuperação, inclua a disable declaração no nível da [edit protocols rsvp graceful-restart] hierarquia:

Desativação do modo de ajuda do RSVP

Para desativar o modo de ajuda do RSVP, inclua a helper-disable instrução no nível [edit protocols rsvp graceful-restart] da hierarquia:

Configurando o tempo de recuperação máximo do helper

Para configurar o tempo que o roteador mantém o estado de seus vizinhos RSVP enquanto eles passam por uma reinicialização graciosa, inclua a maximum-helper-recovery-time declaração em nível de [edit protocols rsvp graceful-restart] hierarquia. Esse valor é aplicado a todos os roteadores vizinhos, portanto, ele deve ser baseado no tempo necessário pelo vizinho RSVP mais lento para se recuperar.

Configurando o tempo de reinicialização máximo do helper

Para configurar o atraso entre quando o roteador descobre que um roteador vizinho foi para baixo e quando ele declara o vizinho para baixo, inclua a instrução no nível maximum-helper-restart-time[edit protocols rsvp graceful-restart] da hierarquia. Esse valor é aplicado a todos os roteadores vizinhos, portanto, ele deve ser baseado no tempo exigido pelo vizinho RSVP mais lento para ser reinicializado.

Visão geral dos túneis LSP do RSVP

Um túnel LSP (Resource Reservation Protocol, Protocolo de reserva de recursos) comutado por rótulos (LSP) permite que você envie LSPs de RSVP dentro de outros LSPs RSVP. Isso permite que um administrador de rede forneça engenharia de tráfego de uma ponta à outra. Uma aplicação útil para esse recurso é conectar roteadores de borda do cliente (CE) com roteadores de borda do provedor (PE) usando um LSP de RSVP e, em seguida, tunelar esse LSP de borda dentro de um segundo RSVP LSP que atravessa o núcleo da rede.

Você deve ter uma compreensão geral dos conceitos de MPLS e com switching de rótulos. Para obter mais informações sobre MPLS, consulte o Guia de configuração MPLS Aplicativos do Junos.

Um túnel LSP RSVP adiciona o conceito de adjacência de encaminhamento, semelhante ao usado para serviços Multiprotocol Label Switching generalizados (GMPLS). (Para obter mais informações sobre o GMPLS, consulte o Guia de Usuário do Junos GMPLS.

A adjabilidade de encaminhamento cria um caminho túnel para o envio de dados entre dispositivos de peer em uma rede RSVP LSP. Uma vez estabelecida uma LSP de adjacência de encaminhamento (FA-LSP), outros LSPs podem ser enviados pelo FA-LSP usando o Caminho Mais Curto Restrito (CSPF), Protocolo de Gerenciamento de Enlace (LMP), Open Shortest Path First (OSPF) (OSPF) e RSVP.

Para habilitar um túnel LSP RSVP, o Junos OS usa os seguintes mecanismos:

  • LMP — Originalmente projetado para GMPLS, o LMP estabelece o encaminhamento de adjacências entre os peers de túnel LSP do RSVP e mantém e aloca recursos para links de engenharia de tráfego.

  • OSPF extensões — OSPF foi projetado para rotear pacotes para interfaces físicas e lógicas relacionadas a uma placa de interface física (PIC). Esse protocolo foi estendido para rotear pacotes para interfaces de peer virtuais definidas em uma configuração LMP.

  • Extensões RSVP-TE — O RSVP-TE foi projetado para sinalizar a configuração de LSPs de pacotes para interfaces físicas. O protocolo foi estendido para solicitar a configuração de caminho para LSPs de pacote que viajam até interfaces peer virtuais definidas em uma configuração LMP.

    Nota:

    A partir da versão 15.1 do Junos OS, o suporte a várias instâncias é estendido para MPLS RSVP-TE. Esse suporte está disponível apenas para o tipo de instância do roteador virtual. Um roteador pode criar e participar de várias TE independentes de topologia, o que permite que cada domínio TE particionados dimensione independentemente. O RSVP-TE em várias instâncias fornece a flexibilidade de escolher manualmente as entidades de plano de controle que precisam ser conscientes da instância, por exemplo, um roteador pode participar de várias instâncias de TE enquanto ainda executa uma única instância BGP instância.

    A implementação do Junos OS da MPLS RSVP-TE é escalonada para aprimorar a usabilidade, visibilidade, configuração e solução de problemas de LSPs no Junos OS Release 16.1.

    Esses aprimoramentos facilitam a configuração TE RSVP em escala:

    • Garantir a preparação do plano de dados LSP durante a ressignação do LSP antes que o tráfego atravesse o LSP com o mecanismo de auto-ping RSVP-TE LSP.

      Um LSP não deve começar a transportar tráfego a menos que seja conhecido por ter sido programado no plano de dados. A troca de dados no plano de dados LSP, como solicitações de ping LSP, acontece no roteador de entrada antes de alternar o tráfego para um LSP ou para sua instância MBB. Em redes grandes, esse tráfego pode sobrecarregar um roteador de saída LSP, conforme o LSP de saída precisa responder às solicitações de ping LSP. O mecanismo de self-ping LSP permite que a LER de entrada crie mensagens de resposta de ping LSP e envie-as pelo plano de dados LSP. Ao receber essas mensagens, a LER de saída as encaminha para a entrada, indicando a vivacência do plano de dados LSP. Isso garante que o LSP não comece a transportar tráfego antes do plano de dados ser programado.

    • Remover o limite rígido atual de 64K LSPs em um roteador de entrada e dimensionar o número total de LSPs com LSPs TE RSVP. Pode haver até 64K LSPs configurados por saída. Anteriormente, esse limite era o número agregado de LSPs que poderia ser configurado na LER de entrada.

    • Impedir o derrubar abrupto de LSPs pelo roteador de entrada por causa do atraso na sinalização do LSP nos roteadores de trânsito.

    • Permitindo uma visão flexível dos conjuntos de dados LSP para facilitar a visualização de dados característica do LSP.

    Nota:

    A partir da versão 17.4 do Junos OS, é introduzido um temporizador padrão de 1.800 segundos para self-ping.

Existem as seguintes limitações para as hierarquias LSP:

  • LSPs baseados em circuito cruzado (CCC) não são suportados.

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

  • A proteção de enlace não está disponível para FA-LSPs ou no ponto de saída da adjacência de encaminhamento.

  • LSPs ponto a multipoint não são suportados em FA-LSPs.

Exemplo: Configuração de túnel LSP RSVP

Figura 5: Diagrama de topologia de túnel LSP RSVPDiagrama de topologia de túnel LSP RSVP

Figura 5mostra um RSVP de ponta a ponta chamado de LSP que se origina no Roteador 0 e e2e_lsp_r0r5 termina no Roteador 5. Em trânsito, este LSP atravessa o FA-LSP. fa_lsp_r1r4 O caminho de retorno é representado pelo RSVP de ponta a ponta que e2e_lsp_r5r0 viajam pelo FA-LSP. fa_lsp_r4r1

No Roteador 0, configure o RSVP de ponta a ponta que vai até o Roteador 5. Use um caminho rigoroso que atravessa o Roteador 1 e o enlace de engenharia de tráfego LMP que vai do Roteador 1 ao Roteador 4.

Roteador 0

No Roteador 1, configure um FA-LSP para chegar ao Roteador 4. Estabeleça um enlace de engenharia de tráfego LMP e relacionamento de colegas de LMP com o Roteador 4. Consulte o FA-LSP no enlace de engenharia de tráfego e adicione a interface de peer em OSPF e RSVP.

Quando o LSP de ponta a ponta do caminho de retorno chega ao Roteador 1, a plataforma de roteamento realiza uma análise de roteamento e pode encaminhá-lo ao Roteador 0. Certifique-se de OSPF configuração correta entre os roteadores 0 e 1.

Roteador 1

No Roteador 2, configure OSPF, MPLS e RSVP em todas as interfaces que transportam os FA-LSPs pela rede de núcleo.

Roteador 2

No Roteador 3, configure OSPF, MPLS e RSVP em todas as interfaces que transportam os FA-LSPs pela rede de núcleo.

Roteador 3

No Roteador 4, configure um caminho de retorno FA-LSP para chegar ao Roteador 1. Estabeleça um enlace de engenharia de tráfego LMP e relacionamento de colegas de LMP com o Roteador 1. Consulte o FA-LSP no enlace de engenharia de tráfego e adicione a interface de peer em OSPF e RSVP.

Quando o LSP inicial de ponta a ponta chega ao Roteador 4, a plataforma de roteamento realiza uma análise de roteamento e pode encaminhá-lo ao Roteador 5. Configure as configurações OSPF corretamente entre o Roteador 4 e o Roteador 5.

Roteador 4

No Roteador 5, configure o caminho de retorno de ponta a ponta RSVP LSP que vai até o Roteador 0. Use um caminho rigoroso que atravessa o Roteador 4 e o enlace de engenharia de tráfego LMP que vai do Roteador 4 ao Roteador 1.

Roteador 5

Verificar seu trabalho

Para verificar se o túnel LSP do RSVP está funcionando corretamente, emita os seguintes comandos:

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

Para ver esses comandos usados no exemplo de configuração, consulte as seções a seguir:

Roteador 0

No Roteador 0, você pode verificar se os FA-LSPs aparecem como caminhos válidos no banco de dados de engenharia de tráfego. Neste caso, procure os caminhos do Roteador 1 ( ) e do Roteador 4 ( ) que referenciam os endereços de enlace de engenharia de tráfego 10.255.41.21610.255.41.217 LMP 172.16.30.1 de e 172.16.30.2 . Você também pode emitir o comando para procurar o caminho do LSP de ponta a ponta enquanto ele vai até o Roteador 5 pelo show rsvp session extensive FA-LSP.

Roteador 1

No Roteador 1, verifique se sua configuração de enlace de engenharia de tráfego LMP está funcionando e se o LSP de ponta a ponta está atravessando o enlace de engenharia de tráfego ao emissão do conjunto de show link-management comandos. Você também pode emitir o show rsvp session extensive comando para confirmar se o FA-LSP está operacional.

Configurando interfaces de peer em OSPF e RSVP

Depois de estabelecer peers LMP, você deve adicionar interfaces de peer para OSPF e RSVP. Uma interface de peer é uma interface virtual usada para dar suporte à adjaceência de controle entre dois peers.

O nome da interface de peer deve combinar peer peer-name com a instrução configurada em LMP no [edit protocols link-management] nível da hierarquia. Como os pacotes de protocolo reais são enviados e recebidos por interfaces de peer, as interfaces de peer podem ser sinaladas e anunciadas para peers, como qualquer outra interface física configurada para OSPF e RSVP. Para configurar OSPF roteamento para peers LMP, inclua a peer-interface instrução no nível [edit protocols ospf area area-number] da hierarquia. Para configurar a sinalização de RSVP para peers LMP, inclua a peer-interface instrução no nível [edit protocols rsvp] da hierarquia.

Definindo caminhos comutado por rótulos para o FA-LSP

Em seguida, defina seu FA-LSP incluindo a label-switched-path instrução em [edit protocols mpls] nível de hierarquia. Inclua a ID do roteador do peer na to declaração em nível de [edit protocols mpls label-switched-path] hierarquia. Como os LSPs de pacote são unidirecionais, você deve criar um FA-LSP para chegar ao peer e um segundo FA-LSP para retornar do peer.

Estabelecendo informações de caminho do FA-LSP

Quando você configura caminhos LSP explícitos para um FA-LSP, você deve usar o endereço remoto do enlace de engenharia de tráfego como seu endereço de next-hop. Quando o CSPF é suportado, você pode usar qualquer opção de caminho que desejar. No entanto, quando o CSPF é inválido com a instrução em nível no-cspf[edit protocols mpls label-switched-path lsp-name] de hierarquia, você deve usar caminhos rígidos.

Nota:

Se o LSP de ponta a ponta tiver origem na mesma plataforma de roteamento que o FA-LSP, você deve desativar o CSPF e usar caminhos rigorosos.

Opção: Destruir LSPs de RSVP de maneira graciosa

Você pode derrubar um LSP RSVP em um processo de duas etapas que retira graciosamente a sessão RSVP usada pelo LSP. Para todos os vizinhos que suportam o rebaixamento, uma solicitação para a redução é enviada pela plataforma de roteamento até o endpoint de destino para o LSP e para todos os vizinhos RSVP no caminho. A solicitação está incluída no ADMIN_STATUS campo do pacote RSVP. Quando os vizinhos recebem a solicitação, eles se preparam para a sessão de RSVP ser retirada. Uma segunda mensagem é enviada pela plataforma de roteamento para concluir a repressão da sessão de RSVP. Caso um vizinho não suporte a um rebaixamento gracioso, a solicitação é tratada como uma repressão padrão da sessão, em vez de uma versão graciosa.

Para realizar uma rebaixamento graciosa de uma sessão de RSVP, emita o clear rsvp session gracefully comando. Opcionalmente, você pode especificar o endereço de origem e destino da sessão RSVP, o identificador de LSP do remetente RSVP e o identificador de túnel da sessão RSVP. Para usar esses qualificadores, inclua connection-source o , e as opções quando você emitir o connection-destinationlsp-idtunnel-idclear rsvp session gracefully comando.

Você também pode configurar o tempo que a plataforma de roteamento espera que os vizinhos recebam a solicitação de rebaixamento graciosa antes de iniciar a repressão real, incluindo a declaração em nível graceful-deletion-timeout[edit protocols rsvp] de hierarquia. O valor de tempo limite de exclusão padrão é de 30 segundos, com um valor mínimo de 1 segundo e um valor máximo de 300 segundos. Para exibir o valor atual configurado para um tempo de exclusão simplificado, eminte o comando show rsvp version do modo operacional.

Tabela de histórico de liberação
Versão
Descrição
19.4R1
16.1
No entanto, a partir da versão 16.1 do Junos OS, quando o RSVP receber mensagens de texto, as sessões de RSVP são enviadas.