SDA Multicast TTL

[manuwidmer]

Hi community,

does any one of you have confirmation/documentation of how TTL is decremented for multicast in the same VN in SDA?

The following slide-deck only covers unicast

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-3810.pdf  page  97 ff

Based on our observation, as soon as multicast / IGMP / MLD snooping is enabled for a VN, it seems that TTL is decremented for each hop in the fabric even when source & receiver are in the same VN (basically mcast following L3 routed unicast approach).

This is causing compatibility issues in our case, as we deal with specific appliances that rely on multicast in their VLAN and have hardcoded TTL of 2. When we want to migrate to SDA depending on size of the branch we will have more than 2 hops between then endpoints.

Is there a way to adapt the behavior such that, for receivers in the same VN as the source, TTL wouldn't get decremented (equivalent to VN-local unicast) ?

Just turning off multicast and relying on BUM flooding is not an option as IGMP / MLD snooping is a requirement.

Thanks

Manuel

[manuwidmer · Accepted solution]

Answering my own question:

Though in SDA we provide subnet across FEs and mobility between them, The multicast however works over L3 and not L2 even when source and receiver are in same subnet but attached to different FEs.

This requires every HOP to decrement TTL. There are applications which work within same subnet with TTL=1 which doesn't work in SDA. Today SDA has no solution to such problems. There is an ongoing enhancement request to address this issue.

[Stefano7K]

Hello, I have a similar problem too. The application is PTPv1 that use TTL=1.  Has Cisco deployed any enhancement to address this issue? Thanks

[jalejand]

For PTPv1 and TTL=1 you need 17.6+ and L2 Flooding for it to work.Which requires underlay multicast.

This was introduced in via https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr13592

Regards