Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Entender o recomeço gracioso para BGP

Entendendo o recurso de reinicialização gracioso BGP de longa duração

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

Historicamente, os protocolos de roteamento e o BGP, em particular, foram projetados com foco na correção, onde um aspecto significativo da "correção" é que o estado de encaminhamento de cada elemento de rede converga para o estado atual da rede o mais rápido possível. Por isso, o protocolo foi projetado para remover o estado anunciado por roteadores que caíram (de uma perspectiva BGP) o mais rapidamente possível. Usando o BGP Graciosa Restart definido no RFC 4724, a funcionalidade de convergência rápida tem sido uma tentativa de remover rapidamente o estado "obsoleto" da rede.

Durante um período de tempo, dois fatores contribuintes fizeram com que esse método de remoção rápida de estados obsoletos fosse modificado e aprimorado. A primeira é a adoção generalizada de infraestruturas de encaminhamento em túneis, por exemplo, MPLS. Essas infraestruturas eliminam o risco de alguns tipos de loops de encaminhamento que podem surgir no encaminhamento hop-by-hop e, assim, reduzem uma das motivações para uma consistência forte entre os elementos de encaminhamento. O segundo é o uso crescente do BGP como transporte para dados menos associados ao encaminhamento de pacotes do que era originalmente o caso. Exemplos incluem o uso do BGP para autodiscovamento (VPLS [RFC4761]) e programação de filtros (FLOWSPEC [RFC5575]). Nesses casos, os dados bgp assumem uma característica que não está em linha com o roteamento tradicional.

Era importante oferecer aos operadores de rede a capacidade de escolher reter dados BGP por um período mais longo, quando o plano de controle BGP falha por algum motivo. Embora as propriedades do BGP Gracioso Restart estejam próximas desse requisito desejado para preservar as informações BGP por mais tempo, existem várias lacunas, mais notadamente no tempo máximo para o qual as informações "obsoletas" podem ser retidas — a reinicialização graciosa impõe uma limitação de 4095 segundos no limite superior. O Junos OS oferece suporte a uma capacidade BGP chamada recurso de reinicialização graciosa de longa duração para que as informações obsoletas possam ser retidas por mais tempo em uma redefinição de sessão. Ela também oferece suporte a uma nova comunidade BGP, "LLGR_STALE", para marcar essas informações. Essas informações obsoletas devem ser tratadas como menos preferidas, e seu anúncio limitado a alto-falantes BGP que oferecem suporte ao novo recurso.

A reinicialização graciosa (LLGR) bgp de longa duração permite que uma operadora de rede escolha manter informações de roteamento obsoletas de um peer BGP com falha por muito mais tempo do que a instalação BGP Graciosa Restart existente. Essa funcionalidade para manter as rotas BGP por mais tempo está de acordo com o rascunho do IETF, Support for Long-Lived BGP Graciosa Restart — draft-uttaro-idr-bgp-persistence-03. De acordo com este rascunho, a reinicialização graciosa (LLGR) de longa duração deve ser explicitamente configurada por NLRI, e inclui provisões para evitar a disseminação de informações obsoletas para outros pares que não reconhecem e validam a LLGR. Os seguintes benefícios e operações são causados pela LLGR:

  • As rotas de nós com falha são retidas por um período de tempo configurado (na ordem dos dias).

  • Você pode examinar os estados de negociação por NLRI LLGR usando comandos show apropriados.

  • Você pode ver se a LLGR está atualmente em vigor para um peer e, se for eficaz, o período após o qual expira.

  • As rotas obsoletas retidas pela LLGR estão explicitamente marcadas na saída do show bgp neighbor comando.

  • As rotas obsoletas aprendidas com outros vizinhos são explicitamente marcadas na saída do show bgp neighbor comando (usando comunidades bem definidas).

Embora a metodologia LLGR possa ser aplicada a vários cenários diferentes, um cenário específico é o objetivo mais importante desse recurso. Em um cenário em que ocorre uma perda de conectividade entre um refletor de rota e um cliente, incluindo conectividade intermitente que pode fazer com que uma conexão seja redefinida antes que toda a RIB possa ser transmitida, tal falha não resulta em uma reinicialização. Além disso, tal fenômeno não implica que exista qualquer tipo de problema de conectividade entre os clientes e os next-hops anunciados pelo refletor de rota. Espera-se que um tempo típico de reinicialização de longa duração seja na ordem de 12 horas.

Todas as diretrizes de comportamento e pontos operacionais descritos no rascunho do IETF, draft-uttaro-idr-bgp-persistence-03, para LLGR são suportados. Além disso, a compatibilidade retrógrada com os recursos existentes do Junos OS em lançamentos anteriores ao Lançamento 15.1, especificamente o recomeço e o roteamento sem parar (NSR), são suportados. Quando a LLGR está configurada, a reinicialização graciosa opera da maneira existente, exceto conforme explicitamente ilustrado no rascunho da Internet. Você também pode configurar o LLGR e o NSR ao mesmo tempo e alcançar a funcionalidade LLGR completa. Como um pré-requisito para LLGR, o suporte para o projeto do IETF, suporte a mensagem de notificação para BGP Graciosa Restart — draft-ietf- idr-bgp-gr-notification-01, é implementado. Esta proposta estende o comportamento da GR comum para permitir que ela se proteja contra interrupções de comunicações e erros de protocolo.

Entender a configuração do período máximo para a geração automática de keepalives BGP por temporadores de kernel após a transição

No Junos OS, o roteamento ativo sem parar (NSR) usa a mesma infraestrutura que a comutação graciosa do Mecanismo de Roteamento (GRES) para preservar as informações de interface e kernel. No entanto, o NSR também salva as informações do protocolo de roteamento executando o processo de protocolo de roteamento (rpd) no mecanismo de roteamento de backup. Ao salvar essas informações adicionais, o NSR é autônomo e não conta com roteadores de helper (ou switches) para ajudar a plataforma de roteamento a restaurar as informações do protocolo de roteamento. O NSR é vantajoso em redes onde roteadores vizinhos (ou switches) não oferecem suporte a extensões de protocolo de reinicialização graciosas. Como resultado dessa funcionalidade aprimorada, o NSR é um substituto natural para uma reinicialização graciosa.

