Jump to content
Калькуляторы

VLAN-peer-user, DHCP Option 82. Вопросы

Добрый день.

 

Небольшой местный провайдер, сеть несколько тысяч абонентов, 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 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг?

 

В общем, надеюсь на Ваши ответы и советы.

Share this post


Link to post
Share on other sites

Добрый день.

 

Небольшой местный провайдер, сеть несколько тысяч абонентов, 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, он умеет все что вам надо

А еще большой плюс, что разработчик прямо тут

Share this post


Link to post
Share on other sites
Дальше странно. Через некоторое время клиент повторяет DHCP Request со своего полученного айпи на реальный IP-сервера, но до сервера этот запрос почему то не доходит (tcmpdump молчит и на интерфейсе клиента, и на интерфейсе к свитчу). Судя по всему свитч запрос и не перенаправляет от себя, и не пропускает. Дальше клиент начинает слать со своего IP броадкастом - тишина. Шлет с 0.0.0.0 броадкастом - сервер отвечает. Это нормальное поведение свитча или очередной баг?

 

Сталкивались с таким

Потому что этот запрос отправляется на DHCP юникастом. Свич его может не релеить - это зависит от прошивки.

Почитайте внимательно http://www.ietf.org/rfc/rfc2131.txt , там не все так просто как могло бы быть.

Share this post


Link to post
Share on other sites

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 всё проще - выдаётся шлюз, а адрес клиент генерит себе сам по маку.

Share this post


Link to post
Share on other sites

Вам как нельзя лучше подойдет 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)

Share this post


Link to post
Share on other sites
Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше.

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

Share this post


Link to post
Share on other sites
Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше.

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

Зачем включать proxy_arp, если при терминировании вланов через мост абоненты и так видят друг друга? proxy_arp для терминирования через роутинг.

Share this post


Link to post
Share on other sites

Их же можно изолировать на мосту через ebtables? Мне наоборот, вариант с мостом больше нравится - не нужно создавать маршруты. Хотя нагрузка на сервер наверное будет выше.

А зачем маршруты на роутере, если в каждом влане свой ip?

Share this post


Link to post
Share on other sites

Нужно начать писать RFC на IPoE :)

Столько споров.

Я вот сейчас тоже SE100+IPoE пытаюсь настроить

Edited by ArhAngel_John

Share this post


Link to post
Share on other sites

Night_Snake как раз что бы знать в каком именно vlan находится тот или иной ip.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this