По-топорному просто: БЖБ нечего не знает о isc-dhcpd , а isc-dhcpd ничего не знает о БЖБ.
Допустим у нас есть N вланов на каждого юзера по влану.
Схема сети - смешенная звёздно-гирляндная с зоопарком моделей и прошивок свитчей на агрегации и на доступе. Эти свитчи ничего не знают о dhcp-relay и знать не должны.
opt-82 вствляет один-единственный свитч на всю сеть, включённый одним единственным портом , развиланеным на все вланы юзеров + один влан в котором слушает isc-dhcpd ( этот же влан- управляющий для этого свитча).
Допустим в влане 100 живёт сеть 10.129.0.0/29 ( 10.129.0.1 - адрес шлюза . 10.129.0.2 - 10.129.0.6 - ипы на клиентских устройствах.).
В влане 101 будет жить сеть 10.129.0.8/29 ( 10.129.0.9 - адрес шлюза . 10.129.0.10 - 10.129.0.14 - ипы на клиентских устройствах.)
В влане 102 будет жить сеть 10.129.0.16/29 ( 10.129.0.17 - адрес шлюза . 10.129.0.18 - 10.129.0.22 - ипы на клиентских устройствах.)
и т.д..
Все вланы терминируются на микротиках по 256 вланов на один 1100AHx2 ( ипы клиентских шлюзов стоят на них).
В принципе это роли не играет. Просто терминаторы вланов в виде микротиков выбраны из того грустного факта что люди в нашем саппорте более-менее научились ёрзать мышью по винбоксам и как огня боятся командной строки линуксов.
Файрволл на микротиках сконфигурён так ,что при закрытых инет-сервисах в договорах клиентов им можно ходить куда-угодно, кроме собственно большого инета (т.е ип клиенту выдаётся всегда , выдаётся один и тот-же и не зависит от состояния его инет.сервиса).
Теперь самое плохое , что заставляет меня всё время делать робкие попытки мигрировать всё это дело на БЖБ :
В ресурсах ип-адресов модуля инет приходится делать два списка :
-основной , содержащий записи вида :
10.129.0.0 - 10.129.0.0
10.129.0.8 -10.129.0.8
10.129.0.16 -10.129.0.16
и т.д. с шагом 8
-дочерний вида:
10.129.0.2 - 10.129.0.6
10.129.0.10 - 10.129.0.14
10.129.0.18 - 10.129.0.22
и т.д. с шагом 4
Т.е. сколько юзеров - столько и записей в этих 2-х списках.
Руками набивать долго ! .Один раз я сделал это для всех потенциальных юзеров в начале бытия и больше к счастью этим делом заниматься никому не надо, но для новых инсталляций это конечно может привратиться в кошмар!
Основной список нужен для того чтобы в основной инет-сервис договора добавлять ип-адрес клиента и его влан , чтобы на микроте исполнялись правила :
Код:
sa.command.serv.create.1=/ip/firewall/address-list/add\n=address=$ip/29\n=list=ACCESS_LIST\n=comment=!!$servId!!\n=disabled=yes
sa.command.serv.create.2=/queue/simple/add\n=max-limit=0/100M\n=target=vlan$vlan\n=name=vlan$vlan\n=comment=vlan$vlan
sa.command.serv.enable=/ip/firewall/address-list/enable\n=numbers="!!$servId!!"
sa.command.serv.disable=/ip/firewall/address-list/disable\n=numbers="!!$servId!!"
sa.command.serv.cancel.1=/ip/firewall/address-list/remove\n=numbers="!!$servId!!"
sa.command.serv.cancel.2=/queue/simple/remove\n=numbers=vlan$vlan
sa.command.inetOption.1.enable=/queue/simple/set\n=max-limit=0/100M\n=numbers=vlan$vlan
sa.command.inetOption.1.disable=/queue/simple/set\n=max-limit=0/99M\n=numbers=vlan$vlan
А дочерний список нужен для того, чтобы к основному инет-сервису прибавить дочерний, ведь именно по ип-ам из этого списка идёт переобсчёт сессий по нетфлоу , идущих с бордеров на BGInetAccounting-сервер.
Так же в основной инет-сервис клиента добавляются инерфейс ( порт свитча доступа , в который воткнут клиент ) и индификатор ( ип свитча доступа клиента ).Но они нужны только в целях инвентаризации , чтобы определить куда воткнут клиент и не принимают никакого участия в управлении.
Cписки VLAN ресурсов содержат к счастью только одну запись :от vlan_min до vlan_max.
ЗЫ:
Есть наверное и вторая причина :
Конечно инициализация сессий при таком способе - по трафику из Netflow а не по сигналу , как это имеет место в случае использования БЖБ-DHCP , т.е создаются псевдосессии.
Кто-то когда то на этом фоуме поведал мне потаенную мысль, что псевдосессии хуже чем обычные ( правда не объяснил почему).
Может это действительно плохо, но у нас такая схема в работе с БЖБ 5.2 и ничего плохого мы пока не замечали...
Вход
Регистрация
FAQ
Поиск
.