O automerge de roteamento ativo sem parar é um dos componentes do kernel da replicação do soquete. No switchover, esse componente mescla os pares de soquete automaticamente do backup ao mecanismo de roteamento principal. A transição do NSR do backup para a primária acontece quando o rpd emite uma chamada de fusão para cada par de soquetes secundários para mesclá-los a um único soquete, o que pode resultar em um atraso. Para evitar esse atraso, um módulo de automerge no kernel desacopla o soquete secundário mesclagem a partir de rpd e mescla automaticamente tomadas secundárias no switchover para que o thread de alta prioridade rpd aproveite isso e gere uma manutenção mais rápida para sustentar conexões TCP no switchover.

Por padrão, o BGP não se inscreve para o serviço de geração keepalive automático fornecido pelo kernel logo após o evento de switchover do backup para o principal. Para isso, você precisa habilitar a nonstop-routing-options declaração em [edit routing-options] nível de hierarquia e configurar temporizadors de precisão no BGP. Configurar tempores de precisão no BGP permite que o BGP registre todas as suas sessões com o serviço de geração keepalive automático fornecido pelo kernel. Uma vez registrado, o kernel gera automaticamente keepalives usando seus timers em nome do BGP para suas sessões de controle logo após o evento de switchover do backup para o principal. Isso permite uma geração de keepalives mais confiáveis para sessões de controle com tempores muito pequenos durante o evento de switchover.

Interoperação de funcionalidades com a reinicialização graciosa do BGP há muito tempo

Este tópico contém as seções a seguir que descrevem o comportamento de trabalho de diferentes funcionalidades com a reinicialização graciosa do BGP de longa duração e as várias condições do sistema:

A partir do Junos OS Release 15.1, o Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade de reinicialização graciosa BGP.

Limitações em NLRIs suportadas

A configuração e a negociação de recursos da LLGR são suportadas para as seguintes famílias de informações de alcance da camada de rede BGP (NLRI):

  • l2vpn

  • inet labeled-unicast

  • fluxo de inet

  • alvo de rota

  • unicast inet-vpn

  • fluxo inet-vpn

  • unicast inet6-vpn

A configuração e a negociação de recursos da LLGR são impedidas para as seguintes famílias:

  • inet-MVPN

  • inet6-mvpn

  • inet-mdt

Para as famílias NLRI para as quais o recurso LLGR é impedido, ele indica que uma tentativa de cometer uma configuração que inclua uma configuração LLGR para essas famílias é rejeitada, e essas configurações não são salvas. As NLRIs associadas a essas famílias não estão incluídas em um anúncio de recursos LLGR e são desconsideradas em um anúncio de recursos llgr recebidos.

A configuração e a negociação de recursos da LLGR são permitidas, mas escondidas, para outras famílias.

Modo de reinicialização do LLGR em NSR

Quando NSR e LLGR são configurados juntos, o roteador negocia o recurso LLGR da maneira normal e regular, incluindo um tempo obsoleto de longa data para acionar o modo receptor LLGR em seus pares. No entanto, a funcionalidade completa do reinício do LLGR (atrasando a transmissão de marcadores End of RIB até que os EoRs sejam recebidos de todos os pares) não funciona sob NSR. Durante uma reinicialização completa do sistema (ambos os Mecanismos de Roteamento), o daemon de protocolo de roteamento (rpd) não espera por EoRs de outros pares antes de enviar seu próprio EoR. Ele transmite o EoR assim que transmite o conteúdo RIB atual. Essa condição pode causar interrupções transitórias quando a rede se reconverge. O NSR é considerado adequado para lidar com todos os cenários de reinicialização de mecanismos de roteamento único. A restrição do modo reiniciador afeta apenas cenários em que ambos os mecanismos de roteamento (ou ambas as cópias de rpd) reiniciam simultaneamente. A configuração do modo de reinicialização comum não está habilitada com NSR.

A configuração do modo de reiniciamento gracioso comum continua a não ser suportada com NSR.

Recursos de LLGR em níveis globais, bgp group e vizinhos BGP

O modo de receptor de reinicialização gracioso de longa duração é habilitado por padrão, a menos que o modo de receptor de reinicialização gracioso comum seja desativado. Para habilitar o recurso BGP de reinicialização graciosa (LLGR) de longa duração, inclua a long-lived receiver enable declaração no nível de [edit protocols bgp graceful-restart] hierarquia. Além de habilitar o BGP LLGR em nível global ou em todo o sistema, você também pode incluir o receptor de longa duração que permite a declaração no nível de hierarquia para configurar o [edit protocols bgp group group-name graceful- restart] LLGR para um determinado grupo BGP e no nível de hierarquia para configurar a [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] LLGR para um determinado vizinho BGP. Para desativar o mecanismo BGP LLGR, inclua a [edit protocols bgp graceful-restart]opção long-lived receiver disable de [edit protocols bgp group group-name graceful-restart], ou [editar protocolos bgp group-group-name neighbor-address graciosa-restart] nível de hierarquia. A desativação do LLGR desativa todos os recursos de LLGR (tanto os modos receptor como de reinício) para todas as famílias de NLRI. Essa propriedade é herdada por grupos da configuração global e por vizinhos da configuração do grupo.

Monitoramento e administração do BGP De longa duração, o Recomeço gracioso

