From owner-freebsd-net@freebsd.org Thu Nov 7 14:18:01 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 B7C331B5BFB for ; Thu, 7 Nov 2019 14:18:01 +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 47858m3mrsz3Fgd for ; Thu, 7 Nov 2019 14:17:59 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from MacBook-Gamov.local (unknown [188.164.215.2]) by mail.otcnet.ru (Postfix) with ESMTPSA id 3E0CF7356C; Thu, 7 Nov 2019 17:17:53 +0300 (MSK) Subject: Re: FreeBSD as multicast router To: mike@karels.net Cc: freebsd-net@freebsd.org References: <201911060241.xA62fd40065707@mail.karels.net> From: Victor Gamov Organization: OstankinoTelecom Message-ID: <3334fa50-8a88-17b6-7e91-c09d22e11f7e@otcnet.ru> Date: Thu, 7 Nov 2019 17:17:48 +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: <201911060241.xA62fd40065707@mail.karels.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47858m3mrsz3Fgd 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)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; 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.61), ipnet: 194.190.78.0/24(-4.31), asn: 50822(-3.44), 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: Thu, 07 Nov 2019 14:18:01 -0000 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? P.S. I rebuild kernel with MROUTING option but ===== # netstat -gs -f inet No IPv4 MROUTING kernel support ===== still here -- CU, Victor Gamov