Memecahkan throughput Metro Ethernet TCP yang rendah

14

Pengaturan

Kami telah menyewa beberapa jalur sewaan yang menampilkan diri sebagai jaringan layer 2, yaitu Anda memiliki satu pipa besar di pusat data dan situs-situs terpencil memiliki pipa yang lebih kecil. Di dalam jaringan layer 2 Anda dapat melakukan apa pun yang Anda suka. Mungkin mereka menggunakan 802.1ad untuk memberikan setiap pelanggan jaringan terpisah di dalam jaringan mereka. AFAICS sebagian besar situs terhubung melalui VDSL biasa.

Kami memutuskan untuk menempatkan router di setiap situs, dan memberikan masing-masing situs VLAN sendiri. Firewall di DC dengan demikian memiliki banyak VLAN yang ditentukan karena ada situs. Dengan demikian, setiap situs menggunakan kisaran alamatnya di VLAN-nya sendiri.

Diagram jaringan:

diagram jaringan

Masalah

Sekarang, kita dihadapkan dengan masalah throughput:

  • Menjalankan transfer FTP dari situs ke DC berfungsi dengan baik pada sekitar 10Mb / s yang merupakan kecepatan garis.
  • Menjalankan transfer FTP dari DC ke situs tidak berfungsi dengan baik pada 6Mb / s atau kurang.

Tidak masalah pihak mana yang memulai transfer. Satu-satunya hal yang konsisten adalah bahwa satu arah tidak berfungsi dengan baik. Sayang sekali itu adalah arah menuju situs karena itu akan menjadi bandwidth yang paling kita butuhkan karena kami ingin menggunakan klien terminal server.

Sekitar 10 detik setelah transfer, throughput turun. Kami melihat DUP ACK saat mengendus. Yang mungkin membuat saya menilai membatasi pada akhir penyedia ?? (Saat ini, mereka tidak memiliki petunjuk, dan saya ingin memastikan kita tidak bersalah sebelum meningkat)

CATATAN Situs jarak jauh terbatas pada 10MB entah bagaimana. Mengatur switch-to-Metro-port ke 10Mb juga tidak membantu. Bahkan itu yang terburuk (maks. 30 KB / s). Pengaturan ke 100MB berfungsi dengan baik tetapi sudah mulai menghasilkan masalah yang diuraikan. Sama untuk 1G.

Tangkapan masalah dapat diunduh di sini:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

Diagnostik

Pada gambar Anda melihat Wireshark IO Graph dengan beberapa detail kesalahan:

  • di sebelah kiri: Transfer FTP dari DC ke situs
  • di sebelah kanan: Transfer FTP dari situs ke DC

duplikat acks

Jika pihak lain yang memulai transfer (mis. Put from dc, bukannya get from remote), masalahnya tetap tidak berubah.

Tolong memanjakan saya dengan apa yang Anda pikir bisa menjadi masalah di sini.

PEMBARUAN # 1 (terintegrasi di atas)

UPDATE # 2 ( DIPERBARUI )

Ini pasti hal kontrol kemacetan.

Perhatikan bahwa dari DC ke jarak jauh kami memiliki tautan 10G-> 1G-> 100M-> 10M-> 1G. <- tidak bekerja

Di arah lain kita memiliki inversi: 1G-> 10M-> 100M-> 1G-> 10G. <- baiklah

"1G-> 10M" pertama adalah 10M "tidak terlihat" di situs jarak jauh, di mana segala sesuatu termasuk kecepatan port uplink diatur pada 1G, meskipun hanya ada 10M di belakangnya (dijual).

Namun 100Mbps di DC adalah 100Mbps nyata, antarmuka dikonfigurasi pada 100Mbps pada lapisan fisik.

Saya sekarang menggunakan iperf:

  • Tes TCP bekerja dengan baik hanya dalam satu arah (klien = DC, server = jarak jauh)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Server mendengarkan pada port TCP 5001
