Identificar e Solucionar Problemas da Sessão do eBGP Travada no Estado Ativo

Introduction

Este documento descreve como solucionar problemas do eBGP (External Border Gateway Protocol) quando a sessão está presa no estado ativo devido a entradas incorretas de LPTS (Local Packet Transport Services).

Contribuído por William Xu, engenheiro do TAC da Cisco.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• BGP
• TCP
• LPTS para IOS XR

Componentes Utilizados

As informações neste documento são baseadas nas plataformas ASR9000 (Aggregation Services Router).

As informações apresentadas neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se a sua rede estiver ativa, certifique-se de que você entende o impacto potencial de qualquer comando.

Problema

Quando você configura o eBGP, a sessão pode ficar indefinidamente presa no modo ativo se:

• Não há nenhum comando update-source configurado
• Há uma alteração de topologia que faz com que o tráfego siga um caminho diferente

Esses sintomas estão presentes quando esse problema ocorre:

• Os endereços IP são alcançáveis
• Ambos os peers de BGP permanecem presos no modo ativo
• A captura de pacotes mostra que os roteadores enviam muitas redefinições de TCP
• show tcp trace error indica este erro para sessões BGP.

Feb 18 09:32:15.393 tcp/error 0/RSP0/CPU0 t9  Lpts set the drop flag for 179 -> 5368, drop packet (pak 0xb1cf80f3) and send a RST

Em resumo, a causa principal do problema é que as entradas LPTS não são atualizadas pela alteração de roteamento e encaminhamento. Isso significa que eles permanecem em um estado antigo após as alterações na topologia.

Há algumas melhorias feitas para o BGP. Esses dois cenários cobrem mais detalhes sobre esse problema.

Note: O iBGP (Internal Border Gateway Protocol) normalmente não atinge esse problema, pois a fonte de atualização é sempre usada.

Cenário 1 - EBGP de vários saltos com alteração de topologia

Você pode criar sessões de eBGP de vários saltos entre ASR9K-1 e ASR9K-3. Os endereços IP do peer são 172.123.1.1 e 172.123.2.2 nas interfaces físicas. Não há nenhum comando update-source configurado. Com a topologia atual, a sessão permanece no estado ativo. Isso é esperado porque ambos os roteadores usarão a interface na sub-rede 172.123.3.0/24 como interface de saída.

Você pode desligar o link direto entre ASR9K-1 e ASR9K-3. Em seguida, os endereços de peer podem ser acessados via ASR9K-2, que é o link de vários saltos, portanto, o ping é bem-sucedido. Os endereços IP de origem correspondem em ambas as extremidades, mas a sessão BGP ainda está em um estado ativo.

Quando os vizinhos BGP são configurados, as entradas LPTS são criadas de acordo com a tabela CEF (Cisco Express Forwarding). Para ASR9K-1, o endereço IP 172.123.2.2 pode ser alcançado através da sub-rede 172.123.3.0/24. Portanto, as entradas relevantes no LPTS estão disponíveis. Permite que o vizinho BGP conecte a porta 179 com o endereço IP local 172.123.3.1. Como ele tenta iniciar uma sessão TCP a partir da porta local 26036, você pode ver outra entrada para ele.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.2.2
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,26036 172.123.2.2,179

Essa saída é a mesma no ASR9K-3.

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,11126 172.123.1.1,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.1.1

Quando o link entre ASR9K-1 e ASR9K-3 é desativado, os peers podem ser acessados via caminho ASR9K-2 com um novo endereço IP de origem local. Mas a alteração de topologia não aciona a atualização de LPTS. A entrada original com a porta 179 permanece com o endereço IP local original. Isso impede que o roteador permita solicitações TCP de entrada para o novo endereço IP local. Portanto, a sessão BGP em ambas as extremidades permanece presa em um estado ativo.

Cenário 2 - eBGP com alteração de endereço de origem de atualização

Você pode implantar uma sessão eBGP entre ASR9K-1 e ASR9K-3. Os endereços IP são 172.123.3.1 e 172.123.3.2. De acordo com o novo plano, você alterou os endereços IP para 172.123.3.111 e 172.123.3.222. Se você configurar o eBGP primeiro e depois atualizar os endereços IP nas interfaces, a sessão do EBGP ficará presa em um estado ativo.

A causa é a mesma do cenário 1. Quando você configura a sessão eBGP, as entradas LPTS são geradas de acordo com a interface de saída local nesse ponto.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.3.222
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,24067 172.123.3.222,179

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,45091 172.123.3.111,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.3.111

Embora os endereços IP locais tenham sido alterados posteriormente, as entradas LPTS não são atualizadas. A solicitação TCP é bloqueada e a sessão permanece presa em um estado ativo para sempre.

Solução

Para resolver esse problema, é necessário disparar uma atualização para LPTS. Você pode usar estas opções para resolver o problema:

• Fechar/Não fechar os vizinhos BGP
• Reconfiguração dos vizinhos de BGP
• Reiniciar o processo bgp
• Configure update-source em ambas as extremidades, o que pode evitar esse problema.

Aprimoramento na versão XR

Há algumas melhorias nas versões recentes do IOS XR.

CSCuz51103 - Sessão de BGP travada no modo ativo

Esta melhoria foi introduzida a partir da versão 6.1.1 do XR. Nesta versão, quando o BGP tenta restabelecer a sessão, o LPTS atualiza suas entradas com o novo endereço IP local . O tempo de atualização depende da configuração do tempo de espera em ambas as extremidades. Você ainda pode esperar as vezes para ver a sessão ativa.

Mesmo com essa melhoria, uma sessão de BGP ainda pode estar presa em um estado ativo se você tiver configurado o modo passivo. A razão é óbvia. Se o BGP não tentar restabelecer a sessão, o endereço IP local não será verificado. Portanto, as entradas LPTS não são atualizadas.

Há outra melhoria para esta situação na versão XR 6.2.1.

CSCvb15128 - Sessão BGP presa no modo ativo enquanto o roteador tem o modo BGP passivo configurado

Informações Relacionadas

• ASR9000/XR: Local Packet Transport Services (LPTS) CoPP (Política de plano de controle)
• Guia de configuração: Implementação de LPTS
• Guia de configuração: Implementação do BGP

---