In specific cases, subscriber traffic is terminated on the BNG by an Epipe. In this case, the subscriber traffic can be offloaded onto a plain Ethernet port by a VSM module (a ‛loop’) so that it can be terminated in ESM. Epipes can be configured in A/S configuration and terminated on two BNG nodes in multihomed environment.
In these multi-homed environment with Epipes and ‛loops’, the ESM itself detaches from the Epipe, which brings the subscriber traffic to the BNG. Because of that, the ESM would not know if the PW’s state is active or standby. As a result, in the downstream direction, traffic could end up being forwarded toward the standby PW, effectively being black-holed.
To overcome this, SRRP can be used in conjunction with an additional mechanism to help monitor the activity of the PWs. This monitoring mechanism is very similar to Fate-sharing. The difference in this case is that the messaging SAP (instead of SRRP instance) is monitoring the activity of the PW. As a result, the SRRP messaging SAP reflects the state of the PW. For example, the PW in a Standby mode would cause the messaging SAP to be in the DOWN state while the PW Active state would cause the messaging SAP to be in the UP state. That is, the SRRP instance reflects the operational state of the messaging SAP. SRRP is indirectly tied into PW state.
Modifying the priority of SRRP instance based on PW’s state as a mean of tying the SRRP master state to the active PW would not help here as SRRP messages are not flowing over standby PWs. This is why SRRP state must be enforced by the messaging SAP.
Fate-sharing for PW termination in conjunction with SRRP is not supported.
Metric adjustment for the subscriber routes is supported. After the tracked SRRP instance transitions into a non-master SRRP state, the state attribute of the route changes and the appropriate action defined in the routing policy is taken.