Ukuran jendela TCP: 85,3 KByte (default)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klien terhubung ke 192.168.x, TCP port 5001
Ukuran jendela TCP: 16.0 KByte (default)
-------------------------------------------------- ----------
[3] port 10.x lokal 38195 terhubung dengan port 192.168.x 5001
[3] 0,0- 2,0 dtk 1,44 MBytes 6,03 Mbits / dtk
[3] 2,0 - 4,0 detik 2,23 MBytes 9,37 Mbits / detik
[3] 4,0- 6,0 detik 2,28 MBytes 9,57 Mbits / detik
[3] 6,0-8,0 detik 1,88 MBytes 7,90 Mbits / detik
[3] 8,0-10,0 detik 1,00 MBytes 4,19 Mbits / detik
[3] 10.0-12.0 dtk 1.30 MBytes 5.47 Mbits / dtk
[3] 12.0-14.0 dt 688 KBytes 2.82 Mbits / dtk
[3] 14,0-16,0 detik 840 KBytes 3,44 Mbits / detik
[3] 16.0-18.0 dtk 1.03 MBytes 4.33 Mbits / dtk
[3] 18,0-20,0 dtk 1,01 MBytes 4,23 Mbits / dtk
[3] 20,0-22,0 detik 1,03 MBytes 4,33 Mbits / detik
[3] 22,0-24,0 dtk 1,18 MBytes 4,95 Mbits / dtk
[3] 24.0-26.0 detik 904 KBytes 3.70 Mbits / detik
[3] 26,0-28,0 detik 840 KBytes 3,44 Mbits / detik
[3] 28,0-30,0 detik 936 KBytes 3,83 Mbits / detik
[3] 30,0-32,0 dtk 1,09 MBytes 4,59 Mbits / dtk
[3] 32.0-34.0 dt 960 KBytes 3.93 Mbits / dtk
[3] 34.0-36.0 dtk 752 KBytes 3.08 Mbits / dtk
[3] 36,0-38,0 dtk 1,09 MBytes 4,59 Mbits / dtk
[3] 38.0-40.0 dtk 1.09 MBytes 4.59 Mbits / dtk
[3] 40.0-42.0 dtk 840 KBytes 3.44 Mbits / dtk
[3] 42,0-44,0 dtk 1,27 MBytes 5,34 Mbits / dtk
[3] 44,0-46,0 dtk 1,16 MBytes 4,85 Mbits / dtk
[3] 46,0-48,0 detik 840 KBytes 3,44 Mbits / detik
[3] 48.0-50.0 dt 960 KBytes 3.93 Mbits / dtk
[3] 50.0-52.0 dtk 1.28 MBytes 5.37 Mbits / dtk
[3] 52,0-54,0 dtk 1,09 MBytes 4,59 Mbits / dtk
[3] 54,0-56,0 detik 992 KBytes 4,06 Mbits / detik
[3] 56.0-58.0 dtk 1,00 MBytes 4,19 Mbits / dtk
[3] 58.0-60.0 dtk 1.09 MBytes 4.59 Mbits / dtk
[3] 0,0-60,2 dtk 33,9 MBytes 4,73 Mbits / dtk
[5] port 10.x lokal 5001 terhubung dengan port 192.168.x 10965
[5] 0,0-2,0 detik 1,85 MBytes 7,75 Mbits / detik
[5] 2,0 - 4,0 dtk 1,90 MBytes 7,98 Mbits / dtk
[5] 4.0-6,0 detik 1,89 MBytes 7,93 Mbits / detik
[5] 6,0-8,0 detik 1,92 MBytes 8,07 Mbits / detik
[5] 8,0-10,0 dtk 1,91 MBytes 8,02 Mbits / dtk
[5] 10.0-12.0 dtk 1,83 MBytes 7.69 Mbits / dtk
[5] 12.0-14.0 dtk 1,86 MBytes 7.78 Mbits / dtk
[5] 14,0-16,0 dtk 1,79 MBytes 7,52 Mbits / dtk
[5] 16.0-18.0 dt. 1.79 MBi 7.52 Mbits / dtk
[5] 18.0-20.0 dtk 1.89 MBytes 7.91 Mbits / dtk
[5] 20.0-22.0 dtk 1,91 MBytes 8.00 Mbits / dtk
[5] 22,0-24,0 dtk 1,88 MBytes 7,91 Mbits / dtk
[5] 24,0-26,0 dtk 1,95 MBytes 8,16 Mbits / dtk
[5] 26.0-28.0 dtk 1.90 MBytes 7.99 Mbits / dtk
[5] 28,0-30,0 dtk 1,87 MBytes 7,84 Mbits / dtk
[5] 30.0-32.0 dtk 1.85 MBytes 7.77 Mbits / dtk
[5] 32,0-34,0 dtk 1,55 MBytes 6,49 Mbits / dtk
[5] 34.0-36.0 dtk 1.92 MBytes 8.07 Mbits / dtk
[5] 36,0-38,0 dtk 1,90 MBytes 7,99 Mbits / dtk
[5] 38.0-40.0 dtk 1,84 MBytes 7.73 Mbits / dtk
[5] 40,0-42,0 dtk 1,66 MBytes 6,95 Mbits / dtk
[5] 42.0-44.0 dtk 1.92 MBytes 8.07 Mbits / dtk
[5] 44,0-46,0 dtk 1,91 MBytes 7,99 Mbits / dtk
[5] 46,0-48,0 dtk 1,90 MBytes 7,98 Mbits / dtk
[5] 48.0-50.0 dtk 1,84 MBytes 7.70 Mbits / dtk
[5] 50,0-52,0 dtk 1,93 MBytes 8.09 Mbits / dtk
[5] 52,0-54,0 dtk 1,80 MBytes 7,54 Mbits / dtk
[5] 54,0-56,0 dtk 1,83 MBytes 7,67 Mbits / dtk
[5] 56.0-58.0 dtk 1.88 MBytes 7.86 Mbits / dtk
[5] 58.0-60.0 dtk 1.85 MBytes 7.78 Mbits / dtk
[5] 0,0-60,3 detik 56,0 MBytes 7,79 Mbits / detik
  • Untuk sampai ke dasarnya, berikut adalah tes UDP dari dua host dalam VLAN yang sama namun menggunakan Koneksi Metro, 200 = jarak jauh, 201 = DC

Kami melihat hilangnya paket meningkat dengan penambahan bandwidth (ketika mendekati 10Mbps kami memiliki 0,93%, mulai menjadi kritis ... dan juga akan menjelaskan mengapa TCP mengalami masalah)

++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server mendengarkan pada port UDP 5001
Menerima datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klien terhubung ke 192.168.191.200, port UDP 5001
Mengirim datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
[4] port 192.168.191.201 lokal 61759 terhubung dengan port 192.168.191.200 5001
[ID] Bandwidth Transfer Interval
[4] 0,0-1,0 dtk 128 KBdit 1,05 Mbits / dtk
[4] 1,0-2,0 detik 128 KBytes 1,05 Mbits / detik
[4] 2,0-3,0 detik 129 KBytes 1,06 Mbits / detik
[4] 3,0 - 4,0 detik 128 KBytes 1,05 Mbits / detik
[4] 4.0- 5.0 dtk 128 KBytes 1.05 Mbits / dtk
[4] 5,0-6,0 detik 128 KBytes 1,05 Mbits / detik
[4] 6,0- 7,0 detik 128 KBytes 1,05 Mbits / detik
[4] 7,0-8,0 detik 128 KBytes 1,05 Mbits / detik
[4] 8,0-9,0 detik 128 KBytes 1,05 Mbits / detik
[4] 9.0-10.0 detik 129 KBytes 1.06 Mbits / sec
[4] 10,0-11,0 detik 128 KBytes 1,05 Mbits / detik
[4] 11.0-12.0 dtk 128 KBytes 1.05 Mbits / dtk
[4] 12,0-13,0 detik 128 KBytes 1,05 Mbits / detik
[4] 13.0-14.0 detik 128 KBytes 1.05 Mbits / detik
[4] 14,0-15,0 detik 128 KBytes 1,05 Mbits / detik
[4] 15.0-16.0 detik 128 KBytes 1.05 Mbits / detik
[4] 16.0-17.0 dt 128 KBytes 1.05 Mbits / dtk
[4] 17.0-18.0 dt 128 KBytes 1.05 Mbits / dtk
[4] 18,0-19,0 ​​detik 131 KBytes 1,07 Mbits / detik
[4] 19.0-20.0 dtk 128 KBytes 1.05 Mbits / dtk
[4] 0,0-20,0 dtk 2,50 MBtitik 1,05 Mbits / dtk
[4] Mengirim 1785 datagram
[4] Laporan Server:
[4] 0,0-20.0 dtk 2.50 MB. 1,05 Mbits / dt. 0,257 ms 0/1785 (0%)
[3] port 192.168.191.201 lokal 5001 terhubung dengan port 192.168.191.200 50749
[3] 0,0-1 1,0 detik 128 KBytes 1,05 Mbits / detik 0,285 ms 0/89 (0%)
[3] 1,0 - 2,0 detik 128 KBytes 1,05 Mbits / detik 0,313 ms 0/89 (0%)
[3] 2,0- 3,0 detik 128 KBytes 1,05 Mbits / detik 0,278 ms 0/89 (0%)
[3] 3,0 - 4,0 detik 128 KBytes 1,05 Mbits / detik 0,241 ms 0/89 (0%)
[3] 4,0-5,0 detik 128 KBytes 1,05 Mbits / detik 0,266 ms 0/89 (0%)
[3] 5,0-6,0 detik 128 KBytes 1,05 Mbits / detik 0,293 ms 0/89 (0%)
[3] 6,0- 7,0 detik 128 KBytes 1,05 Mbits / detik 0,314 ms 0/89 (0%)
[3] 7,0-8,0 detik 128 KBytes 1,05 Mbits / detik 0,280 ms 0/89 (0%)
[3] 8,0-9,0 detik 128 KBytes 1,05 Mbits / detik 0,242 ms 0/89 (0%)
[3] 9.0-10.0 dtk 129 KBytes 1.06 Mbits / dt. 0.250 ms 0/90 (0%)
[3] 10,0-11,0 detik 128 KBytes 1,05 Mbits / detik 0,275 ms 0/89 (0%)
[3] 11,0-12,0 detik 128 KBytes 1,05 Mbits / detik 0,299 ms 0/89 (0%)
[3] 12,0-13,0 detik 128 KBytes 1,05 Mbits / detik 0,327 ms 0/89 (0%)
[3] 13,0-14,0 detik 128 KBytes 1,05 Mbits / detik 0,290 ms 0/89 (0%)
[3] 14,0-15,0 dtk 128 KBytes 1,05 Mbits / dt. 0,251 ms 0/89 (0%)
[3] 15.0-16.0 detik 128 KBytes 1.05 Mbits / detik 0.275 ms 0/89 (0%)
[3] 16.0-17.0 detik 128 KBytes 1.05 Mbits / detik 0.303 ms 0/89 (0%)
[3] 17,0-18,0 detik 128 KBytes 1,05 Mbits / detik 0,333 ms 0/89 (0%)
[3] 18,0-19,0 ​​detik 128 KBytes 1,05 Mbits / detik 0,294 ms 0/89 (0%)
[3] 19.0-20.0 dt. 131 KBytes 1.07 Mbits / dt. 0,281 ms 0/91 (0%)
[3] 0,0-20.0 dtk 2.50 MB. 1,05 Mbits / dt. 0,305 ms 0/1785 (0%)

++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5m
++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server mendengarkan pada port UDP 5001
Menerima datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klien terhubung ke 192.168.191.200, port UDP 5001
Mengirim datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
[4] port 192.168.191.201 lokal 61760 terhubung dengan port 192.168.191.200 5001
[ID] Bandwidth Transfer Interval
[4] 0,0-1,0 dtk 610 KBytes 5,00 Mbits / detik
[4] 1,0- 2,0 dt 609 KBytes 4,99 Mbits / dtk
[4] 2,0 - 3,0 dtk, 610 KB, 5.00 Mbits / dtk
[4] 3,0 - 4,0 detik 609 KBytes 4,99 Mbits / detik
[4] 4.0 - 5.0 dtk. 610 kbytes 5.00 Mbits / dtk
[4] 5,0-6,0 detik 609 KBytes 4,99 Mbits / detik
[4] 6,0-7,0 detik 610 KBytes 5,00 Mbits / detik
[4] 7,0-8,0 detik 609 KBytes 4,99 Mbits / detik
[4] 8,0-9,0 detik 610 KBytes 5,00 Mbits / detik
[4] 9.0-10.0 dt 619 KBytes 5.07 Mbits / dtk
[4] 10.0-11.0 dtk 610 KBytes 5.00 Mbits / dtk
[4] 11.0-12.0 dt 609 KBytes 4.99 Mbits / dtk
[4] 12.0-13.0 dt 609 KBytes 4.99 Mbits / dtk
[4] 13,0-14,0 dtk. KB 6,0 Mbits / dtk
[4] 14,0-15,0 dt 609 KBytes 4,99 Mbits / dtk
[4] 15.0-16.0 detik 610 KBytes 5.00 Mbits / sec
[4] 16.0-17.0 dt 609 KBytes 4.99 Mbits / dtk
[4] 17.0-18.0 dtk 610 KBdetik 5.00 Mbits / dtk
[4] 18.0-19.0 dt 619 KBytes 5.07 Mbits / dtk
[4] 19,0-20,0 dt 609 KBytes 4,99 Mbits / dtk
[4] 0,0-20.0 dtk 11,9 MBytes 5.00 Mbits / dtk
[4] Mengirim 8504 datagram
[4] Laporan Server:
[4] 0,0-20,0 dtk 11,9 MBytes 4,99 Mbits / dt 0,000 ms 12/8503 (0,14%)
[4] 0,0-20,0 dt. 1 datagram diterima rusak
[3] port 192.168.191.201 lokal 5001 terhubung dengan port 192.168.191.200 50750
[3] 0,0-1 1,0 detik 606 KBytes 4,96 Mbits / detik 2,238 ms 1/423 (0,24%)
[3] 1,0-2,0 detik 610 KBytes 5,00 Mbits / detik 2,739 ms 0/425 (0%)
[3] 2,0- 3,0 dt 609 KBytes 4,99 Mbits / dt 3,089 ms 1/425 (0,24%)
[3] 3,0 - 4,0 detik 609 KBytes 4,99 Mbits / detik 3,605 ms 0/424 (0%)
[3] 4,0- 5,0 dt 607 KBytes 4,97 Mbits / dt 1,954 ms 0/423 (0%)
[3] 5.0- 6.0 dt 612 KBytes 5.01 Mbits / dt 2.666 ms 0/426 (0%)
[3] 6,0- 7,0 detik 607 KBytes 4,97 Mbits / detik 2,602 ms 0/423 (0%)
[3] 7,0-8,0 detik 612 KBytes 5,01 Mbits / detik 2,960 ms 0/426 (0%)
[3] 8,0-9,0 detik 609 KBytes 4,99 Mbits / detik 2,512 ms 0/424 (0%)
[3] 9.0-10.0 dt 619 KBytes 5.07 Mbits / dt 2.133 ms 0/431 (0%)
[3] 10,0-11,0 detik 609 KBytes 4,99 Mbits / detik 3,605 ms 1/425 (0,24%)
[3] 11.0-12.0 detik 609 KBytes 4.99 Mbits / sec 2.509 ms 0/424 (0%)
[3] 12,0-13,0 detik 610 KBytes 5,00 Mbits / detik 3,570 ms 0/425 (0%)
[3] 13,0-14,0 dt 609 KBytes 4,99 Mbits / dt 3,077 ms 1/425 (0,24%)
[3] 14,0-15,0 dt 609 KBytes 4,99 Mbits / dt 2.679 ms 0/424 (0%)
[3] 15.0-16.0 dt 609 KBytes 4.99 Mbits / dt 1.887 ms 0/424 (0%)
[3] 16.0-17.0 detik 610 KBytes 5.00 Mbits / sec 2.651 ms 0/425 (0%)
[3] 17.0-18.0 dt 609 KBytes 4.99 Mbits / sec 3.390 ms 0/424 (0%)
[3] 18.0-19.0 dt 617 KBytes 5.06 Mbits / dt 2.601 ms 0/430 (0%)
[3] 19.0-20.0 dt 612 KBytes 5.01 Mbits / dt. 3.525 ms 0/426 (0%)
[3] 0,0-20,0 dtk 11,9 MBytes 4,99 Mbits / dt 3,156 ms 3/8503 (0,035%)
[3] 0,0-20,0 dt. 1 datagram diterima rusak

