Entendendo o recomeço gracioso para BGP
Entendendo o recurso de reinicialização graciosa do BGP de longa duração
O Junos OS oferece suporte ao mecanismo para preservar os detalhes de 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 do BGP.
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 essa razão, o protocolo foi projetado para remover o estado anunciado pelos roteadores que foram desativados (da 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 forte consistência entre os elementos de encaminhamento. A segunda é 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 autodiscovery (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.
Foi 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 Graciosa Restart estejam próximas desse requisito desejado para preservar as informações bgp por uma duração mais longa, existem várias lacunas, mais notavelmente no tempo máximo para o qual as informações "obsoletas" podem ser retidas — a reinicialização graciosa impõe uma limitação de limite superior de 4095 segundos. O Junos OS oferece suporte a um recurso BGP chamado 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. Ele 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) de longa duração do BGP permite que uma operadora de rede escolha manter informações de roteamento obsoletas de um peer BGP com falha muito mais tempo do que a instalação BGP Graciosa Restart existente. Essa funcionalidade para manter as rotas BGP por um período de tempo mais longo está de acordo com o rascunho do IETF, Suporte para o BGP Graciosa Restart de longa duração — draft-quesua-idr-bgp-persistência-03. De acordo com este rascunho, a reinicialização graciosa de longa data (LLGR) deve ser explicitamente configurada por NLRI, e inclui disposições para evitar a disseminação de informações obsoletas para outros pares que não reconhecem e validam o 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 de exibição apropriados.
Você pode ver se o 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 comando.
show bgp neighborAs rotas obsoletas aprendidas com outros vizinhos são explicitamente marcadas na saída do comando (usando comunidades bem definidas).
show bgp neighbor
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 ocorra uma perda de conectividade entre um refletor de rota e um cliente, incluindo a 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 próximos saltos anunciados pelo refletor de rota. Prevê-se que um típico tempo de reinicialização de longa duração esteja na ordem de 12 horas.
Todas as diretrizes de comportamento e pontos operacionais descritos no rascunho do IETF, draft-ocaso-idr-bgp-persistência-03, para LLGR são suportados. Além disso, a compatibilidade retrógrada com os recursos existentes do Junos OS em versões anteriores ao Release 15.1, especificamente o recomeço gracioso e o roteamento sem parar (NSR), é suportada. Quando o LLGR é configurado, 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 pré-requisito para LLGR, o suporte para o rascunho do IETF, suporte a mensagem de notificação para BGP Graciosa Restart — draft-ietf- idr-bgp-gr-notification-01, é implementado. Este rascunho estende o comportamento da GR comum para permitir que ela se proteja contra interrupções de comunicações e erros de protocolo.
Consulte também
Entendendo a configuração de período máximo para a geração automática de manutenções BGP por temporizantes do kernel após a mudança
No Junos OS, o roteamento ativo ininterrupto (NSR) usa a mesma infraestrutura que o gracioso switchover do Mecanismo de Roteamento (GRES) para preservar as informações de interface e kernel. No entanto, o NSR também economiza informações de 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 de protocolo de roteamento. O NSR é vantajoso em redes em que 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 tomada automaticamente do backup ao mecanismo de roteamento primário. A mudança do NSR do backup para a primária acontece quando o rpd emite uma chamada de fusão para cada par de tomadas secundárias para mesclá-los a um único socket, o que pode resultar em um atraso. Para evitar esse atraso, um módulo de automerge no kernel desacopla o soquete secundário 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 no serviço de geração de manutenção automática fornecido pelo kernel logo após o evento de switchover do backup ao primário. Para isso, você precisa habilitar a declaração no nível [] de hierarquia e configurar timers de precisão no BGP.nonstop-routing-optionsedit routing-options A configuração de timers de precisão no BGP permite que o BGP registre todas as suas sessões com o serviço de geração de manutenção automática 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 primário. Isso permite uma geração de keepalives mais confiáveis para sessões de controle com tempores muito pequenos durante o evento de switchover.
Consulte também
Interoperação de funcionalidades com o BGP De longa duração, o recomeço gracioso
Este tópico contém as seguintes seções 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 de 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 do BGP.
- Limitações nas NLRIs suportadas
- Modo de reinício do LLGR sob NSR
- Recursos de LLGR nos níveis de vizinhos globais, BGP Group e BGP
Limitações nas NLRIs suportadas
A negociação de configuração e recursos do LLGR é suportada para as seguintes famílias de informações de acessibilidade de camada de rede BGP (NLRI):
l2vpn
inet rotulado-unicast
fluxo de inet
alvo de rota
unicast inet-vpn
fluxo de inet-vpn
inet6-vpn unicast
A configuração e a negociação de recursos do LLGR são evitadas para as seguintes famílias:
inet-mvpn
inet6-mvpn
inet-mdt
Para as famílias NLRI para as quais o recurso LLGR é evitado, ele indica que uma tentativa de comprometer uma configuração que inclua uma configuração LLGR para essas famílias é recusada, e tais 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 descartadas em um anúncio de recursos LLGR recebidos.
A negociação de configuração e recursos do LLGR é permitida, mas oculta, para outras famílias.
Modo de reinício do LLGR sob NSR
Quando o NSR e o LLGR são configurados juntos, o roteador negocia o recurso LLGR da maneira habitual e regular, incluindo um tempo obsoleto de longa data para acionar o modo receptor LLGR em seus pares. No entanto, a funcionalidade completa do reiniciador LLGR (atrasando a transmissão dos marcadores End of RIB até que os EoRs sejam recebidos de todos os pares) não funciona sob o 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 reiniciador comum não está habilitada com o NSR.
A configuração comum do modo reiniciador gracioso continua a não ser suportada com O NSR.
Recursos de LLGR nos níveis de vizinhos globais, BGP Group e 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 de reinicialização graciosa (LLGR) de longa duração do BGP, inclua a declaração no nível de hierarquia.long-lived receiver enable[edit protocols bgp graceful-restart] Além de habilitar o BGP LLGR no 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 LLGR para um determinado grupo BGP e no nível de hierarquia para configurar LLGR para um vizinho BGP em particular.[edit protocols bgp group group-name graceful- restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] Para desativar o mecanismo BGP LLGR, inclua a opção , ou [editar protocolos bgp de nome de grupo de grupo vizinho-endereço gracioso-restart] nível de hierarquia.long-lived receiver disable[edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart] A desativação do LLGR desativa todos os recursos llgr (tanto os modos receptor quanto de reinício) para todas as famílias NLRI. Essa propriedade é herdada por grupos da configuração global e por vizinhos da configuração do grupo.
Consulte também
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ísticos 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 manuseio do tráfego.
A 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.clear bgp neighbor neighbor-address stale-routes O comando é o mesmo que (o padrão para ), mas não usa o novo subcódigo hard reset nas mensagens Notificar e cessar que são enviadas.clear bgp neighbor neighbor-address gracefullyclear bgp neighbor hardclear bgp neighbor Isso permite que o vizinho entre no modo de helper GR ou LLGR, se negociado. A sessão ainda está liberada neste roteador, e este roteador não entra no modo de helper GR ou LLGR.
Um comando oculto está disponível para o recurso de reinicialização graciosa de longa duração do BGP para fins de depuração:clear
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 que está 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 negociados, e a conexão TCP será restabelecida.
A saída do comando é aprimorada para exibir as seguintes informações adicionais:show bgp neighbor
A opção de reinício graciosa de longa data
Os parâmetros de LLGR que o peer negociou
Os parâmetros LLGR que o roteador de reinicialização negociou
Os tempos são exibidos usando o daemon de protocolo de roteamento (rpd) %#0T formato:
<weeks>w<days>d <hours>:<minutes>:<seconds>Os elementos líderes zero 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:
user@router> show bgp neighbor
Peer: 10.6.128.225+45824 AS 100 Local: 10.255.255.14+44542 AS 100
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Options: <LLGRHelperDisabled> {The LLGRHelperDisabled value for the Options field denotes that long-lived BGP graceful restart is completely disabled for a neighbor}
Se um vizinho não oferece suporte total à LLGR, o seguinte é exibido:
user@router> show bgp neighbor
...
Peer does not support LLGR Restarter or Receiver functionality {BGP neighor or peer does not support long-lived BGP graceful restart restarter or receiver
functionality}
Embora o modo receptor LLGR esteja ativo (um peer que negociou a LLGR desconectou e ainda não se reconectou), a saída do comando exibe o tempo restante até que o LLGR expira, o tempo restante no temporizador obsoleto da GR e os detalhes rib:show bgp neighbor
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
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 comando.show bgp neighbor Esses detalhes incluem a lista de NLRIs para as quais as rotas obsoletas são mantidas (NLRI estamos mantendo rotas obsoletas para campo), o tempo restante no tempo de reinicialização (Tempo até que rotas obsoletas sejam excluídas ou se tornem campo obsoleto de longa data), o tempo restante no temporizador obsoleto (o tempo até o fim da costela é assumido para rotas obsoletas) e os detalhes rib. O tempo é exibido no formato horário universal coordenado (UTC) (YYYY-MM-DD-HH:MM:SS). Observe que o display de temporizante obsoleto ('O 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 helper LLGR estiverem ativas, as informações rib agora são exibidas pelo comando.show bgp summary 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 amortecedas de um peer BGP aparecem na tabela de roteamento inet.0.
2 rotas ativas, 4 rotas recebidas, 4 rotas aceitas e nenhuma rota úmida de um peer BGP aparecem na tabela de roteamento inet.2.
O comando (com e sem a opção ) é aprimorado para identificar rotas que são mantidas no estado obsoleto de longa duração.show route detailreceive-protocol bgp A bandeira indica que a rota foi marcada como obsoleta por este roteador, como parte da operação do modo receptor LLGR.LongLivedStale A bandeira indica que a rota estava marcada como obsoleta de LLGR quando foi recebida de um peer, ou por política de importação.LongLivedStaleImport 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 é obsoleta há muito tempo, o campo de razão inativo na saída do comando de detalhe da rota de exibição exibe LLGR obsoleto. A nova razão inativa obsoleta da LLGR se encaixa na hierarquia de seleção de rotas entre preferência e preferência local.
user@router> show route receive-protocol bgp 10.4.12.11 detail
bgp.l2vpn.0: 38 destinations, 39 routes (37 active, 0 holddown, 1 hidden)
* 1.1.1.4:100:1.1.1.4/96 AD (1 entry, 1 announced)
Accepted LongLivedStale LongLivedStaleImport
Nexthop: 10.4.12.11
Localpref: 100
AS path: I
De acordo com o Centro de Assistência Técnica (JTAC) da Juniper, um comando útil para ajudar a solucionar problemas relacionados ao BGP há muito tempo é o comando.show route table bgp.l2vpn.0 detail hidden 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 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.hidden Outras pistas que ajudam você a solucionar esse cenário incluem a aparência de entradas de log BGP obsoletas (como ), e rotas ocultas aparecendo na saída do comando.bgp_mark_route_staleshow bgp summary
Consulte também
Aumentando a duração para a preservação de rotas BGP entre pares que reiniciam lentamente por um reinício gracioso do BGP
O Junos OS oferece suporte ao mecanismo para preservar os detalhes de 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 do 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 de reinicialização graciosa (LLGR) de longa duração do BGP, inclua a declaração no nível de hierarquia.long-lived receiver enable[edit protocols bgp graceful-restart] Além de habilitar o BGP LLGR no 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 LLGR para um determinado grupo BGP e no nível de hierarquia para configurar LLGR para um vizinho BGP em particular.[edit protocols bgp group group-name graceful-restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] Para desativar o mecanismo BGP LLGR, inclua a opção , ou [editar protocolos bgp de nome de grupo de grupo vizinho-endereço gracioso-restart] nível de hierarquia.long-lived receiver disable[edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart] A desativação do LLGR desativa todos os recursos llgr (tanto os modos receptor quanto de reinício) para todas as famílias 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 substituição de uma opção de desativação herdada de um nível mais alto na configuração.long-lived receiver enable Ele não permite o modo de reiniciador gracioso de longa data para todas as famílias — o modo reiniciador deve ser configurado explicitamente para cada família.
Para permitir que as rotas obsoletas de LLGR sejam anunciadas para vizinhos que não anunciam o recurso LLGR, incluam a declaração no nível de hierarquia.advertise-to-non-llgr-neighbor[edit protocols bgp graceful-restart long-lived][edit protocols bgp group group-name graceful-restart long-lived][edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] Essa configuração se aplica tanto a rotas que estavam marcadas como obsoletas por este roteador, quanto às rotas obsoletas de LLGR recebidas dos vizinhos. O ideal é que todos os roteadores em um sistema autônomo ofereçam suporte à especificação de rascunho do IETF antes de ser habilitado. No entanto, para facilitar a implantação incremental, rotas obsoletas podem ser exigidas para serem anunciadas aos vizinhos que não tenham anunciado o recurso de reinício gracioso de longa data sob as seguintes condições: Os vizinhos devem ser vizinhos internos (IBGP ou Confederação). A comunidade NO_EXPORT deve ser anexada às rotas obsoletas. As rotas obsoletas devem ter seu atributo LOCAL_PREF definido para zero. Se essa técnica para 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 negocia uma pequena redução na flexibilidade (o pedido pode não ser preservado entre as rotas LLGR concorrentes) para obter consistência entre roteadores que suportam e não suportam essa 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 adicionada automaticamente a rotas anunciadas para vizinhos BGP externos (presumivelmente roteadores CE), inclua a declaração no nível de , ou hierarquia.omit- no-export[edit protocols bgp graceful-restart long-lived][edit protocols bgp group group-name graceful-restart long-lived][edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] Em implantações de VPN, por exemplo, o BGP é frequentemente 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 dos 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 para 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 quando sair do limite da confederação BGP. As implantações de VPN normalmente são restringidas topologicamente, removendo essa preocupação. Por esse motivo, uma implementação pode anunciar rotas obsoletas em uma sessão de PE-CE, quando explicitamente configurada. 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 anexo da comunidade NO_EXPORT pode ser desativado explicitamente para acomodar casos excepcionais. Pode ser necessário anunciar rotas obsoletas para um CE em algumas implantações de VPN, mesmo que o 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 executam essa operação combinando na comunidade LLGR_STALE e configurando a LOCAL_PREF para rotas correspondentes a zero.
Quando o modo receptor LLGR é habilitado ou desativado, a sessão é reiniciada. Esse comportamento permite que o novo valor de recursos seja enviado ao vizinho. Quando a opção é habilitada ou desabilitada, a política de exportação é reavaliada e as rotas obsoletas da LLGR podem ser anunciadas ou retiradas.advertise-to-non-llgr-neighbor Quando a opção é adicionada ou removida, a sessão é reiniciada.omit-no-export Este resto de 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 habilitar o recurso de reinício gracioso do BGP de longa data no sistema ou nível global e configurar suas propriedades:
[edit]
protocols {
bgp {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
Para habilitar o recurso de reinício gracioso do BGP de longa duração no nível do grupo BGP e configurar suas propriedades:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
Para habilitar o recurso de reinicialização graciosa de longa duração do BGP no nível vizinho ou de grupo peer e configurar suas propriedades:
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
}
Consulte também
Configuração de comunidades de reinicialização graciosas de longa duração do BGP em políticas de roteamento
O Junos OS oferece suporte ao mecanismo para preservar os detalhes de 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 do BGP.
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ólicos bem conhecidas (como não anunciado, sem exportação e sem subconfiguração de exportação) no atributo da comunidade de definições de rotas estáticas ou em uma definição de 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 retido pela LLGR. O recurso de mensagem de notificação não tem parâmetros de configuração associados.
Você pode incluir as opções e a declaração para associar informações da comunidade BGP a uma rota estática, agregada ou gerada nos seguintes níveis de hierarquia:llgr-staleno-llgrcommunity name members
[edit dynamic policy-options], [edit logical-systems logical-system-name policy-options], [edit policy-options]
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ítica de roteamento:
[edit policy-options]
community name {
members [ llgr-stale | nollgr];
}
A configuração do LLGR não exige que a reinicialização graciosa do BGP também seja configurada. Os valores para as comunidades 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, fluxo de inet e alvo de rota. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.
O Junos OS também oferece suporte para a configuração de 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 para um reinício gracioso de longa data para os prefixos especificados, da seguinte forma:
policy-options {
prefix-list name;
community name members [ llgr-stale | nollgr];
policy-statement name{
from {
prefix-list name;
community name;
}
then {
(accept | reject)
}
}
}
Duas declarações de configuração ocultas são adicionadas sob o ] nível de hierarquia para configuração global, de nível de grupo e de nível de grupo vizinho.[edit protocols bgp graceful-restart
A declaração no nível de , ou hierarquia desativa a transmissão da bandeira N na negociação graciosa da capacidade de reinicialização.disable-notification-flag[edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] A declaração no nível de , ou hierarquia também desativa a transmissão da bandeira N na negociação graciosa de recursos de reinicialização, mas, além disso, desativa as novas regras para invocar o 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.disable-notification-extensions[edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] O subcódigo hard reset continua a ser observado quando recebido em uma notificação ou uma mensagem de cessar.
Desativar a transmissão de bandeiras N e desabilitar regras para desencadear uma reinicialização graciosa no nível global ou em todo o sistema:
[edit]
protocols {
bgp {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
Desativar a transmissão de bandeiras N e desabilitar regras para desencadear uma reinicialização graciosa no nível de grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Desativar a transmissão de bandeiras N e desabilitar regras para ativar uma reinicialização graciosa no nível vizinho ou de pares:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Consulte também
Configuração de negociação de modo 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 de 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 do BGP.
Você também pode configurar o mecanismo de negociação de modo reiniciador gracioso de longa duração do BGP para uma determinada família de endereços, 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 declaração em um dos seguintes níveis de hierarquia.graceful-restart long-lived restarter stale-time interval
Cada tabela de roteamento é identificada pela família de protocolo ou indicador familiar de endereço (AFI) e um identificador familiar de endereço (SAFI) subsequente. O parâmetro AFI pode ser um dos protocolos e o parâmetro SAFI pode ser qualquer um dos protocolos para a família inet e um dos protcols para a família L2VPN..(l2vpn | inet | route-target)(flow | labeled-unicast)(auto-discovery-mspw | auto-discovery-only | signaling)
A configuração do 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, fluxo de inet e alvo de rota. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
As estrofes na seção de configuração do reinício gracioso por família permitem a negociação do modo reiniciador 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 pode ser usado para substituir um atributo de desativação herdado.enable Configurar o reinício gracioso de longa duração no nível vizinho (quando não está configurado no nível de grupo ou globalmente) faz com que um grupo interno seja dividido. Quando o reinícior do LLGR é habilitado ou desativado para uma família ou o tempo obsoleto é alterado, a sessão é reiniciada 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 anotação:
[< semanas>] [< dias>] [<horas>h] [<minutos>] [<segundos>] Por exemplo, você pode especificar 27 dias como 27d, 648h, 38880m ou 2332800. 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 diferentes unidades de período de tempo, como 1d36h são permitidas, desde que o total especificado não exceda o tempo máximo 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 doze 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 a 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 realmente configurados, quando os timers associados são exibidos em comandos de exibição em tempo de execução, tais como , os valores são normalizados, como 1d36h tornando-se 2d 12:00:00.show bgp neighbor As regras completas para exibir tempos LLGR normalizados dependem da configuração de comando.clear bgp neighbor neighbor-address gracefully
Para configurar as características de reinício graciosas de longa duração do BGP por endereço familiar e família de endereços por endereço subsequente no 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
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Configuração do BGP de longa duração recomeço gracioso por família de endereços no nível global para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Para configurar as características de reinício graciosas de longa duração do BGP por endereço familiar e família de endereços por endereço subsequente no nível de grupo BGP para um sistema lógico ou uma instância de roteamento:
Configuração do BGP de longa duração reinício gracioso por família de endereços no nível do grupo BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Configuração do BGP De longa duração, o recomeço gracioso por família de endereços no nível do grupo BGP para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Para configurar as características de reinício graciosas de longa duração do BGP por endereço familiar e 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 de reinício gracioso do BGP de longa duração por família de endereços no nível do BGP Neighbor Group para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Configuração de reinício gracioso do BGP de longa duração por família de endereços no nível do BGP Neighbor Group para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Consulte também
Informar o roteador de ajuda bgp ou peer sobre a retenção de rotas configurando o bit de 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 de 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 do BGP.
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, controlados 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 rotas nulas do tráfego. Durante o segundo período, uma possível filtragem de rota nula do tráfego pode ser reduzida, mas as 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 um determinado aplicativo deve considerar as compensações, a dinâmica da rede e os cenários de falhas potenciais. Se necessário, o primeiro período pode ser contornado pela configuração local ou configurando o tempo de reinicialização no recurso de reinício gracioso para zero, não listando os indicadores da família de endereços (AFI) e os identificadores subsequentes da família de endereços (SAFI) nesse recurso.
A configuração do bit F (e o bit "Estado de encaminhamento" da capacidade de GR que acompanha) depende, em parte, das considerações de implantação. O bit F pode ser interpretado para indicar que o roteador de helper precisa lavar rotas associadas (se a broca ficar limpa). Um cenário importante no qual a LLGR é usada é para rotas mais semelhantes à configuração do que ao roteamento tradicional (encaminhamento salto a salto em vez de roteamento baseado em túnel). Para essas rotas, pode ser útil definir sempre a bit F, independentemente de outras considerações. Da mesma forma, para entidades somente de plano de controle, como refletores de rota dedicados, que não participam do plano de encaminhamento, é preferido que o bit F seja sempre definido. De forma geral, a diretriz a ser adotada é que, se a perda de estado no roteador reiniciador puder razoavelmente causar um loop de encaminhamento ou uma rota nula, a bit F deve ser definida de forma justa, dependendo se o estado foi retido. Você pode determinar se o bit F precisa ser definido ou não, com base nas suas necessidades de implantação e configurações. Pode ser necessário anunciar rotas obsoletas para um CE em algumas implantações de VPN, mesmo que o 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 depreferir as rotas. Normalmente, as implementações BGP executam esse comportamento combinando na comunidade LLGR_STALE e configurando a LOCAL_PREF para rotas correspondentes a zero.
Você pode especificar o bit Estado de encaminhamento, que é uma opção de configuração BGP que pode ser definida nos níveis global, de grupo e vizinho, para qualquer instância lógica de sistema ou roteamento. Para especificar a bit do Estado de encaminhamento no nível global, do grupo BGP ou do vizinho BGP, inclua a declaração no nível de , ou hierarquia.forwarding-state-bit (as-rr-client | from-fib)[edit protocols bgp graceful-restart][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 a bit do Estado de encaminhamento é definida tanto em reinicialização graciosa 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 rota. Se o vizinho não for um cliente refletor de rota, 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 opção define o comportamento de todas as famílias de endereços para ser o mesmo que a funcionalidade para um cliente refletor de rotas.as-rr-client A opção força o comportamento de todas as famílias de endereços como seriam para um cliente não refletor de rotas.from-fib
Para configurar a negociação da bandeira de estado de encaminhamento a nível global:
[edit]
protocols {
bgp {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
Para configurar a negociação da bandeira de estado de encaminhamento no nível do grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
Para configurar a negociação da bandeira de estado de encaminhamento no nível vizinho ou de grupo de pares:
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
}
Além da configuração global para a bit Estado de encaminhamento, o comportamento de bit do Estado de encaminhamento pode ser especificado para famílias individuais. Mudar a configuração de bit de estado de encaminhamento não afeta nenhuma sessão existente. Para especificar a bit do Estado de encaminhamento para uma determinada família de endereços, inclua a declaração no nível de, ou hierarquia em um sistema lógico e uma instância de roteamento.forwarding-state-bit (set | from-fib)[edit protocols bgp graceful-restart family address-family subsequent-address-family][edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family][edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] As opções de configuração BGP por família são adicionadas para controlar o bit do Estado de encaminhamento em reinício gracioso e anúncios de 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 primária de roteamento ou uma instância de roteamento específica. O atributo substitui as regras padrão ou a configuração global para definir o bit Estado de encaminhamento.per-family forwarding-state-bit A opção força a bit do Estado de encaminhamento a ser definida para 1. A opção faz com que o valor seja definido de acordo com o estado da FIB associada.set from-fib 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 declaração para configurar a família de estado de encaminhamento por endereço:forwarding-state-bit (set | from-fib)
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
Para configurar a bit de estado de encaminhamento para a família bgp de reinício gracioso por endereço de longa duração e a família de endereços por subsequente no nível global 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 global para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Configuração da família de estado de encaminhamento bit por endereço no nível global para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Para configurar o bit de estado de encaminhamento para a família bgp de reinício gracioso por endereço de longa duração e a família de endereços por endereço subsequente no nível de grupo BGP para um sistema lógico ou uma instância de roteamento:
Configurando a família de estado de encaminhamento bit por endereço no nível do grupo BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Configuração da família de estado de encaminhamento bit por endereço no nível do grupo BGP para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Para configurar o bit de estado de encaminhamento para BGP há muito tempo, reinicie a família por endereço e a família de endereços por endereço subsequente no nível de grupo vizinho do BGP para um sistema lógico ou uma instância de roteamento:
Configurando a família de estado de encaminhamento bit por endereço no nível de grupo vizinho BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Configurando a família de estado de encaminhamento bit por endereço no nível de grupo vizinho BGP para instâncias de roteamento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Consulte também
Exemplo: Preservação dos 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 de 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 do BGP.
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 essa razão, o protocolo foi projetado para remover o estado anunciado pelos roteadores que foram desativados (da 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) de longa duração do BGP permite que uma operadora de rede escolha manter informações de roteamento obsoletas de um peer BGP com falha muito mais tempo do que a instalação BGP Graciosa Restart existente. Essa funcionalidade para manter as rotas BGP por um período de tempo mais longo está de acordo com o rascunho do IETF, Suporte para o BGP Graciosa Restart de longa duração — draft-quesua-idr-bgp-persistência-03. De acordo com este rascunho, a reinicialização graciosa de longa data (LLGR) deve ser explicitamente configurada por NLRI, e inclui disposições para evitar a disseminação de informações obsoletas para outros pares que não reconhecem e validam o LLGR.
Este exemplo descreve como configurar a funcionalidade de reinicialização graciosa de longa duração do BGP em 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 o reinício gracioso de longa duração do BGP, certifique-se de:
Configure as interfaces do dispositivo.
Configure BGP.
Visão geral
A reinicialização graciosa permite que um dispositivo de roteamento em uma reinicialização informe seus vizinhos e pares adjacentes 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 os 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 de reinicialização graciosa (LLGR) de longa duração do BGP, inclua a declaração no nível de hierarquia.long-lived receiver enable[edit protocols bgp graceful-restart] Além de habilitar o BGP LLGR no 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 LLGR para um determinado grupo BGP e no nível de hierarquia para configurar LLGR para um vizinho BGP em particular.[edit protocols bgp group group-name graceful-restart][edit protocols bgp group group-name neighbor neighbor-address graceful-restart] Para desativar o mecanismo BGP LLGR, inclua a opção , ou [editar protocolos bgp de nome de grupo de grupo vizinho-endereço gracioso-restart] nível de hierarquia.long-lived receiver disable[edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart] A desativação do LLGR desativa todos os recursos llgr (tanto os modos receptor quanto de reinício) para todas as famílias 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 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 uma reinicialização graciosa de um peer ocorre, você também pode configurar roteadores BGP de determinados prefixos de endereço a serem ignorados quando você define o mecanismo de reinício 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 prefixo específico, essas rotas BGP não serão mantidas pelo período de tempo aumentado.
Você também pode configurar o mecanismo de negociação de modo reiniciador gracioso de longa duração do BGP para uma determinada família de endereços, 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 declaração em um dos seguintes níveis de hierarquia.graceful-restart long-lived restarter stale-time interval
Cada tabela de roteamento é identificada pela família de protocolo ou indicador familiar de endereço (AFI) e um identificador familiar de endereço (SAFI) subsequente. O parâmetro AFI pode ser um dos protocolos e o parâmetro SAFI pode ser qualquer um dos protocolos para a família inet e um dos protcols para a família L2VPN..(l2vpn | inet | route-target)(flow | labeled-unicast)(auto-discovery-mspw | auto-discovery-only | signaling)
A configuração do 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, fluxo de inet e alvo de rota. É proibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para outras famílias.
Configuração
- Configuração rápida da CLI
- Configurando um reinício gracioso de longa duração para o modo reiniciador
- Resultados
Configuração rápida da CLI
Para configurar rapidamente este exemplo, 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 a configuração da sua rede, copiar e colar os comandos na CLI no nível de hierarquia e, em seguida, entrar no modo de configuração.[edit]commit
Configuração da lista de prefixo de endereços, comunidade BGP e política de roteamento BGP
set policy-options prefix-list special 44.44.44.44/32 set policy-options community llgr-community llgr-stale set policy-options policy-statement llgr-import from prefix-list special set policy-options policy-statement llgr-import from community llgr-community set policy-options policy-statement llgr-import then reject
Configuração do BGP Group, NLRI e reinicialização graciosa de longa duração
set protocols bgp group ibgp-group type internal set protocols bgp group ibgp-group import llgr-import set protocols bgp group ibgp-group family inet unicast set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
Configurando o BGP Neighbor Group
set protocols bgp group ibgp-group neighbor 1.2.3.4
Configurando um reinício gracioso de longa duração para o modo reiniciador
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 como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Configure a lista de prefixo de endereço, a comunidade BGP e o modificador de condições e ações de correspondência para a política de roteamento BGP.
[edit] user@ host# set policy-options prefix-list special 44.44.44.44/32 user@ host# set policy-options community llgr-community llgr-stale user@ host# set policy-options policy-statement llgr-import from prefix-list special user@ host# set policy-options policy-statement llgr-import from community llgr-community user@ host# set policy-options policy-statement llgr-import then reject
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.
[edit] user@ host# set protocols bgp group ibgp-group type internal user@ host# set protocols bgp group ibgp-group import llgr-import user@ host# set protocols bgp group ibgp-group family inet unicast user@ host# set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
Configure o grupo vizinho BGP.
[edit] user@ host# set protocols bgp group ibgp-group neighbor 1.2.3.4
Resultados
A partir do modo de configuração, confirme sua configuração inserindo os comandos e os comandos.show policy-optionsshow protocols Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
[edit]
user@host# show policy-options
policy-options {
prefix-list special 44.44.44.44/32;
community llgr-community llgr-stale;
policy-statement llgr-import {
from {
prefix-list special;
community llgr-community;
}
then {
reject;
}
}
}
user@host# show protocols
protocols {
bgp {
group ibgp-group {
type internal;
import llgr-import;
family inet unicast {
graceful-restart {
long-lived {
restarter {
stale-time 12h;
}
}
}
}
neighbor 1.2.3.4;
}
}
}
Verificação
Confirme se a configuração está funcionando corretamente.
Verificando se o recurso de reinício gracioso de longa duração está habilitado
Propósito
Verifique o recurso de reinicialização gracioso de longa duração do BGP 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 comando exibe o tempo restante até que o LLGR expira, o tempo restante no temporizador obsoleto da GR e os detalhes rib:show bgp neighbor
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Significado
A saída mostra informações sobre vizinhos BGP.