组播优化、multicast_query_use_ifaddr、accept

shixudong@163.com

疫情期间，对树莓派的组播功能进行了一些优化，优化过程中碰到了一些问题，通过网上搜索资料，这些问题均通过Linux的相关参数调整得到了妥善解决，原本一些模糊的概念也得以厘清，特此记录，以免遗忘。

一、Bridge multicast_to_unicast与hostapd multicast_to_unicast参数的区别。

无线组播具有先天缺陷，常规优化方法就是启用multicast_to_unicast功能，Bridge和hostapd都有multicast_to_unicast参数，然而他们之间究竟有什么区别呢？

根据man bridge资料，结合源码分析和实际验证，要启用bridge的multicast_to_unicast功能（默认关闭），必须先启用multicast_snooping功能（默认启用）并且网络上要存在igmp querier定期维护组播转发信息，所以如家庭网络上不存在igmp querier的话，还需启用multicast_querier功能（默认关闭），才能使bridge的multicast_to_unicast功能生效。

Bridge的multicast_to_unicast功能不仅对eth和wlan之间的组播有效，对不同eth之间的组播依然有效，然而对于同一AP下station之间的组播则无效。虽然station之间相互通信仍然必须通过AP，但这些通信全部在无线网卡驱动层处理，其行为更像Hub而非Switch，压根到不了bridge层面。为使station之间组播也能受益于bridge的multicast_to_unicast功能，需要额外再启用两个参数，首先启用hostapd的ap_isolate功能，使得station之间通信交由bridge处理；其次启用bridge下wlan端口的hairpin_mode功能，使得从同一wlan口进来的组播包经过multicast_snooping处理后允许原路返回。

综上，Bridge的multicast_to_unicast功能在bridge发送环节实现，通用性强，适用于所有无线网卡和有线网卡。不足是由于bridge的内在机制（RFC规范要求），multicast_to_unicast对224.0.0.X多播网段不起作用。此外station之间的multicast_to_unicast功能还取决于bridge是否采用SoftMAC无线网卡，大部分FullMAC无线网卡还没有实现ap_isolate功能。

Hostapd的multicast_to_unicast功能，在无线网卡发送环节实现，其优势在于不依赖bridge，无需配置multicast_snooping，可作用于任何多播网段；ap_isolate=0时，station之间通信也能实现multicast_to_unicast功能。其不足仍然是大部分FullMAC无线网卡还没有实现multicast_to_unicast功能。

Hostapd和Bridge配套使用时，两者的multicast_to_unicast功能可以同时启用，按照网络层对包发送的处理顺序，Bridge的multicast_to_unicast先发挥作用，漏网的组播包，由hostapd的multicast_to_unicast再次处理，理论上可实现multicast_to_unicast的全覆盖。然而对于FullMAC无线网卡来说，依然美中不足，譬如树莓派4的板载无线网卡既不支持multicast_to_unicast，也不支持ap_isolate，所以树莓派4用作无线AP时，其下连station之间组播要想充分受益于multicast_to_unicast功能，只能通过外置无线网卡实现（外置无线网卡采用SoftMAC驱动，使用mac80211框架，multicast_to_unicast和ap_isolate在mac80211实现，不依赖SoftMAC驱动）。

二、Bridge isolated与hostapd ap_isolate参数的区别

根据源码分析，前者隔离bridge物理端口之间的通信（必须进出端口都启用方生效），后者隔离AP station之间的通信。Hostapd不启用ap_isolate时，station之间的通信不经过桥，此时bridge isolated对station之间通信起不到隔离作用。

Hostapd启用ap_isolate后，station之间无法通信，此时启用bridge下wlan端口的hairpin_mode功能，station之间通信就可通过桥转发得以恢复，如再启用bridge下wlan端口的isolated功能，便再次隔离station之间通过桥转发的通信（虽然进出都是同一个wlan口，但仍然符合进出端口都启用isolated这一约束）。

当Hostapd参数ap_isolate=1主要用于控制引导station之间通信经由桥处理时，不宜再通过改变ap_isolate参数来控制station之间通信隔离与否，此时可联合使用bridge无线端口的isolated和hairpin_mode参数实现控制：（1）isolated=1，始终开启AP隔离；isolated=0，通过hairpin_mode控制AP隔离开启与否。（2）hairpin_mode=0，始终开启AP隔离；hairpin_mode=1，再通过isolated控制AP隔离开启与否。就源码分析来看，在上述场景下，isolated=1（开启隔离）和hairpin_mode=0（不允许同一端口之间转发，相当于开启隔离）所起的作用是完全等效的。

三、multicast_querier的源IP问题

如上文所述，要使bridge的multicast_to_unicast功能生效，网络上必须存在igmp querier定期维护组播转发信息。家庭网络可启用linux bridge自带的multicast_querier，定期发送igmp查询报文，默认使用0.0.0.0作为查询报文的源IP。根据资料，源IP为0.0.0.0的igmp querier不参与querier选举，为此可启用multicast_query_use_ifaddr参数使用桥IP作为查询报文的源IP。

