五千年(敝帚自珍)

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

共:💬152 🌺15
分页树展主题 · 全看首页 上页
/ 11
下页 末页
  • 家园 【求助】不灵了,请弟兄们帮忙

    已经快二十四小时没睡了,萨被一个问题折腾得晕头转向,但至今依然没有办法,彷徨之中忽然想起一计。。。

    前两天斑竹区的“红丸案”不知道大伙儿晓得不晓得?

    哦,听说了?那咱再说就不算泄密了哈。

    前两天老铁忽然挂牌,说感冒了 -- 真感冒假感冒谁知道,有个兵部尚书说城主好像不是感冒,是让雪太傅的豹子给吓着了。。。这位尚书第二天就不见了,这两天倒出来了,就是一听豹子就表情怪异。。。

    好了,咱不说了,这事儿起居注上都有,话说老铁病了,烧得胡言乱语,怕他胡改程序大伙儿一着急,就给他张榜招贤求医,求救于西河各路豪杰,一时英杰毕至,加勒比超人是兔子休克疗法,煮酒正熟是要用大斧劈开老铁的脑袋,剔除风涎。。。这俩有弑君倾向的大夫现在还在赵括那儿喝茶呢。最后是原深州团练使,神仙驴举荐的著名兽医老票揭榜,一个放血疗法老铁就生龙活虎了。看人家老票现在升太医院正,锦袍赐紫金鱼袋,何等威风阿。。。

    得,咱也贴榜招贤吧,如果河里有哪位朋友对下面这个问题有所研究,能拉兄弟一把,砸锅卖铁也不敢忘您的大恩大德阿。。。不过,作为同行切磋切磋,无疑也是会互有启发,不一定必求解决问题么。

    言归正传。

    老萨日前接到一个项目,负责在处于两国的两个办公室之间建立一个新的网络连接,这两个办公室我们称为Office1 和Office2(我在Office2),要求是一个小时加密传递7.6GB的文件 -- 搞IT的算算吧,这简直是要命的条件,加上TCP,IPsec,Overhead,最后计算结果需要传递速度20mbps左右,如果用国际专线价格就是天文数字。

    为此,我做的设计是采用带有SLA的InternetVPN,两端分别用同一家ISP的专线联入Internet,各用一台Cisco 3845路由器处理路由和建立IPsec Tunnel,形成加密通道。因为Latency达到了150ms,为了解决一个Session数据传递的上限制约,3845路由器后加装两台Sky-X XH45 作为加速器。Sky-X后面则是防火墙(并作IP地址的NAT),防火墙后为数据终端,Office1的数据终端为IBM Mainframe Host主机,Office2的数据终端为Win2000 Server服务器。

    图如下:

    点看全图

    但是测试中发现问题 -- 从Office2向Office1作传递时可以达到22.9Mbps,但从Office1向Office2作传递时,只有3Mbps。

    这就同样宽的一条路上,从东往西单行可以跑八车道,从西往东单行只能跑一车道一样,不合逻辑么!

    所以萨这段时间对此百般调查,设计测试,至今没有进展。

    1。由于问题出自单向,所以可以排除是线路问题,或者Sky-X,Cisco3845处理能力问题。

    2。已经检查Host和Server,确认没有Shaping的设置,流量没有控制。同时双方Tcp Window Size都是64K,不该出现一方可以跑,一方不能跑的情况。同时,传递时双方CPU/Memo Utilization都在正常范围。

    3。来回路由确认是统一的。

    4。传递时Sky-X监视可以看到数据,因此可以断定数据已经被改为XTP数据包,也就是说不存在Sky-X失灵没有工作的问题。

    5。关联设备端口均为100M, Full Duplex设置,且没有CRC错误提示。

    如此,真有些山穷水尽的感觉。现在已经通知Office1在主机和FW间加Sniffer,来过滤检验数据,与此同时,向大家求助,看有没有处理过类似问题的朋友能提供些宝贵经验。谢过谢过。

    有一个现象值得注意。

    我在监视Sky-X数据流画面时,注意到同样是传递一个文件,从Office2向Office1传递的时候,为连续波峰,从Office1向Office2传递的时候,为间断的波峰,但原因,没有能够判断出来,请看下面的两辐参考图。

    点看全图

    Office2向Office1传递,可以看到连续曲线。

    点看全图

    Office1向Office2传递,曲线为间断。

    百思不得其解,侯教于各位河友,有指教切磋者不胜感谢。。。

    关键词(Tags): #Sky-X#VPN#带宽
    • 家园 是不是office1的mtu经过ipsec处理后超过了1500

      是不是office1的mtu经过cisco3845的ipsec处理后超过了1500,导致丢包

      呵呵。如果是这个那就简单了。。把mainframe的mtu调小应该就ok了

      看图只能瞎猜,呵呵,作为同行,真希望老萨把结果原因大白天下

    • 家园 好像终于找到了Root

      简直让人想骂 -- 他X的!

      好了,在等确认,不过,心里总算有了一点放松,可能结果出来还是不能让人十分满意,但至少会是一个很让人安慰的结果吧。

      也就是说可以满足用户要求的结果。

      问题,很可能在几天以前就被解决了,我们一直在对着空气作战。直到昨天晚上依然毫无进展,灰心之极想看看表,却发现因为电池没电了,已经十点多我还以为刚七点呢。看了手表我忽然灵光一闪。。。

      等结果出来再说吧。唉,先歇一歇吧,这些天他X简直不是人过的日子。

      敌营十八年怎么说?

      曙光在前头,曙光在前头。。。

      看自己写的内容也觉得是有些胡说八道,跟喝多了差不多。

      确实,现在的状态和喝多了的确差不多。

    • 家园 futher more

      if your transmit not require realtime, write a program to do the syn at your night time(network load).

      We use to do that for source code syn between U.S and china

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


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

Copyright © cchere 西西河