Kapan tepatnya PMTUD dilakukan? (Penemuan MTU Path)

Dalam diskusi yang dipacu oleh pertanyaan lain di situs ini , saya menyadari bahwa saya tidak memiliki pemahaman yang kuat tentang kapan Penemuan MTU (PMTUD) Path dilakukan.

Saya tahu apa fungsinya - temukan MTU terendah di jalur dari Client ke Server).
Saya tahu bagaimana melakukannya - mengirim paket yang semakin besar dengan set bit "Don't Fragment" mereka, dan lihat seberapa besar paket yang bisa Anda lewati tanpa mendapatkan kesalahan "ICMP Need to Fragment".

Pertanyaan saya secara khusus, kapan tuan rumah melakukan PMTUD?

Saya mencari kasus tertentu. Bukan hanya sesuatu yang generik seperti "ketika tuan rumah ingin menemukan jalur MTU". Poin bonus jika Anda dapat memberikan tangkapan paket dari tuan rumah yang melakukannya, atau memberikan instruksi untuk menghasilkan tangkapan paket tersebut.

Juga, saya secara khusus mengacu pada IPv4. Saya tahu di router sementara IPv6 tidak bertanggung jawab atas fragmentasi, dan dapat membayangkan bahwa PMTUD terjadi jauh lebih umum. Tetapi untuk saat ini, saya sedang mencari contoh spesifik PMTUD di IPv4. (walaupun jika satu-satunya paket yang dapat Anda kumpulkan dari PMTUD adalah IPv6, saya masih ingin melihatnya)

Jawabannya sederhana: kapan pun tuan rumah mau. Sangat. Sesederhana itu.

Penjelasan di bawah ini mengasumsikan lingkungan IPv4-only, karena IPv6 menghilangkan fragmentasi pada router (memaksa host untuk selalu berurusan dengan fragmentasi dan penemuan MTU).

Tidak ada aturan ketat yang mengatur kapan (atau bahkan jika) suatu host melakukan Path MTU Discovery. Alasan PMTUD muncul adalah karena fragmentasi dianggap berbahaya karena berbagai alasan. Untuk menghindari fragmentasi paket, konsep PMTUD dihidupkan sebagai solusi. Tentu saja, sistem operasi yang bagus harus menggunakan PMTUD untuk meminimalkan fragmentasi.

Jadi, tentu saja, semantik yang tepat ketika PMTUD digunakan tergantung pada sistem operasi pengirim - khususnya, implementasi soket. Saya hanya dapat berbicara untuk kasus spesifik Linux, tetapi varian UNIX lainnya mungkin tidak jauh berbeda.

Di Linux, PMTUD dikendalikan oleh IP_MTU_DISCOVERopsi soket. Anda dapat mengambil statusnya saat ini dengan getsockopt(2)menentukan level IPPROTO_IPdan IP_MTU_DISCOVERopsi. Opsi ini hanya berlaku untuk SOCK_STREAMsoket ( SOCK_STREAMsoket adalah soket dua arah, berorientasi koneksi, dan dapat diandalkan; dalam praktiknya soket TCP, meskipun protokol lain dimungkinkan), dan ketika disetel, Linux akan menjalankan PMTUD persis seperti yang didefinisikan dalam RFC 1191.

Perhatikan bahwa dalam praktiknya, PMTUD adalah proses yang berkelanjutan; paket dikirimkan dengan set bit DF - termasuk paket jabat tangan 3 arah - Anda dapat menganggapnya sebagai properti koneksi (meskipun suatu implementasi mungkin bersedia menerima tingkat fragmentasi tertentu di beberapa titik dan berhenti mengirim paket dengan DF) bit diatur). Dengan demikian, PMTUD hanyalah konsekuensi dari kenyataan bahwa segala sesuatu pada koneksi tersebut sedang dikirim dengan DF.

Bagaimana jika Anda tidak mengatur IP_MTU_DISCOVER?

Ada nilai default. Secara default, IP_MTU_DISCOVERdiaktifkan di SOCK_STREAMsoket. Ini bisa dibaca atau diubah dengan membaca /proc/sys/net/ipv4/ip_no_pmtu_disc. Nilai nol berarti IP_MTU_DISCOVERdiaktifkan secara default di soket baru; bukan-nol berarti sebaliknya.

Bagaimana dengan soket tanpa koneksi?

Ini rumit karena koneksi, soket yang tidak dapat diandalkan tidak mentransmisikan kembali segmen yang hilang. Ini menjadi tanggung jawab pengguna untuk mengemas data dalam potongan berukuran MTU. Selain itu, pengguna diharapkan membuat pengiriman ulang yang diperlukan jika terjadi kesalahan pada Pesan . Jadi, intinya kode pengguna harus mengimplementasikan ulang PMTUD. Namun demikian, jika Anda siap menghadapi tantangan, Anda bisa memaksa bit DF dengan mengedarkan IP_PMTUDISC_DOflag ke setsockopt(2).

Garis bawah

