Introducción
Este documento explica el tiempo involucrado cuando un peer BGP se marca con la trampa BGPPeerSessionDown con respecto a la sincronización del evento que lo desencadenó. El tiempo que tarda el par en ser marcado es un valor menor que el tiempo del temporizador de espera. Este problema concreto se notificó en un router de servicios de agregación (ASR) 5000 de Cisco, pero se aplicaría igualmente a un ASR 5500.
Problema
En este caso concreto, se reinició el proceso de npumgr en la tarjeta de conmutación de paquetes Demux (PSC) 1 en ASR 5000 debido a un problema de Micro Engine, lo que no es tan poco común en un problema transitorio (no hay necesidad de 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 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)
Estas trampas del protocolo simple de administración de red (SNMP) indican una ventana de 10 segundos sobre la que se cerraron todos los peers BGP en el gateway empresarial:
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
BGP se controla en Demux PSC 1 que en este caso es la tarjeta que tuvo el problema. Por lo tanto, no es inesperado que BGP se interrumpa. Además, como se trataba de un chasis de tecnología de recuperación de sesiones entre chasis (ICSR) activo, había un switchover de protocolo de redundancia de servicios (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 fue a las 13:51:45 por las trampas/registros, ¿no se espera que los peers se caigan antes del período de tiempo del temporizador de retención BGP?
Respuesta
La configuración de BGP para todos estos peers es la misma que la siguiente:
timers bgp keepalive-interval 10 holdtime-interval 60
Mientras se configura durante 60 segundos, la negociación con el par honra el valor inferior, que es de 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 explicarse los compañeros que bajan entre las 13:52:00 y las 13:52:10 cuando el evento fue a las 13:51:45?
La respuesta es que es posible que la conectividad se viera comprometida como resultado del problema de la Unidad de procesador de red (NPU) antes de que se visualizara el primer registro. Por ejemplo, haga una suposición de 5 segundos a las 13:51:40. Cada par de peers BGP envía/recibe señales de mantenimiento cada 10 segundos, cada uno en su propio "ciclo". Los pares de peers BGP no se sincronizan entre sí con respecto a los intervalos de mantenimiento, aunque cada par tiene el mismo valor de 10 segundos. Puede suponer que en cualquier intervalo de tiempo de 10 segundos, todos los pares han enviado señales de mantenimiento, ya que el intervalo de keepalive es de 10 segundos. Si la conectividad se interrumpió a las 13:51:40, entonces todos los pares enviaron sus últimas señales de mantenimiento en algún momento entre las 13:51:30 y las 13:51:40 en función de sus ciclos (recuerde que cada par no está relacionado con ningún otro par). En este caso, si no se reciben más señales de mantenimiento después de este intervalo de tiempo, significa que la expiración de 30 segundos ocurriría en el rango de 13:52:00 - 13:52:10, que es precisamente cuando todos los pares fueron marcados.
En resumen, después del punto en el tiempo en que se interrumpe la conectividad (si se puede determinar o no es otra pregunta), se espera que BGP se reduzca algún tiempo entre el intervalo de tiempo de espera y el intervalo de tiempo de espera menos el intervalo de keepalive acordado. En este caso, sería entre 20 y 30 segundos.
Información Relacionada
Comentarios