++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server mendengarkan pada port UDP 5001
Menerima datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klien terhubung ke 192.168.191.200, port UDP 5001
Mengirim datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
[4] port 192.168.191.201 lokal 61761 terhubung dengan port 192.168.191.200 5001
[ID] Bandwidth Transfer Interval
[4] 0,0-1,0 detik 1,07 MBytes 9,00 Mbits / detik
[4] 1,0-2,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 2,0- 3,0 dtk 1,07 MBytes 9,00 Mbits / detik
[4] 3,0 - 4,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 4.0- 5.0 dtk 1.07 MBytes 9.00 Mbits / dtk
[4] 5,0-6,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 6,0- 7,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 7,0-8,0 detik 1,07 MBytes 9,00 Mbits / detik
[4] 8,0-9,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 9.0-10.0 dtk 1.09 MBytes 9.14 Mbits / dtk
[4] 10,0-11,0 detik 1,07 MBytes 9,00 Mbits / detik
[4] 11,0-12,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 12,0-13,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 13,0-14,0 detik 1,07 MBytes 9,00 Mbits / detik
[4] 14,0-15,0 detik 1,07 MBytes 8,98 Mbits / detik
[4] 15.0-16.0 detik 1.07 MBytes 9.00 Mbits / detik
[4] 16.0-17.0 dtk 1.07 MBytes 8.98 Mbits / dtk
[4] 17.0-18.0 dtk 1.07 MBytes 8.98 Mbits / dtk
[4] 18.0-19.0 dtk 1.09 MBytes 9.14 Mbits / dtk
[4] 19,0-20,0 dtk 1,07 MBytes 9,00 Mbits / dtk
[4] 0,0-20,0 dtk 21,5 MBytes 9,00 Mbits / dtk
[4] Mengirim 15315 datagram
[4] Laporan Server:
[4] 0,0-20,0 detik 21,3 MBytes 8,94 Mbits / detik 0,104 ms 96/15314 (0,63%) !!!!!!!!!!
[4] 0,0-20,0 dt. 1 datagram diterima rusak
[3] port 192.168.191.201 lokal 5001 terhubung dengan port 192.168.191.200 50751
[3] 0,0-1,0 detik 1,06 MBytes 8,89 Mbits / detik 2,405 ms 0/756 (0%)
[3] 1,0 - 2,0 detik 1,07 MBytes 9,00 Mbits / detik 2,308 ms 0/765 (0%)
[3] 2,0- 3,0 dtk 1,07 MBytes 9,00 Mbits / dtk 2,305 ms 0/765 (0%)
[3] 3,0 - 4,0 detik 1,07 MBytes 8,97 Mbits / detik 2,290 ms 1/764 (0,13%)
[3] 4,0-5,0 detik 1,07 MBytes 8,98 Mbits / detik 2,271 ms 1/765 (0,13%)
[3] 5,0-6,0 detik 1,07 MBytes 8,98 Mbits / detik 2,313 ms 0/764 (0%)
[3] 6,0- 7,0 detik 1,07 MBytes 9,00 Mbits / detik 2,191 ms 0/765 (0%)
[3] 7,0-8,0 detik 1,07 MBytes 8,95 Mbits / detik 2,314 ms 3/764 (0,39%)
[3] 8,0-9,0 detik 1,07 MBytes 8,98 Mbits / detik 2,232 ms 1/765 (0,13%)
[3] 9.0-10.0 dtk 1.09 MBytes 9.13 Mbits / dt 2.257 ms 0/776 (0%)
[3] 10.0-11.0 dtk 1.07 MBytes 8.98 Mbits / dt 2.365 ms 0/764 (0%)
[3] 11,0-12,0 detik 1,07 MBytes 8,98 Mbits / detik 2,301 ms 1/765 (0,13%)
[3] 12,0-13,0 detik 1,07 MBytes 8,98 Mbits / detik 2,277 ms 0/764 (0%)
[3] 13,0-14,0 detik 1,07 MBytes 9,00 Mbits / detik 2,323 ms 0/765 (0%)
[3] 14,0-15,0 detik 1,07 MBytes 9,00 Mbits / detik 2,176 ms 0/765 (0%)
[3] 15.0-16.0 detik 1.07 MBytes 8.96 Mbits / sec 2.273 ms 2/764 (0.26%)
[3] 16.0-17.0 dtk 1.07 MBytes 8.98 Mbits / dtk 2.313 ms 0/764 (0%)
[3] 17,0-18,0 detik 1,07 MBytes 8,98 Mbits / detik 2,247 ms 1/765 (0,13%)
[3] 18.0-19.0 dtk 1.09 MBytes 9.11 Mbits / sec 2.276 ms 1/776 (0.13%)
[3] 19.0-20.0 dtk 1.07 MBytes 8.97 Mbits / dtk 2.394 ms 1/764 (0.13%)
[3] 0,0-20,0 detik 21,5 MBytes 8,99 Mbits / detik 2,659 ms 11/15314 (0,072%)
[3] 0,0-20,0 dt. 1 datagram diterima rusak

