Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configuração de RSVP

Configuração RSVP mínima

Para habilitar o RSVP em uma única interface, inclua a rsvp declaração e especifique a interface usando a interface declaração. Esta é a configuração 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, substitua all a interface-name variável.

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

Você pode incluir esta 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 objetivo principal do software Junos RSVP é oferecer suporte à sinalização dinâmica dentro de caminhos comutados por rótulos (LSPs). Quando você habilita o MPLS e o RSVP em um roteador, o MPLS torna-se um cliente de RSVP. Nenhuma configuração adicional é necessária para vincular MPLS e RSVP.

Você pode configurar o MPLS para configurar caminhos sinalizados usando a label-switched-path declaração no nível de [edit protocols mpls] 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 comutação de rótulos e o RSVP. Após examinar as informações de solicitação, verificar os estados de RSVP e verificar as tabelas de roteamento locais, o RSVP inicia uma sessão para cada LSP. A sessão é proveniente do roteador local e destina-se ao alvo do LSP.

Quando uma sessão de RSVP é criada com sucesso, o LSP é configurado ao longo dos caminhos criados pela sessão RSVP. Se a sessão de RSVP não for bem sucedida, o RSVP notificará o MPLS de seu status. Cabe ao MPLS iniciar caminhos de backup ou continuar tentando novamente o caminho inicial.

Para passar informações de sinalização de comutação de rótulos, o RSVP oferece suporte a quatro objetos adicionais: Objeto de solicitação de rótulos, objeto de rótulo, objeto de rota explícita e objeto de rota de registro. Para que um LSP seja configurado com sucesso, todos os roteadores ao longo do caminho devem oferecer suporte a MPLS, RSVP e os quatro objetos. Dos quatro objetos, o objeto Da Rota de Registro não é obrigatório.

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

  • Habilite o MPLS em todos os roteadores que participarão da comutação de rótulos (isto é, em todos os roteadores que podem fazer parte de um caminho de comutação de rótulos).

  • Habilite 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.

Você pode configurar caminhos comutados por rótulos (LSPs) RSVP para usar uma métrica de atraso para computar o caminho. Para configurar, use as opções de CLI que introduzimos na [edit protocols mpls label-switched-path name] hierarquia.

Example: Configuração de RSVP e MPLS

O seguinte 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 RSVP

As seções a seguir descrevem como configurar interfaces RSVP:

Configuração da 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 reliable— Habilite todos os recursos de redução de atualização do RSVP: Agrupamento de mensagens RSVP, ID de mensagens RSVP, entrega confiável de mensagens e atualização resumida.

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

  • no-aggregate— Desativar o agrupamento de mensagens de RSVP e atualizar o resumo.

  • no-reliable— Desativar o ID de mensagens RSVP, a entrega confiável de mensagens e a atualização resumida.

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

Se a no-reliable declaração estiver configurada no roteador (a entrega confiável de mensagens é desabilitada), o roteador aceita mensagens RSVP que incluem o objeto ID da mensagem, mas ignora o objeto ID da mensagem e continua realizando o processamento padrão de mensagens. 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 declaração e no-reliable a aggregate declaração ou com as declarações e no-aggregate declaraçõesreliable. Se um vizinho RSVP enviar um objeto de atualização sumária para este roteador, nenhum erro é gerado, mas o objeto De atualização sumária não pode ser processado. Consequentemente, os estados RSVP podem dar um tempo neste roteador se o vizinho depender apenas da Atualização Sumária para atualizar esses estados de RSVP.

Recomendamos, a menos que existam requisitos específicos, que você configure a redução de atualização de RSVP de maneira semelhante em 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 esta 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 o agrupamento de mensagens RSVP e atualizar o resumo, inclua a no-aggregate declaração:

Você pode incluir esta 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 o ID de mensagens RSVP e a entrega confiável de mensagens em uma interface, inclua a reliable declaração:

Você pode incluir esta 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 o ID de mensagem RSVP, a entrega confiável de mensagens e a atualização resumida, inclua a no-reliable declaração:

Você pode incluir esta 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 RSVP

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

  • O bit de RR anunciado pelo vizinho

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

  • As mensagens RSVP reais recebidas do vizinho

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

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 do protocolo de gateway interior (IGP) (IS-IS ou OSPF) e conta com os protocolos IGP para detectar quando um nó falha. Se um protocolo de IGP declara um vizinho para baixo (porque os pacotes olá não estão mais sendo recebidos), o RSVP também derruba esse vizinho. No entanto, os protocolos de IGP e o RSVP ainda agem de forma independente ao trazer um vizinho para cima.

Para os roteadores da Juniper Networks, configurar um intervalo de RSVP mais curto ou mais longo não afeta se uma sessão de RSVP é ou não derrubada. As sessões de RSVP são mantidas mesmo se os pacotes RSVP olá não forem mais recebidos. As sessões de RSVP são mantidas até que o roteador pare de receber pacotes IGP hello ou o tempo de saída das mensagens RSVP Path e Resv. No entanto, a partir do Junos OS Release 16.1, quando o RSVP olá mensagens tempo de saída, as sessões de RSVP são derrubadas.

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 RSVP hello.

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

Nota:

A partir do lançamento, o Junos 16.1 envia mensagens de olá ao RSVP por um LSP de bypass quando um está disponível. Veja no-node-hello-on-bypass informações sobre como reverter para o comportamento histórico de enviar olás sobre o próximo hop do IGP.

Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta 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 apenas vizinhos confiáveis participem na configuração de reservas. Por padrão, a autenticação de RSVP é desabilitada.

A autenticação de RSVP usa um código de autenticação de mensagens hashed (HMAC)-MD5 baseado em mensagens. Esse esquema produz uma digestão de mensagem baseada 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 RSVP. Depois de configurar a autenticação, todas as mensagens RSVP recebidas e transmitidas com todos os vizinhos são autenticadas nesta interface.

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

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

