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:
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