BiTel

как Inet настроить с SE, нужно переносить весь код управления им из примеров для IPN для 5.1?

интересует как ведет себе данная железка

Будет ли успевать натить, шейпить и собирать статистику с 8000 абонентов, как заявлено?

07-25/10:08:39 DEBUG [sa-p-11-t-2] AcknowledgeConsumer - Caught BGInetAccountingPPPoE:Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaAccountingEvent] moduleId: 25; pluginId: no; cid: 191468; scid: -1; userId: 0; type: 1; deviceId: 7; connectionId: 13695; timestamp: 1343178519593
07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorDeviceWorker - Do task deviceId: 7; Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaAccountingEvent] moduleId: 25; pluginId: no; cid: 191468; scid: -1; userId: 0; type: 1; deviceId: 7; connectionId: 13695; timestamp: 1343178519593
07-25/10:08:39 INFO [sa-p-11-t-2] InetApplication - TariffOptionMap: {12=ru.bitel.bgbilling.kernel.tariff.option.server.bean.ContractTariffOptionList$OptionItem@ea3cdf, 5=ru.bitel.bgbilling.kernel.tariff.option.server.bean.ContractTariffOptionList$OptionItem@11e281f}
07-25/10:08:39 DEBUG [sa-p-11-t-2] TrafficRangeManager - Add to RangeKey[21071109755400:3:-603979569] 0 (0, 3600)
07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorDeviceWorker - Command result event: ServiceActivatorEvent type=4; inetServId: 22; call: true; oldState: 0; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14
07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorDeviceWorker - Processing deviceId:7; command ServiceActivatorEvent type=4; inetServId: 22; call: true; oldState: 0; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14
07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorSet - Invoking onAccountingStart
07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorDeviceWorker - Process event type[4] result=true
07-25/10:08:44 INFO [sa-p-11-t-2] ServiceActivatorSet - Disconnecting from device
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorSet - Connecting to device
07-25/10:08:54 DEBUG [sa-p-11-t-1] AcknowledgeConsumer - Caught BGInetAccountingPPPoE:Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 25; pluginId: no; cid: 191468; scid: -1; userId: 0; deviceId: 7; inetServId: 22; connectionId: 13695; state: 0; accessCode: 10; timestamp: 1343178533906
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorDeviceWorker - Do task deviceId: 7; Event[ru.bitel.bgbilling.modules.inet.access.sa.event.InetSaStateModifyEvent] moduleId: 25; pluginId: no; cid: 191468; scid: -1; userId: 0; deviceId: 7; inetServId: 22; connectionId: 13695; state: 0; accessCode: 10; timestamp: 1343178533906
07-25/10:08:54 INFO [sa-p-11-t-1] InetApplication - TariffOptionMap: {12=ru.bitel.bgbilling.kernel.tariff.option.server.bean.ContractTariffOptionList$OptionItem@ea3cdf, 5=ru.bitel.bgbilling.kernel.tariff.option.server.bean.ContractTariffOptionList$OptionItem@11e281f}
07-25/10:08:54 DEBUG [sa-p-11-t-1] TrafficRangeManager - Add to RangeKey[21071109755400:3:-603979569] 0 (0, 3600)
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorDeviceWorker - Command result event: ServiceActivatorEvent type=2; inetServId: 22; call: true; oldState: 1; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorDeviceWorker - Processing deviceId:7; command ServiceActivatorEvent type=2; inetServId: 22; call: true; oldState: 1; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorSet - Invoking connectionModify
07-25/10:08:54 INFO [sa-p-11-t-1] SmartEdgeServiceActivator - Connection modify: oldState: 1; newState: 0; oldOptionSet: [20, 43, 738, 13, 14]; newOptionSet: [20, 43, 738, 13, 14]
07-25/10:08:54 INFO [sa-p-11-t-1] SmartEdgeServiceActivator - Send CoA lock:
Packet type: CoA-Request
Identifier: 1
Authenticator: {39 A4 09 C0 47 29 3B 44 7B 83 94 3F 92 50 AC 3B}
Attributes:
Acct-Interim-Interval=900
Acct-Interim-Interval=900
Service-Type=2
Framed-Protocol=1
Acct-Session-Id=0100FFFF680000B5-500F474C
Forward-Policy=in:HTTP-REDIRECT
HTTP-Redirect-Profile-Name=REDIRECT
Sub-Profile-Name=base-unlimited

