Configuração do LDP

Configurando o timer LDP para mensagens de olá de link

Para modificar a frequência com que o LDP envia mensagens de olá de link, especifique um novo intervalo de mensagens de link olá para o tempordor LDP usando a hello-interval declaração:

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

Configurando o temporizador 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 mensagens de olá direcionado para o temporizador LDP configurando a hello-interval declaração como uma opção para a targeted-hello declaração:

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

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

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

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

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

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

Ativando o recomeço gracioso

Para habilitar a reinicialização graciosa do LDP, você também precisa habilitar uma reinicialização graciosa no roteador. Para ativar a 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 a reinicialização graciosa de todos os protocolos com suporte a esse recurso no roteador. Para obter mais informações sobre a reinicialização graciosa, consulte a Biblioteca de protocolos de roteamento do Junos OS para dispositivos de roteamento.

Por padrão, a reinicialização graciosa do LDP é habilitada quando você permite a reinicialização graciosa tanto no nível de protocolo LDP quanto em todas as instâncias de roteamento. No entanto, você pode desabilitar o reinício gracioso do LDP e o modo de helper de reinicialização graciosa do LDP.

Desativação do LDP gracioso de reinicialização ou modo de helper

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

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

• A reinicialização graciosa do LDP e o modo helper estão habilitados.

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

• A reinicialização graciosa do LDP e o modo helper são desativados. O roteador não usa a reinicialização graciosa do LDP ou o gracioso tipo, comprimento e valor de reinicialização (TLV) enviados na mensagem de inicialização. O roteador se comporta como um roteador que não pode suportar a reinicialização graciosa do LDP.

Um erro de configuração é emitido se você tentar ativar o modo de helper de reinicialização e desativação graciosa.

Configurando o tempo de reconexão

Após a falha na conexão de LDP entre vizinhos, os vizinhos esperam um certo tempo para que o roteador reiniciado graciosamente retome o envio de mensagens LDP. Após o período de espera, a sessão de LDP pode ser restabelecida. Você pode configurar o período de espera em segundos. Esse valor está incluído na sessão tolerante a falhas que o TLV enviou em mensagens de inicialização de LDP quando a reinicialização graciosa do LDP é habilitada.

Suponha que o roteador A e o roteador B sejam vizinhos do LDP. O roteador A é o roteador de reiniciamento. O tempo de reconexão é o momento em que o roteador A diz ao Roteador B para esperar após o roteador B detectar que o Roteador A foi reiniciado.

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

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

Para obter uma lista de níveis de hierarquia nos quais você pode configurar essas declarações, veja 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 que o LDP reinicie graciosamente. O período de recuperação começa quando uma mensagem de inicialização é enviada ou recebida. Esse período também normalmente é a quantidade de tempo que um roteador vizinho mantém suas informações sobre o roteador reiniciador, permitindo que ele continue a encaminhar o tráfego.

Para evitar que um roteador vizinho seja afetado negativamente se receber um valor falso pelo tempo de recuperação do roteador reiniciado, você pode configurar o tempo máximo de recuperação 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 graciosa do LDP. Ele enviou um tempo de recuperação de 900 segundos para o roteador B vizinho. No entanto, o roteador B tem seu tempo máximo de recuperação configurado em 400 segundos. O roteador B só vai esperar por 400 segundos antes de expurgar suas informações de LDP do Roteador A.

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

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

Exemplos: Vinculações de rótulo de LDP de entrada filtragem

Aceite apenas /32 prefixos de todos os vizinhos:

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

Exemplos: Vinculações de rótulo de LDP de saída filtragem

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

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

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

Configurar o endereço de transporte para estabelecer sessões de LDP direcionadas tem os seguintes benefícios:

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

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

Visão geral do endereço de transporte targeted-LDP

Antes do Junos OS Release 19.1R1, o LDP forneceu suporte apenas para iD de 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 ao roteador-ID. Em caso de adjacê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 poderia ser derivado para a interface e, como resultado, a sessão de LDP não pôde ser estabelecida.

A partir do Junos OS Release 19.1R1, além dos endereços IP padrão usados para endereço de transporte de sessões de LDP direcionadas, você pode configurar qualquer outro endereço IP como endereço de transporte sob as sessiondeclarações de configuração e interface configuraçãosession-group. A configuração do endereço de transporte é aplicável para vizinhos configurados, incluindo apenas 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 por endereços de transporte

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

