Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuração do RSVP

Configuração mínima de RSVP

Para habilitar o RSVP em uma única interface, inclua a declaração e especifique a interface usando a declaração.rsvpinterface Esta é a configuração mínima de RSVP. Todas as outras declarações de configuração do 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 a variável.allinterface-name

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

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

Você pode configurar o MPLS para configurar caminhos sinalizados usando a declaração no nível de hierarquia.label-switched-path[edit protocols mpls] 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 do RSVP e verificar as tabelas de roteamento locais, o RSVP inicia uma sessão para cada LSP. A sessão é originária do roteador local e é destinada ao alvo do LSP.

Quando uma sessão de RSVP é criada com sucesso, o LSP é configurado ao longo dos caminhos criados pela sessão de RSVP. Se a sessão de RSVP não tiver sucesso, 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: O 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 de rota de registro não é obrigatório.

Para configurar o MPLS e torná-lo um cliente do 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 possam 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 comuados por rótulos (LSPs) de RSVP para usar uma métrica de atraso para computar o caminho. Para configurar, use as opções de CLI que introduzimos sob a hierarquia.[edit protocols mpls label-switched-path name]

Exemplo: Configuração de RSVP e MPLS

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

O seguinte 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 do RSVP em cada interface, incluindo as seguintes declarações na configuração da interface:

  • e — Habilite todos os recursos de redução de atualização do RSVP:aggregatereliable Agrupamento de mensagens RSVP, ID de mensagem RSVP, entrega confiável de mensagens e atualização sumária.

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

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

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

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

Se a 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.no-reliable 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 a declaração ou com as declarações e declarações.aggregateno-reliablereliableno-aggregate Se um vizinho RSVP enviar um objeto de atualização sumária para este roteador, nenhum erro será gerado, mas o objeto De atualização sumária não pode ser processado. Consequentemente, os estados RSVP podem ficar sem tempo neste roteador se o vizinho estiver contando apenas com a atualização sumária para atualizar esses estados 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 declaração:aggregate

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 o agrupamento de mensagens RSVP e atualizar o resumo, inclua a declaração:no-aggregate

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 de mensagem do RSVP e a entrega confiável de mensagens em uma interface, inclua a declaração:reliable

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 de mensagem do RSVP, a entrega confiável de mensagens e a atualização sumária, incluem a declaração:no-reliable

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]

Determinando 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 do RSVP

  • As mensagens RSVP reais recebidas do vizinho

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

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

Configurando o intervalo de olá do RSVP

O RSVP monitora o status dos vizinhos de 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 desativado (porque pacotes de olá não estão mais sendo recebidos), o RSVP também derruba esse vizinho. No entanto, os protocolos IGP e RSVP ainda agem de forma independente ao criar um vizinho.

Para os roteadores da Juniper Networks, a configuração de um intervalo de olá RSVP mais curto ou mais longo não tem impacto sobre se uma sessão de RSVP foi ou não derrubada. As sessões de RSVP são mantidas, mesmo que os pacotes de olá RSVP não estejam mais sendo 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 time-out, as sessões de RSVP são derrubadas.

O intervalo de olá do RSVP também pode ser afetado quando o equipamento de outro fornecedor derruba 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 de olá, inclua a declaração:hello-interval

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 informações sobre como reverter para o comportamento histórico de enviar olás sobre o IGP no próximo salto.no-node-hello-on-bypass

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

Configuração da autenticação do 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 é desativada.

A autenticação RSVP usa um hashed Message Authentication Code (HMAC)-MD5 message-based digest. Esse esquema produz um digestão de mensagem baseado 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. Uma vez configurada a autenticação, todas as mensagens RSVP recebidas e transmitidas com todos os vizinhos são autenticadas nesta interface.

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

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

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]

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ê subscreve 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, veja Configurando a porcentagem de assinatura de largura de banda para LSPs.Configurando a porcentagem de assinatura de largura de banda para LSPs

