Introdução
Este documento descreve como determinar a causa de flaps de vizinhos internos ou externos do BGP (Border Gateway Protocol) são causados por MTU.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- configuração de BGP
- Unidade máxima de transmissão (MTU)
Certifique-se de concluir estas tarefas em ambos os roteadores BGP antes de concluir os procedimentos neste documento:
- Verifique a configuração do BGP.
- Verifique se o vizinho BGP pode ser alcançado através do Internet Control Message Protocol (ICMP) e se não foram observadas quedas.
- Verifique se a interface conectada usada para peer do BGP não tem excesso de assinaturas e não tem quedas ou erros de entrada/saída.
- Verifique a utilização da CPU e da memória.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
As informações 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 a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Problema
Os vizinhos de BGP se formam; no entanto, no momento da troca de prefixo, o estado de BGP cai e os logs geram manutenções de atividade de saudação de BGP ausentes ou o outro peer termina a sessão.
Conclua estas etapas para determinar se o MTU faz com que os vizinhos de BGP sincronizem:
- Use os próximos comandos para verificar qual vizinho é afetado e a interface conectada em ambos os roteadores BGP. Se o endereço de peering for um endereço de loopback, verifique a interface conectada por meio da qual o loopback pode ser alcançado. Além disso, verifique o BGP OutQ em ambos os roteadores de peering. A OutQ diferente de zero consistente é uma forte indicação de que as atualizações não alcançam o peer devido a um problema de MTU no caminho.
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
- Verifique o MTU da interface em ambos os lados:
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- Confirme o segmento de dados máximo acordado do TCP para ambos os alto-falantes BGP:
Router#show ip bgp neigh 10.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
No exemplo acima, 1460 está correto, pois 20 bytes são atribuídos ao cabeçalho TCP e outros 20 ao cabeçalho IP.
- Confirme se o BGP usado path-mtu está habilitado:
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- Faça ping no correspondente BGP com o conjunto máximo de bits da interface MTU e DF (Não Fragmentar):
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)
- Diminua o valor do tamanho ICMP para determinar o tamanho máximo de MTU que pode ser usado:
ping 10.10.10.2 size 1300 df
Solução
Aqui estão algumas causas possíveis:
- O MTU da interface em ambos os roteadores não corresponde.
- O MTU da interface em ambos os roteadores corresponde, mas o domínio de Camada 2 sobre o qual a sessão BGP é formada não corresponde.
- A descoberta de MTU de caminho determinou o tamanho máximo de dados incorreto para a sessão TCP BGP.
- A descoberta de unidade de transmissão máxima (PMTUD - Maximum Transmission Unit Discovery) do caminho BGP pode estar falhando devido aos pacotes ICMP PMTUD bloqueados (firewall ou ACL)
Estas são as maneiras possíveis de resolver problemas de MTU:
- O MTU da interface em ambos os roteadores deve ser o mesmo; execute o comando show ip int | in MTU para verificar as configurações atuais de MTU.
- Se o MTU da interface em ambos os roteadores estiver correto (por exemplo, 1500), mas os testes de ping com o bit DF definido não excederem 1300, o domínio de Camada 2 no qual a sessão BGP afetada é formada pode incluir configurações de MTU inconsistentes. Verifique cada MTU da interface de Camada 2. Corrija o MTU da interface de Camada 2 para resolver o problema.
- Se você não puder verificar/alterar o domínio de Camada 2, você pode definir o comando global ip tcp mss para um valor menor, como 1000, que pode forçar todas as sessões de segmento de dados máx. TCP originadas localmente (que inclui BGP) para 1000. Para obter mais informações sobre esse comando, consulte a seção ip tcp mss da Referência de Comandos do Cisco IOS® IP Application Services.
Além disso, você pode usar o comando ip tcp adjust-mss para fazer troubleshooting adicional; esse comando é configurado no nível da interface e afeta todas as sessões TCP. Para obter mais informações sobre esse comando, consulte a seção ip tcp adjust-mss da Referência de Comandos do Cisco IOS IP Application Services.
- (Opcional) A PMTUD (Descoberta de Unidade Máxima de Transmissão) do Caminho BGP não pode gerar o tamanho de dados máximo correto. Você pode desabilitá-lo globalmente ou por vizinho para confirmar se essa é a causa. Quando o BGP PMTUD está desabilitado, o BGP Maximum Segment Size (MSS) assume o padrão de 536, conforme definido no RFC 879.
Para obter informações sobre como desabilitar o PMTUD, consulte a seção Configuração do Suporte BGP para Descoberta de MTU de Caminho TCP por Sessão do Guia de Configuração de BGP do Cisco IOS.
Para obter mais informações sobre PMTUD, consulte Resolver problemas de fragmentação de IPv4, MTU, MSS e PMTUD com GRE e IPsec.
Informações Relacionadas
Feedback