5000 Series ASR: Los desvíos de “BGPPeerSessionDown” en menos que el periodo del temporizador del control después del evento quebrado de la Conectividad ocurren

Introducción

Este documento explica la sincronización implicada cuando marcan a un par del Border Gateway Protocol (BGP) abajo con el desvío de BGPPeerSessionDown en cuanto a la sincronización del evento que la accionó. El tiempo que toma para que el par consiga marcado abajo es un valor menos que la época del temporizador del control. Este problema determinado fue señalado sobre un router de los servicios de la agregación de Cisco (ASR) 5000 pero se aplicaría igualmente a un ASR 5500.

Problema

En este caso particular, había un reinicio del proceso del npumgr en el indicador luminoso LED amarillo de la placa muestra gravedad menor de conmutación de conjunto de bits de Demux (PSC) 1 en ASR 5000 debido al problema micro del motor, que no es ése infrecuente de un problema transitorio (no hay necesidad del RMA):

2015-Jun-13+13:51:44.198 [sft 58000 info] [1/0/4255 <sft:100>
 sft_monitor.c:115]
[software internal system critical-info syslog] SFT : Forced 1 times RX
 packet at slot 1, cpu 0, inst 100, inflight packets 30

2015-Jun-13+13:51:45.306 [sft 58000 info] [1/0/4255 <sft:100>
 sft_monitor.c:115]
[software internal system critical-info syslog] SFT : Forced 81 times RX
 packet at slot 1, cpu 0, inst 100, inflight packets 110

2015-Jun-13+13:51:45.205 [sft 58000 info] [1/0/4255 <sft:100>
 sft_monitor.c:115]
[software internal system critical-info syslog] SFT : Forced 71 times RX
 packet at slot 1, cpu 0, inst 100, inflight packets 100

Sat Jun 13 13:51:45 2015 Internal trap notification 73 (ManagerFailure)
facility npumgr instance 1 card 1 cpu 1

2015-Jun-13+13:51:45.335 [npuctrl 16019 error] [8/0/4729 <npuctrl:0>
rl_sf_handler.c:2570] [software internal system syslog] SF CTRL:
 monitoring_recovery: 
Task packet test failed on failed_card 1, calling npuctrl_sf_insert_card()

2015-Jun-13+13:51:48.469 [npuctrl 16019 error] [8/0/4729 <npuctrl:0>
rl_sf_handler.c:2558] [software internal system syslog] SF CTRL:
 monitoring_recovery:
 too many sf insert calls on failed_card 1, cnt = 1 calling
 npuctrl_restart_npumgr()

Sat Jun 13 13:51:48 2015 Internal trap notification 150 (TaskFailed)
 facility npumgr instance 1 on card 1 cpu 1

2015-Jun-13+13:51:48.470 [npuctrl 16020 info] [8/0/4729 <npuctrl:0>
npuctrl_func.c:230] [software internal system critical-info syslog]
 CTRL: restart npumgr instance 1

2015-Jun-13+13:51:48.547 [rct 13012 info] [8/0/4643 <rct:0> rct_task.c:323]
[software internal system critical-info syslog] Death notification of task
 npumgr/1 on 1/1 sent to parent task npuctrl/0

Sat Jun 13 13:51:58 2015 Internal trap notification 1099 (ManagerRestart)
facility npumgr instance 1 card 1 cpu 1

Sat Jun 13 13:51:58 2015 Internal trap notification 151 (TaskRestart)
facility npumgr instance 1 on card 1 cpu 1

2015-Jun-13+13:51:58.376 [npuctrl 16018 info] [8/0/4729 <npuctrl:0>
npuctrl_msg.c:241] [software internal system critical-info syslog] 
task facility npumgr instance 1 created

El escáner de la ingeniería lo captura bien: 

%%%%%%%%%%%%% SFT : Forced X times RX packet at slot Y %%%%%%%%%%%%%
May be a case of Ucode storage corruption.  Please check techzone article
2015-Jun-13+13:51:48.729  [sft 58000 info] [1/0/4255  sft_monitor.c:115] 
[software internal system critical-info syslog] SFT : Forced 321 times 
RX packet at slot 1, cpu 0, inst 100, inflight packets 238(Count: 33,          
First seen: 2015-Jun-13+13:51:44.903,     
Last seen: 2015-Jun-13+13:51:48.729)

Estos desvíos del Simple Network Management Protocol (SNMP) indican una segundo ventana 10 abajo de la cual todos los peeres BGP en el gateway de la empresa pasaron:

Sat Jun 13 13:52:00 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS14 ipaddr 55.54.84.107

Sat Jun 13 13:52:02 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS16 ipaddr 55.54.84.123

Sat Jun 13 13:52:03 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS06 ipaddr 55.54.84.43

Sat Jun 13 13:52:04 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS04 ipaddr 55.54.84.26

Sat Jun 13 13:52:04 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS14 ipaddr 55.54.84.106

Sat Jun 13 13:52:04 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS05 ipaddr 55.54.84.35

