최근 10 / 10Mbps 파이버에서 20 / 20Mbps 파이버 링크로 원격 사이트를 업그레이드했습니다 (지하실에서 파이버, 지하실에서 사무실까지의 VDSL, 약 30 미터). 이 사이트와 중앙 사이트간에 정기적으로 큰 (멀티 기가) 파일 사본이 있으므로 이론상 20/20으로 링크를 늘리면 전송 시간이 대략 절반으로 줄어 듭니다.
파일 복사 전송 (예 : robocopy어느 한 방향으로 파일을 복사하거나 Veeam Backup and Recovery 복제)을 사용하는 경우 10Mbps로 제한됩니다.
업그레이드하기 전에 :
업그레이드 후 ( robocopy) :
거의 동일합니다 (전송 시간의 차이를 무시하십시오).
전송은 Cisco ASA5520과 Mikrotik RB2011UiAS-RM 사이의 IPSec 터널을 통해 수행됩니다 .
첫 생각 :
- QoS-아닙니다. QoS 규칙은 있지만이 흐름에 영향을 미치지는 않습니다. 어쨌든 확인하기 위해 몇 분 동안 모든 규칙을 비활성화했으며 변경 사항은 없습니다.
- 소프트웨어 정의 한계. 이 트래픽의 대부분은 오프 사이트로 배송되는 Veeam Backup and Recovery입니다. 그러나 여기에 정의 된 제한은 없습니다. 또한 방금 똑바로
robocopy똑같은 통계를 보았습니다. - 하드웨어를 사용할 수 없습니다. 5520의 발표 된 성능 수치는 225Mbps의 3DES 데이터이며 Mikrotik은 숫자를 공개하지 않지만 10Mbps 이상입니다. 이러한 전송 테스트를 수행 할 때 Mikrotik의 CPU 사용량은 약 25 % -33 %입니다. (또한 IPSec 터널을 통한 HTTP 전송은 20Mbps에 가깝습니다)
- TCP 창 크기와 결합 된 대기 시간? 사이트 간 대기 시간은 15ms이므로 최악의 경우 32KB 창 크기
32*0.015는 최대 2.1MB / 초입니다. 또한 여러 동시 전송은 여전히 최대 10Mbps를 추가하므로이 이론을 지원하지 않습니다. - 어쩌면 소스와 대상이 모두 똥일까요? 음, 소스는 1.6GB / sec의 지속적인 순차 읽기를 수행 할 수 있으므로 그렇지 않습니다. 대상은 200MB / sec의 지속적인 순차 쓰기를 수행 할 수 있으므로 그렇게하지는 않습니다.
이것은 매우 이상한 상황입니다. 나는 전에 이런 식으로 어떤 것도 분명히 보지 못했습니다.
다른 곳을 볼 수 있습니까?
추가 조사에서 IPSec 터널을 문제로 지적하고 있습니다. 나는 인위적인 예제를 만들어 사이트에 두 개의 공용 IP 주소 사이에 직접 몇 가지 검사를 한 다음 한 정확한 는 IPSec 만의 10Mbps를 내부 IP 주소를 사용하여 동일한 테스트를, 나는 암호화되지 않은 인터넷을 통해 20Mbps의를 복제 할 수 있었고, 측면.
이전 버전에는 HTTP에 대한 청어가있었습니다. 이것을 잊어라, 이것은 잘못된 테스트 메커니즘이었다.
제온의 제안에 따라 내가 지원을 물었을 때 내 ISP에 의해 echo'd, 나는 1422로의 IPSec 데이터에 대한 MSS을 드롭하는 압착 롤러 규칙을 설정 한 - 이 계산에 따라 :
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에 적합합니다. 그러나 아쉽게도 효과적인 차이는 없습니다.
wireshark 캡처를 비교 한 후 TCP 세션은 이제 양쪽 끝에서 1380의 MSS를 협상합니다 (몇 가지 사항을 조정하고 수학이 짜증나는 경우 버퍼를 추가 한 후 힌트 : 아마 그렇습니다). 어쨌든 1380은 ASA의 기본 MSS이기도합니다.
트래픽을 측정하는 데 사용했던 Mikrotik 내부 도구에 이상한 데이터 가 있습니다. 아무것도 될 수 없습니다. 필터링 된 쿼리를 사용하면서 이전에는 이것을 알지 못했으며 필터를 제거했을 때만 이것을 보았습니다.
1394내가 통과 할 수 있었던 가장 큰 MTU입니다.