++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server mendengarkan pada port UDP 5001
Menerima datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Klien terhubung ke 192.168.191.200, port UDP 5001
Mengirim datagram 1470 byte
Ukuran buffer UDP: 64.0 KByte (default)
-------------------------------------------------- ----------
[4] port 192.168.191.201 lokal 61762 terhubung dengan port 192.168.191.200 5001
[ID] Bandwidth Transfer Interval
[4] 0,0-1,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 1,0-2,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 2,0- 3,0 dtk 1,17 MBytes 9,84 Mbits / dtk
[4] 3,0 - 4,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 4,0- 5,0 dtk 1,17 MBytes 9,84 Mbits / dtk
[4] 5,0-6,0 detik 1,17 MBytes 9,83 Mbits / detik
[4] 6,0- 7,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 7,0-8,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 8,0-9,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 9.0-10.0 detik 1.19 MBytes 10.0 Mbits / detik
[4] 10,0-11,0 detik 1,17 MBytes 9,84 Mbits / detik
[4] 11,0-12,0 dtk 1,17 MBytes 9,84 Mbits / dtk
[4] 12,0-13,0 dtk 1,17 MBytes 9,83 Mbits / dtk
[4] 13.0-14.0 dtk 1.17 MBytes 9.85 Mbits / dtk
[4] 14,0-15,0 detik 1,17 MBytes 9,83 Mbits / detik
[4] 15.0-16.0 detik 1.17 MBytes 9,85 Mbits / detik
[4] 16.0-17.0 dtk 1.17 MBytes 9,83 Mbits / dtk
[4] 17,0-18.0 dtk 1,17 MBytes 9,84 Mbits / dtk
[4] 18,0-19,0 ​​dtk 1,19 MBytes 10,0 Mbits / dtk
[4] 19,0-20,0 dtk 1,17 MBytes 9,84 Mbits / dtk
[4] 0,0-20,0 detik 23,5 MBytes 9,85 Mbits / detik
[4] Mengirim 16765 datagram
[4] Laporan Server:
[4] 0,0-20.0 dtk 23,3 MBytes 9,74 Mbits / dt 3,421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 dt. 1 datagram diterima rusak
[3] port 192.168.191.201 lokal 5001 terhubung dengan port 192.168.191.200 50752
[3] 0,0-1,0 detik 1,16 MBytes 9,74 Mbits / detik 2,131 ms 0/828 (0%)
[3] 1,0 - 2,0 detik 1,17 MBytes 9,84 Mbits / detik 2,140 ms 0/837 (0%)
[3] 2,0- 3,0 dtk 1,17 MBytes 9,83 Mbits / dtk 2.099 ms 1/837 (0,12%)
[3] 3,0 - 4,0 detik 1,17 MBytes 9,84 Mbits / detik 2,113 ms 0/837 (0%)
[3] 4.0- 5.0 dtk 1,17 MBytes 9,84 Mbits / dt 2.105 ms 0/837 (0%)
[3] 5,0-6,0 detik 1,17 MBytes 9,83 Mbits / detik 2,058 ms 1/837 (0,12%)
[3] 6,0 - 7,0 detik 1,17 MBytes 9,82 Mbits / detik 2,165 ms 1/836 (0,12%)
[3] 7,0-8,0 detik 1,17 MBytes 9,84 Mbits / detik 2,156 ms 0/837 (0%)
[3] 8,0-9,0 detik 1,17 MBytes 9,82 Mbits / detik 2,135 ms 2/837 (0,24%)
[3] 9.0-10.0 dtk 1.19 MBytes 9.97 Mbits / dt 2.152 ms 2/850 (0.24%)
[3] 10,0-11,0 detik 1,17 MBytes 9,83 Mbits / detik 2,153 ms 1/837 (0,12%)
[3] 11.0-12.0 dtk 1.17 MBytes 9.84 Mbits / dt 2.127 ms 0/837 (0%)
[3] 12.0-13.0 dt 1.17 MBytes 9.83 Mbits / dt 2.136 ms 1/837 (0.12%)
[3] 13,0-14,0 detik 1,17 MBytes 9,82 Mbits / detik 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 detik 1,17 MBytes 9,83 Mbits / detik 2,061 ms 1/837 (0,12%)
[3] 15.0-16.0 dtk 1.17 MBytes 9.84 Mbits / dt 2.045 ms 0/837 (0%)
[3] 16.0-17.0 dtk 1.17 MBytes 9.82 Mbits / dt. 2.203 ms 1/836 (0.12%)
[3] 17.0-18.0 dtk 1.17 MBytes 9.84 Mbits / dt 2.165 ms 0/837 (0%)
[3] 18,0-19,0 ​​dtk 1,17 MBytes 9,83 Mbits / dt. 2,154 ms 1/837 (0,12%)
[3] 19.0-20.0 dt 1.19 MBytes 9.98 Mbits / dt 2.209 ms 0/849 (0%)
[3] 0,0-20,0 dtk 23,5 MBytes 9,84 Mbits / dtk 2.548 ms 13/16764 (0,078%)
[3] 0,0-20,0 dt. 1 datagram diterima rusak