Configurando o limite 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 de banco de dados de engenharia de tráfego se origina 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 então sabem 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, pode não ser desejável realizar uma atualização de IGP para pequenas mudanças na largura de banda. Ao configurar a declaração no nível de hierarquia, você pode ajustar o limiar no qual uma mudança na largura de banda reservada desencadeia uma atualização do IGP.update-threshold[edit protocols rsvp]

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 de IGP. Por exemplo, se você tiver configurado a 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 link, o RSVP não aciona uma atualização do IGP.update-threshold No entanto, se a largura de banda reservada em um link mudar em 20% da largura de banda do link, o RSVP aciona uma atualização do IGP.

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

Se o valor limite estiver configurado para maior que 20% da largura de banda nesse link, o valor limite 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 200Mbps, ela será limitada a 200Mbps.threshold-valuethreshold-value Ele é exibido como 20.000% e como 200Mbps.threshold-percentthreshold-value

Nota:

As duas opções são mutuamente exclusivas.threshold-percentthreshold-value 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 é configurada, a outra opção é calculada e exibida na CLI.

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

Para ajustar o limite em que uma mudança na largura de banda reservada desencadeia uma atualização do IGP, inclua a declaração de limite de atualização .update-threshold Devido ao 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, ele pode descobrir que não há largura de banda suficiente nesse link. 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 declaração no nível de hierarquia ou no nível hierárquico 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.rsvp-error-hold-time[edit protocols mpls][edit logical-systems logical-system-name protocols mpls] Veja a precisão do banco de dados de engenharia de tráfego melhorando com as mensagens RSVP PathErr.Melhorando a precisão do banco de dados de engenharia de tráfego com mensagens RSVP PathErr

Configuração do 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 links não numerados são realizadas nas extensões de engenharia de tráfego IGP para OSPF e IS-IS, conforme descrito na RFC 4203, extensões 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 na RFC 3477, sinalizando links não numerados no Protocolo de ReServação de Recursos - Engenharia de Tráfego (RSVP-TE). Esse recurso permite que você evite ter que configurar 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 uma ID do roteador usando a declaração especificada no nível de hierarquia.router-id[edit routing-options] A ID do roteador deve estar disponível para roteamento (normalmente você pode usar o endereço loopback). As mensagens de controle do 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 enlaces 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 de olás de nós do RSVP

Você pode configurar olás RSVP baseados em nós para ID para garantir que os roteadores da Juniper Networks possam interoperar com os equipamentos de outros fornecedores. Por padrão, o Junos OS usa olás RSVP baseados em interface. Olás RSVP baseados em nós são especificados no RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Olá: Uma declaração de desapuração. Os olás de nó-ID do 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.

Os olás de ID de nós podem ser habilitados globalmente para todos os vizinhos RSVP. Por padrão, o suporte de oi de nós-ID está desativado. Se você não tiver habilitado IDs de nó RSVP no roteador, o Junos OS não aceita nenhum pacote de olá 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 informações sobre como reverter para o comportamento histórico de enviar olás sobre o IGP no próximo salto.no-node-hello-on-bypass

Para permitir que o nó-ID do RSVP seja incluído 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 de olá em uma interface RSVP usando a declaração hello-interval .hello-interval (Protocols RSVP) 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 declaração).hello-interval Essa configuração pode ser necessária em uma rede heterogênea na qual alguns dispositivos oferecem suporte a olás de nós RSVP e outros dispositivos com suporte à interface RSVP.

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

  • [edit protocols rsvp]

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

Exemplo: 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 dos 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 sinalização RSVPLSP típico com sinalização RSVP

Para estabelecer um LSP entre roteadores, você deve habilitar individualmente a família MPLS e configurar o 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 CSPF, garantindo que os hosts C1 e C2 usem o LSP sinalizado por RSVP que corresponde ao caminho mais curto do IGP da rede.

Configuração

Procedimento

Configuração rápida da CLI

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

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 na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos15.1/information-products/pathway-pages/junos-cli/junos-cli.html

Para configurar o RSVP:

  1. Habilite a família MPLS em todas as interfaces de trânsito na 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 inserindo o comando a partir do modo de configuração.show 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 saída de comando inclui apenas a configuração que é relevante para este exemplo.show Qualquer outra configuração no sistema foi substituída por elipses (...).

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

Verificação

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

Verificando os vizinhos do RSVP

Propósito

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

Ação

A partir da CLI, entre no comando.show rsvp neighbor

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

