GreyBox Опубликовано 31 октября, 2013 · Жалоба Добрый день. Небольшой местный провайдер, сеть несколько тысяч абонентов, 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 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг? В общем, надеюсь на Ваши ответы и советы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 31 октября, 2013 · Жалоба Добрый день. Небольшой местный провайдер, сеть несколько тысяч абонентов, 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 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг? В общем, надеюсь на Ваши ответы и советы. Вам как нельзя лучше подойдет accel-ppp, он умеет все что вам надо А еще большой плюс, что разработчик прямо тут Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 31 октября, 2013 · Жалоба Дальше странно. Через некоторое время клиент повторяет DHCP Request со своего полученного айпи на реальный IP-сервера, но до сервера этот запрос почему то не доходит (tcmpdump молчит и на интерфейсе клиента, и на интерфейсе к свитчу). Судя по всему свитч запрос и не перенаправляет от себя, и не пропускает. Дальше клиент начинает слать со своего IP броадкастом - тишина. Шлет с 0.0.0.0 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг? Сталкивались с таким Потому что этот запрос отправляется на DHCP юникастом. Свич его может не релеить - это зависит от прошивки. Почитайте внимательно http://www.ietf.org/rfc/rfc2131.txt , там не все так просто как могло бы быть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 31 октября, 2013 · Жалоба 1) Как оптимальней терминировать вланы на сервере? Потестил две схемы, "ip unnumbered"+роутинг и мост.А мост-то тут причём?Вланы на L2 должны быть изолированы! Как сделана терминация у меня: Каждому влану на роутере соответствует интерфейс. На интерфейсе поднята серая ipv4 подсеть, физлицам по /28, юрлицам по /24. Точно так же подаётся ipv6 /64. ipv6 адреса раздаются с помощью radvd. Некоторым клиентам индивидуально поданы белые ipv4 адреса. Они прописаны маршрутом-на-интерфейс поштучно, по /32. Чтобы "белые" клиенты видели друг друга, включён proxyarp. 2) DHCP. Первоначально планировал привязать пользователя не к порту (opt82), а к влану, т.к. часть свитчей не поддерживает Option 82, а заменить в ближайшем будущем врядли сможем. Да и со свитчами на доступ потом попроще будет, можно брать самое тупое железо. По маку из запроса и арп-таблице получаю интерфейс (VLAN), из биллинга вытаскиваю инфу о адресе, передаю в DHCP. Кто нибудь использует такую схему?Зачем так сложно?Для ipv4 isc-dhcpd сам всё умеет - он же видит, на какой интерфейс роутера пришёл запрос - и выдаёт адрес из соответствующего диапазона. А на ipv6 всё проще - выдаётся шлюз, а адрес клиент генерит себе сам по маку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GreyBox Опубликовано 1 ноября, 2013 · Жалоба Вам как нельзя лучше подойдет accel-ppp, он умеет все что вам надо А еще большой плюс, что разработчик прямо тут Я уже читал упоминания о нем здесь на форуме но сходу не понял, как его применять ) Спасибо, посмотрю. Сталкивались с таким Потому что этот запрос отправляется на DHCP юникастом. Свич его может не релеить - это зависит от прошивки. Почитайте внимательно http://www.ietf.org/rfc/rfc2131.txt , там не все так просто как могло бы быть. Прошивка на этом свитче последняя (стабильная). Да пусть бы не релеил, но он ведь еще и не пропускает DHCP-пакеты от клиента до сервера. А мост-то тут причём? Вланы на L2 должны быть изолированы! Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше. Некоторым клиентам индивидуально поданы белые ipv4 адреса. Они прописаны маршрутом-на-интерфейс поштучно, по /32. Чтобы "белые" клиенты видели друг друга, включён proxyarp. Это второй вариант, который я проверял. А как у Вас "белые" клиенты получают IP-адреса? Зачем так сложно? Для ipv4 isc-dhcpd сам всё умеет - он же видит, на какой интерфейс роутера пришёл запрос - и выдаёт адрес из соответствующего диапазона. А на ipv6 всё проще - выдаётся шлюз, а адрес клиент генерит себе сам по маку. Что то в эту сторону даже не думал. В принципе и в правду можно генерить раз в какое то время статический конфиг и привязывать пулы к интерфейсам. Предположим, я реализую роутинги, реальный айпишник висит на лупбаке, как у ISC с приемом броадкастов на куче интерфейсов? Ответить он на них сможет, если на сервере IP-ник к этим интерфейсам не привязан? (реальный IP + IP unnumbered) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adnull Опубликовано 1 ноября, 2013 · Жалоба Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше. Не надо никакого ebtables. Какой тогда смысл vlan городить, если вы превратили роутер в тупой свич? Достаточно включить proxyarp на нужных интерфейсах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GreyBox Опубликовано 1 ноября, 2013 · Жалоба Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше. Не надо никакого ebtables. Какой тогда смысл vlan городить, если вы превратили роутер в тупой свич? Достаточно включить proxyarp на нужных интерфейсах. Зачем включать proxy_arp, если при терминировании вланов через мост абоненты и так видят друг друга? proxy_arp для терминирования через роутинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 1 ноября, 2013 · Жалоба Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше. А зачем маршруты на роутере, если в каждом влане свой ip? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ArhAngel_John Опубликовано 7 ноября, 2013 (изменено) · Жалоба Нужно начать писать RFC на IPoE :) Столько споров. Я вот сейчас тоже SE100+IPoE пытаюсь настроить Изменено 7 ноября, 2013 пользователем ArhAngel_John Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
biox Опубликовано 7 ноября, 2013 · Жалоба Night_Snake как раз что бы знать в каком именно vlan находится тот или иной ip. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...