Você pode incluir esta 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]

Configurando a assinatura de largura de banda para tipos de classe

Por padrão, o RSVP permite que 100% da largura de banda para um tipo de classe seja usada para reservas de RSVP. Quando você inscreve demais 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 de largura de banda para tipos de classe, consulte Configurando a porcentagem de assinatura de largura de banda para LSPs.

Configurando o limite de atualização de 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 de banco de dados de engenharia de tráfego é originária do RSVP. Quando a largura de banda de um link muda, o RSVP informa os IGPs, que podem então atualizar o banco de dados de engenharia de tráfego e encaminhar as novas informações de largura de banda para todos os nós de rede. Os nós de rede sabem então quanta largura de banda está disponível no link do banco de dados de engenharia de tráfego (local ou remoto), e o CSPF pode computar corretamente os caminhos.

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

Você pode configurar um valor de 0,001% a 20% (o padrão é de 10%) para quando ativar uma atualização do IGP. Se a mudança na largura de banda reservada for maior ou igual à porcentagem de limite configurada da largura de banda estática nessa interface, então ocorre uma atualização do IGP. Por exemplo, se você configurou a update-threshold declaração para 15% e o roteador descobrir que a largura de banda reservada em um link mudou em 10% da largura de banda do enlace, o RSVP não aciona uma atualização do IGP. No entanto, se a largura de banda reservada em um enlace mudar em 20% da largura de banda do enlace, o RSVP aciona uma atualização do IGP.

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

Se o valor do limiar for 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 1Gbps, e a configuração for superior a threshold-value 200Mbps, ela será limitada a threshold-value 200Mbps. O threshold-percent display é de 20.000% e como threshold-value 200Mbps.

Nota:

As duas opções, threshold-percent e threshold-value, são mutuamente exclusivas. Você pode configurar apenas uma opção em um determinado ponto a tempo de gerar uma atualização de IGP para menores reservas de largura de banda. Como resultado, quando uma opção está configurada, a outra opção é calculada e exibida na CLI.

Por exemplo, em um link de 1Gbps, se o threshold-percent for configurado para 5%, o threshold-value cálculo é calculado e exibido como 50Mbps. Da mesma forma, se a threshold-value configuração for de 50m, ela threshold-percent será calculada e exibida em 5%.

Para ajustar o limiar no qual uma mudança na largura de banda reservada aciona uma atualização do IGP, inclua a declaração de limiar de atualização . Por causa do limite de atualização, é possível que o CSPF (Constrained Shortest Path First, caminho mais curto restrito) compute um caminho usando informações de largura de banda de engenharia de tráfego desatualizadas em um link. Se o RSVP tentar estabelecer um LSP nesse caminho, pode descobrir que não há largura de banda suficiente nesse enlace. Quando isso acontece, o RSVP aciona uma atualização do banco de dados de engenharia de tráfego IGP, inundando as informações atualizadas de largura de banda na rede. O CSPF pode então recompor o caminho usando as informações atualizadas de largura de banda 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 rsvp-error-hold-time declaração no nível de [edit protocols mpls] hierarquia ou no nível de [edit logical-systems logical-system-name protocols mpls] 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 do PathErr. Veja a melhoria da precisão do banco de dados de engenharia de tráfego com as mensagens do RSVP PathErr.

Configuração de RSVP para interfaces não numeradas

O Junos OS oferece suporte à engenharia de tráfego RSVP em interfaces não numeradas. As informações de engenharia de tráfego sobre enlaces não numerados são realizadas 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 a comutação generalizada de rótulos multi-protocolo (GMPLS) e RFC 4205, extensões de sistema intermediário para sistema intermediário (IS-IS) em suporte a comutação generalizada de rótulos multi-protocolo (GMPLS). Links não numerados também podem ser especificados na sinalização de engenharia de tráfego MPLS, conforme descrito no 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 que participa da rede sinalizada por RSVP.

Para configurar o RSVP para interfaces não numeradas, você deve configurar o roteador com um ID do roteador usando a router-id declaração especificada no nível de [edit routing-options] hierarquia. O ID do roteador deve estar disponível para roteamento (normalmente você pode usar o endereço de loopback). As mensagens de controle RSVP para os links não numerados 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 redirecionar rapidamente em um roteador com interfaces não numeradas habilitadas, você deve configurar pelo menos dois endereços. Recomendamos que você configure uma interface secundária no loopback, além de configurar o ID do roteador.

Configuração do RSVP Node-ID Hellos

Você pode configurar olás RSVP baseados em nó ID para garantir que os roteadores da Juniper Networks possam interoperar com os equipamentos de outros fornecedores. Por padrão, o Junos OS usa o RSVP baseado em interface hellos. Olás RSVP baseados em nó-ID estão especificados no RFC 4558, protocolo de reserva de recursos baseado em Nó-ID (RSVP) Olá: Uma declaração de esclarecimento. Os olás de nó-ID RSVP são úteis se você tiver configurado o BFD para detectar problemas em interfaces RSVP, permitindo que você desabile olás de interface para essas interfaces. Você também pode usar olás de nó-ID para procedimentos graciosos de reinicialização.

Olás de nó-ID podem ser habilitados globalmente para todos os vizinhos RSVP. Por padrão, o suporte para o nó-ID está desativado. Se você não tiver habilitado IDs de nó RSVP no roteador, o Junos OS não aceita nenhum pacote hello de nó-ID.

Nota:

A partir do lançamento, o Junos 16.1 envia mensagens de olá ao RSVP por um LSP de bypass quando um está disponível. Veja no-node-hello-on-bypass informações sobre como reverter para o comportamento histórico de enviar olás sobre o próximo hop do IGP.

