You are troubleshooting an IPsec session and see the following IPsec security associations:
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
< 192.168.224.1 500 ESP:aes-256/sha1 d6393645 26/ unlim – 0
> 192.168.224.1 500 ESP:aes-256/sha1 153ec235 26/ unlim – 0
< 192.168.224.1 500 ESP:aes-256/sha1 f9a2db9a 3011/ unlim – 0
> 192.168.224.1 500 ESP:aes-256/sha1 153ec236 3011/ unlim – 0
What are two reasons for this behavior? (Choose two.)
A.
Both peers are trying to establish IKE Phase 1 but are not successful.
B.
Both peers have established SAs with one another, resulting in two IPsec tunnels.
C.
The lifetime of the Phase 2 negotiation is close to expiration.
D.
Both peers have establish-tunnels immediately configured.
Explanation:
Reference: http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-esswcmdref/show-security-ipsec-security-associations.html
Could you explain why D is correct:
Can you tell it from the “3011/ unlim – 0”???
Example: with SRX on one side with establish-tunnels immediately configured:
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
268173313 ESP:aes-cbc-256/sha1 568211d3 3595/ 4608000 – root 500 7.7.7.3
0
0
source : AJSEC book part 2 chapter 9 page 42 . answer is right 🙂
the condition occurs when the lifetime of the phase two negotiation is close to expiration. When you have the establish-tunnel immediately configuration option applied, the junos OS will create a new phase two SA before the current SA expires. This behavior minimizes the impact of your SA expiration.
0
0
Thanks Juniper, I really couldn’t get why D as well was true.
0
0