Fate Sharing Group (FSG) is relaying on tracking the state of messaging SAPs over which SRRP instances run. An SRRP instance with the messaging SAP operationally DOWN transitions into the Init state.
The transitioning of any messaging SAP in a FSG into an UP/DOWN state triggers SRRP priority adjustment within the FSG. The SRRP priorities should be chosen carefully to achieve the wanted behavior. They are modified dynamically as the SAP states change. The range in which SRRP priorities can be modified is from 1 to the SRRP priority that is initially configured under the SRRP node. Here are some general guidelines for choosing SRRP priorities in a FSG:
Initially configured SRRP priorities for all SRRP instance within the FSG within the node should be the same.
Initially configured SRRP priorities should be different between pairing FSGs. For example, SRRP instances in the BNG node A within an FSG all have the same SRRP priority ‛X’, while corresponding SRRP instances on the paired node within corresponding FSG all have SRRP priority ‛Y’. This ensures that the SRRP master state is clearly defined between the two BNG nodes. This step is not mandatory as SRRP naturally breaks the master state election tie in the case that all SRRP priorities are the same. However, following this step may provide a clearer view from an operational perspective.
The priority-step parameter used for dynamic SRRP priority adjustment must be greater than the difference in initially configured SRRP priorities between two BNG nodes. This ensures that a single failure event triggers the SRRP switchover. Otherwise, if the dynamically lowered SRRP priority is still greater than the one from the SRRP peer, the switchover would not be triggered. Therefore, the fate sharing concept would not function as intended.
Initially configured SRRP priority of each SRRP instance should be greater than the (anticipated) number of SRRP instances in a FSG multiplied by the SRRP priority-step. This ensures that the dynamically priority never tries to go below 1. There is a code check that prevents SRRP priority going below 1. Nonetheless, it is recommended not to get into a situation where this needs to be enforced in the code.
The priorities can never be less than 1 or greater than initially configured SRRP priority.
Example scenarios:
Assume 3 SRRP instances in a FSG. The SRRP instances in the FSG-1 on BNG 1 have the priority of 100, while the SRRP instances in the FSG-2 on BNG 2 have the priority of 95. The priority-step is 6. The SRRP instances and underlying messaging SAPs are referred to as SRRP 1, 2, 3 and SAP 1,2,3, respectively.
Initialization:
Scenario 1 – all SAPs are operationally UP.
BNG 1 boots up and all messaging SAPs transition into the UP state. When the first SRRP instance in FSG-1 comes up, it looks under the FSG to finds out how many messaging SAPs are operationally UP. Because all messaging SAPs are operationally UP, this first SRRP instance assumes its initially configured priority of 100. The other two SRRP instances in the same FSG follows the same sequence of events.
BNG 2 follows the same flow of events. As a result, all SRRP instances within the corresponding FSG are in the SRRP master state on BNG 1.
Scenario 2 – messaging SAP 1 is operationally DOWN on BNG 1, the rest of the messaging SAPs are operationally UP.
SRRP 2 and 3, during the initialization, pick up SRRP priority of 94 (100 – 1*priority-step).
On BNG 2, all messaging SAPs are UP and consequently all SRRP instances within the FSG on BNG 2 have SRRP priority of 95. The SRRP instances are in the SRRP master state on BNG 2.
Scenario 3 – Continuing from scenario 2, the SAP 1 on BNG 1 transitions into the UP state. SRRP priority of each SRRP instance in FSG-1 is increased by 6, bringing it to 100, enough to assume Mastership.
Adding a New Instance into an FSG
To introduce minimal network disruption, first create messaging SAPs in both BNG nodes and ensure that both SAPs are operationally UP. Then a new SRRP 4 instance should be created on both BNG nodes. The next step would be to include this new messaging SAP into a SAP monitoring group. And finally, the SRRP-4 is added into the FSG (1 and 2). This triggers the recalculation of SRRP priorities for the existing FSG-1 and FSG-2. Because all SRRP priorities are at the maximum (initially configured priority), nothing changes.
There are more disruptive ways of adding an SRRP instance into a FSG. One such example would be in the case where SRRP priorities are not at their maximum (initially configured) priority. If an SRRP instance is first added into an FSG that is in a backup state, this would increase the FSG priority and potentially cause a switchover. If the SRRP instances is then added in a FSG on the peer BNG (previously SRRP master state), the priority of this FSG would be increased again and the switchover would unnecessarily occur for the second time. The new SRRP instances, when operational, should always be added in the FSG with SRRP master state first.
SRRP priority re-calculation within the FSG is triggered by the following events:
SRRP initialization
addition of a SAP under the monitoring group
messaging SAP failure
This priority calculation looks into how many SAPs are in the DOWN state within the monitored SAP group. Based on this number, the priority is calculated as follows:
SRRP priority = configured-priority – priority-step * num_down_SAPs.