标签: 草稿

记折腾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者有什么本质的区别吗?

那么我们回到这次的限制政策上, 大部分的政策的情况就是要造成滴滴网约车必须要提供差异化服务, 车子要好要新,服务要好.

这也就意味着,把大量廉价的黑车级别的车辆运力淘汰出市场. 至少我是觉得如果真是为了安全舒适考虑的话没什么不好的.

至于户籍限制, 除了魔都帝都应该都没太大意义….至于2个超级城市, 我想住这里的都能理解这个户籍背后给人带来的种种标签意义.

我并不认为增加司机的户籍限制是个合理的行为, 不过如果说要为了限制比亚迪秦这种可以直接拿沪牌的车, 那么剩下的招数也着实不多了, 我估计真要说要求房产证什么的做证据那抵制的声音可能比现在说歧视的声音来得更大吧.

从另外一个角度去想, 很多原本靠着滴滴过日子的司机师傅, 可能因为这样的变故, 直接就回老家了. 我不得不想着, 这应该也是政府人口导流的一个措施吧..毕竟魔都跟帝都都是指定了人口限制计划的地方, 基本上不会再考虑外来人口的舒适度了, 这已经是既定方针, 既然这样, 出台这种政策也就没撒大惊小怪的了.

至于滴滴一直在呼吁的运力大幅度下降的情况, 我预期一定时期内确实会存在, 不过只要需求在, 市场在, 那么必然会有解决的办法…以前的黑车后来的滴滴, 哪个是原本就有的东西?

或许为了吸引新的司机队伍, 滴滴就不得不加大补贴的力度了呢?

至于提价…我相信会消费者始终都会用自己的脚来投票的…如果滴滴不想要这块市场, 那么我觉得别人会很乐意看到的,比如摩拜单车也许哪天就变成摩拜租车了…

当然受伤最深的应该就是现在的专职滴滴司机了….如果直接被扫地出门的话, 他们这些近年来完全依靠滴滴生存的人可能直接就没有了立足的根本了.

不得不说, 无论是滴滴还是快递公司们, 他们间接的解决了大量的剩余劳动力, 也解决了中国这个巨大市场的最终末梢的流通环节.

所以, 怎么解决这些人的出路, 可能会是一个不大不小的课题….希望, 能有个妥善的办法吧…

整个事情的背后, 尤其是滴滴的回应, 给人的感觉更像是拿着消费者跟司机们去跟政府讨价还价…多少有点给人一种垄断要挟的感觉.

我不清楚政府制定政策的人是站在什么角度去权衡的, 但是, 从我的角度去考虑, 保护坐车人的安全是第一位的, 其次才是司机跟消费者的经济利益.

所以滴滴只谈经济问题, 不谈监管问题多少有点避实就虚.

而政府政策的收紧, 我看不清楚目的跟动机是什么, 所以多少有点矫枉过正的感觉, 所以引起的反弹确实有点大..

只能希望市场本身能给出一个相对合理的解读然后做成适当的反应, 去解决这个长期困扰各大城市的民生问题了.

BYOD?CYOD?究竟为了什么?

最近在看RemoteAPP的东西,串到了VDI上,然后想应用场景。无非就是BYOD啊,远程办公啊等等。

然后回头再想一个用户端的问题,我为什么要BYOD呢?对我有什么好处啊?

我猜很多用户的心理的自己用的东西用着顺手,程序员等IT类用户尤其。另外一部分是因为便携,希望随手拿起一个PAD就能查需要的东西,公司的高管可能会更倾向于这个。

那么问题来了,这些其实都不构成真正的所谓的用户需求, 只是用户习惯的问题。

从本质上来说,东西用得不顺手的问题,最根本的原因还是公司的deceive catalog问题。

如果给我选,在公司能提供给我自己一样型号甚至更好的新硬件的情况下,我随便怎么样也不会想着把自己的设备带进来。

那么公司的catalog为什么不够大呢?因为要标准化啊,可是现在连BYOD都能用了,这个标准化不就名存实亡了?

然后另外一个优势是成本优势,然而这要求纯粹的BYOD的,公司完全不提供员工硬件的情况下才能实现,这几乎是不可能的。就算真有员工有这样的意向,一般情况也会要求相应的现金补偿,毕竟是要用自己的硬件来干活了。

所以现在有另外一个说法,叫CYOD,Choose your own Device.

基本上就是把BYOD的思路变成了公司采购,最大化公司的catalog满足用户的需求。

从设备端来说这样其实就解决了用户的问题。

那么反过来从管理端来说,为了满足BYOD/CYOD等多样性设备接入企业网络,IT这边又要做些什么呢?

最首要的就是安全管理。

BYOD的设备是用户自己的设备,CYOD的设备很多是非标准windows客户端,想用传统的AD管理收回用户的管理员权限基本没戏。还有大量的移动端等设备,如果为了安全等考虑,则必须全部都用MDM管理起来。

这样的管理方式的思路其实还是基于传统集中化管理的方式,区别只是以前使用AD来管所有的桌面端,现在是用MDM或者类似的工具来管理几乎所有的移动端设备。

那么为了完成这样的一个集中管理,IT不得不去搭建管理平台,MDM,Landesk,或者SCCM等等类似的。

无论采用何种方式,最终的结果仍然是IT要去尽力集中管理所有的接入设备,最好能做到完全的接入控制,从用户端来控制企业内部网络的安全。

做的再多一点的,直接就上整套VDI系统,把桌面系统跟用户设备直接隔离。这样可以无视用户端的系统平台并且尽可能的将办公环境的网络跟数据中心网络的数据交换做隔离。

但是这一切的一切,其实都是要另外的投入的,无论是硬件还是技术人员的投入。

那么BYOD或者CYOD这些方案的最终目标究竟是什么呢?能带给企业什么样的竞争力呢?

