Hi @wombocombo,
As far as I'm aware, the behavior of Any-Source Multicast in the SD-Access overlay remains unchanged and allows for multiple senders on the same group/channel regardless if you are using head-end or native replication. I tested this in the past, and from what I remember it worked without any issues.
This is my understanding of the behavior:
The SSM behavior in the underlay changes to accommodate ASM in the overlay as the sender(s) and their location are not initially known. The LHR builds shared trees for both ASM in the overlay and SSM in the underlay rooted at the RP and then builds shortest path trees towards the source(s) once multicast traffic has been received and the location of senders are known in the network.
As an example - if a receiver sends a join for group 239.50.50.50, (*, 239.50.50.50) is created on the LHR in the overlay multicast routing table and (10.1.1.1, 232.0.0.42) is created in the underlay multicast routing table with 10.1.1.1 representing RP-RLOC and 232.0.0.42 representing the derived SSM group for overlay group 239.50.50.50. Shared trees for both the overlay and underlay are built and rooted at the RP.
When the multicast source(s) start sending traffic to 239.50.50.50 in the overlay, the FRHs send a multicast register towards the RP. The multicast data that is encapsulated in the register messages are forwarded from the RP down to the receiver using the underlay tree that was built above. Once the above is complete, shortest path trees are built in both the overlay and underlay towards the source and SPT cutover occurs.
Imagine that you had two senders to group 239.50.50.50 that are connected to two different fabric edge switches:
Sender 1
Overlay IP address: 10.111.111.11
Fabric Edge RLOC: 172.16.1.1
Sender 2
Overlay IP address: 10.111.111.12
Fabric Edge RLOC: 172.16.1.2
The following multicast routing entries will be created on the LHR after the receiver sends the IGMP join for 239.50.50.50
Overlay: (*, 239.50.50.50)
Underlay: (10.1.1.1, 232.0.0.42) -> Shortest Path Tree built towards the RP
After the multicast traffic is received by the LHR (which is forwarded down from the RP in the underlay), the LHR has enough information to build shortest path trees towards the sources.
Sender 1
Overlay: (10.111.111.11, 239.50.50.50)
Underlay: (172.16.1.1, 232.0.0.42)
Sender 2
Overlay: (10.111.111.12, 239.50.50.50)
Underlay: (172.16.1.2, 232.0.0.42)
If the both senders were connected to the same fabric edge, then they will both use the same SSM tree
Sender 1
Overlay: (10.111.111.11, 239.50.50.50)
Underlay: (172.16.1.1, 232.0.0.42)
Sender 2
Overlay: (10.111.111.12, 239.50.50.50)
Underlay: (172.16.1.1, 232.0.0.42)
These are some good documents that describe the process in more detail. I cant find any SDA documents that caveat the use of multiple senders to the same group/channel so I assume that this is supported and remains unchanged in the SDA fabric.
https://community.cisco.com/t5/networking-knowledge-base/cisco-sd-access-multicast/ta-p/4068110
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKCRS-3810.pdf
Hope that this helps.
Will