Verificação das 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 de reserva de largura de banda está ativo.

Ação

A partir da CLI, entre no comando.show rsvp session detail

A saída mostra as informações detalhadas, incluindo IDs de sessão, reserva de largura de banda e endereços de próximo salto para cada sessão RSVP estabelecida. Verifique as seguintes informações:

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

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

  • Para , o valor apropriado de largura de banda, aparece.Tspec10Mbps

Verificando a presença de LSPs sinalizados por RSVP

Propósito

Verifique 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, verifique se a tabela de roteamento do roteador de entrada R1 tem um LSP configurado para o endereço de loopback do Roteador R7.inet.3Figura 1

Ação

A partir da CLI, entre no comando.show route table inet.3

A saída mostra as rotas RSVP que existem na tabela de roteamento.inet.3 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.

Exemplo: Configuração da malha automática do RSVP

Os provedores de serviços costumam usar VPNs BGP e MPLS para dimensionar a rede de forma eficiente e, ao mesmo tempo, fornecer serviços de geração de receita. Nesses ambientes, o BGP é usado para distribuir as informações de roteamento VPN pela 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. À medida que cada novo roteador PE é adicionado à rede do provedor de serviços, a carga de configuração logo se torna muito para lidar.

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 parte MPLS da rede. A configuração em todos os roteadores PE permite que o RSVP crie automaticamente os LSPs necessários quando um novo roteador PE é adicionado.rsvp-te

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 o RSVP como protocolo de sinalização de caminho comuado por 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 configuração.rsvp-te Para que a malha automática RSVP funcione corretamente, todos os roteadores PE na configuração da malha completa devem ter a declaração configurada.rsvp-te Isso garante que quaisquer novos roteadores PE que forem adicionados posteriormente também se beneficiarão do recurso de malha automática, desde que também estejam configurados com a declaração.rsvp-te

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

Topologia

Há três roteadores PE existentes, PE1, PE2 e PE3, na topologia.Figura 2 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

Configuração

A configuração da malha automática do RSVP envolve a execução dessas tarefas:

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

  • 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 do intervalo de prefixo especificado podem ser criados.

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

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

Configuração rápida da CLI

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

Roteador PE4

Configuração da malha automática do 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, veja Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

Para habilitar a malha automática RSVP:

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

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

Resultados

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

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, emita o comando do modo operacional.show dynamic-tunnels database Este comando mostrará a rede de destino à 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, emita o comando do modo operacional.show mpls lsp Este comando mostrará o estado dos LSPs MPLS.

Ação

Configuração de reconhecimentos de olá para vizinhos RSVP sem sessão

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

Olá, as mensagens recebidas de vizinhos do RSVP que não fazem parte de uma sessão de RSVP comum são descartadas. Se você configurar a declaração no nível de hierarquia, as mensagens de olá de vizinhos sem sessão são reconhecidas com uma mensagem de reconhecimento de olá.hello-acknowledgements[edit protocols rsvp] Quando os olá 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 não-sion. A declaração é desativada por padrão.hello-acknowledgements A configuração dessa declaração permite que roteadores com capacidade de RSVP sejam descobertos usando pacotes olá e verifica se a interface é capaz de receber pacotes RSVP antes de enviar mensagens de configuração MPLS LSP.

Assim que você habilitar reconhecimentos de olá para vizinhos RSVP sem sessão, o roteador continua a reconhecer mensagens de olá de qualquer vizinho RSVP sem sessão, a menos que a interface em si desabilite ou altere a configuração. Os vizinhos baseados em interface não são automaticamente excluídos.

Você pode incluir essa 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 afastar LSPs ativos 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 enlaces ou nós para o tráfego que precisa passar pelo dispositivo de rede que pretende desabilitar. 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 mudar o tráfego para longe de um nó de rede, configure a declaração:always-mark-connection-protection-tlv

    Em seguida, o roteador marca todo o tráfego OAM que transita por essa interface em preparação para mudar o 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 declaração para mudar o tráfego do LSP protegido para o LSP de bypass, ignorando efetivamente o dispositivo de rede downstream padrão.switch-away-lsps O link em si não é derrubado por essa configuração.

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

    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 para longe de um nó de rede:

  • O recurso de desligamento é compatível apenas com roteadores da Série MX.

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

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