Para habilitar o nó-ID RSVP globalmente no roteador, inclua a declaração de nó-olá 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 RSVP globalmente. Esse tipo de configuração pode ser necessária em redes onde o roteador Juniper Networks tem inúmeras conexões RSVP com equipamentos de outros fornecedores. No entanto, se você desativar a interface RSVP globalmente, você também pode configurar um intervalo olá em uma interface RSVP usando a declaração hello-interval . Essa configuração desativa a interface RSVP em todo o mundo, mas permite que a interface RSVP olás na interface especificada (a interface RSVP em que você configura a hello-interval declaração). Essa configuração pode ser necessária em uma rede heterogênea na qual alguns dispositivos oferecem suporte a hellos de nó-ID RSVP e outros dispositivos com suporte a interface RSVP hellos.

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

  • [edit protocols rsvp]

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

Example: Configuração de LSPs sinalizados por RSVP

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

Requisitos

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

Visão geral e topologia

Usando o 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 RSVPLSP típico com sinal RSVP

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

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

Cópia de

Procedimento

Configuração rápida da CLI

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

Procedimento passo a passo

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

Para configurar o RSVP:

  1. Habilite a família MPLS em todas as interfaces de trânsito da rede MPLS.

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

  3. Habilite o processo MPLS na interface de trânsito na rede MPLS.

  4. Defina o LSP no roteador de entrada.

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

Resultados

Confirme sua configuração entrando no comando a show partir do modo de configuração. Se a saída não exibir a configuração pretendida, repita 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 no sistema foi substituída por elipses (...).

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

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

Verificação de vizinhos RSVP

Propósito

Verifique se cada dispositivo mostra os vizinhos RSVP apropriados — por exemplo, esse roteador R1 lista Figura 1 tanto o Roteador R3 quanto o Roteador R2 como vizinhos RSVP.

Ação

Da CLI, entre no show rsvp neighbor comando.

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

Verificando sessões de RSVP

Propósito

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

Ação

Da CLI, entre no 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 next-hop, para cada sessão RSVP estabelecida. Verifique as seguintes informações:

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

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

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

Verificando a presença de LSPs sinalizados por RSVP

Propósito

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

Ação

Da CLI, entre no show route table inet.3 comando.

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

Example: Configuração da malha automática RSVP

Os provedores de serviços costumam usar VPNs BGP e MPLS para dimensionar a rede de maneira eficiente e, ao mesmo tempo, fornecer serviços geradores de receita. Nesses ambientes, o BGP é usado para distribuir as informações de roteamento VPN na rede do provedor de serviços, enquanto o MPLS é usado para encaminhar esse tráfego VPN de um site vpn para outro.

Ao adicionar um novo roteador PE que participará de VPNs BGP e MPLS, todos os roteadores PE existentes anteriormente devem ser configurados para peer 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 demais para ser tratada.

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um roteador que executa o Junos OS Release 10.1 ou posterior.

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

Visão geral

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

Dado esse requisito, este exemplo só mostra a configuração no roteador PE recém-adicionado. Presume-se que a malha automática RSVP já foi configurada nos roteadores PE existentes.

Topologia

Existem Figura 2três roteadores PE existentes, PE1, PE2 e PE3, na topologia. O PE4 foi adicionado e a malha automática RSVP será 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: Rede de provedores de serviços com roteadores PERede de provedores de serviços com roteadores PE

Cópia de

Configurar a malha automática RSVP envolve realizar essas tarefas:

  • Habilitando a rsvp-te declaração de configuração no nível de [edit routing-options dynamic-tunnels dynamic-tunnel-name] hierarquia.

  • Configurando o elemento necessário destination-networks .

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

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

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

Configuração rápida da CLI

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

Roteador PE4

Configuração da malha automática RSVP

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte o uso do editor de CLI no modo de configuração no guia de usuário da CLI.

Para habilitar a malha automática RSVP:

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

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

Resultados

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

Verificação

Verificando a existência de túneis de malha automática RSVP no roteador PE4

Propósito

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

Ação

Verificando a existência de LSPs MPLS no roteador PE4

Propósito

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

Ação

Configuração de reconhecimentos hello para vizinhos RSVP sem sissão

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

Olá, mensagens recebidas de vizinhos RSVP que não fazem parte de uma sessão RSVP comum são descartadas. Se você configurar a hello-acknowledgements declaração no nível da [edit protocols rsvp] hierarquia, as mensagens de olá de vizinhos sem solução são reconhecidas com uma mensagem de reconhecimento olá. Quando olás são recebidos de vizinhos não-sion, uma relação de vizinho RSVP é criada e mensagens de olá periódicas agora podem ser recebidas do vizinho semessão. A hello-acknowledgements declaração é desabilitada por padrão. Configurar esta declaração permite que roteadores com capacidade para RSVP sejam descobertos usando pacotes hello e verifica se a interface é capaz de receber pacotes RSVP antes de enviar mensagens de configuração MPLS LSP.

Uma vez que você habilita reconhecimentos de olá para vizinhos RSVP sem sessão, o roteador continua a reconhecer mensagens de olá de quaisquer vizinhos RSVP sem sessão, a menos que a interface em si desabilite ou você altere a configuração. Os vizinhos baseados em interface não são automaticamente eliminados.

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

  • [edit protocols rsvp]

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

Comutação de LSPs longe de um nó de rede