Este tópico descreve os comandos operacionais e seu significado para permitir que você analise e visualize os parâmetros relacionados à reinicialização graciosa do BGP há muito tempo. Você pode analisar os contadores e métricas estatísticas relacionados a qualquer perda de tráfego e tomar uma medida corretiva apropriada. Os campos exibidos na saída dos comandos do show ajudam a diagnosticar e depurar o desempenho da rede e os problemas de eficiência no tratamento do tráfego.

A clear bgp neighbor neighbor-address stale-routes causa de quaisquer rotas obsoletas atualmente sendo mantidas para o vizinho especificado por causa da reinicialização graciosa (GR) ou das operações de modo receptor de reinicialização graciosa (LLGR) de longa duração. O clear bgp neighbor neighbor-address gracefully comando é o mesmo clear bgp neighbor hard que (o padrão para clear bgp neighbor), mas não usa o novo subcódigo Hard Reset nas mensagens Notificar e Cessar que são enviadas. Isso permite que o vizinho entre no modo de ajuda GR ou LLGR, se negociado. A sessão ainda está liberada neste roteador, e este roteador não entra no modo de ajuda GR ou LLGR.

Um comando oculto clear está disponível para o bgp recurso de reinicialização graciosa de longa duração para fins de depuração:

clear bgp neighbor neighbor-address socket.

Esse comando quebra a conexão TCP para uma sessão de peering estabelecida. Esta é a única implicação direta do comando e todas as outras implicações são efeitos colaterais da conexão sendo quebrada. O efeito resultante é que (a menos que as extensões de notificação de GR tenham sido desabilitadas) ambos os lados da conexão entrarão no modo de helper GR ou LLGR, se negociado, e a conexão TCP será restabelecida.

A saída do show bgp neighbor comando é aprimorada para exibir as seguintes informações adicionais:

  • A opção de reinicialização graciosa de longa duração

  • Os parâmetros LLGR que os peer negociaram

  • Os parâmetros LLGR que o roteador de reinicialização negociou

  • Os tempos são exibidos usando o formato daemon de protocolo de roteamento (rpd) %#0T:

    <weeks>w<days>d <hours>:<minutes>:<seconds>

    Zero elementos líderes são omitidos, por exemplo, um valor inferior a uma semana que não inclui as semanas.

Se a reinicialização graciosa de longa duração for completamente desativada para um vizinho, o seguinte é exibido:

Se um vizinho não aceita totalmente a LLGR, o seguinte é exibido:

Embora o modo receptor LLGR esteja ativo (um peer que negociou a LLGR desconectou e ainda não se reconectou), a saída do show bgp neighbor comando exibe o tempo restante até que o LLGR expira, o tempo restante no temporizador obsoleto da GR e os detalhes do RIB:

Quando o modo de receptor de reinicialização gracioso BGP está ativo para um vizinho, informações adicionais são exibidas na saída do show bgp neighbor comando. Esses detalhes incluem a lista de NLRIs para as quais as rotas obsoletas são mantidas (NLRI estamos mantendo rotas obsoletas para o campo), o tempo restante no tempo de reinicialização (Tempo até que rotas obsoletas sejam excluídas ou se tornem um campo obsoleto de longa duração), o tempo restante no temporizador obsoleto (tempo até o fim da costela é assumido para rotas obsoletas), e os detalhes rib. O tempo é exibido no formato de Tempo Universal Coordenado (UTC) (YYYY-MM-DD-HH:MM:SS). Observe que o display de temporidade obsoleto ('Tempo até o fim da costela é assumido') também está presente quando uma sessão está ativa, mas o vizinho ainda não enviou todas as indicações de ponta da costela.

Quando a reinicialização graciosa ou o modo de ajuda LLGR estiver ativo, as informações RIB agora são exibidas pelo show bgp summary comando. Se uma sessão BGP for estabelecida no dispositivo de roteamento principal, o campo mostrará o número de rotas ativas, recebidas, aceitas e amortecedas que são recebidas de um vizinho e aparecem nas tabelas de roteamento inet.0 (principal) e inet.2 (multicast). Por exemplo, 8/10/10/2 e 2/4/4/0 indicam o seguinte:

  • 8 rotas ativas, 10 rotas recebidas, 10 rotas aceitas e 2 rotas amortecidos de um peer BGP aparecem na tabela de roteamento inet.0.

  • 2 rotas ativas, 4 rotas recebidas, 4 rotas aceitas e nenhuma rota amorteada de um peer BGP aparecem na tabela de roteamento inet.2.

O show route detail comando (com e sem a opção receive-protocol bgp ) é aprimorado para identificar rotas que são mantidas no estado obsoleto de longa duração. A LongLivedStale bandeira indica que a rota foi marcada como obsoleta por este roteador, como parte da operação do modo receptor LLGR. A LongLivedStaleImport bandeira indica que a rota estava marcada como obsoleta de LLGR quando foi recebida de um peer, ou por política de importação. Uma ou ambas as bandeiras podem ser exibidas para uma rota. Nenhuma dessas bandeiras será exibida ao mesmo tempo que a bandeira Stale (gr obsoleta comum). Quando uma rota é desaprezenciada porque está obsoleta há muito tempo, o campo de motivos inativo na saída do comando de detalhes da rota show exibe LLGR obsoleto. O novo motivo inativo obsoleto da LLGR se encaixa na hierarquia de seleção de rotas entre preferência e preferência local.

Dica:

De acordo com o Juniper Technical Assistance Center (JTAC), um comando útil para ajudar a solucionar problemas relacionados ao BGP há muito tempo é o show route table bgp.l2vpn.0 detail hidden comando. A saída do comando ajuda você a detectar se as rotas BGP ainda existem após o término da sessão BGP. O uso da opção hidden permite que você veja as rotas durante e após um incidente, e descubra informações que explicam por que as rotas estão ocultas. Outras pistas que ajudam você a solucionar problemas incluem o aparecimento de entradas de log BGP obsoletas (como bgp_mark_route_stale), e rotas ocultas aparecendo na saída do show bgp summary comando.

