Проблемът: Приложението за база данни е "бавно." Мрежовият екип обвинява сървъра. Сървърът обвинява мрежата. В същото време потребителите са разочаровани и часовете се пропиляват в кръгова дебъгване.
Решението: Систематичен, научен подход за отстраняване на проблеми, който използва доказателства, а не предположения, за идентифициране на коренови причини.
Цената на случайни отстраняване на неизправности: Загуба на време, неправилно определя, че маскира реални проблеми, пръст сочене между екипи, и деградира потребителски опит.
Мрежово отстраняване е основно упражнение в научния метод:
Тази статия осигурява структурирана рамка за решаване на мрежови проблеми, която предотвратява общи капани като:
Преди да се потопите в техническата диагностика, отговорете на тези пет критични въпроса, за да стесните обхвата на разследването:
Промени в настройките? Нов хардуер? Софтуерни актуализации? Промени в топологията?
Един потребител? Една сграда? Всички? Само специфично приложение?
Случва се постоянно? Само през определени часове? Случайни събития?
Можеш ли да задействаш проблема при поискване?
Проверка на двата края на връзката
Моделът 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Кога да използвате: Специфични за приложението проблеми, при които съществува основна свързаност
Започнете от Layer 7 (Is SharePoint service running? DNS решава да коригира IP?) и работи надолу само ако е необходимо.
Използвайте това бързо диагностично дърво, за да определите кой слой не работи:
TCP/IP стека не функционира. Проверете OS услугите, преинсталирайте мрежовите драйвери.
NIC деактивирани, грешен шофьор, кабел изключен. Проверка: ip link show или Управление на устройства
Проверка: Физически кабел, състояние на порта, VLAN задача, ARP таблица
Проверка: Рутинна маса, правила на защитната стена, ACLs. Използване 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
Не предполагай: "Бавно" не винаги означава "мрежа латентност." Винаги събирайте доказателства (пип за латентност, улавяне на пакети за поведение) преди да правите заключения.
Връзката със сървъра ще падне случайно, особено при натоварване. Понякога работи добре, понякога напълно не реагира.
Автопреговорите се провалиха. Сървърът е договорил пълен сплит, превключвателят е паднал обратно на полу-дуплекс. Сблъсъците са настъпили при натоварване само когато двете страни са се опитали да предават едновременно.
! 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 ПровалVPN тунел намали MTU до 1400, но защитната стена блокира ICMP "Необходима фрагментация" съобщения. Път MTU Discovery (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 въпроси. Използвайте пинг с DF бит, за да тествате пътя MTU.
Гласовите разговори са били с прекъсващ звук, прекъсващи отпадането. Само през работното време (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
Времеви въпроси = капацитет: Ако проблемите се случват само в натоварени часове, това не е труден провал, а капацитет / QoS проблем. Проверете статистиката на опашките, не само общата честотна лента.
| Симптом | Слой | Команди за изпълнение | Какво да търсим |
|---|---|---|---|
| Няма светлина за свързване | Слой 1 | show interfaces |
Състояние: долу, няма превозвач, кабелът е изключен |
| Загуба на пакет | Слой 1/2 | show interfaces |
КРС грешки, изтърсаци, гиганти, сблъсъци, късни сблъсъци |
| Не мога да се свържа. | Слой 2 | arp -a |
Не ARP запис, MAC не е научил, STP блокиране |
| Не мога да стигна до отдалечена мрежа. | Слой 3 | traceroute |
Липсващ маршрут, погрешен следващ хоп, маршрутен цикъл |
| Връзката отказана | Слой 4 | telnet host port |
Услугата не слуша, защитна стена блок, TCP RST |
| Бавно изпълнение | Слой 4+ | ping (RTT) |
Висока латентност, ограничение на честотната лента, TCP препредаване, нула прозорци |
| Името на домакина не може да се разреши. | Слой 7 | nslookup |
DNS сървър недостъпен, грешен DNS config, NXDOMAIN |
| Интермитентни капки | Layer 1/2 | ping -f (flood) |
Duplex несъответствие, неработещ кабел, STP възстановяване |
| Понякога работи, не други. | Многократно | Extended ping |
Товароносимост, ECMP асиметрия, преливна маса |
Знаеш кога да ескалираш до TAC или старши инженери. Ескалирайте, когато:
Всяко отстраняване на проблеми е възможност за учене. Изграждане на база от лични знания:
# 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
Организирайте често използвани команди по сценарий за бърза справка по време на отстраняване на неизправности.
Промяната на конфигурацията без разбиране на проблема често прави нещата по-лоши или маскира истинския проблем.
Често "мрежови проблеми" са приложения, сървър, или клиентски проблеми. Съберете доказателства преди да приемете вината.
Ще си губите времето да повтаряте тестове, които вече сте направили или не можете да обясните на колегите какво сте опитали.
Интермитентните проблеми често са ранни предупредителни признаци на предстоящ провал. Разследвайте ги преди да са станали критични.
Рестартиране на устройство може да възстанови услугата, но ако не разберете защо е необходимо рестартиране, проблемът ще се повтори.
Проблемите в мрежата са както наука, така и изкуство. Науката следва систематична методология, използвайки правилно диагностични инструменти и протоколи за разбиране. Изкуството е да знаеш кои тестове да се провеждат първо въз основа на симптомите, разпознавайки модели от опит, и знаейки кога да ескалира.
Като следвате систематичния подход, очертан в тази статия, задавайки правилните въпроси, работейки методично чрез модела OSI, документирайки стъпките си и учейки се от всеки въпрос, вие ще станете по-ефективни при отстраняване на проблеми и избягване на общите капани, които водят до загуба на време и неправилни поправки.
Запомни: Целта не е само да се възстанови услугата, но и да се разбере защо се провали, за да не се случи отново.
Последна актуализация: февруари 2, 2026 г.