Você pode configurar o roteador para alternar LSPs ativos longe de um nó de rede usando um LSP de bypass habilitado 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 do LSP protegido.
  2. Para preparar o roteador para começar a alternar o tráfego para longe 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 por essa interface em preparação para a comutação do tráfego para um caminho alternativo com base na funcionalidade OAM.

    Você pode configurar esta declaração 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 switch-away-lsps declaração para mudar o tráfego do LSP protegido para o LSP de bypass, ignorando efetivamente o dispositivo de rede downstream padrão. O enlace real não é derrubado por essa configuração.

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

    Você pode configurar esta declaração 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 à comutação de LSPs ativos longe de um nó de rede:

  • O recurso de saída é suportado apenas em roteadores da Série MX.

  • O recurso de afastamento não é suportado para o tráfego de comutação de LSPs primários de ponto para multiponto para contornar LSPs ponto a multiponto. Se você configurar a switch-away-lsps declaração para um LSP ponto a multiponto, o tráfego não será trocado para o LSP ponto a multiponto de bypass.

  • 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 fazer antes da pausa de LSPs sinalizados por RSVP. O comportamento de make-before-break normalmente faz com que o roteador tente primeiro re-sinalizar um LSP dinâmico antes de derrubar o original.

Configuração da proteção de configuração de RSVP

Você pode configurar o mecanismo de redirecionamento rápido de backup da instalação 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 ponto a multiponto são suportados. Este recurso é aplicável no seguinte cenário:

  1. Um link ou nó com falha está presente no caminho explícito rigoroso de um LSP antes que o LSP seja sinalizado.

  2. Há também um LSP de bypass que protege o enlace ou nó.

  3. RSVP sinaliza o LSP pelo LSP de bypass. O LSP aparece como se fosse originalmente configurado ao longo de seu caminho principal e, em seguida, falhou no LSP de bypass por causa da falha de enlace ou nó.

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

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

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

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

  • [edit protocols rsvp]

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

Configuração do balanceamento de carga em LSPs RSVP

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

Alternativamente, 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 declaração da policy-statement seguinte forma:

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

Uma vez aplicado o balanceamento de carga por pacote, 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 redirecionamento rápido do PFE. Para habilitar o redirecionamento rápido do PFE, inclua a policy-statement declaração de balanceamento de carga por pacote mostrado nesta seção na configuração de cada um dos roteadores onde um reroute pode ocorrer. Veja também a configuração de reroute rápido.

Você também pode equilibrar o tráfego entre os LSPs em proporção à quantidade de largura de banda configurada para cada LSP. Esse recurso pode distribuir melhor o tráfego em redes com recursos assimétricos de largura de banda 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 RSVP LSP, inclua a load-balance declaração com a opção bandwidth :

Você pode configurar esta declaração nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

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

Tenha em mente as seguintes informações quando você usar a load-balance declaração:

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

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

  • Para LSPs projetados por serviços diferenciados que reconhecem o tráfego, a largura de banda de um LSP é calculada resumindo a largura de banda de todos os tipos de classe.

Configuração da malha automática RSVP

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

Nota:

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

Para configurar a malha automática 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 seguintes declarações para habilitar a malha automática RSVP:

  • destination-networks— Especifique a faixa de prefixo ip versão 4 (IPv4) para a rede de destino. Túneis dinâmicos dentro da faixa de prefixo IPv4 especificada podem ser iniciados.

  • label-switched-path-template (Multicast)— Você pode configurar o modelo padrão explicitamente usando a opção default-template ou configurar um modelo LSP próprio usando a opção template-name . O modelo LSP funciona como uma configuração de modelo para os 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 para o tempo de atualização é de 45 segundos. Esse número é derivado do refresh-time valor padrão da declaração de 30, multiplicado por um valor fixo de 1,5. Essa computação difere do RFC 2205, que afirma 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. As mensagens de atualização são enviadas periodicamente para que os estados de reserva em nós vizinhos não façam um tempo de folga. Cada caminho e mensagem 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 configurado localmente de 1 a 255. O valor padrão é 3. Ele indica o número de mensagens que podem ser perdidas antes que um determinado estado seja declarado ultrapassado 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, ( –keep-multiplier 1) mensagens de atualização sucessivas devem ser perdidas antes que um estado de reserva seja excluído.

Não recomendamos configurar um temporizador de RSVP curto. Se for necessária uma descoberta rápida de um vizinho com falha, configure temporizadors de IGP curtos (OSPF ou IS-IS).

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

Você pode incluir esta 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 esta declaração nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

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

Preparando sessões de RSVP

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

Para sempre prever uma sessão quando a largura de banda for insuficiente, inclua a preemption declaração com a opção aggressive :

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

  • [edit protocols rsvp]

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

Para desativar a preempção da sessão de RSVP, inclua a preemption declaração com a opção disabled :

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

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

  • [edit protocols rsvp]

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

Configuração da sinalização de MTU no RSVP

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

Para configurar a sinalização de MTU no RSVP, inclua a path-mtu declaração:

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

  • [edit protocols mpls]

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

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

Habilitação da sinalização de MTU no RSVP

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

Você pode incluir esta 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 cometer a configuração, as alterações no comportamento de sinalização do MTU para RSVP fazem efeito na próxima vez que o caminho for atualizado.

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

Habilitação da fragmentação de pacotes

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

Você pode incluir esta 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 em conjunto com a mtu-signaling declaração.

Configuração de popping de salto final para LSPs

Por padrão, os LSPs sinalizados por RSVP usam o penúltimo hop popping (PHP). Figura 3 ilustra um LSP de salto penúltimo entre o Roteador PE1 e o Roteador PE2. O roteador CE1 encaminha um pacote para o seu próximo hop (Roteador PE1), que também é a entrada LSP. O roteador PE1 empurra o rótulo 1 no pacote e encaminha o pacote rotulado para o Roteador P1. O roteador P1 completa a operação padrão de troca de rótulos MPLS, trocando o rótulo 1 pelo rótulo 2 e encaminha o pacote para o Roteador P2. Como o Roteador P2 é o penúltimo roteador hop do LSP para o Roteador PE2, ele primeiro abre 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 explícito ou apenas um pacote IP ou VPLS simples. O roteador PE2 encaminha o pacote sem rótulos para o Roteador CE2.

Figura 3: Penúltimo salto para um LSPPenúltimo salto para um LSP

