Problemen met het Border Gateway Protocol oplossen
Inhoud
Inleiding
In dit document wordt beschreven hoe u de meest voorkomende problemen met het Border Gateway Protocol (BGP) kunt oplossen en worden basisoplossingen en richtlijnen geboden.
Voorwaarden
Vereisten
Er zijn geen specifieke voorwaarden van toepassing op dit document. Basiskennis van het BGP-protocol is nuttig, u kunt de BGP Configuration Guide raadplegen voor meer informatie.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardwareversies, maar opdrachten zijn van toepassing voor Cisco IOS® en Cisco IOS® XE.
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.
Achtergrondinformatie
Dit document beschrijft een basisgids voor het oplossen van de meest voorkomende problemen in het Border Gateway Protocol (BGP), geeft corrigerende acties, nuttige opdrachten/fouten om de oorzaak van de problemen op te sporen en beste praktijken om mogelijke problemen te voorkomen. Houd er rekening mee dat alle mogelijke variabelen en scenario's niet kunnen worden overwogen en dat een diepere analyse vereist kan zijn door Cisco TAC.
Topologie
Gebruik dit topologiediagram als referentie voor de uitvoer die in dit document wordt geleverd.
Scenario's en problemen
aangrenzende laag
Als een BGP-sessie niet beschikbaar is en niet verschijnt, vindt u hier de huidige status van de sessieshow ip bgp all summary command.:
- Als de sessie niet up state is, kan deze variëren tussen IDLE en ACTIVE (afhankelijk van het Finite State Machine-proces).
- Als de sessie is geopend, ziet u het aantal ontvangen voorvoegsels.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Geen connectiviteit
De eerste vereiste die moet worden gewaarborgd, is de connectiviteit tussen beide peers, zodat TCP-sessie op poort 179 kan worden vastgesteld. Of ze zijn direct verbonden of niet. Een eenvoudige ping is hiervoor handig. Als peering wordt ingesteld tussen loopback-interfaces, moet een loopback naar loopback-ping worden uitgevoerd. Als een ping-test wordt uitgevoerd zonder specifieke loopback als de broninterface, wordt het uitgaande fysieke interface-IP-adres gebruikt als het bron-IP-adres van het pakket in plaats van het loopback-IP-adres van de router.
Als ping niet succesvol is, overweeg dan deze oorzaken:
- Geen geconnecteerde route peer of helemaal geen route: kan
show ip route peer_IP_addressworden gebruikt. - Probleem met laag 1: fysieke interface, SFP (connector), kabel of extern probleem (transport en provider indien van toepassing) moet worden overwogen.
- Controleer alle firewall- of toegangslijsten die de verbinding kunnen blokkeren.
Als ping succesvol is, overweeg dan het volgende:
Configuratieproblemen
- Verkeerd IP-adres of AS geconfigureerd: voor een verkeerd IP-adres wordt een dergelijk bericht niet weergegeven, maar zorg ervoor dat de juiste configuratie wordt uitgevoerd. Voor verkeerde AS, moet u een bericht zien zoals bij het
show loggingcommando.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Controleer de BGP-configuratie aan beide uiteinden om de AS-nummers of het IP-adres van de peer te corrigeren.
- Router-ID dupliceren:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Controleer de BGP-ID aan beide uiteinden via show ip bgp all summary en corrigeer het duplicaatprobleem. Dit kan handmatig worden bereikt met global command bgp router-id X.X.X.X onder de configuratie van de bgp-router. Zorg er als beste praktijk voor dat de router-ID handmatig is ingesteld op een uniek nummer.
- BGP-bron en TTL:
De meeste iBGP-sessies worden geconfigureerd via de loopback-interfaces die via een IGP bereikbaar zijn. Deze loopback-interface moet expliciet worden gedefinieerd als de bron, Doe dit met de opdracht neighbor ip-address update-source interface-id .
Voor eBGP peer worden direct verbonden interfaces meestal gebruikt voor peering, en er is een controle voor Cisco IOS / Cisco IOS XE om dit doel te bereiken, of het probeert zelfs geen sessie vast te stellen. Als eBGP wordt geprobeerd van loopback naar loopback op direct aangesloten routers, kan deze controle worden uitgeschakeld voor een specifieke buur aan beide uiteinden via neighbor ip-address disable-connected-check .
Echter, als er meerdere hop tussen de eBGP-peers zijn, is een juiste hoptelling vereist, zorg ervoor dat neighbor ip-address ebgp-multihop [hop-count]de hop is geconfigureerd met de juiste hoptelling, zodat de sessie kan worden vastgesteld.
Als de hop-count niet is opgegeven, is de standaard TTL-waarde voor iBGP-sessies 255, terwijl de standaard TTL-waarde voor eBGP-sessies 1 is.
Problemen met TCP-sessies
Een handige actie om poort 179 te testen is een handmatig telnet van de ene peer naar de andere:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Ofwel een open/gesloten verbinding, of een verbinding geweigerd door een externe host geeft aan dat pakketten het externe einde bereiken, zorg er dan voor dat er geen problemen zijn met het besturingsvlak aan het einde. Anders, als er een bestemming onbereikbaar is, controleer dan een firewall of toegangslijsten die TCP-poort 179 of BGP-pakketten kunnen blokkeren of pakketverlies op het pad.
In het geval van een authenticatieprobleem, ziet u de volgende berichten:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Controleer de verificatiemethoden, het wachtwoord en de bijbehorende configuratie en raadpleeg voor verdere probleemoplossing het voorbeeld MD5-verificatie tussen BGP-peers.
Als de TCP-sessie niet verschijnt, kunt u de volgende opdrachten gebruiken voor isolatie:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
nabijheid stuitert
Als de sessie op en neer is, zoek dan naar show logen je kunt enkele scenario's zien.
interfaceflap
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
Zoals het bericht aangeeft, is de reden voor deze fout de situatie van de interface down, op zoek naar fysieke problemen op poort/SFP, kabel of verbroken verbindingen.
Wachttijd verlopen
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Het is een veel voorkomende situatie; het betekent dat de router geen keepalive-bericht of een updatebericht heeft ontvangen of verwerkt voordat de wachttimer is verlopen. Apparaat stuurt een meldingsbericht en sluit de sessie. De meest voorkomende redenen voor dit probleem worden hier opgesomd:
- Interfaceproblemen: zoek naar invoerfouten, inputwachtrijdalingen of fysieke problemen op de aangesloten interfaces van beide peers;
show interfacekan voor dit doel worden gebruikt.
- Verlies van pakketten tijdens het transport: soms kunnen Hello-pakketten tijdens het transport worden gedropt, de beste manier om ervoor te zorgen dat dit een pakketopname op interfaceniveau is.
- U kunt Embedded Packet Capture gebruiken op Cisco IOS- en Cisco IOS XE-apparaten.
- Als pakketten op interfaceniveau worden gezien, moet u er zeker van zijn dat ze het besturingsvlak bereiken, EPC op het besturingsvlak
debug bgp [vrf name] ipv4 unicast keepalivesof nuttig is.
- Hoge CPU: een hoge CPU-conditie kan vallen op het besturingsvlak veroorzaken,
show processes cpu [sorted|history]is handig om problemen te identificeren. Op basis van het platform kunt u de volgende stap vinden om problemen op te lossen met het CPU-referentiedocument
- CoPP-beleidskwesties: de methodologie voor probleemoplossing varieert voor elk platform en valt buiten het bereik van dit document.
- MTU mismatch: Als er MTU verschillen in het pad, en als ICMP berichten worden geblokkeerd in het pad van bron naar bestemming, PMTUD niet functioneert en kan resulteren in sessie flap. Updates worden verzonden met de overeengekomen MSS-waarde en een DF-bitset. Als een apparaat in het pad of zelfs de bestemming de pakketten met een hogere MTU niet kan accepteren, stuurt het een ICMP-foutbericht terug naar de BGP-luidspreker. De bestemmingsrouter wacht op het BGP-keepalive of BGP-updatepakket om de hold-downtimer bij te werken.
- U kunt de MSS controleren die is overeengekomen met
show ip bgp neighbors ip_address.
- U kunt de MSS controleren die is overeengekomen met
Een Ping-test voor een specifieke buur met df-set kan u laten zien of een dergelijke MTU geldig is langs het pad:
ping 198.51.100.2 size max_seg_size df
Als MTU-problemen worden gevonden, moet een nauwkeurige beoordeling van de configuratie worden uitgevoerd om ervoor te zorgen dat de MTU-waarden consistent zijn in het hele netwerk.
AFI/SAFI-problemen
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
Address-Family Identifier (AFI) is een uitbreiding van de mogelijkheid toegevoegd door Multi-Protocol BGP (MP-BGP). Het correleert met een specifiek netwerkprotocol, zoals IPv4, IPv6 en dergelijke, en aanvullende granulariteit via een latere Address-Family Identifier (SAFI), zoals unicast en multicast. MBGP bereikt deze scheiding door middel van BGP path attributes (PAs) MP_REACH_NLRI en MP_UNREACH_NLRI. Deze attributen worden meegenomen in BGP-updateberichten en worden gebruikt om informatie over de bereikbaarheid van het netwerk voor verschillende adresfamilies te dragen.
Het bericht geeft u de nummers van deze AFI / SAFI geregistreerd door IANA:
- Controleer de BGP-configuratie voor de adresfamilies die aan beide zijden zijn bedoeld om ongewenste adresfamilies te corrigeren.
- Gebruik aan
neighbor ip-address dont-capability-negotiatebeide uiteinden. Raadpleeg voor meer informatie Niet-ondersteunde mogelijkheden die een BGP-peer-storing veroorzaken
Pad installeren en selecteren
Voor een betere uitleg over hoe BGP werkt en om het beste pad te selecteren, raadpleegt u BGP Best Path Selection Algorithm
Volgende hop
Voor een route die in onze routeringstabel wordt geïnstalleerd, moet de volgende hop bereikbaar zijn, anders komt het voorvoegsel, zelfs als het op onze Loc-RIB BGP-tabel staat, niet in RIB. Als regel voor lusvermijding wijzigt iBGP op Cisco IOS/Cisco IOS XE het volgende hopattribuut niet en laat AS_PATH met rust, terwijl eBGP de volgende hop herschrijft en de AS_PATH voorbereidt.
U kunt controleren volgende hop met show ip bgp [prefix]. Het geeft u de volgende hop en ontoegankelijk woord. In het voorbeeld is dit een prefix aangekondigd door R1 via eBGP naar R2 en geleerd door R3 via iBGP-verbinding van R2.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CSTOp de uitvoer is de volgende hop de uitgaande interface van R1 die niet bekend is bij R3. Om deze situatie op te lossen, kunt u next-hop adverteren via IGP, statische route of de neighbor ip-address next-hop-selfopdracht op iBGP peer gebruiken om de next-hop IP (die rechtstreeks is verbonden) aan te passen. In het diagram voorbeeld moet deze configuratie op R2 staan; de buurman naar R3 (buurman 10.0.23.3 next-hop-self).
Als gevolg hiervan verandert de volgende hop (na een clear ip bgp 10.0.23.2 soft) naar direct verbonden interface (bereikbaar) en prefix wordt geïnstalleerd.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CSTRIB-fout
Dit gebeurt wanneer de route niet kan worden geïnstalleerd in de Global RIB, wat resulteert in een RIB-fout. De meest voorkomende reden is wanneer hetzelfde voorvoegsel al op RIB staat voor een ander routeringsprotocol met een lagere administratieve afstand, maar de exacte reden voor een RIB-fout wordt gezien met de opdracht ip bgp rib-failure tonen. Voor meer uitleg kun je deze link raadplegen:
rasvoorwaarde
Het meest voorkomende probleem is wanneer IGP de voorkeur heeft boven eBGP in een wederzijds herdistributiescenario. Wanneer een IGP-route wordt herverdeeld in BGP, wordt deze beschouwd als lokaal gegenereerd door BGP en krijgt standaard een gewicht van 32768. Alle voorvoegsels die van een BGP-peer worden ontvangen, krijgen standaard een lokaal gewicht van 0 toegewezen. Daarom, als hetzelfde voorvoegsel moet worden vergeleken, wordt het voorvoegsel met het hogere gewicht geïnstalleerd in de routeringstabel op basis van het BGP beste pad selectieproces en dit is de reden waarom IGP route op RIB is geïnstalleerd.
De oplossing voor dit probleem is om een hoger gewicht in te stellen voor alle routes die worden ontvangen van de BGP-peer onder BGP-configuratie van de router:
neighbor ip-address weight 40000
Andere kwesties
BGP Slow Peer
Het is een peer die de snelheid waarmee de afzender updateberichten genereert niet kan bijhouden. Er zijn veel redenen voor een peer om dit probleem te vertonen; hoge CPU in een van de peers, overtollig verkeer of verkeersverlies op een link, bandbreedtebron, onder anderen.
Geheugenproblemen
BGP maakt gebruik van geheugen dat is toegewezen aan het Cisco IOS-proces om netwerkvoorvoegsels, beste paden, beleid en alle bijbehorende configuratie te behouden om goed te werken. De algemene processen worden gezien met opdracht show processes memory sorted:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
De processorpool is het gebruikte geheugen; ongeveer 2,1 GB in het voorbeeld. Vervolgens moet u naar de kolom Holding kijken om het subproces te identificeren dat het grootste deel ervan bevat. Vervolgens moet u de BGP-sessies controleren die u hebt, hoeveel routes worden ontvangen en welke configuratie wordt gebruikt.
Veelvoorkomende stappen om geheugenbezit door BGP te verminderen:
- BGP-filtering: Als het niet nodig is om een volledige BGP-tabel te ontvangen, gebruikt u beleid om routes te filteren en alleen de voorvoegsels te installeren die u nodig hebt.
- Zachte herconfiguratie: Zoek naar IP_address soft-reconfiguration inbound onder BGP-configuratie; met deze opdracht kunt u alle voorvoegsels zien die u hebt ontvangen voordat er een inbound-beleid (Adj-RIB-in) wordt uitgevoerd. Deze tabel heeft echter ongeveer de helft van de huidige BGP Local RIB-tabel nodig om deze informatie op te slaan, zodat u deze configuratie kunt vermijden, tenzij dit verplicht is of uw huidige voorvoegsels weinig zijn.
Hoge CPU
Routers gebruiken verschillende processen om BGP te laten werken. Als u wilt controleren of het BGP-proces de oorzaak is van een hoog CPU-gebruik, gebruikt u de opdracht show process cpu sorted .
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Hier zijn de gebruikelijke processen, oorzaken en algemene stappen om een hoog CPU-gebruik te overwinnen als gevolg van BGP:
- BGP Router: Wordt één keer per seconde uitgevoerd om snellere convergentie te garanderen. Het is een van de belangrijkste draden. Het leest de bgp-updateberichten, valideert de voorvoegsels/netwerken en attributen, werkt de tabel per AFI/SAFI-netwerk/prefix en de attribuuttabel bij, voert de berekening van het beste pad uit naast vele andere taken.
Enorme route churn is een veel voorkomend scenario dat tot deze situatie leidt. - BGP-scanner: proces met lage prioriteit dat standaard elke 60 seconden wordt uitgevoerd. Dit proces controleert de volledige BGP-tabel om de bereikbaarheid van de volgende hop te verifiëren en werkt de BGP-tabel dienovereenkomstig bij, voor het geval er een wijziging voor een pad is. Het loopt via de Routing Information Base (RIB) voor herdistributie doeleinden.
Controleer de platformschaal, omdat er meer voorvoegsels en routes zijn geïnstalleerd en TCAM is gebruikt, meer bronnen nodig zijn en meestal leidt een overbelast apparaat tot dergelijke situaties.
- BGP I/O: Wordt uitgevoerd wanneer BGP-besturingspakketten worden ontvangen en beheert de wachtrij en verwerking van BGP-pakketten. Als er gedurende een lange periode te veel pakketten in de BGP-wachtrij worden ontvangen of als er een probleem is met TCP, vertoont de router symptomen van een hoge CPU als gevolg van het BGP I/O-proces. (Meestal is BGP Router ook hoog in deze situatie. Kijk naar het aantal berichten om peer te identificeren en pakketten vast te leggen om de bron van deze berichten te identificeren.)
- BGP Open: proces dat wordt gebruikt bij het instellen van sessies. Geen algemeen probleem met een hoge CPU, tenzij de sessie vastzit in Open State.
- BGP Event: is verantwoordelijk voor de next-hop verwerking. Kijk voor next-hop flappen op ontvangen voorvoegsels.
Gerelateerde informatie
- Technische ondersteuning en documentatie – Cisco Systems
- BGP-configuratiehandleiding
- MD5-verificatie tussen BGP-peers Configuratievoorbeeld
- Embedded Packet Capture
- BGP Buurtkleppen met MTU Problemen oplossen
- Niet-ondersteunde mogelijkheden veroorzaken een BGP-peer-storing
- BGP-algoritme voor selectie van het beste pad
- Begrijp BGP RIB-falen en The Command bgp onderdrukken-inactief
- Het belang van het BGP-kenmerk ‘weight path’ in scenario’s met failover van het netwerk
- Gebruik de BGP "Slow Peer" -functie om problemen met langzame collega's op te lossen
- BGP-routers configureren voor optimale prestaties en een lager geheugenverbruik
- Problemen oplossen met hoge CPU veroorzaakt door de BGP-scanner of het routerproces
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
4.0 |
19-Feb-2025
|
hercertificering |
3.0 |
25-Sep-2023
|
Bijgewerkt IOS XE (verwijderd dashboard) en toegevoegd handelsmerk, SEO en opmaak. |
2.0 |
21-Feb-2023
|
Hercertificering. |
1.0 |
04-Aug-2022
|
Eerste vrijgave |
Feedback