记折腾4K IPTV的周末给自己带来的新知识

上个月家里宽带升级了200M, 顺带看到可以免费享受一路4K的IPTV.

其实一直都知道电信的宽带可以免费申请IPTV, 但是一直都没弄, 主要原因是一直都没找到合适的办法去只用一根网线来解决我上网出口跟IPTV的问题..曾经看到一些方案但是都觉得不合适或者说不够理想, 而在几周前,在Chiphell毒坛看到了一个近乎完美的解决方案https://www.chiphell.com/thread-1421026-1-1.html, 这样一来4K的IPTV自然就可以顺理成章的入住了.

申请过程很简单, 直接找电信客服提供信息就可以安排安装了, 连个合同都没其实, 但是却要求1年的锁定期…电信也是可以…

在电信安排安装之前的一周里, 我先对自己内网做了一个简单的调整来保证新的IPTV实现方案的基础.

简单描述一下原来的网络结构:

电信光猫—-ERL3路由(PPPoE拨号+DHCP+DNS+SS…)—HP 2910al交换机—终端

基本上结构无论是逻辑还是单一方向的, 物理接线也是光猫出来的线直接进入路由器再从路由器进交换机.

在调整完以后:

电信光猫—HP交换机(WAN VLAN+IPTV VLAN)—ERL3—HP交换机(LAN VLAN)—终端

盗用一下Chiphell上作者的解释图:

qq20151223-12x

从物理连接上就变得复杂了, 光猫出来的线路先进交换机, 脱标以后的WAN数据进如路由器, 打标的IPTV 组播数据会直接通过VLAN trunk去跟IPTV做交互.

所以整个方案的核心就在于:

  1. 需要交换机使用Trunk线路来同时承载上网数据跟IPTV数据
  2. 在交换机中将2类数据分离开来并且送到需要去的地方
  3. 路由器的DHCP能为IPTV提供需要的配置参数.

所以折腾的点就变成了:

  1. 交换机的VLAN配置
  2. 路由器的DHCP Option

事实上交换机的VLAN配置并没有什么大的挑战, 因为我自己之前的环境内本身就是多VLAN的, 所以无论是设备的支持与否以及能做到什么程度都很清楚.

所以其实只是在交换机上多加了4条VLAN:

  • VLAN for WAN, 专门的2个口用作光猫LAN口跟路由WAN的连接, 目的就是让光猫到交换机的线路变成Trunk状态可以同时承载多VLAN的数据.然后从另外一个出口把脱标的上网数据送给路由器做拨号. 而打标的IPTV组播会从trunk线中的其他VLAN回去到光猫. 这个就实现了我们需要实现的关键功能第一跟第二个核心点
  • VLAN for IPTV, 这个是我专门给IPTV开的一个VLAN, 实际是可以不用的, 可以使用之前已经存在的LAN VLAN来代替. 不过考虑到IPTV需要特殊的DHCP option 参数, 所以我特地开了一个独立的VLAN出来接IPTV, IPTV的公网接口就是从这个VLAN出来再从路由的接口出去的.
  • VLAN 85 跟 VLAN 51, 这两个是IPTV专网使用的组播VLAN, 用来承载电视数据, IPTV会通过这个VLAN直接跟光猫通信跳过路由器. 所以实现第二核心点的重点就是VLAN的划分

到这步为止, IPTV需要的在交换机上的准备就完成了.

剩下的事情就是DHCP的问题了…

因为没用过以前的IPTV所以我不确定是什么情况, 据说比较新的版本是只要能上网就能用了.

而新的4K IPTV是需要所谓的跨越AB面认证的, 从我的认识上来说, 就是先要拿到Internet的access, 再通过VLAN 85拿到专网的IP.

公网access的IP简单, 常规DHCP的配置就行. VLAN85的配置, 根据众多前辈抓包对比以及查阅《中国电信家庭网关总体技术要求》说得到的信息来说,就是需要在第一步的公网IP的DHCP过程中,携带上Option 125的信息,

dhcp

option 125中的信息会告诉Client VLAN85的存在.

具体请参考这里:http://koolshare.cn/thread-43568-1-1.html

所以我就需要给IPTV VLAN的DHCP server必须要可以发送Option 125出去.

然后重点就来了.

我本来天真的以为只要配置上了DHCP Option 125, 那么Client来申请的时候option会被附加上, 然而事实证明我还是太弱鸡了.

不过既然这么想了, 肯定先要把option 125这个配置能正常生成了才行.

所以我去爬了一下Ubnt的国内外论坛, 了解了自定义DHCP option的配置方式, 相对来说还是比较容易实现的.

set service dhcp-server global-parameters “option option-125 code 125 = string;”

set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-125 00:00:00:00:14:02:06:48:47:57:2d:43:54:0a:02:20:00:0b:02:00:55:0d:02:00:2e;”

2条命令就能在ERL3里面自定义出来一个option 125来..不得不说Ubnt的货实在是自由度高到没边啊…

然后我就用Windows上DHCP test去做测试了..