Você também pode configurar o ultimate-hop popping (UHP) (como mostrado ) Figura 4para LSPs sinalizados por 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 Figura 4) executa a operação padrão de troca de rótulos MPLS (neste exemplo, rótulo 2 para rótulo 3 ) antes de encaminhar o pacote para o roteador de saída PE2. O roteador PE2 coloca o rótulo externo e realiza uma segunda olhada no endereço do pacote para determinar o destino final. Em seguida, ele encaminha o pacote para o destino apropriado (seja o Roteador CE2 ou o Roteador CE4).

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

Os aplicativos de rede a seguir exigem que você configure LSPs UHP:

  • MPLS-TP para monitoramento de desempenho e OAM na banda

  • Circuitos virtuais de proteção de borda

Os recursos a seguir não suportam o comportamento de UHP:

  • LSPs sinalizados por LDP

  • LSPs estáticos

  • LSPs ponto a multiponto

  • CCC

  • traceroute Comando

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

Para LSPs sinalizados por RSVP ponto a ponto, o comportamento de UHP é sinalizado a partir da entrada LSP. Com base na configuração do roteador de entrada, o RSVP pode sinalizar o LSP UHP com o conjunto de bandeiras não PHP. As mensagens RSVP PATH carregam as duas bandeiras no objeto LSP-ATTRIBUTES. Quando o roteador de saída recebe a mensagem PATH, ele atribui 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 parte inferior da pilha de rótulos foi ou não alcançada.

  • Roteamento S=0 — indica que há mais rótulos na pilha. O próximo salto para esta rota aponta para a tabela de roteamento mpls.0, desencadeando uma busca de rótulos MPLS em cadeia para descobrir os rótulos MPLS restantes na pilha.

  • Rota S=1 — indica que não há mais rótulos. O próximo hop aponta para a tabela de roteamento inet.0 se a plataforma oferecer suporte a uma busca em cadeia e multi-família. Alternativamente, a rota de rótulos pode apontar para uma interface VT para iniciar o encaminhamento de IP.

