arni Posted March 8, 2015 Author Posted March 8, 2015 А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков? Не должно :) Вставить ник Quote
SyJet Posted March 8, 2015 Posted March 8, 2015 А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков? Не должно :) Вопрос ещё один, возможно ли будет к сабу в qinq пробить статикой к примеру сетку /30? Вставить ник Quote
arni Posted March 8, 2015 Author Posted March 8, 2015 интерфейсы не нужны, достаточно маршрута типа customer_ip dev NYOH, где нёх это некий виртуальный интерфейс, который передаёт трафик в ядро и как-то там обрабатывается. вопрос в том насколько глубоко хочет автор топика залезать в dataplane а без этого никак, если IP раздаются из биллинга, брасов несколько и кастомеры хотят статику Если по-умолчанию все IP в блэк-холе, то да - клиентские IP нужно добавлять отдельным маршрутом на какой-нибудь интерфейс. Подумаем над этой опцией тоже. Думали использовать субнеты с IP-интерфейса и разрешать трафик только после авторизации сессии. Так не надо будет держать каждого клиента в таблице маршрутизации. Вставить ник Quote
arni Posted March 8, 2015 Author Posted March 8, 2015 А как будет дружить это все с квагой-бЁрдом если не будет интерфейсов? Не будет ли глюков? Не должно :) Вопрос ещё один, возможно ли будет к сабу в qinq пробить статикой к примеру сетку /30? ip route add<network> via <client_ip> или ip addr add <network> dev <qinq_dev> ? В первом случае - проще держать маршрут уже готовым (через BGP например) Во втором - должно быть достаточно держать адреса на primary IP интерфейсе (к которому подвязаны ip-unnumbered) Вставить ник Quote
NiTr0 Posted March 9, 2015 Posted March 9, 2015 Если по-умолчанию все IP в блэк-холе Да пофиг, блэкхол или нет, если это не совмещенный брас+бордер/единственный брас в сети. Чтобы выдавать клиентам динамику, нужно чтобы маршруты с браса анонсились. Вставить ник Quote
arni Posted March 9, 2015 Author Posted March 9, 2015 Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны? Вставить ник Quote
SyJet Posted March 9, 2015 Posted March 9, 2015 Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны? А как будет схема с двумя брасами в сети? А без резерва - это что на пороховой бочке сидеть. Кстати, Nitro - я про него писал на первой странице и "его" дистрибутив Leaf. Было бы замечательно ваши проекты подружить. Вставить ник Quote
kayot Posted March 9, 2015 Posted March 9, 2015 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>? Вставить ник Quote
arni Posted March 9, 2015 Author Posted March 9, 2015 Наверное тогда лучше ставить вопрос так : необходимы ли маршруты на каждого клиента или есть сценарии, где не нужны? А как будет схема с двумя брасами в сети? А без резерва - это что на пороховой бочке сидеть. Кстати, Nitro - я про него писал на первой странице и "его" дистрибутив Leaf. Было бы замечательно ваши проекты подружить. На вскидку можно что-то такое придумать : Два и несколько брасов можно сделать по BGP + VRRP c клиентской стороны - разделив префиксы между брасами приоритетами. Соответственно, один упал - трафик перескочил на следующий брас (или на несколько брасов) Может еще что-то похожее можно придумать. Просто не хочется выкинуть функционал, который может быть нужен :) Вставить ник Quote
arni Posted March 9, 2015 Author Posted March 9, 2015 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>? главное чтобы маршрут через нужный интерфейс прошел ;) Вставить ник Quote
VVSina Posted March 10, 2015 Posted March 10, 2015 (edited) Боже, 400 евро за что? Поломать вам малину и выложить в открытый доступ то что написал для себя? Там ровно половина от того что есть у вас и я за это ничего не хочу. Но проблема всё та же - это НЕ готовое решение. Хотя и разгребает Q-in-Q без создания сабов, само вколачивает роуты, ойпи и маки в ядро - откуда их цапает всё что надо. мониторит клиентов arping`ом, авторизирует по произвольному пакету, имеет белые списки сайтов (доступных при блокировки). Встроенный dhcp сервер. пилю балансировку/резервирование. Вчера доделал аналог бриджа для менеджмент влана - нужyо если коммутатор агрегации не умеет selective QinQ ;( ещё всякая чепуха по мелочи. ;) Идей много. Но это побочная деятельность в свободное время, начинавшаяся как хобби. P. S.: Да-да это всё модуль ядра. user-space прокси осталась только для связи с биллингом ;) Хотя по сути можно просто генерить текстовичок который будет перечитываться модулем. Сам иду в торону TCP сессии между модулем и биллингом. Edited March 10, 2015 by VVSina Вставить ник Quote
arni Posted March 10, 2015 Author Posted March 10, 2015 Боже, 400 евро за что? Поломать вам малину и выложить в открытый доступ то что написал для себя? Там ровно половина от того что есть у вас и я за это ничего не хочу. Но проблема всё та же - это НЕ готовое решение. Хотя и разгребает Q-in-Q без создания сабов, само вколачивает роуты, ойпи и маки в ядро - откуда их цапает всё что надо. мониторит клиентов arping`ом, авторизирует по произвольному пакету, имеет белые списки сайтов (доступных при блокировки). Встроенный dhcp сервер. пилю балансировку/резервирование. Вчера доделал аналог бриджа для менеджмент влана - нужyо если коммутатор агрегации не умеет selective QinQ ;( ещё всякая чепуха по мелочи. ;) Идей много. Но это побочная деятельность в свободное время, начинавшаяся как хобби. P. S.: Да-да это всё модуль ядра. user-space прокси осталась только для связи с биллингом ;) Хотя по сути можно просто генерить текстовичок который будет перечитываться модулем. Сам иду в торону TCP сессии между модулем и биллингом. конечно выкладывайте! если работает, то все только выиграют и может нам не надо будет изобретать колесо ;) где можно скачать? ;) Вставить ник Quote
NiTr0 Posted March 10, 2015 Posted March 10, 2015 или есть сценарии, где не нужны? Тазик в мелкой домосети до нескольких сот клиентов разве что. Ну или тазики в сетях с серой адресацией. В таких сетях только навряд кто-то 400 баксов выложит за брас... Вставить ник Quote
arni Posted March 10, 2015 Author Posted March 10, 2015 или есть сценарии, где не нужны? Тазик в мелкой домосети до нескольких сот клиентов разве что. Ну или тазики в сетях с серой адресацией. В таких сетях только навряд кто-то 400 баксов выложит за брас... В любом случае, делаем с маршрутами, и, если надо будет, то должно быть довольно просто отключить добавление маршрутов в ядро. Но похоже не придется :D Вставить ник Quote
arni Posted March 11, 2015 Author Posted March 11, 2015 ASAP :) чтобы дать уже что-то потестить : оптимистично - на следующей неделе, пессимистично - пару-тройку недель. Плюс еще хотим на реальном трафике немного погонять и написать тесты, что еще до юзабельной версии добавит неделю-другую. уже научили софт создавать псевдо-интерфейс и маршруты. Даже пакеты бегают :D как будет синтаксис команд - обновим документацию и я отпишусь тут. Вставить ник Quote
martini Posted March 11, 2015 Posted March 11, 2015 ждемс.. кстати , привязка софта идет по чем ? винт ? маки сетевых ? чтобы знать что из надежного нужно ) Вставить ник Quote
arni Posted March 11, 2015 Author Posted March 11, 2015 на BRAS все надежное лучше ставить :D но к сетевкам и материнке лучше особое внимание уделить Вставить ник Quote
arni Posted March 13, 2015 Author Posted March 13, 2015 Хотим немного уточнить : rp_filter - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе? arp_proxy - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе? dhcp_auth (авторизация только по DHCP) - достаточно ли опции на весь интерфейс, или хочется возможность установить на per-QinQ основе? dhcp_auth option 82 - в каком формате хочется получать ее на DHCP сервере (binary/ascii, формат)? какие-нибудь еще опции нужны? на интерфейс или per-QinQ ? Вставить ник Quote
SyJet Posted March 13, 2015 Posted March 13, 2015 А можно не для тех, кто не является линух специалистом? 1 - не знаю что это такое 2 - по каждому сабу, а лучше маску исключения, не у всех selective qinq, может и mng vlan прийти, или например доступ к локалке - как доп услуга 3 - по маске/шаблону 4 - по маске/шаблону 5 - возможность исключения сабинтерфейса вообще из обработки. Возможность статически назначать подсеть на саб. --- Гляньте последние вопрос в теме accell - там вложенный qinq... Что думаете? Вставить ник Quote
arni Posted March 13, 2015 Author Posted March 13, 2015 SyJet, спасибо! 1 - фильтрация SRC адресов на интерфейсе (только авторизованные SRC адреса будут разрешены). работает для routed-трафика, если это L2 траффик на бридже - фильтр не применяется 2 - ok, делаем на сабах 3 - ok, делаем на сабах 4 - не понял :) 5 - будет + будет. причем на каждый маршрут можно свой dst MAC-адрес поставить (несколько клиентов в одном Q-in-Q например). а вложенный Q-in-Q - по идее не должно быть проблем, если как Link-interface использовать VLAN интерфейс... Но надо тестировать - хардварная акселерация тэгов может подкинуть грабли, но это решаемо. Вставить ник Quote
SyJet Posted March 13, 2015 Posted March 13, 2015 (edited) Пункт 4 - хотя логично :) я за ascii А вот бы встроенный dhcp, чтобы он к биллингу по радиусу сразу обращался - было бы супер, чтоб не городить ещё одну сущность. В аксселле отличная реализация - формирование логина вообще очень гибко. А пароль либо пустой либо mac Edited March 13, 2015 by SyJet Вставить ник Quote
martini Posted March 13, 2015 Posted March 13, 2015 а еще бы чтобы ДХЦП сервер с релеем работал .. вообще замечательно было бы ) по поводу 4 пункта , нужно оставить возможность ничего не изменять\добавлять в опции82 , на случай обработки пакетов релеем или радиусом или мускулом Вставить ник Quote
arni Posted March 13, 2015 Author Posted March 13, 2015 Спасибо, учтем. Опция dhcp-radius это интересно, тоже добавим. с option82 сделаем чтобы можно было ее заменить или добавить (если не установлена) Вставить ник Quote
SyJet Posted March 13, 2015 Posted March 13, 2015 Спасибо, учтем. Опция dhcp-radius это интересно, тоже добавим. с option82 сделаем чтобы можно было ее заменить или добавить (если не установлена) Так dhcp будет с радиус-аккаунтинк? :) --- Я тут подумал... А что по поводу дебиторщиков + whitelist для них? Чтоб те, у кого денег нет - авторизовывались, получали IP, но пользовались только ресурсами указанными в whitelist? Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.