For all protected SRRP instances, the protected node should be the preferred SRRP master. To achieve this, the SRRP priority should be higher in the protected node than in the protecting node. SRRP preemption is recommended in the protecting node to force it to be in the SRRP master state when possible.
ARP hosts configuration is strongly discouraged in protected group interfaces, unless the operator is ready to tolerate an incomplete redundancy mechanism for these hosts.
SRRP tracking is strongly recommended to expedite the routing convergence upon an SRRP transition from non-master to master state in the protecting node.
It is recommended to have a 1:1 relationship between SRRP and subscriber subnets to have smooth routing advertisements based on SRRP state tracking.
The use of M-SAPs should be preferred over the use of static SAPs. Static SAPs are supported in the OMCR mode but they are consuming resources in the protecting node even when the underlying SRRP instance is in a non-master state.
It is recommended that the capture-sap configuration include the track-srrp statement (at least for the protecting node). With this configuration the CPM does not process trigger packets when the leases cannot be created because the SRRP is not in the master state. Configuring SRRP tracking at the capture-sap offloads the CPM from performing false authentication and MSAP creation attempts.
Load balancing between active (SRRP master state) and standby (SRRP non-master state) via export policies for SRRP must not be configured as the hosts are not instantiated in the protecting node when the corresponding SRRP state is non-master.
To minimize traffic impact in the event of node reboot, it is recommended to use hold-time down ip | ipv6 seconds command under the subscriber-interface and allow enough time for the MCS database to reconcile. This is particularly important in the protected node. If the SRRP transitions to the master state in the protected node before the database has been reconciled, the protecting node removes the leases (SRRP non-master state) which have not been synchronized. This would create partial outage.
To avoid SRRP collisions, lack of resources and partial subscriber host instantiation, the use of fate-sharing-groups is not recommended. If an SRRP instance can be served by the protected node, it is preferred to keep it in the SRRP master state in there, instead of switching it to the protecting node as part of the operation-group.