Как блокировать трафик через acl (к примеру netbios, smb на основе портов) при включенном IPBM + DHCP Snooping?
IP Mac Binding создаёт правила в акл для запрета / разрешения доступа , при этом profile id = 513, а вот access_id = 1 для первого порта , в момент когда доступ разрешён, данное правило permit.
В итоге, даже если создать профиль с id = 3 (1 и 2 по умолчанию заняты системой) , а access_id > 1 , то правило не срабатывает, и получается что если пользователь получил айпи, и попал в акцесс лист с пермитом от IPMB , то уже никакие фильтрующие правила на него не срабатывают, как быть?
прошивка: Build 4.34.B007 , на 4.30.B008 такая-же проблема

на A1 ревизии связка работает идеально...

Подскажите как быть, закупили большую партию ревизии C1 , деваться некуда, фильтровать нужно, знали бы что эта ревизия такая не допиленная ни за что бы не купили...

Пример конфига:

На С1 есть отдельные команды
config filter netbios
config filter extensive_netbios

я это пониманию, но помимо этих правил у меня есть ещё другие запрещающие правила которые создаёт биллинг при блокировке абонента, таким образом абонент имеет айпи , но может зайти только в биллинг...

вот пример:


последнее правило создаёт биллинг для заблокированного пользователя, запрещая ходить внутри сети кроме биллинга и шлюза...

или вы подразумеваете что вместе с imb не будут работать acl ?

Уважаемые, обнадёжьте чем нибудь пожалуйста, какие варианты возможны использовать ACL вместе с IMB ?

Совет автору темы - переходите на vlan per customer.
Это решает ВСЕ проблемы. Без преувеличений.

IMPB тоже очень даже решает все проблемы.
Мы должнику по дхцп назначаем IP из левого серого диаппазона, на шлюзе весь его трафик редиректится на страничку "заплати денег". А чтобы было неповадно внутрисеть заюзать, на порту должника ставится скорость 64Кбит/сек.

а как вы решаете проблему с внутри сетевым трафиком ? гоните его до головы или до свитча 3 уровня ? зачем такие накладные расходы когда imb для таких целей и создавался ?

тоже вариант, но у меня сделано (моё имхо) более быстрее, когда у абонента происходит просчёт отчётного периода, ему тут же на порт вешаются акл правила, и он сразу же лицезреет страничку "заплати денег" куда бы он ни ломанулся... в данном случае намного меньше вопросов "почему у меня перестало всё работать"

Вам просто указывают возможные варианты БЕЗ ацл-правил...

это понятно, за что я несомненно благодарен, но как же без ацл ...

предыдущая ревизия (A1) всё умеет и идеально работает в такой схеме, почему же в этой надо было так сильно изменять, неужели ацл давало на столько большую нагрузку что его решили таким образом "оптимизировать" ?

Приведу примеры, что не решает IMPB:

1) Клиенты видят друг друга, и это создаёт ряд проблем.
Конкретный пример - соседи кооперируются: один берёт 100-мегабитный тариф, остальные берут самые дешёвые тарифы, ставят прокси и радуются.
Можно накостылить зарезание прокси-трафика через ACL - но они будут обходить это, пока не зарежем межабонентский трафик полностью.
Можно ограничивать скорость свичом - но такое ограничение, в отличие от шейпа на роутере, вызывает массу жалоб на скорость и потери.

2) Невозможно выдавать IPv4 адреса подсетями.
При использовании vlan per customer, я выдаю клиентам по DHCP серые подсети - по блоку 10.x.x.x/24 на клиента.
Это позволяет клиенту включать у себя любое количество компьютеров без необходимости в приобретении и настройке роутера. Достаточно дешёвого неуправляемого свича.
Клиент при этом может быть любым - начиная от старушки-пенсионерки и заканчивая офисом на 70 компьютеров.

3) При внедрении IPv6 придётся заменять старые свичи доступа. Для сравнения - при vlan per customer, IPv6 прекрасно работает даже на ископаемых DES-3226, которые у меня в сети есть до сих пор. И будут, пока они ещё работоспособны, а порты доступа на 100 мегабит ещё актуальны.

Это тоже создаёт, а не решает проблемы. Если не делать DHCP Lease Time в единицы секунд, должник получит левый адрес далеко не сразу, и для начала ему на длительное время доступ обрубится вовсе. А когда он оплатит (напоминаю, в современных реалиях оплатить можно киви кошельком в три клика!) - доступ так же точно далеко не сразу врубится.

А в чём проблема-то? Гоним до головы, да.Можно уточнить, где тут накладные расходы?

Приведу простейший расчёт, который опровергает наличие каких бы то ни было накладных расходов.
К примеру, для простоты расчётов, имеем сеть на 100 домов по архитектуре "по влану на дом", т.е. 100 вланов.
Кто-то из юзеров раздаёт торрент.
Для простоты предположим, что его качают 100 абонентов, по абоненту в каждом доме.
В итоге, со схемой "по влану на дом" локальной эта раздача станет для ОДНОГО абонента - соседа раздающего.
Остальные 99 будут тянуть через голову.
Итого в данном примере имеем 1% перегрузку. Это даже не смешно.
И сколько бы не было локальных раздач (причём, совершенно неважно, торренты это, dc++ или локальный порносайт), статистика неумолима - абсолютное большинство посетителей придёт из других домов.
А вот для расшаривания интернета, описанного выше, "колхоз" просто идеален