वास्तव में PMTUD कब किया जाता है? (पथ MTU खोज)


21

इस साइट पर अन्य प्रश्नों से प्रेरित होने वाली चर्चाओं में , मैंने महसूस किया है कि जब पथ MTU डिस्कवरी (PMTUD) का प्रदर्शन किया जाता है , तो मुझे इसकी ठोस समझ नहीं है ।

मुझे पता है कि यह क्या करता है - क्लाइंट से सर्वर तक एक पथ पर सबसे कम एमटीयू की खोज करें)।
मुझे पता है कि यह कैसे होता है - अपने "डोंट फ़्रैगमेंट" बिट सेट के साथ उत्तरोत्तर बड़े पैकेट भेजें, और देखें कि "ICMP नीड टू फ़्रैगमेंट" त्रुटि प्राप्त किए बिना आप कितने बड़े पैकेट प्राप्त कर सकते हैं।

मेरा प्रश्न विशेष रूप से तब है, जब कोई होस्ट PMTUD का प्रदर्शन करेगा?

मैं विशिष्ट मामलों की तलाश कर रहा हूं। न केवल कुछ सामान्य जैसे "जब कोई होस्ट MTU पथ की खोज करना चाहता है"। बोनस अंक यदि आप किसी होस्ट के एक पैकेट कैप्चर को प्रदान कर सकते हैं, या ऐसे पैकेट कैप्चर को उत्पन्न करने के लिए निर्देश प्रदान कर सकते हैं।

इसके अलावा, मैं विशेष रूप से IPv4 की बात कर रहा हूं। मुझे पता है कि IPv6 क्षणिक रूटर्स विखंडन के लिए जिम्मेदार नहीं हैं, और यह कल्पना कर सकते हैं कि PMTUD बहुत अधिक सामान्यतः होता है। लेकिन अभी के लिए, मैं IPv4 में PMTUD के विशिष्ट उदाहरणों की तलाश कर रहा हूं। (हालाँकि अगर एकमात्र पैकेट कैप्चर आप PMTUD के साथ IPv6 में रख सकते हैं, तो मैं अभी भी इसे देखना पसंद करूंगा)


क्या PMTUD सबसे कम समर्थित MTU से सबसे अधिक किया जाता है? या क्या पीएमटीयूड का प्रदर्शन करने वाला उपकरण पहले सबसे बड़े एमटीयू की कोशिश करता है और फिर बड़े वेतन वृद्धि से कदम बढ़ाता है जब तक कि पैकेट गुजरता नहीं है और फिर छोटे वेतन वृद्धि में कदम रखता है, फिर अंतिम निर्धारण होने तक आगे और पीछे बारी करता है?
cpt_fink

@ cpt_fink, कुछ रणनीतियाँ हैं। ICMP फ्रैग्मेंटेशन नीडेड संदेश के आधुनिक कार्यान्वयन में ICMP पेलोड में ही लिंक का MTU शामिल है जिसके लिए विखंडन की आवश्यकता थी। इससे यह आसान हो जाता है, क्योंकि शुरुआती होस्ट को तुरंत पता चल जाता है कि एमटीयू क्या है। पुराने कार्यान्वयन को सही MTU का उपयोग करने के लिए विभिन्न रणनीतियों का उपयोग 'खोज' के लिए करना है। उन रणनीतियों को धारा 5 में RFC1191 में उल्लिखित किया गया है। वे अधिक सामान्य रूप से खोज करने के लिए 'सामान्य' MTU की तालिका का उपयोग करने के लिए स्वचालित रूप से IP न्यूनतम (576) से डिफ़ॉल्ट रूप से होते हैं (RFC1191 धारा 7.1 देखें)।
एडी

2
यह एक दिलचस्प सवाल है। मैं PMTUD पर कुछ खुदाई कर रहा था और यह पाया। हालांकि यह पुराना है, मैंने जवाब देने का फैसला किया क्योंकि मेरे पास एक ही सवाल था और शोध के कुछ घंटों के बाद मैं बहुत ही अच्छे उत्तर के साथ आ सकता था (मुझे लगता है)। यदि संभव हो तो मैं कल एक पैकेट कैप्चर के साथ अपने जवाब को अपडेट और सपोर्ट करने की कोशिश करूंगा।
फ़िलिप गोनक्लेव्स

जवाबों:


15

उत्तर सरल है: जब भी मेजबान प्रसन्न होता है। वास्तव में। यह इत्ना आसान है।

नीचे दिया गया स्पष्टीकरण IPv4- केवल वातावरण को मानता है, क्योंकि IPv6 राउटर में विखंडन के साथ दूर करता है (मेजबान को हमेशा विखंडन और MTU खोज से निपटने के लिए मजबूर करता है)।

