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

[GreyBox]

Добрый день.

 

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

 

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

[h1vs2]

Добрый день.

 

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

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

[Negator]

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

 

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

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

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

[rdc]

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

[GreyBox]

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

[adnull]

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

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

[GreyBox]

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

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

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

[Night_Snake]

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

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

[D_Ev_io]

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

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

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

Edited November 7, 2013 by ArhAngel_John

[biox]

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