Unifi全家桶高级组网方案

一、人设及背景
作者帝都IT民工,对技术抱有极高的兴趣。房子是三居,刚装修不久,性冷淡风格系。虽然作者是IT民工,但对于家装,把自己家里装得像个科技馆一样,这是不能接受的,所以,所有复杂的设计全部应该隐藏在背后,对外表现是简单的风格。
此文中的方案是作者对已实现场景的记录,全都是干货,但设计略为复杂,甚至粗略看,有些设计是“画蛇添足”,当然每一个看起来“画蛇添足”之处都有作者的用意,可能需要一定的基础知识作为背景。
另外,作为IT民工,每个人或多或少都有 “Python是世界上最好的语言”这种情节,作者意图不是试图改变某某固件粉丝的想法,所以也会自动忽略“一个K2P解决全部问题”之类评论。
二、总体设计
1.jpg
先不解释这个图,先简要提下这个设计实现的独特设计点:
1、速度更快的Internet接入方案,具体查看“Internet接入”部分。
2、速度更快的VPN访问方案,具体查看“公司VPN接入”部分。
3、无限扩展终端的IPTV方案,具体查看“IPTV接入”部分。
4、千兆级的QoS方案,具体查看“QoS”部分。

在这之前,先简单介绍一下这个图中的核心设备,从上往下:
MA5671
2.jpg
光猫。原来电信送的是SA1456C。用iperf测试,MA5671比SA1456C的桥接性能(交换机的性能)要好,MA5671的千兆网口基本能达到950M-1000M,而SA1456C只有600M左右,如果网口做了VLAN绑定,千兆网口桥接性能只有400M左右。
VLAN Switch
3.jpg
国产杂牌8口VLAN交换机,售价大概140元左右,他的作用是扩展路由器的WAN口,因为下面出场的UBNT USG只有两个WAN口,如果需要使用更多的WAN口就要在路由的WAN口上划分VLAN,然后再用VLAN交换机扩展路由的WAN口(2WAN扩展为6WAN)。对这个VLAN交换机的功能不要求太多,能对网口设置VLAN即可,国产VLAN交换机一般使用RTK芯片,性能还过得去,VLAN交换速度近1000M没问题。
UBNT USG
4.jpg
网关。主角之一,具体参数网上有很多介绍,这里就不贴了,这里选择他的原因主要是:
1、性价比不错,750元左右,具有百万小包转发率(1Mpps),普通路由器不到100Kpps。
2、Unifi全家桶核心成员,统一管理设备和客户端。
当然,这个路由器的缺点也很明显:
1、CPU性能低,500Mhz,只有开启了Hardware NAT(UBNT称之为offload)才能到1Mpps转发率,如果靠CPU转发,性能连100块的路由都比不上。所以,想在USG上跑个第三方软件,尝试一下就行了。
2、QoS功能和Hardware NAT冲突,如果启动QoS,那就得靠CPU转发数据包了,性能参见第一条。
所以,本方案既然使用了USG,那就得针对这两缺点,通过额外的设计方案来补充,才能形成一个整体方案。

X86-J1900
5.jpg
隐藏的第二网关,他的出现是因为USG的CPU性能太低,所以一些需要CPU完成的任务就通过X86-J1900来完成,X86-J1900价格大约在700-800元左右,整机功耗约10W。设个方案使用X86-J1900是因为在X86架构在计算,尤其加密解密等运算方面,和ARM/MIPS架构对比,简直就是秒杀。用数据表达就是, aes256-gcm、chacha20-ietf-poly1305等加密算法,高端的ARM路由(价格大于2000元),大约能跑到50-60M/s的吞吐量,而X86-J1900轻松200M/s以上(USG的MIPS CPU,实测20M/s左右),所以,X86-J1900,承担了整个方案中所有需要CPU参与的工作。对于客户端来说,X86-J1900是透明的,客户端看到的只有一个网关,即USG,是感觉不到X86-J1900作为第二网关存在的,所以叫隐藏的第二网关。
UBNT US-8-60W
6.jpg
PoE交换机,Unifi核心成员之一。作用:核心交换机;为AP供电。
这个设备有太多的介绍,不多说了。这里主要提一下我选这个设备的原因:性价比高。当然,我知道,某某Link一个PoE+的交换机也就这个交换机的1/3价钱,如果是国产杂牌PoE交换机,还会更便宜。何来性价比?其实US-8-60W这个交换机是支持三层QoS的,当然官方并没有明确支持这个功能,需要ssh到交换机上,然后根据EdgeSwitch的CLI命令来配置,虽然很麻烦,但终归是能实现,这个交换机很好的弥补的USG不能开QoS的缺点。后文为会有QoS的设计说明,主要是这个设备来完成。所以,你想限制一下玩客云,或者想让FaceTime不卡顿,都是可以通过这个交换机来实现的,而同等功能的交换机,思科大概在5000左右,Netgare大概在3000左右,所以,这个交换机700-800元是极具性价比的。
UAP-AC-IW、UAP-AC-Lite
uap-ac-iw-pro_front_copy_1024x1024.jpgUAP-AC-lite5.jpg

