समस्या: डेटाबेस एप्लिकेशन "धीमे" है। नेटवर्क टीम सर्वर टीम को दोषी ठहराती है। सर्वर टीम नेटवर्क को दोषी ठहराती है। इस बीच, उपयोगकर्ताओं को निराश कर दिया जाता है, और घंटों को परिपत्र डीबगिंग में बर्बाद कर दिया जाता है।
समाधान: रूट कारणों की पहचान करने के लिए सबूतों का उपयोग करने वाले समस्या निवारण के लिए एक व्यवस्थित, वैज्ञानिक दृष्टिकोण।
हाफजार्ड समस्या निवारण की लागत: बर्बाद समय, गलत फिक्स कि असली समस्याओं का सामना करना पड़ता है, टीमों के बीच उंगली इशारा, और उपयोगकर्ता के अनुभव में गिरावट.
नेटवर्क समस्या निवारण मूल रूप से वैज्ञानिक विधि में एक व्यायाम है:
यह लेख नेटवर्क समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है जो आम नुकसान को रोकता है जैसे:
तकनीकी निदान में गोताखोर से पहले, इन पांच महत्वपूर्ण सवालों का जवाब दें ताकि आपकी जांच क्षेत्र को संकीर्ण किया जा सके:
कॉन्फ़िगरेशन परिवर्तन? नया हार्डवेयर? सॉफ्टवेयर अद्यतन? टोपोलॉजी संशोधन?
एक उपयोगकर्ता? एक इमारत? क्या? केवल विशिष्ट अनुप्रयोग?
हर समय क्या होता है? केवल कुछ घंटों के दौरान? यादृच्छिक घटना?
क्या आप मांग पर समस्या को ट्रिगर कर सकते हैं?
कनेक्शन के दोनों सिरों की जाँच करें
OSI मॉडल समस्या निवारण के लिए एक संरचित ढांचा प्रदान करता है। परत 1 (भौतिकी) से ऊपर की ओर काम करें, या लेयर 7 (Application) से नीचे की ओर, लक्षणों के आधार पर।
कब उपयोग करें: पूर्ण कनेक्टिविटी हानि, कोई लिंक प्रकाश या भौतिक परत लक्षण
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, पैकेट कैप्चरnslookup, dig, curl -vकब उपयोग करें: अनुप्रयोग-विशिष्ट समस्याएं जहां बुनियादी कनेक्टिविटी मौजूद है
परत 7 (Is SharePoint सेवा चल रहा है? क्या आप आईपी को सही करने के लिए DNS को हल करना चाहते हैं?
यह पता लगाने के लिए कि कौन सी परत विफल है, इस त्वरित नैदानिक पेड़ का उपयोग करें:
टीसीपी / आईपी स्टैक कार्य नहीं कर रहा है। ओएस सेवाओं की जाँच करें, नेटवर्क ड्राइवरों को पुनर्स्थापित करें।
एनआईसी अक्षम, गलत ड्राइवर, केबल unpluged। जांच: ip link show या डिवाइस मैनेजर
चेक: भौतिक केबल, स्विच पोर्ट स्टेटस, VLAN असाइनमेंट, ARP टेबल
चेक: रूटिंग टेबल, फायरवॉल नियम, एसीएल। उपयोग traceroute यह पता लगाने के लिए कि पैकेट कहाँ रुकते हैं
चेक: DNS सर्वर सेटिंग्स, DNS सर्वर उपलब्धता, फ़ायरवॉल अवरुद्ध पोर्ट 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")
उचित प्रलेखन परिपत्र डीबगिंग को रोकता है जहां आप इसे महसूस किए बिना कई बार एक ही चीज की कोशिश करते हैं।
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
डेटाबेस अनुप्रयोग प्रतिक्रिया समय <100ms से 5+ सेकंड तक गिरावट आई है। आवेदन टीम ने "नेटवर्क विलंबता" को दोषी ठहराया।
डेटाबेस सर्वर 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" हमेशा "नेटवर्क विलंबता" का मतलब नहीं है। हमेशा सबूत इकट्ठा (लेटेंसी के लिए पिंग, व्यवहार के लिए पैकेट कैप्चर) समापन के लिए कूदने से पहले।
सर्वर कनेक्शन यादृच्छिक रूप से, विशेष रूप से लोड के तहत छोड़ देगा। कभी कभी ठीक काम नहीं किया, कभी कभी पूरी तरह से उत्तरदायी।
स्वतः बातचीत विफल रहा। सर्वर ने पूर्ण-डुप्लेक्स पर बातचीत की, स्विच आधे-डुप्लेक्स पर वापस गिर गया। जब दोनों पक्षों ने एक साथ संचारित करने की कोशिश की, तो कलेक्शन केवल लोड के नीचे हुआ।
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
दोनों सिरों की जाँच करें: इंटरफ़ेस स्थिति बातचीत सेटिंग्स को दर्शाता है। एक गलती का मतलब ऑटो-नेगोटिएशन विफल रहा। सर्वर के लिए हमेशा हार्ड-कोड गति / डुप्लेक्स।
उपयोगकर्ता कुछ वेबसाइटों (Google, याहू) ब्राउज़ कर सकते हैं लेकिन अन्य नहीं (बैंक वेबसाइट, कंपनी पोर्टल)। छोटे HTTP अनुरोधों ने काम किया, बड़े पृष्ठ समय पर थे।
ping -M do -s 1472 सफल ping -M do -s 1473 विफलवीपीएन सुरंग ने MTU को 1400 तक घटा दिया, लेकिन फायरवॉल आईसीएमपी "फ्रैगमेंटेशन नीड" संदेशों को अवरुद्ध कर रहा था। पथ MTU डिस्कवरी (PMTUD) काम नहीं कर सकता, एक MTU ब्लैक होल बना सकता है। छोटे पैकेट फिट, DF बिट सेट के साथ बड़े पैकेट चुपचाप गिरा दिया गया था।
! 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
आकार के मामले: यदि छोटे अनुरोध काम करते हैं लेकिन बड़े हस्तांतरण विफल हो जाते हैं, तो MTU/fragmentation मुद्दों पर संदेह है। पथ MTU परीक्षण करने के लिए DF बिट के साथ पिंग का उपयोग करें।
वॉयस कॉल में चोप्पी ऑडियो, आंतरायिक ड्रॉपआउट थे। केवल व्यावसायिक घंटों (9am-5pm) के दौरान हुआ।
QoS नीति अस्तित्व में है लेकिन बैंडविड्थ आवंटन पिछड़े था: सबसे अच्छा प्रयास 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 |
स्थिति: नीचे, कोई वाहक, केबल unpluged |
| पैकेट हानि | परत 1/2 | show interfaces |
CRC त्रुटियों, runts, दिग्गजों, टकराव, देर से टकराव |
| पिंग गेटवे नहीं | परत 2 | arp -a |
कोई एआरपी प्रविष्टि नहीं, मैक नहीं सीखा, एसटीपी अवरुद्ध |
| रिमोट सबनेट तक नहीं पहुंच सकता | परत 3 | traceroute |
मिसिंग मार्ग, गलत अगली-हॉप, रूटिंग लूप |
| कनेक्शन मना कर दिया | परत 4 | telnet host port |
सर्विस सुनने, फायरवॉल ब्लॉक, टीसीपी आरएसटी |
| धीरे प्रदर्शन | परत 4+ | ping (RTT) |
उच्च विलंबता, बैंडविड्थ सीमा, टीसीपी पुनर्ट्रांसमिशन, शून्य खिड़कियां |
| होस्टनाम को हल नहीं कर सकता | परत 7 | nslookup |
DNS सर्वर अपरिवर्तनीय, गलत DNS विन्यास, NXDOMAIN |
| आंतरायिक गिरावट | Layer 1/2 | ping -f (flood) |
डुप्लेक्स बेमेल, असफल केबल, एसटीपी पुनरावर्तन |
| कभी-कभी काम करता है, अन्य नहीं | एकाधिक | Extended ping |
लोड संतुलन मुद्दा, ECMP asymmetry, स्टेट टेबल ओवरफ्लो |
जब टीएसी विक्रेता या वरिष्ठ इंजीनियरों को escalate करने के लिए पता है। जब Escalate:
हर समस्या निवारण सत्र एक सीखने का अवसर है। व्यक्तिगत ज्ञान का आधार बनाएं:
# 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
समस्या निवारण के दौरान त्वरित संदर्भ के लिए परिदृश्य द्वारा अक्सर उपयोग किए जाने वाले आदेशों को व्यवस्थित करें।
समस्या को समझने के बिना विन्यास बदलने से अक्सर चीजें खराब हो जाती हैं या वास्तविक मुद्दे को मास्क करती हैं।
अक्सर "नेटवर्क मुद्दे" अनुप्रयोग, सर्वर या क्लाइंट-साइड समस्याएं होती हैं। दोष स्वीकार करने से पहले सबूत इकट्ठा करना।
आप पहले से ही किए गए परीक्षणों को दोहराते समय बर्बाद कर देंगे, या आपके द्वारा कोशिश की गई सहयोगियों को समझाने में असमर्थ होंगे।
आंतरायिक समस्याएं अक्सर असफलता के प्रारंभिक चेतावनी संकेत होती हैं। इससे पहले कि वे आलोचनात्मक हो जाते हैं उन्हें निवेश करें।
एक उपकरण को रिबूट करने से सेवा बहाल हो सकती है, लेकिन अगर आपको पता नहीं है कि WHY इसे रिबूट करने की आवश्यकता है, तो समस्या फिर से होगी।
नेटवर्क समस्या निवारण विज्ञान और कला दोनों है। विज्ञान एक व्यवस्थित पद्धति का पालन कर रहा है, नैदानिक उपकरणों का सही ढंग से उपयोग कर रहा है और प्रोटोकॉल को समझने में सक्षम है। कला यह जान रही है कि कौन से परीक्षण लक्षणों के आधार पर पहले चलाने के लिए, अनुभव से पैटर्न को पहचानना, और यह जानने के लिए कि कब बढ़ना है।
इस लेख में वर्णित व्यवस्थित दृष्टिकोण का पालन करके- सही प्रश्नों को लेने, व्यवस्थित रूप से OSI मॉडल के माध्यम से काम करने, अपने चरणों का दस्तावेजीकरण करने और प्रत्येक मुद्दे से सीखने के लिए-आप समस्या निवारण में अधिक कुशल हो जाएंगे और उन सामान्य नुकसानों से बचेंगे जो बर्बाद होने के समय और गलत फिक्स का कारण बनेंगे।
याद रखें: लक्ष्य सिर्फ सेवा को बहाल करने के लिए नहीं है, बल्कि यह समझने के लिए कि WHY यह विफल रहा ताकि आप इसे फिर से होने से रोक सकें।
Last updated: February 2, 2026 लेखक: Baud9600 Technical Team