Запрос на функцию: аппаратный NAT

+1 +1

На самом деле, не самая удачная идея. Аппаратные реализации всегда влекут за собой проблемы с масштабируемостью, которые, с другой стороны, можно решить, обновив CPU/NPU и память в программных решениях. Довольно хорошее решение для борьбы с проблемой джиттера в программных реализациях — выделить одно или два ядра CPU/NPU только для обработки плоскости данных и держать обработку плоскости управления отдельно от этих ядер. Также важно понимать, что плоскость данных делает гораздо больше, чем просто NAT пакетов перед передачей их на плоскость маршрутизации. Например, классификация, фильтрация, очереди, учёт и так далее. Аппаратная реализация хотя бы части маршрутизатора не даст заметного преимущества по задержке, потому что большая часть обработки всё равно остаётся программной, а стоимость производства устройства вырастет в три раза. Не стоит забывать и о невозможности добавлять новые функции в процесс NAT уже в ходе жизненного цикла продукта. С уважением, Ilari Stenroth

Я включил FastTrack в прошлом месяце, и оказалось, что он замедляет все мои соединения, так как я использую его вместе с балансировкой нагрузки PCC. Аппаратный NAT поддерживается некоторыми роутерами с чипом MTK, и он действительно всё ускоряет.

Но погодите, нет… Не поймите меня неправильно. Я полностью за то, чтобы использовать ASIC/FPGA вместо CPU… Но провайдеры, которые делают NAT?! Пожалуйста, нет. IPv4-пространство ограничено, я понимаю, но: сделайте так, чтобы IPv6 работал, чтобы мы как можно скорее могли выключить IPv4 и избавиться от всего этого NAT, который ломает кучу разных протоколов. Потом у нас будет NAT64 — предсказуемая NAT-система, которую легко можно было бы перенести на FPGA или что-то в этом роде.