Após a configuração do endereço de transporte, a sessão targeted-LDP é 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 circuito de Camada 2, MPLS, VPLS e configuração LDP) é a seguinte:

1. Sob [edit protocols ldp session] hierarquia.

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

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

4. Sob [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. Sob [edit protocols ldp interfcae] hierarquia.

2. Sob [edit protocols ldp] hierarquia.

3. Endereço padrão.

A ordem de preferência do endereço de transporte para vizinhos auto-direcionados onde o LDP está configurado para aceitar pacotes olá é a seguinte:

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

2. Sob [edit protocols ldp] hierarquia.

3. Endereço padrão.

Resolução de problemas da configuração de endereços de transporte

Você pode usar as seguintes saídas de comando de exibição para solucionar problemas de sessões de LDP direcionadas:

• show ldp session

• show ldp neighbor

  O detail nível de saída do show ldp neighbor comando exibe o endereço de transporte enviado nas mensagens de olá para o vizinho alvo. Se esse endereço não for acessível do vizinho, a sessão de LDP não será atualizada.

• show configuration protocols ldp

Você também pode habilitar traceoptions de LDP para uma solução de problemas adicionais.

• Se a configuração for alterada de usar um endereço de transporte inválido (não acessável) para um endereço de transporte válido, os seguintes vestígios podem ser observados:

• Se a configuração for alterada de usar um endereço de transporte válido para o endereço de transporte inválido (não acessável), os seguintes vestígios podem ser observados:

Em caso de configuração defeituosa, execute as seguintes tarefas de solução de problemas:

• Confira.address family O endereço de transporte configurado sob a session declaração deve pertencer à mesma família de endereço que o vizinho ou sessão.

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

Exemplo: Configuração dos prefixos anunciados em LDP

Anuncie todas as rotas conectadas em LDP:

Visão geral do MoFRR

Com um redirecionamento rápido em fluxos unicast, um dispositivo de roteamento upstream pré-estabelece caminhos comutados por rótulos MPLS (LSPs) ou pré-computa um caminho de backup alternativo sem loop IP (LFA) para lidar com a falha de um segmento no caminho downstream.

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

Em uma árvore multicast, se o dispositivo detectar uma falha no componente da rede, leva algum tempo para realizar um reparo reativo, levando a uma perda de tráfego significativa enquanto configura um caminho alternativo. O MoFRR reduz a perda de tráfego em uma árvore de distribuição multicast quando um componente de rede falha. Com o MoFRR, um dos dispositivos de roteamento downstream estabelece um caminho alternativo em direção à fonte para receber uma transmissão ao vivo de backup do mesmo tráfego multicast. Quando uma falha acontece ao longo do fluxo primário, o dispositivo de roteamento MoFRR pode mudar rapidamente para o fluxo de backup.

Com o MoFRR habilitado 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 desarticulados se dois desses caminhos estiverem disponíveis. Se os caminhos desarticulados não estiverem disponíveis, o protocolo seleciona dois caminhos sem desarticulação. Se dois caminhos sem desarticulação não estiverem disponíveis, apenas um caminho primário será selecionado sem backup. O MoFRR prioriza o backup desarticulado em favor do balanceamento de carga dos caminhos disponíveis.

O MoFRR é compatível com as famílias de protocolo IPv4 e IPv6.

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

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

Uma das árvores multicast passa pelo 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 derruba o tráfego recebido no caminho de backup.

O MoFRR é suportado tanto em caminhos multicaminho de custo igual (ECMP) quanto em caminhos que não são ECMP. O dispositivo precisa habilitar rotas alternativas sem loop unicast (LFA) para oferecer suporte ao MoFRR em caminhos que não são ECMP. Você habilita rotas LFA usando a link-protection declaração na configuração do protocolo de gateway interior (IGP). Ao ativar a proteção de enlaces em uma interface OSPF ou IS-IS, o dispositivo cria um caminho LFA de backup para o próximo salto primário 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 dispositivo de roteamento de borda de rótulo (LER) MPLS para LDP MoFRR multiponto.

O Multipoint LDP MoFRR é usado no dispositivo de saída de uma rede MPLS, onde os pacotes são encaminhados para uma rede IP. Com o Multipoint LDP MoFRR, o dispositivo estabelece dois caminhos em direção ao dispositivo de roteamento DE PE upstream para receber dois fluxos de pacotes MPLS no LER. O dispositivo aceita um dos fluxos (o principal) e o outro (o backup) é descartado no LER. Se o caminho principal falhar, o dispositivo aceita o fluxo de backup. O suporte para sinalização de banda larga é um pré-requisito para o MoFRR com LDP multiponto (veja Entendendo a sinalização de banda de LDP multiponto para LSPs de ponto a multiponto).

Funcionalidade do PIM

O Junos OS oferece suporte ao MoFRR para a SPT (Shortest Path Tree, árvore de caminho mais curto) que se junta ao MULTICAST (SSM) de origem específica do PIM e multicast de qualquer fonte (ASM). O MoFRR é compatível com intervalos SSM e ASM. Para habilitar a participação do MoFRR para (*,G), inclua a mofrr-asm-starg declaração de configuração na [edit routing-options multicast stream-protection] hierarquia. Para cada grupo G, o MoFRR funcionará para (S,G) ou (*,G), mas não para ambos. (S,G) sempre prevalece (*,G).

Com o MoFRR habilitado, um dispositivo de roteamento PIM se propaga para juntar mensagens em duas interfaces upstream de encaminhamento de caminho reverso (RPF) para receber tráfego multicast em ambos os links para a mesma solicitação de junção. O MoFRR dá preferência a dois caminhos que não convergem para o mesmo dispositivo de roteamento upstream imediato. O PIM instala rotas multicast apropriadas com próximo salto RPF upstream com duas interfaces (para os caminhos primários e de backup).

Quando o caminho principal falha, o caminho de backup é atualizado para o status primário 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ções ou instala a rota multicast apropriada.

Você pode habilitar o MoFRR com o PIM para juntar balanceamento de carga (veja a join-load-balance automatic declaração). No entanto, nesse caso, a distribuição de mensagens de junção entre os links pode não ser uniforme. Quando um novo link ECMP é adicionado, junte-se às mensagens no caminho principal e seja redistribuída e balanceada. As mensagens de junção no caminho de backup ainda podem seguir o mesmo caminho e podem não ser redistribuídas uniformemente.

Você habilita o MoFRR usando a stream-protection declaraçã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 entrada ou um relatório IGMP, ele verifica uma configuração do MoFRR e prossegue da seguinte forma:

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

• Se a configuração do MoFRR estiver presente, o dispositivo verifica se há uma configuração de política.

• Se uma política não estiver presente, o dispositivo verifica caminhos primários e de backup (interfaces upstream) e prossegue da seguinte forma:

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

  • Se os caminhos primários e de backup estiverem disponíveis — o PIM envia a mensagem de junção upstream em direção a dois dos vizinhos upstream disponíveis. O Junos OS estabelece caminhos multicast primários 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 prossegue 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, plano 2 in Figura 12).

  • Se essa verificação de política for aprovada — o dispositivo verifica caminhos primários e de backup (interfaces upstream).

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

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

