As per RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE), this has the implications on the operation of the capture SAP. In an IPoE environment, the initial DHCP traffic related to host establishment uses its native MAC of the physical port on the router. After the group interface is learned (later in the process, by RADIUS or msap-policy), the MAC address is switched to SRRP MAC address (virtual MAC). The IPoE client adapts easily to this change. On the contrary, for the correct operation of PPPoE with SRRP, the initial destination MAC address learned by the PPPoE client does not change during the lifetime of the session.
This is ensured by indirectly referencing the grp-if under the capture SAP:
config>service>vpls
sap 1/1/1:1.* capture-sap
track-srrp 10
sap 1/1/1:2.* capture-sap
track-srrp 20
config>service>vprn>
subscriber-interface <ip-int-name>
group-interface <ip-int-name>
sap 1/1/1:1.1
srrp 10
message-path 1/1/1:1.1
group-interface <ip-int-name>
sap 1/1/1:2.1
srrp 20
message-path 1/1/1:2.1
With this approach the grp-if is nailed during the session initiation phase by referencing the SRRP instance in track-srrp statement (SRRP is a group interface-wide concept). RADIUS returned grp-if name must match the one on which referenced SRRP instance runs.
The capture SAP of the form
sap port-id:*.* capture-sap
track-srrp X
assumes that there is only one grp-if associated with all MSAPs under this capture SAP.
A check is put in place to make sure that the MAC addresses associated with the SRRP instance is the same as the MAC address of the associated capture SAP. A log is raised if there is a discrepancy between the MAC addresses while the grp-if is operationally UP. If there is a MAC address change (user misconfiguration) then the existing PPPoE sessions time out and the new sessions fail to establish until the condition is corrected.