- नोड X के बाद अनुरेखण मार्ग में तारे क्यों दिखाई देते हैं?
- सेवा काम नहीं करती है, और नोड X पर ट्रेसआउट टूट जाता है - क्या इसका मतलब नोड X में कोई समस्या है?
- विंडोज और यूनिक्स के साथ एक ही निशान अलग-अलग परिणाम क्यों दिखाते हैं?
- ट्रेस रूट एक विशेष नोड पर बड़ी देरी क्यों दिखाता है?
- इंटरनेट के माध्यम से ट्रेस करने पर ट्रेस मार्ग "ग्रे" पते क्यों दिखाता है?
- राउटर मेरे द्वारा वांछित पते के साथ ट्रेसआउट का जवाब क्यों नहीं दे रहा है?
- ट्रसाउट कुछ "गलत" डोमेन नाम क्यों दिखाता है?
- ट्रेसिंग मार्ग के निष्कर्ष को हम जो चाहते हैं उससे अधिक बार सहज रूप से अपेक्षित होने से अलग क्यों है?
ट्रेसिंग रूट के साथ नेटवर्क इंजीनियरों और प्रशासकों को दो श्रेणियों में विभाजित किया गया है: नियमित रूप से खुद को और उनके आसपास के लोगों को पूछने और उन्हें जवाब देने में हिचकिचाहट।
यह विषय उपरोक्त प्रश्नों के उत्तर प्रदान
नहीं करता है । या लगभग नहीं। लेकिन वह यह सोचने के बारे में सुझाव देता है कि क्या उन्हें पूछा जाना चाहिए, और यदि हां, तो कब और किससे।
परिवहन मार्ग के साथ संबंध के बारे में, रिचर्ड नसेवे स्टीनबर्गेन ने NANOG-47 (2009) सम्मेलन में एक रिपोर्ट की, जिसके बारे में मैं सभी इच्छुक पक्षों को अध्ययन के लिए सलाह देता हूं।
ट्रेसरआउट (पीडीएफ, 222 केबी) (अंग्रेजी में, निश्चित रूप से, भाषा) के
साथ एक व्यावहारिक गाइड (सही ढंग से) समस्या निवारण ।
मैं यहां विवरणों (जो इसे पढ़ना चाहते हैं) को नहीं बताऊंगा, मैं केवल उन तर्कों और निष्कर्षों के एक समूह पर ध्यान केंद्रित करूंगा, जो एक रोने में मदद करने से पहले ध्यान में रखना अच्छा होगा "मेरे पास एक ट्रेस है जो दिखाता है ..."
( ) — . , , , , . , . , , .
कुछ तथ्य (विस्तार में जाने के बिना)
- नेटवर्क से गुजरने वाले पैकेट में देरी के कई कारक हैं: क्रमबद्धता, बफरिंग, वितरण। प्रत्येक कारक आपके बारे में सोचने से अधिक जटिल है।
- ट्रेसआउट जो देरी आपको दिखाता है वह और भी जटिल है: राउटर प्रक्रिया पैकेट पारगमन पैकेट की तुलना में पूरी तरह से अलग तरीके से खुद को संबोधित करते हैं। यह परिस्थिति विलंब मानों की विशिष्ट प्रकृति की ओर ले जाती है जो ट्रेसआउट हमें दिखाता है। यह इस बात का पालन नहीं करता है कि कोई उनके द्वारा निर्देशित नहीं किया जा सकता है, लेकिन उन्हें पढ़ने में सक्षम होना चाहिए।
- इंटरनेट ट्रैफ़िक लगभग हमेशा क्लाइंट से सर्वर और सर्वर से क्लाइंट तक अलग-अलग दिशाओं में जाता है। ट्राइसाउट हमेशा दोनों दिशाओं में कुल देरी दिखाता है, और ट्रेस - केवल एक दिशा में।
- ट्रेस मार्ग पर कई इंटरफेस (राउटर) के साथ डिवाइस पर स्रोत पते का संकेत उस इंटरफ़ेस की पसंद को प्रभावित नहीं करता है जिसमें से अनुरोध भेजे जाएंगे। और यह प्रभावित करता है - रिटर्न पथ की पसंद पर जिसके साथ उत्तर प्रेषित होते हैं। उनका ट्रेस आउटपुट में दिखाई नहीं देता है, लेकिन इस तरह से समानांतर रिटर्न मार्गों के लिए देरी के अंतर को मापना संभव है।
- इंटरनेट बैकबोन पर कहीं भी L3-बैलेंसिंग का उपयोग करने से अलग-अलग तरीकों से एक ही ट्रेस के भीतर अलग-अलग पैकेट को मजबूर करने की संभावना है। इस तरह के व्यवहार से निष्कर्ष की व्याख्या करना मुश्किल हो जाता है, जिसे हर कोई सही ढंग से नहीं पढ़ सकता है।
- ट्रेस मार्ग का जवाब देते समय, आधुनिक राउटर RFC1812 के खंड 4.3.2.4 की आवश्यकताओं का पालन नहीं करते हैं, जिसके लिए यह आवश्यक है कि ICMP उत्तरों के स्रोत आईपी पते को आउटगोइंग इंटरफ़ेस के पते पर सेट किया जाए। इसके बजाय, उन्होंने इसे उस इंटरफ़ेस के पते के बराबर सेट किया जिसमें ट्रेसआउट अनुरोध प्राप्त हुआ था (TTL = 1 के साथ पैकेट)। हालांकि, अगर यह आसपास का दूसरा रास्ता था, तो ट्रेसी रूट का निष्कर्ष पढ़ना बहुत कठिन होगा।
- बैकबोन नेटवर्क के अंदर स्विच करने वाले एमपीएलएस की उपस्थिति (आज यह किसी भी स्वाभिमानी बड़े प्रदाता के साथ मामला है) ट्रेसआउट की प्रतिक्रियाओं को प्रेषित करने का एक सहज ज्ञान युक्त तरीका और देरी की गणना करने के लिए एक भी कम स्पष्ट तरीका की ओर जाता है।
कुछ सबसे महत्वपूर्ण निष्कर्ष (मेरी रचनात्मक समझ के साथ)
- एक ट्राइसाउट इतनी सरल चीज नहीं है जितना लगता है; आपको इसका उपयोग करने में सक्षम होने की आवश्यकता है। और इसके लिए आपको यह समझने की आवश्यकता है कि यह कैसे काम करता है।
- अधिकांश प्रशासक और सेवा इंजीनियर, सामान्य उपयोगकर्ताओं का उल्लेख नहीं करने के लिए, समझ में नहीं आता है और यह नहीं जानते कि कैसे। यह स्थिति बहुत बार झूठे अलार्म, गलत निदान आदि की ओर ले जाती है।
- ट्रिसिरूट से त्रिस्रुतु संघर्ष। विंडोज पर मानक ट्रैसर्ट उपयोगिताओं और लिनक्स पर ट्रेसरूटे को अलग-अलग तरीके से लागू किया जाता है और विभिन्न परिणाम उत्पन्न कर सकते हैं। विंडोज ICMP भेजता है और लिनक्स UDP भेजता है, ट्रेस मार्ग पर फ़ायरवॉल में अलग-अलग प्रोटोकॉल के लिए अलग-अलग फ़िल्टरिंग सेटिंग्स हो सकती हैं।
- ट्रेस परिणामों की व्याख्या के लिए अनुभव और त्वरित बुद्धि की आवश्यकता होती है। ऐसा होता है कि महत्वपूर्ण निष्कर्ष केवल अनुमान लगाकर बनाया जा सकता है, अप्रत्यक्ष डेटा पर भरोसा करते हुए, जबकि अन्य बिल्कुल भी नहीं हैं, लेकिन केवल "सबसे अधिक संभावना" के लिए सटीक हैं।
कुल मिलाकर
अगर आप ग्राहक हैं
Tracout निष्कर्ष के साथ, प्रदाताओं, इंटीग्रेटर्स, वेंडर्स, कॉर्पोरेट हेल्प डेस्क आदि के लिए तकनीकी समर्थन न करें, जब तक कि आप इस सवाल के जवाब के बारे में पूरी तरह सुनिश्चित न हों कि "मैं इस तरह से ट्रेसिंग की व्याख्या क्यों करता हूं?" सबसे कम, आप अपने गलत संस्करण की शुद्धता के अनुभवहीन सहायक कर्मचारियों को मना सकते हैं, जिसके परिणामस्वरूप वे गलत जगह पर समस्या को खोदने के लिए जाएंगे।
यदि आपको सेवा (सब कुछ काम करता है) के साथ समस्याएं नहीं दिखती हैं, लेकिन आप अनुरेखण मार्ग आउटपुट में कुछ पसंद नहीं करते हैं, तो अलार्म बढ़ाने से पहले सावधानी से सोचें। यह बहुत संभावना है कि आप केवल निष्कर्ष का गलत अर्थ निकाल रहे हैं। बहुत बार, एक समस्या का न्याय करने के लिए एक अनुरेखण मार्ग का उपयोग किया जा सकता है। और अगर वास्तव में कोई समस्या है, तो आमतौर पर ट्रेसआउट के बिना प्रदर्शित करना आसान होता है।
यदि आप एक कलाकार हैं
ट्रेसआउट की वापसी के किसी और की व्याख्या से कभी भी मूर्ख मत बनो। अपने स्वयं के सिर के साथ सोचें (हमेशा आपका स्वागत है - आपकी टोपी)। सामान्य तौर पर, अगर समस्या के बारे में संदेश ट्रेस वापस लेने से शुरू होता है, तो यह एक निश्चित संकेत है कि इससे पहले कि आप कुछ भी करें, नीचे दी गई जानकारी व्यक्तिगत रूप से दोहराई जानी चाहिए।
पढ़ें रिचर्ड की प्रस्तुति समस्या निवारण के लिए मुख्य साधन के रूप में ट्रान्सिंगआउट का उपयोग करते समय सावधानी बरतें: व्याख्या में गलती करना बहुत आसान है, जानकारी अक्सर स्पष्ट निष्कर्ष के लिए पर्याप्त नहीं है। यदि संभव हो तो ट्रेसआउट के रीडिंग की तुलना अन्य उपलब्ध डेटा से करें, यदि संभव हो तो इसे केवल अतिरिक्त या ड्राफ्ट जानकारी के रूप में उपयोग करें।