FreeBSD as multicast router
Victor Gamov
vit at otcnet.ru
Fri Nov 8 12:08:38 UTC 2019
On 08/11/2019 10:30, Mike Karels wrote:
>> On 06/11/2019 05:41, Mike Karels wrote:
>>>> On 05/11/2019 09:09, Mike Karels wrote:
>>>>>> On 03/11/2019 08:22, Mike Karels wrote:
>>>>>>>>>>> Hi All
>>>>>>>>>>>
>>>>>>>>>>> I have (noob) questions about multicast routing under FreeBSD.
>>>>>>>>>>>
>>>>>>>>>>> I have FreeBSD box with two (or more) multicast enabled interfaces (e.x.
>>>>>>>>>>> vlan750 and vlan299). vlan750 connected to multicast source.
>>>>>>>>>>>
>>>>>>>>>>> Then pimd installed and only this two interfaces enabled in pimd config.
>>>>>>>>>>> Multicast routes successfully installed by pimd and listed by `netstat
>>>>>>>>>>> -g -f inet`
>>>>>>>>>>>
>>>>>>>>>>> Then client on vlan299 send IGMP-Join (this Join received by FreeBSD on
>>>>>>>>>>> vlan299)
>>>>>>>>>>>
>>>>>>>>>>> The question is: who will forward muilticast from one interface
>>>>>>>>>>> (vlan750) to another (vlan299)? Is it kernel specific job or I need
>>>>>>>>>>> additional software?
>>>>>>>>>
>>>>>>>>>> Please read the manpage multicast(4) "man 4 multicast",
>>>>>>>>>> you should need to build a custom kernel with the "options MROUTING"
>>>>>>>>>> to enable the multicast forwarding in the kernel.
>>>>>>>>>
>>>>>>>>> If "netstat -g" shows routes, the kernel must have been built with "options
>>>>>>>>> MROUTING".
>>>>>>>
>>>>>>>> Indeed.
>>>>>>>
>>>>>>>>>
>>>>>>>>> The kernel does the forwarding, according to those routing tables installed
>>>>>>>>> by pimd or another multicast routing program. Is it not working? It sounds
>>>>>>>>> like you are very close.
>>>>>>>
>>>>>>>> Could it be sysctl net.inet.ip.forwarding? Does that still apply to mroutes?
>>>>>>>
>>>>>>> No, they are separate. The test is just whether MROUTING is enabled, and
>>>>>>> whether a multicast router like pimd is active.
>>>>>>>
>>>>>>> One other thing to check would be "netstat -gs" (multicast stats).
>>>>>
>>>>>> Oops!
>>>>>
>>>>>> =====
>>>>>> # netstat -f inet -gs
>>>>>> No IPv4 MROUTING kernel support.
>>>>>> =====
>>>>>
>>>>> This looks like a bug in netstat; it is doing a test that is wrong for
>>>>> the loadable module.
>>>
>>> I don't know how much the stats might help, but if you let me know what
>>> version you are running, I can build a fixed netstat. Or I can send
>>> a source patch.
>>>
>>>>>> But I have ip_mroute.ko loaded and netstat -g shows something like
>>>>>
>>>>>> =====
>>>>>> # netstat -f inet -g
>>>>>
>>>>>> IPv4 Virtual Interface Table
>>>>>> Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
>>>>>> 0 1 A.A.A.A 0 0
>>>>>> 1 1 B.B.B.19 0 0
>>>>>> 2 10 10.199.199.102 0 0
>>>>>> 3 15 10.200.200.6 77440 0
>>>>>> 4 1 A.A.A.A 0 77440
>>>>>
>>>>>> IPv4 Multicast Forwarding Table
>>>>>> Origin Group Packets In-Vif Out-Vifs:Ttls
>>>>>> 10.200.200.5 232.232.8.33 1844 3 4:1
>>>>>> 10.200.200.5 232.232.8.171 1843 3 4:1
>>>>>> 10.200.200.5 232.232.8.58 4609 3 4:1
>>>>>> 10.200.200.5 232.232.8.154 1844 3 4:1
>>>>>> 10.200.200.5 232.232.8.170 1844 3 4:1
>>>
>>> I missed this before. Looks like the last column should include 2:1 in
>>> each case if pimd saw the join. The multicasts are only being sent to
>>> Vif 4, the register-vif (see below); the Pkts-Out for it is the same
>>> as the input on 3. I'm not familiar enough with pimd to guess what is
>>> wrong.
>
>
>> I still have misunderstood here. Pimd installs multicast routes and
>> this routes displayed by `netstat -g`. So, the system knows interface
>> where multicast received. When Join received via interface 2 (vlan299)
>> who must resend multicast from input interface 3 (vlan750) to output
>> interface 2 (vlan299)? I guess it kernel-specific task and kernel must
>> resend multicast without any other helpers. Is it wrong?
>
> No, that is correct; the kernel should do the forwarding. But something
> is out of sync. The join messages you showed were from 10.199.199.101,
> which should be vif 2. But the forwarding table shows an origin of
> 10.200.200.5, and the Pkts-In is 77K on vif3. Is the source address
> incorrect, or is there some other confusion as to which network is
> which?
My network scheme is simplest:
---------- -------------------- -----------
| source |-vlan750-| FreeBSD PIM router |-vlan299-| client |
|200.5/29| |200.6/29 199.102/30| |199.101/30|
---------- -------------------- -----------
So, yes, Join comes from 199.101 and it on another subnet -- client
cann't ping source. But client can ping FreeBSD and FreeBSD can ping
source.
One more interesting thing: when pimd started and multicast routing
table populated with 'netstat -g' point of view then 'ifmcstat' shows
only following groups for vlan750:
=====
vlan750:
inet 10.200.200.6
igmpv3 rv 2 qi 12 qri 100 uri 3
group 224.0.0.22 mode exclude
mcast-macaddr 01:00:5e:00:00:16
group 224.0.0.2 mode exclude
mcast-macaddr 01:00:5e:00:00:02
group 224.0.0.13 mode exclude
mcast-macaddr 01:00:5e:00:00:0d
group 224.0.0.1 mode exclude
mcast-macaddr 01:00:5e:00:00:01
=====
and locally started programs cann't read multicast stream while
interface not directly specified like udp://vlan750@232.232.8.33:3333 or
static route to this group not installed like 'route add 232.232.8.33/32
-iface vlan750'
I think problem somewhere here (FreeBSD does not join to multicasts?).
P.S. I try to use smcroute but it started with following errors:
=====
SMCRoute version 2.1.0
Adding vlan750 to list of multicast routing interfaces
Map iface vlan750 => VIF 0 ifindex 13 flags 0x0000 TTL
threshold 20
Failed adding VIF for iface vlan750: Can't assign requested address
Adding vlan299 to list of multicast routing interfaces
Map iface vlan299 => VIF 1 ifindex 10 flags 0x0000 TTL
threshold 20
Failed adding VIF for iface vlan299: Can't assign requested address
=====
and no records reported by 'netstat -f inet -n -g'
--
CU,
Victor Gamov
More information about the freebsd-net
mailing list