GreyBox

Сейчас в своём коде посмотрел - я возвращаю RLM_MODULE_REJECT. Да, accel в таком случае несколько раз переспрашивает, но это нормально. На самом деле, здесь виноват протокол RADIUS (sic!). Я искал этот момент в RFC - написано, что если RADIUS-сервер не может сделать запись accounting, то он не должен отвечать вообще. Reject-а у accounting не предусмотрено. accel, как порядочный RADIUS-клиент, сначала пытается повторить попытку (а вдруг проблема с сетью? а вдруг ещё ответит?), после чего вырубает сессию. FreeRADIUS, кстати, умеет кешировать запросы и для 2-3 одинаковых accounting request-ов может запустить обработчик всего один раз. Посмотрите в эту сторону. Стоял большой таймаут ожидания ответов RADIUS, поэтому accel и слал аккаунтинг один за другим... Все ок :) Чем отличается soft и hard? terminate csid <id> [soft|hard]- terminate session by calling station id

Abram, спасибо, уже нашел по таймауту аттрибут Radius: Session-Timeout, все ок. Насчет "не отвечаю" - так и не понял, как это сделать во FreeRadius. Если возвращать из скрипта вместо RLM_MODULE_OK - RLM_MODULE_REJECT, accel начинает сыпать аккаунтинги один за другим. А чтобы совсем не ответить - не нашел опции. Повесил пока в acct-interim-update проверку услуги и обрыв через accel-cmd terminate. Правда, при этом FreeRadius отбрасывает stop-пакет аккаунтинга из accel-cmd. Не слать бы его тогда совсем.

Подскажите, как правильно реализовать принудительное отключение пользователя - заблокирован, таймаут сессии или сменился IP и нужно установить новую сессию. Может быть у accel есть какой либо параметр для этого, чтобы он раз в какое то время при получении запроса продления аренды от клиента опрашивал RADIUS-сервер. Пока приходит в голову только повесить на аккаунтинг в скрипте запросов к БД проверку таймаута и статуса услуги и в случае необходимости убивать сессию через accel-cmd terminate.

Спасибо конечно, но это давно читано-перечитано (и ман, и ридми) и тот же Framed-IP-Address, без которого не заработало, упоминается там только в L4-редиректе :)

С "no free IPv4 address" в связке с радиусом разобрался, из документации нужны атрибуты: ATTRIBUTE DHCP-Client-IP-Address 240 ipaddr ATTRIBUTE DHCP-Router-IP-Address 241 ipaddr ATTRIBUTE DHCP-Mask 242 integer если к ним добавить Framed-IP-Address как IP абонента - все ок. При этом судя по всему DHCP-Clent-IP-Address не нужен? Без него также работает. В связи с этим вопрос, подскажите, какие атрибуты должен отдавать радиус для accel-ppp для нормальной работы ipoe? (Если кто поделится рабочим конфигом Freeradius буду благодарен)

xeb, модуль загрузил, поправил конфиг - тоже самое... Уточню на всякий случай, на сервер через eth2 приходит куча вланов, в том числе q-in-q vlan 934, в котором идут 1001, 1002, ... Поднят интерфейсы vlan934, vlan1001, vlan1002: VLAN Dev name | VLAN ID Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD vlan934 | 934 | eth2 vlan1001 | 1001 | vlan934 vlan1002 | 1002 | vlan934 Более того, прикрутил радиус, опять: [2013-11-07 18:41:08]: info: vlan1001: send [RADIUS(1) Access-Request id=1 <User-Name "vlan1001"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 6> <NAS-Port-Type Ethernet> <Calling-Station-Id "00:0c:76:21:0b:1c"> <Called-Station-Id "vlan1001"> <User-Password >] [2013-11-07 18:41:08]: info: vlan1001: recv [RADIUS(1) Access-Accept id=1 <Service-Type Framed-User> <DHCP-Client-IP-Address 95.X.X.2> <DHCP-Router-IP-Address 95.X.X.1> <DHCP-Mask 32>] [2013-11-07 18:41:08]: info: vlan1001: vlan1001: authentication succeeded [2013-11-07 18:41:08]: error: vlan1001: no free IPv4 address [2013-11-07 18:41:08]: debug: vlan1001: terminate [2013-11-07 18:41:08]: info: vlan1001: ipoe: session finished

