[теория][бодун]NAT двадцати-сорока гигабит траффика?

Если вам для ната из серых адресов в белые, то дешевле просто адресов купить. И надежнее.

http://nag.ru/news/17045/

Только показатели юниксов несколько занижены тут.

я зачем такие наты, если не секрет?

В самом деле, проще уже реальные ipшники раздать. По объему трафика на сверхсекретные данные это непохоже :)

Прикольно было бы посмотреть как линукс себя ведет под таким трафиком. Но почему-то мне кажется, что если поставить тупой нат без фаервола и всех дел, то стопка рутеров будет как максимум ровна стопке цисок.

а статья то — чистой воды пеар сисько :)

Существуют ли решения, и на какой высоте висят те облака, за которыми прячутся цены на эти решения?

В стратосфере облаков почти не бывает.

http://nag.ru/news/17045/

Только показатели юниксов несколько занижены тут.

Лор фифект?

Error! mysql_connect('-', '-', '-') Too many connections

Error connecting to database. Please try again.

>Прикольно было бы посмотреть как линукс себя ведет под таким трафиком. Но почему-то мне кажется, что если поставить тупой нат без фаервола и всех дел, то стопка рутеров будет как максимум ровна стопке цисок.

У цисок с натом вообще все грустно, кроме спец решений, которые в статье выше и описаны.

http://lkml.org/lkml/2009/7/17/257

Сложно сказать что такое тупой нат, важно количество потоков, нат одного потока нагрузит систему не больше простого роутинга. На линуксе роутинг на 10-40Г реализуем но с рядом оговорок, и в продакшен его пускать сейчас невозможно. Но автор желает 10М трансляций - я любитель софтроутеров под линуксом, но не стал бы для такой задачи выбирать его. Балансировка нагрузки к куче линуксовых натов явно нетривиальная задача.

По поводу пиара вы категоричны. Вы можете предложить еще что то для ната 16гигабит хоть и полудуплекса на 8М трансляций?

> а зачем такие наты, если не секрет?

Страшно сказать, обычный домонет. Это на будущее. Но уже давно перевалили за 10G.

В самом деле, проще уже реальные ipшники раздать.

В моём случае уже придётся либо переходить на с радостью отброшенный в своё время pptp (или аналоги), либо брать минимум пять /16 масок, и очень хитро делить их в dhcpd.conf по узлам. Сеть-то уже есть.
Так что малореально.

Прикольно было бы посмотреть как линукс себя ведет под таким трафиком.

Но почему-то мне кажется, что если поставить тупой нат без фаервола и всех дел

Грамотно оформленный фаерволл на фоне NATа и обычного роутинга ресурсов почти не ест.

то стопка рутеров будет как максимум ровна стопке цисок

Вот не пробовал ещё 10G карты смотреть, как-то всё не до того.
Сейчас стоит распределённая стопка гигабитных (две встроенные intel-сетевухи) линукс-роутеров на четырёхъядерных Зеонах (по четыре ядра на роутер), которая делает NAT, фаерволл, netflow и ещё несколько приятных вкусностей. Один роутер спокойно тянет до гигабита траффика (в одну сторону) при 150kpps и 100-400K трансляций. Очень дёшево. Только, во-первых, нужно ещё траффик между этими роутерами разруливать, а во-вторых, как ни странно, постепенно управление всем этим хозяйством начинает требовать всё большего и большего внимания, совершенно чудесные вещи начинают всплывать (и не только на самих этих роутерах, но и на железе, в которое они воткнуты), а если вместо пары рабочих дней в месяц на обслуживание придётся выделять целого человека с далеко не самой низкой ЗП, получается уже не так уж и дёшево.

Стопку цисок вместо стопки никс-роутеров, конечно, поиметь бы категорически не хотелось. Либо готовое решение, либо оставаться на текущей оправдавшей себя, реально работающей и масштабируемой схеме, и ждать массового прихода IPv6 :)

>Страшно сказать, обычный домонет. Это на будущее. Но уже давно перевалили за 10G.

Хороший у вас домонет с 10G апстиримами. Сколько пользователей?

повторюсь, я с таким объемом не сталкивался никогда, ибо очень давно отошел от телекомовских дел. Но в свое время я частенько дурачился с нашим цисковедом изобретая одно и тоже решения на циске и на линуксе, и потом все это тестировалось. Так вот мои линуксы почему-то почти всегда были получше цисок. В паре случаев побождала циско, но совсем ненамного.

Хз, насколько там циски улучшили свой фирмварь и модельный ряд, но чета мне подсказывает что все осталось также. Главное не лохануться на линуксе с сетевухами. А то кривых дров как известно гора.

>изобретая одно и тоже решения на циске и на линуксе, и потом все это тестировалось

Я так понимаю, под нагрузкой? Бедные десять тысяч пользователей :)

генераторы трафика никто не отменял :)

И какие генераторы умеют генерить 1М-10М потоков для тестирования ната? Nmap умеет, но только вот производительность не ахти.

Нет ничего удивительного в том что юникс обходит софтовые циски, ведь у машин на которых он работает процессоры банально быстрее на порядок. Ясное дело что софтовая циска сливает по полной. Вон вы попробуйте L3 свитч обогнать на маршрутизации. Конечно софтовые решения функциональнее да и дешевле. Просто нужно выбирать инструмент под задачу.

На объемах как у автора обычно домонет становится лиром, получает адреса и не делает никаких меганатов, потому что это банально дешевле.

Вообще странный вопрос о ценах на этом форуме, если можно просто посмотреть в gpl той же циски или обратиться к джунику или алкателю.

И какие генераторы умеют генерить 1М-10М потоков для тестирования ната

Вы не забывайте что у TCP/UDP протоколов есть ограничение на количество портов. И заНАТить через 1 ИП адрес больше 65535 одновременных TCP/UDP соединений вам врядли удастся. :)

>генераторы трафика

Так о них и говорю :)

Удастся. Ограничение на 65535 только для номера порта, а количество трансляций - это количество пар port-dst host как минимум, там вообще хеш считается от большего количества полей. То есть нельзя отнатить более 65535 коннектов к одному хосту(это грубо говоря без учета остальных полей пакета). Вряд ли у вас все юзеры к одному серверу ломануться резко.

Думаю это зависит от реализации NAT и conntrack. На досуге посмотрю исходники, ибо они самый лучший пруф. :)

Тогда и вправду бедные :)

Посмотрел исходники linux ip_conntrack. Вы правы. Действительно одни и тот же порт может использоваться для нескольких соединений, если у них разный destination. Значит судя по гуглю только в дешевых китайских роутерах и дсл-модемах (которые не на linux) есть такое ограничение.