这两设备UBNT 876M的AP产品,UAP-AC-IW带有两个支持VLAN的网口,网上有太多介绍了,不多说了。
Raspberry Pi
7.jpg
Unifi云端管理,和UBNT UCCK一样的功能,但比较便宜,还可以当作智能家庭的中枢。

核心的设备就这么多了,剩下都是客户端设备:比如IPTV盒子,NAS,PS4等等,不做介绍了。

三、Zone区域设计
8.jpg

上部为WAN域,下面为LAN域,每个小域以VLAN隔离,承担的功能都不同。
WAN域:
1、PPPoE(s)Zone:Internet连入,所有访问Internet的流量都要进入这个Zone。
2、IPTV_WAN:所有IPTV的流量都要进入这个Zone。
3、Company VPN Zone:所有访问公司的流量都要被路由到这个Zone
4、AD Block Sites Zone:部分特定的网站(比如:youku.com)的流量要被路由到这Zone,去除广告。
5、Admin_WAN Zone:访问WAN域的设备管理流量,比如访问光猫的管理WEB的流量,都会被路由到这个Zone。
LAN域:
1、Family Zone:LAN的核心域,几乎所有家庭的客户端、智能设备都在这个区域。
2、IPTV_LAN Zone:IPTV盒子单独划分了一个域,用来阻隔组播的风暴。
3、Guest Zone:访客网络,只能访问Internet,不能访问其他域。

四、WAN域设计
1、Internet接入 / PPPoE(s) Zone的实现

9.jpg

这里采用了多拨的方案,这个方案与常见的方案有两点不同:
1、在USG的WAN口上划分了VLAN
每个VLAN里面绑定PPPoE,这种设计是USG的特性决定了,因为USG,在VLAN、PPPoE、NAT等功能上是有硬模块(Offload),划分VLAN,然后在每个VLAN里生成了一个MAC地址进行PPPoE拨号,这个效率是最快的。
2、在USG和光猫之间用了一个VLAN交换机
其实最开始并没有使用VLAN交换机,而是直接在光猫上设置了VLAN绑定,光猫可以直接接收VLAN数据包,但最后实测,光猫接收VLAN的速度并不高,在电信送的SA1456C上实测,做了VLAN绑定后,交换(桥接)速度只有400M/s左右,所以,增加了一个VLAN交换机。这样的好处是,光猫不用超级管理账号,不用改设置,另外,VLAN Switch的VLAN Tag操作效率非常高,950M-1000M/s的线性速度,妥妥的。

这个方案的特点
一个字,快!真的很快!
作者的宽带单拨是100M下行4M上行,用SpeedTest测速大概能测到140M下行4M上行左右,运营商给了较多的下行余量。
用USG多拨,负载均衡后,最后实测的带宽结果如下:
SpeedTest测速
看结果之前,先解释一下,SpeedTest的测试结果和后面从其他几个方面测试的结果有比较大的差异。其实,SpeedTest并不能准确测出多拨的叠加带宽总和,原因是SpeedTest后台大约发起6个连接测速(Chrome的开发工具可以看到,但有时是4个连接),这种情况下,如果6个连接正好随机分配到了6个不同PPPoE出去,那测出的速度是6个PPPoE带宽总和,这是准确的,但如果有2个连接被分配到了同一个PPPoE上,那测出的速度是5个PPPoE带宽的总和,依次类推,所以,SpeedTest在多拨的场景中测速,每次结果差异都很大,6个连接要正好随机分配到6个不同的PPPoE,这种概率很小。所以,下图测速只能做参考,真实叠加带宽比这个数值要大。
10.png

