Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configuração LDP

Configuração LDP mínima

Para habilitar o LDP com configuração mínima:

  1. Ative todas as interfaces relevantes no âmbito da família MPLS. No caso do LDP direcionado, a interface de loopback precisa ser habilitada com a família MPLS.

  2. (Opcional) Configure as interfaces relevantes no nível [edit protocol mpls] da hierarquia.

  3. Ative o LDP em uma interface única, inclua a ldp instrução e especifique a interface usando a interface instrução.

Essa é a configuração de LDP mínima. Todas as outras declarações de configuração de LDP são opcionais.

Para habilitar o LDP em todas as interfaces, all especifique interface-name para .

Para uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração.

Ativação e desativação de LDP

O LDP é consciente de instâncias de roteamento. Para habilitar o LDP em uma interface específica, inclua as seguintes declarações:

Para uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração.

Para habilitar o LDP em todas as interfaces, all especifique interface-name para .

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

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

Configurando o temporizador de LDP para mensagens de olá

As mensagens de olá do LDP permitem que nós de LDP descubram um ao outro e detectem a falha de um vizinho ou do link para o vizinho. Mensagens de olá são enviadas periodicamente em todas as interfaces onde o LDP está ativado.

Existem dois tipos de mensagens de olá LDP:

  • Mensagens de olá do enlace — enviadas pela interface LDP como pacotes de UDP endereçados à porta de descoberta de LDP. O recebimento de uma mensagem de olá de enlace de LDP em uma interface identifica uma adjabilidade com o roteador de peer LDP.

  • Mensagens de olá direcionadas — Enviadas como pacotes de UDP endereçados à porta de descoberta de LDP em um endereço específico. Mensagens de olá direcionadas são usadas para dar suporte a sessões de LDP entre roteadores que não estão conectados diretamente. Um roteador alvo determina se deve responder ou ignorar uma mensagem de olá direcionada. Um roteador alvo que escolhe responder faz isso enviando periodicamente mensagens de olá direcionadas de volta ao roteador de iniciação.

Por padrão, o LDP envia mensagens de olá a cada 5 segundos para mensagens de olá do enlace e a cada 15 segundos para mensagens de olá direcionadas. Você pode configurar o temporizador LDP para alterar a frequência com que ambos os tipos de mensagens de olá são enviados. No entanto, você não pode configurar uma hora para o temporizador LDP maior do que o tempo de espera do LDP. Para obter mais informações, consulte Configurar o atraso antes que os vizinhos LDP sejam considerados para baixo.

Configurando o temporizador de LDP para mensagens de olá do enlace

Para modificar a frequência com que O LDP envia mensagens de olá do enlace, especifique um novo intervalo de mensagem de olá do enlace para o temporizador LDP usando a hello-interval instrução:

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

Configurando o temporizador de LDP para mensagens de olá direcionadas

Para modificar a frequência com que o LDP envia mensagens de olá direcionadas, especifique um novo intervalo de mensagem olá alvo para o temporizador LDP configurando a instrução como uma hello-interval opção para a targeted-hello instrução:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração para essas declarações.

Configurar o atraso antes que os vizinhos LDP sejam considerados inoperantes

O tempo de espera determina por quanto tempo um nó LDP deve esperar por uma mensagem de olá antes de declarar que um vizinho está inoperante. Esse valor é enviado como parte de uma mensagem de olá para que cada nó LDP diga aos seus vizinhos quanto tempo esperar. Os valores enviados por cada vizinho não são igualados.

Normalmente, o tempo de espera deve ser pelo menos três vezes maior do que o intervalo hello. O padrão é de 15 segundos para mensagens de olá do enlace e 45 segundos para mensagens de olá direcionadas. Entretanto, é possível configurar um tempo de espera de LDP próximo do valor do intervalo hello.

Nota:

Ao configurar um tempo de espera de LDP perto do intervalo de olá (menos de três vezes o intervalo de olá), falhas no vizinho LDP podem ser detectadas mais rapidamente. No entanto, isso também aumenta a possibilidade de que o roteador possa declarar um vizinho LDP para baixo que ainda esteja funcionando normalmente. Para obter mais informações, consulte Configurar o temporizador de LDP para mensagens de olá.

O tempo de espera do LDP também é negociado automaticamente entre os peers de LDP. Quando dois peers de LDP anunciam tempos de espera LDP diferentes entre si, o valor menor é usado. Se um roteador de peer LDP anunciar um tempo de espera mais curto do que o valor configurado, o tempo de espera anunciado pelo roteador de peer é usado. Essa negociação também pode afetar o intervalo de restrição de LDP.

Se o tempo de espera do LDP local não for encurtado durante a negociação de peerS LDP, o intervalo de manter-se configurado pelo usuário não será inalterado. No entanto, se o tempo de espera local for reduzido durante a negociação por pares, o intervalo manter-se-ão recalculado. Se o tempo de espera do LDP tiver sido reduzido durante a negociação por pares, o intervalo de intervalo manter-se-ão reduzido a um terço do novo valor de tempo de espera. Por exemplo, se o novo valor de tempo de espera for de 45 segundos, o intervalo de manter a responsabilidade é de 15 segundos.

Esse cálculo automatizado de intervalos de manutenção pode configurar intervalos de manutenção diferentes em cada roteador de peer. Isso permite que os roteadores sejam flexíveis na frequência com que enviam mensagens continuadas, porque a negociação de peers LDP garante que eles sejam enviados com mais frequência do que o tempo de espera do LDP.

Quando você reconfigura o intervalo de tempo de espera, as alterações só fazem efeito após o restabeleamento da sessão. O tempo de espera é negociado quando a sessão de peering LDP é iniciada e não pode ser renegociada enquanto a sessão estiver atualizada (exigido por RFC 5036, Especificação LDP). Para obrigar manualmente a sessão de LDP a reinicializar, emiste o clear ldp session comando.

Configurando o tempo de espera do LDP para mensagens de olá do enlace

Para modificar por quanto tempo um nó LDP deve esperar por uma mensagem de olá do enlace antes de declarar o vizinho para baixo, especifique um novo tempo em segundos usando a hold-time declaração:

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

Configurando o tempo de espera do LDP para mensagens de olá direcionadas

Para modificar por quanto tempo um nó LDP deve esperar por uma mensagem de olá direcionada antes de declarar o vizinho para baixo, especifique um novo tempo em segundos usando a declaração como uma opção para a hold-timetargeted-hello declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode incluir essas declarações, consulte as seções de resumo da declaração para essas declarações.

Permitindo mensagens de olá direcionadas rigorosas para LDP

Use mensagens de olá direcionadas rigorosas para evitar que sessões de LDP tenham sido estabelecidas com vizinhos remotos que não tenham sido configurados especificamente. Se você configurar a declaração, um peer LDP não responderá a mensagens de olá direcionadas provenientes de uma fonte que não é um de strict-targeted-hellos seus vizinhos remotos configurados. Os vizinhos remotos configurados podem incluir:

  • Endpoints de túneis RSVP para os quais o tunelamento de LDP está configurado

  • Vizinhos de circuito de Camada 2

Se um vizinho não configurado enviar uma mensagem de olá, o peer LDP ignora a mensagem e registra um erro (com o sinal de error rastreamento) indicando a origem. Por exemplo, se o peer LDP recebeu um olá direcionado do endereço de Internet 10.0.0.1 e nenhum vizinho com esse endereço estiver configurado especificamente, a mensagem a seguir será impressa no arquivo de log LDP:

Para habilitar mensagens de olá direcionadas rigorosas, inclua a strict-targeted-hellos declaração:

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

Configurando o intervalo para mensagens de LDP

O intervalo manteralive determina a frequência com que uma mensagem é enviada durante a sessão para garantir que o intervalo de tempo não seja excedido. Se nenhum outro tráfego LDP for enviado durante a sessão durante esse período, uma mensagem manter-se-ão enviadas. O padrão é de 10 segundos. O valor mínimo é de 1 segundo.

O valor configurado para o intervalo de manteraive pode ser alterado durante a negociação de sessão LDP se o valor configurado para o tempo de espera de LDP no roteador de peer for inferior ao valor configurado localmente. Para obter mais informações, consulte Configurar o atraso antes que os vizinhos LDP sejam considerados para baixo.

Para modificar o intervalo de manter-se, inclua a keepalive-interval declaração:

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

Configurando o tempo livre de restrição de LDP

Depois que uma sessão de LDP for estabelecida, as mensagens devem ser trocadas periodicamente para garantir que a sessão ainda esteja funcionando. O timeout manteralive define o tempo que o nó LDP vizinho espera antes de determinar se a sessão falhou. Esse valor costuma ser definido para pelo menos três vezes o intervalo de manter. O padrão é de 30 segundos.

Para modificar o intervalo de manter-se, inclua a keepalive-timeout declaração:

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

O valor configurado para a instrução é exibido como o tempo de keepalive-timeout espera ao emitir o show ldp session detail comando.

Configurando a combinação mais longa de LDP

Para permitir que o LDP aprenda as rotas agregadas ou resumidas em áreas OSPF ou níveis de ISIS entre domínios, o Junos OS permite configurar o match mais longo para LDP com base no RFC5283.

Antes de configurar o match mais longo para LDP, você deve fazer o seguinte:

  1. Configure as interfaces de dispositivo.

  2. Configure o protocolo MPLS de segurança.

  3. Configure o protocolo OSPF de segurança.

Para configurar a combinação mais longa de LDP, você deve fazer o seguinte:

  1. Configure a combinação mais longa para o protocolo LDP.
  2. Configure o protocolo LDP na interface.

    Por exemplo, para configurar as interfaces:

Exemplo: Configurando a combinação mais longa de LDP

Este exemplo mostra como configurar o match mais longo para LDP com base em RFC5283. Isso permite que o LDP aprenda as rotas agregadas ou resumidas em OSPF áreas ou níveis de ISIS em entre domínios.. A política de combinação mais longa fornece por granularidade de prefixo.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Seis roteadores da série MX com OSPF protocolo e LDP ativados nas interfaces conectadas.

  • Junos OS Release 16.1 ou posterior em execução em todos os dispositivos.

Antes de começar:

  • Configure as interfaces de dispositivo.

  • Configure OSPF.

Visão geral

O LDP costuma ser usado para estabelecer MPLS LSPs (Label-Switched Paths, Caminhos comutado de rótulos) em todo um domínio de rede completo, usando uma rede IGP, como OSPF ou IS-IS. Nessa rede, todos os links do domínio IGP adjacências, bem como adjacências LDP. O LDP estabelece os LSPs no caminho mais curto até um destino, conforme determinado pelo encaminhamento ip. No Junos OS, a implementação do LDP faz uma pesquisa precisa sobre o endereço IP do FEC no RIB ou IGP rotas para mapeamento de rótulos. Esse mapeamento exato requer MPLS endereços IP de endpoint LDP completos a serem configurados em todos os LERs. Isso descumpri a finalidade do design hierárquico de IP ou do roteamento padrão em dispositivos de acesso. A configuração ajuda a superar isso eliminando o comportamento exato de correspondência e a configuração de LSP com base na rota mais longa de correspondência longest-match por prefixo.

Topologia

Na topologia, mostra Figura 1 que a combinação mais longa de LDP está configurada no dispositivo R0 .

Figura 1: Exemplo Mais longa combinação de LDPExemplo Mais longa combinação de LDP

Configuração

Configuração rápida CLI

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

R0

R1

R2

R3

R4

R5

Configurando o dispositivo R0

Procedimento passo a passo

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

Para configurar o dispositivo R0:

  1. Configure as interfaces.

  2. Atribua os endereços de loopback ao dispositivo.

  3. Configure a ID do roteador.

  4. Configure o MPLS de segurança na interface.

  5. Configure o OSPF de segurança na interface.

  6. Configure a combinação mais longa para o protocolo LDP.

  7. Configure o protocolo LDP na interface.

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

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

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação das rotas

Propósito

Verificar se as rotas esperadas são aprendidas.

Ação

No dispositivo R0, a partir do modo operacional, execute o show route comando para exibir as rotas na tabela de roteamento.

Significado

A saída mostra todas as rotas da tabela de roteamento do dispositivo R0.

Verificar informações de visão geral do LDP

Propósito

Exibir informações de visão geral do LDP.

Ação

No dispositivo R0, a partir do modo operacional, execute o show ldp overview comando para exibir a visão geral do LDP.

Significado

A saída exibe as informações de visão geral do LDP do dispositivo R0

Verificar as entradas de LDP na tabela de topologia interna

Propósito

Exibir as entradas de rota na tabela de topologia interna do Protocolo de Distribuição de Rótulos (LDP).

Ação

No dispositivo R0, a partir do modo operacional, execute o show ldp route comando para exibir a tabela de topologia interna do LDP.

Significado

A saída exibe as entradas de rota na tabela interna de topologia do dispositivo R0 (Label Distribution Protocol) (LDP).

Verificar somente informações fec da rota LDP

Propósito

Exibir apenas as informações FEC da rota LDP.

Ação

No dispositivo R0, a partir do modo operacional, execute o show ldp route fec-only comando para exibir as rotas na tabela de roteamento.

Significado

A saída exibe apenas as rotas FEC do protocolo LDP disponíveis para o dispositivo R0.

Verificar rotas de FEC e Sombra de LDP

Propósito

Exibe o FEC e as rotas de sombra na tabela de roteamento.

Ação

No dispositivo R0, a partir do modo operacional, execute o comando para exibir as rotas FEC e show ldp route fec-and-route de sombra na tabela de roteamento.

Significado

A saída exibe o FEC e as rotas de sombra do dispositivo R0

Configurando preferências de roteamento LDP

Quando vários protocolos calculam rotas até o mesmo destino, as preferências de roteamento são usadas para selecionar qual rota está instalada na tabela de encaminhamento. A rota com o menor valor de preferência é selecionada. O valor de preferência pode ser um número na faixa de 0 a 255. Por padrão, as rotas LDP têm um valor de preferência de 9.

Para modificar as preferências da rota, inclua a preference declaração:

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

LDP Graceful Reboot

O LDP graceful reboot habilita um roteador cujo plano de controle LDP está em fase de reinicialização para continuar a encaminhamento do tráfego enquanto recupera seu estado dos roteadores vizinhos. Ele também habilita um roteador no qual o modo de ajuda está habilitado para ajudar um roteador vizinho que está tentando reinicializar LDP.

Durante a inicialização da sessão, um roteador anuncia sua capacidade de realizar reinicialização graciosa de LDP ou tirar proveito de um vizinho que realiza reinicialização graciosa de LDP enviando o TLV de reinicialização gracioso. Este TLV contém dois campos relevantes para o reinicialização graciosa do LDP: o tempo de reconexão e o tempo de recuperação. Os valores dos tempos de reconexão e recuperação indicam os recursos de reinicialização graciosos suportados pelo roteador.

Quando um roteador descobre que um roteador vizinho está reinicializando, ele espera até o fim do tempo de recuperação antes de tentar reconectar. O tempo de recuperação é o tempo que um roteador espera que o LDP reinicie de forma graciosa. O período de tempo de recuperação começa quando uma mensagem de inicialização é enviada ou recebida. Esse período de tempo também costuma ser o tempo que um roteador vizinho mantém suas informações sobre o roteador de reinicialização, permitindo que ele continue a encaminhá-lo.

Você pode configurar o reinicialização gracioso de LDP na instância principal do protocolo LDP e em uma instância de roteamento específica. Você pode desativar o reinicialização graciosa em nível global para todos os protocolos, no nível de protocolo apenas para LDP e em uma instância de roteamento específica. O reinicialização graciosa de LDP é inválido por padrão, porque, em nível global, a reinicialização graciosa é desabilitada por padrão. No entanto, o modo helper (a capacidade de ajudar um roteador vizinho a tentar uma reinicialização graciosa) é ativado por padrão.

Alguns dos comportamentos associados ao LDP são os seguintes:

  • Rótulos de saída não são mantidos em reinicializações. Novos rótulos de saída são alocados.

  • Quando um roteador está reinicializando, não são enviadas mensagens de mapa de rótulo para os vizinhos que suportam reinicialização graciosa até que o roteador de reinicialização tenha se estabilizado (mensagens de mapa de rótulo são enviadas imediatamente para os vizinhos que não suportam reinicialização graciosa). Entretanto, todas as outras mensagens (continuamente, mensagem de endereço, notificação e versão) são enviadas como de costume. A distribuição dessas outras mensagens impede o roteador de distribuir informações incompletas.

  • O modo helper e o reinicialização são independentes. Você pode desativar o reinicialização graciosa na configuração, mas ainda assim permitir que o roteador colabore com um vizinho que tenta reinicializar de maneira simples.

Configuração de LDP Graceful Reboot

Quando você altera a configuração de reinicialização graciosa nos níveis ou na hierarquia, qualquer sessão LDP em execução é reinicializada automaticamente para aplicar [edit routing-options graceful-restart][edit protocols ldp graceful-restart] a configuração de reinicialização graciosa. Esse comportamento espelha o comportamento da BGP quando você altera sua configuração de reinicialização simples.

Por padrão, o modo de ajuda para reinicialização graciosa está ativado, mas a reinicialização graciosa está desabilitada. Assim, o comportamento padrão de um roteador é ajudar os roteadores próximos a tentar uma reinicialização graciosa, mas não para tentar um reinicializar graciosamente sozinho.

Para configurar o LDP graceful reboot, consulte as seguintes seções:

Ativação do Graceful Reboot

Para habilitar o reinicialização graciosa de LDP, você também precisa habilitar a reinicialização graciosa no roteador. Para habilitar o reinicialização graciosa, inclua a graceful-restart declaração:

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

  • [edit routing-options]

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

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems logical-system-name routing-options ] nível de hierarquia.

A graceful-restart declaração permite reinicialização graciosa para todos os protocolos que suportam esse recurso no roteador. Para obter mais informações sobre o reinicialização graciosa, consulte a Biblioteca de Protocolos de Roteamento do Junos OS para dispositivos de roteamento.

Por padrão, o reinicialização graciosa de LDP é ativado quando você habilita a reinicialização graciosa no nível do protocolo LDP e em todas as instâncias de roteamento. No entanto, você pode desativar o modo LDP graceful reboot e o modo de ajuda de reinicialização graciosa LDP.