在树莓派上启用multicast_querier后，一切运作正常。但一旦开启multicast_query_use_ifaddr功能，其他设备就无法找到树莓派本身提供的MiniDLNA服务（239.255.255.250）或其他multicast接收端服务（非224.0.0.X网段，对于224.0.0.X网段，Bridge不做任何限制）。在其他设备上抓包分析，开启multicast_query_use_ifaddr前后igmp查询报文唯一的区别就是源IP不同。设法在树莓派上运行igmp querier专用软件（采用桥IP作为查询报文的源IP），其他设备能正常找到树莓派的MiniDLNA服务，此时在其他设备抓包，专用软件发出的查询报文包和启用multicast_query_use_ifaddr后树莓派bridge的multicast_querier发出的包格式完全一致，都采用树莓派的桥IP作为源IP。

经在树莓派bridge上抓包，分析树莓派开启multicast_query_use_ifaddr前后的区别，开启前能收到本机发出的igmp report包，而开启后则无法收到本机发出的igmp report包，后者估计是树莓派没有收到自身bridge发出的查询报文包，从而无法发出后续igmp report包。结合源码分析和实际验证，可启用accept_local参数，允许从非loopback网卡进来数据包的源IP可以是本机IP，树莓派就能收到自身bridge发出的查询报文包，并向bridge的multicast_querier发回igmp report包，报告MiniDLNA服务所加入的多播地址，此时其他设备就能正常找到树莓派的MiniDLNA服务。

四、Linux本机组播包自发自收问题

鉴于从其他设备看到树莓派上igmp querier专用软件和bridge的multicast_querier（启用multicast_query_use_ifaddr后）发出的igmp查询报文完全一致，但树莓派本机只能收到前者报文，收不到后者报文（启用accept_local参数后可正常接收）。于是对这两者（都是组播包，理论上都能自发自收）进行了对比分析，意外发现，在本机接收multicast_querier发出的组播包时竟然能被iptables nat表的PREROUTING跟踪，而根据网上资料，接收自己发送的组播（含广播）和单播都不应被本机iptables nat表PREROUTING记录和跟踪。

经对源代码进行分析，通常三层软件发送组播包时，如启用IP_MULTICAST_LOOP选项（默认启用），将会发给自己一份（广播包无此选项，必须发给自己一份）。在三层发组播包给自己时，调用dev_loopback_xmit，在此函数中调用skb_dst_force强制设置路由后调用netif_rx发包，本机接收时，调用skb_valid_dst，发现路由有效，从而跳过了需要进行源IP验证的环节，所以压根无需启用accept_local参数便能收到组播包。而multicast_querier在二层发组播包给自己时，直接调用netif_rx发包，本机接收时，调用skb_valid_dst，发现路由无效，后续进入源IP验证环节，如不启用accept_local参数，就DROP掉源IP为本机IP的数据包。

在三层发组播包给自己时，因为是通过netif_rx发包，不涉及物理网卡，在调用dev_loopback_xmit前通过rt_dst_clone将发送设备修改为loopback_dev，而multicast_querier在二层发组播包给自己时，没有修改发送设备这一环节。本机接收时，nat表的conntrack机制判断如是从loopback_dev收到的包（包括单播），不做跟踪处理，所以正常情况下，igmp querier专用软件发给自己的组播包不被nat表的PREROUTING跟踪，而multicast_querier发给自己的组播包能被nat表的PREROUTING跟踪（如果只启用multicast_query_use_ifaddr而不启用accept_local，因为组播包后续无法通过源IP验证而被DROP，只能看到PREROUTING相关规则计数器增加，看不到实际的连接记录）。通过对raw和mangle表的PREROUTING链进行LOG，证明igmp querier专用软件发给自己的组播包确实经过这两个表的PREROUTING链，后续自然也会经过nat表的PREROUTING链，只是不进行连接跟踪而已。

五、Bridge的multicast_router

根据资料，Bridge物理端口上的multicast_router默认为1，表示该端口如持续收到igmp query包的话，该端口将成为临时router ports；如multicast_router设置为2，表示该端口将成为永久router ports。一旦物理端口成为router ports，该端口总是接收所有multicast traffic而不受multicast_snooping限制，使用bridge –s -d mdb命令可以查看物理端口是否为router ports。近期一系列测试过程中，发现不仅bridge物理端口有multicast_router参数，Bridge本身也有multicast_router参数，Bridge自己的multicast_router又在什么情况下起作用呢？

在前面igmp querier专用软件和bridge的multicast_querier（启用multicast_query_use_ifaddr后）发送igmp查询报文的对比测试中，已经得到结论，如后者不启用accept_local参数，就无法接收发给自己的igmp查询报文，导致收不到本机后续发出的igmp report包，其他设备就找不到树莓派本身提供的MiniDLNA服务。测试过程中，偶尔通过INPUT规则DROP掉前者发给自己的igmp查询报文，此时在bridge上抓包，确实发现也无法收到本机后续发出的igmp report包，但其他设备仍然能找到树莓派本身提供的MiniDLNA服务，根据前面的测试和推论，完全无法给出合理解释。

