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.
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?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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,
Hello echo,
We are still looking for someone to help you.
We will come back to you ASAP.
Regards,
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,
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.
Hello echo,
Thank you for this explanation. I will try to find an expert to reply.
Regards,
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.
OK. I guess I won't make a ticket -- it's not an ongoing problem and multicast has not been interrupted after the upgrade.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.