IP : Protocole BGP (Border Gateway Protocol)

Dépannage de l'utilisation élevée du CPU provoquée par le scanner BGP ou le processus du routeur BGP

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit les situations dans lesquelles un routeur de Ý de Cisco IOS pourrait éprouver l'utilisation du CPU élevé due au processus de routeur de Protocole BGP (Border Gateway Protocol) ou au processus de scanner BGP, suivant les indications de la sortie de la commande CPU de processus d'exposition. La durée de cet état d’utilisation élevée du CPU varie en fonction d’un certain nombre de conditions, en particulier la taille de la table de routage Internet et le nombre de routes qu’un routeur particulier gère dans ses tables de routage et BGP.

La commande CPU de processus d'exposition affiche l'utilisation du processeur ramenée à une moyenne au-dessus des dernières cinq secondes, d'une minute, et de cinq minutes. Les nombres d'utilisation du processeur ne fournissent pas une véritable indication Linéaire de l'utilisation en ce qui concerne le chargement offert. Ce sont certaines des principales raisons :

  • Dans un véritable réseau mondial, la CPU doit manipuler de diverses fonctions de maintenance du système, telles que la Gestion de réseau.

  • La CPU doit traiter périodique et événement-déclenché conduisant des mises à jour.

  • Il y a d'autres exécutions supplémentaires de système interne, telles que l'interrogation pour la disponibilité des ressources, qui ne sont pas proportionnelles pour circulation la charge.

Vous pouvez également employer la commande de show processes cpu afin d'obtenir une certaine indication d'activité CPU.

Une fois que vous lisez ce document, vous devriez comprendre le rôle de chaque processus BGP et quand chaque processus fonctionne. En outre, vous devriez comprendre la convergence et les techniques BGP pour optimiser le temps de convergence.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Conditions préalables

Ce document exige une compréhension de la façon interpréter la commande CPU de processus d'exposition. Référez-vous à l'utilisation du CPU élevé de dépannage sur des Routeurs de Cisco comme manuel de référence.

Composants utilisés

Les informations dans ce document sont basées sur le Logiciel Cisco IOS version 12.0.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Compréhension des processus BGP

Un processus de Cisco IOS, comprend généralement les différents thread et les données associées qui effectuent des tâches, telles que la maintenance du système, les paquets de changement, et la mise en oeuvre des protocoles de routage. Plusieurs processus de Cisco IOS exécutés sur le routeur permettent au BGP de fonctionner. Utilisez la CPU de processus d'exposition | incluez la commande BGP de voir la quantité d'utilisation du processeur due aux processus BGP.

Ce tableau présente la fonction des processus BGP et prouve que chaque processus fonctionne aux heures différentes, selon les tâches qu'il gère. Puisque le scanner BGP et les processus de routeur BGP sont responsables d'un grand nombre de calculs, vous pouvez voir la CPU de haute due à l'un ou l'autre un de ces processus. Les sections suivantes discutent ces processus plus en détail.

Nom du processus Description Intervalle
BGP ouvert Exécute l'établissement de pair BGP. À l'initialisation, en établissant une connexion TCP avec un pair BGP.
BGP I/O Traitements s'alignant et traitant des paquets BGP, tels que des MISES À JOUR et le KEEPALIVES. Comme des paquets de contrôle BGP sont reçus.
BGP Scanner Marche la table BGP et confirme l'accessibilité des prochains sauts. Le scanner BGP vérifie également la conditionnel-publicité pour déterminer si le BGP devrait annoncer des préfixes condition, exécute l'atténuation de la route. Dans un environnement MPLS VPN, les importations de scanner BGP et exporte des artères dans un routage VPN et une instance de transfert particuliers (VRF). Une fois une minute.
Routeur BGP Calcule le meilleur chemin BGP et traite n'importe quelle artère « baratte ». Il également envoie et reçoit des artères, établit des pairs, et interagit avec la base d'informations de routage (NERVURE). Une fois par seconde et en ajoutant, en retirant, ou doux-en modifiant un pair BGP.

CPU de haute due au scanner BGP

La CPU de haute due au processus de scanner BGP peut être pour faire court des durées prévues sur un routeur portant une grande table de routage d'Internet. Une fois une minute, le scanner BGP marche la table de NERVURE BGP et effectue d'importantes tâches de maintenance. Ces tâches incluent vérifier le prochain-saut référencé dans la table BGP du routeur et le vérifier que les périphériques de prochain-saut peuvent être atteints. Ainsi, une grande table BGP prend une quantité de temps équivalente pour être parcourue et validée.

