Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
echo
Contributor II

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?

7 REPLIES 7
Anthony_E
Community Manager
Community Manager

Hello echo,


Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.


Thanks,

Anthony-Fortinet Community Team.
Anthony_E
Community Manager
Community Manager

Hello echo,

 

We are still looking for someone to help you.

We will come back to you ASAP.


Regards,

Anthony-Fortinet Community Team.
Anthony_E
Community Manager
Community Manager

Hello echo,

 

Did you already have a look into this document:

 

https://docs.fortinet.com/document/fortigate/7.0.0/cli-reference/566620/config-router-multicast

 

Tell us if it is helping.

 

Regards,

Anthony-Fortinet Community Team.
echo

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.

Anthony_E
Community Manager
Community Manager

Hello echo,

 

Thank you for this explanation. I will try to find an expert to reply.

 

Regards,

Anthony-Fortinet Community Team.
srajeswaran
Staff
Staff

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.

Regards,

Suraj

- Have you found a solution? Then give your helper a "Kudos" and mark the solution.

echo

OK. I guess I won't make a ticket -- it's not an ongoing problem and multicast has not been interrupted after the upgrade.