Basisproblemen 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, raadpleeg de BGP Configuration Guide 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), biedt corrigerende acties, nuttige opdrachten / debugs om de oorzaak van problemen te detecteren en best practices om potentiële problemen te voorkomen. Houd er rekening mee dat alle mogelijke variabelen en scenario's niet kunnen worden overwogen en dat een diepere analyse kan worden vereist door Cisco TAC.
Topologie
Gebruik dit topologiediagram als referentie voor de uitgangen in dit document.
Scenario's en problemen
Aangrenzing omlaag
Als een BGP-sessie offline is, voert u het overzicht van show ip bgp all uit. command. geeft de huidige status van de sessie:
- Als de sessie niet up state is, kan deze variëren tussen IDLE en ACTIVE (dit is afhankelijk van het Finite State Machine-proces).
- Als de sessie online is, kunt u het aantal ontvangen voorvoegsels zien.
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 is de connectiviteit tussen beide peers, dus de TCP-sessie op poort 179 is vastgesteld. Of ze zijn direct verbonden of niet) en je kunt een ping gebruiken. Als peering wordt ingesteld tussen loopback-interfaces, moet een loopback naar loopback ping worden voltooid. Als een ping-test wordt uitgevoerd zonder een 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 de ping niet succesvol is, overweeg dan deze redenen:
- Geen gekoppelde routepeer of helemaal geen route; voer de opdracht show ip route peer_IP_address uit.
- Layer 1-probleem: fysieke interface, SFP (connector), kabel of externe kwestie (transport en provider indien van toepassing) moet worden overwogen.
- Controleer een firewall of toegangslijsten die uw verbinding kunnen blokkeren.
Als de ping succesvol is:
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 is voltooid. Voor een verkeerde AS moet u een bericht zien dat vergelijkbaar is met de opdracht logboekregistratie weergeven.
%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 peer-IP-adres te corrigeren.
- ID van router dupliceren:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Controleer de BGP-identificatie aan beide uiteinden door de opdracht show ip bgp all summary uit te voeren en het duplicaatprobleem te corrigeren. Dit kan handmatig worden bereikt met de globale opdracht bgp router-id X.X.X.X.X onder de bgp router configuratie. Zorg er als best practice voor dat de router-ID handmatig op een uniek nummer is ingesteld.
- BGP Bron en TTL:
De meeste iBGP-sessies worden geconfigureerd via loopback-interfaces, die bereikbaar zijn via een IGP. Deze loopback interface moet expliciet worden gedefinieerd als de bron, U kunt dit voltooien door het uitvoeren van de buurman ip-adres update-bron interface-id opdracht.
Voor eBGP peer direct verbonden interfaces worden de meeste gebruikt voor peering. Er is een controle voor Cisco IOS / Cisco IOS XE om dit doel te vervullen, of het probeert geen sessie op te zetten. Als eBGP wordt geprobeerd van loopback naar loopback op direct verbonden routers, kan deze controle worden uitgeschakeld voor een specifieke buur aan beide uiteinden door de opdracht buurman-ip-adres uitschakelen-verbonden-controleren uit te voeren.
Als er echter meerdere hops tussen de eBGP-peers zijn, is een goede hoptelling vereist, zorg er dan voor dat het naburige ip-adres ebgp-multihop [hop-count] is geconfigureerd met de juiste hoptelling, zodat elke sessie kan worden ingesteld. Als de hoptelling 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-sessie
Een nuttige actie om poort 179 te testen is een handmatig telnet van de ene naar de andere peer:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Open/gesloten verbinding of verbinding geweigerd door de externe host geeft aan dat pakketten het externe einde hebben bereikt. Zorg er dan voor dat er geen problemen zijn met het controlevliegtuig aan het einde. Als er anders een bericht met bestemming onbereikbaar is, controleert u een firewall of toegangslijsten die TCP-poort 179, BGP-pakketten kunnen blokkeren of als er pakketverlies op het pad is.
Als authenticatie het probleem is, zijn de berichten die u kunt zien:
%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 configuraties en raadpleeg de handleiding MD5 Authentication Between BGP Peers Configuration (Verificatie tussen BGP-peers configuratie) om verdere problemen op te lossen.
Als de TCP-sessie niet online is, gebruikt u de volgende opdrachten voor isolatie:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Aangrenzingsbounces
Als de sessie intermitterend is, zoekt u naar het showlog en kunt u enkele scenario's vinden.
interfaceklep
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
De reden voor deze storing is te wijten aan "Down Interface Flap." Zoek naar fysieke problemen met de poort/SFP, kabel of verbroken verbindingen.
Timer vasthouden verlopen
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Dit komt vaak voor en de router heeft geen bericht ontvangen/verwerkt om het bericht in leven te houden of bij te werken voordat de timer voor het vasthouden is verlopen. Het apparaat stuurt een notificatiebericht en sluit de sessie. De meest voorkomende redenen voor dit probleem zijn:
- Interfacekwesties: Zoek naar invoerfouten, invoerwachtrijdrops of fysieke problemen op beide peer-verbonden interfaces; het uitvoeren van de opdracht show interface kan hiervoor worden gebruikt.
- Packet Loss in Transit: Soms kunnen Hello-pakketten tijdens het transport worden gedropt, om ervoor te zorgen dat dit een pakketopname op interfaceniveau is:
- Gebruik de Embedded Packet Capture op Cisco IOS- en Cisco IOS XE-apparaten.
- Als pakketten worden gezien op het interfaceniveau, zorg er dan voor dat ze het controlevlak bereiken, EPC op het controlevlak, of voer de foutopsporingsopdracht bgp [vrf name] ipv4 unicast keepalives uit.
- Hoge CPU: Een hoge CPU-conditie kan vallen op het besturingsplane veroorzaken, de show processen CPU [gesorteerd|geschiedenis] opdracht kan helpen bij het identificeren van deze problemen. Op basis van het platform kunt u de volgende stappen voor het oplossen van problemen vinden door te verwijzen naar de CPU-handleiding.
- CoPP-beleidskwesties: de methodologie voor het oplossen van problemen verschilt per platform en valt buiten het bereik van dit document.
- MTU-mismatch: als er MTU-discrepanties in het pad zijn en als ICMP-berichten worden geblokkeerd in het pad van de bron naar de bestemming, werkt PMTUD niet goed en kan dit resulteren in een sessieklep. Updates worden verzonden met de onderhandelde MSS-waarde en een DF-bitset. Als een apparaat in het pad of de bestemming de pakketten met een hogere MTU niet kan accepteren, stuurt het een ICMP-foutmelding terug naar de BGP-luidspreker. De bestemmingsrouter wacht tot de BGP in leven blijft of BGP het pakket bijwerkt om de timer ingedrukt te houden.
U kunt de onderhandelde MSS controleren door de opdracht show ip bgp neighbours ip_address uit te voeren.
Een ping-test naar een specifieke buur met de df-set kan u laten zien of de MTU geldig is langs het pad:
ping 198.51.100.2 size max_seg_size df
Als er MTU-problemen worden gevonden, moet een nauwkeurige beoordeling van de configuratie worden voltooid om ervoor te zorgen dat de MTU-waarden consistent zijn in het hele netwerk.
AFI/SAFI-kwesties
%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 mogelijkheden die wordt toegevoegd door Multi-Protocol BGP (MP-BGP). Het correleert met een specifiek netwerkprotocol, zoals IPv4, IPv6 en dergelijke. Extra granulariteit door middel van een Next Address-Family Identifier (SAFI), zoals unicast en multicast. MBGP bereikt deze scheiding met BGP pad attributen (PAs) MP_REACH_NLRI en MP_UNREACH_NLRI. Deze kenmerken worden meegenomen in BGP-updateberichten en worden gebruikt om netwerkbereikbaarheidsinformatie voor verschillende adresfamilies te vervoeren.
Het bericht bevat de nummers van de door IANA geregistreerde AFI/SAFI:
- Controleer de BGP-configuratie voor de adresfamilies die aan beide zijden zijn bedoeld om ongewenste adresfamilies te corrigeren.
- Voer het aangrenzende commando ip-adres dont-capability-negotiate aan beide uiteinden uit. Raadpleeg voor meer informatie de handleiding Niet-ondersteunde functies veroorzaken BGP-peer-storingen.
Padinstallatie en -selectie
Voor aanvullende informatie over BGP en het selecteren van het beste pad, raadpleegt u het BGP Best Path Selection Algorithm.
Volgende hop
Om een route in de routeringstabel te installeren, moet de volgende hop bereikbaar zijn, anders beweegt het prefix niet in RIB, zelfs als het prefix op de Loc-RIB BGP-tabel staat. Als regel voor het vermijden van een lus verandert iBGP op Cisco IOS/Cisco IOS XE het volgende hopkenmerk niet, omdat het AS_PATH met rust laat terwijl eBGP de volgende hop herschrijft en zijn AS_PATH voorbereidt.
U kunt de volgende hop bekijken door de opdracht show ip bgp [prefix] uit te voeren omdat deze de volgende hop en ontoegankelijk woord biedt. In dit voorbeeld is dit een voorvoegsel dat R1 via eBGP naar R2 heeft aangekondigd en dat R3 via iBGP-verbinding van R2 heeft geleerd:
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 CST
Op de uitgang is de volgende hop de uitgaande interface van R1, die niet bekend is bij R3. Om deze situatie op te lossen, kunt u de next-hop adverteren via IGP, statische route, of het naburige ip-adres uitvoeren next-hop-self commando op de iBGP peer om de next-hop IP te wijzigen (die direct verbonden is). In het diagramvoorbeeld moet deze configuratie op R2 staan; de buurman richting R3 (buurman 10.0.23.3 next-hop-self).
Als gevolg hiervan verandert de volgende hop (na een duidelijke ip bgp 10.0.23.2 soft) naar de direct verbonden interface (bereikbaar) en wordt het prefix 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 CST
RIBFALEN
Dit gebeurt wanneer een route niet in de Global RIB kan worden geïnstalleerd, wat resulteert in een RIB-storing. Veel voorkomende redenen zijn 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-fout tonen.
race-conditie
Het meest voorkomende probleem is wanneer IGP de voorkeur krijgt boven eBGP in een scenario van wederzijdse herverdeling. Wanneer een IGP-route wordt herverdeeld in BGP, wordt deze beschouwd als lokaal gegenereerd door BGP en ontvangt standaard een gewicht van 32.768. Alle prefixes die van een BGP-peer worden ontvangen, krijgen standaard een lokaal gewicht van 0 toegewezen. Daarom, als hetzelfde prefix moet worden vergeleken, wordt het prefix met het hogere gewicht geïnstalleerd in de routeringstabel op basis van het BGP-beste padselectieproces, daarom wordt de IGP-route op RIB 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 de bgp-configuratie van de router:
neighbor ip-address weight 40000
Andere kwesties
BGP Slow Peer
Het is een peer die niet kan bijbenen met de snelheid een afzender genereert update berichten. Er zijn veel redenen voor een peer om dit probleem te vertonen; hoge CPU in een van de peers, overtollig verkeer, verkeersverlies op een link, bandbreedte resource, onder anderen.
Geheugenproblemen
BGP maakt gebruik van geheugen dat is toegewezen aan het Cisco IOS-proces om netwerkvoorvoegsels, beste paden, beleidsregels en alle gerelateerde configuraties te onderhouden om correct te werken. De algemene processen worden gezien door de opdracht show processes memory sorted uit te voeren:
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 vasthoudt. Vervolgens moet u controleren welke BGP-sessies u hebt, hoeveel routes worden ontvangen en welke configuratie wordt gebruikt.
Veelvoorkomende stappen om het geheugen vast te houden door BGP te verminderen:
- BGP-filtering: Als het niet nodig is om een volledige BGP-tabel te ontvangen, gebruikt u beleidsregels om routes te filteren en alleen de voorvoegsels te installeren die u nodig hebt.
- Zachte herconfiguratie: Zoek naar inkomende, soft-reconfiguratie van het IP_adres van de buren onder BGP-configuratie; met deze opdracht kunt u alle voorvoegsels zien die zijn ontvangen vóór een inkomend beleid (Adj-RIB-in). Deze tabel heeft echter ongeveer de helft van de huidige BGP Lokale RIB-tabel nodig om deze informatie op te slaan, zodat u deze configuratie kunt vermijden, tenzij deze verplicht is, of uw huidige voorvoegsels weinig zijn.
Hoge CPU
Routers gebruiken verschillende processen voor BGP om te werken. Als u wilt controleren of het BGP-proces de oorzaak is van een hoog CPU-gebruik, voert u de opdracht Show Process CPU Sorted uit.
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
Dit zijn de gebruikelijke processen, oorzaken en algemene stappen om een hoog CPU-gebruik als gevolg van BGP te voorkomen:
- BGP-router: werkt eenmaal per seconde om een snellere convergentie te garanderen (dit is een belangrijke draad). Het leest de bgp-updateberichten, valideert de voorvoegsels/netwerken en attributen, werkt de tabel per AFI/SAFI-netwerk/prefix en attribuuttabel bij, voert onder andere de berekening van het beste pad uit.
Enorme route churn is een veel voorkomend scenario dat leidt tot deze situatie. - 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 actualiseert de BGP-tabel dienovereenkomstig. Het loopt via de Routing Information Base (RIB) voor herdistributiedoeleinden. Controleer de platformschaal, omdat er meer voorvoegsels en routes zijn geïnstalleerd en TCAM wordt gebruikt, zijn er meer bronnen nodig.
- BGP I/O: Wordt uitgevoerd wanneer BGP-controlepakketten worden ontvangen en beheert de wachtrij en verwerking van BGP-pakketten. Als er te veel pakketten worden ontvangen in de BGP-wachtrij voor een lange periode, 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 de BGP Router ook hoog in deze situatie. Kijk naar de berichttellingen 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 veel voorkomend probleem met een hoge CPU tenzij een sessie vastzit in een open status.
- BGP Event: is verantwoordelijk voor de next-hop verwerking. Kijk voor next-hop flaps op prefixes ontvangen.
Gerelateerde informatie
- Technische ondersteuning en documentatie – Cisco Systems
- BGP-configuratiegids
- MD5-verificatie tussen configuratievoorbeelden van BGP-peers
- Embedded Packet Capture
- BGP Buurtkleppen met MTU-probleemoplossing
- Niet-ondersteunde mogelijkheden veroorzaken storing bij BGP Peer
- BGP-algoritme voor selectie van het beste pad
- Begrijp BGP RIB-falen en De opdracht 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 langzame peer-problemen op te lossen
- BGP-routers configureren voor optimale prestaties en minder geheugenverbruik
- Problemen oplossen met hoge CPU veroorzaakt door het BGP-scanner- of routerproces
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
5.0 |
02-Sep-2026
|
Hercertificering bijgewerkt spelling/grammatica, ingevoegd horizontale lijnen naar afzonderlijke secties voor leesbaarheid, en vaste CCW fouten. |
4.0 |
19-Feb-2025
|
hercertificering |
3.0 |
25-Sep-2023
|
Bijgewerkt IOS XE (verwijderd dash) en toegevoegd handelsmerk, SEO en opmaak. |
2.0 |
21-Feb-2023
|
Hercertificering. |
1.0 |
04-Aug-2022
|
Eerste vrijgave |
Feedback