Prawidłowo chodzi tutaj o zjawisko natłoku (ang. congestion) w sieci. Gdy w sieci rozległej pojawia się bardzo dużo ruchu, routery i przełączniki zaczynają mieć przepełnione bufory, kolejki pakietów rosną, a czas oczekiwania na obsługę pakietu dramatycznie się wydłuża. W praktyce wygląda to tak, że część pakietów jest wyrzucana (dropowana), a te które przejdą, docierają do celu z ogromnym opóźnieniem. Dokładnie to opisuje treść pytania: pakiety nie docierają albo docierają bardzo późno. To jest klasyczny objaw natłoku, a nie żadnych „magicznych” awarii. W standardach i literaturze, np. w RFC 2914 czy dokumentach opisujących mechanizmy kontroli przeciążenia w TCP, mówi się wprost o congestion control jako o podstawowym mechanizmie radzenia sobie z taką sytuacją. TCP reaguje na natłok przez zmniejszanie okna congestion window, co skutkuje obniżeniem prędkości wysyłania danych, aby odciążyć sieć. W nowoczesnych sieciach stosuje się różne metody zapobiegania natłokowi: QoS, kolejkowanie priorytetowe, RED/WRED, kształtowanie ruchu (traffic shaping), policery, a w sieciach operatorów MPLS z inżynierią ruchu (traffic engineering). W praktyce, gdy administrator widzi w monitoringu (np. Zabbix, PRTG, NetFlow, SNMP) dużą utratę pakietów i skoki opóźnień na konkretnym łączu, pierwsze podejrzenie to właśnie natłok, a nie jakieś „magiczne” konwergencje. Moim zdaniem takie pytanie jest bardzo życiowe, bo dokładnie takie objawy widzi się przy przepełnionych łączach do Internetu, VPN-ach w godzinach szczytu czy źle zaprojektowanych sieciach WAN w firmach. Dobrą praktyką jest wtedy nie tylko „dokładanie łącza”, ale też analiza, skąd ten ruch się bierze, segmentacja sieci, priorytetyzacja krytycznych usług (VoIP, systemy ERP) i dopiero na końcu rozbudowa przepustowości. Warto też pamiętać, że przeciążenie może być lokalne (np. jeden router, jedno łącze) i nie musi oznaczać awarii całej sieci, tylko źle dobraną lub źle zarządzaną infrastrukturę.
Objawy opisane w pytaniu – pakiety, które nie docierają do celu albo docierają z bardzo dużym opóźnieniem – bardzo często są mylnie kojarzone z różnymi „tajemniczymi” procesami w sieci, jak konwergencja czy rekonfiguracja. W rzeczywistości takie zachowanie jest typowym skutkiem natłoku, czyli przeciążenia sieci. Warto uporządkować pojęcia, bo z mojego doświadczenia to jedno z częstszych źródeł nieporozumień na egzaminach i w praktyce administracyjnej. Regeneracja kojarzy się z urządzeniami warstwy fizycznej, np. z regeneratorami sygnału na długich łączach światłowodowych albo miedzianych. Regenerator po prostu „odświeża” sygnał, przywraca poziomy napięć lub kształt impulsu, ale nie ma wpływu na logikę routingu, kolejki pakietów czy opóźnienia wywołane nadmiarem ruchu. Jeśli w sieci jest problem z natłokiem, to żaden proces regeneracji nie spowoduje nagle losowego gubienia pakietów na poziomie IP – to zupełnie inna warstwa modelu OSI. Konwergencja dotyczy głównie protokołów routingu, takich jak OSPF, EIGRP, IS-IS czy BGP. Konwergencja to moment, w którym wszystkie routery w danej domenie routingu mają już spójny obraz topologii i te same informacje o trasach. Podczas zmian w sieci (awaria łącza, dodanie nowej ścieżki) przez krótki czas może wystąpić niestabilność tras, chwilowe przerwy, a nawet znikome straty pakietów, ale to są zwykle krótkotrwałe zjawiska. Stałe, długotrwałe opóźnienia i regularna utrata pakietów to już nie kwestia konwergencji, tylko przeciążenia łączy lub urządzeń. Rekonfiguracja brzmi groźnie, ale oznacza po prostu zmianę konfiguracji urządzeń sieciowych: dodanie nowego VLAN-u, zmianę trasy statycznej, modyfikację ACL, włączenie QoS i podobne działania. Owszem, nieudana lub źle zaplanowana rekonfiguracja może doprowadzić do przerwy w działaniu usługi, odcięcia części sieci czy nawet pętli, ale nie jest to typowy scenariusz objawiający się trwałym, rosnącym opóźnieniem i stopniową utratą pakietów na danym łączu. Tu raczej mielibyśmy do czynienia z nagłym brakiem łączności albo bardzo konkretnym błędem konfiguracyjnym. Typowy błąd myślowy polega na tym, że skoro coś się dzieje „dziwnie” z pakietami, to musi to być jakiś zaawansowany proces sieciowy, np. konwergencja routingu. Tymczasem w praktyce administratora sieci, zgodnie z dobrymi praktykami opisanymi choćby w dokumentacjach Cisco, Junipera czy standardach IETF, pierwsze co się sprawdza przy wysokim opóźnieniu i utracie pakietów, to obciążenie łączy, wykorzystanie CPU routerów, poziom kolejek i statystyki dropów. To właśnie prowadzi do diagnozy natłoku, a nie do wniosku o „regeneracji”, „konwergencji” czy „rekonfiguracji” jako przyczynie samego zjawiska utraty pakietów i opóźnień.