हमने हाल ही में एक दूरस्थ साइट को 10 / 10Mbps फाइबर से 20 / 20Mbps फाइबर लिंक से अपग्रेड किया है (यह तहखाने के लिए फाइबर है, फिर VDSL बेसमेंट से कार्यालय तक, लगभग 30 मीटर)। इस साइट और एक केंद्रीय साइट के बीच नियमित रूप से बड़ी (मल्टी-गिग) फ़ाइल प्रतियां हैं, इसलिए सिद्धांत यह था कि लिंक को 20/20 तक बढ़ाना चाहिए और हस्तांतरण समय को आधा करना चाहिए।
फ़ाइलों की प्रतिलिपि के लिए स्थानांतरण के लिए (जैसे robocopy
किसी भी दिशा में फ़ाइलों की प्रतिलिपि बनाने के लिए उपयोग करना, या वीम बैकअप और पुनर्प्राप्ति की प्रतिकृति) वे 10Mbps पर कैप किए जाते हैं।
उन्नयन से पहले:
उन्नयन के बाद ( robocopy
):
लगभग समान (स्थानांतरण के समय की लंबाई में अंतर को अनदेखा करें)।
एक सिस्को ASA5520 और एक मिकरोटिक RB2011UiAS-RM के बीच एक IPSec सुरंग के ऊपर स्थानान्तरण किया जा रहा है ।
पहले विचार:
- क्यूओएस - नोप। QoS नियम हैं लेकिन कोई भी इस प्रवाह को प्रभावित नहीं करना चाहिए। मैंने वैसे भी जांच करने के लिए कुछ मिनटों के लिए सभी नियमों को निष्क्रिय कर दिया, और कोई बदलाव नहीं हुआ
- सॉफ्टवेयर परिभाषित सीमाएँ। इस ट्रैफ़िक का अधिकांश भाग वीईएम बैकअप और रिकवरी शिपिंग ऑफ-साइट है, लेकिन इसमें कोई सीमा निर्धारित नहीं है। इसके अतिरिक्त, मैंने अभी एक सीधा किया
robocopy
और ठीक उसी आँकड़े को देखा। - हार्डवेयर सक्षम नहीं। खैर, 5520 के प्रकाशित प्रदर्शन आंकड़े 225Mbps के 3DES डेटा हैं, और मिकरोटिक संख्याओं को प्रकाशित नहीं करता है, लेकिन यह 10Mbps से अधिक होगा। इन स्थानांतरण परीक्षणों को करते समय मिकरोटिक लगभग 25% -33% CPU उपयोग में है। (इसके अलावा, IPSec सुरंग के ऊपर एक HTTP स्थानांतरण करने से 20Mbps के करीब हिट होता है)
- टीसीपी विंडो आकार के साथ संयुक्त विलंबता? खैर यह साइटों के बीच 15ms विलंबता है, इसलिए यहां तक कि सबसे खराब स्थिति 32KB खिड़की का आकार
32*0.015
अधिकतम 2.1MB / सेकंड है। इसके अतिरिक्त कई समवर्ती स्थानांतरण अभी भी केवल 10Mbps तक जुड़ते हैं, जो इस सिद्धांत का समर्थन नहीं करता है - शायद स्रोत और गंतव्य दोनों बकवास हैं? वैसे स्रोत 1.6GB / sec की निरंतर अनुक्रमिक पठन को आगे बढ़ा सकता है, इसलिए ऐसा नहीं है। गंतव्य 200 एमबी / सेकंड निरंतर अनुक्रम लिख सकता है, इसलिए ऐसा नहीं है।
यह बहुत ही विषम स्थिति है। मैंने पहले कभी इस तरह से कुछ भी प्रकट नहीं किया है।
मैं और कहाँ देख सकता हूँ?
आगे की जांच पर, मैं IPSec सुरंग को समस्या के रूप में इंगित करने में आश्वस्त हूं। मैंने एक विवादित उदाहरण बनाया और साइटों पर दो सार्वजनिक आईपी पते के बीच सीधे कुछ परीक्षण किए, और फिर आंतरिक आईपी पते का उपयोग करके सटीक परीक्षण किया, और मैं अनएन्क्रिप्टेड इंटरनेट पर 20Mbps और IPSec पर केवल 10Mbps दोहराने में सक्षम था पक्ष।
पिछले संस्करण में HTTP के बारे में एक लाल हेरिंग था। इस बारे में भूल जाओ, यह एक दोषपूर्ण परीक्षण तंत्र था।
Xeon के सुझाव के अनुसार और मेरे ISP द्वारा गूँजने पर जब मैंने उनसे समर्थन मांगा, तो मैंने IPSec डेटा के लिए MSS को 1422 तक ड्रॉप करने के लिए एक मैंगेल नियम बनाया है - इस गणना के आधार पर :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
ISP के 1480 MTU के अंदर फिट होने के लिए। लेकिन अफसोस कि इससे कोई फर्क नहीं पड़ा।
वायरशार्क कैप्चर की तुलना करने के बाद, टीसीपी सत्र 1380 के एमएसएस पर अब दोनों छोरों पर बातचीत करता है (कुछ चीजों को ट्विक करने और मेरे मैथ्स बेकार होने की स्थिति में एक बफर जोड़ने के बाद। संकेत: यह शायद होता है)। 1380 वैसे भी एएसए का डिफ़ॉल्ट एमएसएस है, इसलिए हो सकता है कि यह पूरे समय इस पर बातचीत कर रहा हो।
मैं Mikrotik के अंदर टूल में कुछ अजीब डेटा देख रहा हूं जिसका उपयोग मैं ट्रैफ़िक को मापने के लिए कर रहा हूं। यह कुछ भी नहीं हो सकता है। जब मैंने फ़िल्टर की गई क्वेरी का उपयोग कर रहा था, तो मैंने इसे पहले नोटिस नहीं किया था, और मैंने केवल यह देखा था जब मैंने फ़िल्टर हटा दिया था।
1394
सबसे बड़ा MTU है जिसे मैं प्राप्त करने में सक्षम था।