至少我很疑惑。

从经济角度,为了接入安全加大的投入可能会抵消轻量化客户端带来的收益。

从管理角度,无法标准化的客户端急剧增大管理的难度。

从安全角度,因为大量的无权限管控的客户端的存在,从客观上增大了网络被攻入的原因。

所以,我个人对于BYOD带来的收益表示怀疑。

相对来所, CYOD由于仍然属于公司的资产,所以至少在强管控上是可以轻松达成的。相对纯粹的BYOD, CYOD或者混合的CYOD/BYOD可能才是更加合适的情况。

 

 

从IT视角去看一个零售企业的运营模式

花了一段时间熟悉这里, 也花了一周的时间直接在店里参加第一线员工的工作。

从个人的一个视角去理解这样一个零售行业的企业的运作我觉得还是挺有意思的一个事情。

总的来说,在产品线已经基本完备的前提下, 整个企业的运作的根本其实就是基于一个稳定而有效的扩展上。

我之前一直认为大量开店只是头脑发热制定的一个狂热的目标, 不过现在看来,至少开店本身其实并没撒错,真正的问题可能在于开多少以及以怎么样的节奏去开吧。

因为门店的扩张本身就是销售的增长的保障, 同时也是均摊后台成本的一个过程。

一方面是制造新的销售增长点, 一方面则是降低back office的均摊成本。

所以,这样的一个企业,开店不只是他们扩展的需要, 也是operation环节里最重要的财务行为。

当然,我并不认为高速开店就是一个真的很好的策略,至少为了去满足某个目标而为了开店而开店是真心不智的。

开店的优势在于新的销售渠道以及均摊成本的降低。

那么新店必须要保证有足够的大的销售额,否则连自己的成本都无法cover这店就无法存活了。

其次,均摊成本的优势,在店的数量大到一定程度后被削弱,一个是边际效应的降低,另外一个是支撑100家店跟101家的后台人员可能一样,但是100跟200家的后台人员一定是不一样的, 所以门店的扩展势必也会加大支持平台的投入,这时候的成本降低的优势又会被削弱。

当然,扩展还有另外一个优势, 也是以前国内的渠道厂商最喜欢的,那就是增大议价权,压榨供应商。

不过在国内成本日益上升的今天,以及消费者日益注重品质的时代,为了增加利润压榨供应商导致品质下降这种事情,其实最终伤害的是自己的品牌。

从一个IT基础人员的角度来看,真正的挑战在于快速扩张以后,需要支撑这样快速扩张带来的体量所需要的运维需求,以及继续维持扩展所需要的资源需求。

因为基础设备的扩展,所以对于设备已经一线的维护要求会线性增张,如果相应的支持力量不足,那么整个门店的运作就会受到影响,最终的结果就是影响业绩。

而同时,为了维持继续扩张,有限的人员又要抽调到开店的程序上,因为开店的业绩是显而易见的而运维则无法看到明显的业绩,所以同一个人,面对开店肯定热情高于运维,这时候的资源矛盾就产生了。

说以,我觉得最终阻止快速扩张的,往往都是自身运营能力无法支撑扩展的速度,导致要么停止扩展先理顺内部的支持资源,要么就是在继续扩张中因为无力支撑导致新店老店的运营不畅影响业绩而无力维持,最终向内塌缩。倒逼着支持团队去强化内部流程完善支持的环境。

所以与其等到那时候,为什么不现在就开始去做呢?

 

 

更新一下..

最近很少更新, 主要是因为正在适应新的工作环境, 理解他们的公司文化.

说真的我很难想象在国内, 在一个相对来说比较classic的零售分销行业内, 有着这样一家思想激进的公司.

作为一个ITer, 第一次感受到了在一个非科技行业的公司内正在运作着一个理念: 我们要把一切都搬上云~

是的, 现在的公司, 整个办公软件环境是全Google化的, 这是他们全cloud化的第一步, 把整个公司的办公环境从微软的捆绑中解除了出来.

现在所有的office主力软件都已经切换到了google的office套件上去了: Gmail, Google Site, Google Online doc等等, 基本的办公环境已经完成了云化.

接着就是把微软的AD服务器系统剥离, 不再使用常规的AD管理方式, 而是放权给用户本身, 然后所有的传统的Windows server都迁移到CentOS上并运行Puppet来说自动化运维.

到了这一步, 其实本地办公环境已经完全可以云化了, 因为Linux所提供的其实只是DHCP, DNS, Radius, SMB共享等基础服务, 在带宽足够的情况下, 完全可以直接迁移到AWS上而毫无影响..

他们的下一部是把传统的商场POS系统进一步云化…

争取把所有的POS系统都做成B/S模式然后中央服务器直接AWS托管.

SAP也直接升级到NWBC的B/S版本上, 随意准备切换成纯WEB base的cloud ERP.

简直Amazing..

作为一个在国内的巨大分支, Google本身的可用性已经对我们提出了巨大的挑战!

为了保证今后的任意时间任意地点的可用性, 我们还要构思一套根据方便好用并且稳定的VPN方案.

暂时的说法是借助Juniper VPN来实现联通, 然后在本地策略上不做默认路由而只针对Google系的应用做策略路由, 然而他们还想要更好的…

一切的一切, 都是为了支撑看似在当前还略有疯狂的想法.

然而既然已经开始了, 就只有死命去做了, 不管怎么样, 至少很多好玩的事情可以去参与甚至于亲手实现, 挺不错不是嘛….

HostGator长期有效Coupon

这段时间忙着找工作…总算有着落了哇..

Hostgator这边搞了个长期有效的Coupon, 号称是25OFF, 实测下来应该是10刀左右的Discount.

有需要的朋友可以尝试下:

cloud25off51mx