Puisque le processus de scanner BGP fonctionne par la table entière BGP, la durée de l'état CPU de haute varie avec le nombre de voisins et le nombre d'artères apprises par voisin. Utilisez le show ip bgp summary et les commandes de show ip route summary de saisir ces informations.

Le processus de scanner BGP marche la table BGP pour mettre à jour toutes les structures de données et marche la table de routage pour la redistribution de routage. (Dans ce contexte, la table de routage est également connue comme base d'informations de routage (NERVURE), que le routeur sort quand vous exécutez la commande de show ip route). Les deux tables sont enregistrées séparément dans la mémoire du routeur et peuvent être les cycles CPU très grands et de ce fait consumants.

La sortie suivante témoin de la commande de debug ip bgp updates capture une exécution du scanner BGP, qui commence la lecture chez le préfixe du nombre le plus inférieur ou 0.0.0.0.

router# 
2d17h: BGP: scanning routing tables 
2d17h: BGP: 3.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 3.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: 4.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 4.0.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#

Tandis que le scanner BGP fonctionne, les processus à basse priorité doivent attendre un plus long temps pour accéder à la CPU. Paquets de Protocole ICMP (Internet Control Message Protocol) de commandes d'un processus à basse priorité tels que des pings. Les paquets ont destiné à ou ont provenu du routeur peuvent éprouver la latence prévue par supérieur à puisque le processus d'ICMP doit attendre derrière le scanner BGP. Le cycle est que le scanner BGP fonctionne pendant quelque temps et s'interrompt, et puis passage d'ICMP. En revanche, des pings envoyés par un routeur devraient être commutés par l'intermédiaire du Technologie Cisco Express Forwarding (CEF) et ne devraient éprouver aucune latence supplémentaire. Les pics périodiques de pour le dépannage dans la latence, comparent des durées d'acheminement pour des paquets expédiés par un routeur contre des paquets traités directement par la CPU sur le routeur.

Remarque: Les commandes pings qui spécifient des options IP, telles que l'artère record, aussi exigent le traitement direct par la CPU et peuvent éprouver de plus longs retards d'expédition.

Utilisez le processus d'exposition | incluez la commande SCANNER BGP de voir la priorité CPU. La valeur du « LSI » dans la sortie suivante témoin emploie « L » pour se rapporter à un processus à basse priorité.

6513# show processes | include BGP Scanner
 172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

CPU de haute due au processus de routeur BGP

Le processus de routeur BGP fonctionne environ une fois par seconde pour vérifier le travail. La convergence BGP définit la durée entre le moment où le premier pair BGP est établi et le point auquel le BGP est convergé. Afin d'assurer les temps de convergence les plus courts possibles, le routeur BGP consomme les cycles CPU tout libres. Cependant, après qu'il commence, il abandonne (ou s'interrompt) la CPU par intermittence.

Le temps de convergence est une mesure directe de combien de temps le routeur BGP passe sur la CPU, pas le temps total. Cette procédure affiche un état CPU de haute pendant la convergence BGP et permute des préfixes BGP avec deux pairs de BGP externe (eBGP).

  1. Capturez une spécification de base pour l'utilisation du processeur normale avant de commencer le test.

    router# show process cpu
      CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%
  2. Une fois les débuts de test, la CPU atteint 100 pour cent d'utilisation. La commande CPU de processus d'exposition prouve que l'état CPU de haute est provoqué par par le routeur BGP, dénoté par 139 (l'ID de processus IOS pour le routeur BGP) dans la sortie suivante.

    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. Surveillez le routeur en capturant de plusieurs sorties du show ip bgp summary et affichez les commandes de processus CPU pendant l'événement. La commande de show ip bgp summary capture l'état des voisins BGP.

    router# show ip bgp summary
      Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
      10.1.1.1    4  64512  309453  157389    19981    0  253 22:06:44 111633
      172.16.1.1  4  65101  188934    1047    40081   41    0 00:07:51 58430
  4. Quand le routeur se termine l'échange de préfixe avec ses pairs BGP, les débits d'utilisation du processeur devraient retourner aux niveaux normaux. L'une minute calculée et cinq moyennes minute arrangeront de retour pour avaler aussi bien et peuvent afficher à supérieur aux niveaux normaux pendant une plus longue période que le débit de cinq secondes.

    router# show process cpu
      CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%
  5. Utilisez la sortie capturée des commandes show ci-dessus de calculer le temps de convergence BGP. En particulier, utilisez la colonne « haut/bas » de la commande de show ip bgp summary et comparez le début et les temps d'arrêt de la CPU de haute conditionnent. Typiquement, la convergence BGP peut prendre plusieurs minutes en permutant une grande table de routage d'Internet.

Remarque: La CPU de haute sur le périphérique a pu également être due à l'instabilité de la table BGP. Si le routeur reçoit deux copies de la table de routage, une de l'EBGP scrutant avec l'ISP et l'autre de l'IBGP scrutant dans le réseau. La cause principale pour ceci est la quantité de mémoire sur le périphérique. Cisco recommande un minimum de 1 yole de RAM pour une copie simple de la table de routage d'Internet. Pour éviter cette instabilité, augmentez la RAM sur le périphérique ou filtrez les préfixes de sorte que la table BGP et la mémoire occupées par lui soit soulagée.

Améliorations des performances

Pendant que le nombre d'artères dans la table de routage d'Internet se développe, fait tellement aussi le temps où elle prend pour que le BGP converge. Généralement la convergence est définie comme processus d'apporter toutes les tables de routage à un état de cohérence. Le BGP est considéré pour être convergé quand les conditions suivantes sont vraies :

  • Toutes les artères ont été reçues.

  • Toutes les artères ont été installées dans la table de routage.

  • La version de table pour tous les pairs égale la version de table de la table BGP.

  • L'InQ et l'OutQ pour tous les pairs est zéro.

Cette section décrit quelques améliorations des performances IOS pour réduire le temps de convergence BGP, qui ont comme conséquence une réduction d'un état CPU de haute dû à un processus BGP.

Alignant au TCP des connexions homologues

Au lieu des données de queue une fois qu'une seconde, le BGP aligne maintenant des données agressivement du BGP OutQ au socket de TCP pour chaque pair jusqu'à ce que l'OutQs se soient écoulés complètement. Puisque le BGP envoie maintenant à une cadence rapide, le BGP converge plus rapidement.

Groupes d'homologues BGP

Tandis qu'ils aident à simplifier la configuration BGP, les groupes de homologues BGP peuvent également améliorer l'évolutivité. Tous les membres du groupe de homologues doivent partager une politique sortante commune. Ainsi, les mêmes paquets de mise à jour peuvent être envoyés à chaque membre du groupe, réduisant le nombre de cycles CPU des lesquels le BGP exige pour annoncer des artères aux pairs. En d'autres termes, avec des groupes de homologues, le BGP marche la table BGP seulement sur le leader de groupe de homologues, filtre les préfixes à l'aide des politiques sortantes, et génère les mises à jour, qu'elle envoie au leader de groupe de homologues. Consécutivement, le leader réplique les mises à jour vers les membres du groupe avec lesquels il est synchronisé. Sans groupes de homologues, le BGP doit marcher la table pour chaque pair, filtrer des préfixes à l'aide des politiques sortantes, et générer les mises à jour qui sont envoyées seulement à l'un pair.

MTU de chemin et la commande d'ip tcp path-mtu-discovery

Toutes les sessions TCP sont liées par une limite sur le nombre d'octets qui peuvent être transportés dans un paquet simple. Cette limite, connue sous le nom de taille maximum de segment (MSS), est de 536 octets par défaut. En d'autres termes, le TCP divise des paquets dans une file d'attente de transmission en 536 blocs d'octet avant de passer des paquets vers le bas à la couche IP. Utilisez le show ip bgp neighbors | incluez la commande data maximum d'afficher le MSS des pairs BGP :

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): 

