Problemen oplossen bij hoge CPU’s veroorzaakt door de BGP-scanner of het routerproces

Opmerking: De hoge CPU's op het apparaat kunnen ook te wijten zijn aan de instabiliteit van de BGP-tabel. Dit gebeurt als de router twee exemplaren van de routingtabel ontvangt, één van de EBGP die met de ISP plaatsvindt en de andere van de IBGP die in het netwerk actief is. De oorzaak hiervan is de hoeveelheid geheugen op het apparaat. Cisco raadt een minimum van 1 Gig RAM aan voor één exemplaar van de internet-routingtabel. Om deze instabiliteit te omzeilen, verhoogt u de RAM op het apparaat of filtert u de voorvoegsels, zodat de BGP-tabel en het geheugen dat het apparaat in beslag neemt, worden verlicht.

Prestatieverbeteringen

Aangezien het aantal routes in de Internet routingtabel groeit, neemt het ook de tijd voor BGP om samen te vallen toe. In het algemeen wordt convergentie gedefinieerd als het proces waarbij alle routetabellen in overeenstemming worden gebracht. BGP wordt geacht te zijn geconvergeerd wanneer deze voorwaarden waar zijn:

• Alle routes zijn geaccepteerd.

• Alle routes zijn geïnstalleerd in de routingtabel.

• De tabelversie voor alle peers is gelijk aan de tabelversie van de BGP-tabel.

• InQ en OutQ voor alle peers is nul.

In dit gedeelte worden enkele verbeteringen van Cisco IOS-prestaties beschreven om de BGP-conversietijd te verkorten, wat leidt tot een reductie van een hoge CPU-toestand door een BGP-proces.

Wachtrij bij TCP-peer-verbindingen

BGP stelt nu gegevens agressief in de wachtrij van BGP OutQ naar het TCP-socket voor elke peer totdat de OutQs volledig zijn weggelopen. Omdat BGP nu sneller verstuurt, convergeert BGP nu sneller.

BGP-peergroepen

Terwijl ze de BGP-configuratie helpen vereenvoudigen, kunnen BGP-peer-groepen ook de schaalbaarheid verbeteren. Alle leden van de peer group moeten een gemeenschappelijk uitgaande beleid delen. Zodoende kunnen dezelfde uploadpakketten naar elk groepslid worden verzonden, en dit vermindert het aantal CPU-cycli dat BGP nodig heeft om routes naar peers te adverteren. Met andere woorden, met peer groepen, loopt BGP de BGP-tabel alleen op de peer group leader, filtert de prefixes door het uitgaande beleid en genereert updates, die worden verzonden naar de peer group leader. Op zijn beurt reproduceert de leider de updates aan groepsleden met wie het gesynchroniseerd is. Zonder peer groepen moet BGP de tabel voor elke peer lopen, voorfixes door uitgaand beleid filteren en updates genereren die alleen naar één peer worden verstuurd.

Pad MTU en de ip TCP pad-mtu-discovery-opdracht

Alle TCP sessies worden begrensd door een limiet op het aantal bytes die in één pakket kunnen worden getransporteerd. Deze grenswaarde, gekend als het Maximum Segment Size (MSS), is standaard 536 bytes. Met andere woorden, TCP breekt pakketten in een verzendwachtrij in 536 byte-pakketten op voordat deze wordt verzonden naar de IP-laag. Gebruik de tonen ip bgp buren | bevat max. gegevensopdracht om de MSS van BGP-peers weer te geven:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

Het voordeel van een 536 byte MSS is dat pakketten waarschijnlijk niet gefragmenteerd zijn op een IP apparaat langs het pad naar de bestemming omdat de meeste links een MTU van minstens 1500 bytes gebruiken. Het nadeel is dat kleinere pakketten de hoeveelheid bandbreedte verhogen die wordt gebruikt om overhead te transporteren. Aangezien BGP een TCP verbinding met alle peers bouwt, beïnvloedt een 536 bytes MSS BGP convergentietijden.

De oplossing is om de optie PMTU (Path MTU) aan te zetten met de opdracht ip tcp path-mtu-discovery. U kunt deze optie gebruiken om dynamisch te bepalen hoe groot de MSS-waarde kan zijn en in de tussentijd geen pakketten maken die gefragmenteerd moeten worden. MTU staat TCP toe om de kleinste MTU grootte tussen alle links in een TCP sessie te bepalen. TCP gebruikt dan deze MTU waarde, minus kamer voor de IP en TCP headers, als MSS voor de sessie. Als een TCP-sessie alleen Ethernet-segmenten doorvoert, dan is de MSS 1460 bytes. Als Packet over SONET (POS)-segmenten alleen wordt verzonden, is de MSS 4430 bytes. De toename in MSS van 536 naar 1460 of 4430 bytes vermindert TCP/IP-overhead, die BGP sneller helpt converteren.