• Tuan rumah memutuskan kapan (dan jika) menggunakan PMTUD
• Ketika menggunakan PMTUD, itu seperti atribut koneksi, itu terjadi terus menerus (tetapi kapan pun implementasinya bebas untuk berhenti melakukannya)
• Sistem operasi yang berbeda menggunakan pendekatan yang berbeda, tetapi biasanya soket yang dapat diandalkan dan berorientasi koneksi melakukan PMTUD secara default, sedangkan soket yang tidak dapat diandalkan dan tanpa sambungan tidak

Biasanya, jalur penemuan unit transmisi maksimum (PMTUD) terjadi setiap kali host berpikir paket dijatuhkan karena terlalu besar.

Ini mungkin sebagai respons terhadap respons ICMP yang diperlukan (tipe 3, kode 4) yang secara eksplisit menunjukkan paket dijatuhkan. Pada praktiknya, semua paket IPv4 diatur dengan set flag "jangan fragmen" (DF), sehingga paket apa pun yang melebihi MTU akan mendapat respons seperti itu. IPv6 tidak mendukung fragmentasi sama sekali.

Beberapa router atau firewall tuan rumah sering menjatuhkan semua ICMP karena administrator yang naif percaya ICMP sebagai risiko keamanan . Atau, beberapa skema agregasi tautan dapat memutus pengiriman ICMP . Mekanisme alternatif untuk menemukan MTU telah terlampaui yang tidak bergantung pada ICMP diusulkan dalam RFC4821 .

tracepathadalah alat Linux favorit saya untuk menyelidiki MTU. Berikut ini adalah contoh dari host dengan MTU 9001 di LAN, tetapi yang harus melintasi IPsec VPN untuk mencapai 10.33.32.157:

$ tracepath -n 10.33.32.157
 1?: [LOCALHOST]                                         pmtu 9001
 1:  10.1.22.1                                             0.122ms pmtu 1500
 1:  169.254.3.1                                           1.343ms pmtu 1422
 1:  10.255.254.61                                        23.790ms 
 2:  no reply
^C [this host won't return an ICMP port unreachable, so tracepath won't terminate]

Kesalahan ICMP dapat diamati dengan tcpdump:

$ sudo tcpdump -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
14:46:57.313690 IP 10.1.22.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1500), length 36
14:46:57.315080 IP 169.254.3.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1422), length 556

Penemuan MTU di-cache. Di Linux ini dapat diamati dan memerah ip(waspadalah terhadap perubahan sejak Linux 3.6 ):

$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache  expires 591sec mtu 1422
$ sudo ip route flush cache
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache

Untuk TCP, melebihi MTU dapat dihindari sebagai bagian dari pengaturan koneksi. Termasuk dalam SYN yang dikirim oleh setiap ujung adalah ukuran segmen maksimum (MSS). Header TCP (20 byte tidak termasuk opsi ) dan header IP (20 byte) berarti MSS dan MTU terkait oleh perbedaan 40 byte.

Berikut adalah contoh pengaturan koneksi antara dua host ini ketika mentransfer file besar dengan scp:

$ sudo tcpdump -p -ni eth0 'host 10.33.32.157 and tcp[13]&2 == 2'
IP 10.1.22.194.45853 > 10.33.32.157.22: Flags [S], seq 634040018, win 26883, options [mss 8961,sackOK,TS val 10952240 ecr 0,nop,wscale 7], length 0
IP 10.33.32.157.22 > 10.1.22.194.45853: Flags [S.], seq 1371736848, ack 634040019, win 26847, options [mss 1379,sackOK,TS val 10824267 ecr 10952240,nop,wscale 7], length 0

Dalam paket pertama, host lokal mengusulkan MSS 8961. Ini adalah MTU 9001 yang dikonfigurasi, kurang dari 40 byte. SYN / ACK yang dikembalikan memiliki MSS 1379, menyiratkan MTU 1419. Saya kebetulan tahu di jaringan ini host jarak jauh juga mengirim 8961, tetapi nilainya telah dimodifikasi oleh router karena ia tahu jalurnya termasuk jalur internet ( MTU 1500) overhead dari terowongan IPsec. Router ini juga memodifikasi MSS kami yang dikirim dari 8961 untuk tampil sebagai 1419 di host lain. Ini disebut penjepit MSS .

Jadi dalam arti tertentu, PMTUD terjadi setiap saat. Dalam praktiknya, ini mungkin sebenarnya tidak pernah terjadi, jika penjepitan MSS ada dan semua lalu lintas terjadi melalui TCP, atau jika tidak ada router yang memiliki MTU yang lebih kecil daripada yang dikonfigurasikan pada titik akhir. Bahkan tanpa MSS clamping, itu mungkin jarang terjadi, ketika cache berakhir.

PMTUD digunakan untuk menghitung MSS terbaik untuk sesi TCP. Salah satu contohnya adalah implementasi BGP pada router Cisco atau Juniper.

http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/routing-configuring-mtu-discovery-for-bgp-sessions.html

Terima kasih.