समस्या:एक डेटाबेस एप्लिकेशन "धीमा" है। नेटवर्क टीम सर्वर टीम को दोषी ठहराती है। सर्वर टीम नेटवर्क को दोष देती है. इस बीच, उपयोगकर्ता निराश हैं, और सर्कुलर डिबगिंग में घंटों बर्बाद हो जाते हैं।
समाधान:समस्या निवारण के लिए एक व्यवस्थित, वैज्ञानिक दृष्टिकोण जो मूल कारणों की पहचान करने के लिए मान्यताओं का नहीं बल्कि साक्ष्यों का उपयोग करता है।
अव्यवस्थित समस्या निवारण की लागत:समय की बर्बादी, गलत सुधार जो वास्तविक समस्याओं को छुपाते हैं, टीमों के बीच उंगली उठाना और उपयोगकर्ता अनुभव में गिरावट।
नेटवर्क समस्या निवारण मूलतः वैज्ञानिक पद्धति का एक अभ्यास है:
यह आलेख नेटवर्क समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है जो सामान्य नुकसानों को रोकता है जैसे:
तकनीकी निदान में उतरने से पहले, अपनी जांच का दायरा सीमित करने के लिए इन पांच महत्वपूर्ण प्रश्नों के उत्तर दें:
कॉन्फ़िगरेशन परिवर्तन? नया हार्डवेयर? सॉफ़्टवेयर अद्यतन? टोपोलॉजी संशोधन?
एक उपयोगकर्ता? एक इमारत? सब लोग? केवल विशिष्ट अनुप्रयोग?
हर समय होता है? केवल कुछ निश्चित घंटों के दौरान? यादृच्छिक घटनाएँ?
क्या आप मांग पर समस्या उत्पन्न कर सकते हैं?
कनेक्शन के दोनों सिरों की जाँच करें
OSI मॉडल समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है। लक्षणों के आधार पर परत 1 (भौतिक) से ऊपर की ओर, या परत 7 (अनुप्रयोग) से नीचे की ओर कार्य करें।
कब उपयोग करें:पूर्ण कनेक्टिविटी हानि, कोई लिंक लाइट या भौतिक परत लक्षण नहीं
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, पैकेट कैप्चरnslookup, dig, curl -vकब उपयोग करें:एप्लिकेशन-विशिष्ट समस्याएं जहां बुनियादी कनेक्टिविटी मौजूद है
परत 7 से शुरू करें (क्या SharePoint सेवा चल रही है? DNS IP को सही करने का समाधान कर रहा है?) और केवल जरूरत पड़ने पर ही काम करें।
यह पहचानने के लिए कि कौन सी परत विफल हो रही है, इस त्वरित डायग्नोस्टिक ट्री का उपयोग करें:
टीसीपी/आईपी स्टैक काम नहीं कर रहा है। OS सेवाओं की जाँच करें, नेटवर्क ड्राइवर पुनः स्थापित करें।
एनआईसी अक्षम, गलत ड्राइवर, केबल अनप्लग। जाँच करना:ip link showया डिवाइस मैनेजर
जांचें: भौतिक केबल, स्विच पोर्ट स्थिति, वीएलएएन असाइनमेंट, एआरपी तालिका
जांचें: रूटिंग टेबल, फ़ायरवॉल नियम, एसीएल। उपयोगtracerouteयह पता लगाने के लिए कि पैकेट कहाँ रुकते हैं
जांचें: डीएनएस सर्वर सेटिंग्स, डीएनएस सर्वर उपलब्धता, फ़ायरवॉल ब्लॉकिंग पोर्ट 53
जांचें: फ़ायरवॉल नियम, सुरक्षा समूह, पोर्ट पर सेवा सुनना
समस्या स्वयं एप्लिकेशन, प्रमाणीकरण, या एप्लिकेशन कॉन्फ़िगरेशन के साथ है
जब आपके पास मूल कारण के बारे में कोई परिकल्पना हो, तो इसकी पुष्टि या अस्वीकार करने के लिए इन अलगाव तकनीकों का उपयोग करें:
यह पहचानने के लिए कि पैकेट कहाँ गिराए गए हैं या संशोधित किए गए हैं, स्रोत, मध्यवर्ती बिंदुओं और गंतव्य पर ट्रैफ़िक कैप्चर करें:
# 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
एक ही डिवाइस के भीतर कनेक्टिविटी का परीक्षण करके बाहरी चर को हटा दें:
# 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
किसी कार्य प्रणाली के विरुद्ध कॉन्फ़िगरेशन और व्यवहार की तुलना करें:
# 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")
उचित दस्तावेज़ीकरण सर्कुलर डिबगिंग को रोकता है जहाँ आप एक ही चीज़ को बिना समझे कई बार आज़माते हैं।
अंक आईडी: TICKET-12345
दिनांक समय: 2026-02-02 14:30 UTC
के द्वारा रिपोर्ट किया गया: Jane Smith (jane.smith@company.com)
प्रभावित उपयोगकर्ता: ~50 users in Building A, 3rd floor
लक्षण: Cannot access file server \\fileserver01
प्रारंभिक टिप्पणियाँ:
- 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
किए गए परीक्षण:
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
मूल कारण:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
संकल्प:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
सत्यापन:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
समाधान का समय: 25 minutes
डेटाबेस एप्लिकेशन प्रतिक्रिया समय <100ms से घटकर 5+ सेकंड हो गया। एप्लिकेशन टीम ने "नेटवर्क विलंबता" को दोषी ठहराया।
उच्च-बैंडविड्थ × विलंब उत्पाद के लिए डेटाबेस सर्वर ओएस बफ़र्स बहुत छोटे थे। टीसीपी विंडो भर जाएगी, जिससे प्रेषक को इंतजार करना पड़ेगा।
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
यह मत मानिए:"धीमे" का अर्थ हमेशा "नेटवर्क विलंबता" नहीं होता है। निष्कर्ष पर पहुंचने से पहले हमेशा सबूत इकट्ठा करें (विलंबता के लिए पिंग, व्यवहार के लिए पैकेट कैप्चर)।
सर्वर कनेक्शन बेतरतीब ढंग से बंद हो जाएगा, खासकर लोड के तहत। कभी-कभी ठीक काम करता था, कभी-कभी पूरी तरह से अनुत्तरदायी।
स्वतः-वार्ता विफल रही. सर्वर ने फुल-डुप्लेक्स पर बातचीत की, स्विच वापस हाफ-डुप्लेक्स पर आ गया। टकराव केवल लोड के तहत हुआ जब दोनों पक्षों ने एक साथ संचारित करने का प्रयास किया।
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
दोनों सिरों की जाँच करें:इंटरफ़ेस स्थिति बातचीत की गई सेटिंग्स दिखाती है। बेमेल का अर्थ है स्वतः-बातचीत विफल होना। सर्वर के लिए हमेशा हार्ड-कोड स्पीड/डुप्लेक्स।
उपयोगकर्ता कुछ वेबसाइटें (Google, Yahoo) ब्राउज़ कर सकते हैं लेकिन अन्य (बैंक वेबसाइट, कंपनी पोर्टल) नहीं। छोटे HTTP अनुरोधों ने काम किया, बड़े पेजों का समय समाप्त हो गया।
ping -M do -s 1472सफल होता है,ping -M do -s 1473विफल रहता हैवीपीएन सुरंग ने एमटीयू को घटाकर 1400 कर दिया, लेकिन फ़ायरवॉल आईसीएमपी "फ़्रेग्मेंटेशन नीडेड" संदेशों को रोक रहा था। पथ एमटीयू डिस्कवरी (पीएमटीयूडी) काम नहीं कर सका, जिससे एमटीयू ब्लैक होल बन गया। छोटे पैकेट फिट हो गए, डीएफ बिट सेट वाले बड़े पैकेट चुपचाप गिरा दिए गए।
! 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
आकार मायने रखती ह:यदि छोटे अनुरोध काम करते हैं लेकिन बड़े स्थानांतरण विफल हो जाते हैं, तो एमटीयू/विखंडन समस्याओं पर संदेह होता है। पथ एमटीयू का परीक्षण करने के लिए डीएफ बिट के साथ पिंग का उपयोग करें।
वॉइस कॉल में ऑडियो ख़राब था, रुक-रुक कर ड्रॉपआउट हो रहा था। केवल व्यावसायिक घंटों (सुबह 9 बजे से शाम 5 बजे तक) के दौरान हुआ।
क्यूओएस नीति अस्तित्व में थी लेकिन बैंडविड्थ आवंटन पीछे की ओर था: सर्वोत्तम प्रयास को 60% मिला, आवाज को 5% मिला। व्यावसायिक घंटों के दौरान जब डेटा ट्रैफ़िक बढ़ गया, तो कतार अतिप्रवाह के कारण वॉयस पैकेट गिरा दिए गए।
! 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
समय-आधारित मुद्दे = क्षमता:यदि समस्याएँ केवल व्यस्त घंटों के दौरान होती हैं, तो यह कोई कठिन विफलता नहीं बल्कि क्षमता/क्यूओएस समस्या है। केवल कुल बैंडविड्थ ही नहीं, कतार आँकड़े भी जाँचें।
| लक्षण | परत | चलाने का आदेश | किसकी तलाश है |
|---|---|---|---|
| कोई लिंक लाइट नहीं | परत 1 | show interfaces |
स्थिति: डाउन, कोई वाहक नहीं, केबल अनप्लग्ड |
| पैकेट हानि | परत 1/2 | show interfaces |
सीआरसी त्रुटियां, रनट्स, दिग्गज, टकराव, देर से टकराव |
| गेटवे पिंग नहीं कर सकता | परत 2 | arp -a |
कोई एआरपी प्रविष्टि नहीं, मैक नहीं सीखा, एसटीपी अवरुद्ध |
| दूरस्थ सबनेट तक नहीं पहुंच सकता | परत 3 | traceroute |
गुम मार्ग, गलत नेक्स्ट-हॉप, रूटिंग लूप |
| कनेक्शन नहीं हो सका | परत 4 | telnet host port |
सेवा नहीं सुन रही, फ़ायरवॉल ब्लॉक, टीसीपी आरएसटी |
| धीमा प्रदर्शन | परत 4+ | ping (RTT) |
उच्च विलंबता, बैंडविड्थ सीमा, टीसीपी पुन: प्रसारण, शून्य विंडो |
| होस्टनाम का समाधान नहीं किया जा सका | परत 7 | nslookup |
DNS सर्वर पहुंच योग्य नहीं है, गलत DNS कॉन्फ़िगरेशन, NXDOMAIN |
| रुक-रुक कर गिरना | परत 1/2 | ping -f (flood) |
डुप्लेक्स बेमेल, विफल केबल, एसटीपी पुनः अभिसरण |
| कभी-कभी काम करता है, अन्य नहीं | विभिन्न | Extended ping |
लोड संतुलन समस्या, ईसीएमपी विषमता, राज्य तालिका अतिप्रवाह |
जानें कि विक्रेता टीएसी या वरिष्ठ इंजीनियरों को कब शिकायत करनी है। आगे बढ़ें जब:
प्रत्येक समस्या निवारण सत्र सीखने का एक अवसर है। व्यक्तिगत ज्ञान का आधार बनाएँ:
# 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 फ़रवरी 2026 | लेखक: बॉड9600 तकनीकी टीम