Funcionalidade de LDP multiponto

Para evitar a duplicação de tráfego MPLS, o LDP multiponto geralmente seleciona apenas um caminho upstream. (Veja seção 2.4.1.1. Determinando o "LSR upstream" em RFC 6388, extensões de protocolo de distribuição de rótulos para caminhos comutados de rótulos de ponto a multiponto e multiponto para multiponto.)

Para LDP multiponto com MoFRR, o dispositivo LDP multiponto seleciona dois pares upstream separados e envia dois rótulos separados, um para cada peer upstream. O dispositivo usa o mesmo algoritmo descrito no RFC 6388 para selecionar o caminho de upstream primário. O dispositivo usa o mesmo algoritmo para selecionar o caminho upstream de backup, mas exclui o LSR upstream primário como candidato. Os dois pares upstream diferentes enviam dois fluxos de tráfego MPLS para o dispositivo de roteamento de saída. O dispositivo seleciona apenas um dos caminhos vizinhos upstream como o caminho principal para aceitar o tráfego MPLS. O outro caminho se torna o caminho de backup, e o dispositivo derruba esse tráfego. Quando o caminho upstream primário falha, o dispositivo começa a aceitar o tráfego do caminho de backup. O dispositivo LDP multiponto seleciona os dois caminhos upstream com base no próximo salto do dispositivo raiz do protocolo de gateway interior (IGP).

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 que é colocado em um determinado pacote representa a FEC à 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 primário e a outra rota 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 como o principal. A qualquer momento, o dispositivo upstream envia tráfego em apenas um dos múltiplos links paralelos.

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

Como acontece com o [edit routing-options multicast] PIM, você habilita o MoFRR com LDP multiponto usando a stream-protection declaração de configuração na hierarquia, e é gerenciado por um conjunto de políticas de filtro.