Configuração da proteção de configuração do 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 o nó.

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

  4. Quando o link ou nó tiver se recuperado, o LSP pode ser revertido automaticamente para o caminho principal.

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

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

Você pode incluir essa 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 entre 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 será encaminhado por ele.

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

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

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

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

Você também pode equilibrar o tráfego entre os LSPs em proporção com a 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 LSP do RSVP, inclua a declaração com a opção :load-balancebandwidth

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

  • [edit protocols rsvp]

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

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

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

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

  • Para LSPs projetados por serviços diferenciados, conscientes do 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 do RSVP

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

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 declaração:rsvp-te

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 do intervalo de prefixo IPv4 especificado podem ser iniciados.

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

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

O RSVP usa dois parâmetros de temporizantes 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 valor padrão da declaração de 30, multiplicado por um valor fixo de 1,5.refresh-time Essa computação difere da 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 percam tempo. Cada caminho e mensagem resv transporta o valor do temporizante 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 obsoleto 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 de reserva seja excluído.keep-multiplier

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

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

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 declaração:keep-multiplier

Você pode incluir essa 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 é antecipada apenas por uma nova sessão de maior prioridade.

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

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 preempção da sessão do RSVP, inclua a declaração com a opção :preemptiondisabled

Para voltar ao padrão (ou seja, antecipar uma sessão apenas para uma nova sessão de maior prioridade), inclua a declaração com a opção :preemptionnormal

Você pode incluir essa 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 da 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 no 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 permitir a fragmentação de pacotes.

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

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 descrevem como permitir a fragmentação de pacotes e a sinalização de MTU no RSVP:

Habilitando a sinalização de MTU no RSVP

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

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]

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

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

Habilitando a fragmentação de pacotes

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

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 declaração sozinho.allow-fragmentation Configure-a sempre em conjunto com a declaração.mtu-signaling

Configuração do salto final para LSPs

