NAT Tables Sizing


#1

Continuing the discussion from Admintagebuch - Dokumentation der Admintätigkeiten:

Der Vorfall dort ist wie ich finde ärgerlich da wir die Settings schon im Oktober einmal angefasst haben. Siehe https://forum.freifunk-muensterland.de/t/nat-table-sizing/118

Daher habe ich das mal in die “Ansible Todos” aufgenommen.

Die Frage ist ja wieviele NAT sessions wir pro Nutzer annehmen sollten.
In einem IETF Paper von 2013 hat jemand für Carrier Grade NAT 400 Session angeben.
Ich sehe auf meinem Notebook ohne was besonderes an (2 Browser, Mail, Twitter) ~100 Connections, wenn man die Browser auch nutzt dann sind es auch 200.
Für Smartphones habe ich keine noch keine Daten gefunden, ich rate mal das es weniger sind (alleine durch Push Mechanismen und Power Management).

D.h. 400 pro aktiven Gerät scheint eine vernünftige Größenordnung zu sein.
Als aktive Geräte zur Peak Usage Zeit nehmen veranschlagen die 25%.

D.h. bei 2500 Clients davon 25% aktiv = 625 * 400 = 250.000 aktive NAT Mappings.

Darin sind Abuse und Torrents nicht enthalten. Torrents bringt das locker über 1000 Connections, ist aber wohl eine Ausnahme. Ebenso Abuse. In dem Paper wird eine Grenze von 1000 Connections pro Client angenommen die reguläre Anwendungen nicht behindert. Ich würde vorschlagen im weiteren Verlauf die Anzahl der NAT Einträge pro IP tatsächlich auf 1000 zu begrenzen.

NAT Einträge sind billig, sie kosten effektiv nur Speicher. Es gibt ein kleines Skript das die
den Speicherbedarf berechnet (bzw andersrum)
Von greyworm-4:

Therefore to consume a maximum of 100 MiB of kernel memory:

  • conntrack_max should be set to 317750
  • Using the kernel’s default ratio, the nf_conntrack module’s `hashsize’ parameter should be set to 39719

Da wir IMHO kein Speicherproblem haben würde ich daher vorschlagen die 300k Sessions tatsächlich so zu konfigurieren.

Quelle:
https://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-01
https://johnleach.co.uk/words/372/netfilter-conntrack-memory-usage


Admintagebuch - Dokumentation der Admintätigkeiten
Admintagebuch - Dokumentation der Admintätigkeiten
#2

Klingt vernünftig. Derzeit verwalten wir die Backbones allerdings noch nicht mit Ansible.


#3

Hier können wir jetzt aber aktiv werden, oder? Fanlin war heute voll…