Цитата:
внутри такого устройства S-VLAN уже будут свои коммутаторы?
Вот именно, что в схеме влан на юзера устройства типа "коммутатор" или "vlan" быть ваще не должно.
Походу в БЖБ пора вводить ресурсы типа "ассоциативный массив" vlan <-> ип-адрес(сеть).
Здесь ведь вот в чём дело.
Конкретный ип по номеру влана и ип dhcp-relay-я можно выдать по dhcp только в s-vlan.
При организации схемы Q-in-Q( когда s-vlan-ы со домовых свитчей уровня доступа "упаковываются" в c-vlan-ы свитчами агрегации района организуется управляющий влан, охватывающий все свитчи уровня доступа с этого района.
Т.е 1-ый район : s-vlan-ы : c 21 по 4000-ый управляющий влан : 4001
Т.е 3-ый район : s-vlan-ы : c 21 по 4000-ый управляющий влан : 4002
......
Т.е 94-ый район : s-vlan-ы : c 21 по 4000-ый управляющий влан : 4094
Диапазон c-vlan-ов : c 2 по 20 например, управляющих вланов : с 4001 по 4094 напрмер.
(Я просто не видел провайдера у которого используются все 2 в 12 -ой степени c-vlan и s-vlan)
dhcp-пакеты с оtp.82 cо свитчей доступа района приходят на dhcp-server по управляющему влану района.
Прелесть селективного Q-in-Q заключается в том что s-vlan-ы района можно оборачивать внешним тегом c-vlan-а а управляющие vlan-ы "реплейсить" тем же тегом этого управляющего влана.
В результате в центр ( где стоят BGB-InetAccess типа dchp ) придут и управляющие вланы с одним тегом так и s-vlan-ы с двумя тегами.
Конечно BGB-InetAccess может реагировать только на пакеты c opt.82 приходящие в управляющих вланах с районов.
Это значит , что он должен стоять на сервере с сетевым интерфейсом, развиланеным управляющими вланами районов и управлять dhcp-процессами , слушащими каждый в своём управляющем влане.
Получается что-то типа этого:
-BGBInetAccess
--dhcp-process 1-го района
---dhcp-relay_1 1-го района
---dhcp-relay_2 1-го района
...
---dhcp-relay_n 1-го района
--dhcp-process 2-го района
---dhcp-relay_1 2-го района
---dhcp-relay_2 2-го района
...
---dhcp-relay_n 2-го района
...........
...........
--dhcp-process n-го района
---dhcp-relay_1 n-го района
---dhcp-relay_1 n-го района
...
---dhcp-relay_n n-го района
А вот к dhcp-relay-ям районов привязываются ресурсы типа "ассоциативный массив" vlan <-> ип-адрес(сеть).
К слову сказать - у нас по одному dhcp-relay на район, потому что у нас dhcp-relay-свитч работает как dhcp-relay 2-го уровня, т.е. "сбоку" от основного траффика и ваще включён в сеть тока одним портом.
При Q-in-Q будет просто дерево из dhcp-relay-ев dhcp-процессов.
В дереве устройств между "лесенкой" dhcp-relay-ев и BGB-InetAccess ,будет стоять шлюз, терминирующий C-vlan:S-vlan
В командах которого будет просто указано:
Код:
sa.command.inetOption.1.enable=/queue/simple/set\n=max-limit=0/1M\n=numbers=vlan$c-vlan_i:$s-vlan_j
sa.command.inetOption.1.disable=/queue/simple/set\n=max-limit=0/100M\n=numbers=vlan$c-vlan_i:$s-vlan_j
.....
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$c-vlan_i:$s-vlan_j\n=name=vlan$c-vlan_i:$s-vlan_j\n=comment=vlan$c-vlan_i:$s-vlan_j
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$c-vlan_i:$s-vlan_j
( в командах например микротика )
Инфа о c-vlan к нему будет приходить с dhcp-process-а n-го района ( в его параметрах можно указывать только с-vlan района и управляющий влан района ).
Инфа о ip и о s-vlan к нему будет приходить с "ассоциативного массива" c-vlan <-> ип-адрес(сеть) с dhcp-relay_i n-го района.
BGBInetAccounting будет стоять над BGBInetAccess и собирать инфу по нетфлоу с бордера, через который проходит траффик с пучка c-vlan:s-vlan.