Desativação do modo LDP Graceful Reboot ou Helper

Para desativar a reinicialização e a recuperação de LDP, inclua a disable declaração:

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

Você pode desativar o modo de ajuda apenas no nível de protocolos LDP. Você não pode desativar o modo de ajuda para uma instância de roteamento específica. Para desativar o modo helper LDP, inclua a helper-disable declaração:

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

As seguintes configurações de reinicialização simples de LDP são possíveis:

  • O modo LDP graceful reboot e o helper estão ativados.

  • O modo LDP graceful reboot está desabilitado, mas o modo de ajuda está ativado. Um roteador configurado dessa forma não pode ser reinicializado de maneira graciosa, mas pode ajudar um vizinho reinício.

  • O modo LDP e o modo helper estão desabilitados. O roteador não usa reinicialização graciosa de LDP ou o tipo de reinicialização, comprimento e valor (TLV) enviados na mensagem de inicialização. O roteador se comporta como um roteador que não consegue suportar a reinicialização graciosa de LDP.

Um erro de configuração é emitido se você tentar habilitar o modo de reinicialização e desativar o helper.

Configurando o tempo de reconexão

Depois que a conexão LDP entre os vizinhos falha, os vizinhos esperam um certo tempo para que o roteador de reinicialização graciosamente recomeça a enviar mensagens LDP. Após o período de espera, a sessão LDP pode ser restabelecida. Você pode configurar o período de espera em segundos. Esse valor é incluído na sessão tolerante a falhas TLV enviada em mensagens de inicialização LDP quando o LDP é reinicializado.

Imagine que o roteador A e o roteador B sejam vizinhos de LDP. O roteador A é o roteador de reinicialização. O tempo de reconexão é o tempo em que o Roteador A informa ao Roteador B para esperar que o Roteador B detecte que o Roteador A foi reinicializado.

Para configurar o tempo de reconexão, inclua a reconnect-time declaração:

Você pode definir o tempo de reconexão como um valor na faixa de 30 a 300 segundos. Por padrão, são 60 segundos.

Para uma lista de níveis de hierarquia nos quais você pode configurar essas declarações, consulte as seções de resumo da declaração para essas declarações.

Configurando o tempo de recuperação e o tempo máximo de recuperação

O tempo de recuperação é a quantidade de tempo que um roteador espera para que o LDP reinicie graciosamente. O período de tempo de recuperação começa quando uma mensagem de inicialização é enviada ou recebida. Esse período também costuma ser a quantidade de tempo que um roteador vizinho mantém suas informações sobre o roteador de reinicialização, permitindo que ele continue a encaminhá-lo.

Para evitar que um roteador vizinho seja afetado se ele receber um valor falso pelo tempo de recuperação do roteador de reinicialização, você pode configurar o tempo de recuperação máximo no roteador vizinho. Um roteador vizinho mantém seu estado pelo menor tempo das duas vezes. Por exemplo, o roteador A está realizando uma reinicialização lDP graciosa. Ele enviou um tempo de recuperação de 900 segundos para o roteador vizinho B. No entanto, o roteador B tem seu tempo de recuperação máximo configurado em 400 segundos. O roteador B só esperará 400 segundos antes de eliminar as informações de LDP do roteador A.

Para configurar o tempo de recuperação, inclua recovery-time a declaração e a maximum-neighbor-recovery-time declaração:

Para uma lista de níveis de hierarquia nos quais você pode configurar essas declarações, consulte as seções de resumo da declaração para essas declarações.

Filtragem de encadernações de rótulos LDP de entrada

Você pode filtrar as vinculações de rótulos LDP recebidas, aplicando políticas para aceitar ou negar vinculações anunciadas por roteadores próximos. Para configurar a filtragem de rótulos recebidos, inclua a import declaração:

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

A política nomeada (configurada em nível de hierarquia) é aplicada a todas as vinculações de [edit policy-options] rótulos recebidos de todos os vizinhos LDP. Toda a filtragem é feita com declarações. lista os únicos operadores que se aplicam à filtragem de rótulos fromTabela 1 de recebido from LDP.

Tabela 1: das operadoras que se aplicam à filtragem de rótulos recebidos por LDP

from Operador

Descrição

interface

Combina com as ligações recebidas de um vizinho adjacente à interface especificada

neighbor

Combina com as vinculações recebidas da ID do roteador LDP especificada

next-hop

Combina com as vinculações recebidas por um vizinho anunciando o endereço de interface especificado

route-filter

Combina com encadernações com o prefixo especificado

Se uma encadernação for filtrada, ela ainda aparece no banco de dados LDP, mas não é considerada como uma instalação como parte de um caminho comutado por rótulos (LSP).

Em geral, a aplicação de políticas em LDP só pode ser usada para bloquear o estabelecimento de LSPs, não para controlar o roteamento deles. Isso porque o caminho que um LSP segue é determinado pelo roteamento unicast e não por LDP. No entanto, quando houver vários caminhos de custo igual até o destino por meio de diferentes vizinhos, você pode usar a filtragem LDP para excluir alguns dos próximos hops possíveis da consideração. (Caso contrário, o LDP escolhe um dos próximos hops possíveis aleatoriamente.)

As sessões de LDP não são limitadas a interfaces ou endereços de interface. LDP anuncia apenas rótulos por roteador (não por interface); portanto, se existirem vários links paralelos entre dois roteadores, somente uma sessão LDP será estabelecida, e ele não está vinculado a uma única interface. Quando um roteador tiver várias adjacências com o mesmo vizinho, tenha o cuidado de garantir que o filtro faça o que é esperado. (Em geral, next-hop usar e não ser apropriado neste interface caso.)

Se um rótulo tiver sido filtrado (o que significa que ele foi recusado pela política e não for usado para construir um LSP), ele será identificado como filtrado no banco de dados:

Para obter mais informações sobre como configurar políticas para LDP, consulte o Guia de Usuário de Políticas de Roteamento, Filtrosde Firewall e Agentes de tráfego .

Exemplos: Filtragem de encadernações de rótulos LDP de entrada

Aceite apenas prefixos /32 de todos os vizinhos:

Aceite 131.108/16 ou mais tempo a partir da ID do roteador e aceite todos os 10.10.255.2 prefixos de todos os outros vizinhos:

Filtragem de ligações de rótulo de LDP de saída

Você pode configurar políticas de exportação para filtrar rótulos de saída LDP. Você pode filtrar as vinculações de rótulos de saída aplicando políticas de roteamento para bloquear a publicidade de encadernações a roteadores próximos. Para configurar a filtragem de rótulos de saída, inclua a export declaração:

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

A política de exportação nomeada (configurada em nível de hierarquia) é aplicada a todas as vinculações de [edit policy-options] rótulos transmitidas a todos os vizinhos LDP. O único operador que se aplica à filtragem de rótulos de saída LDP é , que combina fromroute-filter encadernações com o prefixo especificado. Os únicos to operadores que se aplicam à filtragem de rótulos de saída são os operadores Tabela 2 em .

Tabela 2: para operadores para filtragem de rótulos de saída LDP

para a Operadora

Descrição

interface

Combina com as ligações enviadas a um vizinho adjacente à interface especificada

neighbor

Combina com as vinculações enviadas para a ID do roteador LDP especificada

next-hop

Combina com as vinculações enviadas a um vizinho anunciando o endereço de interface especificado

Se uma encadernação for filtrada, a vinculação não será anunciada ao roteador vizinho, mas sim instalada como parte de um LSP no roteador local. Você pode aplicar políticas em LDP para bloquear o estabelecimento de LSPs, mas não controlar o roteamento deles. O caminho que um LSP segue é determinado pelo roteamento unicast, não por LDP.

As sessões de LDP não são limitadas a interfaces ou endereços de interface. LDP anuncia apenas rótulos por roteador (não por interface). Se existirem vários links paralelos entre dois roteadores, apenas uma sessão LDP será estabelecida, e ele não está vinculado a uma única interface.

Não use os operadores e os operadores quando next-hop um roteador tiver várias interface adjacências com o mesmo vizinho.

Rótulos filtrados estão marcados no banco de dados:

Para obter mais informações sobre como configurar políticas para LDP, consulte o Guia de Usuário de Políticas de Roteamento, Filtrosde Firewall e Agentes de tráfego .

Exemplos: Filtragem de ligações de rótulo de LDP de saída

Bloquear a transmissão da rota para 10.10.255.6/32 qualquer vizinho:

Envie apenas ou mais tempo para a ID do roteador 131.108/16 e envie todos os 10.10.255.2 prefixos para todos os outros roteadores:

Especificando o endereço de transporte usado por LDP

Os roteadores devem estabelecer primeiro uma sessão de TCP entre si antes de estabelecer uma sessão LDP. A sessão TCP permite que os roteadores troquem os anúncios de rótulos necessários para a sessão LDP. Para estabelecer a sessão TCP, cada roteador deve aprender o endereço de transporte do outro roteador. O endereço de transporte é um endereço IP usado para identificar a sessão TCP pela qual a sessão LDP será realizada.

Para configurar o endereço de transporte LDP, inclua a instrução de endereço de transporte:

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

Se você especificar a opção, o endereço do identificador de roteador será usado como o endereço de transporte (a menos que esteja configurado de outra forma, o identificador do roteador normalmente é o mesmo do endereço router-id de loopback). Se você especificar a opção, o endereço de interface será usado como o endereço de transporte de qualquer sessão LDP para os vizinhos que podem ser interface atingidos por essa interface. Observe que o identificador de roteador é usado como o endereço de transporte por padrão.

Não é possível especificar a opção quando há vários links paralelos com o mesmo vizinho LDP, porque a especificação LDP exige que o mesmo endereço de transporte seja anunciado em todas as interfaces para o mesmo interface vizinho. Se o LDP detectar vários links paralelos com o mesmo vizinho, ele desativa as interfaces desse vizinho uma por uma até que a condição seja liberada, seja desconectando o vizinho em uma interface ou especificando a router-id opção.

Endereço de transporte de controle usado para sessão de LDP alvo

Para estabelecer uma sessão TCP entre dois dispositivos, cada dispositivo deve aprender o endereço de transporte do outro dispositivo. O endereço de transporte é um endereço IP usado para identificar a sessão TCP na qual a sessão LDP opera. Anteriormente, esse endereço de transporte só poderia ser o roteador-ID ou um endereço de interface. Com o recurso de endereço de transporte LDP, você pode configurar explicitamente qualquer endereço IP como o endereço de transporte para os vizinhos LDP direcionados para adjacências de Camada 2, MPLS e VPLS. Com isso, você pode controlar as sessões LDP direcionadas usando a configuração de endereço de transporte.

Benefícios do controle do endereço de transporte usado para sessão de LDP direcionada

Configurar o endereço de transporte para o estabelecimento de sessões LDP direcionadas tem as seguintes vantagens:

  • Flexible interface configurations— Fornece a flexibilidade de configurar vários endereços IP para uma interface de loopback sem interromper a criação de sessão LDP entre os vizinhos LDP alvo.

  • Ease of operation— O endereço de transporte configurado no nível da interface permite que você use mais de um protocolo no IGP backbone para LDP. Isso possibilita operações tranquilas e fáceis.

Visão geral do endereço de transporte LDP alvo

Antes da versão do Junos OS 19.1R1, o LDP forneceu suporte apenas para iD do roteador ou endereço de interface como endereço de transporte em qualquer interface LDP. As adjacências formadas nessa interface usavam um dos endereços IP atribuídos à interface ou à ID do roteador. No caso da adjaceência direcionada, a interface é a interface de loopback. Quando vários endereços de loopback foram configurados no dispositivo, o endereço de transporte não conseguiu ser obtido para a interface, e, como resultado, a sessão LDP não conseguiu ser estabelecida.

A partir do Junos OS Release 19.1R1, além dos endereços IP padrão usados para o endereço de transporte de sessões LDP alvo, você pode configurar qualquer outro endereço IP como o endereço de transporte nas declarações de , e session configuração. session-groupinterface A configuração de endereço de transporte é aplicável apenas para os vizinhos configurados, incluindo circuitos de Camada 2, MPLS e adjacências VPLS. Essa configuração não se aplica a adjacências descobertas (direcionadas ou não).

Preferência de endereço de transporte

Você pode configurar o endereço de transporte para sessões LDP direcionadas na sessão, no grupo de sessões e no nível da interface.

Depois que o endereço de transporte estiver configurado, a sessão LDP alvo é estabelecida com base na preferência do endereço de transporte do LDP.

A ordem de preferência do endereço de transporte para vizinho alvo (configurado por meio de circuito de Camada 2, MPLS, VPLS e configuração LDP) é a seguinte:

  1. Na [edit protocols ldp session] hierarquia.

  2. Na [edit protocols ldp session-group] hierarquia.

  3. Na [edit protocols ldp interfcae lo0] hierarquia.

  4. Na [edit protocols ldp] hierarquia.

  5. Endereço padrão.

A ordem de preferência do endereço de transporte para os vizinhos descobertos é a seguinte:

  1. Na [edit protocols ldp interfcae] hierarquia.

  2. Na [edit protocols ldp] hierarquia.

  3. Endereço padrão.

A ordem de preferência do endereço de transporte para vizinhos com alvo automático onde o LDP está configurado para aceitar pacotes hello é a seguinte:

  1. Na [edit protocols ldp interfcae lo0] hierarquia.

  2. Na [edit protocols ldp] hierarquia.

  3. Endereço padrão.

Configuração de endereço de transporte de solução de problemas

Você pode usar as seguintes saídas de comando show para solucionar problemas em sessões LDP direcionadas:

  • show ldp session

  • show ldp neighbor

    O nível de saída do comando exibe o endereço de transporte detail enviado nas mensagens de olá para o vizinho show ldp neighbor alvo. Caso esse endereço não seja alcançável do vizinho, a sessão LDP não aparece.

  • show configuration protocols ldp

Você também pode habilitar rastreamentos de LDP para solucionar mais problemas.

  • Se a configuração for mudada do uso de um endereço de transporte inválido (não alcançável) para um endereço de transporte válido, os seguintes traços podem ser observados:

  • Se a configuração for mudada do uso de um endereço de transporte válido para o transporte que seja inválido (não alcançável), os seguintes traços podem ser observados:

Em caso de configuração com falha, realize as seguintes tarefas de solução de problemas:

  • Consulte address family o . O endereço de transporte configurado na declaração deve ser da mesma família session de endereços do vizinho ou da sessão.

  • O endereço que está configurado como o endereço de transporte em uma ou declaração deve ser local para que as mensagens neighborsession de olá direcionadas comecem. Você pode verificar se o endereço está configurado. Se o endereço não estiver configurado em qualquer interface, a configuração será recusada.

Configuração dos prefixos anunciados em LDP a partir da tabela de roteamento

Você pode controlar o conjunto de prefixos anunciados em LDP e fazer com que o roteador seja o roteador de saída para esses prefixos. Por padrão, somente o endereço de loopback é anunciado em LDP. Para configurar o conjunto de prefixos da tabela de roteamento a ser anunciado em LDP, inclua a egress-policy declaração:

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

Nota:

Se você configurar uma política de saída para LDP que não inclua o endereço de loopback, ela não será mais anunciada em LDP. Para continuar a anunciar o endereço de loopback, você precisa configurá-lo explicitamente como parte da política de saída do LDP.

A política nomeada (configurada em nível [edit policy-options] ou [edit logical-systems logical-system-name policy-options] hierarquia) é aplicada a todas as rotas da tabela de roteamento. Essas rotas que se igualam à política são anunciadas em LDP. Você pode controlar o conjunto de vizinhos aos quais esses prefixos são anunciados usando a export declaração. Apenas from operadoras são consideradas; você pode usar qualquer operador from válido. Para obter mais informações, consulte a Biblioteca de Protocolos de Roteamento do Junos OS para dispositivos de roteamento.

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

Exemplo: Configuração dos prefixos anunciados em LDP

Anununmente todas as rotas conectadas em LDP:

Configuração da Desagregação FEC

Quando um roteador de saída LDP anuncia vários prefixos, os prefixos são vinculados a um único rótulo e agregados em uma única classe de equivalência de encaminhamento (FEC). Por padrão, o LDP mantém essa agregação conforme o anúncio atravessa a rede.

Normalmente, como um LSP não é dividido entre vários hops seguinte e os prefixos estão vinculados a um único LSP, o balanceamento de carga entre caminhos de custo igual não ocorre. No entanto, você pode equilibrar a carga entre caminhos de igual custo se configurar uma política de balanceamento de carga e desagregar os FECs.

A desagregação dos FECs faz com que cada prefixo seja vinculado a um rótulo separado e se torne um LSP separado.

Para configurar FECs desagregação, inclua a deaggregate declaração:

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

Para todas as sessões de LDP, você pode configurar FECs desagregação apenas globalmente.

A desagregação de uma FEC permite que vários LSPs sejam distribuídos por vários caminhos de custo igual e distribua LSPs pelos vários saltos nos segmentos de saída, mas instala apenas um próximo hop por LSP.

Para agregar FECs, inclua a no-deaggregate declaração:

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

Para todas as sessões de LDP, você pode configurar FECs agregados apenas globalmente.

Configuração de policers para FECs LDP

Você pode configurar o Junos OS para rastrear e policiar o tráfego de FECs LDP. Os policiais LDP FEC podem ser usados para fazer qualquer um dos seguintes:

  • Rastrear ou policiar o tráfego de entrada para um FEC LDP.

  • Rastrear ou policiar o tráfego de trânsito para um FEC LDP.

  • Rastrear ou policiar o tráfego FEC LDP originado de uma classe de encaminhamento específica.

  • Rastrear ou policiar o tráfego fec LDP originado de um site específico de roteamento e encaminhamento virtual (VRF).

  • Elimine tráfego falso vinculado a um FEC LDP específico.

Para a fiscalização do tráfego de um FEC LDP, primeiro é necessário configurar um filtro. Especificamente, você precisa configurar a interface instrução ou interface-set a declaração em nível de [edit firewall family protocol-family filter filter-name term term-name from] hierarquia. A interface declaração permite combinar o filtro a uma única interface. A interface-set declaração permite combinar o filtro a várias interfaces.