这是个很小的带抓包功能的测试工具, 基本功能就是检测网卡通信中的DHCP包并且抓取下来, 以及模拟一块新的网卡去discover DHCP.

DHCPtest出来的结果很令人振奋呢, 可以直接看到Option 125在offer包里呢!

所以我就很放心的去等IPTV的安装了…

然而事实证明一帆风顺总是小概率事件, IPTV在完成安装以后直接就跳了认证失败, 网络信息显示公网正常专网拿不到IP地址.

这时候我就觉得这怎么可能..

回头再用DHCTest测试, 明明是有的啊…这时候我都怀疑是不是Option 125给的raw data是否会错了…不过考虑到以及被很多人实现过额, 所以code出错的概率其实很小.

所以, 这时候只能启用交换机的镜像端口去抓IPTV说产生的DHCP包, 结果令我诧异的是根本没有Option 125的数据被附加上去.

这时候我才意识到, 前辈们使用DHCP-option-Force的参数给Dnsmasq来添加Option 125的意义, 就是为了强制把option 125推送除去啊…

然而我不想换Dnsmasq啊, 因为ERL3的web页面管理使用dhcpd来实现的, 很清楚很好用啊…

这时候我已经再想要不要把raspiberry给翻出来专门给IPTV作为DHCP sever来服务了, 因为手头能尝试的办法跟能查询到资料已经大多过了一遍了, 对于EdgeOS的系统上如何实现强制option完全没有涉及.

不过天无绝人之路, 在再次搜索查看信息的时候, 注意到了Linux 的DHCP Man Page里对于Option 55的描述是如下的:

option dhcp-parameter-request-list uint16 [, uint16… ];This option, when sent by the client, specifies which options the client wishes the server to return. Normally, in the ISC DHCP client, this is done using the request statement. If this option is not specified by the client, the DHCP server will normally return every option that is valid in scope and that fits into the reply. When this option is specified on the server, the server returns the specified options. This can be used to force a client to take options that it hasn’t requested, and it can also be used to tailor the response of the DHCP server for clients that may need a more limited set of options than those the server would normally return.”

也就说, 只要能给服务器定义出这样一个option, 服务器就会自动根据配置的option list强制给client发送option 信息, 这不就是我要的嘛.

然后赶紧去查Ubnt怎么配置类似的参数, 还真给找到一个:

于是就有个如下的2个配置:

set service dhcp-server global-parameters “option option-55 code 55 = array of unsigned integer 16;”

set service dhcp-server shared-network-name VLAN_50 subnet 192.168.5.0/24 subnet-parameters “option option-55 3,6,58,59,125;”

第一行是定义一个option 125的参数名字, option code以及数据类型

第二行是在对应的子网下, 定义出需要强制发送的Option List.

这里需要注意的是, 在有了55以后, 很多以前被认为理所应当会被DHCP server发送的option就不发了, 比如option 3的网关信息, Option 6的DNS server 信息等等.. 所以无法偷懒只写一个125.

然后就是享受HD IPTV的时间了…

总的来说, 整个过程因为前人的大量实践, 所以并不是特别曲折, 只是因为设备本身的配置以及功能区别的问题, 所以给了我一个去深入理解DHCP以及Option的契机, 在几天时间内大量的翻阅跟DHCP option相关的文档以及配置案例, 对整个体系的理解有了一个新的认识.

所以说, 在实践出真知啊!! 人生不折腾还有什么意义呢?

|2|1


10条评论

  1. KEY说道:

    Mark一下,自己的ROS应该也能通过option55强制发送option125了,有空尝试下,不知道我的GS108Ev3是否支持Trunk。

    • mypchas6fans说道:

      隔了好久才意识到ROS大概也可以通过option 55实现,不过还没实验。。不知道1L成功了么?

  2. Jqx1991说道:

    你好,请教一下,电信配的光猫是友华的PT921G,默认是路由模式,本地无需拨号,安装的时候也没有提供任何账号密码,同时拿不到superadmin,能修改的设置少的可怜,这样的话是不是必须让电信的工作人员上门修改为桥接模式?
    PT921G只有两个口子,一个1000M的宽带接口,一个100M的IPTV,如果改为桥接模式后IPTV的那个接口肯定是用不了了,那么是不是需要用ERX开启两个VLAN,一个给网络用,一个给IPTV用?
    谢谢解答~

    • smallfount说道:

      事实上,如果在有线路条件的情况下.最简单的做法是…光猫的IPTV口直接送到盒子是最简单的…无论是直连还是过交换机的独立VLAN…这个跟桥接不桥接关系并不大因为IPTV需要AB面双认证…在光猫内是一条独立的VLAN…如果没有多的线了…那么改动基本是逃不掉的,最终的思路跟我一样…因为我就是被迫这么弄的..如果有多余的物理线路能送过去,无论是进交换机还是直接到IPTV设备…那都不用改光猫直接挂就可以

  3. 蠡县说道:

    配置option-55的同时,也是要配置那个option-125吗

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

%d 博主赞过: