Здравствуйте! Подскажите, можно ли как-нибудь запретить клиентам работать с IP, вписанными вручную, то есть разрешать работу только с параметрами из сообщения DHCP ACK. Коммутаторы DES-3200, DES-1210-28/ME/B2, DES-3526, DES-1228/ME(/B1). Спасибо.

Запретить с какой целью? Клиент должен быть в принципе лишен возможности прописать IP вручную или же требуется запретить ему использовать чужие IP? Вообще есть функционал IP-MAC-Port binding в режиме DHCP Snooping, но он применим скорее в корпоративной среде. В ISP я бы не рекомендовал его использовать.

_________________
D-Link Switches: Tips & Tricks

Клиент должен быть лишён возможности использовать IP, отличный от выделенного ему провайдером. IP-MAC-Port binding, насколько я понимаю, нельзя использовать без MAC-адреса. Вообще, интересно, как эту проблему решают провайдеры с Option 82 без VLAN-Per-User. Игры с ARP на шлюзе - не лучший вариант, так как клиенту никто не мешает вписать себе IP шлюза и сломать свой сегмент. Traffic_segmentation запретит клиентам обмениваться трафиком напрямую, что тоже нежелательно.

Кто это вам такое сказал? Есть коммутатор, есть влан, есть порт - по этим параметрам и отдавайте IP адрес, МАС уже прописан в DHCP пакете.

Крайне дибильная схема, реализовывать такую смысла нет, только VLAN-Per-User

Выходите наконец из 90-х, сейчас таким суровым извращением никто из более-менее адекватных админов не занимается.

Как раз желательно, ибо нефиг друг другу червей рассылать. Востребованность внутреннего трафика сейчас близится к 0%, поэтому Traffic_segmentation скорее на пользу пойдёт.

Выше я упоминал про режим DHCP Snooping. Работает это примерно так: а) дхцп пакеты от клиента пропускаются наверх. б) дхцп сервер выдает адрес клиенту. в) коммутатор видит, что адрес был выдан дхцп и создает в специальной таблице разрешающую запись для данных ip+mac+port. Т.е. все работает автоматически, но не все так хорошо, как может показаться:
1. Если таблица по какой то причине сбросилась (перезагрузился коммутатор) то надо как то заставить клиента переполучить IP-адрес
2. Клиентские устройства часто могут смешивать трафик в кучу, т.е. есть ненулевая вероятность, что через абонентский роутер "наверх" будут просачиваться пакеты с внутренними адресами. Это может привести к блокировке разрешенных устройств на порту
3. Сам по себе функционал IMP зачастую ведет себя странно (не обновилась запись, заблокировалась валидная связка, разрешилась невалидная и т.п.)
4. Есть основания думать, что работа IMP может быть связана с "конфликтами хеш", что практически исключает применение функционала на моделях DES-3028 и DES-3200-28/A1/B1.
В общем, я попробовал - не понравилось. Хотя некоторые как то приноровились.


Раньше IP-адрес мы выдавали абоненту. Теперь же это свойство порта коммутатора. Т.е. заранее известно как настраивать порт - задолго до того, как туда будет включен абонент. На каждом порту прописаны правила, разрешающие ARP-ответы по определенному признаку (4-й октет в определенном диапазоне). Правила подходят для всех коммутаторов данной ревизии, т.е. нет нужды конфигурировать каждый свичик индивидуально. Так что абонент может поставить себе любой IP, но об этом никто не узнает, т.к. ARP-ответ будет пропущен только с разрешенным адресом.

_________________
D-Link Switches: Tips & Tricks

Тут от многих факторов зависит. От серости/белости адресов и п.р.
Мы сейчас влан-на-юзера в принципе сделать не сможем, даже если сильно захотим - L3 железки не прожуют, это 100%. Надо будет переделывать много чего. Железо сейчас обновляется, но медленно. Потому влан-на-свич + опция 82 сейчас для нас это золотая середина.

_________________
D-Link Switches: Tips & Tricks

А зачем им обмениваться трафиком напрямую?
Все эти "обмены напрямую" не несут абсолютно никакой пользы, зато оставляют возможными тысячу способов нагадить соседу.

От серости-белости это никак не зависит.
Я выдаю абонентам как серые, так белые адреса - при влане-на-юзера.Опять же - у меня при влане-на-юзера всё построено на L2. На доступе продолжают работать даже древнейшие 3226S, установленные более десяти лет назад. Всё прекрасно пашет.

В данный момент у меня похожая ситуация: PPPoE влан на свич/дом/несколько домов. Но это не мешает мне добавлять на свич дополнительный влан для определённых абонентов.
Сейчас я выдал всего 30 выделенных вланов, при учёте того, что PPPoE вланов у меня на порядок больше. И даже сейчас я уже почуствовал, насколько это удобнее по управлению на L3 и прозрачнее для L2, т.е. по сути, как и сказал RDC, вам глубоко плевать, что вообще у вас за свич на доступе у вас стоит, какой в нём функционал и насколько он глючный.

