[ViRuZzz]

Здравствуйте, коллеги.

Предистория:

У меня небольшая сетка, около 200 свитчей и 3000 с копейками юзеров. Свитчи Zelax ZES-2026 (процентов 65) остальные это Nortel BS450 и BPS2000. Сейчас юзеры получают адреса по DHCP (некоторые прописали себе руками), в инет ходят по PPPoE/PPTP. В новых районах PPPoE нету(много виланов прокидывать приходится), только PPTP, терминируется это все на двух серваках FreeBSD+mpd5(раздает реальные IP) с авторизацией и аккаунтингом по Radius (самописный биллинг на FreeRADIUS). На каждый свитч свой vlan и сеть /25. Так-же в сети ходит multicast для телевидения и дохрена внутрисетевого unicastа.

Вот возникла идея внедрить IPoE. Там где Nortel пока оставим PPPoE/PPTP, ибо способов контролировать юзеров нет. Там где Zelax - все ок, dhcp opt82 они поддерживают. Переход обязательно плавный, грубо говоря надо per user выбирать PPP/IPoE.

Посмотрев существующие решения на рынке, которые поддерживают RADIUS пришел к выводу, что это слишком дорого (надо как минимум 2 BSR(BRAS) брать по соображениям надежности).

Каких-либо opensource решений не нашел вообще. Почему? Может плохо искал?

Начал я писать проект для решения именно этой задачи. идея какова:

Юзер ломится в инет, на роутере(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.

Кому такой проект интересен? Какие еще будут пожелания?

Изменено 13 ноября, 2010 пользователем ViRuZzz

[Ivan_83]

У вас нат 1-1 (внутренний-внешний IP) ?

Хуки lan/wan к чему цепляете?

[ViRuZzz]

У вас нат 1-1 (внутренний-внешний IP) ?

Хуки lan/wan к чему цепляете?

да, 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 демон

[Ivan_83]

На хуках получается IP пакеты, вместо эзернет?

Сколько ппс держит? (и вообще с нагрузкой как справляется)

 

Абоненты не сильно страдают что у них почти весь софт видит только серые адреса?

[ViRuZzz]

На хуках получается IP пакеты, вместо эзернет?

Сколько ппс держит? (и вообще с нагрузкой как справляется)

 

Абоненты не сильно страдают что у них почти весь софт видит только серые адреса?

да, там IP. поддержку Ethernet фреймов сделать можно, проблем нет.

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

По идее не сильно - у большинства провайдеров вообще NAT с PortTranslation и ничего, не жалуются, только торренты у них плохо работают.

Изменено 13 ноября, 2010 пользователем ViRuZzz

[yakuzzza]

Узкозаточенное решение под Netgraph. Но сам Netgraph конечно же очень вкусный.

У меня несколько вопросов: почему не рассматриваете возможность FreeRADIUS выступать как DHCP-сервер? Так можно реализовать IPoE с аккаунтингом? У некоторых даже работает.

 

Я бы начинал детектить сессию с момента поднятия порта на коммутаторе в Up.

[ViRuZzz]

Узкозаточенное решение под Netgraph. Но сам Netgraph конечно же очень вкусный.

У меня несколько вопросов: почему не рассматриваете возможность FreeRADIUS выступать как DHCP-сервер? Так можно реализовать IPoE с аккаунтингом? У некоторых даже работает.

 

Я бы начинал детектить сессию с момента поднятия порта на коммутаторе в Up.

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

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

Изменено 13 ноября, 2010 пользователем ViRuZzz

[yakuzzza]

Убрать НАТ 1 в 1 чтобы реальники не были драгоценными и отправлять пользователей ч-з НАТ-пулы в Интернет. Статический НАТ как допуслуга. 30% пользователей грузят сеть нашару?

У нас в городе давно нет тарифов "без Интернета". Это же потенциальные прокси и туннели в сети, подумайте над этим.

 

Находил ссылку по материалу - может пригодится: http://stas-v.livejournal.com/8636.html

 

 

[ViRuZzz]

Убрать НАТ 1 в 1 чтобы реальники не были драгоценными и отправлять пользователей ч-з НАТ-пулы в Интернет. Статический НАТ как допуслуга. 30% пользователей грузят сеть нашару?

У нас в городе давно нет тарифов "без Интернета". Это же потенциальные прокси и туннели в сети, подумайте над этим.

 

Находил ссылку по материалу - может пригодится: http://stas-v.livejournal.com/8636.html

NAT-PT делать не хочется по ряду причин:

1. торренты и другие протоколы

2. Юзеры уже привыкли к настоящим адресам, по этой причине многие юзеры к нам приходят от конкурентов.

3. NAT-PT на широких каналах и большом pps требует большой мощи

 

 

NAT, наверное, сделаю отключаемым, чтобы при необходимости можно было использовать NAT-PT (ng_nat например)

[yakuzzza]

Впервые встречаюсь с таким подходом - из-за торрентов не хотите строить так, как вам удобнее. Ну что же, тогда докупайте PI-блоки ведь в итоге у вас адресов будет столько же, сколько и активных клиентов. А при Опции 82 еще и неиспользуемых адресов будет много. Пользователи то отключились, то заморозили порт - ваш ресурс сеальников так и висит грузом в бинате.

Не совсем красивое решение в итоге получается.

 

Ну или если хотите шагать впереди планеты всей - перейдите на реальники на абонента сразу в сети, без ната.

[ViRuZzz]

Ну или если хотите шагать впереди планеты всей - перейдите на реальники на абонента сразу в сети, без ната.

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

[Abram]

А чем Вас lISG не устроил?

[Ivan_83]

да, там IP. поддержку Ethernet фреймов сделать можно, проблем нет.

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

[ViRuZzz]

да, там IP. поддержку Ethernet фреймов сделать можно, проблем нет.

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

это да.... тут будет не совсем просто.

[ViRuZzz]

А чем Вас lISG не устроил?

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

 

[Abram]

А чем Вас lISG не устроил?

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

lISG = Linux ISG. От Cisco там только название и идея.

[ViRuZzz]

А чем Вас lISG не устроил?

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

lISG = Linux ISG. От Cisco там только название и идея.

Такого раньше даже не слышал

[Abram]

А чем Вас lISG не устроил?

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

lISG = Linux ISG. От Cisco там только название и идея.

Такого раньше даже не слышал

Ога. А оно, оказывается, в соседней теме ;). http://forum.nag.ru/forum/index.php?showtopic=53156