Se você tiver habilitado o FEC multiponto de LDP de ponto a multiponto para MoFRR, o dispositivo considera as seguintes considerações para a seleção do caminho upstream:

• As sessões de LDP direcionadas são independidas se houver uma sessão de LDP não direcionada. Se houver uma única sessão de LDP direcionada, a sessão LDP direcionada será selecionada, mas o FEC ponto a multiponto correspondente perde o recurso MoFRR porque não há interface associada à sessão LDP direcionada.

• Todas as interfaces que pertencem ao mesmo LSR upstream são consideradas o caminho principal.

• Para quaisquer atualizações de rota de nó raiz, o caminho upstream é alterado com base nos próximos saltos mais recentes do IGP. Se um caminho melhor estiver disponível, o LDP multiponto tenta mudar para um caminho melhor.

Encaminhamento de pacotes

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

• Evita enviar fluxos duplicados por toda a malha

• Evita várias buscas de rota (que resultam em quedas de pacotes).

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

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

Para MoFRR com LDP multiponto em roteadores, o dispositivo usa várias etiquetas MPLS para controlar a seleção de fluxo MoFRR. Cada rótulo representa uma rota separada, mas cada uma 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 multiponto.

Limitações e advertências

• Limitações e advertências do MoFRR em dispositivos de comutação e roteamento
• Limitações do MoFRR em dispositivos de comutação com PIM
• Limitações e advertências do MoFRR em dispositivos de roteamento com LDP multiponto

Visão geral do roteamento por segmentos para a interoperabilidade do LDP

Figura 22 mostra uma topologia de rede LDP simples para ilustrar como funciona a interoperabilidade de dispositivos de roteamento por segmentos com dispositivos LDP. Tenha em mente que tanto o OSPF quanto o ISIS são apoiados, por isso, por enquanto, manteremos as coisas agnósticas em relação ao IGP. A topologia da amostra tem seis dispositivos, R1 a R6, em uma rede que está passando por uma migração do LDP para o roteamento por segmentos.

Na topologia, os dispositivos R1, R2 e R3 estão configurados apenas para roteamento por segmentos. Os dispositivos R5 e R6 fazem parte de um domínio LDP legado e atualmente não oferecem suporte ao SR. O dispositivo R4 oferece suporte ao LDP e ao roteamento por segmentos. Os endereços de loopback de todos os dispositivos são mostrados. Esses loopbacks são anunciados como FECs de saída no domínio LDP e como IDs de nós SR no domínio SR. A interoperabilidade é baseada no mapeamento de um LDP FEC em um ID de nós SR, e vice-versa.

Para que o R1 intertrabalhe com o R6, é necessário tanto um servidor de mapeamento de roteamento por segmentos (SRMS) quanto um cliente de mapeamento de roteamento por segmentos (SRMC). É mais fácil entender o papel do SRMS e SRMC analisando o fluxo de tráfego de maneira unidirecional. Com base nisso Figura 22, diremos que o tráfego que flui da esquerda para a direita se origina no domínio SR e termina no domínio LDP. De forma semelhante, o tráfego que flui da direita para a esquerda se origina no domínio LDP e termina no domínio SR.

O SRMS fornece as informações necessárias para costurar o tráfego na direção esquerda para a direita. O SRMC fornece mapeamento para tráfego que flui da direita para a esquerda.

• Fluxo de tráfego da esquerda para a direita: O servidor de mapeamento de roteamento por segmentos

  O SRMS facilita a costura de LSP entre os domínios SR e LDP. O servidor mapeia OS FECs LDP em IDs de nós SR. Você configura os FECs LDP a serem mapeados sob o nível de [edit routing-options source-packet-routing] hierarquia. Normalmente, você precisa mapear todos os endereços de loopback de nós LDP para obter conectividade completa. Como mostrado abaixo, você pode mapear prefixos contíguos em uma declaração de faixa única. Se os loopbacks de nó LDP não forem contíguos, você precisa definir várias declarações de mapeamento.

  Você aplica a configuração de mapeamento SRMS sob o [edit protocols ospf] nível de hierarquia.[edit protocols isis] Essa escolha depende de qual IGP está sendo usado. Observe que ambos os nós SR e LDP compartilham um domínio de roteamento de IGP comum, de área/nível único.

  O SRMS gera uma lista de prefixo estendida LSA (ou LSP no caso do ISIS). As informações nesta LSA permitem que os nós SR mapeiem prefixos de LDP (FECs) para IDs de nós SR. As rotas mapeadas para os prefixos LDP estão instaladas nas inet.3 tabelas de roteamento dos mpls.0 nós SR para facilitar a entrada e as operações de costura de LSP para o tráfego na direção esquerda para a direita.

  O LSA estendido (ou LSP) é inundado por toda a (única) área de IGP. Isso significa que você está livre para colocar a configuração SRMS em qualquer roteador no domínio SR. O nó SRMS não precisa executar LDP.

