淘客熙熙

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

共:💬152 🌺15
分页树展主题 · 全看首页 上页
/ 11
下页 末页
            • 家园 【注意】搞不懂老萨的物理线路是咋会事...

              搞不懂老萨的物理线路是咋会事。需要自己调end-to-end,应该就是两边买了个isp的接入(100兆仪态网,e3啥的)而已,可老萨又说中间买了带宽,好像中间又还是有专线类服务的。

              • 家园 现在的问题已经比较明白了

                先解释一下我们的线路,在大阪我们用的是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包出错等问题,时间花的很多,但如同在北京胡同里追捕白宝山,的确不是件很容易的事情。

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

          • 家园 应该不是本地路由到ISP线路的问题
        • 家园 说到网卡想起又一次也是两台机器传东西

          自己机器的网卡的link speed /duplex mode 设为100M Full,人家的设为auto,从人家那里拉东西,就老是纳闷:怎么大家都是用100M端口,局域网传输还这么慢吞吞的。后来把auto那台机改为100M Full就正常了。

      • 家园 【建议】

        老萨的问题如果出在网络上的话,是一个标准的mpls vpn(level2 or level 3)的应用的问题,在用户端是难以解决的,只能碰运气了。这里个关键是用户对中间的TRAFFIC无法施加policy.这几年downturn,估计这种vpn的价格还没下来或根本就没有。。。。。。

        • 家园 【建议】这种应用,只要TRACEROUTE上

          有一个ROUTER在一个INTERFACE上overload,老萨一个星期不回家都没用!

          • 家园 现在一线苦斗的是日本一个号称排名全国第十二的

            工程师,并且至少锁定了问题,是属于SLA范围内的事情,感觉和Packet loss有关,究竟是怎么回事,还需要进一步分析。。。

            鬼子工程师说:微妙.

            兄弟听了这几天终于难得一笑,因为日语里面这两个字的发音太“微妙”了,让人有很糟糕的联想。

            • 家园 为了不让你们独占带宽使别的用户没法用,路由器会做自动调节的

              结论是:不用专用线或有带宽保证的通道没戏。

              • 家园 那是签了SLA协议的,否则那ISP可有官司打了

                问题要是ISP自身到也还好,

                就怕涉及到Telstra或Optus,

                那可跟日本的yhaoo和NTT掐架似的,

                骨头(backbone)要硬才行呵

                • 家园 不知道协议里有没有带宽保证,如果只有通畅保证依然没戏

                  一分价钱一分货,人家也不是只做一家的生意,一个通道的带宽毕竟是有限的,他能允许你有带宽峰值,但老占着带宽其他各家的生意就没法做了。

                  • 家园 又有人琢磨我们可能让Sky-X给玩了

                    因为我们一直通过Sky-X的Monitor窗口判断使用带宽,现在我们怀疑它在发送端和接受端的表示可能是不同的!

                    因为在发送端,Monitor窗口的带宽使用率为12-13MBPS的时候,linkstat的结果只有3-4Mbps,同时Skyxstat的结果倒是和窗口接近。

                    由于我们无法接入对端的Sky-X监视窗口,这下子可让我们无法证实又满腹狐疑起来。。。

                    • 家园 听上去,到目前为止,还是没能把出现瓶颈的线路或设备限定住

                      相信经过这么长时间,和那家ISP的关系应该已经成了兄弟牌打字机的那句广告词“不打不相识”。

                      到这份上它若是还不肯给内部数据,老大也许该考虑换一家ISP了。否则,排除法怎么玩?

                    • 家园 【注意】老萨进来:一个自称专家给您的Advice

                      1.通常ISP提供的频宽是不一样的,下行对上行的比例是1:5到1:10。有的讲明,有的不讲。

                      有一个简单的方法,把你的发送变接收,接收变发送。再看一下Monitor窗口。

                      2.ISP提供的频宽是指峰值,不是平均值。说不定你在trouble shooting.ISP的工程师也在加班加点限制的你的上行。

                      3.长时间的满载,会瘫痪这条线路。小日本有时候写程序一根筋到底,说不定你辛苦传送的数据冗余很大,应该对数据进行分析,可能的话应该考虑增量传输。

分页树展主题 · 全看首页 上页
/ 11
下页 末页


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

Copyright © cchere 西西河