Nejen pro konferenční Wi-Fi
Jsem součástí organizačního týmu, který dvakrát ročně organizuje komunitní setkání RIPE Meeting. Této pětidenní události se pravidelně účastní více než 600 síťařů z celého světa, pro které je kromě programu potřeba zajistit na místě také dostatečnou konektivitu.
K tomuto účelu s sebou vozíme kompletní síť včetně dvou serverů, několika síťových přepínačů a flotily přístupových bodů Wi-Fi. Vše podstatné je postaveno na svobodných technologiích: směrování zajišťuje BIRD, firewall máme zařízen pomocí nftables, DNS řeší Knot Resolver, o DHCP se stará Kea a celé to spravujeme pomocí Ansible.
Na místě máme vždy předem vyjednaný optický spoj, do kterého připojíme autonomní systém AS2121, který do globálního internetu oznamuje dva rozsahy: 193.0.24.0/21 a 2001:67c:64::/48. Síť je tak zcela nezávislá na místní infrastruktuře a používá stále stejné adresy. Poskytuje hned několik koncových sítí:
- Hlavní síť pro návštěvníky v režimu IPv6-mostly,
- Síť IPv6-only bez jakékoli podpory pro IPv4,
- Síť zvanou Legacy s klasickým dual-stackem pro ty, kteří mají problémy s předchozími dvěma
- Služební síť pro audiovizuální zařízení - jejich firmware totiž obvykle neimplementuje IP úplně dobře a při vystavení veřejnému internetu se často dějí divné věci
- Privátní síť pro administrační rozhraní síťových prvků
- Privátní síť pro provozovatele videokonferenčního systému Meetecho
Protokol ARP
Když z internetu dorazí provoz na některou z IPv4 adres, musí směrovač zajistit propojení mezi třetí a druhou síťovou vrstvou. Lapidárně řečeno se musí dozvědět, na jaké fyzické zařízení (Wi-Fi kartu) má poslat provoz pro cílovou IP adresu. Tuto informaci zjistí pomocí protokolu ARP.
Princip je velmi jednoduchý: do sítě je odeslána všeobecná výzva (broadcast) o tom, že se hledá účastník s danou IP adresou. Součástí výzvy je informace o odesílateli, tedy jeho IP a MAC adresa. Zpráva dorazí všem uzlům v daném segmentu a účastník s přidělenou adresou na výzvu odpoví. Tím si tazatel může vytvořit v tabulce ARP záznam o tom, že provoz pro tuto IP adresu je třeba odesílat na objevenou fyzickou adresu MAC.
Zachyceno nástrojem tcpdump to vypadá takto:
13:03:58 ARP, Request who-has 192.0.2.2 tell 192.0.2.1, length 46 13:03:58 ARP, Reply 192.0.2.2 is-at 00:00:5e:00:53:ab (oui IANA), length 28
Pokud je daná adresa přidělena, funguje všechno velmi dobře. Adresa je zjištěna při první snaze o kontakt, poté je uložena do tabulky a nějakou dobu používána. Tato doba je ve výchozím stavu 60 sekund a hodnotu lze měnit nastavením parametru linuxového jádra:
# sysctl net.ipv4.neigh.default.gc_stale_time net.ipv4.neigh.default.gc_stale_time = 60
Problém s neobsazenými adresami
Nepříjemná situace ovšem nastává, pokud se někdo z internetu pokouší kontaktovat adresu, která na žádném zařízení není nastavena. To se bohužel děje velmi často, protože prostor IPv4 je neustále skenován křížem krážem.
Implementace protokolu ARP v linuxovém jádře nemá negativní keš, takže si nepamatuje předchozí výzvy bez odpovědi. Každé samostatné pokusy o kontakt nepřidělené adresy tak vytvoří další požadavky, kterými jsou zaplavovány všechny uzly v síti.
V naší hlavní síti s 1024 IPv4 adresami tento provoz vytváří šum o síle 250 paketů za sekundu, což vytváří stálý tok přes 80 kbps. To nevypadá jako příliš velké číslo, je třeba si ale uvědomit, že jde o broadcasty. Ty se šíří všemi směry a v našem případě doputují k Wi-Fi.
Broadcasty na Wi-Fi mají tu vlastnost, že se vysílají nejmenší možnou rychlostí, aby byla co největší šance je dostat pokud možno opravdu ke všem klientům v okolí. Takto zpomalené vysílání ovšem zabírá to nejcennější: vysílací čas v omezeném rádiovém prostoru.
I když tedy jde o malý datový tok, jeho vliv na propustnost Wi-Fi sítě je větší. Běžný unicastový provoz by ve stejném čase mohl běžet i víc než tisíckrát rychleji. Můžeme tedy celou situaci vnímat i tak, že zprávy protokolu ARP nám efektivně zabírají ekvivalent více než 80 Mbps běžného provozu.
Řešení pomocí utility arpd
Překvapivé může být, že zmírnění tohoto problému je velmi jednoduché. Utilita arpd je součástí balíčku iproute2, toho balíčku, který se nám v Linuxu už přes dvacet let stará o konfiguraci sítě. Najdete v něm utility jako ip, ss a také už zmíněný arpd.
Jedná se o implementaci protokolu ARP v uživatelském prostoru, která místo omezeného prostoru v paměti ukládá informace o sousedech do souboru na disku. Oproti implementaci v jádře má víc konfiguračních parametrů a mimo jiné obsahuje právě i negativní keš. Doba její platnosti je konfigurovatelná parametrem -n a výchozí hodnota je 60 sekund. Změnou parametrůapp_solicit amcast_solicit je možné říci jádru, aby objevování sousedů řešila namísto jádra samotného právě utilita arpd.
V distribucích se systemd stačí pro spuštění na linuxovém směrovači vytvořit novou službu a aktivovat ji. Založíme tady novou službu příkazem:
# systemctl edit --full --force arpd
Do editoru pak zapíšeme definici služby:
[Unit] Description=Userspace ARP daemon [Service] ExecStart=/usr/sbin/arpd -k -a2 eth0 eth1 eth2 eth3 [Install] WantedBy=multi-user.target
Parametr -k potlačí implementaci protokolu ARP v jádře. Druhý parametr -a aktivuje aktivní dotazování a určuje, kolikrát má démon vyslat výzvu, než je adresa považována za neobsazenou. Za těmito parametry pak následují názvy síťových rozhraní, o která se má démon starat.
Poté službu aktivujeme pro teď i pro další starty systému:
# systemctl enable --now arpd.service
Šum je téměř pryč
Dobrá zpráva je, že toto jednoduché opatření má velmi pozitivní dopad na problematický šum způsobený zbytečným opakovaným hledáním neexistujících cílů. V naší síti konkrétně klesl počet těchto paketů třicetkrát. Místo 250 jich za sekundu vysíláme jen 8 a příslušně klesl i potřebný datový tok a tím i doba potřebná k odvysílání výzev po Wi-Fi.
Situaci je možné ještě zlepšit zmenšením velikosti sítě. Vzhledem k tomu, že víc než 80 procent zařízení v naší síti už IPv4 nepoužívá a běží v režimu IPv6-only, vypadá blok 1024 adres celkem předimenzovaně. Zmenšení přiděleného bloku nepochybně sníží i množství šumu, změna však nebude zdaleka tak dramatická – bude jen proporční ke zmenšení adresního prostoru.
Utitlita arpd podporuje pouze protokol ARP, který se používá pouze pro IPv4. Obdobnou utilitu pro protokol NDP, který se používá pro IPv6, se mi nepodařilo najít. Prakticky to ale není problém. Díky extrémnímu zředění adresního prostoru s podsítěmi o prefixu délky 64 bitů je prakticky nemožné skenovat celý adresní prostor adresu po adrese. Chytřejší způsoby skenování sice existují, ale prakticky je nepozorujeme.
Šum tedy přichází jen na několik málo IPv6 adres – například těch, se kterými někdo někdy v minulosti komunikoval – a množství multicastového provozu, které takový šum vygeneruje, je v porovnání se zprávami ARP zcela zanedbatelné.