USG的管理端,迅雷全速下载时,Unifi Controller中显示吞吐量为844Mbps:
11.png

迅雷全速下载时,Windows任务管理器中,网卡显示的带宽主要在600-800Mbps区间浮动
2018-06-24_10-15-24.jpg

迅雷全速下载速度总和,在80-90MB/S波动:
13.png

当然这个方案的缺点是:
1、实现比较复杂,USG的WEB功能并不支持上述功能,需要SSH到USG上以及配合json文件,自己写配置来实现。
2、多拨受运营商限制,并不是每个地区都能多拨,或者多拨后带宽增加。

2、IPTV接入设计/IPTV_WAN ZONE 和IPTV_LAN ZONE的实现
IPTV服务的总体设计如下图:
14.jpg

上图,设计时主要考虑两点需求:
1、IPTV盒子不能直接连接光猫,只能放到USG路由的后面(客厅只有一跟网线的场景);
2、能扩展IPTV终端,在其他设备上观看IPTV直播。
上图比较复杂,用一个简化版的图来描述过程如下:
15.jpg

首先,USG“冒充”IPTV盒子认证。USG克隆IPTV盒子的信息通过认证以后,接入运营商的IPTV专有网络。本地运营商对IPTV盒子采取的DHCP认证,也就是IPOE认证,根据抓包分析,运营商根据IPTV盒子的MAC地址、HostName、Vendor来认证。

然后,USG为IPTV盒子创建一个IPTV_LAN Zone,即VLAN 2,并在VLAN 2上“冒充”运营商网关为IPTV盒子分配一个内网IP,比如192.168.5.2/24。根据抓包分析,本地运营商下发IP时并没有特殊的信息,不像上海,网关在下发IP时会带着option125信息,IPTV盒子会认证这个option125。

接着,在USG上,利用策略路由,把所有来自VLAN2的请求,即192.168.5.0/24网段的流量,NAT转发到IPTV_WAN Zone(VLAN 13)网关,这样, IPTV盒子与服务器的认证交互、点播业务、回看都能正常使用了。

最后,在USG中用IGMP Proxy把IPTV_WAN Zone(VLAN 13)的组播数据,代理到IPTV_LAN Zone(VLAN 2),这样IPTV盒子直播也能正常使用了。

上面图中特意忽略了一个核心设备,UAP-UAP-IW,这里补上:
iw.png
UAP-AC-IW可以理解为一个VLAN交换机+AP的合体,这个设备装在客厅电视机附近的86盒里,有效解决客厅只有一根网线的场景,背面网口连接对应上图的VLAN Trunk,左边的网口划分为VLAN2接IPTV盒子(IPTV_LAN Zone,充满组播数据流一个Zone);右边网口划分为VLAN1接其他内网设备(Family Zone),该设备还有AP的功能。

接下来,要解决另外一个问题,因为运营商只送了一个IPTV盒子,如果想在第二台电视上观看IPTV直播还需要进一步设计方案。比较简单的方案(最开始用的这个方案),在USG上用IGMP Proxy把组播复制到小米盒子所在Family Zone(VLAN 1),小米盒子上安装Kodi,Kodi是可以接收组播视频流的,但这个方案会让Family Zone(VLAN 1)中充满组播风暴,降低整个Family Zone的效率。所以,这个方案被放弃了,最后实现的方案如上图X86-J1900的部分。X86-J1900同时接入IPTV_LAN Zone(VLAN 2)和Family Zone(VLAN 1),在上文中IPTV_LAN Zone(VLAN 2)已经是一个组播视频流的域,所以,X86在IPTV_LAN Zone(VLAN2)上可以直接接收组播视频流,然后用udpxy把组播流转化成HTTP点播流,在Family Zone(VLAN1)上提供点播服务,这样就变成单播了,避免了Family Zone(VLAN1)的组播风暴。

最后实施效果如下,IPTV盒子分配到的是一个自己规划的内网IP,IPTV盒子通过路由器连入IPTV专网(不占Internet带宽),所有业务都正常使用:微信图片_20180716091037.jpg