L'avantage 536 d'un octet MSS est que des paquets ne sont pas susceptibles d'être fragmentés à un périphérique IP le long du chemin à la destination puisque la plupart des liens utilisent un MTU au moins de 1500 octets. L'inconvénient est que de plus petits paquets augmentent la quantité de bande passante utilisée pour transporter le temps système. Puisque le BGP établit une connexion TCP à tous les pairs, 536 temps de convergence BGP d'affects de l'octet MSS.

La solution est d'activer la caractéristique du MTU de chemin (PMTU), utilisant la commande d'ip tcp path-mtu-discovery. Vous pouvez employer cette caractéristique pour déterminer dynamiquement combien grand la valeur MSS peut être sans création des paquets qui doivent être fragmentés. PMTU permet au TCP pour déterminer la plus petite taille de MTU parmi tous les liens en session TCP. Le TCP utilise alors cette valeur de MTU, pièce négative pour les en-têtes IP et de TCP, comme MSS pour la session. Si une session TCP traverse seulement des segments d'Ethernets, alors le MSS sera de 1460 octets. S'il traverse seulement des segments de Paquet sur SONET (POS), alors le MSS sera de 4430 octets. L'augmentation de MSS de 536 à 1460 ou 4430 octets réduit le temps système TCP/IP, qui aide le BGP pour converger plus rapide.