Se você habilitar LSPs UHP, aplicativos MPLS, como VPNs de Camada 3, VPLS, VPNs de Camada 2 e circuitos de Camada 2 podem usar os LSPs UHP. O seguinte explica como os LSPs UHP afetam os diferentes tipos de aplicativos MPLS:

  • VPNs de camada 2 e circuitos de Camada 2 — um pacote chega ao roteador PE (saída do UHP LSP) 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 alça 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 próximo salto do roteador CE.

  • VPN de Camada 3 — Um pacote chega ao roteador PE (saída do UHP LSP) 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 alça de tabela para a tabela de roteamento mpls.0. Há dois casos nesse cenário. Por padrão, as VPNs de Camada 3 anunciam o rótulo de hop por próximo. Uma pesquisa baseada no rótulo interno resulta no próximo salto em direção ao roteador CE. No entanto, se você tiver configurado a vrf-table-label declaração para a instância de roteamento VPN de Camada 3, o rótulo LSI interno aponta para a tabela de roteamento VRF. Uma busca por IP também está concluída para a tabela de roteamento VRF.

    Nota:

    UHP para VPNs de Camada 3 configuradas com a vrf-table-label declaração é suportada apenas em plataformas de roteamento universal 5G da Série MX.

  • VPLS — Um pacote chega 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 VPLS (S=1). Uma pesquisa baseada no rótulo de transporte resulta na alça de 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 estiverem configurados (ou uma interface VT não estiver disponível). Os roteadores da Série MX 3D oferecem suporte a uma busca em cadeia e uma busca multi-família.

    Nota:

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

  • IPv4 sobre MPLS — um pacote chega ao roteador PE (saída do UHP LSP) com um rótulo (S=1). Uma busca baseada neste rótulo retorna uma interface de túnel VT. Outra busca por IP é concluída na interface VT para determinar onde encaminhar o pacote. Se a plataforma de roteamento oferece suporte a lookups multifamiliares e encadeados (por exemplo, roteadores MX 3D e roteadores de transporte de pacotes da Série PTX), procure com base na rota de rótulos (S=1) para a tabela de roteamento inet.0.

  • IPv6 sobre MPLS — Para tunelamento IPv6 por MPLS, os roteadores PE anunciam rotas IPv6 entre si com um valor de rótulo de 2. Este é o rótulo nulo explícito para IPv6. Como resultado, os próximos hops de encaminhamento para rotas IPv6 que são aprendidos com roteadores PE remotos normalmente empurram dois rótulos. O rótulo interno é 2 (pode ser diferente se o roteador PE publicitário 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 IPv6 explicit-null (rótulo 2). A busca baseada no rótulo interno na tabela de roteamento mpls.0 redireciona para a tabela de roteamento mpls.0. Nos roteadores da Série MX 3D, o rótulo interno (rótulo 2) é retirado e um lookup IPv6 é feito usando a tabela de roteamento inet6.0.

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

As declarações a seguir permitem o salto final 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 permitir o salto final, inclua a ultimate-hop-popping declaração:

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

    Nota:

    Quando você permite o popping de salto final, o RSVP tenta renunciar aos LSPs existentes como LSPs de última geração de salto em uma forma make-before-break. Se um roteador de saída não tiver suporte para o estouro de salto final, o LSP existente será derrubado (o RSVP envia uma mensagem pathTear ao longo do caminho de um LSP, removendo o estado de caminho e o estado de reserva dependente e liberando os recursos de rede associados).

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

  2. Se você quiser habilitar os próximos hops de última geração e encadeados apenas em roteadores da Série MX 3D, você também precisa configurar a opção enhanced-ip para a network-services declaração:

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

Configuração de RSVP para colocar o rótulo no roteador de salto final

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 de penúltimo salto remove o rótulo e envia o pacote para o roteador de saída. Quando o popping de salto final é ativado, o rótulo 0 (ip versão 4 [IPv4] Explicit Null label) é anunciado. O salto final garante que quaisquer pacotes que atravessem uma rede MPLS incluam um rótulo.

Nota:

Os roteadores da Juniper Networks fazem fila de pacotes com base no rótulo de entrada. Roteadores de outros fornecedores podem fazer filas de pacotes de maneira diferente. Tenha isso em mente ao trabalhar com redes que contêm roteadores de vários fornecedores.

Para configurar o salto final para RSVP, inclua a explicit-null declaração:

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

  • [edit protocols mpls]

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

Habilitando o ultimate-hop popping em LSPs de ponto a multiponto

Por padrão, para LSPs ponto a ponto e ponto a multiponto, o popping de penúltimo salto é usado para tráfego MPLS. Os rótulos MPLS são removidos de pacotes no roteador pouco antes do roteador de saída do LSP. Os pacotes IP simples são então encaminhados para o roteador de saída. Para estalar o salto final, o roteador de saída é responsável pela remoção do rótulo MPLS e pelo processamento do pacote IP simples.

Pode ser benéfico permitir o salto final em LSPs ponto a multiponto, especialmente quando o tráfego de trânsito está atravessando o mesmo dispositivo de saída. Se você habilita o popping de salto final, uma única cópia do tráfego pode ser enviada pelo link de entrada, economizando uma largura de banda significativa. Por padrão, o salto final é desativado.

Você permite o salto final para LSPs ponto a multiponto configurando a tunnel-services declaração. Quando você permite o estouro de salto final, o Junos OS seleciona uma das interfaces de túnel de loopback virtual (VT) disponíveis para devolver os pacotes ao PFE para encaminhamento 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 seleciona outra interface VT com largura de banda suficiente para o controle de admissão.

Se um LSP exigir mais largura de banda do que está disponível em qualquer uma das interfaces de VT, o popping de salto final não pode ser habilitado e o popping de penúltimo salto está habilitado.

Para que os LSPs ponto a multiponto funcionem corretamente, o roteador de saída deve ter um PIC que forneça serviços de túnel, como o PIC de serviços de túnel ou o PIC de serviços adaptativos. Os serviços de túnel são necessários para o estouro do rótulo MPLS final e para o retorno de pacotes para buscas de endereço IP.

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

Para permitir o salto final para os LSPs de ponto a multiponto de saída em um roteador, configure a tunnel-services declaração:

Você pode configurar esta declaração nos seguintes níveis de hierarquia:

  • [edit protocols rsvp]

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

Para permitir o salto final para LSPs de ponto a multiponto de saída, você também deve configurar a interface declaração com a opção all :

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

Rastreamento do tráfego de protocolo RSVP

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

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

  • [edit protocols rsvp]

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

Você pode especificar as seguintes bandeiras específicas do RSVP na declaração RSVP traceoptions :

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

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

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

  • event— eventos relacionados a RSVP (ajuda a rastrear eventos relacionados ao RSVP gracioso reinício)

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

  • packets— Todos os pacotes 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 sinalizados por RSVP sobem e descem.

Nota:

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

Para visualizar o arquivo de log gerado quando você habilitar rastreamentos RSVP, emitir o show log file-name comando, onde file-name está o arquivo especificado usando a traceoptions declaração.

Para obter informações gerais sobre o rastreamento e opções de rastreamento global, consulte a Biblioteca de protocolos de roteamento Junos OS para dispositivos de roteamento.

Exemplos: Rastreamento do tráfego de protocolo RSVP

Rastreie as mensagens de caminho do RSVP em detalhes:

Rastreie todas as mensagens de RSVP:

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

Rastrear as transições de estado do RSVP:

Saída de arquivo de log RSVP

A saída de amostra a seguir é gerada pela emissão do show log file-name comando em um roteador no qual as traceoptions RSVP foram habilitadas com a state bandeira configurada. O LSP E-D sinalizado por RSVP é mostrado sendo derrubado em 11 de março de 14:04:36.707092. Em 11 de março de 14:05:30.101492, é mostrado voltando.

Reinício gracioso do RSVP

A reinicialização graciosa do RSVP permite que um roteador em 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 então cooperar com o roteador de reinicialização. O roteador de reinicialização ainda pode encaminhar tráfego MPLS durante o período de reinicialização; a convergência na rede não é interrompida. A reinicialização não é visível para o resto da rede, e o roteador de reinicialização não é removido da topologia da rede. A reinicialização graciosa do RSVP pode ser habilitada em roteadores de trânsito e roteadores de entrada. Ele está disponível para LSPs ponto a ponto e LSPs ponto a ponto.

A reinicialização graciosa do RSVP é descrita nas seguintes seções:

Terminologia de reinício gracioso do 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 reiniciando antes de declarar que o roteador está morto e eliminando estados.

O Junos OS pode substituir o tempo de reinicialização anunciado por um vizinho se o tempo for superior a 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 reiniciado. Se o tempo de reinicialização for zero, o vizinho reiniciado pode ser imediatamente declarado morto.

Tempo de recuperação (em milissegundos)

Só se aplica quando o canal de controle estiver em alta (a troca de olá está completa) antes do tempo de reinicialização. Aplica-se apenas a falhas nodais.

Quando um reinício gracioso está em andamento, o tempo restante para concluir uma recuperação é anunciado. Em outros momentos, 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ó reiniciado 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 dentro de um período de metade do tempo de recuperação. O nó de reinicialização considera sua reinicialização graciosa completa após seu tempo de recuperação anunciado.

Operação de reinício gracioso do RSVP

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

A reinicialização graciosa do RSVP requer o seguinte de um roteador reiniciado e dos vizinhos do roteador:

  • Para o roteador de reinicialização, o RSVP tenta manter as rotas instaladas pelo RSVP e os rótulos alocados, para que o tráfego continue a ser encaminhado sem interrupções. A reinicialização graciosa do RSVP é feita 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 gracioso RSVP habilitado, permitindo assim que eles ajudem um roteador a tentar reiniciar o RSVP.

Um objeto chamado Restart Cap que é enviado em mensagens de olá RSVP anuncia o recurso de reinicialização de um nó. O nó vizinho envia um objeto Recover Label para o nó de reinicialização para recuperar seu estado de encaminhamento. Esse objeto é essencialmente o rótulo antigo que o nó de reinicialização anunciou antes do nó cair.

A seguir lista os comportamentos de reinicialização graciosos do RSVP, que variam dependendo da configuração e de quais recursos são habilitados:

  • Se você desativar o modo helper, o Junos OS não tenta ajudar um vizinho a reiniciar o RSVP. Todas as informações que chegam com um objeto Restart Cap de um vizinho são ignoradas.

  • Quando você habilita a reinicialização graciosa sob a configuração da instância de roteamento, o roteador pode reiniciar com a ajuda de seus vizinhos. O RSVP anuncia um objeto Restart Cap (RSVP RESTART) em mensagens de olá nas quais os tempos de reinicialização e recuperação são especificados (nenhum dos valores é 0).

  • Se você desativar explicitamente a reinicialização graciosa do RSVP sob o nível de [protocols rsvp] hierarquia, o objeto Restart Cap é anunciado com tempos de reinicialização e recuperação especificados como 0. A reinicialização de roteadores vizinhos é suportada (a menos que o modo helper seja desativado), mas o próprio roteador não preserva o estado de encaminhamento RSVP e não pode recuperar seu estado de controle.

  • Se após uma reinicialização, o RSVP perceber que nenhum estado de encaminhamento foi preservado, o objeto Restart Cap é anunciado com os tempos de reinicialização e recuperação especificados como 0.

  • Se a reinicialização e o modo helper forem desativados, a reinicialização graciosa do RSVP será completamente desativada. O roteador não reconhece nem anuncia os objetos de reinicialização graciosos do RSVP.

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

Ao contrário de outros protocolos, não há como o RSVP determinar que ele completou um procedimento de reinicialização, além de um tempo limite fixo. Todos os procedimentos de reinicialização graciosos do RSVP são baseados em temporizador. Um show rsvp version comando pode indicar que a reinicialização ainda está em andamento, mesmo que todas as sessões de RSVP estejam de volta e as rotas sejam restauradas.

Processamento do objeto de tampa de reinicialização

As seguintes suposições são feitas sobre um vizinho com base no objeto Restart Cap (assumindo que uma falha no canal de controle pode ser distinguida inequívocamente de uma reinicialização de nó):

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

  • Após a reinicialização, um vizinho anunciando um objeto Restart 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 quaisquer estados relacionados a esse vizinho são eliminados, independentemente do valor do tempo de reinicialização.

  • Após um reinício, um vizinho anunciando seu tempo de recuperação com um valor diferente de 0 pode manter ou manteve o estado de encaminhamento. Se o roteador local estiver ajudando seu vizinho com procedimentos de reinicialização ou recuperação, ele envia um objeto Recover Label para este vizinho.

Configuração da reinicialização graciosa do RSVP

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

  • A reinicialização e o modo helper são ativados (o padrão).

  • A reinicialização graciosa é ativada, mas o modo helper é desativado. Um roteador configurado dessa forma pode ser reiniciado de maneira graciosa, mas não pode ajudar um vizinho com seus procedimentos de reinicialização e recuperação.

  • A reinicialização graciosa é desativada, mas o modo helper é ativado. Um roteador configurado dessa forma não pode reiniciar de maneira graciosa, mas pode ajudar um vizinho reiniciando.

  • A reinicialização e o modo helper graciosos são desativados. Essa configuração desativa completamente a reinicialização graciosa do RSVP (incluindo procedimentos de reinicialização e recuperação e modo helper). O roteador se comporta como um roteador que não suporta reinicialização graciosa do RSVP.

Nota:

Para ativar a reinicialização graciosa do RSVP, você deve definir o temporizador de reinicialização gracioso global para pelo menos 180 segundos.

As seções a seguir descrevem como configurar o reinício gracioso do RSVP:

Ativando o recomeço gracioso para todos os protocolos de roteamento

Para habilitar uma reinicialização graciosa para RSVP, você precisa habilitar uma reinicialização graciosa para todos os protocolos que oferecem suporte a uma reinicialização graciosa no roteador. Para obter mais informações sobre o recomeço gracioso, consulte a Biblioteca de protocolos de roteamento Junos OS para dispositivos de roteamento.

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

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

  • [edit routing-options]

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

Desativação de reinício gracioso para RSVP

Por padrão, a reinicialização graciosa do RSVP e o modo de ajuda RSVP são ativados quando você permite uma reinicialização graciosa. No entanto, você pode desativar um ou ambos os recursos.

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

Desativação do modo de ajuda de RSVP

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

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

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

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

Para configurar o atraso entre quando o roteador descobrir que um roteador vizinho caiu e quando declarar o vizinho para baixo, inclua a maximum-helper-restart-time declaração no nível de [edit protocols rsvp graceful-restart] hierarquia. Esse valor é aplicado a todos os roteadores vizinhos, por isso deve ser baseado no tempo necessário pelo vizinho RSVP mais lento para reiniciar.

Visão geral dos túneis LSP RSVP

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

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

Um túnel RSVP LSP adiciona o conceito de uma adjacência de encaminhamento, semelhante à usada para comutação generalizada de rótulos multiprotocol (GMPLS). (Para obter mais informações sobre o GMPLS, consulte o Junos GMPLS User Guide.

A adjacência de encaminhamento cria um caminho em túnel para o envio de dados entre dispositivos peer em uma rede RSVP LSP. Assim que um LSP de adjacência de encaminhamento (FA-LSP) tiver sido estabelecido, outros LSPs podem ser enviados pelo FA-LSP usando O caminho mais curto restrito primeiro (CSPF), protocolo de gerenciamento de links (LMP), Open Shortest Path First (OSPF) e RSVP.

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

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

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

  • Extensões RSVP-TE — 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 do caminho para LSPs de pacotes que viajam para interfaces virtuais de peer definidas em uma configuração LMP.

    Nota:

    Começando pelo Junos OS Release 15.1, o suporte de 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 partições independentes de topologia de TE, o que permite que cada domínio de TE dividido seja dimensionado de forma independente. O RSVP-TE de várias instâncias oferece a flexibilidade de escolher manualmente as entidades de plano de controle que precisam ser conscientes de instâncias, por exemplo, um roteador pode participar de várias instâncias de TE enquanto ainda executa uma única instância BGP.

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

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

    • Garantindo a prontidão do plano de dados LSP durante a resignaçã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 mudar 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, pois o LSP de saída precisa responder às solicitações de ping LSP. O mecanismo de auto-ping LSP permite que a LER de entrada crie mensagens de resposta de ping LSP e as envie pelo plano de dados LSP. Ao receber essas mensagens, a LER de saída as encaminha para a entrada, indicando a linha de vida do plano de dados LSP. Isso garante que o LSP não comece a transportar tráfego antes que o plano de dados seja programado.

    • Removendo o limite rígido atual de 64K LSPs em um roteador de entrada e dimensionando o número total de LSPs com LSPs sinalizados por RSVP-TE. 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.

    • Evitando a derrubada abrupta de LSPs pelo roteador de entrada por causa do atraso na sinalização do LSP nos roteadores de trânsito.

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

    Nota:

    A partir do Junos OS Release 17.4, um temporizador padrão de 1800 segundos para auto-ping é introduzido.

As seguintes limitações existem para as hierarquias de LSP:

  • Os LSPs baseados em circuito cross-connect (CCC) não são suportados.

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

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

  • Os LSPs ponto a multiponto não são suportados em todos os FA-LSPs.

Example: Configuração do túnel LSP RSVP

Figura 5: Diagrama da topologia do túnel LSP RSVPDiagrama da topologia do túnel LSP RSVP

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

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

Roteador 0

No Roteador 1, configure um FA-LSP para chegar ao Roteador 4. Estabeleça um link de engenharia de tráfego LMP e uma relação de peer LMP com o Roteador 4. Faça referência ao FA-LSP no link de engenharia de tráfego e adicione a interface peer tanto no OSPF quanto no RSVP.

Quando o LSP de retorno de ponta a ponta chega ao Roteador 1, a plataforma de roteamento realiza uma busca por roteamento e pode encaminhar o tráfego para o Roteador 0. Certifique-se de configurar o OSPF corretamente entre 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 principal.

Roteador 2

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

Roteador 3

No Roteador 4, configure um caminho de retorno FA-LSP para chegar ao Roteador 1. Estabeleça um link de engenharia de tráfego LMP e uma relação de peer LMP com o Roteador 1. Faça referência ao FA-LSP no link de engenharia de tráfego e adicione a interface peer tanto no OSPF quanto no RSVP.

Quando o LSP de ponta a ponta inicial chega ao Roteador 4, a plataforma de roteamento realiza uma busca por roteamento e pode encaminhar o tráfego para o Roteador 5. Certifique-se de configurar o 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 viaja até o Roteador 0. Use um caminho rigoroso que atravessa o Roteador 4 e o enlace de engenharia de tráfego LMP que viaja do Roteador 4 ao Roteador 1.

Roteador 5

Verificando seu trabalho

Para verificar se seu túnel RSVP LSP está funcionando corretamente, emitiu 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 com o exemplo de configuração, veja as seguintes seções:

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. Nesse caso, procure os caminhos do Roteador 1 (10.255.41.216) e do Roteador 4 (10.255.41.217) que fazem referência aos endereços de enlace de engenharia de tráfego LMP de172.16.30.1.172.16.30.2 Você também pode emitir o show rsvp session extensive comando para procurar o caminho do LSP de ponta a ponta enquanto ele viaja para o Roteador 5 pelo FA-LSP.

Roteador 1

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

Configuração de interfaces de peer no OSPF e RSVP

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

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

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

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

Estabelecendo informações do caminho 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 endereço de próximo salto. Quando o CSPF é suportado, você pode usar qualquer opção de caminho que desejar. No entanto, quando o CSPF é desativado com a no-cspf declaração no nível de [edit protocols mpls label-switched-path lsp-name] hierarquia, você deve usar caminhos rigorosos.

Nota:

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

Opção: Derrubando RSVP LSPs graciosamente

Você pode derrubar um RSVP LSP em um processo de duas etapas que retira graciosamente a sessão RSVP usada pelo LSP. Para todos os vizinhos que suportam o teardown gracioso, uma solicitação de demolição é enviada pela plataforma de roteamento para o endpoint de destino para o LSP e 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 que a sessão de RSVP seja retirada. Uma segunda mensagem é enviada pela plataforma de roteamento para concluir o rompimento da sessão de RSVP. Se um vizinho não aceita um teardown gracioso, a solicitação é tratada como um teardown de sessão padrão em vez de gracioso.

Para realizar um teardown gracioso 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 LSP do remetente RSVP e o identificador de túnel da sessão RSVP. Para usar essas qualificações, inclua asconnection-source, connection-destinatione lsp-idtunnel-id opções quando você emitir o clear rsvp session gracefully comando.

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

Tabela de histórico de liberação
Versão
Descrição
19.4R1
16.1
No entanto, a partir do Junos OS Release 16.1, quando o RSVP olá mensagens tempo de saída, as sessões de RSVP são derrubadas.