Detecção de encaminhamento bidirecional (BFD) para MPLS
Configuração da detecção de encaminhamento bidirecional para MPLS (procedimento CLI)
Você pode configurar o protocolo de detecção de encaminhamento bidirecional (BFD) em switches autônomos EX8200 e Virtual Chassis EX8200 para detectar falhas no caminho mpls label-switch (LSP). O protocolo BFD é um mecanismo simples de olá que detecta falhas em uma rede. Olá, os pacotes são enviados em um intervalo específico e regular. Uma falha no vizinho é detectada quando o dispositivo de roteamento para de receber uma resposta do vizinho após um intervalo especificado. A BFD trabalha com uma ampla variedade de ambientes de rede e topologias. Os temporistas de detecção de falhas para BFD têm prazos mais curtos do que os dos mecanismos de detecção de falhas para rotas estáticas e, portanto, fornecem detecção mais rápida. Esses timers também são adaptativos. Por exemplo, um temporizador pode se adaptar a um valor mais alto se uma adjacência falhar, ou um vizinho pode negociar um valor mais alto do que o configurado.
Este tópico descreve a configuração dos switches de borda (PE) do provedor e dos switches de provedor para oferecer suporte a LSPs baseados em LDP e LSPs baseados em RSVP.
Este tópico inclui:
- Configuração de BFD em switches de borda e provedor de provedores para um LSP baseado em LDP
- Configuração de BFD em switches de borda e provedor de provedores para um LSP baseado em RSVP
Configuração de BFD em switches de borda e provedor de provedores para um LSP baseado em LDP
Você pode habilitar o BFD para LSPs baseados em LDP ou LSPs baseados em RSVP associados a uma classe de equivalência de encaminhamento específica (FEC). Como alternativa, você pode configurar uma política de entrada de Administração e Manutenção de Operações (OAM) para habilitar a BFD em uma variedade de endereços FEC.
Antes de configurar o BFD para um LSP baseado em LDP, você deve configurar os componentes básicos para uma rede MPLS:
Configure dois switches PE. Veja a configuração do MPLS em switches de borda de provedores usando IP-over-MPLS.
Configure um ou mais switches de provedor. Veja a configuração do MPLS nos switches EX8200 e EX4500.
Para configurar a BFD em PE e switches de provedor:
Configuração de BFD em switches de borda e provedor de provedores para um LSP baseado em RSVP
Quando o BFD é configurado para um LSP baseado em RSVP no switch de entrada, ele é habilitado no caminho principal e em todos os caminhos secundários de espera para esse LSP. Você pode habilitar o BFD para todos os LSPs em um switch ou para LSPs específicos. Se você configurar o BFD para um LSP específico, quaisquer valores configurados globalmente para BFD serão substituídos nesse LSP. As sessões de BFD se originam apenas no switch de entrada e terminam no switch de saída.
Antes de configurar o BFD para um LSP baseado em RSVP, você deve configurar os componentes básicos para uma rede MPLS:
Configure dois switches PE. Veja a configuração do MPLS em switches de borda de provedores usando IP-over-MPLS.
Configure um ou mais switches de provedor. Veja a configuração do MPLS nos switches EX8200 e EX4500.
Para configurar a BFD em PE e switches de provedor:
Reparo local desencadeado por BFD para convergência rápida
Entendendo a proteção local desencadeada por BFD
O tempo necessário para uma rede convergir após uma falha de link ou nó pode variar drasticamente com base em uma série de fatores, incluindo o tamanho da rede, os protocolos usados e o design da rede. No entanto, embora cada evento de convergência em particular seja diferente, o processo de convergência é essencialmente consistente. A falha é detectada, a falha é relatada (inundada) na rede, um caminho alternativo é encontrado para o tráfego, e o plano de encaminhamento é atualizado para passar tráfego em um novo caminho.
Essa visão geral discute como o reparo local desencadeado pela detecção de encaminhamento bidirecional (BFD) contribui para um tempo de restauração mais rápido para uma convergência rápida em uma rede MPLS.
- Finalidade do reparo local desencadeado por BFD
- Configuração do reparo local desencadeado por BFD
- Desativação do reparo local desencadeado por BFD
Finalidade do reparo local desencadeado por BFD
No Junos OS, a proteção geral de tráfego MPLS para falhas de caminho comutada por rótulos sinalizados por RSVP (LSP) é fornecida por vários mecanismos complementares. Esses mecanismos de proteção incluem proteção local (redirecionamento rápido, proteção de enlaces e proteção de enlaces de nós) e proteção de caminhos (caminhos primários e secundários). A proteção local em conjunto com a proteção do caminho pode fornecer perda mínima de pacotes para um LSP e controlar a forma como o LSP é redirecionado após uma falha. Tradicionalmente, ambos os tipos de proteção dependem da detecção rápida de falha de conectividade no nível físico. No entanto, para mídia de transmissão sem detecção rápida de nível físico, o Junos OS oferece suporte a BFD e MPLS para detecção rápida de falhas.
Com ligações entre roteadores, quando uma rota cai, o processo de protocolo de roteamento recalcula o próximo melhor caminho. Quando o MPLS é habilitado para redirecionamento rápido (FRR), as mensagens ifl são inundadas para todos os concentradores de PIC flexíveis (FPCs). O FPC de borda permite o túnel LSP de bypass MPLS. Por fim, todas as rotas são reparadas e enviadas pelo túnel LSP de bypass MPLS. O tempo necessário para o reparo de todas as rotas é proporcional ao número de rotas.
Esse cenário de reparo fica mais difícil quando um switch fica entre dois links. Veja Figura 1.
Quando um link cai na extremidade remota, a falha não é detectada na extremidade local até que o protocolo de gateway interior (IGP) seja desativado. Aguardar o processo de protocolo de roteamento recalcular o próximo melhor caminho leva muito tempo.
Com o reparo local desencadeado por BFD habilitado, o Mecanismo de encaminhamento de pacotes completa o reparo primeiro, usando o túnel MPLS LSP de bypass (pré-configurado e instalado), e então informa o processo de protocolo de roteamento para recalcular uma nova rota. Ao fazer isso, quando o túnel LSP mpls primário cai, o FPC pode desviar o tráfego intermitente e imediatamente para o FPC com o túnel LSP MPLS de desvio.
Usar o reparo local dessa forma alcança um tempo de restauração mais rápido de menos de 50 ms.
Configuração do reparo local desencadeado por BFD
O reparo local desencadeado por BFD não é configurável, mas faz parte da configuração padrão.
O reparo local desencadeado por BFD funciona dentro dos recursos legados do Junos OS MPLS-FRR, BFD para IGP e alternativas sem loop (LFAs).
Desativação do reparo local desencadeado por BFD
Por padrão, o reparo local desencadeado por BFD é habilitado para todas as interfaces de roteamento. Se desejado, você pode desabilitar o reparo local desencadeado por BFD no nível [edit routing-options] de hierarquia.
Para desabilitar explicitamente o reparo local desencadeado pela BFD:
Inclua a
no-bfd-triggered-local-repairdeclaração no nível de hierarquia [editar opções de roteamento]:user@host# set no-bfd-triggered-local-repair
(Opcional) Verifique suas configurações antes de comprometê-las usando o
show routing-optionscomando.user@host# run show routing-options
Confirme sua configuração emitindo o show routing-options comando.
user@host# show routing-options
...
no-bfd-triggered-local-repair;
}
Ao desabilitar esse recurso, você também deve reiniciar o roteamento, incluindo a graceful-restart declaração para o IGP. Por exemplo, para OSPF, isso é realizado incluindo a graceful-restart declaração no nível de [edit protocols ospf] hierarquia.
Configuração de BFD para LSPs MPLS IPv4
Você pode configurar o protocolo de detecção de encaminhamento bidirecional (BFD) em LSPs MPLS IPv4, conforme descrito no rascunho da Internet draft-ietf-bfd-mpls-02.txt, BFD para LSPs MPLS. O BFD é usado como um recurso periódico de operação, administração e manutenção (OAM) para LSPs para detectar falhas no plano de dados LSP. Você pode configurar o BFD para LSPs que usam LDP ou RSVP como protocolo de sinalização.
BFD para MPLS IPv4 LSP é baseado no mecanismo de roteamento e não é distribuído. Como resultado, o intervalo mínimo de temporizador BFD é (100 ms * 3) por uma sessão de LSP, e para sessões de LSP escalonadas, o intervalo mínimo de temporizador BFD é (300 ms * 3). Conforme você aumenta o número de sessões de LSP com BFD, você também deve aumentar (escala) os temporizantes de intervalo para dar suporte à rede.
Para instâncias de comutação do mecanismo de roteamento com suporte ininterrupto de roteamento ativo (NSR), o intervalo mínimo de temporizador BFD é (2,5 segundos * 3).
Você também pode usar os comandos LSP ping para detectar falhas no plano de dados LSP. No entanto, a BFD tem alguns benefícios: exige menos processamento de computador do que os comandos LSP ping e pode detectar falhas rapidamente em um grande número de LSPs (os comandos LSP ping devem ser emitidos individualmente para cada LSP). Por outro lado, a BFD não pode ser usada para verificar o plano de controle em relação ao plano de dados na saída LSR, o que é possível quando uma solicitação de eco LSP ping está associada a uma classe de equivalência de encaminhamento (FEC).
Os temporizadores de detecção de falhas de BFD são adaptativos e podem ser ajustados para serem mais ou menos agressivos. Por exemplo, os timers podem se adaptar a um valor mais alto se a adjacência falhar, ou um vizinho pode negociar um valor mais alto por um temporizador do que o valor configurado. Os tempores se adaptam a um valor mais alto quando uma aba de sessão BFD ocorre mais de três vezes em um período de 15 segundos. Um algoritmo de back-off aumenta o intervalo de recebimento (Rx) em dois se a instância local de BFD for a razão para a aba da sessão. O intervalo de transmissão (Tx) é aumentado em dois se a instância BFD remota for a razão para a aba da sessão. Você pode usar o clear bfd adaptation comando para devolver os temporizador de intervalo BFD aos seus valores configurados. O clear bfd adaptation comando é sem impacto, o que significa que o comando não afeta o fluxo de tráfego no dispositivo de roteamento.
A partir do Junos OS Release 13.2R4, 13.3R2 e 14.1, você pode definir o intervalo de tempo entre as mensagens de ping LSP e o número de respostas de ping LSP, respectivamente, após a qual a sessão de detecção de encaminhamento bidirecional (BFD) é derrubada. Para isso, você configura a lsp-ping-interval declaração e a lsp-ping-multiplier declaração no nível de [edit protocols mpls oam] hierarquia.
Para obter instruções de configuração para LSPs sinalizados por LDP, consulte Configuração de BFD para LSPs LDP. Para obter instruções de configuração para LSPs sinalizados por RSVP, veja a seção a seguir.
- Configuração de BFD para LSPs sinalizados por RSVP
- Configurando uma ação de falha para a sessão de BFD em um RSVP LSP
Configuração de BFD para LSPs sinalizados por RSVP
BFD para RSVP oferece suporte a LSPs IPv4 unicast. Quando o BFD é configurado para um RSVP LSP no roteador de entrada, ele é habilitado no caminho principal e em todos os caminhos secundários de standby para esse LSP. O endereço IP de origem para pacotes BFD de saída do lado de saída de uma sessão de BFD MPLS é baseado no endereço IP da interface de saída. Você pode habilitar o BFD para todos os LSPs em um roteador ou para LSPs específicos. Se você configurar o BFD para um LSP específico, quaisquer valores configurados globalmente para BFD serão substituídos. As sessões de BFD se originam apenas no roteador de entrada e terminam no roteador de saída.
Um erro é registrado sempre que uma sessão de BFD para um caminho falha. O exemplo a seguir mostra como as mensagens de log BFD para RSVP LSP podem aparecer:
RPD_MPLS_PATH_BFD_UP: MPLS BFD session for path path1 up on LSP R0_to_R3 RPD_MPLS_PATH_BFD_DOWN: MPLS BFD session for path path1 down on LSP R0_to_R3
Você pode configurar o BFD para todos os LSPs RSVP no roteador, um LSP específico ou o caminho principal de um LSP específico. Para configurar o BFD para RSVP LSPs, inclua as e bfd-liveness-detection as oam declarações.
oam { bfd-liveness-detection { failure-action { make-before-break teardown-timeout seconds; teardown; } failure-action teardown; minimum-interval milliseconds; minimum-receive-interval milliseconds; minimum-transmit-interval milliseconds; multiplier detection-time-multiplier; } lsp-ping-interval time-interval; lsp-ping-multiplier multiplier; }
Você pode configurar esta declaração nos seguintes níveis de hierarquia:
[edit protocols mpls][edit protocols mpls label-switched-path lsp-name][edit protocols mpls label-switched-path lsp-name primary path-name]
A bfd-liveness-detection declaração inclui as seguintes opções:
minimum-interval— especifica o intervalo mínimo de transmissão e recebimento.minimum-receive-interval— especifica o intervalo mínimo de recebimento. A faixa é de 1 a 255.000 milissegundos.minimum-transmit-interval— especifica o intervalo mínimo de transmissão. A faixa é de 1 a 255.000 milissegundos.lsp-ping-multiplier— especifica o multiplicador de tempo de detecção. A faixa é de 1 a 255.Nota:Para evitar o desencadeamento de falsos negativos, configure um tempo de detecção de falhas de BFD que é mais longo do que o tempo de redirecionamento rápido.
Você também pode configurar a opção lsp-ping-interval de ajustar o intervalo de tempo entre pings LSP. O comando de ping LSP para LSPs sinalizados por RSVP é ping mpls rsvp. Para obter mais informações sobre o ping mpls rsvp comando, consulte o CLI Explorer.
Configurando uma ação de falha para a sessão de BFD em um RSVP LSP
Quando a sessão de BFD para um RSVP LSP cai, o LSP é demolido e renunciado. O tráfego pode ser trocado para um LSP em standby, ou você pode simplesmente derrubar o caminho LSP. Todas as ações realizadas estão registradas.
Quando uma sessão de BFD para um caminho RSVP LSP cai, você pode configurar o Junos OS para ressignificar o caminho LSP ou simplesmente desabilitar o caminho LSP. Um caminho LSP de espera pode ser configurado para lidar com o tráfego, enquanto o caminho LSP primário não está disponível. O roteador pode se recuperar automaticamente de falhas LSP que podem ser detectadas pela BFD. Por padrão, se uma sessão de BFD falhar, o evento é simplesmente logado.
Para permitir que o Junos OS derrube um caminho RSVP LSP no caso de um evento BFD, inclua a failure-action declaração:
failure-action { make-before-break teardown-timeout seconds; teardown; }
Para obter uma lista dos níveis de hierarquia em que você pode incluir esta declaração, veja a seção de resumo da declaração para esta declaração.
Você pode configurar as opções ou make-before-break as teardown opções:
teardown— Faz com que o caminho LSP seja retirado e renunciado imediatamente.make-before-break— Faz com que o Junos OS tente sinalizar um novo caminho LSP antes de romper o antigo caminho LSP. Você também pode configurar a opçãoteardown-timeoutde demolir automaticamente o LSP após o período de tempo especificado se a tentativa de ressignificar o LSP falhar noteardown-timeoutintervalo. Se você especificar um valor de 0 para oteardown-timeoutintervalo, o LSP será retirado e renunciado imediatamente (o mesmo comportamento de quando você configura a opçãoteardown).
Para configurar uma ação de falha para todos os LSPs RSVP, inclua a failure-action declaração no nível de [edit protocols mpls oam bfd-liveness-detection] hierarquia. Para configurar uma ação de falha para um RSVP LSP específico, inclua a failure-action declaração no nível de [edit protocols mpls label-switched-path lsp-name oam bfd-liveness-detection] hierarquia.
Para configurar uma ação de falha para um caminho primário específico, inclua a failure-action declaração no nível de [edit protocols mpls label-switched path lsp-name primary path-name oam bfd-liveness-detection] hierarquia. Para configurar uma ação de falha para um caminho LSP secundário específico, inclua a failure-action declaração no nível de [edit protocols mpls label-switched-path lsp-name secondary path-name oam bfd-liveness-detection] hierarquia.
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.