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.

    213710-troubleshoot-ebgp-session-stuck-in-activ-00.png

    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