<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic SDA Multicast TTL in Software-Defined Access (SD-Access)</title>
    <link>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/4260766#M1013</link>
    <description>&lt;DIV class="_2zOpJb7ZbCN0X1DoeFyiYw JWNdg1hee9_Rz6bIGvG1c allowTextSelection"&gt;
&lt;DIV&gt;
&lt;DIV class="rps_8426"&gt;
&lt;DIV dir="ltr"&gt;
&lt;DIV&gt;Hi community,&lt;/DIV&gt;
&lt;DIV&gt;does any one of you have confirmation/documentation of how TTL is decremented for multicast in the same VN in SDA?&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;The following slide-deck only covers unicast&lt;/DIV&gt;
&lt;DIV&gt;&lt;A href="https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-3810.pdf" target="_blank" rel="noopener noreferrer" data-auth="NotApplicable"&gt;https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-3810.pdf&lt;/A&gt;&amp;nbsp; page&amp;nbsp; 97 ff&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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 &amp;amp; receiver are in the same VN (basically mcast following L3 routed unicast approach).&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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.&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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) ?&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;Just turning off multicast and relying on BUM flooding is not an option as IGMP / MLD snooping is a requirement.&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;Thanks&lt;/DIV&gt;
&lt;DIV&gt;Manuel&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;</description>
    <pubDate>Fri, 18 Dec 2020 14:20:22 GMT</pubDate>
    <dc:creator>manuwidmer</dc:creator>
    <dc:date>2020-12-18T14:20:22Z</dc:date>
    <item>
      <title>SDA Multicast TTL</title>
      <link>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/4260766#M1013</link>
      <description>&lt;DIV class="_2zOpJb7ZbCN0X1DoeFyiYw JWNdg1hee9_Rz6bIGvG1c allowTextSelection"&gt;
&lt;DIV&gt;
&lt;DIV class="rps_8426"&gt;
&lt;DIV dir="ltr"&gt;
&lt;DIV&gt;Hi community,&lt;/DIV&gt;
&lt;DIV&gt;does any one of you have confirmation/documentation of how TTL is decremented for multicast in the same VN in SDA?&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;The following slide-deck only covers unicast&lt;/DIV&gt;
&lt;DIV&gt;&lt;A href="https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-3810.pdf" target="_blank" rel="noopener noreferrer" data-auth="NotApplicable"&gt;https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCRS-3810.pdf&lt;/A&gt;&amp;nbsp; page&amp;nbsp; 97 ff&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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 &amp;amp; receiver are in the same VN (basically mcast following L3 routed unicast approach).&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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.&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;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) ?&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;Just turning off multicast and relying on BUM flooding is not an option as IGMP / MLD snooping is a requirement.&lt;/DIV&gt;
&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;
&lt;DIV&gt;Thanks&lt;/DIV&gt;
&lt;DIV&gt;Manuel&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;
&lt;/DIV&gt;</description>
      <pubDate>Fri, 18 Dec 2020 14:20:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/4260766#M1013</guid>
      <dc:creator>manuwidmer</dc:creator>
      <dc:date>2020-12-18T14:20:22Z</dc:date>
    </item>
    <item>
      <title>Re: SDA Multicast TTL</title>
      <link>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/4269036#M1050</link>
      <description>&lt;P&gt;Answering my own question:&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Jan 2021 14:24:06 GMT</pubDate>
      <guid>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/4269036#M1050</guid>
      <dc:creator>manuwidmer</dc:creator>
      <dc:date>2021-01-12T14:24:06Z</dc:date>
    </item>
    <item>
      <title>Re: SDA Multicast TTL</title>
      <link>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/5014975#M3007</link>
      <description>&lt;P&gt;Hello, I have a similar problem too. The application is PTPv1 that use TTL=1.&amp;nbsp; Has Cisco deployed any enhancement to address this issue? Thanks&lt;/P&gt;</description>
      <pubDate>Thu, 08 Feb 2024 15:11:35 GMT</pubDate>
      <guid>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/5014975#M3007</guid>
      <dc:creator>Stefano7K</dc:creator>
      <dc:date>2024-02-08T15:11:35Z</dc:date>
    </item>
    <item>
      <title>Re: SDA Multicast TTL</title>
      <link>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/5015059#M3008</link>
      <description>&lt;P&gt;For PTPv1 and TTL=1 you need 17.6+ and L2 Flooding for it to work.Which requires underlay multicast.&lt;/P&gt;
&lt;P&gt;This was introduced in via &lt;A href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr13592" target="_blank"&gt;https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr13592&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;Regards&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 08 Feb 2024 16:54:28 GMT</pubDate>
      <guid>https://community.cisco.com/t5/software-defined-access-sd-access/sda-multicast-ttl/m-p/5015059#M3008</guid>
      <dc:creator>jalejand</dc:creator>
      <dc:date>2024-02-08T16:54:28Z</dc:date>
    </item>
  </channel>
</rss>

