Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Achtergrondinformatie

Begrijp de BGP-processen

Hoge CPU’s door BGP-scanner

Hoge CPU’s door BGP-routerproces

Prestatieverbeteringen

Wachtrij bij TCP-peer-verbindingen

BGP-peergroepen

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

Wachtrijen voor interface-invoer vergroten

Aanvullende verbeteringen in Cisco IOS

Procedures voor probleemoplossing

Gerelateerde informatie

Inleiding

In dit document wordt beschreven hoe u de oorzaak van een hoge CPU-uitloop kunt oplossen wanneer de BGP-scanner of -router wordt gebruikt.

Voorwaarden

Vereisten

Dit document vereist dat u weet hoe u het cpu-opdracht van het showproces interpreteert.

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco IOS® softwarerelease 12.0.

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.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

Dit document beschrijft situaties waarin een Cisco IOS-router gebruik van hoge CPU’s kan ervaren door het BGP-routerproces (Border Gateway Protocol) of het BGP-scannerproces, zoals getoond in de uitvoer van het cpu-opdracht van het showproces. De duur van de hoge CPU-voorwaarde varieert op basis van een aantal voorwaarden, met name de omvang van de internet-routingtabel en het aantal routes dat een bepaalde router in zijn routing en BGP-tabellen houdt. De cpu-opdracht voor het tonen van proces laat een gemiddeld CPU-gebruik zien gedurende de afgelopen vijf seconden, één minuut en vijf minuten. De benuttingsgetallen van de CPU bieden geen echte lineaire indicatie van het gebruik met betrekking tot de aangeboden lading.

Dit zijn een paar van de belangrijkste redenen:

- In een netwerk in de echte wereld moet de centrale verwerkingseenheid verschillende systeemonderhoudsfuncties verwerken, zoals netwerkbeheer.

- De CPU moet periodieke en met een gebeurtenis verbonden routingupdates verwerken.

- Er zijn andere overhead-operaties van het interne systeem, zoals opiniepeilingen naar beschikbaarheid van bronnen, die niet evenredig zijn met de verkeersbelasting.

U kunt de cpu-opdracht voor bewerking ook gebruiken om een indicatie van de CPU-activiteit te verkrijgen.

Opmerking: Voor meer informatie over de show opdrachten, zie de Cisco IOS Configuration Fundamentals Opdrachtreferentie voor Cisco IOS Configuration

Begrijp de BGP-processen

Een Cisco IOS proces, in het algemeen, bestaat uit de individuele draden en de verbonden gegevens die taken, zoals systeemonderhoud, overschakelingspakketten en implementatie van het routing protocollen, uitvoeren. Verschillende Cisco IOS processen die op de router worden uitgevoerd maken het mogelijk BGP te starten. Gebruik het cpu-proces voor tonen | bevat de BGP-opdracht om de hoeveelheid CPU-gebruik te zien ten gevolge van BGP-processen.

Deze tabel toont de functie van de BGP-processen en toont aan dat elk proces op verschillende tijdstippen draait. Die tijden zijn afhankelijk van de taken die worden verwerkt Omdat de BGP-scanner en BGP-routerprocessen verantwoordelijk zijn voor een groot aantal berekeningen, kunt u een hoge CPU zien door een van deze processen. In de volgende paragrafen worden deze processen uitvoeriger besproken.

Procesnaam

Beschrijving

Interval

BGP openen

Voer de BGP-peer-instelling uit.

Bij initialisatie, wanneer een TCP verbinding met een BGP peer wordt gevestigd.

BGP I/O

Handelt BGP-pakketten af die in de wachtrij staan en worden verwerkt, zoals UPDATES en BEWAKING.

Als BGP-besturingspakketten worden ontvangen.

BGP-scanner

Walkt de BGP-tabel en bevestigt de bereikbaarheid van de volgende hop. BGP-scanner controleert ook of voorwaardelijke advertentie wordt geplaatst om te bepalen of BGP-advertenties plaatsen voor vooraf bepaalde condities en routevermindering uitvoert. In een MPLS VPN-omgeving importeren en exporteren BGP-scanner routes naar een bepaalde VPN-routing en -verzendinstantie (VRF).

Eén keer per minuut.

BGP-router

Berekent het beste BGP pad en verwerkt elke route churn. Het stuurt en ontvangt ook routes, stelt peers vast en interageert met de routinginformatiebasis (RIB).

Eén keer per seconde en wanneer een BGP-peer wordt toegevoegd, verwijderd of zacht geconfigureerd.

Hoge CPU’s door BGP-scanner

Hoge CPU’s door het BGP-scannerproces kunnen voor korte perioden worden verwacht op een router die een grote tabel voor internetrouting draagt. Eenmaal per minuut loopt de BGP-scanner op de BGP RIB-tabel en voert hij belangrijke onderhoudstaken uit. Deze taken omvatten onderzoek van de volgende-hop die in de BGP-tabel van de router van genoemde oorsprong is en verifieert dat de volgende-hopapparaten kunnen worden bereikt. Een grote BGP-tafel heeft dus evenveel tijd nodig om te lopen en gevalideerd te worden.

