虚拟机无法接受组播消息_IPTV（组播）骨干网完整解决方案--四川广电网络

一，基于ANYCAST 设计骨干RP热备

1，RP选举说明

组播网络RP设置分为动态，静态2种。但和很多网络协议不一样，RP的选择默认是动态优先。也就是在路由器上同时存在动态和静态RP的时候会优选动态，除非定义强制静态优选动态才不会优先于静态。

针对多个动态RP根据组播相关定义其优先级顺序为：

1）服务的组范围（以最长掩码匹配）

2） RP优先级

3） HASH（默认30）

4）IP地址大

问题描述：

如果单纯的使用一个RP路由器进行服务势必导致单点故障问题，如果采用多RP路由器进行普通的动态RP备份无法负载分担压力，即永远只有一台路由器提供RP能力服务。为了更好的设计组播骨干网川网将基于ANYCAST RP思想进行RP设计。

ANYCAST RP实现主要有MSDP和PIM2种实现方式，对于运营商通常选择MSDP实现。采用ANYCAST RP后不仅仅实现了对RP的热备，而且也让RP路由器可以负载分担压力，就近提供服务每个边缘路由器节点。

命令实现（思科IOS-XR）：

router msdp

originator-id Loopback0//设置起源RP（此地址不能是本地的RP地址，这里假设RP地址是LOOPBACK 1），由于MSDP在收到对端SA消息后发现收到的RP消息和本地RP一致会丢弃（防环），因此采用非RP地址作为发起源RP 。（因为MSDP主要目的是告诉对端邻居，针对某个组播地址G，信源的地址S是谁，对端路由器在收到SA消息后会得到SG消息，在确定自己有对应的*G条目后从而朝着信源方向建立S,G条目）

peer X.X.X.X//指明对端邻居地址

connect-source Loopback0//使用本地接口和对端邻居建立连接

工作流程解释

1）：例如路由器A和路由器B均有RP地址 60.255.1.1，并被配置在LOOPBACK 1下面。路由器A和路由器B分别有不同的下游接收者，并且存在条目（*，239.1.1.1）。组播源向RP发送注册报文，根据最短路径的流达到路由器A后，A根据正常的流程向源建立（S,239.1.1.1）条目，并转发给下游接口。如果此刻路由器B同样存在（*，239.1.1.1），在没有配置MSDP情况下会导致路由器B无法得知源的地址S，以至于导致路由器B下面的客户无法收到组播流。

2），为了解决这个问题，使用上述命令在路由器A和路由器B之间建立MSDP邻居，这样A和B消息通过SA消息交互。SA消息包含了S,G相关信息。 B收到后，同样会以正常流程向源建立（S,G）条目，并转发流量给下游接口。这样路由器B下游的用户也可以收到组播流。

3），当其中任何一台路由器出现故障时，另外一台路由器仍然以唯一RP路由器身份服务全网，在同时正常的时候2台路由器又可以起到负载分担的作用边缘路由器就近寻找RP路由器服务，无疑方式更优于单纯的动态RP方式。

二，基于ANYCAST信源热备

信源作为重要节点，至少需要2台以上作为热备份。通常传统方式是使用心跳（通常IP探测）在2台信源之间建立相互备份关系，但通常这种方式发生在同信源厂家之间，并且通常仅能支持2台设备备份难实现3台以上信源热备，除此之外切换发生在探测报文确定对方失效之后（预计在主用故障之后会有超10秒的延迟切换）

1）更好的热备提议：

主备信源编码同IP地址传送到IP承载网，例如主备信源均编码CCTV 1（239.1.1.1）

存在问题：

如果主备信源的源地址不一样即主信源是S1，备用信源地址是S2,S3会导致使用机顶盒观看节目时黑屏，花屏。

2）问题分析：

如果机顶盒收到2套239.1.1.1的流，例如一套CCTV 1流8M，这个时候机顶盒会接收16M的流，由于这16M的流都是239.1.1.1的地址，机顶盒都会接收并进行处理，但是由于流量过载导致混乱进而出现黑屏，花屏等现象。所以在使用这个方式必须保证多套流到IP骨干网但仅一套流传到机顶盒。

3）解决办法：

