BiTel

Собирается стандартная схема ISG c cisco, но хочется DHCP вынести на отдельную машинку.
Устройства выглядят так:
-pgISG:pgISG --- ID: 10
|- ciscoISG --- ID: 11
|- cisco3560 --- ID:12
|- Dlink 3200-28 --- ID: 13

На первой машине будет радиус и flow, на второй - DHCP.

1. Получится ли вынести DHCP на отдельную машинку?
2. Нужен ли Accounting на второй машинке, если да, то что в нем нужно оставлять?

_________________
Клиент: вер. 7.1.102 / 20.04.2018 19:02:09
os: Windows 8.1; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_172
Сервер: вер. 7.1.970 / 20.04.2018 19:04:17
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_162

а с каких устройств будет идти dhcp, netflow, radius? со всех ?

Radius и netflow будет только на одном - ciscoISG.
DHCP будет с нескольких relay устройств типа cisco 3560.

_________________
Клиент: вер. 7.1.102 / 20.04.2018 19:02:09
os: Windows 8.1; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_172
Сервер: вер. 7.1.970 / 20.04.2018 19:04:17
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_162

Если обычная схема ISG, когда DHCP проходит через него (InetDhcpHelperProcessor), то, возможно, не получится.
Access, отвечающий на DHCP, иногда не будет успевать получать информацию о новой сессии до того как придет первый DHCP-запрос.
Смотреть надо, что будет в данной ситуации, возможно от абонента придет снова DISCOVER и на второй раз сработает, так что все произойдет незаметно.

Еще вариант - что оба Access будут отвечать на DHCP, но тут надо доработать - обычный InetDhcpProcessor сейчас умеет так работать - они оба шлют OFFER, а потом фильтруют REQUEST'ы по параметру dhcp.filter.serverIdentifier. InetDhcpHelperProcessor сейчас так не умеет.
Вроде бы в этом случае, если второй Access'а успеет получить информацию о новой сессии - то тоже пошлет OFFER вместе с первым.


Если схема DHCP82 + Cisco IP Subscription - возможен другой вариант, что пойдет авторизация по IP-пакету, а RADIUS-Access еще не будет знать о DHCP-сессии. Но тут возможны варианты, например, слать DHCP и RADIUS на оба, чтобы снизить кол-во таких случаев; настроить переавторизацию или изменение состояния сессии через CoA (когда Accounting определит, что сессия в состоянии отключена а должна быть - включена).

В моей схеме DHCP не будет приходить с ciscoISG, dhcp запросы будут приходить с нижестоящих коммутаторов и ip будет выдаваться клиенту один во всех состояниях сервиса (включен, отключен, заблокирован).
Доступом будет управлять ISG по ISGServiceActivator.
При чем, часть абонентов будет со статическим ip адресом (без dhcp).
Т. е. DHCP на втором сервере выдает клиенту ip адрес, а Radius на первом сервере создает дочернюю сессию по ISGServiceActivator на основе уже выданного ip...
Так можно?

_________________
Клиент: вер. 7.1.102 / 20.04.2018 19:02:09
os: Windows 8.1; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_172
Сервер: вер. 7.1.970 / 20.04.2018 19:04:17
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_162