How to get multicast working?

[echo]

I'd like to get multicast working: first as a test to understand the topic; that is, between two networks that are connected to the same Fortigate and later over an Ipsec tunnel. I have read all kinds of information, I have configured something but I can't get anything working. I could write huge amount of information of what I have done but... maybe later.

I think our working solution that works within one VLAN at the moment uses IGMPv2 because the receiver has only multicast address configured and not (in addition) the unicast source to ask the information from (this is probably called SSM and it is used with IGMPv3 as I understand). So I see tha RP has to be configured for this to work between different networks.

I read a suggestion that RP has to be UP always so it is advisable to use a loopback address. So I made one having IP-address 192.168.255.9/29.

Debug showed me this:

id=20301 logdesc="Routing log" msg="PIM-SM: Nexthop for 192.168.255.9 unreachable"

Also "get router info multicast pim sparse-mode next-hop" gave me these entries among other entries:

0.0.0.0         N..U  0         0.0.0.0         -1               0      0     0 192.168.255.9   N..U  0         0.0.0.0         -1               0      0     0 Here U means unreachable.

And of course I have this configuration among other:

    config pim-sm-global         config rp-address             edit 1                 set ip-address 192.168.255.9             next         end     end

What is needed to make 192.168.255.9 reachable? Reachable to what? Both the receiver and sender? I already tried with non-multicast policies to make this connection but there is 0 traffic on those policies. I also have multicast policies in place: from 192.168.255.9 to multicast-addresses and from receiver to multicast-addresses and also from the multicast sender network to multicast-addresses.

Any help is appreciated! It has turned out to be much more difficult to get even the most basic multicast working! And even more, the unicast address that is part of captured multicast packets shows 192.168.1.1 as source which is actually in use in this VDOM already -- does this have to be globally routable within the same VDOM where I want to get the multicast packets traversing from one network to another? That IP does not even exist actually since it is rather "virtual" and unreachable directly because it is behind a modem and the current receiver and that modem are in the same network/VLAN, that's how it works. The modem has no place where 192.168.1.1 is configured, it is rather coming from another end behind special cabling.

Could comebody give a suggestion about this RP problem?

[Benoit_Rech_FTNT]

Hello "Echo",

RP should be reachable by both sender and receveivers, through ICMP + PIM. This means you need a firewall policy to reach from the ingress interface up to your loopback.

best regards, Benoit

[echo]

Hello!

I have these policies in place with 0 traffic on them...

I can debug the receiver part later because that one has unicast address at least. That is, pinging and then whatever PIM is.

But sender? Which one? The virtual 192.168.1.1? It is not defined in that VLAN at all, it only appears in the packet capture.

[echo]

Now I checked the firewall policies again.

Yes, they are both ways existing but as I mentioned, the problem is the real unicast source address somewhere. Since this not under our control, I can't do anything about this address other than a big change to get rid of that 192.168.1.0/24 network which is in use or make another VDOM just because of that one IP-address cross-usage.

Still I don't understand why I have this output of "get router info multicast pim sparse-mode next-hop":

0.0.0.0         N..U  0         0.0.0.0         -1               0      0     0 192.168.255.9   N..U  0         0.0.0.0         -1               0      0     0

Who says 192.168.255.9 is unreachable? There is no source in this table so it can't be related to 192.168.1.1. Regarding this address, this one single source can be unreachable, but what if there are other mcast sources (even though I don't have any) that are present? This 192.168.255.9 is reachable to Fortigate. What should be in this table with a working RP address? Should there be anything different than 0.0.0.0? I have no idea what's the problem here and how to make 192.168.255.9 as "reachable".

I tried "diagnose debug flow filter addr 192.168.255.9" but there is silence, I waited for a while. I only got something to appear there when I pinged this address. So nothing is even trying to connect this.

Another thing that I don't understand. Since the real source 192.168.1.1 has to be routable then how real that IP-address has to be? Because even if I can get rid of 192.168.1.0/24 in our environment, I have to route this network into a different IP-address that has no connection with 192.168.1.0/24 nor 192.168.1.1. Does that make any sense at all? The problem is that I configured 192.168.1.x in a small network to check if 192.168.1.1 behaves like an additional IP-address in this network but after pinging it, it didn't appear to ARP cache. So do I really have to route a network or just a single IP-address while it doesn't really exist in this network on L2 but only appears in multicast packets as a random parameter (random from my point of view)? I only have to be sure that it really is somewhere out there?

[echo]

I got another server for testing. So I leave that possibly problematic 192.168.1.1 aside for a while.