电脑VLC通过HTTP点播流收看IPTV直播:
16.jpg

iPad装上VLC也可以光看IPTV直播。
17.jpg

同样,小米盒子装上Kodi能观看IPTV直播(盒子截图导出来麻烦,就不上图了)。

总结一下,这个IPTV方案的优点是:
1、解决了客厅只有一根网线的场景2、光猫不需要超级管理员账号,原来IPTV盒子接光猫iTV的网口,现在还是接iTV口,不需要设置光猫。
3、在LAN侧划分了一个IPTV Zone(VLAN 2)给IPTV盒子,有效的把组播控制在这个范围里面。
4、解决第二台电视和其他设备观看IPTV直播的需求。
5、无限扩展IPTV终端。运营商网关并不知道,接入IPTV专用网络的交互对象是一个路由器(因为克隆了IPTV盒子的信息),所以,在路由器背后可以任意增加IPTV客户端,如上文提到的X86-J1900,其实就是一个IPTV客户端(接收组播视频流)。。
6、在内网核心域,即Family Zone中以单播的方式提供IPTV直播服务,既满足了IPTV直播观看的需求,又能保证Family Zone的整体效率。

缺点:
1、其他设备只能看直播,回看和点播只能在IPTV盒子中。点播业务IPTV盒子需要向网关HTTPS登录。
2、实现较为复杂,以上所有的配置,USG都不能通过WEB完成,手工写配置写死人!

3、公司VPN接入实现/Company VPN Zone
18.jpg

上图说明了Company VPN Zone的实现方式,但便于阐述具体过程,所以,上图按照数据流的流向做了稍许变化,如下图:
19.jpg
1、首先客户端访问公司的地址,以apple.com为例。
2、在USG上,定义了一个公司地址范围,apple.com位于这个范围中,因此被策略路由发送到VLAN20的next hop,即 X86-J1900。
3、X86-J1900上部署了公司VPN客户端,把来至于VLAN20的流量全部转发到VPN Tunnel,而公司VPN客户端连入Internet的方式是通过USG,所以,X86的VPN流量通过LAN再一次回到USG。
4、这一次USG会把VPN客户端的流量当作正常流量发送到Internet。

这个方案的特点是:
1、利用了X86架构的高性能运算能力。
2、USG的NAT、交换机的转发都是线性速度,虽然数据流来回转了很多次,对延迟并没影响。
3、客户端透明,无需额外设置,而且客户端并不知道apple.com的流量被USG路由到了X86去处理,客户端无需任何操作。
4、速度很快,真的、真的很快。
测速结果:
通过接入公司VPN网络(加密方式AES256-GCM),SpeedTest的测速能达到200+M/s:
20.png
另外从上图可以看出,虽然数据流在各个设备来来回回好几次,ping延时并没有受到影响,公司接入服务器位于香港,直连ping值也在50ms左右波动。

视频网站测速,5K视频,如下图:
21.jpg

该方案的缺点:
实现较为复杂,以上所有的配置,USG都不能通过WEB完成,手工写配置写死人!(后面这个点不说了,下文中几乎所有的实现都要手工配置)

4、去广告服务设计/AD Block Sites Zone

22.jpg
上图说明了AD Block Sites Zone的实现方式,和Company VPN Zone类似,其数据流向如下:
23.jpg

上图过程和Company VPN Zone的数据流向极为相似,不再复述,这里阐述一下和其他去广告方案设计的比较:
1、与屏蔽广告dns的方案相比,比如:利用dnsmasq把广告的dns解析到一个不存在的ip,或者干脆直接使用pi hole作为dns server。此方案中的adbyby和koolproxy可以自动更新去广告的规则,自动调整WEB页面,把屏蔽的广告部位清除,不会出现满屏的404错误,对广告去除比较精准。
2、与直接在路由器上运行adbyby/koolproxy方案比较,此方案中,利用策略路由在USG中进行一次筛选,只把少部分需要去广告网站的流量路由到X86,大大减轻X86的压力。同时,adbyby/koolproxy是两款比较占系统资源的应用,在X86上运行的效率比ARM/MPIS其他架构效率要高很多。
3、客户端透明,客户端不需要额外设置,而且客户端并不知道是X86完成了去广告的处理过程。