Por padrão, os LSPs sinalizados por RSVP usam o penúltimo salto (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 seu próximo salto (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 de salto para o LSP para o Roteador PE2, ele primeiro coloca 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 não rotulado para o Roteador CE2.

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

Você também pode configurar o popping de salto final (UHP) (como mostrado ) para LSPs sinalizados por RSVP.Figura 4 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 ) 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 PE2 de saída.Figura 4 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: Salto final para um LSPSalto final 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 de ponto a multiponto

  • CCC

  • traceroute Comando

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

Para LSPs sinalizados por RSVP ponto a ponto, o comportamento de UHP é sinalizado pela entrada do LSP. Com base na configuração do roteador de entrada, o RSVP pode sinalizar o UHP LSP 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 à bit S do rótulo MPLS, que indica se a parte inferior 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 para essa rota aponta para a tabela de roteamento mpls.0, desencadeando uma busca encadeada do rótulo MPLS para descobrir os rótulos MPLS restantes na pilha.

  • Rota S=1 — indica que não há mais rótulos. O próximo salto aponta para a tabela de roteamento inet.0 se a plataforma oferece suporte a uma busca acorrentada e multi-família. Como alternativa, a rota do rótulo 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 duas etiquetas. 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. Há 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 neste cenário. Por padrão, as VPNs de Camada 3 anunciam o rótulo de salto 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 declaração para a instância de roteamento VPN de Camada 3, o rótulo LSI interno aponta para a tabela de roteamento VRF.vrf-table-label 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 declaração é compatível apenas com plataformas de roteamento universal 5G da Série MX.vrf-table-label

  • 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 encadeada e uma busca multifamiliar.

    Nota:

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

  • 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 de IP é concluída na interface VT para determinar para 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 em pontos de rota de rótulo (S=1) para a tabela de roteamento inet.0.

  • IPv6 sobre MPLS — Para o tunelamento IPv6 em 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 saltos de encaminhamento para rotas IPv6 que são aprendidos com roteadores PE remotos normalmente empurram duas etiquetas. O rótulo interno é 2 (poderia 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 IPv6 explicit-null (rótulo 2). A busca baseada no rótulo interno da tabela de roteamento mpls.0 redireciona para a tabela de roteamento mpls.0. Nos roteadores da Série MX 3D, a etiqueta interna (rótulo 2) é despojada e um lookup IPv6 é feito usando a tabela de roteamento inet6.0.

  • Habilitando os LSPs PHP e UHP — você pode configurar 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 saltos LSP usando uma expressão regular com a declaração.install-nexthop 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 declaração:ultimate-hop-popping

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

    Nota:

    Quando você permite o salto final, o RSVP tenta renunciar aos LSPs existentes como LSPs de salto final de uma forma make-before-break. Se um roteador de saída não suportar estalos de salto final, o LSP existente é demolido (o RSVP envia uma mensagem PathTear ao longo do caminho de um LSP, removendo o estado do caminho e o estado de reserva dependente e liberando os recursos de rede associados).

    Se você desativar o salto final, o RSVP renuncia aos LSPs existentes como o penúltimo salto que estoura LSPs de forma make-before-break.

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

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

Configuração do 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 penúltimo roteador de salto remove o rótulo e envia o pacote para o roteador de saída. Quando o estouro de salto final é habilitado, o rótulo 0 (versão IP 4 [IPv4] Explicit Null label) é anunciado. O salto final garante que todos os pacotes que atravessam 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 declaração:explicit-null

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

  • [edit protocols mpls]

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

Habilitando o salto final surgindo em LSPs de ponto a multiponto

Por padrão, tanto para LSPs ponto a ponto quanto de ponto a multiponto, o estouro do penúltimo salto é usado para tráfego MPLS. As etiquetas MPLS são removidas dos 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 o salto final, o roteador de saída é responsável por remover o rótulo MPLS e processar o pacote IP simples.

Pode ser benéfico permitir o salto final aparecer em LSPs de ponto a multiponto, especialmente quando o tráfego de trânsito está atravessando o mesmo dispositivo de saída. Se você habilitar o 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 de ponto a multiponto configurando a declaração.tunnel-services Quando você permite o estouro de salto final, o Junos OS seleciona uma das interfaces de loopback virtual (VT) disponíveis para loop de volta os pacotes para o PFE para encaminhamento ip. Por padrão, o processo de seleção da interface VT é executado 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 salto final não pode ser habilitado e o salto de penúltimo salto está habilitado.

Para que os LSPs de ponta a multiponto funcionem corretamente, o roteador de saída deve ter um PIC que forneça serviços de túnel, como os serviços de túnel PIC ou os serviços adaptativos PIC. 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ços IP.

Você pode configurar explicitamente quais interfaces VT lidam com o tráfego RSVP, incluindo a opção para a declaração.devicestunnel-services A opção permite especificar quais interfaces VT devem ser usadas pelo RSVP.devices 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 declaração:tunnel-services

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 declaração com a opção :interfaceall

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

Rastreamento do tráfego de protocolo RSVP

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

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 as seguintes bandeiras específicas do RSVP na declaração do RSVP :traceoptions

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

  • 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 à reinicialização graciosa do RSVP)

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

  • packets— Todos os pacotes RSVP

  • path— Todas as mensagens de caminho

  • pathtear— Mensagens do PathTear

  • resv— Mensagens resv

  • resvtear— Mensagens resvTear

  • route— Informações de roteamento

  • state— Transições de estado de sessão, inclusive quando os LSPs sinalizados por RSVP sobem e descem.

Nota:

Use a bandeira de rastreamento e o modificador de bandeira com cuidado, pois estes podem fazer com que a CPU fique muito ocupada.alldetail

Para visualizar o arquivo de log gerado quando você habilitar traceoptions RSVP, emita o comando, onde está o arquivo que você especificou usando a declaração.show log file-namefile-nametraceoptions

Para obter informações gerais sobre o rastreamento e opções de rastreamento global, consulte a Biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/config-guide-routing/index.html

Exemplos: Rastreamento do tráfego de protocolo RSVP

Trace detalhadamente as mensagens de caminho do RSVP:

Trace todas as mensagens de RSVP:

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

Trace as transições de estado do RSVP:

Saída de arquivo de log RSVP

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

Reiniciamento gracioso do RSVP

A reinicialização graciosa do RSVP permite que um roteador que está sendo reiniciado informe seus vizinhos adjacentes sobre sua condição. O roteador de reinicialização solicita um período de carência do vizinho ou peer, que pode então colaborar com o roteador de reinicialização. O roteador de reinicialização ainda pode encaminhar o 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 tanto para LSPs ponto a ponto quanto para LSPs de ponto a multiponto.

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

RSVP Gracioso Reinicie Omissão

Tempo de reinicialização (em milissegundos)

O valor padrão é de 60.000 milissegundos (1 minuto). O tempo de reinicialização é anunciado na mensagem de 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 purgando estados.

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

Tempo de recuperação (em milissegundos)

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

Quando uma reinicialização graciosa está em andamento, o tempo restante para concluir uma recuperação é anunciado. 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ó 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 concluída 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 no nível global para todos os protocolos.

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

  • Para o roteador de reiniciamento, o RSVP reinicializa graciosamente as tentativas de manter as rotas instaladas pelo RSVP e as etiquetas alocadas, 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 helper de reinicialização gracioso RSVP habilitado, permitindo assim que eles ajudem um roteador que tenta 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. Este objeto é essencialmente o rótulo antigo que o nó de reinicialização anunciado antes do nó cair.

O seguinte lista os comportamentos de reinicialização graciosos do RSVP, que variam dependendo da configuração e em quais recursos estão habilitados:

  • Se você desativar o modo helper, o Junos OS não tenta ajudar um vizinho a reiniciar o RSVP. Qualquer informação que chegar com um objeto Restart Cap de um vizinho é ignorada.

  • Quando você permite a reinicialização graciosa sob a configuração da instância de roteamento, o roteador pode reiniciar graciosamente 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 valor é 0).

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

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

  • Se a reinicialização graciosa 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 reinício graciosos do RSVP são baseados em temporização. Um 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.show rsvp version

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 inequivocamente de uma reinicialização de nó):

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

  • Após uma 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 este vizinho são eliminados, independentemente do valor do tempo de reinicialização.

  • Após uma reinicialização, 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 o vizinho com procedimentos de reinicialização ou recuperação, ele envia um objeto Recover Label para este vizinho.