Aumentando a duração para preservar rotas BGP em pares que reiniciam lentamente pelo BGP Há muito tempo, o Gracioso Restart

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

O modo de receptor de reinicialização gracioso de longa duração é habilitado por padrão, a menos que o modo de receptor de reinicialização gracioso comum seja desativado. Para habilitar o recurso BGP de reinicialização graciosa (LLGR) de longa duração, inclua a long-lived receiver enable declaração no nível de [edit protocols bgp graceful-restart] hierarquia. Além de habilitar o BGP LLGR em nível global ou em todo o sistema, você também pode incluir o receptor de longa duração que permite a declaração no nível de hierarquia para configurar o [edit protocols bgp group group-name graceful-restart] LLGR para um determinado grupo BGP e no nível de hierarquia para configurar a [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] LLGR para um determinado vizinho BGP. Para desativar o mecanismo BGP LLGR, inclua a [edit protocols bgp graceful-restart]opção long-lived receiver disable de [edit protocols bgp group group-name graceful-restart], ou [editar protocolos bgp group-group-name neighbor-address graciosa-restart] nível de hierarquia. A desativação do LLGR desativa todos os recursos de LLGR (tanto os modos receptor como de reinício) para todas as famílias de NLRI. Essa propriedade é herdada por grupos da configuração global e por vizinhos da configuração do grupo.

Os vizinhos BGP podem ser configurados nos seguintes níveis de hierarquia:

  • [edit protocols bgp group group-name]— Sistema lógico padrão e instância de roteamento padrão.

  • [edit routing-instances instance-name protocols bgp group group-name]— sistema lógico padrão com uma instância de roteamento especificada.

  • [edit logical-systems logical-system-name protocols bgp group group-name]— Sistema lógico configurado e instância de roteamento padrão.

  • [edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name]— Sistema lógico configurado com uma instância de roteamento especificada.

A long-lived receiver enable substituição de uma opção de desativação herdada de um nível mais alto na configuração. Ele não permite o modo de reinício gracioso de longa duração para todas as famílias — o modo de reinício deve ser configurado explicitamente para cada família.

Para permitir que as rotas obsoletas da LLGR sejam anunciadas a vizinhos que não anunciam o recurso LLGR, incluam a advertise-to-non-llgr-neighbor declaração no [edit protocols bgp graceful-restart long-lived]nível de hierarquia [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived][edit protocols bgp group group-name graceful-restart long-lived]. Essa configuração se aplica a ambas as rotas que foram marcadas como obsoletas por este roteador, e as rotas obsoletas da LLGR recebidas dos vizinhos. Idealmente, todos os roteadores em um sistema autônomo oferecem suporte à especificação do projeto do IETF antes de ser habilitado. No entanto, para facilitar a implantação incremental, rotas obsoletas podem ser necessárias para serem anunciadas aos vizinhos que não anunciaram o recurso de reinicialização gracioso de longa data nas seguintes condições: Os vizinhos devem ser vizinhos internos (IBGP ou Confederação). A comunidade NO_EXPORT deve estar ligada às rotas obsoletas. As rotas obsoletas devem ter seu atributo LOCAL_PREF definido para zero. Se essa técnica de implantação parcial for usada, você deve definir LOCAL_PREF a zero para todas as rotas LLGR em todo o sistema autônomo. Essa configuração troca uma pequena redução na flexibilidade (os pedidos podem não ser preservados entre as rotas LLGR concorrentes) para obter consistência entre roteadores que oferecem suporte e não oferecem suporte a esta especificação. Como a consistência da seleção de rotas pode ser importante para evitar loops de encaminhamento, esta última consideração dos roteadores que não suportam essa especificação precede.

Para evitar que a comunidade BGP sem exportação seja automaticamente adicionada a rotas anunciadas para vizinhos BGP externos (presumivelmente roteadores CE), inclua a omit- no-export declaração no [edit protocols bgp graceful-restart long-lived]nível de , [edit protocols bgp group group-name graceful-restart long-lived]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] hierarquia. Em implantações de VPN, por exemplo, o BGP costuma ser usado como um protocolo PE-CE. Pode ser uma necessidade prática nessas implantações acomodar a interoperação com CEs que não podem ser atualizados facilmente para oferecer suporte a especificações como esta. Esse requisito causa um problema, ao mesmo tempo em que garante que as informações de roteamento "obsoletas" não vazem além do perímetro de roteadores que oferecem suporte a esses procedimentos onde um ou mais roteadores IBGP não são atualizados. No caso VPN PE-CE, o protocolo em uso é EBGP, e o LOCAL_PREF, um atributo de caminho somente do IBGP, é usado. A principal motivação para restringir a propagação de informações de roteamento "obsoletas" é a razão para evitar que ela se espalhe sem limite assim que sair da fronteira da confederação BGP. As implantações de VPN normalmente são restringidas topologicamente, removendo essa preocupação. Por isso, uma implementação pode anunciar rotas obsoletas em uma sessão PE-CE, quando configurada explicitamente. Nesse cenário, a implementação deve anexar a comunidade NO_EXPORT às rotas em questão por padrão, como uma proteção adicional contra rotas obsoletas que se espalham sem limite. O apego da comunidade NO_EXPORT pode ser desativado explicitamente para acomodar casos excepcionais. Talvez seja necessário anunciar rotas obsoletas para um CE em algumas implantações de VPN, mesmo que a CE não ofereça suporte a essa especificação. Nesse caso, se você configurar os roteadores PE para anunciar tais rotas, você deve notificar o operador do CE que recebe as rotas, e o CE deve ser configurado para depreferir as rotas. Implementações BGP típicas realizam essa operação combinando com a comunidade LLGR_STALE e definindo a LOCAL_PREF para rotas correspondentes a zero.