5、WAN_ADMIN ZONE/WAN管理域
24.jpg

这个Zone的设计主要是能够满足为与LAN的客户端能够对WAN的设备进行维护(光猫、VLAN交换机)。

五、LAN域设计

1、LAN的总体规划
核心成员,Unifi全家桶,前面已经出场过了

25.jpg

Unifi Controller 部署在Raspberry Pi上,为什么选Raspberry Pi,因为便宜。一共四个AP,两个卧室各一个UAP-AC-LITE,书房和客厅有网口的需求,所以用的是UAP-AC-IW。

整个内网划分了三个Zone(VLANs)

IPTV_LAN,前文IPTV部分已经介绍过了,IPTV盒子所在的Zone。

Guest Zone是访客网络,这个Zone是只能访问Internet,不能访问其他Zone。

Family Zone就是内网核心Zone,所有的内网设备都在这个Zone里面,按照完美的角度来说,这个Zone其实还可以进一步分成Admin Zone和User Zone,把设备的管理都放到Admin Zone里面,普通用户在User Zone里面,但是,懒,就这样了。

2、AP布置
四个AP分布和网关分布如下:
26.jpg

由于受到装修时布线所限,就这样了。另外,由于高密度部署AP,所以AP的摆放不是依照信号为原则,每个房间一个AP,避免金属物遮挡,怎么摆其实信号都差不多,所以,AP布局主要是以美观为主,其实就是怎么能把AP藏起来。最后呈现的效果,几乎没有客人能发现家里无线在哪。

网关、交换机、X86网关的安置
27.jpg
不要误会放错照片了,哪来莫名奇妙的一个鞋柜,因为没有办法接受在家弄上一个机柜,和装修太不搭了,所以用了一个鞋柜,挡在弱电箱前面。
28.jpg
鞋柜后面的弱电箱,比较小,只能放上交换机,线比较乱,反正看不到。

29.jpg
鞋柜里面的网关。

客厅的AP
30.jpg
全部的AP采用了隐藏设计,上图你能找到AP在哪吗?

31.jpg
上图,缩小一下范围,在电视左下角。

32.jpg
答案是:柜子后面,给个特写,UAP-AC-IW。

卧室的AP
33.jpg
你能找到AP在哪吗?

34.jpg
答案:在窗帘后面,墙装的。

书房的AP
35.jpg
书房的AP在书桌下面,UAP-AC-IW和插线板放一块,没图,忘拍了。

虽然AP有遮挡,但信号总的来说,还过得去。
36.png

3、无线频率规划
没什么好规划的,两个离得近的AP用频率离得远的Channel就好了。

4、无线SSID规划

无线SSID规划的原则是2G和5G的SSID分开。其实,UBNT是支持2G和5G使用同一个SSID,AP引导5G终端连到5G上,但实际测速过程中,部分智能2G终端对这种技术支持并不好,所以,让2G和5G使用不同的SSID。智能设备全部在2G,而手机、平板、笔记本连5G,并可以漫游。

5、QoS设计
前文提到过USG的QoS功能和HWNAT(Offload)是冲突的,一打开QoS,USG的转发速度能从800M/s掉到5M/s,是的5M/s,你没有看错,用了多拨以后,USG的CPU就只有5M/s的转发能力,5M/s不能再多了。
家里有一个玩客云,(后来在高价的时候被我卖了),如果不限制他,他的上传速度能上天,但又不能一刀切,毕竟在闲时,还可以补贴一些电费,所以,QoS必须的。

最后,这个QoS的任务落到了Unifi全家桶核心成员之一US-8-60W交换机(USW)上。
如下图(以数据流出站方向看):
37.jpg
这个方案是把QoS设置在交换机的uplink端口上,uplink的上级是USG,
数据包到达交换机后,交换机根据IP,MAC地址、DSCP值来进行队列排序,让优先级高的数据先从uplink出去,先达到USG路由被处理,这样USG不用开QoS,也可以保证高优先级的业务。
对于电脑这种多业务的终端,只能利用操作系统的DSCP功能,让操作系统把迅雷这个进程产生的流量打上一个较低的DSCP值,让IE的流量打上较高的DSCP值,数据包到达交换机后,交换机直接信任这个IP的DSCP值,这里,举一个不信任的例子,比如玩客云,就算玩客云把自己的流量DSCP值设置很高,交换机直接忽略,只要是这个IP的流量都被重新赋予一个较低的DSCP值,然后,交换机根据DSCP进行QoS,迅雷的流量就被降权了,因此,边下载边看网页,网页也不会卡顿。

