From owner-freebsd-net@freebsd.org Fri Nov 8 12:08:38 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06E2C1B071F for ; Fri, 8 Nov 2019 12:08:38 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 478fF06f0tz4Ghr for ; Fri, 8 Nov 2019 12:08:36 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from MacBook-Gamov.local (unknown [194.190.78.9]) by mail.otcnet.ru (Postfix) with ESMTPSA id C6665739B4; Fri, 8 Nov 2019 15:08:33 +0300 (MSK) Subject: Re: FreeBSD as multicast router To: freebsd-net@freebsd.org, mike@karels.net References: <201911080730.xA87UAel076108@mail.karels.net> From: Victor Gamov Organization: OstankinoTelecom Message-ID: Date: Fri, 8 Nov 2019 15:08:33 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <201911080730.xA87UAel076108@mail.karels.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 478fF06f0tz4Ghr X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of vit@otcnet.ru designates 194.190.78.3 as permitted sender) smtp.mailfrom=vit@otcnet.ru X-Spamd-Result: default: False [-5.47 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; SH_EMAIL_ZRD(0.00)[232.232.8.33]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[232.232.8.33]; R_SPF_ALLOW(-0.20)[+a:mail.otcnet.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[otcnet.ru]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-3.27)[ip: (-8.62), ipnet: 194.190.78.0/24(-4.31), asn: 50822(-3.45), country: RU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:50822, ipnet:194.190.78.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 12:08:38 -0000 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