Inleiding
Dit document beschrijft hoe de oorzaak van interne of externe BGP-buurflappen wordt veroorzaakt door MTU.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- BGP-configuratie
- Max. transmissieeenheid (MTU)
Zorg ervoor dat u deze taken op beide BGP-routers uitvoert voordat u de procedures in dit document voltooit:
- Controleer de BGP-configuratie.
- Controleer dat de BGP-buur via Internet Control Message Protocol (ICMP) kan worden bereikt en dat er geen druppels worden waargenomen.
- Controleer dat de aangesloten interface die gebruikt wordt om BGP te peer niet overgeabonneerd is en geen input/output dalingen of fouten heeft.
- Controleer de CPU en het geheugengebruik.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Probleem
BGP-buren vormen zich; op het moment van de prefixuitwisseling worden de BGP-status verlaagd en de logs genereren ontbrekende BGP hello-keepalives of de andere peer beëindigt de sessie.
Voltooi deze stappen om te bepalen of de MTU veroorzaakt dat de BGP buren flap:
- Gebruik de volgende opdrachten om te controleren welke buur is aangetast en welke interface op beide BGP-routers is aangesloten. Als het doorlopende adres een loopback-adres is, controleert u de aangesloten interface waar de loopback door kan worden bereikt. Controleer ook of de BGP OutQ op beide peer routers is ingeschakeld. De consistente non-zero OutQ is een sterke aanwijzing dat updates niet de peer te bereiken als gevolg van een MTU probleem in het pad.
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
- Controleer de interface MTU aan beide zijden:
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- Bevestig het TCP overeengekomen max datasegment voor beide BGP-speakers:
Router#show ip bgp neigh 10.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
In het bovenstaande voorbeeld is 1460 correct als 20 bytes worden toegewezen aan de TCP-header en nog eens 20 aan de IP-header.
- Bevestig als BGP gebruikte path-mtu is ingeschakeld:
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- Ping de BGP peer met max interface MTU en DF (Do not Fragment) bit set:
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)
- Verminder de waarde van de grootte ICMP om de maximumMTU grootte te bepalen die kan worden gebruikt:
ping 10.10.10.2 size 1300 df
Oplossing
Hier zijn een paar mogelijke oorzaken:
- De interface MTU op beide routers komt niet overeen.
- De interface MTU op beide routers komt overeen, maar Layer 2-domein waarover de BGP-sessie wordt gevormd, komt niet overeen.
- Path MTU-detectie bepaalde de onjuiste maximale dataset voor de TCP BGP-sessie.
- De detectie van de maximale BGP-transmissieeenheid (PMTUD) kan mislukken vanwege geblokkeerde PMTUD ICMP-pakketten (firewall of ACL)
Hier zijn mogelijke manieren om MTU problemen op te lossen:
- De interface MTU op beide routers moet het zelfde zijn; stel ip int. in werking | in opdracht MTU om de huidige MTU-instellingen te controleren.
- Als de interface MTU op beide routers correct is (bijvoorbeeld 1500) maar de ping-tests met DF-bitset niet hoger zijn dan 1300, dan kan Layer 2-domein waarop de getroffen BGP-sessie wordt gevormd inconsistente MTU-configuraties bevatten. Controleer elke Layer 2-interface MTU. Corrigeer Layer 2 interface MTU om het probleem op te lossen.
- Als u Layer 2-domein niet kunt controleren/wijzigen, kunt u de opdracht ip tcp mss global instellen op een lagere waarde zoals 1000, die alle lokaal gegenereerde TCP max-gegevenssegmentsessies (inclusief BGP) kan dwingen naar 1000. Raadpleeg voor meer informatie over deze opdracht het gedeelte IP-TCP-mesh van de opdrachtreferentie voor Cisco IOS® IP-toepassingsservices.
Daarnaast kunt u de opdracht IP TCP-aanpassing-mss gebruiken om verder problemen op te lossen; deze opdracht wordt geconfigureerd op interfaceniveau en heeft invloed op alle TCP-sessies. Raadpleeg voor meer informatie over deze opdracht de sectie IP-tcp-aanpassing van de Opdrachtreferentie voor Cisco IOS IP-toepassingsservices.
- (Optioneel) De BGP Path Max Transmission Unit Discovery (PMTUD) kan niet de juiste maximale gegevensgrootte genereren. U kunt het globaal of per buur onbruikbaar maken om te bevestigen als dit de oorzaak is. Als BGP PMTUD is uitgeschakeld, staat de BGP Maximum Segment Size (MSS) standaard op 536 zoals gedefinieerd in RFC 879.
Raadpleeg de sectie BGP-ondersteuning configureren voor TCP-pad-detectie per sessie van de Cisco IOS BGP-configuratiegids voor informatie over het uitschakelen van PMTUD.
Raadpleeg IPv4-fragmentatie, MTU, MSS en PMTUD-problemen oplossen met GRE en IPsec voor meer informatie over PMTUD.
Gerelateerde informatie
Feedback