测试结果:

38.png
上图是没有应用QoS的场景,可以从右下角,迅雷,可以看到,目前速度50MB/s,但ping延时已经高达557ms,整体网络效率变慢了。

39.png
上图是应用了QoS的结果,可以从右下角,迅雷,可以看到,目前下载速度已经近70MB/s,但ping 延时还是比较正常。

这个方案的优点:
1、 初步解决了Unifi全家桶中主路由USG不能做QoS的缺陷(和Hardware NAT冲突)。
2、 QoS速度很快,交换机有Hardware做QoS,速度是线性速度。
3、 QoS对玩客云、赚钱宝等业务效果比好,既不影响收益也不影响正常上网。
缺点是:
1、首先,US-8-60W,这个交换机只能在ingress上做QoS,不支持在egress上做QoS。所以,如果0口是uplink,那QoS策略只能做在1-7口的ingress上。
2、对于整个架构来说,流量是针对Internet出站流量做QoS。对于入站流量,这个方案的瓶颈在USG,当数据包已经进入到交换机的uplink端口后,已经没有做入站流量QoS的必要了,交换机的交换速度没有性能瓶颈。只能在出站流量上做QoS的意思,并不是说出站流量的QoS解决不了问题,首先对于上传类业务,比如限制玩客云、赚钱宝,效果是100%,对于下载类,比如迅雷,如果一个迅雷下载的数据包QoS降权,以低优先级发出,对端服务器收到包的等待时间就会变长,应答的速率就会变慢,迅雷下载入站的流量就会降低,USG就能够处理更多其他业务的入站流量,从而间接保障了其他业务的流畅(比如上图测试结果就取得了很好的效果)。后记:从作者后期使用的来看,如果迅雷的并发数特别多,尤其是同时下载4-5个任务,USG的入站流量被大量迅雷下载流量占据,效果并不是特别明显,没有上图作者测试时的效果,这也是不直接做ingress qos的妥协。
3、官方主要是通过Unifi Controller管理交换机,并没有打算让Unifi交换机能够支持CLI手写配置。所以,这个QoS方案最严重的缺陷:目前手写的CLI配置生效没问题,但不能保存,用write memory完全没用,重启就没了!!!在全球论坛提过这个问题,官方的答复是,我们开放CLI,并不是打算让你写配置的,主要是让你用show xxxx看看配置。
4、复杂,实现很复杂。

6、安全设计

证书服务
40.jpg
利用Let’s Encrypt 给unifi颁发免费的证书,放在Raspberry Pi上可以到期自动续签,如下图,Unifi使用了SSL证书,除此之外,还可以为NAS提供SSL证书。
41.jpg

Guest Portal
这个是Unifi 自带的功能,可以用密码二次登录,很好解决了,访客不小心把密码分享到WIFI万能钥匙的问题。这个安全功能是必须的,因为家里的智能设备比较多,一旦被别人连入WIFI,后果太严重了。

42.png

7、智能家庭设计
43.jpg

这个是一个应用场景设计,也是最炫的一个设计,也是作者给客人得瑟最多的设:
视频效果:(不会贴视频)v.youku.com/v_show/id_XMzcyNDIyNjEzMg

44.png

(完)

6赞

不错,感谢分享,很多想法值得我去学习。

鼓掌,很多我得学习的地方:)

厉害了 很多功能 学习 iptv那块学习一下 多拨 我也搞了

不错,这些方案太合适我了

值得学习的案例,CHH上也发一个吧,可以上榜:)

太厉害了

请教楼主,如果没有多拨和第二网关的需求,可以不用连光猫的vlan交换机,直接接路由把iptv的数据转发出去吧?

另外能详细讲讲怎么克隆tv盒子进行认证和把组播流转化成HTTP点播流的方法吗?家里的黑群不知道能不能搞搞这个

