-
-
手机阅读
负荷分担的基本思想是通过每个链路中的带宽来均匀分布流量，目前还没有考虑PMP，2M UNI，34UNI，没有考虑优先级和百分比，况且对于同一局向的路由表的地址长度一定要相等，目前对于BEST EFFORT呼叫仅分配150K的带宽（UBR业务），此参数可在static void GetBandwidth( STraffic *sTempTraffic, DWORD *pdwBandwidth )函数细调，为了达到统计均匀，此参数要合适。如有二条负荷分担路由A、B，A中已建了10M的PVC，如果上述参数太少，则所有BEST EFFORT呼叫都在B上，而不会到A上，如果选取150K，则在B上有70个呼叫（BEST EFFORT）后，就在A、B上同时都分担呼叫。
根据上述负荷分担的基本思想进行了负荷分担 的功能测试。测试中的线路连接图如下图所示。
HP测试仪设置Forword/Backword Peak Cell Rate为1000cells/s，测试仪的3口向7口发起呼叫（信令类型为UNI3.1）。在没有发起呼叫前，将交换机 1、2的5、7和8口的ILMI和信令均激活，这三个口不建立与其它光口的链路，此时这三个口的已用带宽（Used Band-In/Out）为2000cellsps （sh port 可以看到已用带宽为信令链路所占）。现在由测试仪3口发起一次呼叫，sh port 5、7可以看到已用带宽由2000变为3000，同时建立起一条5口和7口间的SVC。再发起第二次呼叫，sh port 8可以看到已用带宽由2000变为3000，而 5口的已用带宽由3000变为4000，同时增加了一条5口和8口间的SVC。如此不断地发起呼叫，可以看到7口和8口的已用带宽是交替在增长的，这样就证明了负荷分担功能的实现。
Radium.MPU%sh po 7
Port status : Active
Band width : STM_1
O/E attribute : Optical
Clock attribute : Source timing
Type : UNI
Loopback mode : No loop
Alarm status : NODEFECT
Max Band-In : 353207
Max Band-Out : 353207
Used Band-In : 2000
Used Band-Out : 2000
Max VPCs : 100
Max VCCs : 1900
Used PVPs : 0
Used PVCs : 2
Used SVCs : 331
Test mode : off
在测试的过程中出现了如下的现象：交换机1的7口和交换机2的7、8口的ILMI注册成功，三个口都获得了对端的网络前缀，只有交换机1的8口的ILMI状态为VERIFYING，却没有获得对端的网络前缀，从LOG信息看，该口的ILMI注册过程正确。经查该口的ILMI协议版本为3.1，信令版本为UNI3.1，而其它三个口的ILMI协议版本为4.0， 信令版本为IISP，发起的所有呼叫都从交换机1的7口中继到交换机2，8口没有进行分担。将交换机1的8口的ILMI协议版本设置为4.0，8口即可进行负荷分担。这说明ILMI协议版本没有实现自适应的功能。后与开发人员沟通后得知，我们交换机的ILMI4.0版本可以自适应其它厂家的ILMI3.1版本，但不自适应我们自己交换机的ILMI3.1版本，对端网络前缀的获得也仅限于ILMI4.0 ，并且是非协议规定的，是由我们自己设计的，设计中没有考虑ILMI3.1 对获得对端网络前缀的支持。在实际开局中，ILMI是不激活的，信令版本是由手工设置为IISP的，以实现与其它厂家的产品的互通。
测试结果说明负荷分担功能已经正确地实现了，但条件是ILMI的版本必须为4.0。