07-25/10:08:54 INFO [sa-p-11-t-1] RadiusClient - Sending to /x.x.x.x:3799
Packet type: CoA-Request
Identifier: 1
Authenticator: {39 A4 09 C0 47 29 3B 44 7B 83 94 3F 92 50 AC 3B}
Attributes:
Acct-Interim-Interval=900
Acct-Interim-Interval=900
Service-Type=2
Framed-Protocol=1
Acct-Session-Id=0100FFFF680000B5-500F474C
Forward-Policy=in:HTTP-REDIRECT
HTTP-Redirect-Profile-Name=REDIRECT
Sub-Profile-Name=base-unlimited

07-25/10:08:54 INFO [sa-p-11-t-1] DatagramChannelListener - ru.bitel.bgbilling.kernel.network.radius.RadiusClient$RadiusDatagramChannelListener socket init ok.
07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorDeviceWorker - Process event type[2] result=true
07-25/10:08:54 INFO [rds-clnt-/x.x.x.x-3799] RadiusClient - Recieved from /x.x.x.x:3799
Packet type: CoA-NAK
Identifier: 1
Authenticator: {6F 2A A3 EB 79 1A AD 01 E6 AA 48 E2 87 2A 30 FE}
Attributes:
Error-Cause=405
Event-Timestamp=1343178586
Service-Type=2

07-25/10:08:59 DEBUG [sa-p-11-t-1] EventWorker - Waiting 5000 millis for last future results will done...
07-25/10:08:59 INFO [sa-p-11-t-1] EventWorker - Future is done
07-25/10:08:59 WARN [sa-p-11-t-1] ServiceActivatorDeviceWorker - Task return false
07-25/10:08:59 INFO [sa-p-11-t-1] ServiceActivatorSet - Disconnecting from device

07-25/10:08:39 INFO [sa-p-11-t-2] ServiceActivatorDeviceWorker - Command result event: ServiceActivatorEvent type=4; inetServId: 22; call: true; oldState: 0; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14

07-25/10:08:54 INFO [sa-p-11-t-1] ServiceActivatorDeviceWorker - Processing deviceId:7; command ServiceActivatorEvent type=2; inetServId: 22; call: true; oldState: 1; newState: 0; oldOptionSet: 20,43,738,13,14; newOptionSet: 20,43,738,13,14

На данный момент с SE100 возможны примерно такие алгоритмы работы Redject-to-Accept:

1. C разрывом сессии:

При уходе в минус (закрытии сервиса и т.п.) -- разрыв сессии.
При подключении с минусовым балансом -- Выдаются аттрибуты с натройками редиректа, IP из спец пула, и т.п.
При переходе в плюс -- разрыв сессии.

2. Без разрыва:

При уходе в минус -- CoA отключающее текущие сервисы(опции модуля INET) + CoA которое включает Forward-Policy c редиректом.
При переходе в плюс -- CoA на оключение Forward-Policy c редиректом + CoA на включение положенных по ТП сервисов(опций модуля INET).
При подключении с минусовым балансом -- выдаются default аттрибуты для сессии, IP адрес из остновного пула, и Forward-Policy c редиректом.

При подключении с отриц. балансом работает reject.attributes, а при уходе активного в минус работают disable.attributes

На DHCP сервере используйте опцию stash-agent-options.

В сессии не будет адреса, если в аккаунтинг пакетах его нет.

По протоколу DHCP на SE напрямую запрос должен идти только в стадии RENEW - она начинается за половину времени до истечения срока lease.
За четверть срока до lease, если на RENEW не получил ответа, DHCP клиент переходит в стадию REBINDING и начинает слать запросы как обычно.
Т.е. в том, что он не получает ответ на RENEW не должно быть ничего страшного. Поэтому не понятно, как он не успевает нормально запросить адрес в стадии REBINDING.

Т.е. получается, в каких-то случаях он вообще не приходит?
А если не приходит - он просто заново авторизируется на SE?
Попробуйте также протестировать с параметром в конфгурации устройства dhcp.alwaysBroadcast=1, как поведет себя.

В принципе, для таких пакетов можем попробовать сделать, чтобы по адресу находил сессию и, наверное, дополнительно проверял (для большей безопасности), что MAC-адрес совпадает с callingStationId сессии.

Попробуйте также протестировать с параметром в конфгурации устройства dhcp.alwaysBroadcast=1, как поведет себя.