Sat Jun 13 13:52:04 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS02 ipaddr 55.54.84.11

Sat Jun 13 13:52:04 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn EXGWin ipaddr 55.55.245.4

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS16 ipaddr 55.54.84.122

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS12 ipaddr 55.54.84.91

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS01 ipaddr 55.54.84.3

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS11 ipaddr 55.54.84.83

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS15 ipaddr 55.54.84.115

Sat Jun 13 13:52:05 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS01 ipaddr 55.54.84.2

Sat Jun 13 13:52:06 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS04 ipaddr 55.54.84.27

Sat Jun 13 13:52:06 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS05 ipaddr 55.54.84.34

Sat Jun 13 13:52:06 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS11 ipaddr 55.54.84.82

Sat Jun 13 13:52:06 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS06 ipaddr 55.54.84.42

Sat Jun 13 13:52:07 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Ingress ipaddr 55.55.245.5

Sat Jun 13 13:52:07 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS03 ipaddr 55.54.84.18

Sat Jun 13 13:52:07 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS10 ipaddr 55.54.84.254

Sat Jun 13 13:52:08 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS03 ipaddr 55.54.84.19

Sat Jun 13 13:52:08 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS15 ipaddr 55.54.84.114

Sat Jun 13 13:52:09 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS02 ipaddr 55.54.84.10

Sat Jun 13 13:52:10 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS13 ipaddr 55.54.84.98

Sat Jun 13 13:52:10 2015 Internal trap notification 119 (BGPPeerSessionDown)
vpn Egress-MPLS12 ipaddr 55.54.84.90 

El BGP se controla en el PSC 1 de Demux que en este caso es el indicador luminoso LED amarillo de la placa muestra gravedad menor que tenía el problema. Es por lo tanto no inesperado para que el BGP vaya abajo. Además, puesto que esto era una recuperación inter activa de la sesión del chasis (ICSR) - chasis de la tecnología, había un intercambio del Redundancy Protocol del servicio (SRP):

[local]Enterprise_XGW> show srp call-loss statistics
 Switchover-9  started at : Sat Jun 13 13:52:06 2015,  took 3 seconds to finish.
    Switchover reason : BGP failure
    Total number of active calls at switchover time : 714711

Solución

Pregunta

¿Si el incidente estuviera en 13:51:45 por los desvíos/los registros, no se esperaba que para que a los pares vayan abajo de no más pronto que el período de tiempo del temporizador del control BGP?

Respuesta

Las configuraciones BGP para todos estos pares son lo mismo que esto:

timers bgp keepalive-interval 10 holdtime-interval 60

 Mientras que está configurada por 60 segundos, la negociación con el par honra el valor inferior, que es 30 segundos:

******** show ip bgp neighbors *******
Saturday June 13 14:42:38 UTC 2015
BGP neighbor is 55.55.245.4, remote AS 22394, local AS  64873, external link
  BGP version 4, remote router ID 55.54.244.197
  BGP state = Established,up for 5d04h29m
  Hold time is 30 seconds, keepalive interval is 10 seconds
  Configured Hold time is 60 seconds, keepalive interval is 10 seconds

¿Cómo pueden los pares que vaya abajo entre 13:52:00 y 13:52:10 a ser explicado cuando el evento estaba en 13:51:45?

La respuesta es que es posible que la Conectividad fue comprometida como resultado del problema de la unidad del procesador de red (NPU) antes de que el primer registro fuera visualizado. Por ejemplo, haga una suposición de 5 segundos en 13:51:40. Cada peer BGP que el par envía/que recibe las señales de mantenimiento cada 10 segundos, cada uno en sus los propio “ciclo”. El peer BGP que no son los pares sincronizó todo a uno otro en lo que respecta a los intervalos señales de mantenimiento, aunque cada par tiene la misma configuración de 10 segundos. Usted puede asumir que en cualquier segundo intervalo 10 del tiempo, todos los pares han enviado el Keepalives puesto que el intervalo de keepalive es 10 segundos.  Si la Conectividad se rompió en 13:51:40, después todos los peeres de entidades pares enviaron su Keepalives más reciente alguna vez entre 13:51:30 y 13:51:40 basados en cuáles eran sus ciclos (recuerde que cada par está sin relación a cualquier otro par). En este caso, sin el Keepalives adicional recibido después de este rango de tiempo, significa que el segundo vencimiento 30 ocurriría en el rango de 13:52:00 - 13:52:10, que está exacto cuando marcaron a todos los pares abajo.

En fin, después de que se esperara que la punta en el tiempo que la Conectividad está quebrada (si ésa puede ser determinado o no es otra pregunta), BGP fuera marcada abajo de una cierta hora entre el intervalo de tiempo en espera y el intervalo de tiempo en espera menos el intervalo de keepalive estado de acuerdo. En este caso eso sería entre 20 y 30 segundos.

Información Relacionada

• Guía de administración del sistema ASR5000 - Cisco Systems
• Soporte Técnico y Documentación - Cisco Systems