Quando o modo receptor LLGR está ativado ou desativado, a sessão é redefinida. Esse comportamento permite que o novo valor de capacidade seja enviado ao vizinho. Quando a opção advertise-to-non-llgr-neighbor está ativada ou desabilitada, a política de exportação é reavaliada e as rotas obsoletas da LLGR podem ser anunciadas ou retiradas. Quando a opção omit-no-export é adicionada ou removida, a sessão é reiniciada. Este restante de uma sessão permite que as rotas obsoletas da LLGR sejam readvertidas com ou sem a comunidade sem exportação (que é adicionada fora da política de exportação).

Para permitir que o BGP seja um recurso de reinicialização gracioso de longa data no sistema ou no nível global e configurar suas propriedades:

Para habilitar a capacidade de reinicialização graciosa do BGP há muito tempo no nível do grupo BGP e configurar suas propriedades:

Para permitir que o BGP seja um recurso de reinicialização gracioso de longa duração no nível do vizinho ou do grupo de peer e configurar suas propriedades:

Configurar comunidades bgp de reinício gracioso de longa duração em políticas de roteamento

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

Duas novas comunidades conhecidas são introduzidas. Essas novas comunidades BGP podem ser usadas em qualquer um dos níveis de hierarquia de configuração como outras comunidades simbólicas conhecidas (como sem anúncios, sem exportação e sem subconfiguração de exportação) no atributo comunitário de definições de rotas estáticas ou em uma definição da comunidade de opções de políticas. As duas novas comunidades são as seguintes:

  • llgr-stale— Adiciona uma comunidade a uma rota obsoleta de longa data quando ela é readvertida.

  • no-llgr— Marca rotas que um alto-falante BGP não deseja ser retida pela LLGR. O recurso de mensagem de notificação não tem parâmetros de configuração associados.

Você pode incluir a e no-llgr as llgr-stale opções com a community name members declaração para associar informações da comunidade BGP a uma rota estática, agregada ou gerada nos seguintes níveis de hierarquia:

Para configurar as comunidades de reinicialização graciosas de longa duração do BGP para uso em uma condição de correspondência de políticas de roteamento:

Configurar LLGR não exige que a reinicialização graciosa do BGP também seja configurada. Os valores para as comunidades já conhecidas e sem llgr são 0xFFFF0006 e 0xFFFF0007, respectivamente. Os privilégios são os mesmos dos protocolos bgp. A seção de reinicialização graciosa de longa duração é visível apenas para famílias l2vpn, inet labeled-unicast, inet flow e route-target. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.

O Junos OS também oferece suporte para configurar uma política de exportação BGP que corresponda ao estado de uma rota para a reinicialização graciosa do BGP há muito tempo. Você pode associar a comunidade que você definiu anteriormente e uma lista de prefixos de endereço em uma política de roteamento para aceitar ou rejeitar seletivamente as rotas de reinicialização graciosa de longa duração para os prefixos especificados, da seguinte forma:

Duas declarações de configuração ocultas são adicionadas sob o [edit protocols bgp graceful-restart] nível de hierarquia para configuração global, de nível de grupo e de nível de grupo vizinho.

A disable-notification-flag declaração no [edit protocols bgp graceful-restart]nível de , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hierarquia desativa a transmissão da bandeira N na negociação de recursos de reinicialização graciosa. A disable-notification-extensions declaração no [edit protocols bgp graceful-restart]nível de , [edit protocols bgp group group-name graceful-restart]ou [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] hierarquia também desativa a transmissão da bandeira N na negociação de recursos de reinicialização graciosa, mas, além disso, desativa as novas regras para invocação do modo receptor de reinicialização gracioso conforme especificado no rascunho de notificação bgp-gr-notification do IETF e desativa a transmissão do subcódigo Hard Reset. O subcódigo Hard Reset continua a ser observado quando recebido em uma mensagem Notificar ou cessar.

Para desativar a transmissão de bandeiras N e desabilitar regras para desencadear uma reinicialização graciosa em nível global ou em todo o sistema:

Para desativar a transmissão de bandeiras N e desabilitar regras para desencadear uma reinicialização graciosa no nível do grupo:

Para desabilitar a transmissão de bandeiras N e desabilitar regras para desencadear uma reinicialização graciosa no nível vizinho ou de pares:

Configuração de negociação de modo de reinício gracioso de longa duração para uma família de endereços específica em sistemas lógicos e instâncias de roteamento

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

Você também pode configurar o mecanismo de negociação do modo de reinicialização gracioso BGP para uma família de endereços em particular, em vez de configurar esse recurso para todas as famílias de endereços em um sistema, sistema lógico ou instância de roteamento. Para habilitar o BGP LLGR para uma família de endereços específica, inclua a graceful-restart long-lived restarter stale-time interval declaração em um dos seguintes níveis de hierarquia.

Cada tabela de roteamento é identificada pela família de protocolo ou indicador familiar de endereço (AFI) e por um identificador familiar de endereço subsequente (SAFI). O parâmetro AFI pode ser um dos (l2vpn | inet | route-target) protocolos e o parâmetro SAFI pode ser qualquer um dos protocolos para a (flow | labeled-unicast) família inet e um dos protcols para a (auto-discovery-mspw | auto-discovery-only | signaling) família L2VPN..

Configurar LLGR não exige que a reinicialização graciosa do BGP também seja configurada. A seção de reinicialização graciosa de longa duração é visível apenas para famílias l2vpn, inet labeled-unicast, inet flow e route-target. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.

As estrofes na seção de configuração do reinício gracioso por família permitem a negociação do modo de reinício do LLGR para o BGP globalmente, ou para um grupo ou vizinho. Os valores são herdados por grupos da configuração global e por vizinhos da configuração do grupo. O atributo de desativação é usado para substituir a configuração herdada de um nível mais alto. Ele não desativa o modo receptor LLGR; você deve desativar o modo receptor LLGR explicitamente para todas as famílias conforme necessário. Um atributo oculto enable pode ser usado para substituir um atributo de desativação herdado. Configurar um reinício de longa duração de recomeço gracioso no nível vizinho (quando não está configurado no nível do grupo contendo ou globalmente) faz com que um grupo interno seja dividido. Quando o reinício do LLGR está habilitado ou desativado para uma família ou o tempo obsoleto é alterado, a sessão é redefinida para que o novo recurso possa ser enviado ao vizinho.

