ARGOMENTO:

Ciao a tutti,

facendo l'esame del capitolo 2 della CCNP ROUTE,c'era questa domanda:


html1-f.scribdassets.com/847mgsp6f4m42de...ges/6-a9853f8107.png


Refer to the exhibit. A network administrator has configured R1 and R2 for EIGRP authentication with multiplekeys and activation times. After functioning normally for a month, R1 and R2 are now no longer forming anEIGRP adjacency. Which configuration change to the key lifetimes will correct the EIGRP adjacency problem?

a.Change the key 1 accept life to an end time of Feb 1 on both routers.

b.Change key 2 send lifetime to a start time of Jan 1 on both routers.

c.Change the key 1 send lifetime to an end time of Feb 1 on both routers.

d.Change the key 2 accept lifetime to a start time of infinite on both routers.

---

La risposta giusta è la C,però da domanda dice che non formano più l'adiacenza,e il debug indica che la data si riferisce al 6 febbraio,ovviamente l'accettazione della key 1 è scaduta su entrambi i router poichè l'accept-lifetime è fino al 5 febbraio,ma l'adiacenza dovrebbe comunque persistere perchè c'è la key 2 che è valida che si sovrappone alla key 1,perchè dalla domanda risulta che non c'è più l'adiacenza?E perchè modificando il send-lifetime su entrambi i router all'end time 1 febbraio dovrebbe ristabilirsi?Ok,la chiave non è più accettabile,quindi la dovrebbe ignorare,ma non negare l'adiacenza,giusto?C'è sempre key 2 a essere valida...chi mi aiuta a capire?Ho scelto la risposta C da esame perchè sono andato a esclusione siccome la B e la D si riferiscono a key 2 che non centra...e la A non avrebbe avuto senso...e ci ho azzeccato...ma vorrei capire...grazie

Ciao Luigi, ciao a tutti.
Premetto che la mia risposta è frutto di un mio ragionamento/osservazioni varie.
Attendo la conferma (o smentita) di Virgilio per avere una risposta più precisa e chiara possibile

In sintesi, io ho capito che il funzionamento dell'EIGRP AUTHENTICATION funziona così:

1. 1)
   Quando un EIGRP router invia un pacchetto autenticato, il router esamina le KEYs nel suo KEY-CHAIN, secondo l'ordine crescende di KEY ID (dal KEY-ID più piccolo al più grande) e di VALIDITA' (LIFETIME);
quindi userà la KEY-ID 1 ("firstkey") in quanto è la prima KEY valida [VALID NOW] che incontra scorrendo dall'inizio il suo KEY-CHAIN[/li]

2. 2)
   Quando un EIGRP router riceve un pacchetto autenticato, lo esamina usando tutte le KEYs valide [VALID NOW] del suo KEY-CHAIN,
   finchè non trova un MATCH; in caso negativo (nessun MATCH), cade l'adiacenza (neighborship) tra i due EIGRP router.
3. 3)
   Per evitare un periodo temporale in cui non esistano KEYs VALIDE, è consigliabile creare un OVERLAP dell'ACCEPT-LIFETIME tra le KEYs del KEY-CHAIN, in maniera che la "rotazione delle chiavi" vada a buon fine EVITANDO che la NEIGHBORSHIP tra i 2 router vada DOWN.

Per qunto detto al punto 1), R1 userà la chiave 1 ("firstkey") per inviare i pacchetti ad R2 a partire da 1 JAN 2010 per sempre (SEND LIFETIME);
R1, quindi, non userà mai la KEY "secondkey" per l'invio dei pacchetti EIGRP (specularmente, vale lo stesso per R2 nei confronti di R1);
il problema è che la KEY "firstkey" verrà accettata fino al 5 FEB 2010, poi non sarà più MATCHATA, quindi cadrà la neighborship tra R1 e R2;
per tale motivo, l'END-TIME del SEND LIFETIME della KEY 1 "firstkey" deve terminare l' 1 FEB 2010;

##############################################################################################

R2# show key chain
Key-chain R2_eigrp_keys:
key 1 -- text "firstkey"
accept lifetime (12:00:00 UTC Jan 1 2010) - (12:00:00 UTC Feb 5 2010)
send lifetime (12:00:00 UTC Jan 1 2010) - (infinite) [VALID NOW]
key 2 -- text "secondkey"
accept lifetime (12:00:00 UTC Feb 1 2010) - (12:00:00 UTC Mar 5 2010) [VALID NOW]
send lifetime (12:00:00 UTC Feb 1 2010) - (infinite) [VALID NOW]
###################################################################################################
R1# show key chain
Key-chain R1_eigrp_keys:
key 1 -- text "firstkey"
accept lifetime (12:00:00 UTC Jan 1 2010) - (12:00:00 UTC Feb 5 2010)
send lifetime (12:00:00 UTC Jan 1 2010) - (infinite) [VALID NOW]
key 2 -- text "secondkey"
accept lifetime (12:00:00 UTC Feb 1 2010) - (12:00:00 UTC Mar 5 2010) [VALID NOW]
send lifetime (12:00:00 UTC Feb 1 2010) - (infinite) [VALID NOW]
###################################################################################################
R2# debug eigrp packets
EIGRP Packet debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

*Feb 6 21:35:52.490: EIGRP: pkt authentication key id = 1, key not defined or not live
*Feb 6 21:35:52.490: EIGRP: Serial0/1/0: ignored packet from 192.168.0.254, opcode = 5 (invalid authentication)
###################################################################################################


Risposte possibili:
=============
a. Change the key 1 accept life to an end time of Feb 1 on both routers. ====> Non è necessario, per il motivo spiegato al punto 2);
b. Change key 2 send lifetime to a start time of Jan 1 on both routers. ====> Non è necessario, per il punto 1); verrebbe sempre usata la prima key "firstkey" per l'invio;
==> c. Change the key 1 send lifetime to an end time of Feb 1 on both routers. ==> Corretto, così dopo il 1 FEB 2010 verrà usata la key 2 "secondkey" per l'invio;
d. Change the key 2 accept lifetime to a start time of infinite on both routers. ==> Non credo sia necessario;

Mi è impossibile rispondere in modo più esauriente di Filippo, per sintetizzare se la chiave che un router accetta è differente da quelle valide in ricezione l'adiacenza non si instaura, questo vale anche se il router riceve la stessa chiave che sta inviando diversa però da quella valida in ricezione. Perchè l'adiacenza si instauri la cosa importante è che il router riceva una chiave valida in ricezione.

Vi ringrazio per le vostre risposte.

Quindi,da quanto ho capito,anche se c'è un overlap di chiavi,l'adiacenza si perde perchè i router hanno il send lifetime infinito sulla prima key,quindi finchè non scade,il router userà sempre e solo quella,come se la seconda key non esistesse.

Grazie mille!