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.
Feedback