• Fluxo de tráfego da direita para a esquerda: O cliente de mapeamento de roteamento por segmentos

  Para interoperar na direção da direita para a esquerda, ou seja, da ilha LDP até a ilha SR, você simplesmente permite o mapeamento de roteamento por segmentos da funcionalidade do cliente em um nó que fala TANTO SR quanto LDP. Em nosso exemplo, esse é o R4. Você ativa a funcionalidade SRMC com a mapping-client declaração na [edit protocols ldp] hierarquia.

  A configuração SRMC ativa automaticamente uma política de saída de LDP para anunciar os SIDs de nó e prefixo do domínio SR como FECs de saída LDP. Isso oferece aos nós de LDP a acessibilidade de LSP para os nós no domínio SR.

• A função SRMC deve ser configurada em um roteador que é anexado aos domínios SR e LSP. Se desejado, o mesmo nó também pode funcionar como o SRMS.

Roteamento por segmentos para interoperabilidade de LDP usando OSPF

Figura 22Consulte, suponha que device R2 (na rede de roteamento por segmentos) seja o SRMS.

1. Definir a função SRMS:

   Essa configuração cria um bloco de mapeamento para ambos os endereços de loopback do dispositivo LDP na topologia de amostra. O índice inicial de ID do segmento (SID) mapeado para o loopback do R5 é 1000. Especificar o tamanho 2 resulta em um índice SID 10001 sendo mapeado para o endereço loopback do R6.

   Nota:

   O endereço IP usado como start-prefix endereço de loopback de um dispositivo na rede LDP (R5, neste exemplo). Para ter uma conectividade completa, você deve mapear todos os endereços de loopback dos roteadores LDP para o domínio SR. Se os endereços de loopback forem contíguos, você pode fazer isso com uma única prefix-segment-range declaração. Loopbacks não contíguos exigem a definição de várias declarações de mapeamento de prefixo.

   Nosso exemplo usa loopbacks contíguos para que um único prefix-segment-range seja mostrado acima. Apresentamos aqui um exemplo de vários mapeamentos para dar suporte ao caso de dois nós LDP com endereçamento de loopback não contíguo:

2. Em seguida, configure o suporte OSPF para o LSA estendido usado para inundar os prefixos mapeados.

   Uma vez que a configuração do servidor de mapeamento é comprometida no dispositivo R2, a faixa de prefixo estendida TLV é inundada em toda a área de OSPF. Os dispositivos capazes de roteamento por segmentos (R1, R2 e R3) instalam rotas de roteamento por segmentos OSPF para o endereço loopback especificado (R5 e R6 neste exemplo), com um índice de ID (SID) de segmentos. O índice SID também é atualizado na mpls.0 tabela de roteamento pelos dispositivos de roteamento por segmentos.

3. Habilite a funcionalidade SRMC. Para nossa topologia de amostra, você deve habilitar a funcionalidade SRMC no R4.

   Uma vez que a configuração do cliente de mapeamento é comprometida no dispositivo R4, os IDs de nós SR e blocos de rótulos são anunciados como FECs de saída para o roteador R5, que depois os anuncia novamente para R6.

O suporte para costurar o roteamento por segmentos e o next-hop de LDP com OSPF começou no Junos OS 19.1R1.

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

• Os conflitosde prefixo só são detectados no SRMS. Quando há um conflito de faixa de prefixo, prevalece o SID prefixo do ID do roteador inferior. Nesses casos, é gerada uma mensagemRPD_OSPF_PFX_SID_RANGE_CONFLICT de erro de log do sistema.

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

• A inundação do LSA opaco de prefixo estendido do OSPF em fronteiras AS (inter-AS) não é suportada.

• A funcionalidade de servidor de mapeamento de LDP entre áreas não é suportada.

• A funcionalidade ABR do LSA opaco de prefixo estendido não é suportada.

• A funcionalidade ASBR do LSA opaco de prefixo estendido não é suportada.

• O mapeamento deroteamento por egment do servidor Preference TLV não é suportado.

