📬 ISN 219: Dlaczego RTT w Traceroute Kłamie? Plus MTU, Crossplane i Skalowanie Google!

MTU i fragmentacja CAPWAP psują Wi-Fi

Why MTU, MSS & CAPWAP Fragmentation Break More Wi-Fi Than People Realise

(A story from inside the tunnels where packets go to suffer) Most Wi-Fi problems announce themselves loudly alarms, alerts, complaints, Teams messages with far too many exclamation marks. But some issues don’t come with drama.

LinkedInZeeshan Khan

Dashboardy zielone. RF czyste. Klienci podłączeni. A użytkownicy mówią: "Wi-Fi jest wolne". Znasz to uczucie? To właśnie moment, kiedy prawdziwy problem kryje się tam, gdzie nikt nie patrzy.

Wszystko wygląda dobrze:

• Roaming działa
• DHCP/DNS bez zarzutu
• Interferencja normalna

Speed test przez tunel CAPWAP: 3 Mbps.
Ten sam klient przez LAN: 300 Mbps.

PMTU między kontrolerami pokazał 1385 bajtów. Wystarczająco dla małych pakietów. Śmiertelnie mało dla nowoczesnego ruchu aplikacyjnego.

Ale to nie sama fragmentacja była winna. To była kombinacja:

• MTU za niskie
• MSS nie zaciskane
• Overhead CAPWAP
• Ruch internetowy w godzinach szczytu
• WAN zachowujący się jak ulica jednokierunkowa

Pakiety nie padały - dzieliły się, zwalniały, ponawiały próby. TCP myślał, że ścieżka jest zdrowa. Tunel je kroił. WAN je ściskał. Użytkownik czekał.

Naprawa niewidzialnego potwora

Żadnych heroicznych komend. Tylko kilka cichych poprawek:

• Dostosowanie MTU do rzeczywistej ścieżki
• MSS clamping na WAN edge
• Włączenie PMTU discovery
• Weryfikacja overhead CAPWAP
• Usunięcie zbędnego tunnelingu

Rezultat: 3 → 250 Mbps w kilka minut. Zero zmian w RF. Zero tuning RRM. Tylko pakiety dostały w końcu przestrzeń, na którą zasługiwały.

Dlaczego traceroute pokazuje dziwne czasy RTT?

traceroute breaks the time-space continuum!

traceroute is a source of fun for young and old, mostly old. What you may not have known until now is its ability to break the laws of physics.

bitpuff.io: Software&NetworksMarc Suñé

Uruchamiasz traceroute google.com i widzisz coś dziwnego:

traceroute to google.com (142.250.200.206), 30 hops max, 60 byte packets
 1  192.168.1.1  3.550 ms  3.424 ms  3.346 ms
 2  81.46.38.147  20.595 ms  20.536 ms  20.475 ms
 3  81.46.34.125  79.685 ms  79.602 ms  79.540 ms
 4  * * *
 5  * * *
 6  * * *
 7  81.173.106.65  26.469 ms  15.869 ms  15.664 ms
 8  74.125.245.171  17.053 ms 108.170.225.251  14.295 ms  17.687 ms
 9  108.170.255.26  27.739 ms 192.178.110.134  16.176 ms 142.251.76.110  13.844 ms
10  108.170.252.173  19.309 ms 64.233.175.63  19.250 ms 108.170.252.173  15.359 ms
11  172.253.65.53  40.944 ms  42.708 ms 142.251.79.237  42.634 ms
12  72.14.234.190  44.364 ms 142.251.254.74  43.244 ms 192.178.85.180  44.738 ms
13  192.178.105.215  43.094 ms  42.461 ms  44.523 ms
14  209.85.243.145  44.422 ms  42.834 ms 209.85.143.123  44.361 ms
15  142.250.200.206  44.262 ms  42.788 ms  40.920 ms

3. hop (Madrid) ma RTT ~80ms, ale 10. hop (prawdopodobnie USA) tylko ~15ms. Pakiety podróżują w czasie? Nie. Mierzysz coś zupełnie innego niż myślisz.

Co faktycznie mierzy traceroute

Traceroute działa sprytnie: wysyła pakiety z rosnącym TTL i czeka na ICMP "Time Exceeded" od kolejnych routerów. Problem? Te ICMP-y generuje Control Plane, nie Forwarding Plane.

Gdy pakiet ma TTL=0, następuje exception w hardware forwarding - pakiet wędruje do CPU routera. Tam, w Control Plane, router musi:

• Odebrać pakiet (przez rate-limiting i QoS)
• Wygenerować ICMP Time Exceeded
• Wysłać go z powrotem

To nie jest priorytet. Control Plane zajmuje się BGP, OSPF, management - krytycznymi rzeczami. Twój ICMP? Low priority task, który może poczekać... lub w ogóle się zgubić.

Router w Madrycie (81.46.34.125) jest po prostu wolny w generowaniu ICMP. Może być przeciążony, mieć agresywne rate-limiting, albo stare CPU. Routery Google'a w USA? Szybkie, nowoczesne, zaprojektowane do wydajnego przetwarzania exceptions.

Nie mierzysz RTT - mierzysz RTT + czas procesowania Control Plane.

Sprawdź sam: uruchom traceroute kilka razy do tego samego hosta. RTT do tego samego hopa będzie skakać od 24ms do 144ms. Gdyby to była propagacja sygnału, byłoby stabilne.

Dla rzeczywistych pomiarów RTT używaj:

• ping bezpośrednio do hosta (bez intermediate hops)
• BFD Echo mode dla directly-connected peers - działa w data plane, daje prawdziwe RTT
• Monitoring tools typu SmokePing dla długoterminowych trendów

Rozproszone monitorowanie sieci

GitHub - macwilam/linksense: Distributed network of network monitoring agents.

Distributed network of network monitoring agents. Contribute to macwilam/linksense development by creating an account on GitHub.

GitHubmacwilam

LinkSense to wysokowydajny, asynchroniczny system monitoringu sieci opartej na Rust, umożliwiający łatwe wdrażanie lekkich agentów zbierających i raportujących metryki wydajności do centralnego serwera. Dzięki prostemu modelowi agent-serwer pozwala na ciągłe monitorowanie zdrowia i parametrów sieci, skalowalne do setek punktów monitoringu przy minimalnym zużyciu zasobów. System obsługuje osiem typów zadań (ping, TCP, TLS, HTTP, DNS, przepustowość, SQL, SNMP), a konfiguracja zarządzana jest dynamicznie i bez przestojów z wykorzystaniem plików TOML i systemu wykrywania zmian.

Pakiet konfiguracyjny Crossplane

GitHub - mbakalarski/netclab-xp: Crossplane Configuration Package providing abstract XRDs for managing network elements.

Crossplane Configuration Package providing abstract XRDs for managing network elements. - mbakalarski/netclab-xp

GitHubmbakalarski

INFO: netclab-xp to deklaratywny pakiet konfiguracyjny Crossplane, który pozwala zarządzać konfiguracją fizycznych, wirtualnych i konteneryzowanych routerów w stylu GitOps. Umożliwia spójne i powtarzalne zarządzanie routerami poprzez wielowarstwowe abstrakcje – od ogólnych usług sieciowych, przez konstrukty routerów, aż po niskopoziomowe modele YANG dostępne przez RESTCONF lub JSON-RPC.

Jak Google śledzi miliardy requestów