ऐसा कोई भी सख्त नियम नहीं है जो होस्ट (या भले ही) होस्ट MTU डिस्कवरी करता है। PMTUD का कारण यह है कि विखंडन को विभिन्न कारणों से हानिकारक माना जाता है। पैकेट विखंडन से बचने के लिए, PMTUD की अवधारणा को वर्कअराउंड के रूप में जीवन में लाया गया था। बेशक, एक अच्छा ऑपरेटिंग सिस्टम को विखंडन को कम करने के लिए PMTUD का उपयोग करना चाहिए

इसलिए, स्वाभाविक रूप से, जब PMTUD का उपयोग किया जाता है, तो सटीक शब्दार्थक प्रेषक के ऑपरेटिंग सिस्टम पर निर्भर करता है - विशेष रूप से, सॉकेट कार्यान्वयन। मैं केवल लिनक्स के विशिष्ट मामले के लिए बोल सकता हूं, लेकिन अन्य UNIX वेरिएंट शायद बहुत अलग नहीं हैं।

लिनक्स में, PMTUD को IP_MTU_DISCOVERसॉकेट विकल्प द्वारा नियंत्रित किया जाता है। आप getsockopt(2)स्तर IPPROTO_IPऔर IP_MTU_DISCOVERविकल्प को निर्दिष्ट करके इसकी वर्तमान स्थिति को पुनः प्राप्त कर सकते हैं । यह विकल्प SOCK_STREAMकेवल सॉकेट्स के लिए मान्य है (एक SOCK_STREAMसॉकेट एक दो-तरफ़ा, कनेक्शन-उन्मुख, विश्वसनीय सॉकेट है; व्यवहार में यह एक टीसीपी सॉकेट है, हालांकि अन्य प्रोटोकॉल संभव हैं), और जब सेट किया जाता है, तो लिनक्स पीएमटीयूडी प्रदर्शन करेगा जैसा कि आरएफसी में परिभाषित है। 1191।

ध्यान दें कि व्यवहार में, PMTUD एक सतत प्रक्रिया है; पैकेट को डीएफ बिट सेट के साथ भेजा जाता है - जिसमें 3-वे हैंडशेक पैकेट शामिल हैं - आप इसे कनेक्शन संपत्ति के रूप में सोच सकते हैं (हालांकि एक कार्यान्वयन कुछ बिंदु पर विखंडन की एक निश्चित डिग्री को स्वीकार करने और डीएफ के साथ पैकेट भेजने से रोकने के लिए तैयार हो सकता है। बिट सेट)। इस प्रकार, PMTUD इस तथ्य का एक परिणाम है कि उस कनेक्शन पर सब कुछ DF के साथ भेजा जा रहा है।

यदि आप सेट नहीं करते हैं तो क्या होगा IP_MTU_DISCOVER?

डिफ़ॉल्ट मान है। डिफ़ॉल्ट रूप से, सॉकेट IP_MTU_DISCOVERपर सक्षम है SOCK_STREAM। इसे पढ़कर या बदलकर पढ़ा जा सकता है /proc/sys/net/ipv4/ip_no_pmtu_disc। शून्य मान का अर्थ है कि IP_MTU_DISCOVERनए सॉकेट में डिफ़ॉल्ट रूप से सक्षम; एक गैर-शून्य का मतलब विपरीत है।

कनेक्शन रहित सॉकेट के बारे में क्या?

यह मुश्किल है क्योंकि कनेक्शन रहित, अविश्वसनीय कुर्सियां ​​खोए हुए खंडों को फिर से नहीं जमा करती हैं। एमटीयू के आकार के विखंडू में डेटा को पैक करना उपयोगकर्ता की जिम्मेदारी बन जाती है। साथ ही, उपयोगकर्ता से यह अपेक्षा की जाती है कि वह संदेश की बहुत बड़ी त्रुटि के मामले में आवश्यक प्रतिधारण कर सकता है । तो, अनिवार्य रूप से उपयोगकर्ता कोड को PMTUD को फिर से लागू करना होगा। फिर भी, यदि आप चुनौती के लिए तैयार हैं, तो आप IP_PMTUDISC_DOध्वज को पास करके DF बिट को बाध्य कर सकते हैं setsockopt(2)

तल - रेखा

  • PMTUD का उपयोग करने के लिए (और अगर) मेजबान फैसला करता है
  • जब यह PMTUD का उपयोग करता है, तो यह एक कनेक्शन विशेषता की तरह है, यह निरंतर होता है (लेकिन किसी भी बिंदु पर कार्यान्वयन ऐसा करने से रोकने के लिए स्वतंत्र है)
  • अलग-अलग ऑपरेटिंग सिस्टम अलग-अलग तरीकों का उपयोग करते हैं, लेकिन आमतौर पर, विश्वसनीय, कनेक्शन-उन्मुख सॉकेट्स डिफ़ॉल्ट रूप से पीएमटीयूडी करते हैं, जबकि अविश्वसनीय, कनेक्शन-रहित सॉकेट नहीं करते हैं