accel-ppp собран из исходников, взял git'ом сегодня Пытаюсь настроить простую схему: Реальные IP, IP unnumbered, vlan-peer-user. Юзер в vlan1001, должен получить IP 95.X.X.2, интерфейс создан, маршрут добавлен (95.X.X.2 dev vlan1001 scope link src 95.X.X.1). IP шлюза 95.X.X.1, висит на lo. accel-ppp.conf [core] log-error=/var/log/accel-ppp/core.log thread-count=4 [log] level=5 log-file=/var/log/accel-ppp/accel-ppp.log log-emerg=/var/log/accel-ppp/emerg.log log-fail-file=/var/log/accel-ppp/auth-fail.log copy=1 [modules] log_file ipoe #ippool [ipoe] noauth=1 verbose=5 username=ifname lease-time=60 max-lease-time=360 shared=0 ifcfg=0 mode=L2 start=dhcpv4 interface=vlan1001,range=95.X.X.0/24 #interface=vlan1001 #ip-pool=ipoe #[client-ip-range] #95.X.X.0/24 #[ip-pool] #gw-ip-address=95.X.X.1 #95.X.X.1-254,ipoe В логах: emerg.log min-mtu cann't be greater then mtu/mru iprange: section 'client-ip-range' not found in config file, pptp and l2tp probably will not work... Я так понимаю, это к ipoe не относится? (хотя client-ip-range пробывал указывать, вторая строчка из лога уходит, результат тот же) accel-ppp.log [2013-11-06 18:37:10]: info: ipoe: start interface vlan1001 (range=95.X.X.0/24) [2013-11-06 18:37:10]: msg: accel-ppp version 6d160f30d56df6433ea30e504e0dfeb626d52aa5 [2013-11-06 18:37:31]: info: : recv [DHCPv4 Discover xid=77ed8a chaddr=00:0c:76:21:0b:1c <Message-Type Discover> <Request-IP 95.X.X.2> <Host-Name aaa> <Request-List Subnet,Broadcast,Time-Offset,Router,Domain-Name,DNS,119,Host-Name,44,47,MTU,Classless-Route,NTP>] [2013-11-06 18:37:31]: info: vlan1001: vlan1001: authentication succeeded [2013-11-06 18:37:31]: error: vlan1001: no free IPv4 address [2013-11-06 18:37:31]: debug: vlan1001: terminate [2013-11-06 18:37:31]: info: vlan1001: ipoe: session finished [2013-11-06 18:37:34]: info: : recv [DHCPv4 Discover xid=77ed8a chaddr=00:0c:76:21:0b:1c <Message-Type Discover> <Request-IP 95.X.X.2> <Host-Name aaa> <Request-List Subnet,Broadcast,Time-Offset,Router,Domain-Name,DNS,119,Host-Name,44,47,MTU,Classless-Route,NTP>] [2013-11-06 18:37:34]: info: vlan1001: vlan1001: authentication succeeded [2013-11-06 18:37:34]: error: vlan1001: no free IPv4 address [2013-11-06 18:37:34]: debug: vlan1001: terminate [2013-11-06 18:37:34]: info: vlan1001: ipoe: session finished Пробывал и с ip-pool, тоже самое. Почему он не видит свободных IP в указанном диапазоне? P.S. Я так понимаю, модуль ядра для начала сессии по DHCP не нужен. Но если его не загружать, то в лог сваливается: [2013-11-06 18:43:26]: debug: libnetlink: RTNETLINK answers: No such file or directory [2013-11-06 18:43:26]: error: genl: error talking to kernel [2013-11-06 18:43:26]: warn: ipoe: unclassified packet handling is disabled

Не надо никакого ebtables. Какой тогда смысл vlan городить, если вы превратили роутер в тупой свич? Достаточно включить proxyarp на нужных интерфейсах. Зачем включать proxy_arp, если при терминировании вланов через мост абоненты и так видят друг друга? proxy_arp для терминирования через роутинг.

Я уже читал упоминания о нем здесь на форуме но сходу не понял, как его применять ) Спасибо, посмотрю. Прошивка на этом свитче последняя (стабильная). Да пусть бы не релеил, но он ведь еще и не пропускает DHCP-пакеты от клиента до сервера. Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше. Это второй вариант, который я проверял. А как у Вас "белые" клиенты получают IP-адреса? Что то в эту сторону даже не думал. В принципе и в правду можно генерить раз в какое то время статический конфиг и привязывать пулы к интерфейсам. Предположим, я реализую роутинги, реальный айпишник висит на лупбаке, как у ISC с приемом броадкастов на куче интерфейсов? Ответить он на них сможет, если на сервере IP-ник к этим интерфейсам не привязан? (реальный IP + IP unnumbered)

