Porovnání propustnosti NATu mezi Linuxem a pfSense/FreeBSD

[drazil]

Ahoj,

jako v minulém příspěvku (Porovnání propustnosti NATu mezi Linuxem a MiktoTik RouterOS) jsem provedl měření propustnosti implementace NATu na Linuxu (Debian 8.3, kernel 4.3.0), pfSense 2.2.6 (založen na FreeBSD 10.1) a FreeBSD 10.2. Oproti minulému případu, kdy jsem musel kvůli technickým potížím použít starší stroj, nyní používám nejlepší počítač, který mám k dispozici. Konkrétně se jedná o počítač s procesorem Intel Core i7 6700 @ 3.40 GHz, 2x8 GB RAM DDR4, základní deska ASUS Z170I PRO GAMING a síťová karta stejně jako minule Intel Ethernet Server Adapter X520-DA2.

Každý testovaný OS byl nastaven tak, aby každé jádro mělo přístup ke "své" frontě paketů na síťovém adaptéru. Stejně jako minule jsem použil NAT 1:M (PAT) a generoval provoz s 10 000 UDP toky s pakty o velikosti 128 B. Výsledky jsou na grafech níže (osa X je počet generovaných paketů, osa Y je počet paketů zpracovaných NATem, hodnoty jsou v milionech paketů za sekundu).

pfSense 2.2.6:

FreeBSD 10.2:

Linux Debian 8.3, kernel 4.3.0:

Maximální propustnost pfSense a FreeBSD je prakticky stejná a pohybuje se kolem 1,2 milionů paketů za sekundu. Oproti tomu Linux zvládá odbavit až 4 miliony paketů za sekundu. Toto měření opět ukazuje, že Linux má velmi dobře implementovaný NAT.

Možná některé zarazilo, proč jsem nepoužil výchozí kernel dodávaný s Debianem. Důvod je takový, že spojení Linux verze 3.16 (+patche od Debianu) a procesoru Intel i7 Skylake se objevil zákeřný problém. Po nastavení pravidel pro NAT a následném spuštění generátoru provozu operační systém skončil s kernel panic. Stack trace vedl do funkcí spojených se souborovým systémem, tak jsem pro jistotu vyměnil celý disk a provedl čistou instalaci Debianu. Jenže i po tomto zásahu se projevoval stejný problém. Vzhledem k tomu, že řada procesorů Skylake je poměrně nová a jádro 3.16 poměrně staré (srpen 2014), tak jsem zkusil nasadit jádro 4.3.0. Po zvýšení verze kernelu se problém přestal projevovat.

Na základě výše uvedeného problému mě napadá provést měření na kernelu 3.16 a 4.3 a zjistit jak moc se liší propustnost. To však znamená připravit další stroj, kde budou fungovat obě verze kernelu, takže výsledky budou v dalším příspěvku.

[Salamander]

Mohl bys prosim do srovnani pridat VyOS? http://vyos.net/wiki/Main_Page

[cerva]

Díky za velmi zajímavá měření Jen pro doplnění bych se rád zeptal, jaký firewall byl na FreeBSD použit - IPFW nebo PF? Nechceš ještě vyzkoušet nftables na Linuxu?

[Standa99]

Skylake je podporován až od kernelu 4.3 a sám mám vyzkoušené, že kernel 4.5 je ještě trochu lepší. Tím myslím podporu (např. pro GPU), NATování už možná lepší nebude.

[drazil]

Mohl bys prosim do srovnani pridat VyOS? http://vyos.net/wiki/Main_Page

Promň, že jsem nenapsal už minule, koukal jsem na to a je to vesměs Linux 3.13 s upraveným shellem. Obecně se dají očekávat stejné výsledky jako v případě Debiana. Nemůžu zaručit, že ho změřím, ale pokud na to budu mít čas, tak to udělám.

Díky za velmi zajímavá měření Jen pro doplnění bych se rád zeptal, jaký firewall byl na FreeBSD použit - IPFW nebo PF? Nechceš ještě vyzkoušet nftables na Linuxu?

Jo tady jsem to zapomněl napsat, že je to měřené nad IPFW.

Skylake je podporován až od kernelu 4.3 a sám mám vyzkoušené, že kernel 4.5 je ještě trochu lepší. Tím myslím podporu (např. pro GPU), NATování už možná lepší nebude.

Tohle se dá očekávat, vzhledem k tomu, že když se vyvíjel kernel 3.16, tak se mluvilo maximálně o Broadwellech. Člověk by čekal, že starší kernel bude fungovat i na Skylake, vzhledem k tomu jak Intel tlačí politiku zpětné kompatibility. Osobně si však myslím, že to bude souviset spíš se zastaralými drivery řadiče disků. Vede mě k tomu jednak stack trace, a pak fakt, že RouterOS (ještě starší linuxový kernel) vůbec disky nevidí.

[mrm]

Bolo by možné urobiť meranie, ktoré sa viacmenej približuje reálnej prevádzke?
To jest:
- TCP, UDP pakety
- firewall má cca 100 pravidiel ACCEPT, DROP a REJECT
- logovanie DROP a REJECT paketov
- toľko súbežných spojení koľko dá traffic generator.