淘客熙熙

主题:【求助】不灵了,请弟兄们帮忙 -- 萨苏

共:💬152 🌺15
全看分页树展 · 主题 跟帖
家园 现在的问题已经比较明白了

先解释一下我们的线路,在大阪我们用的是EthernetWan,从大阪到我们的ISP的东京端口,这一段是固定带宽的服务,从对端到我们的ISP的悉尼端口也是EthernetWAN,也是固定带宽的服务,而我们使用的是这家ISP提供的一种叫做DIP的特殊服务,也就是说如果我们购买他们在两端的线路/端口,并且在其上构造InternetVPN,因为在Internet上走的是他们一家的BACKBONE,他们可以给我们提供Latency,packet loss,availibility等一系列SLA,从而保证我们可以达到较好的连接效果.至于带宽,这又是一个微妙的地方,尽管没有SLA,但是基于对自己网络使用状况的了解,ISP承诺在我方使用其网络的某一时间段,可以保证需要的带宽。

这是一个介于专线和普通IPVPN之间的服务,价钱也在其间,但是已经满贵的了。

事实上,我们的测试也表明,ISP的Internet部分并没有带宽问题,无论Upload还是Download都没有问题。这让萨这边松口气,因为如果是这部分出了问题,对方毕竟没有SLA,我们会不太有利。

而这个测试结果让ISP也十分委屈,因为这说明它的确有能力给我们提供承诺的服务,却不知道什么原因背上了黑锅。

进一步的分段测试,得出结论从ISP到对端办公室的线路,虽然按照合同是EthernetWAN,但是表现却没有达到承诺,上传达到26Mbps,下传只有7.2Mbps,我想这是问题的关键,但解决起来并不容易,这一段虽然只有很短,中间的设备却比较复杂,因为我们的ISP实际上也是用其它公司的线路,而不同公司间接口也就比较多,单单比较这些接口的CRC状况就要花费很多时间。

这中间,我们还排除了Host的问题,FW 处理能力的问题,往返路由不一致的可能,Application的Bug,Server的CPU使用率过高,加密通道错误,Sky-X的XTP包出错等问题,时间花的很多,但如同在北京胡同里追捕白宝山,的确不是件很容易的事情。

还在进一步确定问题点中。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河