Network Troubleshooting Methodology - The Systematic Approach

उपलब्ध भाषाएँ:

नेटवर्क समस्या निवारण पद्धति: व्यवस्थित दृष्टिकोण

क्यों मेथोलोजी मामले

समस्या: डेटाबेस एप्लिकेशन "धीमे" है। नेटवर्क टीम सर्वर टीम को दोषी ठहराती है। सर्वर टीम नेटवर्क को दोषी ठहराती है। इस बीच, उपयोगकर्ताओं को निराश कर दिया जाता है, और घंटों को परिपत्र डीबगिंग में बर्बाद कर दिया जाता है।

समाधान: रूट कारणों की पहचान करने के लिए सबूतों का उपयोग करने वाले समस्या निवारण के लिए एक व्यवस्थित, वैज्ञानिक दृष्टिकोण।

हाफजार्ड समस्या निवारण की लागत: बर्बाद समय, गलत फिक्स कि असली समस्याओं का सामना करना पड़ता है, टीमों के बीच उंगली इशारा, और उपयोगकर्ता के अनुभव में गिरावट.

परिचय: वैज्ञानिक विधि नेटवर्किंग के लिए लागू

नेटवर्क समस्या निवारण मूल रूप से वैज्ञानिक विधि में एक व्यायाम है:

अवलोकन लक्षण और डेटा इकट्ठा
एक परिकल्पना मूल कारण के बारे में
परिकल्पना का परीक्षण नैदानिक उपकरण के साथ
परिणाम विश्लेषण और परिकल्पना की पुष्टि या अस्वीकार
एक फिक्स लागू करें पुष्टिकृत रूट कारण पर आधारित
सत्यापित समस्या हल हो जाती है

यह लेख नेटवर्क समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है जो आम नुकसान को रोकता है जैसे:

पुष्टि पूर्वाग्रह (केवल सबूत है कि अपने प्रारंभिक अनुमान का समर्थन करने के लिए देख)
निदान के बिना यादृच्छिक परिवर्तन ("स्प्रे और प्रार्थना" दृष्टिकोण)
रूट कारणों के बजाय लक्षणों को ठीक करना
क्या कोशिश की जा रही है के बिना परिपत्र debugging

पांच प्रमुख प्रश्न

तकनीकी निदान में गोताखोर से पहले, इन पांच महत्वपूर्ण सवालों का जवाब दें ताकि आपकी जांच क्षेत्र को संकीर्ण किया जा सके:

प्रश्न 1: हाल ही में क्या बदल गया?

कॉन्फ़िगरेशन परिवर्तन? नया हार्डवेयर? सॉफ्टवेयर अद्यतन? टोपोलॉजी संशोधन?

परिवर्तन प्रबंधन लॉग की जाँच करें
हाल ही में कॉन्फ़िगरेशन प्रबंधन प्रणाली में प्रतिबद्ध है
पूछो: "क्या यह कल काम कर रहा है?

↓

प्रश्न 2: कौन प्रभावित है?

एक उपयोगकर्ता? एक इमारत? क्या? केवल विशिष्ट अनुप्रयोग?

एक उपकरण: समान रूप से एक स्थानीय मुद्दा (NIC, केबल, विन्यास)
एक सबनेट: गेटवे, डीएचसीपी, या स्विच मुद्दा
हर कोई: कोर इंफ्रास्ट्रक्चर, आईएसपी, या व्यापक मुद्दे
विशिष्ट अनुप्रयोग: अनुप्रयोग सर्वर, फ़ायरवॉल नियम, या DNS

↓

प्रश्न 3: क्या यह लगातार या आंतरायिक है?

हर समय क्या होता है? केवल कुछ घंटों के दौरान? यादृच्छिक घटना?

स्थिर: हार्ड विफलता (केबल कट, गलत विन्यास, डाउन सर्विस)
समय आधारित: व्यावसायिक घंटों के दौरान भीड़, निर्धारित प्रक्रियाएं
Intermittent/Random: डुप्लेक्स बेमेल, असफल हार्डवेयर, आंतरायिक लिंक