Après l'activation de PMTU, utilisez de nouveau le show ip bgp neighbors | incluez la commande data maximum de voir la valeur MSS par pair :

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): 

Augmentez les files d'attente d'entrée d'interface

Si le BGP annonce des milliers d'artères à beaucoup de pairs, le TCP doit transmettre des milliers de paquets dans une durée. Les pairs BGP reçoivent ces paquets et envoient des accusés de réception de TCP au speaker BGP de la publicité, qui fait recevoir le speaker BGP une pléthore de TCP Acks dans une courte période. Si Acks arrivent à un débit qui est trop élevé pour le processeur d'artère, les paquets sauvegardent dans les files d'attente d'interface d'arrivée. Par défaut, les interfaces de routeur utilisent une taille de file d'attente d'entrée de 75 paquets. En outre, les paquets de contrôle spéciaux tels que des MISES À JOUR BGP utilisent une file d'attente spéciale avec le Rejet sélectif de paquet (SPD). Cette file d'attente spéciale tient 100 paquets. Pendant la convergence BGP, le TCP Acks peut remplir rapidement 175 zones de la mise en mémoire tampon d'entrée et des paquets nouvellement de arrivée doivent être lâchés. Sur des Routeurs avec 15 pairs ou plus BGP et échange de la pleine table de routage d'Internet, plus de 10,000 gouttes par interface par minute peut être vu. Voici l'exemple de sortie d'un routeur 15 minutes après réinitialisation :

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

Augmentant la profondeur de file d'attente d'entrée d'interface (utilisant le hold-queue <1-4096> aux commandes) les aides réduisent le nombre de TCP abandonné Acks, qui réduit la quantité de BGP de travail doit faire pour converger. Normalement, une valeur de 1000 problèmes de résolutions provoqués par des pertes de file d'attente d'entrée.

Remarque: La gamme Cisco 12000 utilise maintenant une valeur par défaut de spd headroom de 1000. Il retient la taille par défaut de file d'attente d'entrée de 75. Utilisez la commande de l'exposition SPD de visualiser ces files d'attente d'entrée spéciales.

Améliorations supplémentaires dans IOS 12.0(19)S

IOS 12.0(19)S inclut plusieurs optimisations au code de groupe de homologues BGP pour améliorer l'emballage et la réplication de mise à jour. Avant que nous discutions ces améliorations, permettez-nous regardent l'emballage et la réplication de mise à jour plus en détail.

Une mise à jour BGP se compose d'une combinaison des attributs (tels que le MED = 50 et LOCAL_PREF = 120) et les préfixes des informations d'accessibilité de couche de liste de réseaux (NLRI) qui partagent cette combinaison des attributs. Plus le BGP peut le répertorier dans une mise à jour simple préfixes NLRI, plus le BGP peut converger depuis le temps système (tel que des en-têtes IP rapide, de TCP, et BGP) est réduits. Le « emballage de mise à jour » se rapporte à l'emballage de NLRI dans des mises à jour BGP. Par exemple, si une table BGP tient 100,000 artères avec 15,000 seules combinaisons d'attribut, le BGP doit envoyer seulement 15,000 mises à jour si NLRI est emballé avec 100 pour cent d'efficacité.

Remarque: Le pour cent zéro d'efficacité d'emballage signifie que le BGP devrait envoyer 100,000 mises à jour dans cet environnement.

Utilisez la commande de show ip bgp peer-group de visualiser l'efficacité des mises à jour BGP.

Si un membre du groupe de homologues est « dans le sync », un routeur BGP prend un message de mise à jour formaté pour le leader de groupe de homologues et le réplique pour le membre. Il est bien plus efficace de répliquer une mise à jour pour un membre du groupe de homologues qu'il est de reformater la mise à jour. Par exemple, supposez qu'un groupe de homologues a 20 membres et tous les membres doivent recevoir 100 messages BGP. La réplication de cent pour cent signifie qu'un routeur BGP formate les 100 messages pour le leader de groupe de homologues et réplique ces messages vers les 19 autres membres du groupe de homologues. Pour confirmer des améliorations de réplication, comparez nombre de messages répliqués vers nombre de messages formatés, comme affiché par la commande de show ip bgp peer-group. Les améliorations font une différence excessive en quelques temps de convergence et permettent au BGP pour prendre en charge beaucoup plus de pairs. Regardons un exemple.