Omdat het BGP-scannerproces door de gehele BGP-tabel loopt, varieert de duur van de hoge CPU-conditie met het aantal buren en het aantal routes dat per buurman wordt geleerd. Gebruik de samenvatting van tonen ip bgp en toon ip route samenvatting opdrachten om deze informatie op te nemen. Het BGP-scannerproces loopt de BGP-tabel om gegevensstructuren bij te werken en loopt de routingtabel voor routeherverdelingsdoeleinden. (In deze context, is de routingtabel ook bekend als de routing information base (RIB), die de router output wanneer u de ;show ip route opdracht uitvoert). Beide tabellen worden afzonderlijk opgeslagen in het geheugen van de router en kunnen groot zijn en CPU-cycli gebruiken.

De volgende voorbeelduitvoer van de debug ip bgp update opdracht neemt een uitvoering van BGP scanner op:

router#

2d17h: BGP: scanning routing tables

2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

router#

Terwijl de BGP-scanner draait, moeten processen met een lage prioriteit een langere tijd afwachten om toegang tot de CPU te krijgen. Eén proces met lage prioriteit regelt de pakketten Internet Control Message Protocol (ICMP), zoals pings. Pakketten die bestemd zijn om van de router te of die van de router afkomstig zijn, kunnen een hogere dan verwachte vertraging ervaren aangezien het ICMP-proces achter de BGP-scanner moet wachten. Het programma is dat de BGP-scanner een tijdje actief is en zichzelf onderbreekt, waarna de ICMP-scanner actief is. Pings die door een router worden verstuurd moeten daarentegen via Cisco Express Forwarding (CEF) worden geschakeld en mogen geen extra vertraging ondervinden. Wanneer u periodieke centrifugesnelheden in een later stadium wilt oplossen, vergelijk u verzendtijden voor pakketten die door een router zijn verzonden tegen pakketten die rechtstreeks door de CPU op de router zijn verwerkt.

Opmerking: Ping-opdrachten die IP-opties specificeren, zoals opnameroute, vereisen ook dat de CPU deze direct verwerkt en dit kan langere verzendvertragingen veroorzaken.

Gebruik het proces van tonen | bgp-scanneropdracht opnemen om de CPU-prioriteit te zien. De waarde van Lsi in de volgende steekproefuitvoer gebruikt L om te verwijzen naar een laagprioriteitsproces.

6513#show processes | include BGP Scanner

172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

Hoge CPU’s door BGP-routerproces

Het BGP-routerproces werkt ongeveer eenmaal per seconde om te controleren op het werk. BGP - convergentie definieert de duur tussen het tijdstip waarop de eerste BGP - peer wordt ingesteld en het punt waarop BGP wordt geconvergeerd. Om de kortst mogelijke convergentietijden te verzekeren, gebruikt de BGP-router alle gratis CPU-cycli. Nadat de CPU is begonnen, wordt deze echter met tussenpozen afgebroken (of opgeschort).

De tijd van de convergentie is een directe meting van hoe lang de router BGP op de CPU besteedt, niet de totale tijd. Deze procedure toont een hoge CPU-conditie tijdens BGP-convergentie en wisselt BGP-prefixes met twee externe BGP-peers (eBGP) uit.

1. Leg een uitgangswaarde vast voor normaal CPU-gebruik voordat u de test start.

router#show process cpu

CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. Zodra de test is begonnen, bereikt de CPU 100 procent van het gebruik. Het computingsysteem van het proces van de show toont dat de hoge CPU-voorwaarde door een BGP-router wordt veroorzaakt, die door 139 (het Cisco IOS proces-ID voor een BGP-router) in de volgende uitvoer wordt aangegeven.

router#show process cpu

CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%

!--- Output omitted.

139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. U kunt meerdere uitgangen van de samenvatting van ip bekijken en opnemen en op dit moment cpu-opdrachten van het proces tonen. De summiere opdracht tonen ip legt de staat van de buren van BGP vast.

router#show ip bgp summary

Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd

10.0.0.0    4  64512  309453  157389    19981    0  253 22:06:44 111633

10.1.0.0  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. Wanneer de router prefix-uitwisseling met zijn BGP-peers voltooit, keren de CPU-gebruikstarieven terug naar normale niveaus. De berekende gemiddelden van één minuut en vijf minuten kunnen ook weer omlaag gaan en kunnen gedurende een langere periode dan de vijf seconden rente hoger dan normaal zijn.

router#show process cpu

CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. Gebruik de opgenomen output van de vorige show opdrachten om de BGP conversietijd te berekenen. Gebruik in het bijzonder de kolom Up/Down</strong> van de opdracht voor samenvatting van ip en vergelijk de begin- en eindtijden van de hoge CPU-toestand. Meestal kan BGP-conversie meerdere minuten in beslag nemen als er een grote tabel voor internetrouting is. wordt omgewisseld

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