4

आमतौर पर, पथ अधिकतम संचरण इकाई की खोज (PMTUD) तब होती है जब एक मेजबान को लगता है कि एक पैकेट बहुत बड़ा होने के कारण गिरा दिया गया था।

यह आवश्यक हो सकता है ICMP विखंडन के जवाब में (टाइप 3, कोड 4) प्रतिक्रिया स्पष्ट रूप से इंगित करती है कि पैकेट गिरा दिया गया था। विशिष्ट अभ्यास में सभी IPv4 पैकेट "डोन्ट फ़्रेग्मेंट" (DF) ध्वज सेट के साथ सेट किए जाते हैं, इसलिए MTU से अधिक का कोई भी पैकेट इस तरह की प्रतिक्रिया को हटा देगा। IPv6 विखंडन का समर्थन नहीं करता है।

कुछ राउटर या होस्ट फायरवॉल सभी ICMP को अक्सर गिरा देते हैं क्योंकि एक भोले प्रशासक का मानना ​​है कि ICMP एक सुरक्षा जोखिम है । या, कुछ लिंक एकत्रीकरण योजनाएं ICMP डिलीवरी को तोड़ सकती हैं । MTU की खोज के लिए एक वैकल्पिक तंत्र को पार कर लिया गया है जो RFC4821 में प्रस्तावित ICMP पर निर्भर नहीं करता है ।

tracepathMTU जांच के लिए मेरा पसंदीदा लिनक्स उपकरण है। यहां LAN पर एक 9001 MTU के साथ एक मेजबान से एक उदाहरण है, लेकिन जिसे IPsec VPN को 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]

ICMP त्रुटियों के साथ देखा जा सकता है 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

MTU खोजों को कैश किया जाता है। लिनक्स में इसे देखा जा सकता है और इसके साथ फ्लश किया जा सकता है ip( लिनक्स 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

टीसीपी के लिए, कनेक्शन सेटअप के भाग के रूप में MTU से अधिक बचा जा सकता है। प्रत्येक छोर से भेजे गए SYN में शामिल एक अधिकतम खंड आकार (MSS) है। टीसीपी हेडर ( विकल्प को छोड़कर 20 बाइट्स ) और आईपी हेडर (20 बाइट्स) का मतलब है कि एमएसएस और एमटीयू 40 बाइट्स के अंतर से संबंधित हैं।

यहाँ एक बड़ी फ़ाइल को स्थानांतरित करते समय इन दोनों मेजबानों के बीच कनेक्शन सेटअप का एक उदाहरण दिया गया है 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

पहले पैकेट में, स्थानीय होस्ट 8961 का एमएसएस प्रस्तावित करता है। यह कॉन्फ़िगर किया गया 9001 MTU, 40 बाइट्स से कम है। लौटे SYN / ACK में 1379 का एक MSS है, जो 1419 के MTU से मिलता है। मुझे पता है कि इस नेटवर्क में रिमोट होस्ट भी 8961 भेजा गया था, लेकिन मूल्य को राउटर द्वारा संशोधित किया गया है क्योंकि यह रास्ता जानता है जिसमें एक इंटरनेट पथ शामिल है। MTU 1500) IPsec सुरंग से एक ओवरहेड। इस राउटर ने हमारे भेजे गए MSS को दूसरे होस्ट में 1419 के रूप में प्रदर्शित करने के लिए संशोधित किया। इसे MSS क्लैम्पिंग कहा जाता है ।

तो एक मायने में, PMTUD हर समय हो रहा है। व्यवहार में, यह वास्तव में कभी नहीं हो सकता है, अगर एमएसएस क्लैम्पिंग की जगह है और सभी ट्रैफ़िक टीसीपी पर हो रहे हैं, या यदि राउटर में से कोई भी एमटीयू से छोटा नहीं है जो एंडपॉइंट पर कॉन्फ़िगर किया गया है। एमएसएस क्लैंपिंग के बिना भी यह शायद ही कभी हो सकता है, जब कैश समाप्त हो जाता है।


-3

PMTUD का उपयोग TCP सत्रों के लिए सर्वोत्तम MSS की गणना के लिए किया जाता है। एक उदाहरण सिस्को या जुनिपर रूटर्स पर बीजीपी कार्यान्वयन है।

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

धन्यवाद।


2
मेरा मानना ​​है कि उनका मतलब था "यह कब शुरू होता है?"।
जॉर्डन हेड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.