Ce document décrit les informations de configuration et de dépannage sur la fonctionnalité Maximum-Prefix du Border Gateway Protocol (BGP).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document ne sont pas limitées à des versions logicielles et matérielles spécifiques. Cependant, les exemples sont basés sur des plates-formes de périphérie de la gamme Cisco Catalyst 8500 qui exécutent le logiciel Cisco IOS XE version 17.12.x.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Ce document fournit des informations de configuration et de dépannage sur la fonctionnalité BGP Maximum Prefix. Cette fonctionnalité vous permet de contrôler le nombre de préfixes pouvant être reçus d'un voisin. Par défaut, cette fonctionnalité permet à un routeur de désactiver un homologue lorsque le nombre de préfixes reçus de cet homologue dépasse la limite de préfixe maximum configurée. Ceci est couramment utilisé pour les homologues BGP externes, mais peut être appliqué aux homologues BGP internes.
La fonction Maximum-Prefix est utile lorsque, lors d'une modification de la stratégie sortante sur le site d'appairage distant, un routeur commence à recevoir plus de routes que la mémoire du routeur ne peut en prendre. Si le routeur exécute également des fonctions de routage critiques, une augmentation inattendue des préfixes BGP reçus peut consommer des ressources système et affecter la connectivité réseau interne. Avec la commande neighbor <neighbor-ip> maximum-prefix, il est possible de protéger un routeur contre cette situation.
Lorsque vous prévoyez d'utiliser cette fonctionnalité, tenez compte des points clés suivants :
Savoir combien de routes le routeur d'appairage BGP distant envoie normalement.
Définissez la limite maximum-prefix supérieure au nombre de préfixes attendu en fonctionnement normal. Configurez le seuil d'avertissement comme un pourcentage de cette limite de préfixe maximum.
Remarque : L'option restart tente automatiquement de rétablir une session BGP après que la limite maximum-prefix a terminé la session. Pour obtenir des informations détaillées sur la configuration, consultez Redémarrer la session de voisinage BGP après que la limite de préfixe max. a été atteinte.
Dans cette section, vous trouverez les informations nécessaires à la configuration des fonctionnalités décrites dans ce document.
La syntaxe de commande utilisée pour configurer la fonctionnalité BGP Maximum-Prefix est la suivante :
neighbor {ip-address | peer-group-name} maximum-prefix <maximum> [threshold] [restart <restart-interval>] [warning-only]
Where:
maximum - Représente le nombre maximal de préfixes autorisés à partir du voisin.
threshold — Spécifie le pourcentage de la limite de préfixe maximum configurée à laquelle le routeur génère un message d'avertissement. La plage valide est comprise entre 1 et 100 %.
La valeur par défaut est 75 %.
Par exemple, si la valeur maximale configurée est 20 et le seuil est 60, le routeur génère des messages d'avertissement quand le nombre de routes apprises BGP du voisin dépasse 60% de 20 (12) routes.
restart-interval - Spécifie l'intervalle, en minutes, après que le routeur ait tenté de rétablir la session BGP. La plage valide est comprise entre 1 et 65535 minutes, comme indiqué.
warning-only (Optional) : permet au routeur de générer un message de journal lorsque la limite Maximum-Prefix est dépassée, au lieu de mettre fin à la session d'appairage.
Pour mieux illustrer l'utilisation, considérez cet exemple :
neighbor 10.1.1.1 maximum-prefix 3000 !--- Drops the peering to 10.1.1.1 when !--- more than 3000 prefixes are received. neighbor 10.1.1.1 maximum-prefix 3000 warning-only !--- Logs a warning message when the peer sends !--- more than 3000 prefixes. neighbor 10.1.1.1 maximum-prefix 3000 50 !--- Logs a warning message at 1500 and drops the !--- peering when over 3000 prefixes are sent. neighbor 10.1.1.1 maximum-prefix 3000 50 warning-only !--- Initially warns at 1500 and re-warns !--- (different message) at 3000 prefixes received. !--- However, the BGP Peer is not disconnected.
Topologie BGP à préfixe maximal
Le routeur A du système autonome 200 se connecte directement au routeur B du système autonome 300 via l’interface TenGigabitEthernet0/0/0. Le routeur A utilise 10.0.0.1/30 et le routeur B utilise 10.0.0.2/30. Les routeurs établissent une session eBGP (Border Gateway Protocol) externe à un seul saut sur cette liaison.
Dans la configuration Maximum-Prefix warning-only, le routeur B est configuré pour consigner uniquement un message d'avertissement lorsque le nombre de préfixes reçus du routeur A dépasse le seuil défini.
La configuration des deux routeurs est indiquée dans ce tableau. Notez la présence du mot clé warning-only configuré avec la commande neighbor :
| Routeur_A | Routeur_B |
|---|---|
|
|
Remarque : Dans cet exemple, la commande maximum-prefix génère un avertissement lorsque le nombre de préfixes BGP reçus du voisin 10.0.0.1 dépasse huit.
Les résultats des commandes show et debug dans la section Verify and Troubleshoot de ce document rapportent ce qui se passe sur le routeur B lorsque le nombre de préfixes reçus du routeur A dépasse le seuil défini.
Dans cet exemple, Router_B génère un avertissement lorsque le nombre de préfixes reçus dépasse le seuil d'avertissement. Router_B met fin à la session BGP lorsque le nombre de préfixes reçus dépasse la limite de préfixes maximum. Le mot clé warning-only n'est pas configuré. La commande maximum-prefix termine la session BGP lorsque le nombre de préfixes reçus du voisin dépasse 10 :
| Routeur_A | Routeur_B |
|---|---|
|
|
Remarque : Dans cet exemple, la commande maximum-prefix force la session de voisin à se déconnecter quand les routes apprises par le BGP du voisin dépassent 10.
Les résultats des commandes show et debug dans la section Verify and Troubleshoot signalent ce qui se passe sur le routeur B lorsque le nombre de préfixes qu'il reçoit du routeur A dépasse le seuil défini.
Cette section fournit des informations que vous pouvez utiliser pour confirmer le bon fonctionnement de votre configuration. La syntaxe de commande et les valeurs par défaut de la fonctionnalité utilisée dans ce document sont disponibles sur la page de commande BGP.
Remarque : Référez-vous à Comprendre les informations importantes sur les commandes de débogage avant d'utiliser les commandes de débogage.
show ip bgp neighbor - Affiche l'état du voisin BGP et les informations de limite de préfixe
show ip bgp summary - Affiche l'état de toutes les connexions BGP
debug ip bgp updates in — Affiche les informations relatives aux mises à jour BGP
Faites attention à ces numéros :
Limite de préfixe maximum configurée : 10 (dix préfixes)
Seuil d'avertissement : 80 % (huit préfixes)
Remarque : La génération de route exacte et la configuration d'annonce BGP utilisées pour les préfixes de test sont omises. Le routeur A peut émettre les préfixes par le biais d'instructions réseau ou de la redistribution, ou les apprendre d'autres voisins BGP et les annoncer au routeur B.
Tant que le nombre de préfixes reçus ne dépasse pas le seuil défini, aucun message n'est consigné. Dès que le nombre de routes BGP apprises du voisin 10.0.0.1 dépasse la limite de seuil de huit préfixes, Router_B consigne ce message.
Cette situation est simulée lorsque neuf préfixes sont envoyés :
%BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 9, max 10
Si la situation s'aggrave et dépasse le nombre Maximum-Prefix défini sur 10, le routeur consigne ce message. Cette situation est simulée lorsque davantage de préfixes sont envoyés :
%BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.0.1 (afi 0): 11 exceed limit 10
Router_B#show ip bgp neighbor 10.0.0.1 BGP neighbor is 10.0.0.1, remote AS 200, external link BGP version 4, remote router ID 10.0.0.1 BGP state = Established, up for 00:17:22 Last read 00:00:25, last write 00:00:22, hold time is 180, keepalive interval is 60 seconds Last update received: 00:04:04 Neighbor sessions: 1 active, is not multisession capable (disabled) Neighbor capabilities: Route refresh: advertised and received(new) Four-octets ASN Capability: advertised and received Address family IPv4 Unicast: advertised and received Enhanced Refresh Capability: advertised and received Multisession Capability: Stateful switchover support enabled: NO for session 1 Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 1 2 Keepalives: 20 19 Route Refresh: 0 0 Total: 22 22 Do log neighbor state changes (via global configuration) Default minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast Session: 10.0.0.1 BGP table version 12, neighbor version 12/0 Output queue size : 0 Index 1, Advertise bit 0 1 update-group member Slow-peer detection is disabled Slow-peer split-update-group dynamic is disabled Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 0 11 (Consumes 1496 bytes) Prefixes Total: 0 11 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 11 Used as multipath: n/a 0 Used as secondary: n/a 0 Outbound Inbound Local Policy Denied Prefixes: -------- ------- Bestpath from this peer: 11 n/a Total: 11 0 Maximum prefixes allowed 10 (warning-only) Threshold for warning message 80% Number of NLRIs in the update sent: max 0, min 0 Current session network count peaked at 11 entries at 20:05:46 Aug 19 2026 UTC (00:04:05.075 ago) Highest network count observed at 11 entries at 20:05:46 Aug 19 2026 UTC (00:04:05.075 ago) Last detected as dynamic slow peer: never Dynamic slow peer recovered: never Refresh Epoch: 1 Last Sent Refresh Start-of-rib: never Last Sent Refresh End-of-rib: never Last Received Refresh Start-of-rib: never Last Received Refresh End-of-rib: never Sent Rcvd Refresh activity: ---- ---- Refresh Start-of-RIB 0 0 Refresh End-of-RIB 0 0 Address tracking is enabled, the RIB does have a route to 10.0.0.1 Route to peer address reachability Up: 1; Down: 0 Last notification 00:17:27 Connections established 1; dropped 0 Last reset never External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) Interface associated: TenGigabitEthernet0/0/0 (peering address in same link) Transport(tcp) path-mtu-discovery is enabled Graceful-Restart is disabled SSO is disabled Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1 Local host: 10.0.0.2, Local port: 179 Foreign host: 10.0.0.1, Foreign port: 48663 Connection tableid (VRF): 0 Maximum output segment queue size: 50 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0x386BB365): Timer Starts Wakeups Next Retrans 21 0 0x0 TimeWait 0 0 0x0 AckHold 22 21 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 Linger 0 0 0x0 ProcessQ 0 0 0x0 iss: 3438119007 snduna: 3438119468 sndnxt: 3438119468 irs: 2705427639 rcvnxt: 2705428185 sndwnd: 15924 scale: 0 maxrcvwnd: 16384 rcvwnd: 15839 scale: 0 delrcvwnd: 545 SRTT: 939 ms, RTTO: 1411 ms, RTV: 472 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 1000 ms, ACK hold: 120 ms uptime: 1042758 ms, Sent idletime: 22095 ms, Receive idletime: 21895 ms Status Flags: passive open, gen tcbs Option Flags: nagle, path mtu capable IP Precedence value : 6 Window update Optimisation : Enabled ACK Optimisation : Dynamic ACK Tuning Enabled Datagrams (max data segment is 1460 bytes): Peer MSS: 1460 Rcvd: 44 (out of order: 0), with data: 22, total data bytes: 545 Sent: 45 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 22, total data bytes: 460 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 TCP Semaphore 0x746BB5E1C7B0 FREE
Router_B#show ip bgp summary BGP router identifier 10.0.0.2, local AS number 300 BGP table version is 12, main routing table version 12 11 network entries using 2728 bytes of memory 11 path entries using 1496 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 1 BGP AS-PATH entries using 24 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 4544 total bytes of memory BGP activity 11/0 prefixes, 11/0 paths, scan interval 60 secs 11 networks peaked at 20:05:46 Aug 19 2026 UTC (00:08:51.371 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.1 4 200 27 27 12 0 0 00:22:09 11
Le routeur A annonce 11 préfixes au routeur B. Le routeur B génère un avertissement lorsque le nombre de préfixes reçus atteint neuf et génère un message de dépassement de préfixe maximal lorsque le nombre atteint 11. Étant donné que le paramètre warning-only est configuré, la session BGP reste établie.
Mise en garde : La commande debug ip bgp updates dans peut générer un résultat substantiel et affecter les performances du périphérique. Exécutez cette commande uniquement pendant une fenêtre de dépannage contrôlée, surveillez les ressources système, utilisez des filtres de commandes et désactivez le débogage après la collecte des données.
Router_B#debug ip bgp updates in *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin ?, metric 0, merged path 200, AS_PATH *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.0.0.0/30 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.10.1.0/30 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.1.1.1/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.2.2.2/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.3.3.3/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.4.4.4/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.5.5.5/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.6.6.6/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.7.7.7/32 *Aug 19 20:34:50.019: %BGP-4-MAXPFX: Number of prefixes received from 10.0.0.1 (afi 0) reaches 9, max 10 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.9.9.9/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.8.8.8/32 *Aug 19 20:34:50.019: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.0.0.1 (afi 0): 11 exceeds limit 10 *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.0.0.0/30 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.1.1.1/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.2.2.2/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.3.3.3/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.4.4.4/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.5.5.5/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.6.6.6/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.7.7.7/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.8.8.8/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.9.9.9/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.10.1.0/30 -> 10.0.0.1(global) to main IP table
Dans l'exemple précédent, la relation de voisinage BGP est maintenue même si le routeur voisin envoie plus de préfixes que la politique ne le permet. Le routeur B consigne les messages d'avertissement et de dépassement de préfixe maximal, mais garde la session BGP établie. Le routeur B continue d’accepter les préfixes du voisin, car warning-only est configuré.
Les conditions initiales requises dans ce cas ont le voisin BGP en fonctionnement et avec six préfixes envoyés par le Routeur_A au Routeur_B. Comme le montre l’exemple, lorsque le routeur A annonce d’autres préfixes (par exemple, 9), le résultat des commandes reflète exactement ce qui a déjà été vu dans le cas où le routeur B est configuré pour consigner un message d’avertissement.
Une fois que le routeur A a annoncé un onzième préfixe, le nombre de préfixes reçus dépasse la limite configurée de 10. Le routeur B envoie une notification indiquant le nombre maximal de préfixes atteints et met fin à la session BGP.
Router_B#debug ip bgp updates in
*Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin ?, metric 0, merged path 200, AS_PATH
*Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd 10.7.7.7/32
*Aug 19 20:45:48.779: %BGP-4-MAXPFX: Number of prefixes received from 10.0.0.1 (afi 0) reaches 10, max 10 *Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd 10.9.9.9/32
*Aug 19 20:45:48.779: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.0.0.1 (afi 0): 11 exceeds limit 10 *Aug 19 20:45:48.780: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.1 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 00000A
*Aug 19 20:45:48.780: %BGP-5-NBR_RESET: Neighbor 10.0.0.1 reset (Peer over prefix limit)
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.0.0.0/30
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.1.1.1/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.2.2.2/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.3.3.3/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.4.4.4/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.5.5.5/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.6.6.6/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.7.7.7/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.8.8.8/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.10.1.0/30
*Aug 19 20:45:48.780: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down Peer over prefix limit *Aug 19 20:45:48.780: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.0.1 IPv4 Unicast topology base removed from session Peer over prefix limit
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.0.0.0/30
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.1.1.1/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.2.2.2/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.3.3.3/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.4.4.4/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.5.5.5/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.6.6.6/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.7.7.7/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.8.8.8/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.1.0/30
Router_B#show ip bgp summary
BGP router identifier 10.0.0.2, local AS number 300
BGP table version is 25, main routing table version 25
17 networks peaked at 20:33:04 Aug 19 2026 UTC (00:13:00.072 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 200 0 0 1 0 0 00:00:15 Idle (PfxCt)
Remarque : Dans ce scénario, vous devez utiliser la commande clear ip bgp <neighbor-ip> pour restaurer la session homologue. Avant de réinitialiser la session, réduisez le nombre de préfixes annoncés par l'homologue ou ajustez la limite maximum-prefix configurée après la validation de la capacité. Cette commande réinitialise la session BGP et supprime temporairement les routes apprises de l'homologue.
Router_B#show ip bgp neighbors 10.0.0.1
BGP neighbor is 10.0.0.1, remote AS 200, external link
BGP version 4, remote router ID 10.0.0.1
BGP state = Idle, down for 00:00:39
Last update received: n/a
Neighbor sessions:
0 active, is not multisession capable (disabled)
Stateful switchover support enabled: NO for session 0
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 1
Notifications: 1 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 1 1
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 25, neighbor version 1/25
Output queue size : 0
Index 0, Advertise bit 0
Address family not supported notification sent
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 10
Threshold for warning message 80%
Reduce the no. of prefix and clear ip bgp 10.0.0.1 to restore peering
Number of NLRIs in the update sent: max 0, min 0
Highest network count observed at 12 entries at 20:32:03 Aug 19 2026 UTC (00:14:25.012 ago) Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 1
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
Address tracking is enabled, the RIB does have a route to 10.0.0.1
Route to peer address reachability Up: 1; Down: 0
Last notification 00:54:04
Connections established 3; dropped 3
Last reset 00:00:39, due to BGP protocol initialization
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
Interface associated: TenGigabitEthernet0/0/0 (peering address in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
No active TCP connection
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
20-Aug-2026
|
Mise à jour du titre, de l'orthographe, de la grammaire, insertion de lignes horizontales pour séparer les sections pour plus de lisibilité. |
1.0 |
09-Jul-2002
|
Première publication |