Sommario

Introduzione

Problema

Ambiente

Risoluzione

Causa

Informazioni correlate

Introduzione

In questo documento vengono descritti i tempi di ripristino estesi e gli errori di accesso SSH causati dall'accumulazione di pacchetti di trust CEPKI su un nodo NCS 1010 (con Cisco IOS® XR 24.3.1, 25.1.1).

Problema

I tempi di ripristino estesi intermittenti vengono osservati dopo il ricaricamento del Route Processor (RP) sui nodi ottici NCS 1010. Durante il periodo di ripristino, l'accesso SSH al dispositivo non riesce a causa di ritardi nell'inizializzazione di Cisco Embedded Public Key Infrastructure (CEPKI). In questo modo si evitano la gestione remota e le attività operative sui nodi interessati. I messaggi syslog e gli errori SSH indicano che il processo SSHD non può recuperare le chiavi host da CEPKI finché non viene completata l'inizializzazione, con conseguenti errori di accesso SSH. Il ripristino dell'accesso SSH viene osservato solo dopo il completamento dell'inizializzazione di CEPKI, spesso dopo 30-60 minuti. Il problema è correlato a un grande accumulo di pacchetti trustpool sul dispositivo, in particolare sulle versioni software 24.3.1 e 25.1.1.

Ambiente

- Tecnologia: Reti ottiche

- Famiglia di prodotti: NCS serie 1000 (nodi ottici NCS 1010)

- Versioni software: IOS XR 24.3.1, 25.1.1 (problema riprodotto su entrambi)

- Componenti: Route Processor (RP), CEPKI, processo SSHD

- Funzioni operative: Applicazioni Call-Home, Smart Licensing

- Osservazioni Recenti: Tempi di ripristino prolungati, errori di accesso SSH dopo il ricaricamento dell'RP, accumulo di bundle trustpool elevati

Risoluzione

Per ridurre e risolvere il ritardo di inizializzazione CEPKI e l'errore di accesso SSH dovuto all'accumulo del bundle del trustpool, attenersi alla procedura descritta. Questi passaggi derivano direttamente dall'analisi tecnica convalidata e dalle risoluzioni documentate.

1. Verifica Accumulazione Bundle Trustpool:

Eseguire questi comandi per esaminare lo stato corrente del bundle del trustpool e le informazioni sul certificato correlato. Gli output di esempio non sono disponibili nei dati forniti.

Passaggio 1. Esaminare le informazioni tecniche dettagliate relative a NCS1010.

show tech ncs1010 detailed

Passaggio 2. Esaminare i dettagli della sessione di crittografia.

show tech crypto session

Passaggio 3. Verificare i dati del supporto tecnico CEPKI.

show tech-support cepki

Passaggio 4. Verificare lo stato del database di sistema.

show tech sysdb

Passaggio 5. Elencare tutti i certificati delle CA crittografiche installati.

show crypto ca certificates

Passaggio 6. Visualizzare i dettagli del bundle del trustpool.

show crypto ca trustpool detail

Passaggio 7. Visualizzare lo stato del trust pool.

show crypto ca trustpool

Passaggio 8. Visualizzare i criteri del pool di fiducia.

show crypto ca trustpool policy

2. Soluzione per le versioni interessate (24.3.1 e 25.1.1):

Per pulire i bundle trustpool accumulati e forzare la reimportazione, eseguire i comandi indicati in sequenza. Questo processo rimuove i certificati del pool di fiducia scaricati in precedenza e scarica il bundle corrente, riducendo i ritardi di inizializzazione.

Passaggio 1. Eliminare i certificati del pool di fiducia prima dell'importazione.

crypto ca trustpool import url clean

Passaggio 2. Importare il bundle trustpool.

crypto ca trustpool import url

3. Correzione permanente (aggiornamento consigliato):

Il problema sottostante è stato risolto in Cisco IOS XR versione 26.1.1 con ID bug Cisco CSCwq39205.

Eseguire l'aggiornamento a questa release per assicurarsi che il sistema cancelli automaticamente i certificati del pool di fiducia scaricati in precedenza prima di scaricare il bundle corrente. In questo modo viene mantenuto uno stato del pool di fiducia pulito e coerente per le operazioni future.

4. Consulenza sul metodo di trasporto a domicilio:

Si noti che Cisco ha annunciato la fine del ciclo di vita (EoL) per il metodo di trasporto Call-Home a partire da Cisco IOS XR versione 25.3.1. Si consiglia di passare al metodo di trasporto di Smart Licensing per continuare a supportare il sistema. Per ulteriori informazioni, fare riferimento agli avvisi Cisco forniti.

Indicatori tecnici e registri:

- Syslog:

sshd[21897]: main: failed to get keys from cepki

- Syslog:

cepki[274]: certificate database updated

- Errore SSH:

ssh: connect to host <node> port 22: Connection refused

- Osservazione: Processo CEPKI che aggiorna ripetutamente i certificati senza il segnale di fine inizializzazione (EOI).

- Numero di pool di trust osservato: 20 occorrenze di 'Trustpool: Predefinito, 768 di 'Pool di fiducia: Scaricato'.

Causa

La causa principale è l'accumulo di più pacchetti trustpool sul dispositivo, innescato da download ripetuti tramite applicazioni Call-Home e Smart Licensing. Nelle versioni 24.3.1 e 25.1.1 di Cisco IOS XR, queste applicazioni scaricano i trust pool senza cancellare i certificati precedentemente archiviati, causando ritardi nell'inizializzazione di CEPKI e nel recupero della chiave SSH. Questo comportamento è stato risolto e risolto in Cisco Bug ID CSCwq39205.

nella release 26.1.1, in cui il sistema cancella i certificati del trustpool precedenti prima di scaricare nuovi bundle.

Informazioni correlate

- Cisco Bug ID CSCwq39205 - È necessario cancellare il bundle del pool di fiducia prima di scaricarlo di nuovo

- Cisco Bug ID CSCwq53226 - Consulenza sulla fine del ciclo di vita del metodo di trasporto a domicilio

- Consulenza Cisco: Notifica della migrazione "call-home" a Smart Transport

- Supporto tecnico Cisco e download