Para obter mais informações sobre como configurar a declaração, a declaração e os agentes de segurança para FECs LDP, consulte as Políticas de Roteamento, filtros de firewall e Guia do usuário interfaceinterface-set dos políciadores de tráfego.

Depois de configurar os filtros, você precisa incluí-los na configuração policing de declaração de LDP. Para configurar os agentes de polícia para FECs LDP, inclua a policing declaração:

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

A policing declaração inclui as seguintes opções:

  • fec— Especifique o endereço FEC para o FEC LDP que você deseja policiar.

  • ingress-filter— Especifique o nome do filtro de tráfego de entrada.

  • transit-traffic— Especifique o nome do filtro de tráfego de trânsito.

Configuração da filtragem fec LDP IPv4

Por padrão, quando uma sessão LDP direcionada é estabelecida, o Junos OS sempre troca as classes de equivalência de encaminhamento (FECs) do IPv4 e os FECs de circuito de Camada 2 na sessão LDP direcionada. Para uma sessão LDP para um vizinho conectado indiretamente, você só pode querer exportar FECs de circuito de Camada 2 para o vizinho se a sessão estivesse configurada especificamente para dar suporte a circuitos de Camada 2 ou VPLS.

Em uma rede de fornecedores mistos, na qual todos os prefixos não BGP são anunciados em LDP, o banco de dados LDP pode se tornar grande. Para esse tipo de ambiente, pode ser útil impedir o anúncio de FECs IPv4 em sessões LDP formadas por causa da configuração de circuito de Camada 2 ou VPLS LDP. Da mesma forma, pode ser útil filtrar quaisquer FECs IPv4 recebidos nesse tipo de ambiente.

Se todos os vizinhos LDP associados a uma sessão LDP são apenas a Camada 2, você pode configurar o Junos OS para anunciar apenas FECs de circuito de Camada 2 configurando a l2-smart-policy declaração. Esse recurso também filtra automaticamente os FECs IPv4 recebidos nesta sessão. Configurar uma política de exportação ou importação explícita ativada para l2-smart-policy desativar esse recurso na direção correspondente.

Se um dos vizinhos da sessão LDP for formado por causa de uma adjacência descoberta ou se a adjacência for formada por causa de uma configuração de tunelamento LDP em um ou mais LSPs RSVP, os FECs IPv4 são anunciados e recebidos usando o comportamento padrão.

Para impedir que LDP exporte FECs IPv4 em sessões LDP apenas com os vizinhos de Camada 2 e filtrar os FECs IPv4 recebidos durante essas sessões, inclua a l2-smart-policy declaração:

Para uma lista de níveis de hierarquia nos quais você pode configurar esta declaração, consulte o resumo da declaração para esta declaração.

Configuração de BFD para LSPs LDP

Você pode configurar a Detecção de Encaminhamento Bidirecional (BFD) para LSPs LDP. O protocolo BFD é um mecanismo simples de olá que detecta falhas em uma rede. Os pacotes Hello são enviados em um intervalo especificado e regular. Uma falha do vizinho é detectada quando o roteador para de receber uma resposta após um intervalo especificado. O BFD funciona com uma grande variedade de ambientes e topologias de rede. Os temporizadores de detecção de falhas para BFD têm limites de tempo mais curtos do que os mecanismos de detecção de falhas de rotas estáticas, fornecendo detecção mais rápida.

Um erro é registrado sempre que uma sessão BFD de um caminho falha. As seguintes mostra como podem aparecer mensagens de log BFD para LDP LSP:

Você também pode configurar BFD para LSPs RSVP, conforme descrito na configuração de BFD para LSPscom sinal de RSVP.

Os temporizadores de detecção de falhas de BFD são adaptáveis e podem ser ajustados para serem mais ou menos agressivos. Por exemplo, os temporizadores podem se adaptar a um valor mais alto se a adjaciência falhar, ou um vizinho pode negociar um valor mais alto por um temporizador do que o valor configurado. Os temporizadores se adaptam a um valor mais alto quando um retalho de sessão BFD ocorre mais de três vezes em um intervalo de 15 segundos. Um algoritmo de back-off aumenta o intervalo de recebimento (Rx) em dois, se a instância BFD local for o motivo do retalho de sessão. O intervalo de transmissão (Tx) é ampliado em dois se a instância BFD remota for o motivo do retalho de sessão. Você pode usar o comando para devolver os temporizadores de intervalo clear bfd adaptation BFD aos valores configurados. O comando não tem sucesso, o que significa que o comando não afeta o fluxo de clear bfd adaptation tráfego no dispositivo de roteamento.

Para habilitar BFD para LSPs LDP, inclua oam as e bfd-liveness-detection declarações:

Você pode habilitar BFD para os LSPs LDP associados a uma classe de equivalência de encaminhamento (FEC) específica, configurando o endereço FEC usando a opção no nível fec[edit protocols ldp] da hierarquia. Como alternativa, você pode configurar uma política de ingresso na Operação Administração e Gerenciamento (OAM) para habilitar o BFD em uma variedade de endereços FEC. Para obter mais informações, consulte Configurando políticas de ingresso no OAM para LDP.

Você não pode habilitar LSPs BFD LDP, a menos que seus endereços FEC equivalentes sejam configurados explicitamente ou o OAM esteja habilitado nos FECs usando uma política de ingresso no OAM. Se o BFD não estiver habilitado para quaisquer endereços FEC, a sessão BFD não será ativada.

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

  • [edit protocols ldp]

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

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

A oam declaração inclui as seguintes opções:

  • fec— Especifique o endereço FEC. Você deve especificar um endereço FEC ou configurar uma política de ingresso no OAM para garantir que a sessão BFD seja realizada.

  • lsp-ping-interval— Especifique a duração do intervalo de ping LSP em segundos. Para emitir um ping em um LSP com sinal de LDP, use o ping mpls ldp comando. Para obter mais informações, consulte o ClI Explorer.

A bfd-liveness-detection declaração inclui as seguintes opções:

  • ecmp— Cause ao LDP que estabeleça sessões de BFD para todos os caminhos de ECMP configurados para o FEC especificado. Se você configurar ecmp a opção, você também deve configurar a periodic-traceroute instrução para o FEC especificado. Caso não faça isso, a operação de compromisso falha. Você pode configurar a declaração em nível de hierarquia global () ao mesmo tempo em que periodic-traceroute configura a opção de um [edit protocols ldp oam]ecmp FEC específico ( [edit protocols ldp oam fec address bfd-liveness-detection] ).

  • intervalo de espera— Especifique a duração da sessão BFD deve permanecer aberta antes de adicionar a rota ou o próximo hop. Especificar um tempo de 0 segundos faz com que a rota ou o próximo hop sejam adicionados assim que a sessão BFD voltar.

  • minimum-interval— Especifique o intervalo mínimo de transmissão e recebimento. Se você configurar minimum-interval a opção, você não precisa configurar a minimum-receive-interval opção ou a minimum-transmit-interval opção.

  • minimum-receive-interval— Especifique o intervalo de recebimento mínimo. O intervalo vai de 1 a 255.000 milissegundos.

  • minimum-transmit-interval— Especifique o intervalo mínimo de transmissão. O intervalo vai de 1 a 255.000 milissegundos.

  • multiplier— Especifique o multiplicador de tempo de detecção. O intervalo vai de 1 a 255.

  • versão— especifique a versão BFD. As opções são BFD versão 0 ou BFD versão 1. Por padrão, o software do Junos OS tenta determinar automaticamente a versão BFD.

Configuração de BFD consciente de ECMP para LSPs LDP

Quando você configura BFD para um FEC, uma sessão BFD é estabelecida para apenas um next-hop local ativo para o roteador. No entanto, você pode configurar várias sessões de BFD, uma para cada FEC associada a um caminho de multipath (ECMP) de custo igual específico. Para que isso funcione corretamente, você também precisa configurar o traceroute diário LDP LSP. (Consulte Configuração do LDP LSP Traceroute.) O traceroute LDP LSP é usado para descobrir caminhos de ECMP. Uma sessão BFD é iniciada para cada caminho de ECMP descoberto. Sempre que uma sessão BFD de um dos caminhos DE ECMP falha, um erro é registrado.

O traceroute LDP LSP é executado periodicamente para verificar a integridade dos caminhos de ECMP. As seguintes podem ocorrer quando um problema for descoberto:

  • Se o traceroute LDP LSP mais recente de uma FEC difere do traceroute anterior, as sessões de BFD associadas a esse FEC (as sessões de BFD para intervalos de endereços que mudaram da corrida anterior) são trazidas e novas sessões BFD são iniciadas para os endereços de destino nas faixas alteradas.

  • Se o traceroute LDP LSP retornar a um erro (por exemplo, um tempo de saída), todas as sessões de BFD associadas a esse FEC serão destruídas.

Para configurar o LDP para estabelecer sessões de BFD para todos os caminhos de ECMP configurados para o FEC especificado, inclua a ecmp declaração.

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

Junto com a declaração, você também deve incluir a declaração, seja na configuração OAM global LDP (no nível ou na hierarquia) ou na configuração para o ecmpperiodic-traceroute[edit protocols ldp oam][edit logical-systems logical-system-name protocols ldp oam] FEC especificado (no nível ou na [edit protocols ldp oam fec address][edit logical-systems logical-system-name protocols ldp oam fec address] hierarquia). Caso contrário, a operação de compromisso falha.

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

Configurando uma ação de falha na sessão BFD em um LDP LSP

Você pode configurar propriedades de rotear e next-hop no caso de falha na sessão BFD em um LDP LSP. O evento de falha pode ser uma sessão de BFD existente que foi para baixo ou pode ser uma sessão BFD que nunca ocorreu. O LDP adiciona de volta a rota ou o próximo hop quando a sessão BFD relevante voltar a ser realizada.

Você pode configurar uma das seguintes opções de ação de falha para a declaração no caso de falha na sessão failure-action BFD no LDP LSP:

  • remove-nexthop— Remove a rota correspondente ao próximo hop da rota do LSP no nó de entrada quando um evento de falha de sessão BFD é detectada.

  • remove-route— Remove a rota correspondente ao LSP das tabelas de roteamento apropriadas quando um evento de falha de sessão BFD é detectada. Se o LSP estiver configurado com ECMP e uma sessão BFD correspondente a qualquer caminho for abaixo, a rota será removida.

Para configurar uma ação de falha no caso de falha na sessão BFD em um LDP LSP, inclua a opção ou a remove-nexthopremove-route opção da failure-action instrução:

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

Configurando o intervalo de espera para a sessão BFD

Você pode especificar a duração da sessão BFD antes de adicionar uma rota ou próximo hop configurando a instrução no nível da hierarquia ou no nível holddown-interval[edit protocols ldp oam bfd-livenesss-detection] da [edit protocols ldp oam fec address bfd-livenesss-detection] hierarquia. Especificar um tempo de 0 segundos faz com que a rota ou o próximo hop sejam adicionados assim que a sessão BFD voltar.

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

Entender o fast reroute somente para multicast

O reroute rápido somente para multicast (MoFRR) minimiza a perda de pacote para tráfego em uma árvore de distribuição multicast quando ocorrem falhas no enlace, aprimorando protocolos de roteamento multicast, como PIM (Protocol Independent Multicast) e Multipoint Label Distribution Protocol (multipoint LDP) em dispositivos que suportam esses recursos.

Nota:

Nos switches, o MoFRR com MPLS de rótulos e LDP multipoint não é suportado.

Para roteadores da Série MX, o MoFRR é suportado apenas em roteadores da Série MX com placas de linha MPC. Como um pré-requisito, você deve configurar o roteador em modo, e todas as placas de linha do roteador network-services enhanced-ip devem ser MPCs.

Com o MoFRR ativado, os dispositivos enviam mensagens de junção nos caminhos upstream principais e de backup em direção a uma origem multicast. Os dispositivos recebem pacotes de dados dos caminhos principal e de backup e descartam os pacotes redundantes com base na prioridade (pesos atribuídos aos caminhos principal e de backup). Quando um dispositivo detecta uma falha no caminho principal, ele começa imediatamente a aceitar pacotes da interface secundária (o caminho de backup). A comover rápida melhora muito os tempos de convergência após falhas de enlace do caminho principal.

Uma aplicação para MoFRR é o streaming de IPTV. Os streams IPTV são multicast como streams de UDP, portanto, quaisquer pacotes perdidos não são retransmitidos, o que leva a uma experiência de usuário menos do que satisfatória. O MoFRR pode melhorar a situação.

Visão geral do MoFRR

Com rerroteamento rápido em streams unicast, um dispositivo de roteamento up MPLS stream pré-estabelece caminhos comutados por rótulos (LSPs) ou pré-computa um caminho de backup rápido e sem loop IP (LFA) para tratar a falha de um segmento no caminho downstream.

No roteamento multicast, o lado de recebimento geralmente origina os gráficos de distribuição de tráfego. Isso é diferente do roteamento unicast, que geralmente estabelece o caminho da origem até o receptor. PIM (para IP), LDP multipoint (para MPLS) e RSVP-TE (para MPLS) são protocolos capazes de estabelecer gráficos de distribuição multicast. Desses, os receptores PIM e multipoint LDP iniciam a configuração de gráfico de distribuição, para que o MoFRR possa trabalhar com esses dois protocolos multicast nos quais são suportados.

Em uma árvore multicast, se o dispositivo detectar uma falha nos componentes da rede, ele leva algum tempo para realizar um reparo reativo, o que leva a uma perda significativa de tráfego ao configurar um caminho alternativo. O MoFRR reduz a perda de tráfego em uma árvore de distribuição de multicast quando um componente de rede falha. Com o MoFRR, um dos dispositivos de roteamento downstream configura um caminho alternativo em direção à origem para receber uma transmissão ao vivo de backup do mesmo tráfego multicast. Quando ocorre uma falha ao longo do fluxo principal, o dispositivo de roteamento MoFRR pode mudar rapidamente para o fluxo de backup.

Com o MoFRR ativado, para cada entrada (S,G), o dispositivo usa duas das interfaces upstream disponíveis para enviar uma mensagem de junção e receber tráfego multicast. O protocolo tenta selecionar dois caminhos diferentes se dois desses caminhos estão disponíveis. Se não estiver disponível caminhos de desatarjamento, o protocolo selecionará dois caminhos não ungidos. Se dois caminhos não diferentes não estão disponíveis, apenas um caminho principal será selecionado sem backup. O MoFRR prioriza o backup desassossego em prol do balanceamento de carga dos caminhos disponíveis.

O MoFRR é suportado para famílias de protocolo IPv4 e IPv6.

