IP : Border Gateway Protocol (BGP)

Aletas do vizinho de BGP com o MTU que pesquisa defeitos TechNote

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como determinar se as aletas vizinhas internas ou do Protocolo de Gateway Limite externo (eBGP) (BGP) estão causadas por edições da unidade de transmissão máxima (MTU).

Contribuído por Amer Ibrahimovic, por Mani Ganesan, e por gaio Kulkarni, engenheiros de TAC da Cisco.

Pré-requisitos

Assegure-se de que você termine estas tarefas em ambos os BGP Router antes que você termine os procedimentos neste documento:

  • Verifique a configuração de BGP.
  • Verifique que o vizinho de BGP é alcançável através do Internet Control Message Protocol (ICMP) e nenhuma gota está observada.
  • Verifique que a interface conectada usada para espreitar BGP não é oversubscribed e não tem nenhuns gotas ou erros do entrada/saída.
  • Verifique o CPU e a utilização de memória.

Problema

Formulário dos vizinhos de BGP; contudo, na altura da troca do prefixo, as gotas do estado BGP e os logs gerenciem Keepalives faltante BGP olá! ou o outro par termina a sessão.

Termine estas etapas a fim determinar se o MTU faz com que os vizinhos de BGP batam:

  1. Use os comandos abaixo a fim verificar que vizinho é afetado e a interface conectada em ambos os BGP Router. Se o endereço espreitando é um endereço de loopback, verifique a interface conectada através de que o laço de retorno é alcançável. Também, verificação para o BGP OutQ em ambos os roteadores peering. O OutQ diferente de zero consistente é uma indicação forte que as atualizações não alcançam o par devido a uma edição MTU no trajeto.
    Router#show ip bgp summ | in InQ|10.10.10.2
    Neighbor     V   AS MsgRcvd MsgSent  TblVer  InQ OutQ Up/Down  State/PfxRcd
    10.10.10.2    4   3     64      62 3    0    0 00:00:3       2
    Router#show ip route 10.10.10.2
    Routing entry for 10.10.10.0/24
      Known via "connected", distance 0, metric 0 (connected, via interface)
      Routing Descriptor Blocks:
      * directly connected, via GigabitEthernet1/0
          Route metric is 0, traffic share count is 1
  2. Verifique a interface MTU em ambos os lados:
    Router#show ip int g1/0 | i MTU
    MTU is 1500 bytes
    Router#
  3. Confirme o segmento de dados máximo concordado TCP para ambos os auto-falantes de BGP:
    Router#show ip bgp neigh 20.20.20.2 | inc segment
    Datagrams (max data segment is 1460 bytes):
    Router#

    No exemplo acima, 1460 estão corretos porque 20 bytes são atribuídos ao cabeçalho de TCP e a uns outros 20 ao cabeçalho IP.

  4. Confirme se o PATH-MTU usado BGP é permitido:
    Router#show ip bgp neigh 10.10.10.2 | in tcp
    Transport(tcp) path-mtu-discovery is enabled
    Router#
  5. Sibile o bgp peer com interface MTU máxima e jogo do bit DF (Don't Fragment):
    Router#ping 10.10.10.2 size 1500 df

    Type escape sequence to abort.
    Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
    Packet sent with the DF bit set
    .....
    Success rate is 0 percent (0/5)
  6. Diminua o valor do tamanho ICMP a fim determinar o tamanho do MTU máximo que pode ser usado:
    ping 10.10.10.2 size 1300 df 

Solução

Estão aqui algumas causas possíveis:

  • A interface MTU em ambo o Roteadores não combina.
  • A interface MTU em ambo o Roteadores combina, mas o domínio da camada 2 sobre que a sessão de BGP é formada não combina.
  • O Path MTU Discovery determinou o máximo incorreto datasize para a sessão de BGP TCP.
  • O Path Maximum Transmission Unit Discovery BGP (PMTUD) poderia ser falhar devido aos pacotes ICMP PMTUD obstruídos (firewal ou o ACL)

Estão aqui os caminhos possíveis resolver edições MTU:

  1. A interface MTU em ambo o Roteadores deve ser a mesma; execute a mostra IP int | no comando mtu a fim verificar as configurações MTU atuais.

  2. Se a interface MTU em ambo o Roteadores está correta (por exemplo, 1500) mas os testes de ping com jogo do bit DF não excedem 1300, a seguir o domínio da camada 2 em que a sessão de BGP afetada é formada pôde incluir configurações incompatíveis MTU. Verifique cada interface de camada 2 MTU. Corrija a interface de camada 2 MTU a fim resolver a edição.

  3. Se você deve verificar incapaz/mudança o domínio da camada 2, você pode ajustar o comando global dos mss IP tcp ao valor menor como 1000, que forçarão sessões máximas toda localmente originadas do segmento de dados TCP (que inclui o BGP) a 1000. Para obter mais informações sobre deste comando, refira a seção dos mss IP tcp da referência de comandos dos Serviços de aplicação IP do Cisco IOS.

    Além, você pode usar o comando ip tcp adjust-mss a fim pesquisar defeitos mais; este comando é configurado a nível de interface e afeta todas as sessões de TCP. Para obter mais informações sobre deste comando, refira o IP tcp ajustam-mss a seção da referência de comandos dos Serviços de aplicação IP do Cisco IOS.

  4. (Opcional) o Path Maximum Transmission Unit Discovery BGP (PMTUD) não pôde gerar o tamanho de dados máximo correto. Você pode desabilitá-lo globalmente ou pelo vizinho a fim confirmar se esta é a causa. Quando o BGP PMTUD é desabilitado, o Maximum Segment Size BGP (MSS) opta 536 como definido no RFC 879.

    Para obter informações sobre de como desabilitar o PMTUD, refira o suporte do BGP configurando para o Path MTU Discovery TCP pela seção de sessão do guia de configuração de BGP do Cisco IOS.

    Para obter mais informações sobre do PMTUD, refira o que é PMTUD?


Document ID: 116377