↓

प्रश्न 4: क्या आप इसे फिर से पेश कर सकते हैं?

क्या आप मांग पर समस्या को ट्रिगर कर सकते हैं?

हाँ: निदान करने में बहुत आसान (हाइपोथेसिस का परीक्षण कर सकते हैं)
नहीं: निगरानी / लॉगिंग सेट करें और पुनरावृत्ति के लिए प्रतीक्षा करें

↓

प्रश्न 5: अन्य साइड क्या देखें?

कनेक्शन के दोनों सिरों की जाँच करें

ग्राहक परिप्रेक्ष्य बनाम सर्वर परिप्रेक्ष्य
स्रोत बनाम गंतव्य पर पैकेट कैप्चर
सममित रूटिंग? भेजने के लिए विभिन्न पथ बनाम प्राप्त करते हैं?

ओएसआई मॉडल आधारित नैदानिक दृष्टिकोण

OSI मॉडल समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है। परत 1 (भौतिकी) से ऊपर की ओर काम करें, या लेयर 7 (Application) से नीचे की ओर, लक्षणों के आधार पर।

नीचे-अप दृष्टिकोण (लेयर 1 → लेयर 7)

कब उपयोग करें: पूर्ण कनेक्टिविटी हानि, कोई लिंक प्रकाश या भौतिक परत लक्षण

परत 1: भौतिक

जांच: केबल जुड़े? पर लिंक रोशनी? फाइबर स्वच्छ?
कमान: show interfaces, ethtool eth0
के लिए देखो: CRC त्रुटियों, टकराव, देर से टकराव, runts, दिग्गजों

↓

परत 2: डेटा लिंक

जाँच करें: सही VLAN? पोर्ट सक्षम? एसटीपी अवरुद्ध?
कमान: show mac address-table, show spanning-tree
के लिए देखो: MAC flapping, STP टोपोलॉजी परिवर्तन, VLAN mismatches

↓

परत 3: नेटवर्क

चेक: डिफ़ॉल्ट गेटवे पिंग कर सकते हैं? रूटिंग टेबल सही?
कमान: ping, traceroute, show ip route
के लिए देखो: लापता मार्ग, गलत अगले हॉप, रूटिंग loops

↓

परत 4: परिवहन

चेक: टीसीपी कनेक्शन स्थापित कर सकते हैं? फायरवॉल अवरुद्ध बंदरगाह?
कमान: telnet host port, netstat -an, पैकेट कैप्चर
के लिए देखो: TCP retransmissions, शून्य खिड़कियां, RST पैकेट

↓

परत 5-7: सत्र / प्रस्तुति / आवेदन

चेक: DNS निराकरण? आवेदन जवाब देना? प्रमाणीकरण कार्य?
कमान: nslookup, dig, curl -v
के लिए देखो: DNS विफलताओं, अनुप्रयोग त्रुटियों, टाइमआउट मुद्दों

शीर्षडाउन दृष्टिकोण (लेयर 7 → लेयर 1)

कब उपयोग करें: अनुप्रयोग-विशिष्ट समस्याएं जहां बुनियादी कनेक्टिविटी मौजूद है

उदाहरण: "मैं इंटरनेट ब्राउज़ कर सकता हूं, लेकिन मैं कंपनी SharePoint साइट तक पहुंच नहीं सकता।