Interoperabilidade do roteamento por segmentos com LDP usando ISIS

Figura 22Consulte, assuma que o dispositivo R2 (na rede de roteamento por segmentos) é o SRMS. A configuração a seguir é adicionada para a função de mapeamento:

1. Definir a função SRMS:

   Essa configuração cria um bloco de mapeamento para ambos os endereços de loopback do dispositivo LDP na topologia de amostra. O índice inicial de ID do segmento (SID) mapeado para o loopback do R5 é 1000. Especificar o tamanho 2 resulta em um índice SID 10001 sendo mapeado para o endereço loopback do R6.

   Nota:

   O endereço IP usado como start-prefix endereço de loopback de um dispositivo na rede LDP (R5, neste exemplo). Para ter conectividade completa, você deve mapear todos os endereços de loopback dos roteadores LDP no domínio SR. Se os endereços de loopback forem contíguos, você pode fazer isso com uma prefix-segment-range declaração. Loopbacks não contíguos exigem a definição de várias declarações de mapeamento.

   Nosso exemplo usa loopbacks contíguos para que um único prefix-segment-range seja mostrado acima. Aqui está um exemplo de mapeamentos de prefixo para lidar com o caso de dois roteadores LDP com endereçamento de loopback não contíguo:

2. Em seguida, configure o suporte do ISIS para o LSP estendido usado para inundar os prefixos mapeados.

   Uma vez que a configuração do servidor de mapeamento é comprometida no dispositivo R2, a faixa de prefixo estendida TLV é inundada em toda a área de OSPF. Os dispositivos capazes de roteamento por segmentos (R1, R2 e R3) instalam rotas de roteamento por segmentos ISIS para o endereço de loopback especificado (R5 e R6 neste exemplo), com um índice de ID (SID) do segmento. O índice SID também é atualizado na mpls.0 tabela de roteamento pelos dispositivos de roteamento por segmentos.

3. Habilite a funcionalidade SRMC. Para nossa topologia de amostra, você deve habilitar a funcionalidade SRMC no R4.

   Uma vez que a configuração do cliente de mapeamento é comprometida no dispositivo R4, os IDs de nós SR e blocos de rótulos são anunciados como FECs de saída para o roteador R5, e de lá para R6.

O suporte para costurar o roteamento por segmentos e o próximo salto do LDP com o ISIS começou no Junos OS 17.4R1.

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

• O comportamento de estouro do penúltimo salto para TLV de ligação de rótulos não é suportado.

• A publicidade da gama de prefixos no TLV vinculante de rótulos não é suportada.

• A resolução de conflitos de roteamento por segmentos não é suportada.

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

• O roteamento ativo sem parar (NSR) e o gracioso switchover do mecanismo de roteamento (GRES) não são suportados.

• O nível internível do ISIS não é suportado.

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

• A redistribuição da rota LDP como um tapume de prefixo no nó de costura não é suportada.

Configure o LDP para usar a métrica de rota IGP

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

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

Evite a inclusão de rotas de entrada na tabela de roteamento inet.0

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

Nota:

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

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

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

Ao configurar várias instâncias de roteamento LDP, você pode usar o LDP para anunciar rótulos em uma VPN de operadora de operadoras de um roteador de borda de provedor de serviços (PE) para um roteador de borda de cliente de operadora (CE). Isso é especialmente útil quando o cliente da operadora é um provedor de serviços básicos de Internet (ISP) e quer restringir rotas completas de Internet aos seus roteadores PE. Ao usar o 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 aos seus clientes.

Para um exemplo de como configurar várias instâncias de roteamento LDP para VPNs de operadoras de operadoras, consulte o Guia do usuário de múltiplas instâncias para protocolo de distribuição de rótulos.

Configure MPLS e LDP para colocar o rótulo no roteador de salto final

O rótulo anunciado padrão é o rótulo 3 (rótulo Implicit Null). Se o rótulo 3 for anunciado, o penúltimo roteador de salto remove o rótulo e envia o pacote para o roteador de saída. Se o estouro de salto final for habilitado, o rótulo 0 (rótulo IPv4 Explicit Null) é anunciado. O salto final garante que todos os pacotes que atravessam uma rede MPLS incluam um rótulo.

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

Nota:

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

Para obter mais informações sobre rótulos, consulte a visão geral do rótulo MPLS e a alocação de rótulos MPLS.

Habilite o LDP sobre LSPs estabelecidos por RSVP

