Multicast change in FortiOS 7?
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.
- "# diagnose sys mcast-session list" showed sessions.
- "# 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?