Pertanyaan sebenarnya tetap:

Kami tidak berlangganan secara berlebihan tautan DC karena berada pada 100Mbps dan tidak dapat mengirim lebih dari 100Mbps. Namun situs jarak jauh berada di 10Mbps.

  • Apakah buffer di sisi jauh meluap dan menjatuhkan paket?
  • Apakah traffic traffic penyedia melakukan sesuatu terhadap traffic? (Apakah traffic yang datang dari node lain dipengaruhi oleh traffic traffic ISP atau hanya traffic yang masuk node (dari luar)) ...... Anda mengerti maksud saya?

Mengapa TCP tidak bisa menangani semua itu sendiri?

Perbarui # 3 Saya sekarang telah menggunakan skenario berikut:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Berikut ini adalah paket loss di arah remote DC->: (tes UDP iperf 9 Mbps)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

Arah lainnya baik-baik saja. Namun , ketika menjalankan uji TCP, arah-> DC jarak jauh tidak jauh lebih baik daripada arah jarak jauh-> DC- (sekitar 5Mbps) .......

Saya tidak yakin kita mencapai bagian bawah ini.

ethernet  tcp  troubleshooting  packet-analysis  metro-ethernet 
— Marki
sumber
Tidak benar-benar jawaban tetapi rekomendasi saya adalah untuk mendapatkan JDSU dan menguji rangkaian ini. Jika mereka mengatur Anda, maka pastikan Anda mendapatkan pengaturan, "regulator", kebijakan ... Jika mereka memiliki CBS kecil maka mereka membatasi lalu lintas TCP Anda pada dasarnya ukuran jendela yang lebih kecil. Anda dapat menguji ini melalui tes back-2-back. Saya telah menghabiskan banyak waktu melakukan bolak-balik dengan penyedia di sirkuit L2 untuk mengetahui bahwa ketika kita mendapatkan tes sirkuit baru, itu benar-benar tidak hanya di CIR tetapi di CBS ...
— matak
Juga, hanya catatan singkat. Throughput TCP yang dilihat dari OS Windows vs Linux akan berbeda karena pengaturan TCP akan berbeda; yaitu. ukuran buffer, algoritma, dll. Anda dapat melihat pengaturan untuk mesin Linux Anda melalui sysctltidak yakin tentang Windows ... mungkin netsh. Jika saya akan menebak apa yang salah dengan sirkuit Anda, saya akan mengatakan bahwa CPE di situs spoke diatur dengan CBS yang lebih besar daripada sisi hub ... yang biasanya sebaliknya. Sekali lagi, JDSU akan menyepak bola kembali ke mereka atau membiarkan Anda memfokuskan kembali pada apa masalahnya.
— matak
@matak Mengapa tidak membuat jawaban tambahan atas komentar Anda? Ketika kita berbicara tentang pembentuk, di mana saya membayangkan perangkat ini? Di DC ada konektor RJ45 tanpa CPE (terlihat). Di situs terpencil saya kebanyakan memiliki modem VDSL dan beberapa jenis router yang mampu MPLS. Tidak yakin apakah mereka menggunakan MPLS. Dan selanjutnya arah lalu lintas mana yang membentuk pembentuk? Kita dapat membentuk ingress @ spoke (dari situs), egress @ spoke (menuju cloud ISP), ingress @ hub (dari DC), egress @ hub (menuju cloud ISP) ... Saya mungkin kehilangan gambaran besar. Bisakah Anda menggambarkan mengapa masalah dengan CBS akan menjadi masalah?
— Marki

Jawaban:

20

Merujuk obrolan Stack Exchange kami ...

Singkatnya, Anda perlu mengontrol ketidakcocokan kecepatan di kedua sisi tautan Ethernet metro Anda ... Saya menggambar ulang diagram Anda demi kejelasan ... Catatan 1

Diagram Masalah

  • DC (diperlihatkan dalam warna hijau) transisi dari 10GE ke 100M dengan sangat cepat ... ini adalah transisi kecepatan 100 kali lipat, dan Anda biasanya perlu mengimplementasikan beberapa bentuk qo (seperti shaping) untuk mengurangi transisi besar tersebut. Lihat bagian bawah jawaban ini untuk bukti bahwa DC perlu membentuk (per situs) ...
  • Transisi sisi jarak jauh dari 1GE ke 10M CIR dengan sangat cepat ... ini lagi, adalah transisi kecepatan 100 kali lipat. Membentuk atau solusi qos lainnya biasanya diperlukan.
  • Tampaknya juga ada ketidakcocokan kecepatan antara UNI DC (100M) dan UNI jarak jauh (10M); ini sendiri meminta solusi manajemen bandwidth per-situs.

FYI, jika penyedia Anda mengimplementasikan layanan yang sesuai dengan MEF , mereka tidak membentuk, mereka adalah pemolisian . Lalu lintas TCP cenderung berkinerja lebih baik dengan pembentukan .

Kebutuhan akan QoS Anda sendiri

Anda tampaknya mempertanyakan perlunya qo , jadi saya akan mengutip dari MEF "Memahami Carrier Ethernet Throughput" Whitepaper , halaman 9 ... dengan cara meninjau, pelanggan dalam Gambar 2 MEF Whitepaper memiliki situasi yang lebih baik daripada Anda. .. mereka membeli 50Mbps CIR, tetapi UNI mereka dikirimkan pada 1GE ... situs jarak jauh Anda memiliki 10Mbps CIR pada UNI 1GE.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Menanggapi pertanyaan TCP lainnya dalam edit ...

Kami tidak berlangganan berlebihan tautan DC karena itu pada 100Mbps dan tidak dapat mengirim lebih dari 100Mbps ...