A faixa de valores para o tempo obsoleto é de 1 a 16777215 (2^24 – 1) segundos. O valor é um inteiro simples que oferece o número de segundos por padrão, mas também pode ser especificado usando a seguinte notação:

[< semanas>w] [<days>d] [<horas>h] [<minutos>m] [<segundos>] Por exemplo, você pode especificar 27 dias como 27d, 648h, 38880m ou 2332800s. 90 minutos podem ser configurados como 1h30m, 90m ou 5400s. O número especificado de dias é multiplicado por 86400, o número de horas em 3600 e o número de minutos em 60; estes são adicionados aos segundos para obter o total. Um formato combinado de dias e horas, em unidades de período de tempo diferentes, como 1d36h são permitidas, desde que o total especificado não exceda o tempo máximo de obsoleto.

Além disso, os tempos também podem ser configurados usando a seguinte notação: <horas>:<minutos>:<segundos> Por exemplo, 12:00:00 especifica 12 horas. As horas e minutos são opcionais.

As duas notações podem ser combinadas, por exemplo, 2w1d 12:00:02 especifica duas semanas, um dia, doze horas e dois segundos (1339202 segundos). (Observe que o CLI requer cotações duplas em torno de um valor como este com espaços nele.) Expresso nesta notação, o tempo máximo obsoleto é de 27w5d 04:20:15 (27 semanas, 5 dias, 4 horas, 20 minutos e 15 segundos). Enquanto o comando de configuração do show exibe os valores configurados de fato, quando os temporizadors associados são exibidos em comandos de show em tempo de execução, como show bgp neighbor, os valores são normalizados, como 1d36h tornando-se 2d 12:00:00. As regras completas para exibir tempos LLGR normalizados dependem da configuração de clear bgp neighbor neighbor-address gracefully comando.

Para configurar as características de reinicialização graciosas do BGP por endereço e a família de endereços por endereço subsequente em nível global para um sistema lógico ou uma instância de roteamento:

Configuração do BGP de longa duração Recomeço gracioso por família de endereços em nível global para sistemas lógicos

Configuração de recomeço gracioso BGP de longa duração por família de endereços em nível global para instâncias de roteamento

Para configurar as características de reinicialização graciosas bgp de longa duração por família de endereço e a família de endereços por endereço subsequente no nível do grupo BGP para um sistema lógico ou uma instância de roteamento:

Configuração do BGP de longa duração recomeço gracioso por família de endereços no nível do BGP Group para sistemas lógicos

Configuração de recomeço gracioso BGP de longa duração por família de endereços no nível do BGP Group para instâncias de roteamento

Para configurar as características de reinicialização graciosas do BGP de longa duração por família por endereço e a família de endereços subsequentes no nível do grupo vizinho BGP para um sistema lógico ou uma instância de roteamento:

Configuração do BGP de longa duração Recomeço gracioso por família de endereços no nível do BGP Neighbor Group para sistemas lógicos

Configuração de recomeço gracioso BGP de longa duração por família de endereços no nível do BGP Neighbor Group para instâncias de roteamento

Informando o roteador de ajuda ou peer BGP sobre a retenção de rotas, configurando a bit do estado de encaminhamento para todas as famílias de endereços e para uma família de endereços específica

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

Após uma sessão bgp cair e antes da sessão ser restabelecida, as rotas obsoletas podem ser retidas por até dois períodos consecutivos, controladas pelo tempo de reinicialização e parâmetros de tempo obsoletos de longa duração, respectivamente. Durante o primeiro período, as modificações de roteamento são evitadas, mas com uma filtragem potencial de roteamento nulo do tráfego. Durante o segundo período, a possível filtragem de roteamento nulo do tráfego pode ser reduzida, mas mudanças de roteamento são visíveis em toda a rede. Em seu ambiente de rede, a configuração dos parâmetros relevantes para uma determinada aplicação deve considerar as compensações, a dinâmica da rede e os cenários de falha potenciais. Se necessário, o primeiro período pode ser ignorado pela configuração local ou definindo o tempo de reinicialização no recurso de reinicialização gracioso para zero, não listando os indicadores familiares de endereço (AFI) e um subsequente identificador de família de endereços (SAFI) nesse recurso.

A configuração do bit F (e a parte "Estado de encaminhamento" da capacidade de GR que acompanha) depende, em parte, de considerações de implantação. O bit F pode ser interpretado para indicar que o roteador de ajuda precisa liberar rotas associadas (se a bit estiver liberada). Um cenário importante no qual a LLGR é usada é para rotas mais semelhantes à configuração do que ao roteamento tradicional (encaminhamento hop-by-hop em vez de roteamento baseado em túnel). Para essas rotas, pode ser útil definir sempre o bit F, independentemente de outras considerações. Da mesma forma, para entidades somente de plano de controle, como refletors de rota dedicados, que não participam do plano de encaminhamento, é preferido que a bit F seja sempre definida. No geral, a diretriz a ser adotada é que, se a perda de estado no roteador de reinicialização pode razoavelmente causar um loop de encaminhamento ou uma rota nula, o bit F deve ser definido criteriosamente, dependendo se o estado foi mantido. Você pode determinar se o bit F precisa ser definido ou não, com base nas suas necessidades de implantação e configurações. Talvez seja necessário anunciar rotas obsoletas para um CE em algumas implantações de VPN, mesmo que a CE não ofereça suporte a essa especificação. Nesse cenário, o operador de rede que configura seu PE para anunciar tais rotas deve notificar o operador do CE que recebe as rotas, e o CE deve ser configurado para depreferência das rotas. Normalmente, as implementações BGP executam esse comportamento combinando na comunidade LLGR_STALE e definindo a LOCAL_PREF para rotas correspondentes a zero.

