Pesquise defeitos a sessão de eBGP colada no estado ativo

Introdução

Este original descreve como pesquisar defeitos o eBGP (Protocolo de Gateway Limite externo (eBGP)) quando a sessão está colada no estado ativo devido às entradas incorretas LPTS (serviços de transporte do pacote local).

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

Pré-requisitos

Requisitos

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

• BGP
• TCP
• LPTS para IO XR

Componentes Utilizados

A informação neste documento é baseada (a agregação presta serviços de manutenção ao roteador) nas Plataformas ASR9000.

As informações apresentadas neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se sua rede está viva, assegure-se de que você compreenda o impacto potencial dos comandos any.

Problema

Quando você configura o eBGP, a sessão pode ser colada no active indefinidamente se:

• Não há nenhum comando update-source configurado
• Há uma alteração de topologia que faça com que o tráfego tome um trajeto diferente

Estes sintomas atuais em que esta edição ocorre:

• Os IP address são alcançáveis
• Ambos os bgp peer permanecem colados no active
• A captura de pacote de informação mostra que o Roteadores envia muitas restaurações TCP
• o erro do traço tcp da mostra indica este erro para sessões de 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 de raiz da edição é que as entradas LPTS não estão atualizadas pela mudança do roteamento e da transmissão. Significa que permanecem em um estado velho após as alterações de topologia.

Há alguns realces feitos para o BGP. Estas duas encenações cobrem mais detalhe sobre esta edição.

Note: o iBGP (internal border gateway protocol) normalmente não bate esta edição desde que a atualização-fonte é usada sempre.

Encenação 1 - EBGP Multihop com alteração de topologia

Você pode construir sessões de eBGP multihop 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ísica. Não há nenhum comando update-source configurado. Com a topologia atual, a sessão fica no estado ativo. Isto é esperado porque ambo o Roteadores usará a relação na sub-rede 172.123.3.0/24 como a interface de saída.

Você pode fechar o link direto entre ASR9K-1 e ASR9K-3. Então, os endereços de peer são alcançáveis através de ASR9K-2 que é o link multihop, assim o sibilo é bem sucedido. Os endereços IP de origem combinam no ambas as extremidades, mas a sessão de BGP está ainda em um estado ativo.

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

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

Esta saída é 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 vai para baixo, os pares são alcançáveis através do trajeto ASR9K-2 com um endereço IP de origem local novo. Mas a alteração de topologia não provoca a atualização LPTS. A entrada original com porta 179 fica com o endereço IP local original. Isto impede o roteador para permitir pedidos do ingresso TCP ao endereço IP local novo. Daqui, a sessão de BGP no ambas as extremidades permanece colada em um estado ativo.

Encenação 2 - eBGP com mudança do endereço de origem da atualização

Você pode distribuir uma sessão de eBGP entre ASR9K-1 e ASR9K-3. Os endereços IP de Um ou Mais Servidores Cisco ICM NT são 172.123.3.1 e 172.123.3.2. Conforme o plano novo, você mudou os endereços IP de Um ou Mais Servidores Cisco ICM NT a 172.123.3.111 e a 172.123.3.222. Se você configura o eBGP primeiramente e atualiza então os endereços IP de Um ou Mais Servidores Cisco ICM NT nas relações, a sessão de eBGP está colada em um estado ativo.

A causa é mesma que a encenação 1. Uma vez que você configura a sessão de eBGP, as entradas LPTS estã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 sejam mudados mais tarde, as entradas LPTS não são atualizadas. O pedido TCP é obstruído e a sessão permanece colada em um estado ativo para sempre.

Solução

Para resolver esta edição, você precisa de provocar uma atualização a LPTS. Você pode usar estas opções para resolver a edição:

• Shut/No fechou os vizinhos de BGP
• Reconfiguração dos vizinhos de BGP
• BGP do processo do reinício
• Configurar a atualização-fonte no ambas as extremidades que podem impedir esta edição.

Realce na liberação XR

Há alguns realces em liberações recentes IO XR.

CSCuz51103 - Sessão de BGP colada no active

Este realce introduzido da liberação 6.1.1 XR. Nesta liberação, quando o BGP tenta restabelecer a sessão, LPTS atualiza suas entradas com o endereço IP local novo. O update time depende da configuração do tempo de contenção no ambas as extremidades. Você pode ainda esperar às vezes para ver acima a sessão.

Mesmo com este realce, uma sessão de BGP ainda pode ser colada em um estado ativo se você configurou o modo passivo. A razão é óbvia. Se o BGP não tenta restabelecer a sessão, o endereço IP local não está verificado. Daqui as entradas LPTS não são atualizadas.

Há um outro realce para esta situação da liberação 6.2.1 XR.

CSCvb15128- a sessão de BGP colou no active quando o roteador tiver o modo passivo BGP configurado

Informações Relacionadas

• ASR9000/XR: Serviços de transporte do pacote local (LPTS) CoPP (Policiamento do plano de controle)
• Manual de configuração: Executando LPTS
• Manual de configuração: Executando o BGP

---