परत 7 (Is SharePoint सेवा चल रहा है? क्या आप आईपी को सही करने के लिए DNS को हल करना चाहते हैं?

निर्णय पेड़: क्या यह परत 1, 2, या 3 है?

यह पता लगाने के लिए कि कौन सी परत विफल है, इस त्वरित नैदानिक पेड़ का उपयोग करें:

क्या आप स्थानीय होस्ट कर सकते हैं (127.0.0.1)?

नहीं

समस्या: ऑपरेटिंग सिस्टम / सॉफ्टवेयर अंक

टीसीपी / आईपी स्टैक कार्य नहीं कर रहा है। ओएस सेवाओं की जाँच करें, नेटवर्क ड्राइवरों को पुनर्स्थापित करें।

Yes

क्या आप अपने आईपी पते को पिंग कर सकते हैं?

↓ NO

समस्या: परत 1/2 - स्थानीय नेटवर्क इंटरफ़ेस

एनआईसी अक्षम, गलत ड्राइवर, केबल unpluged। जांच: ip link show या डिवाइस मैनेजर

↓ YES

क्या आप डिफ़ॉल्ट गेटवे को पिंग कर सकते हैं?

↓ NO

समस्या: परत 1/2 - स्थानीय नेटवर्क

चेक: भौतिक केबल, स्विच पोर्ट स्टेटस, VLAN असाइनमेंट, ARP टेबल

↓ YES

क्या आप आईपी पते से दूरस्थ होस्ट कर सकते हैं?

↓ NO

समस्या: परत 3 - रूटिंग

चेक: रूटिंग टेबल, फायरवॉल नियम, एसीएल। उपयोग traceroute यह पता लगाने के लिए कि पैकेट कहाँ रुकते हैं

↓ YES

क्या आप DNS को हल कर सकते हैं?

↓ NO

समस्या: DNS विन्यास

चेक: DNS सर्वर सेटिंग्स, DNS सर्वर उपलब्धता, फ़ायरवॉल अवरुद्ध पोर्ट 53

↓ YES

क्या आप आवेदन पोर्ट (टेलनेट होस्ट पोर्ट) तक पहुंच सकते हैं?

↓ NO

समस्या: फायरवॉल / पोर्ट ब्लॉकिंग

चेक: फायरवॉल नियम, सुरक्षा समूह, पोर्ट पर सुनवाई सेवा

↓ YES

नेटवर्क ठीक है - आवेदन परत मुद्दा

समस्या स्वयं अनुप्रयोग, प्रमाणीकरण या अनुप्रयोग विन्यास के साथ है

अलगाव तकनीक

जब आपके पास जड़ के कारण के बारे में एक परिकल्पना होती है, तो इन अलगाव तकनीकों का उपयोग इसकी पुष्टि या अस्वीकार करने के लिए करें:

1. अवयव व्यवस्थित रूप से बदलें

युक्ति: एक समय में एक चर बदलें। यदि आप केबल और स्विच पोर्ट दोनों को स्वैप करते हैं, तो आपको यह नहीं पता होगा कि इसे किस प्रकार तय किया गया है।

ज्ञात-अच्छा केबल के साथ स्वैप पैच केबल
विभिन्न स्विच पोर्ट पर टेस्ट
विभिन्न एनआईसी (या यूएसबी नेटवर्क एडाप्टर) की कोशिश करें
विभिन्न क्लाइंट डिवाइस से टेस्ट
विभिन्न VLAN/subnet

2. पैकेट एकाधिक बिंदुओं पर कब्जा

स्रोत, मध्यवर्ती बिंदुओं और गंतव्य पर यातायात को कैप्चर करने के लिए जहां पैकेट गिराया जाता है या संशोधित किया जाता है:

# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com

# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com

# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue

3. लूपबैक परीक्षण

एक ही डिवाइस के भीतर कनेक्टिविटी का परीक्षण करके बाह्य चर को हटा दें:

# Test TCP stack without network
ping 127.0.0.1

# Test application listening locally
telnet localhost 80

# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing

4. ज्ञात-अच्छा बेसलाइन तुलना

एक कार्य प्रणाली के खिलाफ विन्यास और व्यवहार की तुलना करें:

# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
     <(ssh broken-switch "show run int gi1/0/1")

# Compare routing tables
diff <(ssh router1 "show ip route") \
     <(ssh router2 "show ip route")

दस्तावेज़ीकरण के दौरान समस्या निवारण

उचित प्रलेखन परिपत्र डीबगिंग को रोकता है जहां आप इसे महसूस किए बिना कई बार एक ही चीज की कोशिश करते हैं।

समस्या निवारण टेम्पलेट

Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01

Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds

Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found

Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss

Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.

Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.

Time to Resolution: 25 minutes

क्यों प्रलेखन मामले: इस रिकॉर्ड के बिना, अगली बार जब कोई उस स्विच पर CRC त्रुटियों को देखता है, तो वे तुरंत फाइबर सफाई की जांच के बजाय केबलों और परीक्षण बंदरगाहों की जगह बर्बाद कर सकते हैं।

रियल वर्ल्ड केस स्टडीज

केस स्टडी 1: "नेटवर्क धीमी है" (वास्तव में: टीसीपी विंडो एक्स्हॉस्टेशन)

लक्षण

डेटाबेस अनुप्रयोग प्रतिक्रिया समय <100ms से 5+ सेकंड तक गिरावट आई है। आवेदन टीम ने "नेटवर्क विलंबता" को दोषी ठहराया।

प्रारंभिक मान्यताओं (Wrong)

नेटवर्क भीड़
WAN लिंक संतृप्त
Firewall bottleneck

नैदानिक प्रक्रिया

पिंग टेस्ट: RTT = 2ms (उत्कृष्ट, नियम बाहर परत 3 विलंबता)
बैंडविड्थ परीक्षण (iperf): 1 जीबीपीएस लिंक पर 950 एमबीपीएस (कोई भीड़ नहीं)
पैकेट कैप्चर: डेटाबेस सर्वर से टीसीपी शून्य विंडो पैकेट का खुलासा किया
सर्वर निरीक्षण: डेटाबेस सर्वर प्राप्त बफर = 64KB (टिनी!)

रूट कारण

डेटाबेस सर्वर OS बफर उच्च बैंडविड्थ × देरी उत्पाद के लिए बहुत छोटे थे। टीसीपी विंडो भर जाएगी, प्रेषक को प्रतीक्षा करने के लिए मजबूर करेगी।

संकल्प

# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216

पाठ सीखे

मत मानो: "Slow" हमेशा "नेटवर्क विलंबता" का मतलब नहीं है। हमेशा सबूत इकट्ठा (लेटेंसी के लिए पिंग, व्यवहार के लिए पैकेट कैप्चर) समापन के लिए कूदने से पहले।

केस स्टडी 2: आंतरायिक कनेक्टिविटी (वास्तव में: डुप्लेक्स मैस्मैच)

Symptom

सर्वर कनेक्शन यादृच्छिक रूप से, विशेष रूप से लोड के तहत छोड़ देगा। कभी कभी ठीक काम नहीं किया, कभी कभी पूरी तरह से उत्तरदायी।

Initial Assumptions (Wrong)

एनआईसी
खराब केबल
हार्डवेयर मुद्दे स्विच करें

Diagnostic Process

इंटरफ़ेस निरीक्षण: सर्वर एनआईसी = 1000 / पूर्ण, स्विच पोर्ट = 1000 / आधा (mismatch!)
त्रुटि काउंटर: स्विच पोर्ट पर व्यापक टकराव की गिनती
लेट टकराव: डुप्लेक्स धुंध के संकेतक

Root Cause

स्वतः बातचीत विफल रहा। सर्वर ने पूर्ण-डुप्लेक्स पर बातचीत की, स्विच आधे-डुप्लेक्स पर वापस गिर गया। जब दोनों पक्षों ने एक साथ संचारित करने की कोशिश की, तो कलेक्शन केवल लोड के नीचे हुआ।

Resolution

! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
 speed 1000
 duplex full

Lesson Learned

दोनों सिरों की जाँच करें: इंटरफ़ेस स्थिति बातचीत सेटिंग्स को दर्शाता है। एक गलती का मतलब ऑटो-नेगोटिएशन विफल रहा। सर्वर के लिए हमेशा हार्ड-कोड गति / डुप्लेक्स।

केस स्टडी 3: "कुछ वेबसाइटों तक नहीं पहुंच सकते" (वास्तव में: MTU / PMTUD ब्लैक होल)

Symptom

उपयोगकर्ता कुछ वेबसाइटों (Google, याहू) ब्राउज़ कर सकते हैं लेकिन अन्य नहीं (बैंक वेबसाइट, कंपनी पोर्टल)। छोटे HTTP अनुरोधों ने काम किया, बड़े पृष्ठ समय पर थे।

Initial Assumptions (Wrong)

DNS
फायरवॉल विशिष्ट साइटों को अवरुद्ध करता है
आईएसपी रूटिंग समस्या

Diagnostic Process

DNS रिज़ॉल्यूशन: सभी साइटों के लिए ठीक काम करता है
पिंग टेस्ट: "unreachable" साइटों को पिंग कर सकते हैं
लघु HTTP अनुरोध (curl): छोटे पृष्ठों के लिए काम करता है
डाउनलोड: टीसीपी हैंडशेक के बाद स्टाल
MTU परीक्षण: ping -M do -s 1472 सफल ping -M do -s 1473 विफल
आईसीएमपी निगरानी: No "Fragmentation Needed" (टाइप 3 कोड 4) संदेश प्राप्त

Root Cause

वीपीएन सुरंग ने MTU को 1400 तक घटा दिया, लेकिन फायरवॉल आईसीएमपी "फ्रैगमेंटेशन नीड" संदेशों को अवरुद्ध कर रहा था। पथ MTU डिस्कवरी (PMTUD) काम नहीं कर सकता, एक MTU ब्लैक होल बना सकता है। छोटे पैकेट फिट, DF बिट सेट के साथ बड़े पैकेट चुपचाप गिरा दिया गया था।

Resolution

! Implemented TCP MSS clamping on router
interface Tunnel0
 ip tcp adjust-mss 1360

! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big

Lesson Learned

आकार के मामले: यदि छोटे अनुरोध काम करते हैं लेकिन बड़े हस्तांतरण विफल हो जाते हैं, तो MTU/fragmentation मुद्दों पर संदेह है। पथ MTU परीक्षण करने के लिए DF बिट के साथ पिंग का उपयोग करें।

प्रकरण अध्ययन 4: वीओआईपी गुणवत्ता मुद्दे (वास्तव में: QoS Misconfiguration)

Symptom

वॉयस कॉल में चोप्पी ऑडियो, आंतरायिक ड्रॉपआउट थे। केवल व्यावसायिक घंटों (9am-5pm) के दौरान हुआ।

Initial Assumptions (Wrong)

अपर्याप्त बैंडविड्थ
वीओआईपी सर्वर ओवरलोड
आईएसपी कनेक्शन गुणवत्ता

Diagnostic Process

बैंडविड्थ परीक्षण: व्यस्त घंटे के दौरान केवल 40% उपयोग किए जाने वाले लिंक
QoS निरीक्षण: आवाज यातायात DSCP EF (46) सही ढंग से चिह्नित
कतार निरीक्षण: वॉयस कतार में केवल 5% बैंडविड्थ आवंटन (33%) होना चाहिए।
पैकेट कैप्चर: भीड़ के दौरान आवाज पैकेट गिराया जा रहा है

Root Cause

QoS नीति अस्तित्व में है लेकिन बैंडविड्थ आवंटन पिछड़े था: सबसे अच्छा प्रयास 60% मिला, आवाज 5% हो गया। व्यापार के समय जब डेटा यातायात में वृद्धि हुई, तो आवाज पैकेट को कतार अतिप्रवाह के कारण गिरा दिया गया।

Resolution

! Corrected QoS policy
policy-map WAN-QOS
 class VOICE
  priority percent 33
 class VIDEO
  bandwidth percent 25
 class CRITICAL-DATA
  bandwidth percent 20
 class class-default
  bandwidth percent 22

Lesson Learned

समय आधारित मुद्दों = क्षमता: यदि समस्याएं केवल व्यस्त घंटों के दौरान होती हैं, तो यह एक कठिन विफलता नहीं बल्कि एक क्षमता / क्यूओएस मुद्दा नहीं है। कतार सांख्यिकी की जाँच करें, न केवल कुल बैंडविड्थ।

सिम्पटम द्वारा कमान संदर्भ

लक्षण	परत	रन करने के लिए कमांड	क्या देखना है?
कोई लिंक प्रकाश नहीं	परत 1	`show interfaces ethtool eth0`	स्थिति: नीचे, कोई वाहक, केबल unpluged
पैकेट हानि	परत 1/2	`show interfaces show interfaces counters errors`	CRC त्रुटियों, runts, दिग्गजों, टकराव, देर से टकराव
पिंग गेटवे नहीं	परत 2	`arp -a show mac address-table show spanning-tree`	कोई एआरपी प्रविष्टि नहीं, मैक नहीं सीखा, एसटीपी अवरुद्ध
रिमोट सबनेट तक नहीं पहुंच सकता	परत 3	`traceroute show ip route show ip route summary`	मिसिंग मार्ग, गलत अगली-हॉप, रूटिंग लूप
कनेक्शन मना कर दिया	परत 4	`telnet host port netstat -an tcpdump`	सर्विस सुनने, फायरवॉल ब्लॉक, टीसीपी आरएसटी
धीरे प्रदर्शन	परत 4+	`ping (RTT) iperf3 tcpdump show interfaces`	उच्च विलंबता, बैंडविड्थ सीमा, टीसीपी पुनर्ट्रांसमिशन, शून्य खिड़कियां
होस्टनाम को हल नहीं कर सकता	परत 7	`nslookup dig cat /etc/resolv.conf`	DNS सर्वर अपरिवर्तनीय, गलत DNS विन्यास, NXDOMAIN
आंतरायिक गिरावट	Layer 1/2	`ping -f (flood) show logging show interfaces`	डुप्लेक्स बेमेल, असफल केबल, एसटीपी पुनरावर्तन
कभी-कभी काम करता है, अन्य नहीं	एकाधिक	`Extended ping Packet capture Interface statistics`	लोड संतुलन मुद्दा, ECMP asymmetry, स्टेट टेबल ओवरफ्लो

जब Escalate

जब टीएसी विक्रेता या वरिष्ठ इंजीनियरों को escalate करने के लिए पता है। जब Escalate:

आपने अपने ज्ञान के आधार पर सभी समस्या निवारण चरणों को समाप्त कर दिया है
समस्या के लिए आपको एक्सेस / अनुमति की आवश्यकता नहीं है
समस्या में विक्रेता सॉफ्टवेयर बग या हार्डवेयर दोष शामिल है
व्यापार प्रभाव महत्वपूर्ण और समय-संवेदनशील है
एकाधिक टीमों को सहयोग करने की आवश्यकता होती है (आवेदन + नेटवर्क + सर्वर)

इससे पहले: सब कुछ आप की कोशिश की है दस्तावेज़। TAC इंजीनियरों को अपने चरणों को दोहराने से बचने के लिए इस जानकारी की जरूरत है। शामिल:

पूर्ण लक्षण विवरण
जब जारी करना शुरू हो गया
नैदानिक आदेश चलाने और उनके उत्पादन
विन्यास बैकअप
पैकेट कैप्चर (यदि प्रासंगिक हो)
क्या आपने पहले से ही कोशिश की है

अपने व्यक्तिगत ज्ञान बेस का निर्माण

हर समस्या निवारण सत्र एक सीखने का अवसर है। व्यक्तिगत ज्ञान का आधार बनाएं:

1. एक समस्या निवारण जर्नल बनाएँ

# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md  # Index of all issues

# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation

2। एक कमांड धोखा शीट बनाएँ

समस्या निवारण के दौरान त्वरित संदर्भ के लिए परिदृश्य द्वारा अक्सर उपयोग किए जाने वाले आदेशों को व्यवस्थित करें।

3. अपने नेटवर्क दस्तावेज़

टोपोलॉजी आरेख (लेयर 2 और लेयर 3)
आईपी एड्रेस स्कीम प्रलेखन
VLAN असाइनमेंट
मानक विन्यास (टेम्पलेट)
ज्ञात आधार रेखाएँ (इंटरफेस सांख्यिकी समस्याओं से पहले)

आम एंटी-पैटरन से बचने के लिए

To make a random change without diagnosis

समस्या को समझने के बिना विन्यास बदलने से अक्सर चीजें खराब हो जाती हैं या वास्तविक मुद्दे को मास्क करती हैं।

The network is हमेशा गलती पर

अक्सर "नेटवर्क मुद्दे" अनुप्रयोग, सर्वर या क्लाइंट-साइड समस्याएं होती हैं। दोष स्वीकार करने से पहले सबूत इकट्ठा करना।

To make a problem of a person.

आप पहले से ही किए गए परीक्षणों को दोहराते समय बर्बाद कर देंगे, या आपके द्वारा कोशिश की गई सहयोगियों को समझाने में असमर्थ होंगे।

Intermittent मुद्दों

आंतरायिक समस्याएं अक्सर असफलता के प्रारंभिक चेतावनी संकेत होती हैं। इससे पहले कि वे आलोचनात्मक हो जाते हैं उन्हें निवेश करें।

The end of the end of the end of the end of the body.

एक उपकरण को रिबूट करने से सेवा बहाल हो सकती है, लेकिन अगर आपको पता नहीं है कि WHY इसे रिबूट करने की आवश्यकता है, तो समस्या फिर से होगी।

सारांश: व्यवस्थित समस्या निवारण चेकलिस्ट

शुरू करने से पहले

पांच प्रमुख प्रश्नों का उत्तर दें (What बदल गया? कौन प्रभावित है? लगातार या आंतरायिक? Reproducible? अन्य पक्ष क्या देखता है?
कैथर प्रारंभिक लक्षण और उपयोगकर्ता रिपोर्ट
हाल के परिवर्तनों या रखरखाव के लिए जाँच करें

For the Troubleshooting.

ओएसआई परतों (बॉटम-अप या टॉप-डाउन) के माध्यम से विधिवत काम करें
परीक्षण करते समय एक समय में परिवर्तनशील
प्रत्येक परीक्षण और उसके परिणाम
वास्तविक यातायात व्यवहार देखने के लिए पैकेट कैप्चर का उपयोग करें
ज्ञात आधार रेखाओं के खिलाफ तुलना करें

संकल्प के बाद

निश्चित रूप से समस्या को हल करने की पुष्टि करें
दस्तावेज़ रूट कारण और संकल्प
अपने ज्ञान आधार को अद्यतन करें
यदि कॉन्फ़िगरेशन बदल जाता है, तो अद्यतन प्रलेखन
विचार करें: क्या यह पहले पकड़ा गया है?

निष्कर्ष

नेटवर्क समस्या निवारण विज्ञान और कला दोनों है। विज्ञान एक व्यवस्थित पद्धति का पालन कर रहा है, नैदानिक उपकरणों का सही ढंग से उपयोग कर रहा है और प्रोटोकॉल को समझने में सक्षम है। कला यह जान रही है कि कौन से परीक्षण लक्षणों के आधार पर पहले चलाने के लिए, अनुभव से पैटर्न को पहचानना, और यह जानने के लिए कि कब बढ़ना है।

इस लेख में वर्णित व्यवस्थित दृष्टिकोण का पालन करके- सही प्रश्नों को लेने, व्यवस्थित रूप से OSI मॉडल के माध्यम से काम करने, अपने चरणों का दस्तावेजीकरण करने और प्रत्येक मुद्दे से सीखने के लिए-आप समस्या निवारण में अधिक कुशल हो जाएंगे और उन सामान्य नुकसानों से बचेंगे जो बर्बाद होने के समय और गलत फिक्स का कारण बनेंगे।

याद रखें: लक्ष्य सिर्फ सेवा को बहाल करने के लिए नहीं है, बल्कि यह समझने के लिए कि WHY यह विफल रहा ताकि आप इसे फिर से होने से रोक सकें।

Last updated: February 2, 2026 लेखक: Baud9600 Technical Team