最近有点忙,没时间写具体的教程,您提到的如何克隆iptv盒子信息是需要抓包分析的,比如我这,进行dhcp认证的时候能抓到,iptv盒子在dhcp的时候发了哪些信息,然后让usg模拟这些信息即可,下面是我json配置文件的片段,其中包含了克隆mac地址(通过vlan产生一个新的mac),发送的hostname,vendor,请求dhcp分配项等,完全模拟iptv盒子的行为,您可以参考:

{
 "interfaces": {
   "ethernet": {
   "eth0": {
   "vif": {
   "13": {
   "mac": "74:97:81:7a:1f:e1",
   "firewall": {
   "in": {
   "ipv6-name": "WANv6_IN",
   "name": "WAN_IN"
   },
   "local": {
   "ipv6-name": "WANv6_LOCAL",
   "name": "WAN_LOCAL"
   },
   "out": {
   "ipv6-name": "WANv6_OUT",
   "name": "WAN_OUT"
   }
   },
   "address": "dhcp",
   "dhcp-options": {
   "client-option": 
   "send host-name "B0000000000000000000007497817A1FE1";",
   "request subnet-mask, routers, domain-name-servers, host-name, domain-name, broadcast-address, router-discovery, static-routes;",
   "send vendor-class-identifier "iTV";"
   ],
   "default-route-distance": "200",
   "name-server": "no-update",
   "default-route": "update"
   }
   }
   }
   }
   }
  }
}

关于组播转点播,您网上搜索udpxy,有比较多的教程。

我没有CHH的账号。。。

这才是大神啊,理念和思路都值得学习,慢慢吸收中。
其中很多手写代码更是遥不可及,路还很远,感谢分享!

你好,大神,你的方案很不错,我也是UNIFI 全家桶,很喜欢你的网络拓扑,正是我追求的家庭网络终极目标,但折腾时间有限,LINUX 语言不会,限制了我折腾的范围,是否可付费请你帮我实现呢?期待您回复!有偿!有偿!有偿! 诚心的,谢谢!

消失几天就发现大神的更新。慢慢学习。现在我的只有形没有神,得慢慢学习。

每天都刷新论坛等大神的更新,前面多拨还没尝试,据说苏州电信无法多拨。。。楼主设备跟我真的很类似,也想配置成这样的终极方案,静待大神有空了更新具体实施方案

另外问下 家里有个NETGEAR GS108T带网管和VLAN功能的交换机,应该就是大神你所说的VLAN交换机吧

谢谢厚爱,楼主最近有点忙。建议您可以联系一下ubnt的代理商,他们一般可以提供付费的上门服务,给他们提实现要求就可以了,具体价格您咨询服务提供商。楼主接私活的价格是几K/天,但最近有个项目要投标,忙cry了。。。

进一步优化了一下。
3215U虚拟化跑了LEDE+Ubuntu(pihole+unbound)
其他不变。
目前300M带宽,Speedtest 能跑到110%的速度。无线情况下,国内、国外测速点都能到这个水平。

后面进一步优化,pihole DNS servers的作用。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

之前就参考您的方案做了初步架构调整。目前是
USG pro4 主路由
3215U 刷了LEDE专门跑特殊服务
树莓派3 主要跑了Pihole(dns over https+去广告)+HA(目前只有小米设备没正式开始完)
交换机(EDGE Switch 48 POE)

没有IPTV。IPTV我现在用的是直播源+超级直播。完全无压力(缺点是占用贷款)
GCP建的特殊服务,在没搭pihole之前,DNS有些问题,加了Pihole之后一切正常。
(300M带宽,目前通过特殊服务只能跑到200M,而且访问国外测速点,PING值有点高,后期重点解决这个问题。)
上海电信。无法多播,就没考虑了。目前在折腾HA。
这套方案已经推广给很多人使用了。
很赞,感谢大神期初的指点。

生意兴隆~~~~

感谢回复,价格可以接受,我不急,等楼主空了也行的,方便的话可以私一个联系方式。我是上海的

学习了,没见过比楼主更能折腾的:D

大神,求留个联系方式,想要你这个方案的详细配置,大神应该是通过Console连接做的配置吧。希望能深度沟通一下。