Você pode especificar o bit Forwarding State, que é uma opção de configuração BGP que pode ser definida nos níveis global, de grupo e vizinho, para qualquer sistema lógico ou instância de roteamento. Para especificar a bit Do Estado de Encaminhamento no nível global, do grupo BGP ou do vizinho BGP, inclua a forwarding-state-bit (as-rr-client | from-fib) declaração no [edit protocols bgp graceful-restart]nível de hierarquia[edit protocols bgp group-group-name graceful-restart][edit protocols bgp group-group-name neighbor neighbor-address graceful-restart]. O atributo de estado-bit de encaminhamento controla como o bit Do Estado de Encaminhamento é definido tanto em anúncios graciosos de reinicialização quanto em anúncios de recursos de reinicialização graciosos de longa duração. Por padrão, o valor depende se o vizinho é um cliente refletor de rotas. Se o vizinho não for um cliente refletor de rotas, o valor é definido de acordo com o estado da FIB associada em conformidade com a RFC 4724. Se o vizinho for um cliente refletor de rota, o valor é definido para 1 para todas as famílias, exceto inet unicast e inet6 unicast, que usam o estado da FIB associada. A as-rr-client opção define o comportamento para que todas as famílias de endereços sejam iguais à funcionalidade de um cliente refletor de rotas. A opção from-fib força o comportamento de todas as famílias de endereços como seriam para um cliente não refletor de rotas.

Para configurar a negociação da bandeira de estado de encaminhamento em nível global:

Para configurar a negociação da bandeira de estado de encaminhamento no nível do grupo:

Para configurar a negociação da bandeira de estado de encaminhamento no nível vizinho ou de grupo de pares:

Além da configuração global para a bit Estado de encaminhamento, o comportamento de bits do Estado de encaminhamento pode ser especificado para famílias individuais. Mudar a configuração de estado-bit de encaminhamento não tem efeito em nenhuma sessão existente. Para especificar a bit do Estado de Encaminhamento para uma família de endereços em particular, inclua a forwarding-state-bit (set | from-fib) declaração no [edit protocols bgp graceful-restart family address-family subsequent-address-family]nível, [edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family]ou [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] hierarquia em um sistema lógico e uma instância de roteamento. As opções de configuração BGP por família são adicionadas para controlar o bit Forwarding State em anúncios graciosos de reinício e recursos de reinicialização graciosos de longa duração. Eles podem ser especificados para o sistema lógico padrão ou para um sistema lógico específico, e para a instância de roteamento primária ou uma instância de roteamento específica. O per-family forwarding-state-bit atributo substitui as regras padrão ou a configuração global para definir a bit Do Estado de Encaminhamento. A opção set obriga o estado de encaminhamento a ser definido para 1. A opção from-fib faz com que o valor seja definido de acordo com o estado da FIB associada. Mudar a configuração de estado-bit de encaminhamento por família não surtiu efeito em nenhuma sessão existente.

Os seguintes são os níveis de hierarquia de configuração completos nos quais você pode incluir a forwarding-state-bit (set | from-fib) declaração para configurar o estado de encaminhamento bit por família de endereço:

Para configurar o bit de estado de encaminhamento para BGP de longa duração, reinicie a família por endereço e a família de endereços por endereço subsequente em nível global para um sistema lógico ou uma instância de roteamento:

Configuração do estado de encaminhamento bit por endereço familiar em nível global para sistemas lógicos

Configuração do estado de encaminhamento bit por endereço familiar em nível global para instâncias de roteamento

Para configurar o bit de estado de encaminhamento para a família bgp de reinício gracioso por endereço e a família de endereços por endereço subsequente no nível do grupo BGP para um sistema lógico ou uma instância de roteamento:

Configuração da família de estado de encaminhamento bit por endereço no nível do GRUPO BGP para sistemas lógicos

Configurar a família de estado de encaminhamento bit por endereço no nível do GRUPO BGP para instâncias de roteamento

Para configurar o bit de estado de encaminhamento para BGP de longa duração, reinicie graciosamente a família por endereço e a família de endereços por endereço subsequente no nível do grupo vizinho BGP para um sistema lógico ou uma instância de roteamento:

Configuração do estado de encaminhamento bit por endereço familiar no nível do BGP Neighbor Group para sistemas lógicos

Configuração do estado de encaminhamento bit por endereço familiar no nível do BGP Neighbor Group para instâncias de roteamento

Exemplo: Preservando detalhes da rota para pares BGP lentos e latentes usando o BGP De longa duração, o Gracioso Restart

O Junos OS oferece suporte ao mecanismo para preservar os detalhes do roteamento BGP por um período mais longo de um peer BGP com falha do que a duração para a qual essas informações de roteamento são mantidas usando a funcionalidade bgp graciosa de reinicialização.

Historicamente, os protocolos de roteamento e o BGP, em particular, foram projetados com foco na correção, onde um aspecto significativo da "correção" é que o estado de encaminhamento de cada elemento de rede converga para o estado atual da rede o mais rápido possível. Por isso, o protocolo foi projetado para remover o estado anunciado por roteadores que caíram (de uma perspectiva BGP) o mais rapidamente possível. Usando o BGP Graciosa Restart definido no RFC 4724, a funcionalidade de convergência rápida tem sido uma tentativa de remover rapidamente o estado "obsoleto" da rede.