针对组播路由通常会以 S,G进行标识。S即信源地址，G为组播地址。路由器仅能加载一个S,G到组播转发条目。如果2套信源地址分别为S,S1。那么在IP网路由器上会存在S,G S1，G ，导致流同时传递给机顶盒。因此根据这个机制，川网在设计IP组播信源热备，会设置所有信源地址为S，并且把不同的信源挂载到不同的路由器上，这样可以实现2台，3台，4台甚至N台信源的热备。并保证全网所有路由器针对同一节目均只有一个S，G条目（根据IGP COST选择最优）。

现象测试：

川网部署2台在信源在不同的路由器上，并且设置一样的S地址。根据IGP COST 让其中一台优选。经川网测试：打开机顶盒观看电视，待稳定后关闭主用信源。电视仅起不到1秒的轻微马赛克就完成切换。可以验证组播路由转发表会同步IGP 路由收敛变化，全网IGP收敛通常不到1秒。根据此机制不仅仅可以灵活实现不同厂家，不多数量信源热备，更能大幅降低切换延迟。

三， 安全风险：

1，用户以自己为信源反打非法流到IP城域网，干扰全网接收或无法管理区域在配置其他组播流（集客/本地节目）的时候误配和公共IP相同的组播IP干扰正常的IPTV

如上图所示：

在分公司MSE下游用户在自家注入一套239.132.1.1的非法流到城域网，如果此时OLT无法过滤到反向的239.132.1.1的流，若239.132.1.1为公司某正常节目地址，会造成该频道全省黑屏或者花屏甚至非法插播等严重问题。

问题规避：1,分公司OLT对反向流进行过滤

2,RP路由器通过防止非法注册策略过滤

针对问题规避第一种方式相对好理解，只要分公司OLT支持对应功能即可，但实际上并不是完美的，总有遗漏，甚至存在本地节目错误编码成公共节目地址。因此我们往往需要第2道防范机制，根据组播机制。信源要把流传递给用户，首先是向第一跳路由器向RP发送一个注册报文此报文为单播报文，因此在骨干层面只要阻断接收未经允许的注册报文即可。在这里路由器提供注册白名单策略，策略含义只有带特定S,G消息才可以注册。

命令：思科 IOS-XR，其他厂家类似

ipv4 access-list zubo_rp_yuan

30 permit ipv4 10.80.210.0 0.0.0.255 239.132.1.0 0.0.0.255

40 permit ipv4 10.80.210.0 0.0.0.255 239.132.10.0 0.0.0.255 //定义策略只有源IP 10.80.210.0 并且提供的组播流是239.132.10.0的信息才可以注册成功

1000 deny ipv4 any any

router pim

address-family ipv4

accept-register zubo_rp_yuan //应用策略

此刻若用户反打非法流到城域网地址和城域网现有节目一样例如为239.132.1.1，但由于用户IP非10.80.210.0段，因此RP路由器会拒绝接收这套流，避免影响全网。

2， 非法动态RP影响

1）组播机制本身不完善的一些考虑

组播机制仅支持BSR地址的RPF校验，并不支持RP地址的RPF校验。例如BSR地址为60.255.255.1（BSR通过了城域网路由器RPF校验），携带的RP地址为100.100.1.1（此地址可能是别的区域乱发布的）。这样即使其他分公司（或别的无法管理区域）路由器没有100.100.1.1路由，也会接收100.100.1.1作为自己路由器的RP。那么问题来了，假如由于本身配置的静态或者优先级更低的动态，那么下游会朝着错误的方向加载（*,G）条目（此时RP地址为100.100.1.1然而这条路由在城域网是非法RP地址，甚至没有路由到100.100.1.1），导致本区域IP节目全部黑屏

问题规避：1，统一管理，针对特大型骨干网在整合期比较困难

2,全省强制静态优选

全省强制静态优选RP命令模板：
中兴强制绑定静态RP模板：中兴请基于以下前缀策略做

ip prefix-list XXXX seq 5 permit 239.132.0.0 16 // XXXX为自定义策略名称

ip multicast-routing

router pim

static-rp 60.255.255.1 group-list XXXX

static-rp override

思科强制绑定静态RP模板 IOS--XR版本老版IOS亦可参考

ipv4 access-list XXXX // XXXX为自定义策略名称

10 permit ipv4 239.132.0.0 0.0.255.255 any

router pim