目前，不少企业或政府部门，通过自建或租用线路，开发属于自己的宽带IP城域网，并在其上开展视频会议等应用。一般来说，搭建一个星型网络，进行点对点的TCP/IP数据包传输，并非难事，只要能Ping通对方就行，因为TCP/IP提供可靠传输，接收方假如没有收到数据包，发送方会重发这些包。但是在组播方式下，采用的是不可靠的UDP传输，发送方没有重发数据包的机制，假如传输环境不进行优化，或者网络交换机的配置不很合理，就很轻易造成数据包的延时或丢失，导致传输视频会议的图像时，在接收端出现马赛克、停顿，甚至黑屏等现象。因此，笔者愿把自己总结出的一些组播应用的治理经验与读者共享。
一、网络概况
笔者所在的地级市，下辖9个县，我们利用IP over Optical技术，组建了覆盖全市的光纤千兆IP城域网，在该网络上利用组播技术，成功地召开了多次交互式视频会议，网上用户还可以实时收看CCTV-5转播的视频新闻和世界杯足球赛等。该网络选用了美国Foundry公司的产品，其中在地级市的核心交换机采用BigIron 8000，而在9个县中，有5个单位的汇接层交换机为BigIron 4000，另外4个单位的汇接层交换机为NetIron，这些型号的交换机都是第三层交换机。至于各个单位的接入层交换机则有多种型号，包括3Com、Cisco、Intel和华为等。以上这些产品组成了以BigIron 8000为中心的树型网络，这种网络结构正好与政府部门的分级治理模式相符合。
二、组播协议
组播技术是根据路由器下游是否有组播成员来决定是否转发数据包的，这样，支持组播协议的网络，由于只在路由有分支的节点复制数据包，与传统单播协议在源端复制后，再一一发送出去的方式比较，不但大大节省了带宽资源，还减轻了源端及中间路由器节点处理重复分组的负担，缩短了通信所需的处理时间，大大提高了网络工作的效率。
IP网上的组播有以下三个常用的协议。
1．Internet群组治理协议(IGMP)
该协议被主机用来通知直连的路由器，提出具体组播地址，申请加入或离开一个组播组。发送者则要确定一个合适的地址，这个地址代表一个主组，然后，组播数据包通过普通的IP地址以UDP广播方式传送到提出申请的主机所在子网内的各主机用户。
2．独立组播协议(PIM)
该协议实现对各种组播应用的支持，有密集模式PIM-DM和稀疏模式PIM-SM两种。在Foundry产品上，加载PIM会自动启用IGMP。
3．距离矢量组播路由协议(DVMRP)
该协议属于密集模式，它根据自己的算法建立组播路由表。在Foundry产品上，加载DVMRP也会自动启用IGMP。
要想在IP网络上召开交互式视频会议或发布视频新闻，就需要利用IP网络组播的密集模式，并且启动PIM或DVMRP协议。在Foundry产品上启动这些协议时，不同的VLAN配置方法可产生不同的效果。
三、重在治理
在治理方面，我们做了以下工作。
1．划分VLAN
划分VLAN（虚拟局域网）是为了控制广播包的扩散。对于我们的视频会议应用，采用MPEG 2标准，由于设备相对独立，与网上其他桌面用户之间不存在信息交流，所以我们在全市范围内共10台三层交换机上专门开辟了一个VLAN 24，并给定一个单独的网段，不设网关。Foundry的802.1p/q标准标记答应建立跨越交换机边界的虚拟局域网，于是VLAN 24跨越了不同的交换机，使得尽管这10台三层交换机最远距离为90km以上，还能处在同一VLAN内，避免了一些不相干广播包的干扰，大大提高了接收端处理数据的效率。
对于视频新闻，采用MPEG 1标准，由于接收方是城域网上的普通用户，所以只在源端设定一个独立的VLAN 25。目前在网上运行的视频新闻有2套系统，一套采用MediaPlayer 7.1，另一套采用专用的客户端软件。
2．设置优先级
网络治理员利用可选服务质量，通过IEEE 802.1p/q虚拟局域网标记和优先级别分配，将QoS的优点延伸到交换机边界。
Foundry的BigIron交换机支持8个等级（0～7）的优先级，这8个优先级被分为4组，在默认状态下，最高级别的优先级可请求到80%的带宽。对于VLAN 24来说，就需要为它设置最高级别的优先级（第7级）。
3．配置组播协议
在视频会议系统调试时，由于没有配置好组播协议，整个城域网存在着丢失数据包较多的现象，我们先用HP公司的Netperf软件对网络点对点状态下的TCP连接与UDP连接性能（包括丢包率）进行测试，测试时网络所传递的数据量为11.29Mbps，远大于视频会议的数据流量（6Mbps），测试结果表明没有任何丢包，而且交换机CPU的使用率也很低（NetIron为4%，BigIron 8000为1%）。后来，又邀请第三方用美国Fluke公司的Enterprise LANMeter 683测试仪对全网进行更为严密的检测，结论为该网络是稳定和健壮的。
以上测试结果说明网络交换性能良好，那么为什么在整个视频会议系统调试时，却会出现丢包现象呢？我们仔细检查了组播协议的配置。
对于VLAN 24 来说，由于所有参加视频会议的设备均处在同一个虚拟局域网内，不需要组播路由，只需在最靠近组播源的三层交换机上加载 IGMP即可。实际应用中，我们就在核心层交换机BigIron 8000中属于VLAN 24的 int ve 24上启用了DVMRP，由它来自动加载IGMP；在5个汇接层交换机BigIron 4000上不再启用 DVMRP，否则就要引起混乱，造成组播数据包的丢失；但是由于BigIron和NetIron上的 DVMRP版本不同，所以在另外4个汇接层交换机 NetIron上仍然需要启用 DVMRP。
对于VLAN25来说，由于接收方是城域网上的所有普通用户，他们与组播源分别属于不同的VLAN和不同的IP子网，所以需要在所有VLAN的虚拟端口上启用组播路由协议，包括千兆口上用于级联的VLAN。实际应用中，我们在每个VLAN（不包括VLAN 24）的虚拟端口上都启用了PIM。经过多次试验，我们发现：（1）PIM使用IP ROUTE中的路由信息，而DVMRP则根据它自己的算法，另外生成一个路由表；（2）在同一交换机上，不同的VLAN假如有的使用PIM，有的使用DVMRP，则这些VLAN中的主机不能加入同一组地址；（3）在同一交换机上，不同VLAN、不同子网的主机在相同的PIM或DVMRP的支持下，可以加入同一组地址；（4）在同一交换机上，同一VLAN下的不同子网的主机可以公用一个PIM或DVMRP；（5）同一VLAN下的不同子网，只有地址最小的网段能进入DVMRP的路由表中。
4．协调交换机的互连
不同型号的交换机相连时，需要协调好彼此的配置，否则会影响组播数据的传输。例如，其中一个县级单位的汇接层交换机是BigIron 4000，假如视频会议终端与它直接相连，则能正常工作；假如在BigIron 4000与视频会议终端之间加入一台接入层交换机，型号为Intel 530，结果图像传输不正常，有严重丢帧现象。经过仔细分析，发现是两台交换机的配置没有协调好，后来开通了Intel 530交换机的双工功能，图像传输即恢复正常。
5．检查端口流量
在视频会议的调试初期，地级单位控制中心上的解码设备收到了很多额外的数据包，仔细检查与这些解码设备直连的接入层交换机FastIron上各个端口的流量后，发现当在城域网上进行视频传输时，FastIron会打开组播协议，假如此时组播组里没有接收设备，则FastIron会将其接收到的组播数据包广播给每一个端口，直到有接收设备加入到组播组时，FastIron才停止广播，把数据包只发给已加入组播组的端口。
这是因为Foundry的FastIron属于接入层设备，是第2层交换机，当交换机检测进入的数据流，并且检查目的MAC地址以确定如何转发这个数据流时，由于目的MAC地址是一个组播地址，且在交换表中没有该数据流应该转发到何处的条目，所以这个视频流就简单地被发送到其所有的端口。
要解决这个问题有以下方法：（1）第2层交换机可以窥探IGMP查询和报告消息以了解组播组成员的端口对应关系，这使得交换机可以动态跟踪组播组成员，不过，窥探每个组播数据包和控制包会消耗交换机很多的处理能力，并会因此降低交换机的转发性能、增加包转发延时；（2）在打开与FastIron直接相连的编解码设备时，按照先开接收设备，后开视频发送设备的顺序操作，这种方法的缺点是工作人员往往由于疏忽而造成误操作；（3）将只有二层交换功能的FastIron换成三层交换机NetIron，由于后者的价格比前者贵很多，所以这种方法会造成浪费。
实际应用中，对视频传输软件进行改进，每当需要发送视频组播包时，先用软件模拟一个接收设备，提出申请，加入组播组，这样就不会引发FastIron的广播，从根本上解决这个问题。
6．优化传输环境
在视频会议系统的调试初期，另一个造成数据包丢失的原因是有些三层交换机光纤端口的校验码（FCS）值较大，这会引起频繁启用握手信号，影响正常数据的传输。由于产生FCS错误的原因主要有坏的网卡及驱动、电磁干扰，及其他线路噪声、超负荷工作的路由和网桥、传输线缆超标等，所以有针对性地检查了一些光纤的光功率，有几条光纤的功率已将到交换机接受范围的临界，于是将这几条光纤的尾纤和跳线接头用无水酒精擦洗干净，重新接上后再进行测试，一切正常。
7．治理组播地址
根据Internet地址分配机构的规定，应用系统中可采用的组播地址范围是：224.0.1.0～238.255.255.255。
在实际应用中，我们一般都采用静态设置，如在视频会议系统中设置好组播地址，以后永远不变，这种方式虽然比较简单，在目前视频会议系统使用不多时没有问题，但是假如有两个此类会议系统同时运行，或使用相同组播地址的不同系统同时运行（由于没有统一治理组播地址，开发商互相不知道），那么就会出现无法解决的地址冲