A reinicialização graciosa (LLGR) bgp de longa duração permite que uma operadora de rede escolha manter informações de roteamento obsoletas de um peer BGP com falha por muito mais tempo do que a instalação BGP Graciosa Restart existente. Essa funcionalidade para manter as rotas BGP por mais tempo está de acordo com o rascunho do IETF, Support for Long-Lived BGP Graciosa Restart — draft-uttaro-idr-bgp-persistence-03. De acordo com este rascunho, a reinicialização graciosa (LLGR) de longa duração deve ser explicitamente configurada por NLRI, e inclui provisões para evitar a disseminação de informações obsoletas para outros pares que não reconhecem e validam a LLGR.

Este exemplo descreve como configurar a funcionalidade de reinicialização graciosa do BGP há muito tempo nos roteadores da Série MX, e contém as seguintes seções:

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um roteador da Série MX com um MPC.

  • Junos OS Versão 15.1R1 ou posterior para roteadores da Série MX

Antes de configurar a reinicialização graciosa do BGP há muito tempo, certifique-se de:

  1. Configure as interfaces do dispositivo.

  2. Configure BGP.

Visão geral

A reinicialização graciosa permite que um dispositivo de roteamento em uma reinicialização informe seus vizinhos adjacentes e colegas de sua condição. Durante uma reinicialização graciosa, o dispositivo de reinicialização e seus vizinhos continuam encaminhando pacotes sem interromper o desempenho da rede. Como dispositivos vizinhos ajudam na reinicialização (esses vizinhos são chamados de roteadores de helper), o dispositivo de reinicialização pode retomar rapidamente a operação completa sem recalcular algoritmos.

O modo de receptor de reinicialização gracioso de longa duração é habilitado por padrão, a menos que o modo de receptor de reinicialização gracioso comum seja desativado. Para habilitar o recurso BGP de reinicialização graciosa (LLGR) de longa duração, inclua a long-lived receiver enable declaração no nível de [edit protocols bgp graceful-restart] hierarquia. Além de habilitar o BGP LLGR em nível global ou em todo o sistema, você também pode incluir o receptor de longa duração que permite a declaração no nível de hierarquia para configurar o [edit protocols bgp group group-name graceful-restart] LLGR para um determinado grupo BGP e no nível de hierarquia para configurar a [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] LLGR para um determinado vizinho BGP. Para desativar o mecanismo BGP LLGR, inclua a [edit protocols bgp graceful-restart]opção long-lived receiver disable de [edit protocols bgp group group-name graceful-restart], ou [editar protocolos bgp group-group-name neighbor-address graciosa-restart] nível de hierarquia. A desativação do LLGR desativa todos os recursos de LLGR (tanto os modos receptor como de reinício) para todas as famílias de NLRI. Essa propriedade é herdada por grupos da configuração global e por vizinhos da configuração do grupo.

Topologia

Considere um cenário de amostra em que você deseja aumentar o período de tempo para o qual as rotas obsoletas são mantidas para um peer BGP ou um vizinho com o endereço de 1,2,3,4. Além de especificar a duração para as quais as rotas devem ser retidas para sessões obsoletas e quando ocorre uma reinicialização graciosa de um peer, você também pode configurar roteadores BGP de determinados prefixos de endereço a serem desconsiderados quando você definir o mecanismo de reinicialização gracioso de longa data. Você pode definir uma lista de prefixos de endereço IPv4 ou IPv6 para uso em uma declaração de política de roteamento e uma comunidade BGP a ser incluída na política de roteamento. Se você definir o modificador de ação para rejeitar rotas de um determinado prefixo, essas rotas BGP não são mantidas por um período de tempo maior.

Você também pode configurar o mecanismo de negociação do modo de reinicialização gracioso BGP para uma família de endereços em particular, em vez de configurar esse recurso para todas as famílias de endereços em um sistema, sistema lógico ou instância de roteamento. Para habilitar o BGP LLGR para uma família de endereços específica, inclua a graceful-restart long-lived restarter stale-time interval declaração em um dos seguintes níveis de hierarquia.

Cada tabela de roteamento é identificada pela família de protocolo ou indicador familiar de endereço (AFI) e por um identificador familiar de endereço subsequente (SAFI). O parâmetro AFI pode ser um dos (l2vpn | inet | route-target) protocolos e o parâmetro SAFI pode ser qualquer um dos protocolos para a (flow | labeled-unicast) família inet e um dos protcols para a (auto-discovery-mspw | auto-discovery-only | signaling) família L2VPN..

Configurar LLGR não exige que a reinicialização graciosa do BGP também seja configurada. A seção de reinicialização graciosa de longa duração é visível apenas para famílias l2vpn, inet labeled-unicast, inet flow e route-target. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.

Configuração

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar no commit modo de configuração.

Configuração da lista de prefixo de endereço, comunidade BGP e política de roteamento BGP

Configurando o BGP Group, NLRI e a reinicialização graciosa de longa duração

Configuração do BGP Neighbor Group

Configuração de reinício gracioso de longa duração para o modo reinício

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre a navegação na CLI, consulte o uso do Editor de CLI no modo de configuração no Guia de Usuário da CLI.

  1. Configure a lista de prefixo de endereço, a comunidade BGP e o modificador de condições e ação de correspondência para a política de roteamento BGP.

  2. Configure o grupo BGP, a família de endereços e a funcionalidade de reinicialização graciosa de longa data para o modo reiniciador com o tempo obsoleto para fluxos.

  3. Configure o grupo vizinho BGP.

Resultados

A partir do modo de configuração, confirme sua configuração entrando no e show protocols comandosshow policy-options. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

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

Verificando se o recurso de reinicialização gracioso de longa duração está habilitado

Propósito

Verifique o recurso de reinicialização gracioso bgp de longa duração configurado para o nível de vizinho BGP

Ação

Embora o modo receptor LLGR esteja ativo (um peer que negociou a LLGR desconectou e ainda não se reconectou), a saída do show bgp neighbor comando exibe o tempo restante até que o LLGR expira, o tempo restante no temporizador obsoleto da GR e os detalhes do RIB:

Significado

A saída mostra informações sobre os vizinhos BGP.