Skip to main content
echo
echo
Explorer II
July 5, 2021
Question

How to get multicast working?

  • July 5, 2021
  • 1 reply
  • 11404 views

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?

1 reply

Benoit_Rech_FTNT
Staff
Benoit_Rech_FTNT
Staff
July 5, 2021

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
echoAuthor
Explorer II
July 5, 2021

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
echoAuthor
Explorer II
July 6, 2021

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?

Terms & ConditionsAccessibility statement