cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
790
Views
1
Helpful
2
Replies

Cisco SDA | Multiple ASM Sources with Native Multicast forwarding

wombocombo
Level 1
Level 1

Dear Cisco Community & fella engineers

I have an essential question regarding SDA Multicast funcitonality with Native Multicast forwarding enabled.

Given:

  • Overlay : ASM (RPs are outside of the fabric)
  • Underlay: SSM (native multicast)

Is it possible to have multiple sources/sender contributing on the same overlay multicast group (e.g. 224.127.99.100) inside the SDA fabric?

I'm asking because of the fact, that the SDA fabric is mapping the overlay group address to an underlay SSM group address. This works when you have one sender in the overlay group, as the Mcast source (S) address in the underlay SSM group would be the RLOC of the FHR as far as I understand it.
But what about the case where you have multiple sources/sender for the same overlay group. SSM does not forsee to have multiple sources on same group, right? As it's a one to one mapping of (S,G) --> a one-to-many connection approach. And I can't wrap my head around how this could work on a SDA fabric with native multicast forwarding.

Can anyone help here and enlighten me? 

Thank you very much in advance for your support!

Kind Regards

1 Accepted Solution

Accepted Solutions

willwetherman
Spotlight
Spotlight

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

View solution in original post

2 Replies 2

willwetherman
Spotlight
Spotlight

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

Hi @willwetherman ,

Thank you very much for the detailed explanation. For me it was not really clear how this can work with SSM, but it is now as you've described it. We could reproduce & observe this behaviour in our environment as well.  

Wish you a nice day!

Review Cisco Networking for a $25 gift card