Nadat u PMTU hebt ingeschakeld, gebruikt u opnieuw de tonen ip bgp-buren | max. gegevensopdracht opnemen om de MSS-waarde per peer te zien:

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

Wachtrijen voor interface-invoer vergroten

Als BGP duizenden routes aan vele peers adverteert, moet TCP duizenden pakketten in een korte tijd verzenden. De BGP peers ontvangen deze pakketten en verzenden TCP ontvangstbewijzen naar de BGP spreker die adverteert, wat de BGP luidspreker ertoe brengt om een vloed van TCP ACKs in een korte tijd te ontvangen. Als de ACK's bij een te hoge snelheid voor de routeprocessor aankomen, worden de pakketten in inkomende interfacerijen weergegeven. Standaard gebruiken routerinterfaces een grootte van 75 pakketten in de wachtrij. Bovendien gebruiken speciale controlepakketten zoals BGP UPDATES een speciale rij met Selectieve Packet Discard (SPD). Deze speciale rij bevat 100 pakketten. Wanneer er BGP-conversie plaatsvindt, kunnen TCP-ACK's snel de 175 punten van invoerbuffering vullen en moeten de nieuwe pakketten die aankomen, worden verwijderd. Op routers met 15 of meer BGP-peers en uitwisseling van de volledige tabel met internetrouting kunnen meer dan 10.000 druppels per interface per minuut worden gezien. Hier is voorbeelduitvoer van een router 15 minuten na het opnieuw opstarten:

Router#show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

Als u de diepte van de interface ingangswachtrij verhoogt (met de wachtrij in de opdracht), dan helpt u het aantal gevallen TCP-ACK's te verminderen, wat de hoeveelheid werk vermindert die BGP moet doen om te converteren. Normaal gesproken lost een waarde van 1000 problemen op die worden veroorzaakt door een daling van de invoerwachtrij.

Opmerking: Gebruik dit bewust omdat de verhoging van de ingangswachtrij enige vertraging kan toevoegen.

Aanvullende verbeteringen in Cisco IOS

Cisco IOS bevat verschillende optimalisaties voor de BGP-groepscode om bijwerken van verpakking en replicatie te verbeteren. Voordat u deze verbeteringen bekijkt, controleert u de pakking en replicatie van de update meer in detail.

Een BGP-update bestaat uit een combinatie van eigenschappen (zoals MED = 50 en LOCAL_PREF = 120) en een lijst met NFR-voorvoegsels (Network Layer Reachability Information) die deze combinatie van eigenschappen delen. Hoe meer NLRI-prefixes die BGP in één update kan opgeven, des te sneller BGP kan converteren omdat de overhead (zoals IP, TCP en BGP-headers) is verminderd. Het inpakken van de tekst verwijst naar het inpakken van NLRI in BGP-updates. Bijvoorbeeld, als een BGP-tabel 100.000 routes met 15.000 unieke attributencombinaties bevat, hoeft BGP slechts 15.000 updates te sturen als NLRI verpakt is met 100% efficiëntie.

Opmerking: Nulprocent verpakkingsefficiëntie betekent dat BGP 100.000 updates in deze omgeving nodig zou hebben.

Gebruik het opdracht van peer-group van show ip om de efficiëntie van de BGP updates te bekijken.

Als een peer groepslid in sync is, neemt een BGP router een update bericht dat voor de peer groepsleider wordt geformatteerd en repliceert het voor het lid. Het is veel efficiënter om een update voor een lid van een peer group te kopiëren dan het is om de update opnieuw in te vullen. Bijvoorbeeld, neem aan dat een peer groep 20 leden heeft en alle leden 100 BGP berichten moeten ontvangen. Honderd procent replicatie betekent dat een BGP-router de 100 berichten voor de peer group leider formatteert en deze berichten naar de andere 19 peer group leden reproduceert. Om replicatieverbeteringen te bevestigen, vergelijk het aantal berichten dat wordt gerepliceerd met het aantal berichten dat is geformatteerd, zoals wordt getoond door de peer-group opdracht van ip bgp. Deze verbeteringen maken een dramatisch verschil in de convergentietijden en zorgen ervoor dat BGP nog veel meer deelnemers kan ondersteunen.

