Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Coleção de Logs

RCM

Etapa 1. Capturar algumas saídas de comando

Etapa 2. Coletar registros do controlador e do Configmgr

PARA CIMA

Troubleshooting

Cenário para UPs que ficam presos no estado Pendente

Solução

Introdução

Este documento descreve os problemas relacionados à incompatibilidade de estados UPF no RCM.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- Gerenciador de Configuração de Redundância (RCM)

- Função do plano do usuário (UPF/UP)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Coleção de Logs

RCM

Etapa 1. Capturar algumas saídas de comando

Primeiro, você deve identificar qual é a UP problemática e qual é o padrão da questão. Para determinar quais UPs passaram por um switchover e identificar onde o problema atual está localizado, é essencial documentar os motivos dos switchovers.

rcm show-statistics switchover

rcm show-statistics switchover-verbose

rcm show-statistics configmgr  --------------- to check how many UPs are registered for config push

rcm show-statistics controller --------------- to check no of UPs and its states registered with controller

Etapa 2. Coletar registros do controlador e do Configmgr

Depois de identificar entre quais UPs o problema está, você pode coletar logs do controlador e logs do configmgr para identificar qual foi a causa do switchover e o que deu errado para os UPs ficarem presos no estado Pendente.

Consulte o link Coleta de logs do RCM para obter informações sobre o procedimento de coleta de logs.

PARA CIMA

SSD, Syslogs e traps SNMP para o timestamp problemático, cobrem o período de tempo pelo menos duas horas antes do início do problema.

Troubleshooting

Cenário para UPs que ficam presos no estado Pendente

- Geralmente, todo UP se registra no RCM por meio do controlador

- A controladora é responsável por manter os estados UP que recebe do UP e o atribuído pelo RCM e compilá-los

rcm show-statistics controller

message :

{

"keepalive_version": "f1ab207c5d3120f8a4286b999b9f4cd207034e7c61e204d74e41f48578c476de",

"keepalive_timeout": "20s",

"num_groups": 2,

"groups": [

{

"groupid": 1,

"endpoints_configured": 7,

"standby_configured": 1,

"pause_switchover": false,

"active": 2,

"standby": 0,

"endpoints": [

{

"endpoint": "X.X.X.X",    -------- UP IP

"bfd_status": "STATE_UP",

"upf_registered": true,

"upf_connected": true,

"upf_state_received": "UpfMsgState_Active",

"bfd_state": "BFDState_UP",

"upf_state": "UPFState_PendActive",

"route_modifier": 32,

"pool_received": false,

"echo_received": 253,

"management_ip": "X.X.X.X",

"host_id": "SEUD2413",

"ssh_ip": "Y.Y.Y.Y",

"force_nso_registration": false

},

Nas estatísticas do controlador, se observadas, há diferentes estados que o controlador está mantendo e cada estado UP tem seu próprio significado.

Estado de BFD - Indica o estado de BFD entre RCM e UP (não se refere a ele como estado de UF, é apenas estado de BFD)

Estado da UPF - O estado atual da UPF no RCM

Estado UPF recebido - estado UP enviado por UP para RCM

- De acordo com o fluxo em geral, sempre que houver um switchover de Ativo UP para Standby UP, o RCM deve passar por certos procedimentos para transferências suaves mencionadas aqui:

1. Checkpointmgr liberar de UP antigo e sincronizar ponto de verificação com o novo UP Ativo

2. Liberação de configuração

3. Envio de configuração

4. Gerenciamento de estados UP

Considere o exemplo de par UP como UP-A (UP Ativo) e UP-B (Standby-UP) e quando há um switchover antes de entrar nos estados Ativo e Standby, ele primeiro entra no estado Pendente.

UP-A (Ativo UP) --------------------- PendStandby ---------------------- Standby

UP-B (Standby UP) ------------------- PendActive ---------------------- Ative

Como pode ser visto antes de se tornar Ativo/Em espera, as transações de procedimentos mencionadas estão ocorrendo entre o RCM e o UP para que haja uma transição tranquila.

- Sempre que houver um switchover de Ativo para Standby e vice-versa, o RCM deve executar um push de configuração onde ele envia a configuração Ativo UP no UP que se torna Ativo e envia a configuração de Standby UP no UP que se torna Standby.

Note :: In Standby UP normally RCM push all the UP config which are currently active so that whenever this UP becomes active it removes all the unwanted config

- Assim que o switchover é iniciado, o RCM tem um valor de temporizador de 15 minutos (ele varia com base no valor configurado) e dentro desse valor de temporizador, ele deve concluir o switchover que é concluído depois que o envio da configuração é concluído.

- Agora, por algum motivo, se o envio da configuração não for concluído dentro do tempo em que o temporizador expira e o RCM inicia a recarga para o UP. Isso continua até que o envio da configuração seja concluído.

- Assim, quando o RCM está enviando a configuração para o UP, ele espera um sinal de configuração completa do UP com base no qual o RCM entende que o envio da configuração foi concluído e o considera um switchover bem-sucedido.

Esse é o registro que pode ser visto nos syslogs e nas interceptações SNMP quando o envio da configuração é concluído.

Syslogs

Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1]  [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete

Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1]  [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config

SNMP

Fri Mar 24 09:59:01 2023 Internal trap notification 1425 (RCMTCPConnect) Context Name: rcm

Fri Mar 24 09:59:01 2023 Internal trap notification 1421 (RCMConfigPushCompleteSent) Context Name: rcm

Fri Mar 24 09:59:01 2023 Internal trap notification 1426 (RCMChassisState) RCM Chassis State: (2) Chassis State Standby

Fri Mar 24 09:59:04 2023 Internal trap notification 1276 (BFDSessionUp) vpn n6 OurAddr fc00:10:5:132::10 NeighborAddr fc00:10:5:132::254 Session(6/1090552866), Diagnostic code 0 PhyPortId 0

- No entanto, caso haja algum problema devido ao qual a conclusão do envio da configuração esteja demorando, o que faz com que o valor do temporizador expire, ocorrerão esses problemas de UP travado no estado Pending.

- Como o RCM não obteve o status de conclusão do envio da configuração, ele considera que o switchover não está concluído e mantém UP no estado Pending.

- Motivos diferentes para problemas de envio de configuração são explicados em UP Reload Causes.

Solução

1. Temporariamente você pode forçar o sinal config push complete do UP para o RCM com este comando mencionado para trazer de volta o UP no estado Ativo/Standby:

rcm-config-push-complete end-of-config

2. Esta solução alternativa mencionada é apenas temporária para identificar o problema que leva tempo para o envio de configuração, que é descrito em UP Reload Causes.