ISPforum 2016 Jezerka NAT++
1. část Kolik to dá, když to nainstaluju?
Překlad síťových adres (NAT) ●
Zajímalo nás jak výkonný je NAT na Linuxu (a nejen na něm) ○ ○
●
Kolik paketů za sekundu je možné odbavit? Jak se s různou zátěží mění Round Trip Time?
Jak jsme to měřili ○
○ ○
Vytvořili jsme 10 000 toků ■ Délka rámců: 128 Bytů ■ L4: UDP Postupně jsme zvyšovali zátěž linky až do 10 Gbps Měřili jsme kolik paketů bylo skutečně přeloženo
Spirent TestCenter ● ●
Testovací prostředí pro verifikaci síťových zařízení Výhody ○ ○
●
Přesné generování toků Analýza příchozích paketů
Nevýhody ○ ○
Nedostupná podpora plnohodnotného TCP provozu Provoz je syntetický
Round Trip Time ● ●
Jak dlouho trvá od odeslání paketu získat potvrzení o jeho doručení Stejně pro všechny měřené platformy:
Nastavení NATu na operačních systémech ● ● ● ●
Přerušení rozložené na všechna jádra Velikost conntrack tabulky: 262140 položek v 65536 bucketech (výchozí nastavení v Debianu 8.2) NAT ve FreeBSD nastaven pomocí nástroje PF NAT na RouterOS nastaven prostřednictvím WebFig
Intel Xeon (2012) ● ● ● ● ● ●
Intel Xeon E5-2620 6 jader (12 vláken) 2,00 GHz 15 MB cache 32 GB RAM NIC: Intel X520-DA2 (2x 10Gbps)
● ●
Linux 3.16 Linux 4.3.0
2,4 Mpps 3,7 Mpps
Intel i7 (2015) ● ● ● ● ● ●
Intel Core i7-6700 4 jádra (8 vláken) 3,40 GHz 8 MB cache 16 GB RAM NIC: Intel X520-DA2 (2x 10Gbps)
● ● ●
Linux 3.16 Linux 4.3 FreeBSD 10.2
5,1 Mpps 5,5 Mpps 1,1 Mpps
Intel i3 (2015) ● ● ● ● ● ●
Intel Core i3-6300 2 jádra (4 vlákna) 3,80 GHz 4 MB cache 16 GB RAM NIC: Intel X520-DA2 (2x 10Gbps)
● ●
Linux 3.16 Linux 4.3
2,8 Mpps 2,9 Mpps
Intel Xeon (2010) ● ● ● ● ● ●
Intel Xeon E5420 4 jádra (bez HT) 2,50 GHz 12 MB cache 10 GB RAM NIC: Intel X520-DA2 (2x 10Gbps)
● ●
Linux 4.3 RouterOS 6.34
1,4 Mpps 0,6 Mpps
AMD Opteron ● ● ● ● ● ●
AMD Opteron 6376 (2012) 4×16 jader 16 MB cache 2,30 GHz 64 GB RAM NIC: Intel X520-DA2 (2x 10Gbps)
●
Linux 3.16
1,8 Mpps
ARM Platformy - 1Gbps rozhraní ●
Olimex OLinuXino LIME A20 ○ ○
●
HardKernel Odroid C1+ ○ ○
●
ARM Cortex-A7 Dual-core @ 1 GHz, 512 MB DDR3 RAM Propustnost: 33 Kpps ARM Cortex-A5 Quad-core @ 1.5 GHz, 1 GB DDR3 RAM Propustnost: 154 Kpps
HardKernel Odroid XU4 ○ ○ ○ ○
ARM Cortex-A15 Quad-core @ 2 GHz ARM Cortex-A7 Quad-core @ 1.4 GHz 2GB LPDDR RAM Propustnost: N/A
Shrnutí měření
Linux 3.16
Linux 4.3
FreeBSD
RouterOS
Intel i7 (2015)
5,1
5,5
1,1
-
Intel Xeon (2012)
2,4
3,7
-
-
Intel i3 (2015)
2,8
2,9
-
-
AMD Opteron
1,8
-
-
-
Intel Xeon (2010)
-
1,4
-
0,6
2. část Jak to zrychlit?
Ladění: CONNTRACK ● ●
Tabulka pro uchování probíhajících spojení Hashovací tabulka, položky řetězeny lineárně ○
○
●
nf_conntrack_max = maximální počet sledovaných toků (256K výchozí) ■ nastavuje se v závislosti na dostupné paměti ■ Velikost paměti v bytech / 16384 / (x / 32), x = 32 nebo 64 podle architektury nf_conntrack_buckets = počet “bucketů” v tabulce (64K výchozí) ■ systém odvozuje podle velikosti conntrack ■ CONNTRACK_MAX / 8
Zachovat co nejmenší poměr mezi parametry (1 bucket se chová jako seznam => pomalé vyhledávání při velkém počtu toků)
Ladění: CONNTRACK ●
●
Nedostatečená kapacita silně ovlivní výkonnost, stejně tak nevhodný poměr hodnot nf_conntrack_max a nf_conntrack_buckets Vliv je více patrný u velkého počtu toků (v měření použito 1000000 toků) ○ při nižším množství toků je rozdíl řádově menší
Ladění: Timeouty ●
Výchozí hodnoty relativně dlouhé ○
● ●
TCP spojení ve stavu ESTABLISHED až 5 dní!
Kratší hodnoty umožní efektivně čistit tabulky => obslouží více spojení Nastavení v souborech /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_<stav>
Ladění: Nový vs. starý kernel ●
●
Nové verze kernelu pomáhají s výkonností (optimalizace zpracování, ovladačů aj.) Při nasazování prověřit stabilitu
Ladění: Přerušení a CPU ● ● ● ●
Každá RX/TX fronta síťové karty dostane vlastní číslo přerušení Ve výchozím nastavení přiděleny všechny na jedno jádro CPU irqbalance -- výchozí nástroj pro rozložení přerušení Rozložení lze nastavit i ručně pro RX: /proc/irq/<číslo irq>/smp_affinity pro TX: /sys/class/net/
/queues/tx-<číslo fronty>/xps_cpus
Ladění: Multi-CPU stroje ● ● ●
Každý CPU má přiděleny vlastní PCI-E sloty Přenos dat mezi CPU zpomaluje (nutnost synchronizace) Intel HyperThreading - není ideální pro síťové úlohy, může mít negativní vliv na rychlost zpracování
DPDK NAT ●
DPDK ○ framework pro vývoj aplikací zpracovávající síťovou komunikaci ○ obchází Linux Kernel (zpracování paketů v userspace)
3. část Co s tím dál?
Myšlenka “IP koncentrátoru” ● ●
Jenom NAT nestačí pro nasazení u ISP Další funkce: ○ ○ ○ ○ ○ ○ ○ ○
●
centrální správa sítě s “jednodušším” nastavením (web frontend “ala Mikrotik” + napojitelnost na existující systémy ISP) Podpora různých adresných schémat (Statické IP adresy, DHCP, PPPoE, ještě něco?) NAT a IP filtr / firewall (SNAT, DNAT, Blokace IP, portu, přesměrováni, …) Traffic shaping VLAN Směrování (OSPF, …) SNMP Radius
Postupně akcelerovat potřebné funkce (které jsou pro vás vhodné?)
Další motivace pro IP koncentrátor ● ● ● ● ● ●
Pružnější správa přístupu koncových zařízení do sítě - odděluje je od správy zbytku sítě. Centralizované řešení, kde se přístup do sítě, ověření a účtování řeší v jednom bodě. Úkolem sítě je "pouze" doručit pakety na koncentrátor. Díky AAA lepší přehled o aktivitě klienta. “Směruje” administratora mít pořádek v síti. Obsahuje REST API pro ovládání z nadřazených billing systemů (ISP admin, FreeNet IS) Automatizuje činnosti spojené s přídáváním, konfigurováním a monitorováním klientů připojených do sítě.
Děkujeme za pozornost ...a budeme rádi za náměty pro další vývoj