I started Singlewire's Multicast tester software in this testserver as server and in another server where I tested earlier as client. It uses 239.0.1.2:20480. I added firewall policies for the network where the new testserver is located at and added multicast sparse-mode configuration too. Doesn't work.

Then I removed the loopback address as static RP and made all the other interfaces as candidates with different priorities but again nothing changed. Maybe that step would require more firewall policies too?

But anyway, then I put back the static RP 192.168.255.9.

Then I realised that I haven't added sparse-mode configuration for that loopback interface. I added it and it is now in the list of other sparse-mode-activated interfaces but again that didn't help. The output of "get router info multicast pim sparse-mode next-hop" shows 192.168.255.9 still with U-tag. What is it that can't reach this, I don't understand.

Output excerpt of running test-software:

Server 10.0.57.18:

Singlewire Software Packet 4349 239.0.1.2:20480  TTL: 16 Singlewire Software Packet 4350 239.0.1.2:20480  TTL: 16 Singlewire Software Packet 4351 239.0.1.2:20480  TTL: 16 Singlewire Software Packet 4352 239.0.1.2:20480  TTL: 16

Client 10.12.1.131:

Listen Singlewire Software : 239.0.1.2:20480: no multicast traffic 3509 Listen Singlewire Software : 239.0.1.2:20480: no multicast traffic 3510 Listen Singlewire Software : 239.0.1.2:20480: no multicast traffic 3511 Listen Singlewire Software : 239.0.1.2:20480: no multicast traffic 3512

diag sniff packet any 'host 239.0.1.2' 4 0 a interfaces=[any] filters=[host 239.0.1.2] 2021-07-07 08:05:10.520891 LAG-2.157 in 10.0.57.18.62714 -> 239.0.1.2.20480: udp 31 2021-07-07 08:05:11.522711 LAG-2.157 in 10.0.57.18.62714 -> 239.0.1.2.20480: udp 31 2021-07-07 08:05:12.534657 LAG-2.157 in 10.0.57.18.62714 -> 239.0.1.2.20480: udp 31

Strangely enough,

diag ip router pim-sm level info diag ip router pim-sm all enable diag debug enable

shows no 239.0.1.2-related information but only 192.168.1.1-related logs with multicast addresses related to this source.

It looks like I have to open a ticket because so far it's been banging my head on the wall with no success.

[echo]

Little progress so far: the test environment uses Windows servers and it turned out the Windows firewall blocked incoming multicast in the server where the client was.

So the testing software gets the packets from another server in another network. Interesting but the OK logs for receiving multicast appeared after about 50-60 seconds when the same amount of packets were sent by the server.

Now I want to expand this to real life situation and the next router in line is almost silent, no PIM registrations etc. I only see neighbours and that probably only because I activated multicast in sparse mode on those interfaces. So I'm trying to understand that situation.

[echo]

I could finally get multicast working from over ipsec tunnel (don't know yet if there could be any MTU issue though) and now the old problem with 192.168.1.1 reappeared. For this, I made a dangerous route so the same IP is used for both purposes and the routes have different distance in the routing monitor table.

Does anybody know what is the meaning of multicast source nat in the multicast policy?

I thought if I use it then it will change the source unicast IP in the multicast packets but it doesn't.

Because when I used source nat in multicast policy, I found that some packets really started coming from that snat-IP because I saw the new IP in packet sniffer and also "get router info multicast pim sparse-mode table" and "get router info multicast pim sparse-mode next-hop" showed this new IP.

But as soon as I disabled the unicast route to the original multicast source IP 192.168.1.1 ("behind the nat"), the multicast traffic stopped coming. Which means it is still somehow in the packets and the source nat does not replace it. Fortigate's documentation only says "When the packets leave the external interface, their source address is translated to ..." but in my experience this does not work like that. If it were like that the traffic would continue to arrive even after disabling the route to original source 192.168.1.1.

I hope there is some way to change that unicast IP in multicast packets too because I don't really like the situation where 192.168.1.0/24 is routed in one place and 192.168.1.1 which is the default gateway for that network is routed to another place. Has anybody dealt with this before? I try to avoid making a separate VDOM because that would make the whole configuration in our environment so much more complex.

[echo]

Just a final note about this: so far it looks like its working. For the double 192.168.1.1 I had to do separate VDOMs, there just was no other way (our FortiOS is too old to support VRF, maybe that could have helped to avoid VDOMs, not sure). The RP is still shown as unreachable in the next-hop list. I see no traffic counter for the non-multicast traffic to reach the RP in the source router... So there are unclear parts here but it seems to be working (and without GRE in the IPSEC tunnel).