Son zamanlarda uzak bir siteyi 10 / 10Mbps fiberden 20 / 20Mbps fiber bağlantıya yükselttik (bodruma fiber, daha sonra bodrumdan ofise, kabaca 30 metre olan VDSL). Bu site ile merkezi bir site arasında düzenli büyük (çok-gig) dosya kopyaları vardır, bu nedenle teori, 20/20'ye olan bağlantıyı artırmanın transfer sürelerini kabaca yarıya indirmesi gerektiğiydi.
Dosyaları kopyalamak için yapılan aktarımlar için (örneğin robocopy, dosyaları herhangi bir yönde kopyalamak için kullanma ve Veeam Backup ve Recovery replikasyonu) 10 Mbps'de sınırlanır.
Yükseltmeden önce:
Yeni sürüme geçtikten sonra ( robocopy):
Neredeyse aynı (transfer süresinin uzunluğundaki farkı göz ardı edin).
Aktarımlar, bir Cisco ASA5520 ve Mikrotik RB2011UiAS-RM arasındaki bir IPSec tüneli üzerinden yapılıyor .
İlk düşünceler:
- QoS - hayır. QoS kuralları var, ancak bu akışı etkilemesi gerekenler yok. Yine de kontrol etmek için tüm kuralları birkaç dakika devre dışı bıraktım ve değişiklik yok
- Yazılım tanımlı limitler. Bu trafiğin çoğu site dışında Veeam Backup and Recovery gönderimidir, ancak burada tanımlanan sınır yoktur. Ayrıca, sadece bir düz yaptım
robocopyve tam olarak aynı istatistikleri gördüm. - Donanım kullanılamıyor. 5520'nin yayınlanan performans rakamları 225Mbps 3DES verisi ve Mikrotik sayı yayınlamıyor ancak 10Mbps'nin üzerinde olacak. Bu transfer testlerini yaparken Mikrotik yaklaşık% 25-% 33 CPU kullanımındadır. (Ayrıca, IPSec tüneli üzerinden HTTP aktarımı yapmak 20 Mbps'ye yaklaşır)
- Gecikme TCP Pencere boyutu ile birleştirildi mi? Peki siteler arasında 15ms gecikme süresi, bu yüzden en kötü durumda 32KB pencere boyutu
32*0.015maksimum 2.1MB / sn. Ek olarak, birden fazla eşzamanlı aktarım hala 10Mbps'ye kadar ekler, bu da bu teoriyi desteklemez - Belki de kaynak ve hedef boktan? Kaynak 1.6GB / sn'lik sürekli ardışık okumaları itebilir, bu yüzden değil. Hedef 200MB / sn sürekli ardışık yazma yapabilir, bu yüzden de öyle değil.
Bu çok garip bir durum. Daha önce hiç bu şekilde tezahür eden hiçbir şey görmedim.
Başka nereye bakabilirim?
Daha fazla araştırma yaparken, sorun olarak IPSec tüneline işaret ettiğinden eminim. Ben yapmacık ibret ve sitelerde iki genel IP adresleri arasındaki doğrudan bazı testler yaptı ve sonra yaptığı kesin IPSec sadece 10 Mbps iç IP adreslerini kullanarak aynı testi ve ben şifresiz internet üzerinden 20Mbps çoğaltmak mümkün ve yan.
Önceki sürümde HTTP hakkında kırmızı bir ringa balığı vardı. Bunu unutun, bu hatalı bir test mekanizmasıydı.
Xeon'un önerisine göre ve destek istediğimde ISS'im tarafından yankılandı , bu hesaplamaya dayanarak IPSec verileri için MSS'yi 1422'ye bırakmak için bir mangle kuralı oluşturdum :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
ISS'nin 1480 MTU'suna sığdırmak için. Ama ne yazık ki bu etkili bir fark yaratmadı.
Wireshark yakalamalarını karşılaştırdıktan sonra, TCP oturumu şimdi her iki uçta 1380'lik bir MSS ile pazarlık yapar (birkaç şeyi değiştirdikten ve matematiklerimin emmesi durumunda bir tampon ekledikten sonra. İpucu: muhtemelen yapar). 1380 aynı zamanda ASA'nın varsayılan MSS'sidir, bu yüzden yine de bu süre boyunca müzakere ediyor olabilir.
Trafiği ölçmek için kullandığım Mikrotik'in içindeki araçta bazı garip veriler görüyorum . Hiçbir şey olmayabilir. Filtrelenmiş bir sorgu kullandığımdan önce bunu fark etmedim ve sadece filtreyi kaldırdığımda bunu gördüm.
1394geçebildiğim en büyük MTU.
