ViRuZzz

хм... ну теоретически устраивает. Но этот вариант я даже не рассматривал (рассматривал Juniper и Redback) ибо имел очень много секса с Cisco (без ISG), и честно говоря, от цисок впечатление осталось больше негативное (особенно после Juniper) lISG = Linux ISG. От Cisco там только название и идея. Такого раньше даже не слышал

хм... ну теоретически устраивает. Но этот вариант я даже не рассматривал (рассматривал Juniper и Redback) ибо имел очень много секса с Cisco (без ISG), и честно говоря, от цисок впечатление осталось больше негативное (особенно после Juniper)

"Проблемы" появятся если вы захотите чтобы работала связка ethernet <-> ip в обе стороны. это да.... тут будет не совсем просто.

Хотим, но слишком большой overhead получается. /27 на свитч не хватает (iptv, а скоро еще и voip), щас выдаем на свитч /25. Жирно получается.

NAT-PT делать не хочется по ряду причин:1. торренты и другие протоколы 2. Юзеры уже привыкли к настоящим адресам, по этой причине многие юзеры к нам приходят от конкурентов. 3. NAT-PT на широких каналах и большом pps требует большой мощи NAT, наверное, сделаю отключаемым, чтобы при необходимости можно было использовать NAT-PT (ng_nat например)

возможность выступать FreeRADIUS как DHCP сервер я как раз очень даже рассматриваю, но вот IPoE с аккаунтингом мне кажется так не получится. У некоторых работает как-то иначе.Начинать сессию в момент подняти порта нецелесообразно, ибо процентов 30 линков это юзеры не юзающие инет, на них расходовать драгоценные IP адреса жирно.

да, там IP. поддержку Ethernet фреймов сделать можно, проблем нет.по поводу pps я еще под нагрузкой не тестил, но доп. нагрузки он должен создавать совсем мало, там 1 lookup по дереву (по source адресу если на lan хуке или по destination адресу если на wan хуке), замена адреса, и пересчет CRC (инкрементальный). Думаю ng_netflow создаст нагрузку значительно больше. По идее не сильно - у большинства провайдеров вообще NAT с PortTranslation и ничего, не жалуются, только торренты у них плохо работают.

да, 1 - 1цепляю к ipfw: [root@frog]# ipfw -a list 01000 511 39781 netgraph 10 ip from 192.168.2.0/24 to any out recv em1 xmit em0 01100 84521 5492967 netgraph 20 ip from any to xxx.xx.253.0/24 in recv em0 01910 50 2916 fwd 127.0.0.1,81 tcp from 192.168.2.0/24 to any dst-port 80 out recv em1 xmit em0 [root@frog]# ngctl show zznat0: Name: zznat0 Type: zznat ID: 0000000e Num hooks: 4 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- ctl zznatd5373 socket 0000002c cfg wanrej ipfw ipfw 00000001 21 wan ipfw ipfw 00000001 20 lan ipfw ipfw 00000001 10 ctl это userspace демон

Удалите плз эту тему. Случаянно создал 2 раза.

Здравствуйте, коллеги. Предистория: Начал я писать проект для решения именно этой задачи. идея какова:Юзер ломится в инет, на роутере(FreeBSD, почему расскажу позже) мы это детектим, шлем запрос на radius(там передаем IP клиента), если radius нас пустил то создаем "сессию". в ней указывается "внутренний"(серый) адрес, "внешний"(белый) адрес и ряд дополнительных параметров. внешний адрес мы берем либо из параметра ответа Framed-IP-Address, либо, если нам сервер передал имя IP пулла, то выделяем из него. Далее регулярно мы смотрим как у нас поживает сессия, забираем из ядра в userspace статистику и отправляем ее на Radius сервер. Когда мы понимаем что юзер долго(Session-idle-timeout) ничего не шлет/получает мы отваливаемся, либо отваливаемся когда прошло уже Sesssion-Timeout времени. Так-же при старте/стопе сессии есть возможность удалять/добавлять адрес (локальный или внешний) в таблицу IPFW (это тоже передается через radius). Что есть сейчас: Все что написано в предидущем абзаце есть и, вроде, даже работает. Как это реализовано: netgraph нода, у нее 3 основные хука lan - тут у нас локалка, wan - тут интернет, ctl - сюда подключается userspace daemon, который рулит всем процессом. внутри реализован простой NAT (1 в 1, без трансляции портов) (пока нет поддержки SCTP) и уведомление о новых сессиях через ctl хук. Нода поддерживает операции создания, удаления сессии с заданными локальным и внешним адресом, получение статистики о каждой сессии (кол-во пакетов и байт в каждую сторону) и получение списка сессиий. Так-же есть еще дополнительный хук, wanrej - это для заблоченых юзеров, этих юзером мы прозрачно проксируем на сайт с обзяснением о сложившейся ситуации. В netgraph ноду трафик заворачивается через ipfw. там-же будет происходить ограничение скоростей через dummynet. В юзерспейсе крутится демон, который коннектится к netgraph ноде, получает от нее уведомления о новых сессиях, запрашивает инфу о сессиях у радиуса, создает сессии в нетграф ноде, забирает оттуда статистику, отправляет ее на радиус, следит затаймаутами и управляет таблицами IPFW. почему FreeBSD: а что еще? Не солярис-же? На самом деле у FreeBSD есть отличная технология netgraph, которая сильно упрощает разработку и внедрение подобных вещей. Чего еще нет но скоро будет: поддержка кластера: это когда есть несколько узлов, и при появлении сессии на одном из узлов, она появляется на всех узлах кластера, общие синхронизированные пуллы адресов, узлы поддерживают одну или несколько(для балансировки нагрузки) carp групп, если один из узлов выходит из строя то юзер ничего не заметит. Проект будет OpenSource, лицензия скорее всего BSD. Кому такой проект интересен? Какие еще будут пожелания?