Saya tidak setuju, Anda dapat mengirim microburst s di 10GE karena DC Anda memiliki tautan 10GE, tetapi metro UNI adalah 100Mbps. Satu pertanyaan terbuka adalah berapa banyak buffer yang Anda miliki pada switch Enterasys LAN Anda (Switch A) ketika Anda melakukan transisi dari 10GE ke 100M.

Mengapa TCP tidak bisa menangani semua itu sendiri?

TCP menangani berbagai hal dengan memperlambat ketika ia melihat packet loss ... ia benar-benar melambat (dan mungkin membatalkan koneksi) untuk packet loss yang serius. Jadi, TCP melakukan apa yang seharusnya ... sebagai insinyur jaringan, tujuan Anda adalah membangun jaringan dengan kondisi yang membuat TCP bahagia.

Pertanyaan TCP lainnya dari obrolan

Marki berkata : Saya tidak mengerti apa yang dijatuhkan di mana dan oleh siapa dan mengapa dan mengapa TCP tidak hanya menangani fakta bahwa ada (nyata) 100Mb di satu ujung, dan hanya 10Mbps di ujung lainnya.

Mengenai kebutuhan TCP untuk buffering, dan konsekuensi dari tidak ada buffer :

Fakta nomor 1: TCP perlu buffering untuk transisi kecepatan karena dirancang sebagai sistem kontrol umpan balik .

Menggunakan analogi mengemudi: sebagai pengemudi yang baik kita selalu menyisakan ruang beberapa detik antara kita dan mobil di depan kita; dalam beberapa hal, ruang antara mobil kira-kira analog dengan buffer jaringan. Jika orang di depan kita menginjak rem ketika seekor binatang berlari di depan mereka, ruang di antara mobil kita (semoga) mencegah kita dari menabrak mobil mereka. Kami meninggalkan ruang karena mata kami membutuhkan waktu untuk melihat lampu rem, kaki kami untuk bereaksi, dan rem untuk menghilangkan panas yang cukup; mata kita memberi kita sistem kontrol umpan balik visual.

Demikian juga, ketika sesi FTP meledak pada 10GE, ledakan lalu lintas bisa mencapai 4MB (dalam kasus Anda) karena ukuran jendela skala TCP sebelum soket harus berhenti dan menunggu TCP ACK. Sementara itu jika arus lalu lintas 10GE tiba-tiba mencapai "Fast Ethernet", TCP perlu secara bertahap melambat. Buffer yang dalam pada peralatan jaringan memungkinkan TCP untuk menjatuhkan paket yang jauh lebih sedikit ketika membuat transisi kecepatan; Namun, jika Anda tidak memiliki buffer, Anda mungkin bisa menjatuhkan 99% dari jendela TCP 4MB ketika itu diperketat dari 10GE ke 100M. Pikirkan kehilangan 99% yang parah itu sebagai soket TCP crash; TCP bereaksi terhadap hilangnya paket yang relatif bertahap. TCP bereaksi jauh lebih mudah ditebak terhadap kehilangan paket yang parah, Catatan 3 .

Untuk pertanyaan mengapa Anda tidak harus menggunakan Metro Ethernet CIR asimetris dengan 100M di DC dan 10M di remote, tanyakan pada diri Anda pertanyaan retoris "siapa yang buffering yang lalu lintas 100Mbps meledak ketika hits NID Ethernet 10Mbps murah yang metro Anda penyedia -ethernet memberi Anda? "... (petunjuk: tidak ada yang buffering).

Jika tidak ada yang menahan transisi kecepatan besar (lihat Catatan 2), maka titik-titik tersebut adalah tempat potensial untuk sesekali menghentikan lalu lintas.

Apa yang dijatuhkan oleh siapa :

Lalu lintas keluar turun dari DC

Ketika lalu lintas TCP meninggalkan pusat data, ada tiga tempat yang bisa dijatuhkan:

  • Di D1: karena switch LAN jarang memiliki buffering yang cukup dalam untuk transisi kecepatan 100: 1
  • Di D2: jika NID pernah menegosiasikan tautan UNI dengan kecepatan lebih tinggi daripada CIR ; bukan itu masalahnya sekarang, jadi saya tidak berharap tetes di sana.
  • Pada D3: untuk semua alasan saya baru saja menjelaskan tentang asimetris Metro Ethernet CIR .

Ketika lalu lintas TCP pergi ke pusat data ...

Lalu lintas masuk menurun ke DC

  • Di D4: karena Anda memiliki UNI 1GE dan CIR 10M ; ini adalah kasus patologis D2 yang saya sebutkan di atas.

Cara mengurangi ketidakcocokan kecepatan:

Contoh solusi EVPL : EVPL dengan solusi EVC point-to-point

  • Dalam topologi yang diaktifkan seperti ini, EVPL dengan EVC titik ke titik dari DC ke setiap Remote mungkin merupakan pilihan terbaik Anda (lihat diagram di atas). Ini akan menerapkan CIR individu untuk setiap EVC. Catatan: semua panduan QoS lain dalam jawaban ini berlaku ... yaitu hindari transisi kecepatan besar Catatan 2 tanpa menguji apakah peralatan Anda akan menangani itu dengan cukup baik.
  • Atau, Anda dapat mempertimbangkan membeli layanan metroe yang memiliki tingkat simetris antara DC dan jarak jauh; meskipun saya akan mengakui bahwa itu mungkin bukan panduan paling praktis.
  • FYI, solusi klasik untuk masalah ini untuk layanan yang diarahkan adalah untuk membeli router yang mendukung pembentukan pada kecepatan yang diperlukan dan kemudian bentuk lalu lintas metroe Anda ke CIR yang sesuai (per situs jarak jauh). FYI, sisi jarak jauh bisa lolos dengan router yang cukup kecil, karena itu hanya input 1GE dan 10Mbps CIR ... Berbulan-bulan yang lalu, ketika kita berbicara tentang desain layanan ini, saya merekomendasikan rute jika Anda merasa nyaman dengan teknologi. ...

  • Jika Anda tidak memiliki uang tambahan untuk dibelanjakan dan tidak dapat merekayasa ulang layanan metro-ethernet Anda, Anda dapat memijat ketidakcocokan kecepatan secara lebih bertahap. Saya belum pernah melakukan ini, tetapi pada prinsipnya Anda dapat mencoba untuk membuat transisi kecepatan 10 ke 1, bukan 100 ke 1 (yang saat ini Anda miliki di DC dan remote):

    • Alih-alih membeli router untuk membentuk remote ke 10M, Anda bisa mencoba memaksa UNI remote untuk melakukan negosiasi otomatis pada 100M alih-alih 1GE; GigabitEthernet membutuhkan semua pin pada kabel Cat5e , sehingga Anda dapat secara efektif memaksanya ke 100M dengan RJ45 mod-plug yang hanya menghubungkan pin 1, 2, 3 dan 6.
    • Alih-alih membeli router untuk membentuk DC hingga 100M, gunakan Enterasys Anda untuk mengawasi tautan 10GE ke 1GE saat mengirim lalu lintas ke arah tautan 100M