Figura 12 mostra dois caminhos do dispositivo de roteamento do receptor multicast (também chamado de dispositivo de borda do provedor de saída (PE) até o dispositivo de roteamento de origem multicast (também chamado de dispositivo PE de ingresso).

Figura 12: Topologia de amostra moFRRTopologia de amostra moFRR

Com o MoFRR ativado, o dispositivo de roteamento de saída (lado do receptor) configura duas árvores multicast, um caminho principal e um caminho de backup, em direção à origem multicast para cada (S,G). Em outras palavras, o dispositivo de roteamento de saída propaga o mesmo (S,G) junta mensagens em direção a dois diferentes vizinhos upstream, criando assim duas árvores multicast.

Uma das árvores multicast atravessa o plano 1 e a outra pelo plano 2, como mostrado em Figura 12 . Para cada (S,G), o dispositivo de roteamento de saída encaminha o tráfego recebido no caminho principal e reduz o tráfego recebido no caminho de backup.

O MoFRR é suportado em caminhos multicamadas de custo igual (ECMP) e não-ECMP. O dispositivo precisa habilitar rotas LFA (Unicast Loop-Free Alternate, Alternativa sem loop unicast) para dar suporte a MoFRR em caminhos não ECMP. Você habilita rotas LFA link-protection usando a instrução na configuração de protocolo de gateway interior (IGP). Ao habilitar a proteção de enlace em uma interface OSPF ou IS-IS, o dispositivo cria um caminho LFA de backup até o próximo salto principal para todas as rotas de destino que atravessam a interface protegida.

O Junos OS implementa o MoFRR na rede IP para IP MoFRR e no MPLS de roteamento de borda de rótulo (LER) para MoFRR de LDP multipoint.

O MoFRR multipoint LDP é usado no dispositivo de saída de uma rede MPLS, onde os pacotes são encaminhados para uma rede de IP. Com o MoFRR multipoint LDP, o dispositivo estabelece dois caminhos em direção ao dispositivo de roteamento PE upstream para receber dois fluxos de MPLS pacotes no LER. O dispositivo aceita um dos streams (o principal), e o outro (o backup) é descartado no LER. SE o caminho principal falhar, o dispositivo aceitará o fluxo de backup. O suporte à sinalização de inband é um pré-requisito para MoFRR com LDP multipoint (consulte Entender a sinalização de inband LDP multipoint para LSPs point-to-multipoint).

Funcionalidade PIM

O Junos OS tem suporte para MoFRR para SPT (Shortest-Path Tree, árvore de caminho mais curto) e se une a SSM (Source-Specific Multicast, multicast) e multicast de qualquer origem (ASM). O MoFRR é suportado para as variedades SSM e ASM. Para habilitar a junção do MoFRR (*,G), inclua a instrução mofrr-asm-starg de configuração na [edit routing-options multicast stream-protection] hierarquia. Para cada grupo G, o MoFRR operará para (S,G) ou (*,G), mas não para ambos. (S,G) sempre tem precedência sobre (*,G).

Com o MoFRR ativado, um dispositivo de roteamento PIM propaga-se juntando mensagens em duas interfaces de encaminhamento de caminho reverso (RPF) upstream para receber tráfego multicast em ambos os links para a mesma solicitação de adesão. O MoFRR dá preferência a dois caminhos que não convergem para o mesmo dispositivo de roteamento upstream imediato. O PIM instala as rotas multicast adequadas com os próximos hops de RPF upstream com duas interfaces (para os caminhos principais e de backup).

Quando o caminho principal falha, o caminho de backup é atualizado para o status principal e o dispositivo encaminha o tráfego de acordo. Se houver caminhos alternativos disponíveis, o MoFRR calcula um novo caminho de backup e atualiza ou instala a rota multicast adequada.

Você pode habilitar o MoFRR com o PIM juntando o balanceamento de carga (consulte a join-load-balance automatic declaração). Entretanto, nesse caso, a distribuição de mensagens de junção entre os links pode não ser uniforme. Quando um novo enlace de ECMP é adicionado, junte mensagens no caminho principal e seja redistribuído e balanceado de carga. As mensagens de junção no caminho de backup ainda podem seguir o mesmo caminho e talvez não sejam redistribuídas uniformemente.

Você habilita o MoFRR usando a stream-protection instrução de configuração na [edit routing-options multicast] hierarquia. O MoFRR é gerenciado por um conjunto de políticas de filtro.

Quando um dispositivo de roteamento PIM de saída recebe uma mensagem de junção ou um relatório IGMP, ele verifica se há uma configuração moFRR e prossegue da seguinte forma:

  • Se a configuração MoFRR não estiver presente, o PIM enviará uma mensagem upstream de junção em direção a um vizinho upstream (por exemplo, plano 2 in Figura 12 ).

  • Se a configuração MoFRR estiver presente, o dispositivo verificará uma configuração de política.

  • Se uma política não estiver presente, o dispositivo verificará os caminhos principais e de backup (interfaces upstream) e prossiga da seguinte forma:

    • Se os caminhos principais e de backup não estão disponíveis, o PIM envia uma mensagem upstream de junção em direção a um vizinho upstream (por exemplo, plano 2 in Figura 12 ).

    • Se os caminhos principais e de backup estão disponíveis, o PIM envia a mensagem de junção upstream em direção a dois dos vizinhos upstream disponíveis. O Junos OS configura caminhos multicast principais e secundários para receber tráfego multicast (por exemplo, plano 1 in Figura 12 ).

  • Se uma política estiver presente, o dispositivo verifica se a política permite o MoFRR para isso (S,G), e prossiga da seguinte forma:

    • Se essa verificação de política falhar— o PIM envia uma mensagem de junção upstream em direção a um vizinho upstream (por exemplo, o plano 2 in Figura 12 ).

    • Se essa verificação de política for aprovada, o dispositivo verificará os caminhos principais e de backup (interfaces upstream).

      • Caso os caminhos principal e de backup não sejam disponíveis, o PIM enviará uma mensagem upstream de junção em direção a um vizinho upstream (por exemplo, plano 2 in Figura 12 ).

      • Se os caminhos principais e de backup estão disponíveis, o PIM enviará a mensagem de junção upstream em direção a dois dos vizinhos upstream disponíveis. O dispositivo configura caminhos multicast principais e secundários para receber tráfego multicast (por exemplo, plano 1 in Figura 12 ).

Funcionalidade de LDP multipoint

Para evitar MPLS duplicação de tráfego, o LDP multipoint costuma selecionar apenas um caminho upstream. (Consulte a seção 2.4.1.1. Determinar o 'upstream LSR' da One na RFC 6388, extensões de protocolo de distribuição de rótulos para caminhos comutado de rótulos de ponto para multipoint e multipoint para multipoint.)

Para LDP multipoint com MoFRR, o dispositivo LDP multipoint escolhe dois peers upstream separados e envia dois rótulos separados, um para cada peer upstream. O dispositivo usa o mesmo algoritmo descrito na RFC 6388 para selecionar o caminho upstream principal. O dispositivo usa o mesmo algoritmo para selecionar o caminho upstream de backup, mas exclui o upstream principal LSR como um candidato. Os dois peers upstream diferentes enviam dois fluxos de MPLS para o dispositivo de roteamento de saída. O dispositivo escolhe apenas um dos caminhos do vizinho upstream como o caminho principal para aceitar o tráfego MPLS de segurança. O outro caminho torna-se o caminho do backup, e o dispositivo reduz esse tráfego. Quando o caminho upstream principal falha, o dispositivo começa a aceitar o tráfego do caminho de backup. O dispositivo LDP multipoint escolhe os dois caminhos upstream com base no próximo hop do protocolo de gateway interior (IGP) root.

Uma classe de equivalência de encaminhamento (FEC) é um grupo de pacotes IP que são encaminhados da mesma maneira, pelo mesmo caminho e com o mesmo tratamento de encaminhamento. Normalmente, o rótulo colocado em um pacote específico representa o FEC ao qual esse pacote é atribuído. No MoFRR, duas rotas são colocadas na tabela mpls.0 para cada FEC, uma rota para o rótulo principal e a outra para o rótulo de backup.

Se houver links paralelos em direção ao mesmo dispositivo upstream imediato, o dispositivo considera ambos os links paralelos os principais. Em qualquer ponto do tempo, o dispositivo upstream envia tráfego em apenas um dos vários links paralelos.

Um nó de botão é uma LSR que é uma saída LSR, mas também tem um ou mais LSRs conectados diretamente no downstream. Para um nó de botão, o tráfego do caminho upstream principal é encaminhado para uma rede downstream LSR. Se o caminho upstream principal falhar, o tráfego MPLS do caminho upstream de backup é encaminhado para a rede de LSR. Isso significa que o próximo salto LSR downstream é adicionado a ambas as MPLS, juntamente com o próximo salto de saída.

Assim como no PIM, você habilita o MoFRR com LDP multipoint usando a instrução de configuração na hierarquia, e ela é gerenciada por um conjunto de políticas stream-protection[edit routing-options multicast] de filtro.

Se você habilitar o FEC multipoint LDP ponto a multipoint para MoFRR, o dispositivo considerará as seguintes considerações para selecionar o caminho upstream:

  • As sessões de LDP direcionadas são ignoradas se houver uma sessão LDP não realizada. Se houver uma sessão LDP segmentada única, a sessão LDP segmentada é selecionada, mas o FEC ponto a multipoint correspondente perde o recurso moFRR porque não há interface associada à sessão LDP direcionada.

  • Todas as interfaces que pertencem à mesma rede upstream LSR são consideradas o caminho principal.

  • Para quaisquer atualizações de rota de nó raiz, o caminho upstream é alterado com base nos próximos hops mais recentes do IGP. Se tiver um caminho melhor, o LDP multipoint tenta mudar para o caminho melhor.

Encaminhamento de pacotes

Para PIM ou LDP multipoint, o dispositivo realiza seleção de fluxo de origem multicast na interface de ingresso. Isso preserva a largura de banda da malha e maximiza o desempenho do encaminhamento, porque:

  • Evita enviar fluxos duplicados na malha

  • Impede várias olhadas de roteamento (que resultam em gotas de pacotes).

Para PIM, cada fluxo de multicast IP contém o mesmo endereço de destino. Independentemente da interface na qual os pacotes chegam, os pacotes têm a mesma rota. O dispositivo verifica a interface na qual cada pacote chega e encaminha apenas aqueles que são da interface primária. Se a interface combina com uma interface de fluxo de backup, o dispositivo derruba os pacotes. Se a interface não combinar com a interface de fluxo principal ou de backup, o dispositivo tratará os pacotes como exceções no plano de controle.

Figura 13 mostra esse processo com amostra de interfaces primárias e de backup para roteadores com PIM. Figura 14 mostra isso da mesma forma para switches com PIM.

Figura 13: MoFRR IP Route Lookup na área Mecanismo de Encaminhamento de Pacotes roteadoresMoFRR IP Route Lookup na área Mecanismo de Encaminhamento de Pacotes roteadores
Figura 14: MoFRR IP Route Handling no Mecanismo de Encaminhamento de Pacotes switchesMoFRR IP Route Handling no Mecanismo de Encaminhamento de Pacotes switches

Para MoFRR com LDP multipoint nos roteadores, o dispositivo usa várias MPLS rótulos para controlar a seleção de fluxo MoFRR. Cada rótulo representa uma rota separada, mas cada um faz referência à mesma verificação da lista de interface. O dispositivo só encaminha o rótulo principal e derruba todos os outros. Várias interfaces podem receber pacotes usando o mesmo rótulo.

Figura 15 mostra esse processo para roteadores com LDP multipoint.

Figura 15: MoFRR MPLS de rotas no Mecanismo de Encaminhamento de PacotesMoFRR MPLS de rotas no Mecanismo de Encaminhamento de Pacotes

Limitações e ressalvas

Limitações e ressalvas do MoFRR sobre dispositivos de comação e roteamento

O MoFRR tem as seguintes limitações e ressalvas sobre dispositivos de roteamento e com switching:

  • A detecção de falha do MoFRR é suportada para proteção imediata do enlace do dispositivo de roteamento no qual o MoFRR está ativado e não em todos os enlaces (de ponta a ponta) no caminho do tráfego multicast.

  • O MoFRR tem suporte para reroute rápido em dois caminhos desunião selecionados em direção à origem. Dois dos vizinhos upstream selecionados não podem estar na mesma interface, ou seja, dois vizinhos upstream em um segmento de LAN. O mesmo acontece se a interface upstream for uma interface de túnel multicast.

  • Não é possível detectar os caminhos upstream máximos de desaintados de ponta a ponta. O dispositivo de roteamento do lado do receptor (saída) só garante se existe um dispositivo upstream desagregue (o hop anterior imediato). O PIM e o LDP multipoint não suportam o equivalente a erOs (Explicit Route Objects, objetos de rota explícitos). Assim, a detecção de caminho upstream desarmada limita-se ao controle do dispositivo de hop imediatamente anterior. Devido a essa limitação, o caminho para o dispositivo upstream do hop anterior selecionado como principal e backup pode ser compartilhado.

  • Pode haver perda de tráfego nos seguintes cenários:

    • Um caminho upstream melhor fica disponível em um dispositivo de saída.

    • O MoFRR está ativado ou inválido no dispositivo de saída enquanto há um fluxo de tráfego ativo fluindo.

  • O balanceamento de carga de junção de PIM para unir mensagens para caminhos de backup não é suportado.

  • Para um grupo multicast G, o MoFRR não é permitido para mensagens de junção (S,G) e (*,G). (S,G) as mensagens de junção têm precedência sobre (*,G).

  • O MoFRR não tem suporte para streams de tráfego multicast que usam dois grupos multicast diferentes. Cada combinação (S,G) é tratada como um fluxo de tráfego multicast exclusivo.

  • A gama de PIM bidirecionais não tem suporte para MoFRR.

  • O modo denso PIM não é suportado com MoFRR.

  • As estatísticas de multicast para o fluxo de tráfego de backup não são mantidas pelo PIM e, portanto, não estão disponíveis na saída operacional dos show comandos.

  • O monitoramento de taxas não é suportado.

Limitações do MoFRR em dispositivos de comação com PIM

O MoFRR com PIM tem as seguintes limitações nos dispositivos de comação:

  • O MoFRR não é suportado quando a interface upstream é uma interface integrada de roteamento e ponte (IRB), o que afeta outros recursos de multicast, como Internet Group Management Protocol versão 3 (IGMPv3).

  • Replicação de pacotes e buscas em multicast enquanto encaminha o tráfego multicast pode fazer com que os pacotes recirculam por meio de PFEs várias vezes. Como resultado, os valores exibidos para contagens de pacotes multicast a partir do comando podem mostrar números mais altos do que o esperado em campos de show pfe statistics traffic saída, como Input packets e Output packets . Você pode notar esse comportamento com mais frequência em cenários MoFRR, porque os fluxos de backup e primária duplicado aumentam o fluxo de tráfego em geral.

Limitações e ressalvas do MoFRR em dispositivos de roteamento com LDP multipoint

O MoFRR tem as seguintes limitações e ressalvas nos roteadores quando usado com LDP multipoint:

  • O MoFRR não se aplica ao tráfego LDP multipoint recebido em um túnel RSVP porque o túnel RSVP não está associado a nenhuma interface.

  • O MoFRR miststream não é suportado. Isso refere-se à sinalização em banda de LDP multipoint PIM, na qual um caminho upstream é por LDP multipoint e o segundo caminho upstream é por PIM.

  • Rótulos de LDP multipoint, pois rótulos internos não são suportados.

  • Se a origem for alcançável por meio de vários dispositivos de roteamento de borda do provedor de entrada (do lado da origem), o MoFRR multipoint não é compatível.

  • Sessões upstream LDP direcionadas não são selecionadas como o dispositivo upstream do MoFRR.

  • A proteção de enlace LDP multipoint no caminho de backup não é suportada porque não há suporte para rótulos internos MoFRR.

Configuração de reroute rápido somente para multicast

Você pode configurar o reroute rápido somente para multicast (MoFRR) para minimizar a perda de pacotes em uma rede quando houver uma falha no enlace.

Quando o rerrote rápido é aplicado a streams unicast, um roteador upstream pré-estabelece MPLS caminhos comutados por rótulos (LSPs) ou pré-computa um caminho de backup rápido e sem loop (LFA) ip para tratar a falha de um segmento no caminho de downstream.

No roteamento multicast, os gráficos de distribuição de tráfego geralmente são originados pelo receptor. Isso é diferente do roteamento unicast, que normalmente estabelece o caminho da origem até o receptor. Os protocolos capazes de estabelecer gráficos de distribuição multicast são PIM (para IP), LDP multipoint (para MPLS) e RSVP-TE (para MPLS). Desses, os receptores PIM e multipoint LDP iniciam a configuração do gráfico de distribuição e, portanto:

  • Na série QFX, o MoFRR é suportado em domínios DE PIM.

  • Na Série MX e na Série SRX, o MoFRR é suportado em domínios de PIM e LDP multipoint.

As etapas de configuração são as mesmas para permitir o MoFRR para PIM em todos os dispositivos que suportam esse recurso, a menos que indicado de outra forma. Etapas de configuração que não são aplicáveis ao MoFRR multipoint LDP também são indicadas.

(Somente para roteadores da série MX) O MoFRR é suportado em roteadores da Série MX com placas de linha MPC. Como pré-requisito, todas as placas de linha do roteador devem ser MPCs.

Para configurar o MoFRR em roteadores ou switches:

  1. (Somente para roteadores da série MX e série SRX) Definir o roteador para o modo IP aprimorado.
  2. Ative o MoFRR.
  3. (Opcional) Configure uma política de roteamento que filtra um conjunto restrito de streams multicast a ser afetado pela configuração do MoFRR.

    Você pode aplicar filtros com base em endereços de origem ou grupo.

    Por exemplo:

  4. (Opcional) Se você configurar uma política de roteamento para filtrar o conjunto de grupos multicast a fim de ser afetado pela configuração MoFRR, aplique a política para proteção do fluxo MoFRR.

    Por exemplo:

  5. (Opcional) Em um domínio PIM com MoFRR, permita que o MoFRR seja aplicado a qualquer asm (ASM) de qualquer origem.

    Ele não é suportado para MoFRR multipoint LDP.

  6. (Opcional) Em um domínio PIM com MoFRR, permita que apenas um RPF (um RPF em um plano separado) seja selecionado como o caminho RPF de backup.

    Ele não é suportado para MoFRR multipoint LDP. Em um domínio LDP MoFRR multipoint, o mesmo rótulo é compartilhado entre links paralelos com o mesmo vizinho upstream. Esse não é o caso em um domínio de PIM, onde cada enlace forma um vizinho. A declaração não permite que um caminho de RPF de backup seja selecionado se o caminho for para o mesmo vizinho upstream que o mofrr-disjoint-upstream-only do caminho RPF principal. Isso garante que o MoFRR seja acionado apenas em uma topologia que tenha vários vizinhos upstream RPF.

  7. (Opcional) Em um domínio de PIM com MoFRR, impeça o envio de mensagens de junção no caminho de backup, mas mantenha todas as outras funcionalidades do MoFRR.

    Ele não é suportado para MoFRR multipoint LDP.

  8. (Opcional) Em um domínio DE PIM com MoFRR, permitir que uma nova seleção de caminho principal seja baseada na seleção de gateway unicast para a rota unicast até a origem e mudar quando houver uma mudança na seleção unicast, em vez de promover o caminho de backup como principal. Isso garante que o hop RPF principal sempre está no melhor caminho.

    Quando você inclui a declaração, não é garantido que o caminho de backup seja promovido a ser o novo caminho mofrr-primary-selection-by-routing principal quando o caminho principal for abaixo.

    Ele não é suportado para MoFRR multipoint LDP.

Exemplo: Configurando o reroute rápido somente para multicast em um domínio LDP multipoint

Este exemplo mostra como configurar o Reroute rápido somente para multicast (MoFRR) para minimizar a perda de pacotes em uma rede quando houver uma falha no enlace.

O MoFRR multipoint LDP é usado no nó de saída de uma rede MPLS, onde os pacotes são encaminhados para uma rede de IP. No caso do MoFRR LDP multipoint, os dois caminhos em direção ao roteador de borda do provedor de upstream (PE) são estabelecidos para receber dois fluxos de pacotes de MPLS no roteador de borda do rótulo (LER). Um dos fluxos (o principal) é aceito, e o outro (o backup) é descartado na LER. O fluxo de backup é aceito se o caminho principal falhar.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Em um domínio LDP multipoint, para o MoFRR funcionar, somente o roteador PE de saída precisa ter o MoFRR ativado. Os outros roteadores não precisam dar suporte ao MoFRR.

O MoFRR é suportado em plataformas da Série MX com placas de linha MPC. Como um pré-requisito, o roteador deve ser definido como modo, e todas as placas de linha na plataforma network-services enhanced-ip devem ser MPCs.

Este exemplo requer a versão 14.1 do Junos OS ou mais tarde no roteador PE de saída.

Visão geral

Neste exemplo, o dispositivo R3 é o roteador de borda de saída. O MoFRR está ativado apenas neste dispositivo.

OSPF é usado para conectividade, embora qualquer protocolo de gateway interior (IGP) ou rotas estáticas possa ser usado.

Para fins de teste, os roteadores são usados para simular a origem e o receptor. O dispositivo R4 e o dispositivo R8 estão configurados para se juntarem ao grupo desejado usando o set protocols igmp interface interface-name static group group comando. No caso em que um host receptor multicast real não estiver disponível, como neste exemplo, essa configuração de IGMP estático é útil. Nos receptores, para fazê-los ouvir o endereço do grupo multicast, este exemplo usa set protocols sap listen group .

A configuração MoFRR inclui uma opção de política que não é mostrada neste exemplo, mas é explicada separadamente. A opção está configurada da seguinte forma:

Topologia

Figura 16 mostra a rede amostral.

Figura 16: MoFRR em um domínio LDP multipointMoFRR em um domínio LDP multipoint

Configuração rápida CLI mostra a configuração de todos os dispositivos em Figura 16 .

A seção Configuração descreve as etapas do dispositivo R3.

Configuração rápida CLI

Configuração rápida CLI

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

Src1 de dispositivos

Src2 de dispositivos

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Dispositivo R6

Dispositivo R7

Dispositivo R8

Configuração

Procedimento

Procedimento passo a passo

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

Para configurar o dispositivo R3:

  1. Ative o modo IP aprimorado.

  2. Configure as interfaces de dispositivo.

  3. Configure o número do sistema autônomo (AS).

  4. Configure as políticas de roteamento.

  5. Configure PIM.

  6. Configurar LDP.

  7. Configure rotas IGP ou estáticas.

  8. Configure a rede BGP.

  9. Configure MPLS e, opcionalmente, RSVP.

  10. Ative o MoFRR.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show chassisshow interfaces comandos, show protocols , show policy-optionsshow routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

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

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação das classes de equivalência de encaminhamento de LDP point-to-multipoint

Propósito

Certifique-se de que o MoFRR está ativado e determine quais rótulos estão sendo usados.

Ação
Significado

A saída mostra que o MoFRR está habilitado, e mostra que os rótulos 301568 e 301600 estão sendo usados para os dois LSPs multipoint LDP ponto a multipoint.

Examinando as informações de rótulos

Propósito

Certifique-se de que o dispositivo de saída tenha duas interfaces upstream para a junção do grupo multicast.

Ação
Significado

A saída mostra os caminhos upstream principais e os caminhos upstream de backup. Ele também mostra os próximos saltos do RPF.

Verificação das rotas multicast

Propósito

Examine a tabela de encaminhamento de IP multicast para ter certeza de que existe uma lista de interface RPF upstream, com uma interface principal e uma interface de backup.

Ação
Significado

A saída mostra sessões primárias e de backup, e os próximos hops de RPF.

Verificação das estatísticas de tráfego de LDP point-to-multipoint

Propósito

Certifique-se de que as estatísticas primárias e de backup estão listadas.

Ação
Significado

A saída mostra rotas primárias e de backup com os rótulos.

Exemplo: Configurando o downstream de LDP sob demanda

Este exemplo mostra como configurar o LDP downstream sob demanda. Normalmente, o LDP é configurado usando o modo de anúncios não solicitado downstream, o que significa que os anúncios de rótulos de todas as rotas são recebidos de todos os peers de LDP. Conforme os provedores de serviços integram as redes de acesso e agregação em um único domínio MPLS, o LDP downstream sob demanda é necessário para distribuir as ligações entre as redes de acesso e agregação e reduzir os requisitos de processamento do plano de controle.

Nós downstream podem potencialmente receber dezenas de milhares de encadernações de rótulos dos nós de agregação upstream. Em vez de aprender e armazenar todas as vinculações de rótulos para todos os endereços de loopback possíveis em toda a rede MPLS, o nó de agregação downstream pode ser configurado usando LDP downstream sob demanda para solicitar apenas as vinculações de rótulo para os FECs correspondentes aos endereços de loopback desses nós de saída nos quais os serviços estão configurados.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Série M roteador

  • Junos OS 12.2

Visão geral

Você pode habilitar um anúncio de rótulo de LDP sob demanda para uma sessão LDP, incluindo a instrução downstream-on-demand em nível [edit protocols ldp session] de hierarquia. Se tiver configurado o downstream sob demanda, o roteador Juniper Networks anunciará a solicitação de downstream sob demanda para seus roteadores de peer. Para que uma sessão downstream sob demanda seja estabelecida entre dois roteadores, ambos têm que anunciar o modo downstream sob demanda durante o estabelecimento da sessão LDP. Se um roteador anunciar o modo downstream não solicitado e o outro anunciar downstream sob demanda, o modo downstream não solicitado é usado.

Configuração

Configurando o downstream de LDP sob demanda

Procedimento passo a passo

Para configurar uma política de downstream de LDP sob demanda e, em seguida, configurar essa política e habilitar o LDP downstream sob demanda na sessão LDP:

  1. Configure a política de downstream sob demanda (DOD-Request-Loopbacks neste exemplo).

    Essa política faz com que o roteador encaminhe mensagens de solicitação de rótulo apenas para os FECs que sejam acasaados pela política DOD-Request-Loopbacks.

  2. Especifique a política DOD-Request-Loopbacks usando a dod-request-policy instrução no [edit protocols ldp] nível da hierarquia.

    A política especificada com a dod-request-policy instrução é usada para identificar os prefixos para enviar mensagens de solicitação de rótulo. Essa política é semelhante a uma política de saída ou de importação. Ao processar rotas da tabela de roteamento inet.0, o software do Junos OS verifica rotas que correspondências com DOD-Request-Loopbacks a política (neste exemplo). Se a rota corresponder à política e a sessão LDP for negociada com o modo de anúncio do DOD, as mensagens de solicitação de rótulo serão enviadas para a sessão LDP downstream correspondente.

  3. Inclua a downstream-on-demand declaração na configuração da sessão LDP para habilitar o modo de distribuição sob demanda.

Distribuição de rotas downstream de LDP sob demanda em linhas BGP

Procedimento passo a passo

Para distribuir rotas de downstream de LDP sob demanda em BGP rótulos, use uma BGP de exportação.

  1. Configure a política de rota LDP redistribute_ldp (neste exemplo).

  2. Inclua a política de rote BGP LDP (como parte da configuração BGP redistribute_ldp grupo de serviços neste ebgp-to-abr exemplo).

    BGP encaminha as rotas LDP com base na redistribute_ldp política para o roteador PE remoto

Procedimento passo a passo

Para restringir a propagação de rótulos a outros roteadores configurados no modo downstream não solicitado (em vez de downstream sob demanda), configure as seguintes políticas:

  1. Configure a dod-routes política para aceitar rotas a partir do LDP.

  2. Configure a do-not-propagate-du-sessions política para não encaminhamento de rotas para os 1.1.1.12.2.2.2 vizinhos, e 3.3.3.3 .

  3. Configure a política para evitar que as rotas analisadas pela política seja encaminhada aos roteadores vizinhos filter-dod-on-du-sessionsdod-routes definidos na do-not-propagate-du-sessions política.

  4. filter-dod-routes-on-du-sesssionEspecifique a política como a política de exportação para BGP broup. ebgp-to-abr

Resultados

A partir do modo de configuração, confirme sua configuração inserindo show policy-options os comandos e os show protocols ldp comandos. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

Verificação do modo de anúncios de rótulos

Propósito

Confirmar se a configuração está funcionando corretamente.

Use o show ldp session comando para verificar o status do modo de anúncios de rótulos da sessão LDP.

Ação

Emitir os show ldp session comandos show ldp session detail e os comandos:

  • A saída de comando a seguir para o comando indica que o (modo de anúncios de rótulos) está (o que significa que a sessão show ldp sessionAdv. Mode de DOD downstream do LDP sob demanda está operacional):

  • A saída de comando a seguir para o comando indica que show ldp session detailLocal Label Advertisement mode o valor padrão (o downstream sob demanda não está Downstream unsolicited configurado na sessão local). Por outro lado, Remote Label Advertisement mode os dois indicam que está configurado na sessão Negotiated Label Advertisement modeDownstream on demand remota

Configurando o suporte ao LDP Native IPv6

O LDP é suportado em uma rede somente IPv6 e em uma rede de pilha dupla IPv6 ou IPv4, como descrito em RFC 7552. Configure a família de inet endereços como IPv4 ou IPv6 ou ambas, e a preferência de transporte inet6 seja IPv4 ou IPv6 . A declaração permite que o Junos OS LDP estabeleça a conexão TCP no IPv4 com os vizinhos IPv4 e sobre o IPv6 com os vizinhos IPv6 como um único dual-transport LSR. As e IDs são as duas LSR IDs que devem ser configuradas para estabelecer uma sessão LDP no transporte inet-lsr-idinet6-lsr-id IPv4 e IPv6 TCP. Esses dois IDs devem ser não zero e devem ser configurados com valores diferentes.

Antes de configurar o IPv6 como uma pilha dupla, configure os protocolos de roteamento e sinalização.

Para configurar o suporte ao IPv6 nativo do LDP, você deve fazer o seguinte:

  1. Ative a desagregação da classe de equivalência de encaminhamento (FEC) a fim de usar rótulos diferentes para famílias de endereços diferentes.
  2. Configure famílias de endereçoS LDP.
  3. Configure a instrução para selecionar o transporte preferido para a conexão transport-preference TCP quando IPv4 e IPv6 estão ativados. Por padrão, o IPv6 é usado como o transporte TCP para estabelecer uma conexão LDP.
  4. (Opcional) Configure um transporte duplo para permitir que o LDP estabeleça uma sessão IPv4 separada com um vizinho IPv4 e uma sessão IPv6 com um vizinho IPv6. Configure como a LSR ID de IPv4 e como a inet-lsr-id LSR inet6-lsr-id ID para IPv6.

    Por exemplo, configure inet-lsr-id como 10.255.0.1 e inet6-lsr-id como 1.1.1.1.

Exemplo: Configurando o suporte ao LDP Native IPv6

Este exemplo mostra como permitir que o Junos OS Label Distribution Protocol (LDP) estabeleça a conexão TCP no IPv4 com os vizinhos IPv4 e sobre IPv6 com os vizinhos IPv6 como uma única pilha LSR. Isso ajuda a evitar o tunelamento de IPv6 por IPv4 MPLS núcleo com caminhos com MPLS LSPs (Label-Switched Paths, caminhos com MPLS com sinal de IPv4).

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Dois roteadores da série MX

  • Junos OS Release 16.1 ou posterior em execução em todos os dispositivos

Antes de configurar o IPv6 como uma pilha dupla, configure os protocolos de roteamento e sinalização.

Visão geral

O LDP é suportado em uma rede somente IPv6 e em uma rede de pilha dupla IPv6 ou IPv4, como descrito em RFC 7552. Configure a família de inet endereços como IPv4 ou inet6 IPv6. Por padrão, o IPv6 é usado como o transporte TCP para a sessão LDP com seus colegas quando IPv4 e IPv6 estão ativados. A instrução de transporte duplo permite que o Junos LDP estabeleça a conexão TCP sobre IPv4 com os vizinhos IPv4 e sobre o IPv6 com os vizinhos IPv6 como uma única LSR. Os dois IDs de LSR que devem ser configurados para estabelecer uma sessão LDP no transporte inet-lsr-idinet6-lsr-id IPv4 e IPv6 TCP. Esses dois IDs devem ser não zero e devem ser configurados com valores diferentes.

Topologia

Figura 17 mostra o LDP IPv6 configurado como uma pilha dupla no dispositivo R1 e no dispositivo R2.

Figura 17: Exemplo: suporte ao IPv6 nativo do LDPExemplo: suporte ao IPv6 nativo do LDP

Configuração

Configuração rápida CLI

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

R1

R2

Configuração de R1

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte " " no Guia do Usuário Using the CLI Editor in Configuration Modedo Junos OS CLI.

Para configurar o dispositivo R1:

  1. Configure as interfaces.

  2. Atribua um endereço de loopback ao dispositivo.

  3. Configure as IS-IS de rede.

  4. Configure MPLS para usar interfaces LDP no dispositivo.

  5. Ative a desagregação da classe de equivalência de encaminhamento (FEC) a fim de usar rótulos diferentes para famílias de endereços diferentes.

  6. Configure famílias de endereçoS LDP.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo show interfaces os comandos e os show protocols comandos. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Configure a preferência de transporte para selecionar o transporte preferido

Configuração rápida CLI
Procedimento passo a passo

Você pode configurar a instrução para selecionar o transporte preferido para uma conexão TCP quando transport-preference IPv4 e IPv6 estão ativados. Por padrão, o IPv6 é usado como transporte TCP para estabelecer uma conexão LDP.

  • (Opcional) Configure a preferência de transporte para uma conexão LDP.

Procedimento passo a passo
Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show protocols comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Configure o transporte duplo para estabelecer sessões separadas para IPv4 com um vizinho IPv4 e um IPv6 com um vizinho IPv6

Procedimento passo a passo

Você pode configurar a declaração para permitir que o LDP estabeleça uma sessão IPv4 separada com um vizinho IPv4 e uma sessão IPv6 com um vizinho dual-transport IPv6. Isso requer a configuração de inet-lsr-id ID LSR ID de IPv4 e como a inet6-lsr-id LSR ID de IPv6.

  • (Opcional) Configure o transporte duplo para permitir que o LDP estabeleça a conexão TCP sobre IPv4 com os vizinhos IPv4 e sobre IPv6 com os vizinhos IPv6 como um sistema de LSR.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show protocols comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificar as entradas de roteamento na tabela mpls.0
Propósito

Exibir informações da tabela de rota mpls.0.

Ação

No dispositivo R1, a partir do modo operacional, execute o comando para exibir informações da tabela de roteamento show route table mpls.0 mpls.0.

Significado

A saída mostra as informações da tabela de rota mpls.0.

Verificar as entradas de roteamento na Tabela inet.3
Propósito

Exibir informações da tabela de rotas do inet.3.

Ação

No dispositivo R1, a partir do modo operacional, execute o comando para exibir informações da tabela de roteamento show route table inet.3 inet.3.

Significado

A saída mostra as informações da tabela de rota inet.3.

Verificar as entradas de roteamento na Tabela inet6.3
Propósito

Exibir informações da tabela de rotas do inet6.3.

Ação

No dispositivo R1, a partir do modo operacional, execute o comando para exibir informações da tabela de roteamento show route table inet6.3 inet6.3.

Significado

A saída mostra as informações da tabela de rota inet6.3.

Verificação do banco de dados LDP
Propósito

Exibir as informações do banco de dados LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute o comando para exibir informações do banco show ldp database de dados LDP.

Significado

A saída mostra as entradas no banco de dados LDP.

Verificação das informações do vizinho LDP
Propósito

Exibir as informações do vizinho LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute os comandos e os show ldp neighbor comandos para exibir informações do vizinho show ldp neighbor extensive LDP.

Significado

A saída mostra informações de vizinho LDP de endereços IPv4 e IPv6.

Verificação das informações de sessão LDP
Propósito

Exibir as informações da sessão LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute os comandos e os show ldp session comandos para exibir informações de sessão show ldp session extensive LDP.

Significado

A saída exibe informações para a sessão LDP usando IPv6 como transporte TCP.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação das informações do vizinho LDP
Propósito

Exibir as informações do vizinho LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute o show ldp neighbor extensive comando para exibir informações do vizinho LDP.

Significado

A saída mostra informações de vizinho LDP para os endereços IPv4 e IPv6.

Verificação das informações de sessão LDP
Propósito

Exibir as informações da sessão LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute o show ldp session extensive comando para exibir informações de sessão LDP.

Significado

A saída exibe informações para a sessão LDP usando IPv6 como transporte TCP.

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação das informações do vizinho LDP
Propósito

Exibir as informações do vizinho LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute o show ldp neighbor extensive comando para exibir informações do vizinho LDP.

Significado

A saída mostra informações de vizinho LDP para os endereços IPv4 e IPv6.

Verificação das informações de sessão LDP
Propósito

Exibir as informações da sessão LDP.

Ação

No dispositivo R1, a partir do modo operacional, execute o show ldp session extensive comando para exibir informações do vizinho LDP.

Exemplo: Configuração da sinalização in band de LDP multipoint para LSPs point-to-multipoint

Entender a sinalização de inband de LDP multipoint para LSPs point-to-multipoint

O Protocolo de Distribuição de Rótulos multipoint (M-LDP) para caminhos comutado de rótulos (LSPs) ponto a multipoint com sinalização em banda é útil em uma implantação com uma backbone de IP/MPLS existente, na qual você precisa transportar tráfego multicast, por exemplo, para IPTV.

Por anos, a solução mais usada para transportar tráfego multicast tem sido o uso de multicast IP nativo no núcleo do provedor de serviços com tunelamento de IP multipoint para isolar o tráfego do cliente. Um protocolo de roteamento multicast, normalmente PIM (Protocol Independent Multicast), é implantado para configurar os caminhos de encaminhamento. O roteamento ip multicast é usado para encaminhamento, usando a sinalização de PIM no núcleo. Para que esse modelo funcione, a rede de núcleo precisa ser habilitada para multicast. Isso permite implantações eficazes e estáveis, mesmo em cenários de sistema inter-autônomo (AS).

Entretanto, em uma rede de IP/MPLS existente, a implantação de PIM pode não ser a primeira opção. Alguns provedores de serviços estão interessados em substituir o tunelamento ip por MPLS encapsulamento de rótulos. As motivações para passar para MPLS de rótulos é utilizar recursos de engenharia de tráfego de MPLS e proteção e reduzir a sobrecarga de tráfego de controle no núcleo do provedor.

Para isso, os provedores de serviços estão interessados em aproveitar a extensão das implantações existentes para permitir a passagem do tráfego multicast. As extensões multicast existentes para IP/MPLS são extensões ponto a multipoint para RSVP-TE e extensões ponto a multipoint e multipoint para LDP. Esses cenários de implantação são discutidos em RFC 6826, Sinalização in-Band de LDP multipointpara caminhos comutado de rótulos de ponto para multipoint e multipoint para multipoint. Essa visão geral do recurso se limita a extensões ponto a multipoint para LDP.

Como o M-LDP funciona

Encadernações de rótulos na sinalização de M-LDP

A extensão de multipoint para LDP usa elementos da classe de equivalência de encaminhamento de multipoint para multipoint (FEC) (definidos em RFC 5036, Especificação LDP)juntamente com anúncios de capacidade, mapeamento de rótulos e procedimentos de sinalização. Os elementos FEC incluem a ideia da raiz LSP, que é um endereço IP, e um valor "opaco", um seletor que reúne os nós de folha que compartilham o mesmo valor opaco. O valor opaco é transparente para os nós intermediários, mas tem significado para a raiz LSP. Cada nó LDP anuncia sua vinculação de rótulo local de entrada ao nó LDP upstream no caminho mais curto até o endereço IP raiz encontrado no FEC. O nó upstream que recebe as ligações de rótulo cria seu próprio rótulo local e interfaces de saída. Esse processo de alocação de rótulos pode resultar na replicação de pacotes, caso haja várias filiais de saída. Como mostrado em , um nó LDP mescla as vinculações de rótulos pelo mesmo valor opaco se ele encontrar nós downstream compartilhando o mesmo nó Figura 18 upstream. Isso permite a criação eficaz de LSPs point-to-multipoint e conservação de rótulos.

Figura 18: Encadernações de rótulos na sinalização de M-LDPEncadernações de rótulos na sinalização de M-LDP
M-LDP no núcleo de MPLS PIM

Figura 19 mostra um cenário de implantação escalonado. Dois domínios de PIM separados são interconectados por um site de núcleo sem PIM. Os roteadores de borda deste site de núcleo suportam PIM nas interfaces de borda. Além disso, esses roteadores de borda coletam e distribuem as informações de roteamento dos locais adjacentes à rede principal. Os roteadores de borda no site C são executados BGP para descoberta de nós raiz. As rotas do protocolo de gateway interior (IGP) não podem ser usadas para descoberta de ingresso, porque, na maioria dos casos, o próximo salto de encaminhamento fornecido pela IGP não forneceria informações sobre o dispositivo de ingresso em direção à origem. A sinalização de banda de inband M-LDP tem um mapeamento de um para um entre o LSP ponto a multipoint e o fluxo (S,G). Com a sinalização na banda, as mensagens de PIM são diretamente traduzidas para as vinculações FEC M-LDP. Em comparação, a sinalização fora da banda é baseada na configuração manual. Uma aplicação para sinalização de inband M-LDP é transportar tráfego multicast IPTV em uma base MPLS backbone.

Figura 19: Topologia de M-LDP amostra em núcleo de MPLS PIMTopologia de M-LDP amostra em núcleo de MPLS PIM
Configuração

A mldp-inband-signalling instrução de configuração do roteador de borda de rótulo (LER) permite que o PIM use sinalização em banda M-LDP para os vizinhos upstream quando o LER não detectar um vizinho upstream PIM. A configuração estática da raiz MPLS LSP está incluída na configuração PIM, usando a política. Isso é necessário quando o IBGP não está disponível no site de núcleo ou para substituir a detecção de raiz LSP baseada em IBGP.

Por exemplo:

M-LDP no núcleo MPLS PIM

A partir da versão 14.1 do Junos OS, para migrar os serviços de IPTV existentes do multicast IP nativo para MPLS multicast, você precisa fazer uma transição tranquila de PIM para LSPs de ponto para multipoint M-LDP com interrupção mínima. Figura 20 apresenta uma topologia M-LDP Figura 19 semelhante, mas com um cenário diferente. O núcleo é ativado com PIM, com uma única fonte transmitindo todos os canais de IPTV. Os canais de TV são enviados como streams de ASM a cada canal identificado por seu endereço de grupo. Anteriormente, esses canais eram transmitidos no núcleo como streams de IP e sinalização por meio de PIM.

Figura 20: Topologia M-LDP amostral em núcleo MPLS PIMTopologia M-LDP amostral em núcleo MPLS PIM

Ao configurar o cenário neste cenário, a sinalização M-LDP só é iniciada quando não há nenhum vizinho mldp-inband-signaling PIM em direção à origem. Entretanto, como sempre existe um vizinho PIM em direção à origem, a menos que o PIM seja ativado nas interfaces upstream do PE de saída, o PIM tem precedência sobre M-LDP e O M-LDP não faz efeito.

Configuração

Para migrar gradualmente canal por canal para núcleo M-LDP MPLS com poucos streams usando upstream M-LDP e outros streams usando upstream PIM existente, inclua a instrução de configuração junto com filtros baseados em grupo no filtro de política para sinalização de banda selected-mldp-egress M-LDP.

Nota:

O filtro de política de sinalização de inband M-LDP pode incluir a instrução ou a declaração source-address-filter ou uma combinação de route-filter ambos.

Por exemplo:

Nota:

Algumas das limitações da configuração acima são as seguinte:

  • A selected-mldp-egress instrução deve ser configurada apenas no LER. Configurar a instrução em roteadores PIM não de saída pode causar falhas selected-mldp-egress na configuração do caminho.

  • Quando são feitas alterações de política para mudar o tráfego de PIM upstream para M-LDP upstream e vice-versa, a perda de pacotes pode ser esperada conforme o mecanismo de break-and-make é executado no plano de controle.

Terminologia

Os termos a seguir são importantes para uma compreensão da sinalização em banda de M-LDP para tráfego multicast.

LSP ponto a ponto

Um LSP que tenha um roteador comutado de rótulos (LSR) de entrada e um de saída LSR.

Multipoint LSP

Um LSP ponto-a-multipoint ou um LSP multipoint para multipoint.

LSP ponto a multipoint

Um LSP que tenha uma entrada LSR e um ou mais LSRs de saída.

Multipoint-to-point LSP

Um LSP que tenha uma ou mais LSRs de entrada e uma saída única LSR.

LSP multipoint para multipoint

Um LSP que conecta um conjunto de nós, de maneira que o tráfego enviado por qualquer nó no LSP seja entregue a todos os outros.

Entrada LSR

Uma entrada LSR um LSP específico é uma LSR que pode enviar um pacote de dados ao longo do LSP. LSPs multipoint para multipoint podem ter vários LSRs de entrada. LSPs ponto a multipoint têm apenas um, e esse nó costuma ser chamado de nó raiz.

Saída LSR

Uma saída para LSR LSP em especial é uma LSR que pode remover um pacote de dados desse LSP para posterior processamento. LSPs ponto a ponto e multipoint-to-point têm apenas um único nó de saída. LSPs de ponto para multipoint e multipoint para multipoint podem ter vários nós de saída.

Trânsito LSR

Uma LSR que tenha alcance até a raiz do LSP multipoint por meio de um LSR upstream diretamente conectado e um ou mais LSRs conectados diretamente ao downstream.

Bud LSR

Uma LSR que é uma saída, mas também tem um ou mais LSRs conectados diretamente ao downstream.

nó Leaf

Seja uma saída ou um LSR no contexto de um LSP point-to-multipoint. No contexto de um LSP multipoint-para-multipoint, um LSR tem entrada e saída para o mesmo LSP multipoint-para-multipoint e também pode ser um botão LSR.

Ingresso na tradução e no tratamento de pseudo interface

Na LER de entrada, o LDP notifica o PIM sobre as mensagens (S,G) que são recebidas pela sinalização na banda. O PIM associa cada mensagem (S,G) com uma pseudo interface. Posteriormente, uma mensagem de junção (SPT) de árvore de caminho mais curta é iniciada em direção à origem. A PIM o trata como um novo tipo de receptor local. Quando o LSP é derrubado, o PIM remove esse receptor local com base na notificação do LDP.

Splicing de entrada

O LDP fornece PIM com um próximo hop a ser associado a cada entrada (S,G). O PIM instala uma rota multicast PIM (S,G) com o próximo hop LDP e outros receptores PIM. O próximo salto é um próximo hop composto de receptores locais + a lista de vizinhos DE PIM downstream + um salto no próximo nível para o túnel LDP.

Encaminhamento de caminho reverso

O cálculo de RPF (Reverse-Path-Forwarding, Encaminhamento de caminho reverso) do PIM é realizado no nó de saída.

O PIM realiza sinalização M-LDP na banda quando todas as condições a seguir são verdadeiras:

  • Não há vizinhos pim em direção à origem.

  • A instrução de sinalização em banda M-LDP está configurada.

  • O próximo hop é BGP, ou está presente no mapeamento estático (especificado em uma política de sinalização em banda M-LDP).

Caso contrário, se a detecção de raiz LSP falhar, o PIM manterá a entrada (S,G) com um estado RPF não resolvido.

O PIM RPF registra esse endereço de origem sempre que as informações de roteamento unicast mudam. Portanto, se a rota em direção à origem mudar, o recálculo do RPF recorre. BGP o protocolo seguinte saltos em direção à origem também são monitorados para alterações na raiz LSP. Essas alterações podem causar interrupções no tráfego por durações curtas.

Detecção raiz de LSP

Se a operação RPF detectar a necessidade de sinalização upstream em banda do M-LDP, a raiz LSP (ingresso) será detectada. Essa raiz é um parâmetro para sinalização LDP LSP.

O nó raiz é detectado da seguinte forma:

  1. Se a configuração estática existente especificar o endereço de origem, a raiz será tomada como dada na configuração.

  2. Uma olhada é realizada na tabela de roteamento unicast. Se o endereço de origem for encontrado, o próximo salto do protocolo em direção à origem é usado como a raiz LSP.

    Antes da Versão 16.1 do Junos OS, o LSP ponto a multipoint M-LDP é sinalizado de uma saída para a entrada usando o endereço raiz da entrada LSR. Esse endereço raiz só pode ser IGP, limitando o LSP ponto a multipoint M-LDP a um único sistema autônomo. Se o endereço raiz não for alcançável por meio de um IGP, mas alcançável por meio de BGP, e se essa rota BGP for recursivamente solucionada por um LSP MPLS, o LSP ponto a multipoint não será sinalizado mais adiante desse ponto em direção à entrada LSR endereço raiz.

    Existe a necessidade de sinalização desses LSPs não segmentados ponto a multipoint em vários sistemas autônomos, que podem ser usados para as seguintes aplicações:

    • MVPN inter-AS com LSPs não segmentados point-to-multipoint.

    • Sinalização de inband inter-AS M-LDP entre as redes do cliente conectadas por uma MPLS de núcleo.

    • Sinalização de inband MVPN ou M-LDP entre áreas com LSPs não segmentados ponto a multipoint (sem interrupções MPLS multicast).

    A partir da versão 16.1 do Junos OS, o M-LDP pode sinalizar LSPs ponto a multipoint no ASBR ou transitar ou saída quando o endereço raiz é uma rota BGP que é recursivamente solucionada por um LSP MPLS de segurança.

Saída junte-se à tradução e ao tratamento de pseudo interface

Na LER de saída, o PIM notifica lDP da mensagem (S,G) a ser sinalizada junto com a raiz LSP. O PIM cria uma pseudo interface como a interface upstream para esta mensagem (S,G). Quando uma mensagem de podada (S,G) é recebida, essa associação é removida.

Splicing de saída

No nó de saída da rede de núcleo, onde a mensagem (S,G) de junção do site downstream é recebida, essa mensagem de junção é traduzida para parâmetros de sinalização em banda M-LDP e LDP é notificada. Além disso, o rebaixamento do LSP ocorre quando a entrada (S,G) é perdida, quando a raiz do LSP muda ou quando a entrada (S,G) pode ser alcançada por um vizinho PIM.

Funcionalidade suportada

Para a sinalização em banda de M-LDP, o Junos OS tem suporte para as seguintes funcionalidades:

  • Splicing de saída do PIM no próximo hop com a rota LDP

  • Splicing de entrada da rota DO PIM com o próximo hop LDP

  • Tradução de PIM juntar mensagens para parâmetros de configuração LSP ponto a multipoint LDP

  • Tradução de parâmetros LSP in-band M-LDP para configurar mensagens de junção de PIM

  • Protocolo de configuração estática e BGP próxima detecção raiz LSP baseada em hop

  • PIM (S,G) estados nos intervalos de multicast específico de origem (SSM) e multicsast de qualquer fonte (ASM)

  • Declarações de configuração de LERs de entrada e saída para permitir que elas atuem como roteadores de borda

  • IGMP une mensagens em LERs

  • Transporte de endereço de origem e grupo IPv6 como informações opacas em direção a um nó raiz IPv4

  • Configuração estática para mapear um IPv6 (S,G) para um endereço raiz IPv4

Funcionalidade não compatível

Para a sinalização em banda de M-LDP, o Junos OS não tem suporte para as seguintes funcionalidades:

  • Suporte total para PIM ASM

  • O mpls lsp point-to-multipoint ping comando com uma opção (S,G)

  • Roteamento ativo sem parar (NSR)

  • Make-before-break (MBB) para PIM

  • Endereços raiz LSP IPv6 (LDP não tem suporte para LSPs IPv6.)

  • Relacionamento com os vizinhos entre alto-falantes PIM que não estão conectados diretamente

  • Reinicialização graciosa

  • modo denso PIM

  • modo bidirecional PIM

Funcionalidade LDP

As informações de PIM (S,G) são transportdas como codificações de valor de comprimento (TLV) opacas do tipo M-LDP. O elemento FEC ponto a multipoint consiste no endereço do nó raiz. No caso das VPNs multicast de última geração (NGEN MVPNs), o LSP ponto a multipoint é identificado pelo endereço de nó raiz e pela ID LSP.

Funcionalidade de SAÍDA LER

Na LER de saída, o PIM aciona o LDP com as seguintes informações para criar um LSP ponto a multipoint:

  • Nó raiz

  • (S,G)

  • Próximo hop

O PIM encontra o nó raiz com base na origem da árvore multicast. Se o endereço raiz estiver configurado para essa entrada (S,G), o endereço configurado será usado como a raiz LSP ponto-a-multipoint. Caso contrário, a tabela de roteamento é usada para procurar a rota até a origem. Se a rota para a origem da árvore multicast for uma rota BGP aprendida, o PIM recupera o endereço de hop do BGP seguinte e o usa como o nó raiz do LSP ponto-a-multipoint.

O LDP encontra o nó upstream com base no nó raiz, aloca um rótulo e envia o mapeamento de rótulos para o nó upstream. O LDP não usa penúltimo hop popping (PHP) para sinalização M-LDP na banda.

Se os endereços raiz da origem da árvore multicast mudarem, o PIM excluirá o LSP ponto a multipoint e aciona o LDP para criar um novo LSP ponto a multipoint. Quando isso acontece, a lista de interface de saída torna-se NULA, o PIM aciona o LDP para excluir o LSP ponto a multipoint, e o LDP envia uma mensagem de saída do rótulo para o nó upstream.

Funcionalidade de LSR de trânsito

O departamento de LSR anuncia um rótulo para o upstream LSR em direção à origem do FEC ponto-a-multipoint e instala o estado de encaminhamento necessário para encaminhamento dos pacotes. A segurança LSR pode ser qualquer roteador capaz de M-LDP.

Funcionalidade de LER de entrada

Na LER de entrada, o LDP fornece as seguintes informações ao PIM ao receber o mapeamento de rótulos:

  • (S,G)

  • Flood next hop

Em seguida, o PIM instala o estado de encaminhamento. Caso as novas filiais sejam adicionadas ou eliminadas, o próximo salto será atualizado de acordo. Caso todas as filiais sejam excluídos devido a uma exclusão de um rótulo, o LDP enviará informações atualizadas para o PIM. Se houver vários links entre os vizinhos upstream e downstream, o LSP ponto a multipoint não será balanceado.

Exemplo: Configuração da sinalização in band de LDP multipoint para LSPs point-to-multipoint

Este exemplo mostra como configurar a sinalização em banda de LDP (M-LDP) multipoint para tráfego multicast, como uma extensão ao protocolo PiM (Protocol Independent Multicast) ou como um substituto do PIM.

Requisitos

Este exemplo pode ser configurado usando os seguintes componentes de hardware e software:

  • Junos OS Release 13.2 ou mais tarde

  • Roteadores de borda multisserviços da Série MX Plataformas de roteamento universal ou Série M para roteadores de borda do provedor (PE)

  • A série PTX Roteadores de transporte de pacotes como roteadores comutado por rótulos de trânsito

  • Série T roteadores centrais para roteadores de núcleo

Nota:

Os roteadores PE também podem ser Série T roteadores de núcleo, mas isso não é típico. Dependendo de seus requisitos de dimensionamento, os roteadores de núcleo também podem ser roteadores de borda 5G da Série MX Plataformas de roteamento universal ou Série M Multisserviço. Os dispositivos de borda do cliente (CE) podem ser outros roteadores ou switches da Juniper Networks ou de outro fornecedor.

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Configuração rápida CLI mostra a configuração de todos os dispositivos em Figura 21 . A seção #d158e60__d158e615 descreve as etapas do Device EgressPE.

Figura 21: Sinalização in band M-LDP para topologia de exemplo de LSPs point-to-multipointSinalização in band M-LDP para topologia de exemplo de LSPs point-to-multipoint

Configuração

Procedimento
Configuração rápida CLI

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

Src1 de dispositivos

IngressPE de dispositivos

EgressPE de dispositivo

Dispositivo p6

Dispositivo pr3

Dispositivo pr4

Dispositivo pr5

Procedimento passo a passo

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

Para configurar o EgressPE do dispositivo:

  1. Configure as interfaces.

    Ative MPLS nas interfaces voltadas para núcleo. No próximo salto de saída, você não precisa habilitar a MPLS.

  2. Configure o IGMP nas interfaces de saída.

    Para fins de teste, este exemplo inclui endereços de grupo estático e de origem.

  3. Configure MPLS nas interfaces voltadas para núcleo.

  4. Configure BGP.

    BGP é um protocolo orientado a políticas, por isso configure e aplique todas as políticas de roteamento necessárias.

    Por exemplo, você pode querer exportar rotas estáticas para BGP.

  5. (Opcional) Configure uma conexão de peer MSDP com o Dispositivo pr5 para interconectar os domínios PIM diferentes, permitindo RPs redundantes.

  6. Configure OSPF.

  7. Configure LDP nas interfaces voltadas para núcleo e na interface de loopback.

  8. Habilitar LSPs ponto a MPLS multipoint.

  9. Configure o PIM nas interfaces downstream.

  10. Configure as configurações de RP porque esse dispositivo funciona como o ponto de encontro PIM (RP).

  11. Habilitar a sinalização em banda do M-LDP e definir a política associada.

  12. Configure a política de roteamento que especifica o endereço raiz para os endereços de Origem point-to-multipoint e os endereços de origem associados.

  13. Configure o ID do sistema autônomo (AS).

Resultados

A partir do modo de configuração, confirme sua configuração show interfaces inserindo os show protocols comandos , e show policy-options . show routing-options Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

EgressPE de dispositivo

Da mesma forma, configure os outros dispositivos de saída.

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

Verificação

Confirmar se a configuração está funcionando corretamente.

Verificação dos estados de junção do PIM
Propósito

Exibir informações sobre o PIM juntam-se aos estados para verificar os detalhes do upstream e downstream em banda do M-LDP. No dispositivo de entrada, o show pim join extensive comando é exibido na interface Pseudo-MLDP downstream. Na saída, o comando é show pim join extensive exibido para a interface Pseudo-MLDP upstream.

Ação

Do modo operacional, insira o show pim join extensive comando.

Verificação das fontes de PIM
Propósito

Verificar se as fontes PIM têm os detalhes esperados de upstream e downstream em M-LDP.

Ação

Do modo operacional, insira o show pim source comando.

Verificação do banco de dados LDP
Propósito

Certifique-se de que o comando exibe as ligações show ldp database esperadas de raiz para(S,G).

Ação
Procurar as informações de rotear para o rótulo MPLS de segurança
Propósito

Exibir as informações de FEC point-to-multipoint.

Ação
Verificação das estatísticas de tráfego LDP
Propósito

Monitore as estatísticas de tráfego de dados para LSP point-to-multipoint.

Ação

Servidor de mapeamento de LDP para interoperabilidade do roteamento por segmentos com visão geral do LDP

Em uma rede LDP com implantação gradual de roteamento por segmentos, pode haver ilhas de dispositivos que suportam apenas LDP ou apenas roteamento por segmentos. Para que os dispositivos intertrabalham, o recurso do servidor de mapeamento LDP precisa ser configurado em qualquer dispositivo na rede de roteamento por segmentos.

O recurso do servidor de mapeamento LDP é implementado usando-se OSPF ou ISIS.

Interoperabilidade do roteamento por segmentos com LDP usando OSPF

Para implementar interoperabilidade do roteamento por segmentos com LDP usando OSPF, um anúncio de estado de enlace de prefixo estendido (LSA) com tipo de intervalo, comprimento e valor (TLV) para todos os prefixos LDP é gerado, e as rotas de mapeamento correspondentes ao prefixo são instaladas nas tabelas de roteamento inet.3 e mpls.0.

Figura 22 é uma topologia de rede LDP simples usada para ilustrar a interoperabilidade de dispositivos de roteamento por segmentos com dispositivos LDP que usam OSPF. A topologia tem seis dispositivos (dispositivos R1, R2, R3, R4, R5 e R6) com migração de roteamento LDP para segmentos.

Figura 22: Amostra de topologia de LDP com interoperabilidade do roteamento por segmentos com LDP usando OSPFAmostra de topologia de LDP com interoperabilidade do roteamento por segmentos com LDP usando OSPF

Na topologia acima, os dispositivos R1, R2 e R3 são capazes de apenas roteamento por segmentos, os dispositivos R5 e R6 são capazes apenas de LDP, e o dispositivo R4 aceita ODP e o roteamento por segmentos. Aqui, o dispositivo R1 não pode trabalhar com o dispositivo R6 por causa de problemas de interoperabilidade.

Para habilitar a interoperabilidade entre os dispositivos com capacidade de LDP e os dispositivos de roteamento por segmentos, qualquer interface do dispositivo no segmento de rede de roteamento por segmentos está configurada como o servidor de mapeamento LDP. No momento, o servidor de mapeamento configura prefixos em nível [edit routing-options source-packet-routing] de hierarquia. Com esse recurso, a configuração do servidor de mapeamento LDP se aplicada no nível da hierarquia, onde um novo prefixo estendido LSA com intervalo TLV para todos os prefixos LDP é anunciado por [edit protocols ospf] OSPF. O dispositivo capaz de roteamento por segmentos analisar o intervalo de prefixo estendido TLV e as rotas de mapeamento correspondentes ao prefixo estão instaladas nas tabelas de roteamento inet.3 e mpls.0.

Por exemplo, se o dispositivo R2 (na rede de roteamento por segmentos) for o servidor de mapeamento Figura 22 LDP, a seguinte configuração está incluída:

Nota:

O endereço IP usado como o endereço de loopback do dispositivo na rede start-prefix LDP (Dispositivo R5, neste exemplo).

Quando a configuração do servidor de mapeamento LDP está comprometida no dispositivo R2, o intervalo de prefixo estendido TLV é inundado pela área OSPF de segurança. Os dispositivos capazes de roteamento por segmentos (dispositivos R1, R2 e R3) instalam OSPF roteamento por segmentos para o endereço de loopback especificado com um índice de ID (SID) do segmento. O índice SID também é atualizado na tabela de roteamento mpls.0 pelos dispositivos de roteamento por segmentos.

A partir do Junos OS Release 19.1R1, o roteador de borda por segmentos roteamento-LDP pode costurar o tráfego de roteamento por segmentos até LDP no next-hop e vice-versa.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF

  • O conflito de prefixo só é detectado na configuração de origem. Quando há um conflito de intervalo de prefixo, prevalece o SID de prefixo da ID do roteador inferior. Nesses casos, é gerada uma mensagem de erro no log RPD_OSPF_PFX_SID_RANGE_CONFLICT do sistema.

  • Os prefixos IPv6 não são suportados.

  • Não há suporte para inundações do OSPF Extended Prefix Opaque LSA gerada pelo servidor de mapeamento do roteamento por segmentos para sistemas autônomos (ASs).

  • O servidor de mapeamento LDP entre áreas não é suportado.

  • A funcionalidade ABR do Extended Prefix Opaque LSA não é suportada.

  • A funcionalidade ASBR do Extended Prefix Opaque LSA não é suportada.

  • O servidor de preferência do mapeamento do roteamento por segmentos não tem suporte.

Interoperabilidade do roteamento por segmentos com LDP usando ISIS

Para implementar interoperabilidade do roteamento por segmentos com LDP usando ISIS, é necessária uma configuração servidor-cliente nos protocolos ISIS e LDP, respectivamente, e as rotas das tabelas de roteamento inet.3 ou inet.0 são usadas para a costura de LSP do roteamento por segmentos com um LDP LSP e vice-versa.

Figura 23 é uma topologia de rede LDP simples usada para ilustrar a interoperabilidade de dispositivos de roteamento por segmentos com dispositivos LDP usando um recurso de servidor-cliente de mapeamento LDP. A topologia tem quatro dispositivos de borda do provedor (Dispositivos PE1, PE2, PE3 e PE4) e quatro dispositivos de provedor (P) (Dispositivos P5, P6, P7 e P8).

Figura 23: Amostra de topologia de LDP com interoperabilidade do roteamento por segmentos com LDP usando ISISAmostra de topologia de LDP com interoperabilidade do roteamento por segmentos com LDP usando ISIS

Os dispositivos PE3, PE4, P6, P7 e P8 são os dispositivos capazes de LDP. Os dispositivos PE1, PE2, P5 e P6 são capazes de roteamento por segmentos com valor global de bloco de roteamento por segmentos (SRGB) de 100 e 200, e IDs por segmentos de nó (SIDs) de 101, 102.105 e 106, respectivamente.

Para que um fluxo de serviço seja tunelado para e para o dispositivo PE3 e o Dispositivo PE1 usando um túnel MPLS contínuo, as ilhas de dispositivos que suportam o roteamento por segmentos e o LDP devem interoperar.

LDP Mapping Client Functionality (LDP to Segment Routing)

A funcionalidade do cliente LDP é o mapeamento do roteamento LDP para segmentos, que é o fluxo de tráfego da direita para a esquerda Figura 23 em . No dispositivo P6, uma política de saída do LDP está configurada para anunciar todos os SIDs de nós e SIDs de prefixo da rede de roteamento por segmentos à esquerda. Como resultado, no dispositivo P6, o LDP anuncia os dispositivos PE1, PE2 e P5 como as ligações de rótulos FEC de saída ao dispositivo P7.

O Dispositivo PE3 aprenderam uma rota de serviço com o Device PE1 como o próximo salto do protocolo. O Device PE3 tem uma encadernação de rótulos LDP do próximo hop do P8 para o PE1 FEC. Como resultado, o Dispositivo PE3 envia seu pacote de serviço para o dispositivo P8 de acordo com o comportamento LDP clássico. O Device P8 tem uma encadernação de rótuloS LDP de seu próximo hop P7 para PE1 FEC, portanto, o dispositivo P8 encaminha o dispositivo P7 de acordo com o comportamento LDP clássico.

O Dispositivo P7 tem uma encadernação de rótulos LDP de seu P6 no próximo hop, o PE1 FEC, como resultado, o dispositivo P7 encaminha o dispositivo P6 de acordo com o comportamento LDP clássico.

Device P6that está atuando como uma saída LDP para o PE1 FEC, pontos e troca o rótulo LDP de saída para o PE1 FEC por um nó de roteamento por segmentos equivalente (101 neste exemplo) para encaminhamento do tráfego para o dispositivo P5.

O dispositivo P5 pops 101 SID, assumindo que o Dispositivo PE1 divulgou seu segmento de nó 101 com o penúltimo conjunto de bandeiras pop e, em seguida, encaminha o tráfego para o Dispositivo PE1. O dispositivo PE1 recupera o pacote em túnel e processa o rótulo de serviço.

Como resultado, o túnel de MPLS de ponta a ponta é construído a partir de um LDP LSP do dispositivo PE3 ao dispositivo P6, e do segmento de nó relacionado do dispositivo P6 ao dispositivo PE1.

LDP Mapping Server Functionality (Segment Routing to LDP)

A funcionalidade do servidor LDP é o mapeamento do roteamento por segmentos para LDP, que é o fluxo de tráfego da esquerda para a Figura 23 direita. No dispositivo P6, a configuração dos prefixos do servidor de mapeamento está incluída no nível [edit routing-options source-packet-routing] da hierarquia. Quando a configuração é aplicada sob a IGP específica, o tipo, o comprimento e o valor (TLV) de rótulos de LDP são anunciados como rotas LDP.3.

Aqui, o Dispositivo P6 funciona como um Servidor de Mapeamento de Roteamento por segmentos (SRMS) e anuncia os seguintes mapeamentos – (P7, 107), (P8, 108), (PE3, 103), (PE4, 104) e (P7, 107). Se o roteamento por segmentos fosse suportado no Dispositivo PE3, o nó SID 103 estaria configurado no Dispositivo PE3. Como o Dispositivo PE3 não tem suporte para o roteamento por segmentos, a política está configurada no SRMS no dispositivo P6, e o dispositivo P6 é responsável por anunciar os mapeamentos.

Esses anúncios de servidor de mapeamento só são compreendidos pelos dispositivos de roteamento por segmentos. Os dispositivos de roteamento por segmentos instalam os SIDs de nós relacionados no MPLS de dados exatamente como os segmentos de nó foram anunciados pelos próprios nós. Por exemplo, o Device PE1 instala o nó SID 103 com P5 next hop exatamente como se o Dispositivo PE3 tivesse anunciado SID 103.

O Device PE1 tem uma rota de serviço com PE3 como protocolo no próximo salto. O Device PE1 tem um segmento de nó para essa IGP de rotear – 103 com P5 no próximo salto. Como resultado, o Dispositivo PE1 envia seu pacote de serviço para o dispositivo P5 com dois rótulos: o rótulo inferior, que é o rótulo de serviço, e o rótulo superior, que é SID 103. O dispositivo P5 troca 103 por 103 e encaminha para o dispositivo P6. O next-hop para Device P6 é a IGP PE3, que não é capaz de roteamento por segmentos. (O dispositivo P7 não anuncia o recurso de roteamento por segmentos). Entretanto, o Device P6 tem uma encadernação de rótulos LDP a partir desse próximo hop para o mesmo FEC (por exemplo, rótulo LDP 1037). Como resultado, no dispositivo P6, o IGP troca 103 por 1037 e encaminha para o dispositivo P7.

O dispositivo P7 troca esse rótulo pelo rótulo LDP recebido do dispositivo P8 e depois o encaminha ao dispositivo P8. O rótulo LDP é preso pelo dispositivo P8 e encaminhado ao dispositivo PE3.

O dispositivo PE3 recebe o pacote em túnel e processa o rótulo de serviço. O túnel de MPLS de ponta a ponta é construído a partir de um nó de roteamento por segmentos dos dispositivos PE1 até P6, e de um LDP LSP dos dispositivos P6 até PE3.

Segment Routing to LDP Stitching

Quando o ip do IGP de roteamento por segmentos LSP não dá suporte ao roteamento por segmentos, a IGP olha para a tabela de roteamento inet.3 para ver se existe um LDP LSP com o mesmo prefixo. Se o LDP LSP estiver presente, a IGP o LSP do roteamento por segmentos até o LDP LSP programando uma rota de trânsito MPLS que troca o rótulo de roteamento por segmentos pelo rótulo LDP para mudar o tráfego do domínio do roteamento por segmentos para o domínio LDP.

Figura 24 ilustra a costura do roteamento por segmentos e LSPs LDP para permitir interoperabilidade.

Figura 24: Roteamento por segmentos de costura e LSPs LDPRoteamento por segmentos de costura e LSPs LDP

Na topologia, o Device PE3 é capaz de LDP e não tem suporte para o roteamento por segmentos. O servidor de mapeamento no domínio do roteamento por segmentos pode anunciar TLV de encadernação de rótulos para dispositivos P7, P8 e PE4. Nesse cenário, o Dispositivo PE1 pode ter TLV e SID de encadernação de rótulos remotos e SID de prefixo para chegar ao Dispositivo PE4. Entretanto, o Dispositivo PE1 prefere o prefixo SID ao TLV de encadernação de rótulos remotos ao mesmo tempo em que programa sua rota de roteamento por segmentos de entrada para o Dispositivo PE4. Como resultado, o Dispositivo PE1 usa o roteamento por segmentos LSP de ponta a ponta para enviar tráfego para o dispositivo PE4 e usa a costura de roteamento por segmentos para LDP ao enviar tráfego para o Dispositivo PE3.

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • O comportamento penultimate-hop popping para TLV de encadernação de rótulos não é suportado.

  • Não há suporte para anúncios de diversos prefixos em TLV de encadernação de rótulos.

  • A Resolução de conflito do roteamento por segmentos não é suportada.

  • As estatísticas de tráfego LDP não funcionam.

  • O roteamento ativo sem parar (NSR) e Mecanismo de Roteamento comutador de Mecanismo de Roteamento (GRES) não são suportados.

  • O nível inter-ISIS não é suportado.

  • RFC 7794, IS-IS atributos de prefixo para IPv4 estendido não é suportado.

  • Não é suportado redistribuir a rota LDP como um sid de prefixo no nó de costura.

Configuração de propriedades LDP diversas

As seções a seguir descrevem como configurar várias propriedades LDP diversas:

Configurando LDP para usar a métrica IGP roteamento

Use a instrução se você quiser que a métrica de rotear do protocolo de gateway interior (IGP) seja usada para as rotas LDP, em vez da métrica de rota LDP padrão (a métrica de rota LDP padrão track-igp-metric é 1).

Para usar a métrica IGP de rotear, inclua a track-igp-metric declaração:

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

Impedir a inclusão de rotas de ingresso na tabela de roteamento inet.0

Ao configurar a instrução, você pode impedir que rotas de entrada possam ser adicionadas à tabela de roteamento inet.0 em vez da tabela de roteamento inet.3, mesmo se você habilitar a instrução no nível ou na no-forwardingtraffic-engineering bgp-igp[edit protocols mpls][edit logical-systems logical-system-name protocols mpls] hierarquia. Por padrão, a no-forwarding instrução está desabilitada.

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

Para omitir rotas de entrada da tabela de roteamento inet.0, inclua a no-forwarding declaração:

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

VPNs de LDP de várias instâncias e operadoras

Ao configurar várias instâncias de roteamento LDP, você pode usar LDP para anunciar rótulos em uma VPN de operadora de operadora de serviços de um roteador de borda do provedor de serviços (PE) até um roteador de borda do cliente da operadora do cliente (CE). Isso é especialmente útil quando o cliente da operadora é um provedor de serviços de Internet (ISP) básico e deseja restringir rotas de Internet completas a seus roteadores PE. Ao usar lDP em vez de BGP, o cliente da operadora protege seus outros roteadores internos da Internet. O LDP de várias instâncias também é útil quando um cliente de operadora deseja fornecer serviços VPN de Camada 2 ou Camada 3 para seus clientes.

Para um exemplo de como configurar várias instâncias de roteamento LDP para VPNs da operadora de operadora, consulte o Guia de usuário de protocolo de distribuição de rótulos com várias instâncias.

Configurando MPLS e LDP para pop the Label no roteador ultimate-hop

O rótulo anunciado padrão é o rótulo 3 (rótulo Implicit Null). Se o rótulo 3 for anunciado, o roteador penúltimo-hop remove o rótulo e envia o pacote para o roteador de saída. Se o ultimate-hop popping estiver ativado, o rótulo 0 (rótulo IPv4 Explicit Null) será anunciado. O ultimate-hop popping garante que todos os pacotes que atravessem uma MPLS de rede incluam um rótulo.

Para configurar o ultimate-hop popping, inclua a explicit-null declaração:

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

Nota:

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

Para obter mais informações sobre rótulos, consulte MPLS Visão geral dos rótulos e MPLS alocação de rótulos.

Ativação de LDP em LSPs estabelecidos por RSVP

Você pode executar LDP em LSPs estabelecidos por RSVP, tunelando com eficiência o LSP estabelecido por LDP por meio do estabelecido pelo RSVP. Para isso, habilita o LDP na interface lo0.0 (consulte Como ativar e desativar LDP). Você também deve configurar os LSPs nos quais deseja que o LDP opere, incluindo a ldp-tunneling instrução no nível [edit protocols mpls label-switched-path lsp-name] da hierarquia:

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

Ativação de LDP em LSPs estabelecidos por RSVP em redes heterogêneas

Alguns outros fornecedores usam uma OSPF de 1 para o endereço de loopback. Juniper Networks roteadores usam uma OSPF de 0 para o endereço de loopback. Isso pode exigir que você configure manualmente a métrica de RSVP ao implantar o túnel LDP em LSPs RSVP em redes heterogêneas.

Quando um roteador de Juniper Networks está vinculado a outro roteador por meio de um túnel RSVP, e o tunelamento de LDP também estiver ativado, por padrão o roteador de Juniper Networks pode não usar o túnel RSVP para rotear o tráfego até os destinos LDP downstream do roteador de saída do outro fornecedor se o caminho do RSVP tiver uma métrica de 1 maior que o caminho de OSPF físico.

Para garantir que o tunelamento de LDP funcione corretamente em redes heterogêneas, você pode configurar um OSPF para ignorar a métrica LSP do RSVP incluindo a ignore-lsp-metrics instrução:

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

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

Para habilitar LDP em LSPs RSVP, você também ainda precisa concluir o procedimento na Seção Ativação de LDP em LSPs estabelecidos por RSVP .

Configurando a assinatura TCP MD5 para sessões de LDP

Você pode configurar uma assinatura MD5 para uma conexão LDP TCP para se proteger contra a introdução de segmentos TCP spoofed em fluxos de conexão de sessão LDP.

Um roteador que usa a opção de assinatura MD5 está configurado com uma senha para cada peer para o qual a autenticação é necessária. A senha é armazenada criptografada.

As adjacências LDP hello ainda podem ser criadas mesmo quando interfaces de peering estão configuradas com assinaturas de segurança diferentes. No entanto, a sessão TCP não pode ser autenticada e nunca está estabelecida.

A partir da versão 16.1R1 Junos OS, o suporte ao Hashed Message Authentication Code (HMAC) e à autenticação MD5 para sessões LDP é estendido de uma configuração por sessão para uma configuração de sub-match (ou seja, mais longa combinação de prefixo).

O suporte para autenticação de subnet-match fornece flexibilidade para configurar a autenticação para sessões de LDP (TLDP) direcionadas automaticamente, facilitando a implantação de pseudowires LFA (Remote Loop-Free Alternate, alternativa sem loop remoto) e pseudowires FEC 129.

Para configurar uma assinatura MD5 para uma conexão LDP TCP, inclua session-group a e a authentication-key declaração:

Use a session-group instrução para configurar o endereço para o final remoto da sessão LDP.

A md5-authentication-key (senha) pode ter até 69 caracteres. Caracteres podem incluir quaisquer strings ASCII. Se você incluir espaços, inclua todos os caracteres entre aspas.

Você também pode configurar um mecanismo de atualização de chave de autenticação para o protocolo de roteamento LDP. Esse mecanismo permite atualizar chaves de autenticação sem interromper protocolos de roteamento e sinalização associados, como Open Shortest Path First (OSPF)(OSPF)e Protocolo de Configuração de Reserva de Recursos(RSVP).

Para configurar o mecanismo de atualização da chave de autenticação, inclua a declaração no nível da hierarquia e especifique a opção de criar um chaveiro composto por várias key-chain[edit security authentication-key-chains] chaves de key autenticação.

Para configurar o mecanismo de atualização da chave de autenticação para o protocolo de roteamento LDP, inclua a declaração no nível da hierarquia para associar o protocolo authentication-key-chain[edit protocols ldp] às chaves de [edit security authentication-key-chains] autenticação. Você também deve configurar o algoritmo de autenticação incluindo a authentication-algorithm algorithm declaração do nível da [edit protocols ldp] hierarquia.

Para obter mais informações sobre o recurso de atualização da chave de autenticação, consulte Configurar o Mecanismo de Atualização de Chaves de Autenticação para BGP e protocolos de roteamento LDP.

Configurando a proteção de sessão LDP

Normalmente, uma sessão LDP é criada entre um par de roteadores conectados por um ou mais links. Os roteadores formam uma adjacência hello para cada enlace que os conecta e associados a todas as adjacências à sessão LDP correspondente. Quando a última sessão de Adjacency de Olá para uma sessão LDP vai embora, a sessão LDP é terminada. É possível modificar esse comportamento para evitar que uma sessão de LDP seja desnecessariamente terminada e restabelecida.

Você pode configurar o Junos OS para deixar a sessão LDP entre dois roteadores em alta, mesmo se não houver adjacências hello nos links que conectam os dois roteadores configurando a session-protection declaração. Opcionalmente, você pode especificar uma hora em segundos usando a timeout opção. A sessão permanece até a duração especificada, desde que os roteadores mantenham a conectividade da rede IP.

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

Desativação de armadilhas de SNMP para LDP

Sempre que um LDP LSP faz uma transição de cima para baixo ou para cima, o roteador envia uma armadilha de SNMP. No entanto, é possível desativar as armadilhas LDP SNMP em um roteador, sistema lógico ou instância de roteamento.

Para obter informações sobre as armadilhas LDP SNMP e a propriedade LDP MIB, consulte o SNMP MIB Explorer..

Para desativar as armadilhas de SNMP para LDP, especifique trap disable a opção da log-updown instrução:

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

Configurando a sincronização de LDP com a IGP em links LDP

LDP é um protocolo para distribuição de rótulos em aplicações não projetadas por tráfego. Os rótulos são distribuídos pelo melhor caminho determinado pela IGP. Se a sincronização entre LDP e IGP não for mantida, o LSP cai. Quando o LDP não está totalmente operacional em um determinado enlace (uma sessão não está estabelecida e os rótulos não são trocados), a IGP anuncia o enlace com a métrica de custo máximo. O enlace não é preferido, mas permanece na topologia de rede.

A sincronização de LDP é suportada apenas em interfaces ativas ponto a ponto e interfaces LAN configuradas como ponto a ponto sob a IGP. A sincronização LDP não é suportada durante a reinicialização graciosa.

Para anunciar a métrica de custo máximo até o LDP estar operacional para sincronização, inclua a ldp-synchronization declaração:

Para desativar a sincronização, inclua a disable declaração. Para configurar o período de tempo para anunciar a métrica de custo máximo de um enlace que não seja totalmente operacional, inclua a hold-time declaração.

Para ver uma lista de níveis de hierarquia nos quais você pode configurar essa declaração, consulte a seção resumo de declarações para esta declaração.

Configurando a sincronização de LDP com a IGP no roteador

Você pode configurar o tempo que o LDP espera antes de informar IGP que o vizinho LDP e a sessão para uma interface estão operacionais. Para redes grandes com inúmeros FECs, talvez seja necessário configurar um valor mais longo para permitir tempo suficiente para que os bancos de dados de rótulos LDP sejam trocados.

Para configurar o tempo que o LDP espera antes de informar a IGP de que o vizinho e a sessão LDP estão operacionais, inclua a declaração e especifique um tempo em segundos para igp-synchronization a holddown-interval opção:

Para ver uma lista de níveis de hierarquia nos quais você pode configurar essa declaração, consulte a seção resumo de declarações para esta declaração.

Configurando o temporizador de retirada de rótulos

O temporizador de retirada de rótulos retarda o envio de uma mensagem de retirada de rótulos para um FEC para um vizinho. Quando um IGP link para um vizinho falha, o rótulo associado ao FEC precisa ser retirado de todos os roteadores upstream se o vizinho for o próximo hop para o FEC. Depois que IGP converge e um rótulo é recebido de um novo hop, o rótulo é readvertido para todos os roteadores upstream. Esse é o comportamento típico da rede. Ao retardar a retirada do rótulo por um pequeno período de tempo (por exemplo, até que o IGP converge e o roteador receba um novo rótulo para o FEC a partir do próximo hop downstream), a retirada do rótulo e o envio de um mapeamento de rótulos em breve podem ser evitados. A label-withdrawal-delay declaração permite configurar esse tempo de atraso. Por padrão, o atraso é de 60 segundos.

Caso o roteador receba o novo rótulo antes que o temporizador se esvae, o temporizador de retirada de rótulos é cancelado. No entanto, se o tempo acabar, o rótulo do FEC será retirado de todos os roteadores upstream.

Por padrão, o LDP espera por 60 segundos antes de retirar rótulos para evitar ressignificar LSPs várias vezes enquanto o IGP está reverregando. Para configurar o tempo de atraso da retirada do rótulo em segundos, inclua a label-withdrawal-delay declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode configurar essa declaração, consulte a seção resumo de declarações para esta declaração.

Ignorar a verificação de sub-rede LDP

Na versão 8.4 e posterior do Junos OS, uma verificação de sub-rede de endereço de origem LDP é executada durante o procedimento do estabelecimento do vizinho. O endereço de origem no pacote Hello do enlace LDP é igual ao endereço da interface. Isso causa um problema de interoperabilidade com alguns equipamentos de outros fornecedores.

Para desativar a verificação da sub-rede, inclua a allow-subnet-mismatch declaração:

Essa declaração pode ser incluída nos seguintes níveis de hierarquia:

  • [edit protocols ldp interface interface-name]

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

Nota:

Os roteadores da Série ACX não suportam [ edit logical-systems ] nível de hierarquia.

Configurando o LDP LSP Traceroute

Você pode rastrear a rota seguida por um LSP com sinal de LDP. O traceroute de LDP LSP baseia-se no RFC 4379, detectando falhas no plano de dados comutado de rótulos multi-protocolo (MPLS). Esse recurso permite rastrear periodicamente todos os caminhos em uma FEC. As informações de topologia do FEC são armazenadas em um banco de dados acessível a partir da CLI.

Uma alteração de topologia não aciona automaticamente um sinal de LDP LSP. No entanto, você pode iniciar manualmente um rastreamento. Se a solicitação de rastreamento for para uma FEC que está no banco de dados no momento, o conteúdo do banco de dados será atualizado com os resultados.

O recurso de traceroute periódico se aplica a todos os FECs especificados pela oam instrução configurada em nível [edit protocols ldp] de hierarquia. Para configurar o traceroute LDP LSP periódico, inclua a periodic-traceroute declaração:

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

Você pode configurar periodic-traceroute a declaração sozinho ou com qualquer uma das seguintes opções:

  • exp— Especifique a classe de serviço usar ao enviar testes.

  • fanout— Especifique o número máximo de saltos a seguir a ser pesquisado por nó.

  • frequency— Especifique o intervalo entre tentativas de rastreamento.

  • paths— Especifique o número máximo de caminhos a ser pesquisado.

  • retries— Especifique o número de tentativas de enviar uma sonda para um nó específico antes de desistir.

  • source— Especifique o endereço de origem IPv4 a ser usado ao enviar testes.

  • ttl— Especifique o valor máximo de tempo de vida. Nós que estão além desse valor não são localizados.

  • wait— Especifique o intervalo de espera antes de remendá-lo.

Coleta de estatísticas de LDP

As estatísticas de tráfego LDP mostram o volume de tráfego que passou por uma FEC específica em um roteador.

Quando você configura a instrução em nível de hierarquia, as estatísticas de tráfego LDP são coletadas periodicamente traffic-statistics[edit protocols ldp] e escritas em um arquivo. Você pode configurar com que frequência as estatísticas são coletadas (em segundos) usando a interval opção. O intervalo de coleta padrão é de 5 minutos. Você deve configurar um arquivo de estatísticas de LDP; caso contrário, as estatísticas de tráfego LDP não são coletadas. Se o LSP cair, as estatísticas de LDP serão reajustadas.

Para coletar estatísticas de tráfego LDP, inclua a traffic-statistics declaração:

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

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

Resultado das estatísticas do LDP

A saída da amostra a seguir é de um arquivo de estatísticas LDP:

O arquivo de estatísticas LDP inclui as seguintes colunas de dados:

  • FEC—FEC para a qual as estatísticas de tráfego LDP são coletadas.

  • Type— Tipo de tráfego originado de um roteador, Ingress ou (proveniente deste roteador) ou Transit (encaminhado por este roteador).

  • Packets— Número de pacotes passados pelo FEC desde que seu LSP surgiu.

  • Bytes— Número de bytes de dados passados pelo FEC desde que seu LSP surgiu.

  • Shared— Um valor indica que vários prefixos estão vinculados ao mesmo rótulo (por exemplo, quando vários prefixos são anunciados com uma política Yes de saída). As estatísticas de tráfego LDP deste caso aplicam-se a todos os prefixos e devem ser tratadas como tal.

  • read— Esse número (que aparece ao lado da data e da hora) pode diferir do número real das estatísticas exibidos. Algumas das estatísticas são resumidas antes de serem visualizadas.

Desativação de estatísticas de LDP no roteador penúltimo-hop

Reunir estatísticas de tráfego LDP no penúltimo roteador pode consumir recursos excessivos do sistema em rotas de next-hop em especial. Esse problema é agravado se você tiver configurado a deaggregate declaração além da traffic-statistics declaração. Para roteadores que atingem o limite de uso da rota de next-hop, recomendamos configurar a no-penultimate-hop opção para a traffic-statistics declaração:

Para ver uma lista de níveis de hierarquia nos quais você pode configurar a declaração, consulte a traffic-statistics seção resumo de declarações para esta declaração.

Nota:

Ao configurar a opção, não há estatísticas disponíveis para os FECs que sejam o no-penultimate-hop penúltimo hop para este roteador.

Sempre que você incluir ou remover essa opção da configuração, as sessões LDP são retiradas e reinicializadas.

A saída de amostra a seguir é de um arquivo de estatísticas LDP mostrando roteadores nos quais no-penultimate-hop a opção está configurada:

Limitações de estatísticas de LDP

Os seguintes problemas estão relacionados à coleta de estatísticas de LDP configurando a traffic-statistics declaração:

  • Não é possível limpar as estatísticas de LDP.

  • Se você encurtar o intervalo especificado, uma nova solicitação de estatísticas de LDP será emitida apenas se o temporizador de estatísticas expirar mais tarde do que o novo intervalo.

  • Uma nova operação de coleta de estatísticas de LDP não pode começar até que a anterior tenha terminado. Se o intervalo for curto ou se o número de estatísticas de LDP for grande, o intervalo de tempo entre as duas coletas de estatísticas pode ser maior do que o intervalo.

Quando um LSP cai, as estatísticas de LDP são reinicializadas.

Rastreamento do tráfego de protocolo LDP

As seções a seguir descreverão como configurar as opções de rastreamento para examinar o tráfego de protocolo LDP:

Rastreamento do tráfego de protocolo LDP nos níveis de instância de protocolo e roteamento

Para rastrear tráfego de protocolo LDP, você pode especificar opções na instrução global no nível da hierarquia e especificar opções específicas de LDP incluindo traceoptions[edit routing-options] a traceoptions instrução:

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

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

As bandeiras de rastreamento a seguir exibem as operações associadas ao envio e recebimento de várias mensagens LDP. Cada um pode levar um ou mais dos seguintes modificadores:

  • address— Rastrear a operação do endereço e abordar mensagens de retirada.

  • binding— Rastrear operações de encadernação de rótulos.

  • error— Rastrear condições de erro.

  • event— Rastrear eventos de protocolo.

  • initialization— Rastrear a operação das mensagens de inicialização.

  • label— Rastrear a operação da solicitação de rótulos, mapa de rótulos, rescisão de rótulos e mensagens de liberação de rótulos.

  • notification— Rastrear a operação das mensagens de notificação.

  • packets— Rastrear a operação do endereço, a retirada de endereços, inicialização, solicitação de rótulo, mapa de rótulos, retirada de rótulos, liberação de rótulos, notificação e mensagens periódicas. Esse modificador é equivalente à configuração address de , , e initializationlabelnotificationperiodic modificadores.

    Você também pode configurar o filter modificador de bandeira com match-on address a sub-opção para a packets bandeira. Com isso, você pode rastrear com base nos endereços de origem e destino dos pacotes.

  • path— Rastrear operações de caminho comutado por rótulos.

  • path— Rastrear operações de caminho comutado por rótulos.

  • periodic— Rastrear a operação do hello e manter mensagens.

  • route— Rastrear a operação das mensagens de rota.

  • state— Rastrear transições de estado do protocolo.

Rastreamento do tráfego de protocolo LDP dentro de FECs

O LDP associa uma classe de equivalência de encaminhamento (FEC) a cada LSP criada. O FEC associado a um LSP especifica quais pacotes são mapeados para esse LSP. LSPs são estendidos por uma rede conforme cada roteador escolhe o rótulo anunciado pelo próximo hop para o FEC e o splices ao rótulo que anuncia a todos os outros roteadores.

Você pode rastrear tráfego de protocolo LDP em um FEC específico e filtrar declarações de rastreamento de LDP com base em um FEC. Isso é útil quando você deseja rastrear ou solucionar problemas no tráfego de protocolo LDP associado a um FEC. Para isso, existem as seguintes bandeiras de rastreamento: routepathbinding e.

O exemplo a seguir ilustra como você pode configurar a instrução LDP para filtrar declarações de rastreamento traceoptions de LDP com base em um FEC:

Esse recurso tem as seguintes limitações:

  • O recurso de filtragem só está disponível para FECs composto por prefixos IP versão 4 (IPv4).

  • Os FECs de circuito de Camada 2 não podem ser filtrados.

  • Ao configurar o rastreamento e a filtragem de roteamento, MPLS as rotas não são exibidas (elas são bloqueadas pelo filtro).

  • A filtragem é determinada pela política e pelo valor configurado para a match-on opção. Ao configurar a política, certifique-se de que o comportamento padrão é sempre reject .

  • A única match-on opção é fec . Portanto, o único tipo de política que você deve incluir é uma política de filtragem de rotas.

Exemplos: Rastreamento do tráfego de protocolo LDP

Rastrear mensagens de caminho LDP em detalhes:

Rastrear todas as mensagens de saída LDP:

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

Rastrear todas as mensagens de LDP e todas as operações de encadernação de rótulos:

Rastrear tráfego de protocolo LDP para uma FEC associada ao LSP:

Tabela de histórico de liberação
Versão
Descrição
19.1
A partir do Junos OS Release 19.1R1, o roteador de borda por segmentos roteamento-LDP pode costurar o tráfego de roteamento por segmentos até LDP no next-hop e vice-versa.
16.1R1
A partir da versão 16.1R1 Junos OS, o suporte ao Hashed Message Authentication Code (HMAC) e à autenticação MD5 para sessões LDP é estendido de uma configuração por sessão para uma configuração de sub-match (ou seja, mais longa combinação de prefixo).
16.1
A partir da versão 16.1 do Junos OS, o M-LDP pode sinalizar LSPs ponto a multipoint no ASBR ou transitar ou saída quando o endereço raiz é uma rota BGP que é recursivamente solucionada por um LSP MPLS de segurança.
14.1
A partir da versão 14.1 do Junos OS, para migrar os serviços de IPTV existentes do multicast IP nativo para MPLS multicast, você precisa fazer uma transição tranquila de PIM para LSPs de ponto para multipoint M-LDP com interrupção mínima.