Configuração do reinício gracioso do RSVP

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

  • A reinicialização graciosa e o modo de helper estão ambos habilitados (o padrão).

  • A reinicialização graciosa está habilitada, mas o modo de helper é desativado. Um roteador configurado dessa forma pode reiniciar graciosamente, mas não pode ajudar um vizinho com seus procedimentos de reinicialização e recuperação.

  • A reinicialização graciosa é desativada, mas o modo de helper está habilitado. Um roteador configurado dessa forma não pode reiniciar graciosamente, mas pode ajudar um vizinho reiniciado.

  • 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 de helper). O roteador se comporta como um roteador que não oferece suporte a reinicialização graciosa do RSVP.

Nota:

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

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

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

Para permitir a reinicialização graciosa do 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 a reinicialização graciosa, consulte a Biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.

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

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 da reinicialização graciosa para RSVP

Por padrão, a reinicialização graciosa do RSVP e o modo de helper RSVP são habilitados quando você habilita a reinicialização graciosa. No entanto, você pode desabilitar um ou ambos os recursos.

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

Desativação do modo de helper RSVP

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

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 declaração no nível de hierarquia.maximum-helper-recovery-time[edit protocols rsvp graceful-restart] 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 foi desativado e quando ele declara o vizinho desativado, inclua a declaração no nível de hierarquia.maximum-helper-restart-time[edit protocols rsvp graceful-restart] 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 do RSVP