Menganalisis iperfhasil Anda ...

Ada dua poin penting yang perlu diingat iperf(semua informasi berdasarkan iperfversi 2):

Dengan demikian, output berikut ini menunjukkan bahwa mesin DC (dalam iperf -cmode) terhubung ke iperfserver di situs jarak jauh (192.168.x) dan mendorong data dari DC (100M UNI) ke situs jarak jauh (10M UNI) ...

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

Output di atas jelas menunjukkan masalah pada DC ke arah jauh; kita harus mengharapkan untuk melihat 9Mbps atau lebih ketika semuanya bekerja dengan baik (yaitu Anda mengharapkan setidaknya 90% dari kapasitas - 10Mbps di situs jarak jauh). Sekarang, mari kita lihat lalu lintas ke arah yang berlawanan (ketika iperfmendorong data dari situs jarak jauh ke DC) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Anda dapat mengirim sekitar 80% dari kapasitas CIR jarak jauh Anda, tetapi itu masih kurang dari yang saya harapkan.

Ilustrasi ketidakcocokan kecepatan DC (10Gbps -> 100Mbps)

marki berkata : Jangan lupa, masalahnya hanya muncul dengan sendirinya saat alirannya 100Mb-> 10Mb, bukan sebaliknya.

Masalahnya menunjukkan dirinya di kedua arah, tetapi iperfgejalanya tampaknya lebih buruk di DC -> arah jauh. Lihat analisis saya dari iperfoutput di atas.

Untuk membuat ini konkret, mari kita lihat pcap FTP Anda ketika mendorong file dari server DC DC Anda (130.1.6.4) ke situs jarak jauh (192.168.191.2). Transfer dari sisi metro ethernet 100M menjadi terbatas pada beberapa titik selama transfer. Anda dapat melihat ini jika Anda melihat dc-to-remote_remote-side.pcapngpcap, dan memfilterexpert.message contains "segment not captured"

masukkan deskripsi gambar di sini

Catatan Akhir :

Catatan 1 Saya memilih nilai CBS 25KB per 1Mbps MetroEthernet CIR; ini adalah rasio umum yang digunakan oleh penyedia ... YMMV
Note 2 Aturan pribadi saya: "besar" adalah transisi kecepatan yang secara signifikan lebih besar dari transisi kecepatan 10: 1
Catatan 3Saya tidak bisa memberikan angka yang sulit untuk apa yang bisa dan tidak terlalu banyak packet loss untuk TCP. Jika kerugiannya cukup buruk untuk aplikasi Anda menderita, maka itu terlalu banyak. Aturan pribadi saya: Ketika berhadapan dengan jaringan perusahaan kabel sepenuhnya di bawah kendali saya sendiri, setiap kehilangan paket (tidak disengaja) terlalu banyak. Yang mengatakan, ada beberapa model sakelar yang memotong sudut pada buffering; sakelar-sakelar ini kadang-kadang dapat menjatuhkan paket ... ini merupakan panggilan penilaian, apakah Anda harus hidup dengan masalah tersebut atau membeli sakelar yang lebih baik. FYI: Tidak selalu jelas, tetapi TCP secara berkala meningkatkan laju transmisi soket untuk memastikan bahwa ia mendapatkan throughput sebanyak mungkin; banyak implementasi TCP tahu bahwa mereka berjalan terlalu cepat ketika mereka melihat paket drop.

— Mike Pennington
sumber
Perhatikan bahwa kecepatan PHY DC (port Metro Ethernet) sudah mencapai 100 MB. Tapi saya juga tidak bisa mengirim dengan 100M karena sisi lain maks 10 MB ... Saat ini masih belum jelas di mana tepatnya harus dibentuk. Oh dan maksud Anda "gejala iperf tampaknya lebih buruk di DC -> arah jauh "?
— Marki
Saya memperbarui jawabannya, ya "remote -> DC" adalah kesalahan ketik pada jawaban aslinya.
— Mike Pennington
Saya setuju dengan Mike di sini, tergantung pada siapa penyedia Anda, jika Anda bertanya kepada mereka, mereka akan memberi tahu Anda garis tarif pada akhirnya, membuatnya sesuai dengan antarmuka fisik Anda yang tergantung pada metro-E Anda. Adapun WHERE ke QoS, saya akan lakukan di titik masuk terbesar Anda, jadi perangkat 10Gb Anda, sebelum mereka naik ke perangkat hulu yang lebih kecil. Saya menghabiskan lebih banyak waktu firewall dan routing daripada beralih, tetapi mudah-mudahan Mike dapat menguatkan klaim saya!
— AL
3
@ MikePennington - Pemblokiran jalan keluar karena ketidakcocokan kecepatan adalah sesuatu yang sering saya jumpai dengan tautan microwave P2P. Jawaban bagus, banyak informasi bagus di posting Anda. Terima kasih!
— matak
1
Juga periksa ketidakcocokan dupleks, ini dapat menyebabkan masalah kecepatan uni-directional.
— cpt_fink
2

Sementara membahas masalah ini sangat menarik, ISP sementara itu mulai bertukar modem DSL di situs yang berbeda dengan merek lain. Beberapa masalah fragmentasi paket kata mereka. Dan hei, 9,5 Mbps di kedua arah tanpa masalah atau pengaturan khusus.

— Marki
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.