Перейти к содержимому
Калькуляторы

BRAS soft для Linux (шейпер, файрволл, CG-NAT) Еще один софт для нарезки скорости клиентам

А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков?

 

Не должно :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков?

 

Не должно :)

Вопрос ещё один, возможно ли будет к сабу в qinq пробить статикой к примеру сетку /30?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

интерфейсы не нужны, достаточно маршрута типа customer_ip dev NYOH, где нёх это некий виртуальный интерфейс, который передаёт трафик в ядро и как-то там обрабатывается. вопрос в том насколько глубоко хочет автор топика залезать в dataplane

 

а без этого никак, если IP раздаются из биллинга, брасов несколько и кастомеры хотят статику

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

Думали использовать субнеты с IP-интерфейса и разрешать трафик только после авторизации сессии. Так не надо будет держать каждого клиента в таблице маршрутизации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков?

 

Не должно :)

Вопрос ещё один, возможно ли будет к сабу в qinq пробить статикой к примеру сетку /30?

 

ip route add<network> via <client_ip>

или

ip addr add <network> dev <qinq_dev> ?

 

В первом случае - проще держать маршрут уже готовым (через BGP например)

Во втором - должно быть достаточно держать адреса на primary IP интерфейсе (к которому подвязаны ip-unnumbered)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если по-умолчанию все IP в блэк-холе

Да пофиг, блэкхол или нет, если это не совмещенный брас+бордер/единственный брас в сети. Чтобы выдавать клиентам динамику, нужно чтобы маршруты с браса анонсились.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны?

А как будет схема с двумя брасами в сети? А без резерва - это что на пороховой бочке сидеть.

Кстати, Nitro - я про него писал на первой странице и "его" дистрибутив Leaf. Было бы замечательно ваши проекты подружить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ip route add<network> via <client_ip>

или

ip addr add <network> dev <qinq_dev> ?

 

В первом случае - проще держать маршрут уже готовым (через BGP например)

Во втором - должно быть достаточно держать адреса на primary IP интерфейсе (к которому подвязаны ip-unnumbered)

А почему не в unnumbered-style

ip route add <net> dev <qinq_dev>?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны?

А как будет схема с двумя брасами в сети? А без резерва - это что на пороховой бочке сидеть.

Кстати, Nitro - я про него писал на первой странице и "его" дистрибутив Leaf. Было бы замечательно ваши проекты подружить.

На вскидку можно что-то такое придумать :

Два и несколько брасов можно сделать по BGP + VRRP c клиентской стороны - разделив префиксы между брасами приоритетами.

Соответственно, один упал - трафик перескочил на следующий брас (или на несколько брасов)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ip route add<network> via <client_ip>

или

ip addr add <network> dev <qinq_dev> ?

 

В первом случае - проще держать маршрут уже готовым (через BGP например)

Во втором - должно быть достаточно держать адреса на primary IP интерфейсе (к которому подвязаны ip-unnumbered)

А почему не в unnumbered-style

ip route add <net> dev <qinq_dev>?

главное чтобы маршрут через нужный интерфейс прошел ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Боже, 400 евро за что?

 

Поломать вам малину и выложить в открытый доступ то что написал для себя?

 

Там ровно половина от того что есть у вас и я за это ничего не хочу.

Но проблема всё та же - это НЕ готовое решение.

Хотя и разгребает Q-in-Q без создания сабов, само вколачивает роуты, ойпи и маки в ядро - откуда их цапает всё что надо.

мониторит клиентов arping`ом, авторизирует по произвольному пакету, имеет белые списки сайтов (доступных при блокировки).

Встроенный dhcp сервер. пилю балансировку/резервирование.

Вчера доделал аналог бриджа для менеджмент влана - нужyо если коммутатор агрегации не умеет selective QinQ ;(

ещё всякая чепуха по мелочи. ;)

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

 

P. S.: Да-да это всё модуль ядра. user-space прокси осталась только для связи с биллингом ;) Хотя по сути можно просто генерить текстовичок который будет перечитываться модулем. Сам иду в торону TCP сессии между модулем и биллингом.

Изменено пользователем VVSina

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Боже, 400 евро за что?

 

Поломать вам малину и выложить в открытый доступ то что написал для себя?

 

Там ровно половина от того что есть у вас и я за это ничего не хочу.

Но проблема всё та же - это НЕ готовое решение.

Хотя и разгребает Q-in-Q без создания сабов, само вколачивает роуты, ойпи и маки в ядро - откуда их цапает всё что надо.

мониторит клиентов arping`ом, авторизирует по произвольному пакету, имеет белые списки сайтов (доступных при блокировки).