Utilisez la commande de show ip bgp peer-group de vérifier l'efficacité de l'emballage de mise à jour et de la réplication de mise à jour. La sortie suivante est d'un test de convergence avec 6 groupes de homologues, 20 pairs dans chacun des 5 premiers groupes de homologues (pairs d'eBGP) et 100 pairs au sixième groupe de homologues (les pairs internes BGP (iBGP)). En outre, la table BGP qui a été utilisée a eu 36,250 combinaisons d'attribut.

La sortie suivante témoin du show ip bgp peer-group | incluez la commande répliquée sur un routeur exécutant IOS 12.0(18)S affiche les informations suivantes :

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.

Afin de calculer le débit de réplication pour chaque groupe de homologues, divisez le nombre de mises à jour répliquées par le nombre de mises à jour formatées :

1668500/836500 = 1.99 1455000/1050000 = 1.38 1844500/660500 = 2.79 1849000/656000 = 2.81 2003750/501250 = 3.99 12114785/2476715 = 4.89

Si le BGP répliqué parfaitement, alors les groupes de homologues d'eBGP chacun aurait un débit de réplication de 19 parce qu'il y a 20 pairs au groupe de homologues. La mise à jour devrait être formatée pour le leader de groupe de homologues et être puis répliquée vers les 19 autres pairs, fournissant un débit optimal de réplication de 19. Le débit idéal de réplication pour le groupe de homologues d'iBGP serait 99 puisqu'il y a 100 pairs.

Si le BGP emballait des mises à jour parfaitement, alors nous aurions seulement formaté 36,250 mises à jour. Nous devrions seulement devoir générer 36,250 mises à jour pour chaque groupe de homologues parce que c'est le nombre de combinaisons d'attribut dans la table BGP. Formats de groupe de homologues d'iBGP les seuls presque 2,500,000 mises à jour tandis que les groupes de homologues chacun d'eBGP génèrent n'importe où de 500,000 à 1,000,000 mises à jour.

Sur un routeur exécutant IOS 12.0(19)S, le show ip bgp peer-group | incluez la commande répliquée fournit ces informations :

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

Remarque: L'emballage de mise à jour est optimal. Exactement 36,250 mises à jour sont formatées pour chaque groupe de homologues.

688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Remarque: La réplication de mise à jour est également parfaite.

Dépannage

Employez ces procédures afin de dépanner la CPU de haute due au scanner ou au routeur BGP BGP :

  • Les informations de rassemblement sur votre topologie BGP. Déterminez le nombre de pairs BGP et le nombre d'artères annoncé par chaque pair. La durée de l'état CPU de haute est-elle raisonnable basée sur votre environnement ?

  • Déterminez quand la CPU de haute se produit. Coïncide-t-il avec une inspection régulièrement programmée de la table BGP ?

  • Exécutez la commande de show ip bgp flap-statistics. La CPU de haute a-t-elle suivi une instabilité d'interface ?

  • Cinglez par le routeur et puis cinglez du routeur. Des échos d'ICMP sont manipulés comme processus à basse priorité. Le document comprenant le ping et les commandes traceroute explique ceci plus en détail. Assurez que l'expédition régulier n'est pas affecté.

  • Assurez-vous que les paquets peuvent suivre un chemin de transfert rapide en vérifiant si la commutation rapide et/ou le CEF sont activés sur les interfaces d'arrivée et sortantes. Assurez-vous que vous ne voyez l'aucune commande de cef d'ip route-cache sur l'interface ou l'aucune commande d'ip cef sur la configuration globale. Afin d'activer le CEF en mode de configuration globale, utilisez la commande d'ip cef.

  • Obtenez la sortie de ces commandes :

    Commande Description
    Show mls cef summary Affiche le nombre d'artères dans la table multicouche de commutation de couche 3 de matériel de la commutation (MLS) pour tous les protocoles.
    show mls cef maximum-routes Affiche la configuration de système maximum en cours d'artère.
    <status de show mls cef exception > Affiche des informations au sujet de l'état d'exception de Cisco Express Forwarding.

  • Vérifiez la mémoire vive dynamique sur le routeur. Selon la recommandation, il devrait y avoir un minimum de 512 Mo de l'espace de mémoire vive dynamique par pair BGP qui envoie la pleine table de routage d'Internet. Si le routeur a deux pairs EBGP qui exécutent la pleine table de routage d'Internet, alors un Go du minimum 1 de l'espace de mémoire vive dynamique est recommandé. L'espace de mémoire vive dynamique mentionné ici est juste la mémoire exigée pour le BGP. D'autres caractéristiques qui fonctionnent sur le routeur exigeront l'espace supplémentaire de mémoire vive dynamique.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 107615