Você pode executar LDP sobre LSPs estabelecidos pelo RSVP, tunelando efetivamente o LSP estabelecido por LDP através do estabelecido pelo RSVP. Para isso, habilite o LDP na interface lo0.0 (ver Ativação e desativação do LDP). Você também deve configurar os LSPs sobre os quais deseja que o LDP opere, incluindo a ldp-tunneling declaração no nível de [edit protocols mpls label-switched-path lsp-name] hierarquia:

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

Nota:

O LDP pode ser tunelado em uma sessão de RSVP que tem a proteção de link habilitada. Começando pelo Junos OS Release 21.1R1, exibindo detalhes sobre a rota tunelada LDP exibe os próximos saltos LSP primários e de desvio. Nos lançamentos anteriores do Junos OS, o bypass LSP next hop mostrou o próximo salto para o LSP primário.

Habilite o LDP sobre LSPs estabelecidos por RSVP em redes heterogêneas

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

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

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

Você pode configurar esta declaração 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 suportamedit logical-systems o [] nível de hierarquia.

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

Configure a assinatura TCP MD5 para sessões de LDP

Você pode configurar uma assinatura MD5 para uma conexão TCP LDP para proteger contra a introdução de segmentos TCP falsificados em fluxos de conexão de sessão LDP. Para obter mais informações sobre a autenticação do TCP, consulte TCP. Para saber como usar a opção de autenticação de TCP (TCP-AO) em vez de TCP MD5, veja No link title.

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 do LDP hello ainda podem ser criadas mesmo quando as interfaces de peering são configuradas com diferentes assinaturas de segurança. No entanto, a sessão de TCP não pode ser autenticada e nunca está estabelecida.

Você pode configurar o Hashed Message Authentication Code (HMAC) e a autenticação MD5 para sessões de LDP como uma configuração por sessão ou uma configuração de correspondência de sub-rede (ou seja, a configuração de prefixo mais longa). O suporte para autenticação de correspondência de sub-rede oferece flexibilidade na configuração da autenticação para sessões de LDP (TLDP) direcionadas automaticamente. Isso facilita a implantação de pseudowires alternativos sem loop remoto (LFA) e FEC 129.

Para configurar uma assinatura MD5 para uma conexão TCP LDP, inclua a authentication-key declaração como parte do grupo de sessão:

Use a session-group declaração para configurar o endereço para a extremidade remota da sessão de LDP.

A md5-authentication-key, ou senha, na configuração pode ter até 69 caracteres de comprimento. Os 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 que você atualize as chaves de autenticação sem interromper protocolos de roteamento e sinalização associados, como Open Shortest Path First (OSPF) e Resource Reservation Setup Protocol (RSVP).

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

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

Para obter mais informações sobre o recurso de atualização da chave de autenticação, consulte Configurando o mecanismo de atualização da chave de autenticação para protocolos de roteamento BGP e LDP.

Configuração da proteção de sessão LDP

Uma sessão de LDP é normalmente criada entre um par de roteadores conectados por um ou mais links. Os roteadores formam um olá adjacência para cada link que os conecta e associam todas as adjacências com a sessão LDP correspondente. Quando a última adjacência de olá para uma sessão de LDP desaparece, a sessão de LDP é terminada. Você pode querer 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 de LDP entre dois roteadores, mesmo que não haja adjacências de olá nos links que conectam os dois roteadores configurando a session-protection declaração. Você pode especificar opcionalmente um tempo em segundos usando a opção timeout . A sessão permanece ativa pela duração especificada enquanto os roteadores mantiverem a conectividade da rede IP.

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

Desativação de armadilhas SNMP para LDP

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

Para obter informações sobre as armadilhas LDP SNMP e o LDP MIB proprietário, consulte o SNMP MIB Explorer..

Para desativar armadilhas SNMP para LDP, especifique a opção trap disable para a log-updown declaração:

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

Configuração da sincronização de LDP com o IGP em links LDP

LDP é um protocolo para distribuir rótulos em aplicativos não projetados para tráfego. Os rótulos são distribuídos ao longo do melhor caminho determinado pelo IGP. Se a sincronização entre LDP e IGP não for mantida, o LSP cairá. Quando o LDP não está totalmente operacional em um determinado link (uma sessão não está estabelecida e os rótulos não são trocados), o IGP anuncia o link com a métrica de custo máximo. O link não é preferido, mas permanece na topologia da rede.

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

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

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

Para obter uma lista de níveis de hierarquia em que você pode configurar esta declaração, veja a seção de resumo da declaração para esta declaração.

