Troubleshooting de Sessão de eBGP Parada em Estado Ativo

Introduction

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

Contribuição de William Xu, engenheiro do Cisco TAC.

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 sua rede estiver ativa, certifique-se de que você compreende o impacto potencial de qualquer comando.

Problema

Quando você configura o eBGP, a sessão pode ficar presa indefinidamente 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

Estes sintomas aparecem quando este problema ocorre:

• Os endereços IP estão acessíveis
• Ambos os peers BGP permanecem presos em ativo
• A captura de pacotes mostra que os roteadores enviam muitas redefinições de TCP
• show tcp trace error indica esse 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 obsoleto após as alterações de topologia.

Há alguns aprimoramentos feitos para o BGP. Esses dois cenários abordam mais detalhes sobre esse problema.

Observação: o iBGP (Internal Border Gateway Protocol) normalmente não alcança esse problema, já que update-source é sempre usado.

Cenário 1 - EBGP Multihop com Alteração de Topologia

Você pode criar sessões eBGP multihop entre ASR9K-1 e ASR9K-3. Os endereços IP de 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 a interface de saída.

Você pode desligar o link direto entre ASR9K-1 e ASR9K-3. Em seguida, os endereços de peer são alcançáveis através do ASR9K-2, que é o link de vários saltos, portanto, o ping é bem-sucedido. Os endereços IP 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 o ASR9K-1, o endereço IP 172.123.2.2 pode ser acessado através da sub-rede 172.123.3.0/24. Por conseguinte, estão disponíveis as entradas relevantes no LPTS. 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 o ASR9K-1 e o ASR9K-3 é desativado, os peers podem ser acessados através do 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 de eBGP entre ASR9K-1 e ASR9K-3. Os endereços IP são 172.123.3.1 e 172.123.3.2. Conforme 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 EBGP ficará presa em um estado ativo.

A causa é a mesma do cenário 1. Depois de configurar 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 está bloqueada e a sessão permanece presa em um estado ativo para sempre.

Solução

Para resolver esse problema, você precisa ativar uma atualização para LPTS. Você pode usar estas opções para resolver o problema:

• Feche/Não feche os vizinhos BGP
• Reconfiguração dos vizinhos BGP
• Reiniciar 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 BGP travada em ativo

Esse aprimoramento foi introduzido a partir do XR versão 6.1.1. 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. Às vezes, você ainda pode esperar para ver a sessão funcionando.

Mesmo com esse aprimoramento, uma sessão de BGP ainda pode ficar 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á outro aprimoramento para essa situação a partir do XR release 6.2.1.

CSCvb15128- sessão BGP travada em ativo enquanto o roteador tem o modo BGP passivo configurado

Informações Relacionadas

• ASR9000/XR: LPTS (Local Packet Transport Services, serviços de transporte de pacote local) CoPP (Políticas de plano de controle)
• Guia de configuração: implementação de LPTS
• Guia de configuração: Implementação do BGP

---