Has anybody upgraded from 6.4 to 7.0 while using multicast? I did it and encountered a problem with ASM multicast while SSM multicast continued working with no problems. I tried to find information from release notes (7.0.0-7.0.12) if there is a documented change in behaviour about it but I couldn't find any.
The environment is like this:
1. Two 1800F devices in A-P HA cluster.
2. ASM multicast source is behind IPSEC tunnel.
3. After upgrade 6.4.12 -> 7.0.12 ASM multicast didn't work anymore.
Solution: disable "Multicast Routing" configuration in Network/Multicast section in GUI and reenable it (the other configuration is back immediately, no need to reenter all of that).
The various debug commands from CLI gave me a hint what happened.
Multicast actually arrived from the IPSEC-tunnel, this I saw with "# diag sniffer packet <filter>" and with many other things. So I suspected something has happened to the server software.
"# get router info multicast table" was empty -- but it should not be empty when multicast is being actually forwarded to a server.
I noticed that the output of "# get router info multicast pim sparse-mode next-hop" was different from the output in the past: in the past there used to be the _internal_ IP-addresses of the IPSEC tunnel addresses on the other end (as for the multicast sources behind which there is the actual source). But now I saw there were the _external_ IP-addresses of the other end, the ones of the tunnel endpoint! It doesn't make much sense: the external IP-addresses of the IPSEC-tunnel are "invisible" to the traffic it carries. Besides, the external interfaces have not even been enabled multicast because they actually don't participate in multicast. So this output doesn't make much sense from the multicast perspective, but it makes sense from IPSEC perspective. But it was in the output of a multicast command, not IPSEC command. Is this somehow dependent on the NAT-traversal being enabled or not? During the debug I disabled it. Possibly not related.
Anyway, I suspect that this change plus the HA-cluster solution where the sessions were carried over, not restarted from the scratch, caused the outage.
Is this a bug, undocumented change or should I worry that there is still something wrong in the output of the next-hop table and I should get the internal IP-addresses back there?
I checked it but I didn't notice anything special (new) there. The only configuration from "config router multicast" that we use is setting the sparse-mode for interfaces and setting the static RP address. Plus, of course, enabling multicast routing. This configuration, just like anything else that is multicast-related and manually configured, is exactly the same in both the old and the new config file.
Just for information, the SSM multicast, that was OK, is not going over an IPSEC tunnel in our case.
Hi @echo , I did a quick check on the reported bugs, but couldn't find an exact match. This could be a design change but I would recommend you opening a TAC ticket with the output ""# get router info multicast pim sparse-mode next-hop" from the previous OS and current version for further investigation.
- Have you found a solution? Then give your helper a "Kudos" and mark the solution.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.