Добрый день. Небольшой местный провайдер, сеть несколько тысяч абонентов, 1 VLAN на всех PPPoE, 1 влан на всех реальщиков, часть абонентов через NAT, часть через статические реальные IP, фильтрация и ограничения скорости частью на доступе, частью в ядре, частью нет (свитчи не держат ACLы). Решили разгрести этот бардак и перевести сеть на VLAN-peer-user, выдачу IP-адресов через DHCP и фильтрацию\скорость централизованно на сервере. Вроде как если смотреть с далеко все понятно и сложностей не видно. Но как начнешь тестировать... Гугл замучан, но всех вопросов не решил. На доступе D-Link DES-3200\3552, сейчас смотрим в сторону аналогичных коммутаторов SNR. Все абонентские вланы через q-in-q идут в ядро на сервер Debian Wheezy, пока для теста поднят в ESX, если потребуется прикупим физический сервак. Плюс нужно добавить любимое всеми IPTV. Вопросы: 1) Как оптимальней терминировать вланы на сервере? Потестил две схемы, "ip unnumbered"+роутинг и мост. С мостом почему то возникли проблемы, переодически теряется часть пингов до сервера с любого порта (2-4%). При роутинге все ок. Побороть так и не смог. Wheezy с последним стабильным ядром и обновлениями. ESX 5 и тоже обновлен. Вланов в мосте всего лишь два. Пока нет возможности потестить на физическом сервере, виртуалка мешает? 2) DHCP. Первоначально планировал привязать пользователя не к порту (opt82), а к влану, т.к. часть свитчей не поддерживает Option 82, а заменить в ближайшем будущем врядли сможем. Да и со свитчами на доступ потом попроще будет, можно брать самое тупое железо. По маку из запроса и арп-таблице получаю интерфейс (VLAN), из биллинга вытаскиваю инфу о адресе, передаю в DHCP. Кто нибудь использует такую схему? Вроде как на бумаге все ок. Тестирую на мосте, бог с ними с пингами пока. Для DHCP - freeradius как единственный умеющий через скрипт запрашивать динамическую инфу. Странно, но Freeradius с dhcp-броадкаст подружить не удалось, снифером вижу запрос от клиента, в логах радиуса все ок, получил, обработал, выдал айпи и вроде как отправил. Но в tcpdump'e на сервере тишина. Версия 2.2.0. При dhcp-юникаст (opt82) все ок. В варианте с роутингом так и не понял, как настроить DHCP-сервер - решил пока попробывать dnsmasq, броадкаст-запросы от клиентов видит и в лог падает строчка, что на интерфейсе, откуда пришел запрос нет IP-адреса, правильно, адрес висит на loopback. Соответственно ответить не может. 3) После всех этих экспериментов решил вернуться к классической схеме с Option 82. По началу, на DES-3552 сходу не завелось, шлет dhcp-запрос только с портов, не сидящих в влане. Нетегированный порт в влане - тишина. Обновили прошивку, вроде как все ок: IP свитча 192.168.0.171, сервера 192.168.0.172. Клиентам выдаются IPники из реального диапазона. Freeradius слушает интерфейс\IP 192.168.0.172. Броадкаст-запрос от клиента релеется юникастом, приходит на сервер, сервер отвечает, свитч отдает IP-клиенту. Дальше странно. Через некоторое время клиент повторяет DHCP Request со своего полученного айпи на реальный IP-сервера, но до сервера этот запрос почему то не доходит (tcmpdump молчит и на интерфейсе клиента, и на интерфейсе к свитчу). Судя по всему свитч запрос и не перенаправляет от себя, и не пропускает. Дальше клиент начинает слать со своего IP броадкастом - тишина. Шлет с 0.0.0.0 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг? В общем, надеюсь на Ваши ответы и советы.