再次验证分析，通常情况下，Bridge对igmp查询报文的处理既可在bridge发出该报文时处理，也可在bridge接收该报文时处理。由第四部分分析可知，igmp querier专用软件发给自己的igmp查询报文调用netif_rx发包，因此发给自己的igmp查询报文无论是发送还是接收，都不经过bridge。但igmp querier专用软件发往外部的igmp查询报文从三层发出，需要经过bridge，此时会调用bridge的发送函数br_dev_xmit对igmp查询报文进行处理。简单来说，就是bridge持续收到上层发来的igmp查询报文，Bridge本身将成为临时router ports，与bridge物理端口不同的是，该临时router ports面向上层协议而不是外部设备，意味着本机能收到的multicast traffic将不受multicast_snooping限制，全部发往上层协议，因此虽然bridge收不到本机后续发出的igmp report，但丝毫不影响其他设备找到树莓派本身提供的MiniDLNA服务。

Bridge的multicast_querier（启用multicast_query_use_ifaddr后）的igmp查询报文从二层发出，无论是发给自己（调用netif_rx发包）还是发往外部，都无需经过br_dev_xmit处理（该函数仅面向上层提供发送服务），接收自己发送的查询报文也无需通过bridge收包，此时bridge的multicast_router（默认为1）因为收不到上层发出的igmp query包，永远不可能成为面向上层的临时router ports。

根据上述分析，为本文第三部分存在的问题提供了另外一种解决思路，即无需启用accept_local参数，直接将bridge的multicast_router设置为2即可。经测试，虽然此时bridge仍然收不到本机后续发出的igmp report，但也同样不影响其他设备顺利找到树莓派本身提供的MiniDLNA服务。

值得一提的是，无论bridge本身成为临时router ports，还是将bridge自己的multicast_router设置为2，都无法通过bridge –s -d mdb命令验证这一事实。

六、后记

本文是一篇事后补记的流水账，断断续续花了三个晚上，而流水账记录的整个优化、分析、验证与测试过程，则断断续续花了近半个月的时间，通过流水账梳理，再一次强化了关于组播的基本概念，特此记录，以备今后随时查询，如能有益于他人，善莫大焉。

组播优化、multicast_query_use_ifaddr、accept_local及其他相关推荐

城域网未知组播分析和优化
1 引言电信城域网目前综合承载宽带,IPTV,语音业务.随着网络规模的增大,网络内未知组播报文的数量随之增多,达到一定程度后,就会对网络带宽,设备负载产生压力,进而影响业务质量.研究未知组播的成因, ...
技术方案——可控组播
--IPTV业务的承载风帆一. 前言进几年来,随着网络带宽和接入用户的迅猛增加,宽带业务运营商已经将关注的焦点逐渐由提高宽带用户数向提高户均营收(ARPU)值的目标转移.IPTV业务作为消除宽带用 ...
07-IP组播配置指导
1 组播概述 1.1 组播简介作为一种与单播(Unicast)和广播(Broadcast)并列的通信方式,组播(Multicast)技术能够有效地解决单点发送.多点接收的问题,从而实现了网络中点到 ...
组播应用场景_推介4K IP切换系统在5G媒体集成制作中的应用
作者:中央电视台汪波近年来,随着计算机技术.移动通信技术.广电技术的不断发展,我们迎来了5G和4K超高清时代.2019年3月1日,工信部.国家广播电视总局.中央广播电视总台印发<超高清视频产 ...
加入rtp组播_耗时10+小时撰写带你系统认识组播收藏这些概念
组播multicast:在一个或跨越多个广播域,实现点对多点的通信需求,不存在强制性:比单播技术更加灵活.比广播技术更加高效:广泛应用在网络电视.在线直播.远程教育.视频会议等对带宽和数据交互实时性较 ...
tcp 组播_深入了解TCP/IP协议
TCP/IP协议网络上类似的科普知识很多,博主针对一些资料做了下整理,加入了自己的一些理解和观点.主要还是针对新人教程,结构比较清晰,有一定学习价值. 下面进入主题,我们知道现在互联网协议是经过分层的 ...
HCIE-RS 论述题组播
题目需求 1.端口1.2.3需要运行哪些协议?为什么需要运行这些协议,请写出具体原因 2 在大型网络中,RP是很重要的,所以必须提高RP的可靠性,降低RP的负担,请说出具体可行的方法,并解释原因一. ...
UDP 实现多收多发，广播发送，组播发送 TCP 实现多收多发
文章目录 TCP 实现多收多发(上线下线提醒) UDP多收多发 UDP广播发送接收 UDP 组播发送接收 TCP 实现多收多发(上线下线提醒) 创建发送端 public static void mai ...
WIFI6：WLAN 组播转单播原理与测试
1.wlan 组播面临的问题许多视频应用给接收设备传输数字信息都需要使用IP组播,由于组播流量的传递并不可靠,而在无线网络中,广播/组播报文会使用最低速率发送广播报文,所以当广播报文比较多时,会相对 ...

组播优化、multicast_query_use_ifaddr、accept_local及其他

组播优化、multicast_query_use_ifaddr、accept_local及其他相关推荐

最新文章

热门文章