Встроенный dhcp сервер. пилю балансировку/резервирование.

Вчера доделал аналог бриджа для менеджмент влана - нужyо если коммутатор агрегации не умеет selective QinQ ;(

ещё всякая чепуха по мелочи. ;)

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

 

P. S.: Да-да это всё модуль ядра. user-space прокси осталась только для связи с биллингом ;) Хотя по сути можно просто генерить текстовичок который будет перечитываться модулем. Сам иду в торону TCP сессии между модулем и биллингом.

конечно выкладывайте! если работает, то все только выиграют и может нам не надо будет изобретать колесо ;)

где можно скачать? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

или есть сценарии, где не нужны?

Тазик в мелкой домосети до нескольких сот клиентов разве что. Ну или тазики в сетях с серой адресацией. В таких сетях только навряд кто-то 400 баксов выложит за брас...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

или есть сценарии, где не нужны?

Тазик в мелкой домосети до нескольких сот клиентов разве что. Ну или тазики в сетях с серой адресацией. В таких сетях только навряд кто-то 400 баксов выложит за брас...

В любом случае, делаем с маршрутами, и, если надо будет, то должно быть довольно просто отключить добавление маршрутов в ядро. Но похоже не придется :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ASAP :) чтобы дать уже что-то потестить : оптимистично - на следующей неделе, пессимистично - пару-тройку недель. Плюс еще хотим на реальном трафике немного погонять и написать тесты, что еще до юзабельной версии добавит неделю-другую.

уже научили софт создавать псевдо-интерфейс и маршруты. Даже пакеты бегают :D

как будет синтаксис команд - обновим документацию и я отпишусь тут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ждемс..

 

кстати , привязка софта идет по чем ? винт ? маки сетевых ? чтобы знать что из надежного нужно )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на BRAS все надежное лучше ставить :D но к сетевкам и материнке лучше особое внимание уделить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хотим немного уточнить :

 

  1. rp_filter - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе?
  2. arp_proxy - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе?
  3. dhcp_auth (авторизация только по DHCP) - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе?
  4. dhcp_auth option 82 - в каком формате хочется получать ее на DHCP сервере (binary/ascii, формат)?
  5. какие-нибудь еще опции нужны? на интерфейс или per-QinQ ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А можно не для тех, кто не является линух специалистом?

1 - не знаю что это такое

2 - по каждому сабу, а лучше маску исключения, не у всех selective qinq, может и mng vlan прийти, или например доступ к локалке - как доп услуга

3 - по маске/шаблону

4 - по маске/шаблону

5 - возможность исключения сабинтерфейса вообще из обработки. Возможность статически назначать подсеть на саб.

---

Гляньте последние вопрос в теме accell - там вложенный qinq... Что думаете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SyJet, спасибо!

1 - фильтрация SRC адресов на интерфейсе (только авторизованные SRC адреса будут разрешены). работает для routed-трафика, если это L2 траффик на бридже - фильтр не применяется

2 - ok, делаем на сабах

3 - ok, делаем на сабах

4 - не понял :)

5 - будет + будет. причем на каждый маршрут можно свой dst MAC-адрес поставить (несколько клиентов в одном Q-in-Q например).

 

а вложенный Q-in-Q - по идее не должно быть проблем, если как Link-interface использовать VLAN интерфейс... Но надо тестировать - хардварная акселерация тэгов может подкинуть грабли, но это решаемо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пункт 4 - хотя логично :) я за ascii

 

А вот бы встроенный dhcp, чтобы он к биллингу по радиусу сразу обращался - было бы супер, чтоб не городить ещё одну сущность.

В аксселле отличная реализация - формирование логина вообще очень гибко. А пароль либо пустой либо mac

Изменено пользователем SyJet

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а еще бы чтобы ДХЦП сервер с релеем работал .. вообще замечательно было бы )

по поводу 4 пункта , нужно оставить возможность ничего не изменять\добавлять в опции82 , на случай обработки пакетов релеем или радиусом или мускулом

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, учтем. Опция dhcp-radius это интересно, тоже добавим. с option82 сделаем чтобы можно было ее заменить или добавить (если не установлена)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, учтем. Опция dhcp-radius это интересно, тоже добавим. с option82 сделаем чтобы можно было ее заменить или добавить (если не установлена)

Так dhcp будет с радиус-аккаунтинк? :)

---

Я тут подумал... А что по поводу дебиторщиков + whitelist для них? Чтоб те, у кого денег нет - авторизовывались, получали IP, но пользовались только ресурсами указанными в whitelist?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.