Configuração do RSVP

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 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 all a interface-name variável.

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

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

• [edit protocols rsvp interface interface-name ]

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

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 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 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 [edit protocols mpls label-switched-path name] hierarquia.

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

• Configuração da redução de atualização do RSVP
• Configurando o intervalo de olá do RSVP
• Configuração da autenticação do RSVP
• Configurando a assinatura de largura de banda para tipos de classe
• Configurando o limite de atualização do RSVP em uma interface
• Configuração do RSVP para interfaces não numeradas

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

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

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 policy-statement seguinte forma:

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 policy-statement 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. Veja também a configuração do 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 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]

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

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

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

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

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 refresh-time valor padrão da declaração de 30, multiplicado por um valor fixo de 1,5. 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, ( –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 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 refresh-time declaração:

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

• [edit protocols rsvp]

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

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

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

• [edit protocols rsvp]

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

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

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

Para voltar ao padrão (ou seja, antecipar 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 essa declaração nos seguintes níveis de hierarquia:

• [edit protocols rsvp]

• [edit logical-systems logical-system-name protocols 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 path-mtu declaração:

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

• [edit protocols mpls]

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

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

• Habilitando a sinalização de MTU no RSVP
• Habilitando a fragmentação de pacotes

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.

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

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

• [edit protocols mpls]

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

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 tunnel-services declaração. 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 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.

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

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

• [edit protocols rsvp]

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

Você pode especificar as seguintes bandeiras específicas do RSVP na declaração do 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 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.

Para visualizar o arquivo de log gerado quando você habilitar traceoptions RSVP, emita o show log file-name comando, onde file-name está o arquivo que você especificou 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 do Junos OS para dispositivos de roteamento.

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:

• Padrão de reinicialização graciosa do RSVP

• RSVP Gracioso Reinicie Omissão

• Operação de reinício gracioso do RSVP

• Processamento do objeto de tampa de reinicialização

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 [protocols rsvp] 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.

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

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.

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.

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
• Desativação da reinicialização graciosa para RSVP
• Desativação do modo de helper RSVP
• Configurando o tempo máximo de recuperação do helper
• Configurando o tempo máximo de reinicialização do helper

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.

Figura 5: Diagrama da topologia de túneis LSP do 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 RSVP LSP e2e_lsp_r5r0 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 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