Пробуйте всё-таки vlan-per-user, попытка попробовать по железу - от 5000 рублей, но даже она того стОит.

Спасибо всем за ответы!



Подскажите, как Вы организовали DHCP в такой схеме. Я в интернете нашёл вариант с DHCP-релеем на базе Accel PPP и Option 82 на базе клиентских VLAN и Q-in-Q. Сервером DHCP в такой схеме может выступать Freeradius.

У Вас так и организовано? Или есть другая схема? Поделитесь, пожалуйста, опытом, а то это на данный момент единственная схема, которая позволяет не отказываться от старых коммутаторов типа DES-3026 и DES-1228/ME Rev. A.

У меня сделано так:
- на доступе от свичей требуются только вланы, Option 82 не используется
- на агрегации стоят DGS-3120-24SC, они сворачивают пачку вланов доступа во "внешний" влан qinq
- пачка qinq вланов идёт на PC-роутеры, на которых запущено соответствующее количество ip-интерфейсов.
На каждом ip-интерфейсе PC-роутера поднята серая подсеть, /28 для физлиц, /24 для юрлиц.
Запущен isc-dhcpd - он видит, с какого интерфйса пришёл dhcp запрос, и отдаёт адрес из соответствующей подсети.

Схема:
свич с вланами - циска 3750-24 - фряха - интернет
На циске IP Unnumbered, она же является DHCP релеем, на ней же включен DHCP Snooping, в изначальном конфиге сгенерированы только потенциально-используемые вланы (50 штук) и интерфейсы к ним
На фряхе ISC-DHCP для выдачи IP адресов по Option 82, выдаю основываясь на влане и IP адресе циски, конфиг генерирует биллинг автоматически, DHCP сервак патченный, подгрузка когфига и ребут DHCP сервака так-же автоматизирован.
На фряхе же включен IPFW для шейпинга и включения/выключения абонентов.
На фряхе же есть возможность использовать IPFW NAT для серых адресов.
Считать трафик буду через NetFlow с интерфейса, который смотрит на циску.

В данный момент работаю только над включением/выключением абонентов и шейпингом.

Всё это добро на узле комутируется через DGS-3650. Конфиги циски и tables/pipes IPFW генерируются биллингом.
В будущем, как и RDC, планирую заворачивать абонентские вланы во второй тег, и на ту или иную циску с DGS уже отдавать в развёрнутом виде.
Циска стоит только для того, чтобы до серваков не доходил абонентский ethernet, серваки и DGS-3650 через RIP получают маршруты на абонентов.

а циска тут не является ли лишним звеном?
у меня это работает без циски

Если хорошо посмотреть - то да, является, однако это во первых избавляет сервак от клиентского езернета (а там всякое), во вторых, может быть с учётом наших особенностей (в плане квалификации штата), сам конфиг сервака значительно упрощается, работая лиш таблицами и пайпами, ну и в третьих IP Unnumbered на FreeBSD делать несколько костыльно.

Какова цель этого избавления от езернета?

Проблему ручных настроек я решил так:
в биллинге заранее создаются пачки неактивированных учёток.
При этом биллинг генерит конфиги для PC-роутеров и свичей.
Пример - нужно поставить новый свич. В биллинге жмём кнопку "добавить 24 учётки". Создаются 24 учётки, создаётся пачка интерфейсов на PC-роутере, создаётся текстовый файл с кучей команд create vlan / config vlan. Далее остаётся только скопипастить его в консоль свича, а роутер трогать не надо вовсе.
Все свичи у меня D-Link, копипаста универсальна.

Проблему квалификации штата я решил так:
когда монтажники подключают абонента, учётка, вланы и интерфейсы уже давно созданы заранее.
Осталось только воткнуться в любой свободный порт и ввести в получившемся веб-интерфейсе код активации.

Unnumbered я использую только для внешних ipv4 адресов, для физлиц это отдельная платная услуга.
Делается это на FreeBSD не просто, а очень просто:
route add x.x.x.x/32 -iface <влан-на-абонента>

Серые ipv4 адреса нарезаны по /28 на влан, там нет никакого смысла делать unnumbered, их хватит на всех и навсегда.
ipv6 - /64 на влан, стандартно.

У меня серых адресов нет и пока не планируется, белых закуплено достаточно, поэтому только IP Unnumbered. Я пытаюсь найти решение, которое позволило бы привязать на сервере DHCP IP к интерфейсу. На доступе будут DES-1228/ME, DES-3200, DES-3026, DES-3028/52, DES-3526/3528, DES-1210/ME/B2. На агрегации - DGS-3627G/DGS-3620-28SC.
Есть у кого-то решение, позволяющее привязать IP к интерфейсу без цисок и прочей радости?