The following information describes requirements to deploy SR OS IPsec features.
To avoid high CPU loads and some complex cases, the following are the requirements to configure IKEv2 lifetime:
The IKE_SA lifetime on one side should be approximately twice as large as the other side. The CHILD_SA lifetime on one side should be approximately two or three times larger than the other side.
With the previous rule, the lifetime of the side with smaller lifetime should not be too small:
IKE_SA: >= 86400 seconds
CHILD_SA: >= 3600 seconds
With first rule, on the side with the smaller lifetime, the IKE_SA lifetime should be at least three times larger than CHILD_SA lifetime.
The IKE protocol is the control plane of IPsec, therefore, the IKE packet should be treated as high QoS priority in the end-to-end path of the public service.
On a public interface, a SAP ingress QoS policy should be configured to ensure the IKE packet is treated as high QoS priority.
The correct system time is required for certificate authentication to work properly.
The peer’s DPD interval must be larger than 30 seconds and should not send a DPD request if it receives IKE or ESP traffic.
The following are requirements for MC-IPsec specific deployments:
The IKEv2 lifetime requirements from IPsec general should be applied with special care to MC-IPsec deployments.
In an MC-IPsec deployment where the MC-IPsec pair peers with single, non-redundant IKE clients, the IKEv2 lifetime requirements must be applied with the larger lifetimes configured on the MC-IPsec pair.
An MC-IPsec deployment where one MC-IPsec pair peers with another MC-IPsec pair is not recommended. MC-IPsec performs optimally when the multi-chassis pair peers with a single IKE entity. If such a peering (MC-to-MC) is created, the above IKEv2 lifetime requirements should still be followed. However, with one side nominated to be the primary rekey initiator and having the smaller configured lifetimes.
Responder-only configuration is a mandatory requirement for all types of tunnels on the MC-IPsec pair in the usual deployment scenario of a MC-IPsec pair peering with single, non-redundant IKE clients.
DPD on the peer side (following the DPD requirement in the above IPsec General section), dpd interval 300 max-retries 3 reply-only on the MC-IPsec side.
Dedicated, redundant, direct physical link between chassis with enough bandwidth for MCS and shunting traffic.
MIMP/MCS and BFD for MC-IPsec traffic must be forwarded over resilient links so that a single IOM/IMM, MDA or port failure does not cause the MIMP to go down. Because this control traffic is forwarded in the base routing instance, the base routing instance links need to spread over multiple ports on multiple IOM/IMMs. Proper QoS configuration is needed to make sure the control traffic gets the highest priority.
A MC-IPsec switchover when the protection status is not nominal may result in unexpected behavior and traffic loss. A nominal state must be reached on both MC-IPsec chassis before a MC-IPsec switchover is triggered.
When using VRRP in the public service and a chassis failure occurs, the VRRP/Layer 2 network should re-converge before the MC-IPsec switchover occurs. One way to speed up VRRP switchover is to bind a BFD session to VRRP.
The system time of the master and standby chassis must be the same. One way to achieve this is for both chassis to sync to an NTP or SNTP server.
The CLI configuration is not synchronized via MCS so the user must provision the same IPsec-related configurations on the master and standby chassis. This includes using the same IKE policy ID, tunnel template ID, public or private interface name, and so on.
For an MC-IPsec shunting interface, only one next-hop address is supported; in case of multiple redundant next hops configured using the same shunting interface, the last next hop configured is used.