Gebruik bijvoorbeeld de opdracht Show ip bgp peer-group om de efficiëntie van update verpakking te controleren en replicatie bij te werken. De volgende output komt van een convergentietest met 6 peer groepen, 20 peers in elk van de eerste 5 peer groepen (eBGP peers) en 100 peers in de zesde peer group (interne BGP (iBGP) peers). De gebruikte BGP-tabel had ook 36.250 attributencombinaties.

De volgende voorbeelduitvoer van de toonaangevende IP bgp peer-group | omvat gereproduceerde opdracht op een router die Cisco IOS 12.0(18)S uitvoert en deze informatie weergeeft:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

Om het replicatiepercentage voor elke peer groep te berekenen, moet u het aantal updates verdelen dat wordt gereproduceerd door het aantal geformatteerde updates:

1668500/836500 = 1,99 145000/1050000 = 1,38 1844500/660500 = 2,79 18 9000/656000 = 2,81 2003750/501250 = 3,99 12114785/2476715 = 4,89

• Als BGP perfect is gerepliceerd, hebben de eBGP-peer-groepen elk een replicatiesnelheid van 19 omdat er 20 peers in de peer-groep zijn. De update is opgemaakt voor de peer group leider en vervolgens gerepliceerd naar de andere 19 peers. Dit biedt een optimale replicatiesnelheid van 19. De ideale replicatiesnelheid voor de iBGP peer groep zou 99 zijn aangezien er 100 peers zijn.
• Als BGP-berichten perfect zijn ingepakt, zijn er slechts 36.250 updates opgemaakt. U hoeft alleen 36.250 updates voor elke peer group te genereren omdat dat het aantal attributencombinaties in de BGP-tabel is. De iBGP peer group alleen maakt bijna 2.500.000 updates terwijl de eBGP peer groepen elk produceren van 500.000 tot 1.000.000 updates.

Op een router die Cisco IOS 12.0(19)S draait, de hoe ip bgp peer-group | ook de opdracht bevat deze informatie:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

Opmerking: Update het verpakken is optimaal. Precies 36.250 updates zijn opgemaakt voor elke peer group. 688750/36250 = 19 68750/36250 = 19 68750/36250 = 19 6888 750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Opmerking: De replicatie bijwerken is ook perfect.

Procedures voor probleemoplossing

Gebruik deze procedures om een hoge CPU-oplossing te problemen door een BGP-scanner of een BGP-router:

• Verzamel informatie over uw BGP-topologie. Bepaal het aantal BGP-peers en het aantal routes dat door elke peer wordt geadverteerd. Is de duur van de hoge CPU-conditie redelijk op basis van uw omgeving?

• Bepaal wanneer de hoge CPU’s worden uitgevoerd. Komt dit overeen met een regelmatig geplande wandeling van de BGP-tafel?

• Heeft de hoge CPU een interfaceklop gevolgd? U kunt de opdracht ip bgp beademing flap-statistics gebruiken als demping is ingeschakeld.

• Ping door de router en pingelt dan van de router. De ICMP-echo's worden behandeld als een proces met lage prioriteit. In het documentUnderstanding the Ping and Traceroute Commands wordt dit nader toegelicht. Zorg ervoor dat het normale transport niet wordt beïnvloed.

• U moet ervoor zorgen dat pakketten een snel door te sturen pad kunnen volgen wanneer u controleert of snelle omschakeling en/of CEF op de inkomende en de uitgaande interfaces wordt geactiveerd. Zorg ervoor dat u de geen ip route-cache cef opdracht op de interface of de geen ip cef opdracht op de mondiale configuratie ziet. Gebruik de ip-opdracht om CEF in de mondiale configuratie-modus in te schakelen.

• Controleer de platformschaal omdat deze in de meeste gevallen het gevolg is van een overbelast apparaat dat in dergelijke situaties leidt. Garandeerde ook dat er juiste externe content adresseerbare memory (TCAM) ruimte beschikbaar is op de router.

• Controleer genoeg geheugen op de router. Zoals in de aanbeveling, moet u minimaal 1 GB DRAM aan Cisco IOS-ruimte per BGP-peer hebben toegewezen die de volledige Internet-routingtabel verstuurt. De hier genoemde DRAM-ruimte is slechts het benodigde geheugen voor BGP. Andere eigenschappen die op de router lopen kunnen extra ruimte vereisen.

Gerelateerde informatie

• Ondersteuningspagina voor IP-routing
• Technische ondersteuning – Cisco Systems