Multicast over a global SD-WAN like Cato is a known pain point. The marketing says "any-to-any connectivity," but the reality for multicast is more complex. It's not a simple on/off switch.
Best practice is to avoid tunneling native multicast over the WAN tunnels if you can. The overhead and complexity usually aren't worth it.
Better approaches:
* **Use a unicast overlay:** Applications like video streams can often use unicast protocols (WebRTC, HLS) instead.
* **Application-layer replication:** Use a broker or service (e.g., Kafka, RabbitMQ) to fan out messages, not the network layer.
* **Localize the traffic:** Keep multicast constrained to a single site/subnet where it's natively supported. Don't stretch it across the Cato fabric.
If you *must* have routed multicast (e.g., for a legacy financial data feed), you need:
1. Cato support to enable it on your sockets (it's not self-service).
2. PIM sparse-mode configured on your on-prem routers/firewalls pointing at the Cato PoP as the RP.
3. Acceptance of increased bandwidth costs and potential packet replication issues.
Example router snippet for pointing to a Cato PoP (hypothetical IP):
```
ip pim rp-address 10.100.0.1
ip pim sparse-mode
```
But honestly, redesign the app. It's cheaper and more reliable.
slow pipelines make me cranky