К сожалению, варианта "поставить новое железо" нет, приходится работать с тем что есть. Да и в принципе схема на 3200 вполне устраивает. У меня на: DES-3200-10/A1: Boot PROM Version : Build 1.00.007 Firmware Version : Build 1.28.009 Hardware Version : A1 все работает. Окончательный вариант конфига: disable asymmetric_vlan enable pvid auto_assign config vlan default delete 1-10 config vlan default add tagged 9-10 create vlan 15 tag 15 config vlan 15 add tagged 9-10 create vlan 1000 tag 1000 config vlan 1000 add tagged 10 config vlan 1000 add untagged 9 enable qinq create vlan_translation replace cvid 1 svid 1 create vlan_translation replace cvid 15 svid 15 create vlan_translation add cvid 1001 svid 1000 create vlan_translation add cvid 1002 svid 1000 create vlan_translation add cvid 1003 svid 1000 create vlan_translation add cvid 1004 svid 1000 create vlan_translation add cvid 1005 svid 1000 config qinq ports 10 role nni outer_tpid 0x8100 trust_cvid disable vlan_translation disable config qinq ports 9 role uni outer_tpid 0x8100 trust_cvid enable vlan_translation enable config gvrp 9 state disable ingress_checking enable acceptable_frame admit_all pvid 1000 Вланы 1001-1005 оборачиваются в влан 1000 и идут дальше по сетке. Вланы 1 и 15 тегированными без навешивания q-in-q в обе стороны. 9 порт - на "абонентский" свитч. 10 порт - в сетку.

По сути получится одно и тоже, он автоматом сменит PVID на таком порту. Конфиг для DES-3200-10/A1: disable asymmetric_vlan enable pvid auto_assign config vlan default delete 1-10 config vlan default add tagged 9-10 create vlan 15 tag 15 config vlan 15 add tagged 9-10 create vlan 1000 tag 1000 config vlan 1000 add tagged 9-10 enable qinq create vlan_translation replace cvid 1 svid 1 create vlan_translation replace cvid 15 svid 15 create vlan_translation add cvid 1001 svid 934 create vlan_translation add cvid 1002 svid 934 create vlan_translation add cvid 1003 svid 934 create vlan_translation add cvid 1004 svid 934 create vlan_translation add cvid 1005 svid 934 config qinq ports 9 role uni outer_tpid 0x8100 trust_cvid enable vlan_translation enable config qinq ports 10 role nni outer_tpid 0x8100 Без "trust_cvid enable" работать не хочет.

Спасибо, уже нашел, но т.к. там бета сомневался ставить или нет. Попробуем. Взял пока для теста другое железо: DES-3552 Boot PROM Version : Build 1.00.B008 Firmware Version : Build 2.60.017 Hardware Version : A3 С таким конфигом все работает config vlan default delete 1-52 config vlan default add tagged 49-50 create vlan 15 tag 15 config vlan 15 add tagged 49-50 advertisement disable create vlan 16 tag 16 config vlan 16 add tagged 49-50 advertisement disable create vlan 1000 tag 1000 config vlan 1000 add tagged 49-50 advertisement disable enable qinq config qinq inner_tpid 0x8100 config qinq ports 1-52 add_inner_tag disable config qinq ports 1-48,50-52 role nni missdrop disable outer_tpid 0x8100 config qinq ports 49 role uni missdrop disable outer_tpid 0x8100 create vlan_translation ports 49 replace cvid 1 svid 1 create vlan_translation ports 49 replace cvid 15 svid 15 create vlan_translation ports 49 replace cvid 16 svid 16 create vlan_translation ports 49 add cvid 1001 svid 1000 create vlan_translation ports 49 add cvid 1002 svid 1000 create vlan_translation ports 49 add cvid 1003 svid 1000 create vlan_translation ports 49 add cvid 1004 svid 1000 create vlan_translation ports 49 add cvid 1005 svid 1000 Но решение немного не нравится тем, что нужно навешивать кучу vlan_translation. Может возможно как то упростить? Странно что на DES-3200 с таким же конфигом оно не завелось. UPD: Отвечу сам себе: config port_vlan 49 pvid 1000 create vlan_translation ports 49 replace cvid 1 svid 1 create vlan_translation ports 49 replace cvid 15 svid 15 create vlan_translation ports 49 replace cvid 16 svid 16 vlan_translation для 1001-... в таком случае не нужны

А можно ссылку на обновленную прошивку, ни на русском офф-сайте, ни здесь ничего не нашел. Про selective qinq читал, но реализовать на данном свитче не получилось.

Добрый день! Есть два свитча, DGS-3010G и DES-3200-10/A1. Задача - собрать вланы 1001-1005 в один 1000 с двойным тегом (Q-in-Q) на DES-3200 и отправить дальше по сети. При этом на все остальные вланы (1, 15, 16) двойное тегирование не вешать. На схеме более наглядно. С DGS-3010G все вланы (1, 15-16, 1001-1005) выходят с тегом. DES-3200-10/A1: Boot PROM Version : Build 1.00.007 Firmware Version : Build 1.28.009 Hardware Version : A1 Два дня экспериментов на стенде ничего не дали, или второй тег не вашется, или вешается на все вланы.