Configuração da sincronização de LDP com o IGP no roteador

Você pode configurar o tempo que o LDP aguarda antes de informar ao IGP que o vizinho LDP e a sessão para uma interface estão operacionais. Para redes de grande porte com vários FECs, você pode precisar configurar um valor mais longo para permitir a troca de bancos de dados de rótulos LDP o suficiente.

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

Para obter uma lista de níveis de hierarquia em que você pode configurar esta declaração, veja a seção de resumo da declaração para esta declaração.

Configurando o timer de retirada de rótulos

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

Se o roteador receber o novo rótulo antes que o temporizador se esgote, o temporizador de retirada de rótulos será cancelado. No entanto, se o temporizante acabar, o rótulo para o FEC será retirado de todos os roteadores upstream.

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

Para obter uma lista de níveis de hierarquia em que você pode configurar esta declaração, veja a seção de resumo da declaração para esta declaração.

Ignorando a verificação da sub-rede LDP

No Junos OS Release 8.4 e versões posteriores, uma verificação de sub-rede de endereço fonte LDP é realizada durante o procedimento de estabelecimento vizinho. O endereço de origem no pacote olá do link LDP é combinado com o 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.

Saída de estatísticas do LDP

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

O arquivo de estatísticas do 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 originário de um roteador, seja Ingress (originário deste roteador) ou Transit (encaminhado por este roteador).

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

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

• Shared— Um Yes 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 de saída). As estatísticas de tráfego de LDP para este caso se aplicam a todos os prefixos e devem ser tratadas como tal.

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

Desativação das estatísticas de LDP no penúltimo roteador de salto

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

Para obter uma lista de níveis de hierarquia em que você pode configurar a traffic-statistics declaração, consulte a seção de resumo da declaração para esta declaração.

Nota:

Quando você configura a opção no-penultimate-hop , não há estatísticas disponíveis para os FECs que são o penúltimo salto para este roteador.

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

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

Limitações das estatísticas do LDP

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

• Você não pode limpar as estatísticas do LDP.

• Se você reduzir o intervalo especificado, uma nova solicitação de estatísticas de LDP só será emitida se o temporizador de estatística 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, a diferença de tempo entre as duas coletas de estatísticas pode ser maior do que o intervalo.

Quando um LSP cai, as estatísticas do LDP são redefinidas.

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

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

Para obter uma lista de níveis de hierarquia em que você possa incluir esta declaração, veja a seção de resumo da declaração para esta declaração.

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

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

• address— Trace a operação de mensagens de retirada de endereços e endereços.

• binding— Trace as operações de vinculação de rótulos.

• error— Rastrear condições de erro.

• event— Trace eventos de protocolo.

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

• label— Trace a operação de solicitação de rótulos, mapa de rótulos, retirada de rótulos e mensagens de versão de rótulos.

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

• packets— Trace a operação de endereço, retirada de endereços, inicialização, solicitação de rótulos, mapa de rótulos, retirada de rótulos, liberação de rótulos, notificação e mensagens periódicas. Este modificador equivale à configuração deaddress, , initialization, labele notificationperiodic modificadores.

  Você também pode configurar o modificador de filter bandeira com a match-on address subopção para a packets bandeira. Isso permite rastrear com base nos endereços de origem e destino dos pacotes.

• path— Trace as operações de caminho comutada por rótulos.

• path— Trace as operações de caminho comutada por rótulos.

• periodic— Trace a operação de mensagens de olá e keepalive.

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

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

Rastreamento do tráfego de protocolo LDP dentro dos FECs

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

Você pode rastrear o tráfego de protocolo LDP em uma FEC específica e filtrar declarações de rastreamento de LDP com base em uma FEC. Isso é útil quando você deseja rastrear ou solucionar problemas de tráfego de protocolo LDP associado a uma FEC. As seguintes bandeiras de rastreamento estão disponíveis para esta finalidade: routeepathbinding...

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

Esse recurso tem as seguintes limitações:

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

• OS FECs de circuito de camada 2 não podem ser filtrados.

• Quando você configura tanto o rastreamento de rota quanto a filtragem, as rotas MPLS não são exibidas (elas são bloqueadas pelo filtro).

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

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

Exemplos: Rastreamento do tráfego de protocolo LDP

Trace as mensagens de caminho do LDP em detalhes:

Trace todas as mensagens de saída de LDP:

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

Rastreie todas as mensagens de entrada de LDP e todas as operações de vinculação de rótulos:

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