Um túnel de caminho comutada por rótulos (RSVP) do Protocolo de Reserva de Recursos (RSVP) permite que você envie LSPs RSVP para outros LSPs RSVP. Isso permite que um administrador de rede forneça engenharia de tráfego de uma ponta da rede para a outra. Um aplicativo útil para esse recurso é conectar roteadores de borda do cliente (CE) com roteadores de borda (PE) do provedor 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 de rótulos multiprotocol generalizada (GMPLS). (Para obter mais informações sobre o GMPLS, consulte o Guia de usuário do Junos GMPLS.

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 (FA-LSP) de adjacência de encaminhamento tiver sido estabelecido, outros LSPs podem ser enviados pelo FA-LSP usando O CSPF (Constranged Shortest Path First, CSPF), Link Management Protocol (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 o encaminhamento de adjacências entre os pares de túneis LSP do RSVP e mantém e aloca recursos para links de engenharia de tráfego.

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

    Nota:

    Começando com o Junos OS Release 15.1, o suporte a várias instâncias é estendido ao MPLS RSVP-TE. Esse suporte está disponível apenas para o tipo de instância de roteador virtual. Um roteador pode criar e participar em várias partições independentes de topologia 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 flexibilidade para escolher manualmente as entidades de plano de controle que precisam estar cientes de instâncias, por exemplo, um roteador pode participar em várias instâncias de TE enquanto ainda executa uma única instância BGP.

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

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

    • Garantindo a prontidão do plano de dados LSP durante a renúncia do LSP antes que o tráfego passe pelo 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 grandes redes, 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 a ping LSP e as envie pelo plano de dados LSP. Ao receber essas mensagens, a egressa LER 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 escalando o número total de LSPs com LSPs sinalizados por RSVP-TE. Pode haver até 64K LSPs configurados por saída. Antes, esse limite era o número agregado de LSPs que poderia ser configurado na entrada LER.

    • Evitando a derrubada brusca de LSPs pelo roteador de entrada devido à demora 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 self-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 enlaces não está disponível para FA-LSPs ou no ponto de saída da adjacência de encaminhamento.

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

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

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

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

No Roteador 0, configure o LSP RSVP de ponta a ponta que viaja para 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 um relacionamento de peer LMP com o Roteador 4. Faça referência à FA-LSP no link de engenharia de tráfego e adicione a interface peer tanto no OSPF quanto no RSVP.

Quando o caminho de retorno LSP 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 os roteadores 0 e 1.

Roteador 1

No Roteador 2, configure OSPF, MPLS e RSVP em todas as interfaces que transportam os FA-LSPs por toda a rede central.

Roteador 2

No Roteador 3, configure OSPF, MPLS e RSVP em todas as interfaces que transportam os FA-LSPs por toda a rede central.

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 à FA-LSP no link de engenharia de tráfego e adicione a interface peer tanto no OSPF quanto no RSVP.

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

Roteador 1

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

Configuração de interfaces peer no OSPF e RSVP

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

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

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

Em seguida, defina seu FA-LSP incluindo a declaração no nível de hierarquia.label-switched-path[edit protocols mpls] Inclua a ID do roteador do peer na declaração no nível de hierarquia.to[edit protocols mpls label-switched-path] 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 sobre o caminho FA-LSP

Ao configurar caminhos LSP explícitos para um FA-LSP, você deve usar o endereço remoto do link 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 declaração no nível de hierarquia, você deve usar caminhos rigorosos.no-cspf[edit protocols mpls label-switched-path lsp-name]

Nota:

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

Opção: Derrubando LSPs RSVP graciosamente

Você pode derrubar um RSVP LSP em um processo de duas etapas que retira graciosamente a sessão de RSVP usada pelo LSP. Para todos os vizinhos que suportam o teardown gracioso, um pedido de demolição é enviado 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 campo do pacote RSVP.ADMIN_STATUS Quando os vizinhos recebem a solicitação, eles se preparam para a sessão de RSVP a ser retirada. Uma segunda mensagem é enviada pela plataforma de roteamento para concluir o rompimento da sessão de RSVP. Se um vizinho não suportar o 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 comando.clear rsvp session gracefully Opcionalmente, você pode especificar o endereço de origem e destino da sessão de RSVP, o identificador LSP do remetente RSVP e o identificador de túnel da sessão de RSVP. Para usar essas classificatórias, inclua as opções, e quando você emitir o comando.connection-sourceconnection-destinationlsp-idtunnel-idclear rsvp session gracefully

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 declaração no nível de hierarquia.graceful-deletion-timeout[edit protocols rsvp] 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 modo operacional.show rsvp version

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
19.4R1
16.1
No entanto, a partir do Junos OS Release 16.1, quando o RSVP olá mensagens time-out, as sessões de RSVP são derrubadas.