forum.bitel.ru http://forum.bitel.ru/ |
|
Решение SmartEdge 100 с авторизацией по порту коммутатора http://forum.bitel.ru/viewtopic.php?f=44&t=5361 |
Страница 4 из 7 |
Автор: | sergey-xxi [ 24 мар 2012, 03:33 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
поменяли обработчики, на те что в на ru.bitel.bgbilling.modules.inet.dyn... вот хеандлер Код: package ru.bitel.bgbilling.modules.inet.dyn.device.redback; import ru.bitel.bgbilling.kernel.network.dhcp.DhcpPacket; import ru.bitel.bgbilling.kernel.network.dhcp.DhcpProtocolHandler; import ru.bitel.bgbilling.kernel.network.radius.RadiusDictionary; import ru.bitel.bgbilling.kernel.network.radius.RadiusPacket; import ru.bitel.bgbilling.kernel.network.radius.RadiusProtocolHandler; import ru.bitel.common.Utils; import ru.bitel.common.sql.ConnectionSet; import ru.bitel.bgbilling.modules.inet.radius.InetRadiusProcessor; public class SmartEdgeClipsProtocolHandler extends SmartEdgeProtocolHandler implements RadiusProtocolHandler, DhcpProtocolHandler { /** * Установка username * @param request */ private void setUsername( RadiusPacket request ) { String macAddr = request.getStringAttribute( 2352, 145, null ); byte[] remoteId = request.getByteAttribute( 2352, 96, null ); byte[] circuitId = request.getByteAttribute( 2352, 97, null ); String realm = request.getStringAttribute(30); if( macAddr != null && remoteId != null && circuitId != null ) { String callingStation = macAddr.replaceAll( "\\-", "" ); String userName = Utils.bytesToHexString( remoteId ).substring(4, 16) + ":" + Utils.bytesToHexString( circuitId ).substring(10, 12); userName = userName.toLowerCase(); request.setStringAttribute( -1, 1, userName ); request.setStringAttribute( -1, 31, callingStation ); } } @Override public void preprocessAccessRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { super.preprocessAccessRequest( request, response, connectionSet ); // устанавливаем поле username setUsername( request ); } @Override public void postprocessAccessRequest( RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { super.postprocessAccessRequest( request, response, connectionSet ); response.removeAttributes( -1, RadiusDictionary.Framed_IP_Address ); } @Override protected void preprocessAccountingRequestImpl( int acctStatusType, RadiusPacket request, RadiusPacket response, ConnectionSet connectionSet ) throws Exception { acctStatusType = request.getIntAttribute( -1, 40, 0 ); // старты получается не обрабатываем, сессия стартует по апдейту if( acctStatusType != 1 && acctStatusType != 101 ) { preprocessAccessRequest( request, response, connectionSet ); Integer ipaddr = request.getIntAttribute( 2352, 132, null ); if( ipaddr != null ) { request.setIntAttribute( -1, 8, ipaddr ); } } if ( acctStatusType == 3 || acctStatusType == 2) { // обнуляем общие счетчики трафика (нас интересуют только посервисные) request.setIntAttribute(-1, 42, 0); request.setIntAttribute(-1, 43, 0); } if ( acctStatusType == 103 || acctStatusType == 102) { String sessionID = request.getStringAttribute(-1, 50, null); request.setStringAttribute(-1, 44, sessionID); } if ( acctStatusType == 103 || acctStatusType == 102) { request.setIntAttribute(-1, 40, 3); } setUsername( request ); } @Override public void preprocessDhcpRequest( DhcpPacket request, DhcpPacket response ) throws Exception { // подмена try { byte[] circuitId = request.getSubOption( (byte)1 ).value; byte[] remoteId = request.getSubOption( (byte)2 ).value; byte[] mac = new byte[6]; byte[] port = new byte[1]; System.arraycopy( circuitId, 5, port, 0, 1 ); System.arraycopy( remoteId, 2, mac, 0, 6 ); request.setSubOption( (byte)1, port ); request.setSubOption( (byte)2, mac ); } catch( java.lang.NullPointerException e ) { return; } } @Override public void postprocessDhcpRequest( DhcpPacket request, DhcpPacket response ) throws Exception { } } создается только родительская сессия, сервисной все равно нет. пакет сервисной сесии Код: radius 03-24/01:16:01 INFO [rdsLstnr-p-6-t-7] InetRadiusProcessor - REQUEST_AFTER_PREPROCESS: Packet type: Accounting-Request Identifier: 38 Authenticator: {30 64 11 F4 88 40 CD 07 B5 EE 70 AD B8 C0 67 44} Attributes: User-Name=0012cff2a740:0f NAS-Identifier=RedBack NAS-IP-Address=192.168.1.247 NAS-Port=33751040 Service-Type=5 Framed-IP-Address=192.168.4.105 Acct-Input-Octets=197208 Acct-Output-Octets=334 Acct-Status-Type=3 Acct-Session-Time=900 Acct-Input-Packets=594 Acct-Session-Id=0102FFFF78007140-4F6CE42B Acct-Authentic=1 Acct-Multi-Session-Id=0102FFFF78007140-4F6CE42B NAS-Port-Id=2/3 clips 160064 Acct-Output-Packets=1 Event-Timestamp=1332537263 Acct-Output-Gigawords=0 Acct-Input-Gigawords=0 Calling-Station-Id=000c42823fd4 NAS-Port-Type=5 Called-Station-Id=192.168.4.1 Acct-Mcast-Out-Packets-64={00 00 00 00 00 00 00 00} DHCP-Max-Leases=1 UNKNOWN[2352-201]={01 C0 A8 04 01} UNKNOWN[2352-202]={3D 3D 07 01 00 0C 42 82 3F D4} UNKNOWN[2352-202]={0C 0C 08 4D 69 6B 72 6F 54 69 6B} Acct-Output-Octets-64={00 00 00 00 00 00 01 4E} Acct-Input-Octets-64={00 00 00 00 00 03 02 58} Acct-Output-Packets-64={00 00 00 00 00 00 00 01} Acct-Input-Packets-64={00 00 00 00 00 00 02 52} Acct-Mcast-In-Octets-64={00 00 00 00 00 00 00 00} Service-Parameter=Rate=10000 Burst=1250000 Assigned-IP-Address=192.168.4.105 Acct-Mcast-In-Packets-64={00 00 00 00 00 00 00 00} Acct-Mcast-Out-Octets-64={00 00 00 00 00 00 00 00} Acct-Update-Reason=26 Mac-Addr=00-0c-42-82-3f-d4 Acct-Mcast-In-Octets=0 Acct-Mcast-Out-Octets=0 Acct-Mcast-In-Packets=0 Acct-Mcast-Out-Packets=0 Platform-Type=4 Medium-Type=11 Agent-Remote-Id={00 06 00 12 CF F2 A7 40} Agent-Circuit-Id={00 04 00 03 01 0F} IP-Interface-Name=clients Service-Name=SE Service-Options:0=1 OS-Version=6.5.1.4 NAS-Real-Port=33751040 UNKNOWN[3561--1]={02 0A 00 06 00 12 CF F2 A7 40} UNKNOWN[3561--1]={01 08 00 04 00 03 01 0F} radius 03-24/01:16:01 INFO [rdsLstnr-p-6-t-7] InetRadiusProcessor - Session 0102FFFF78007140-4F6CE42B found. radius 03-24/01:16:01 DEBUG [rdsLstnr-p-6-t-7] connection - 1038:1247 Add time 300 radius 03-24/01:16:01 DEBUG [rdsLstnr-p-6-t-7] connection - 1038:1247 Add traffic 0=300 radius 03-24/01:16:01 DEBUG [rdsLstnr-p-6-t-7] connection - 1038:1247 Add traffic 0=300 radius 03-24/01:16:01 DEBUG [rdsLstnr-p-6-t-7] ProcessorRequest - Sending to /192.168.1.247:1812 radius 03-24/01:16:01 INFO [rdsLstnr-p-6-t-7] RadiusListenerWorker - RESPONSE: Packet type: Accounting-Response Identifier: 38 Authenticator: {42 5B B9 8F F1 2B B0 85 15 9F F7 68 72 86 24 5C} Attributes: 343 accounting 03-24/01:16:01 DEBUG [accwrkr-3-p-10-t-1] SessionFinishManager - Run SessionFinishManager... accounting 03-24/01:16:01 DEBUG [worker-p-13-t-1] InetLogProccessor - Run InetLogProcessor... accounting 03-24/01:16:01 DEBUG [accwrkr-3-p-10-t-1] SessionFinishManager - Finished 0 auto (checked 0) sessions for 0 ms. accounting 03-24/01:16:01 DEBUG [worker-p-13-t-1] InetLogProccessor - Proccesed 0 hours for 3 ms. accounting 03-24/01:16:01 DEBUG [worker-p-13-t-1] InetLogProccessor - InetLogProcessor finished mq 03-24/01:16:02 DEBUG [evpool-pblsh-p-4-t-2] EventProcessor - Publish: Event[pool:ru.bitel.bgbilling.modules.inet.accounting.event.InetAccountingEvent] timestamp: 1332537362106; moduleId: 1; pluginId: -1; cid: -1; scid: -1; userId: -1 accounting 03-24/01:16:11 DEBUG [accwrkr-1-p-12-t-1] connection - 1038:1247 Before calc inetOptions: 1 accounting 03-24/01:16:11 INFO [accwrkr-1-p-12-t-1] SessionTarifficationManager - Calculate for 24.03.2012 01:01:01 accounting 03-24/01:16:11 INFO [accwrkr-1-p-12-t-1] SessionTarifficationManager - TariffOptionMap: {} accounting 03-24/01:16:11 DEBUG [accwrkr-1-p-12-t-1] connection - 1038:1247 TariffRequest: PARAMS: mid: 1; cid: 2 ServiceCost [serviceId: -3; date1: ; date2: ; serviceStart: ; serviceEnd: ; accountingPeriodDays: 0; amount: 0; cost: null] имя сервиса передает правильно "SE" вот статус сессии из редбэка Код: Session state Up Circuit 2/3 clips 160064 Internal Circuit 2/3:511:63:31/7/2/28992 Interface bound clients Current port-limit unlimited Protocol Stack IPV4 dhcp max-addrs 1 (applied) ip interface clients (applied) dhcp option client id 0x3d0701000c42823fd4 (applied) dhcp option hostname 0x0c084d696b726f54696b (applied) qos-policing-policy DEF-IPOE-IN (applied from sub_default) qos-metering-policy DEF-IPOE-OUT (applied from sub_default) service (applied) [svc id: 0] SE (acct enabled) service-parameter (applied) [svc id: 0] Rate=10000 Burst=1250000 dynamic policy acl [svc mask: 0x0001] (applied in: qos out: qos) [svc id: 0] ip out forward class EXTERNAL qos [svc id: 0] ip in forward class EXTERNAL qos qos-dynamic-param [svc mask: 0x0001] (applied) [svc id: 0] meter-class-rate EXTERNAL rate-absolute 10000 (applied) [svc id: 0] meter-class-burst EXTERNAL 1250000 (applied) [svc id: 0] police-class-rate EXTERNAL rate-absolute 10000 (applied) [svc id: 0] police-class-burst EXTERNAL 1250000 (applied) service-acct (in) [svc mask: 0x0001] (applied) [svc id: 0] qos class-mask 0x02 service-acct (out) [svc mask: 0x0001] (applied) [svc id: 0] qos class-mask 0x02 service-interim-acct-interval [svc mask: 0x0001] (applied) [svc id: 0] 900 IP host entries installed by DHCP: (max_addr 1 cur_entries 1) 192.168.4.105 00:0c:42:82:3f:d4 на редбэке debug aaa exception %AAA-7-EXCEPT: aaa_process_dhcp_iphost_del: DHCP DEL lookup failed for pvc slot 1 port 2 channel 0xffff ip_addr 192.168.4.105 : drop что не так может быть ? |
Автор: | babay951 [ 11 апр 2012, 06:54 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Ну так кто-нибудь уже ввёл эту железяку в реальную работу или нет? В wiki не увидел как же netflow снимать. |
Автор: | akornilov [ 23 апр 2012, 14:38 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Коллеги, а где можно найти специалистов, которые за деньги донастроят нам BGBill версии 5.2 и интегрируют с SE100? А то у нас все в зависшем состоянии, плюс до конца не ясно, как Inet настроить с SE, нужно переносить весь код управления им из примеров для IPN для 5.1? |
Автор: | babay951 [ 27 апр 2012, 09:01 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Поддерживаю вопрос, может тоже нанимать будем на интеграцию. |
Автор: | Amir [ 27 апр 2012, 19:09 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Биллинг и мы можем настроить. Железки - нет. Работает у нескольких клиентов. Можно и по netflow собирать, но зачем, если она, насколько помню, в посервисном аккаунтинге может сама разделять трафик на виды? Цитата: как Inet настроить с SE, нужно переносить весь код управления им из примеров для IPN для 5.1? Скорее всего, вам хватит того, что уже есть в модуле inet. Какие скрипты у вас были в ipn?
|
Автор: | babay951 [ 11 май 2012, 12:31 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Думаю с настройка биллинга будут минимальные проблемы. Больше интересует как ведет себе данная железка. Будет ли успевать натить, шейпить и собирать статистику с 8000 абонентов, как заявлено? Вот и интересно, есть ли опыт. А то в рекламе одно пишут, а в реале получаешь кота в мешке. Типа ну да расчитано на 8000 абонентов, но мы же не говорили что одновременно она натить и шейпить будет. В такой конфигурации только 3000. |
Автор: | Yarlan Zey [ 11 май 2012, 15:02 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
это на наге. если железка есть, то даже пустят в закрытый раздел |
Автор: | akornilov [ 29 май 2012, 12:35 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Коллеги, задали вопрос на наге, решили и сюда продублировать, т.к. пока не ясно, в какую сторону смотреть. Вот он: ==== Вопрос из разряда "странного хочется": Можно ли "сэмулировать" выдачу клиенту серой подсети? Тоесть к примеру есть сеть 10.0.0.0/8 из которой мы хотим каждому клиенту выдать /24 сетку. При этом SmartEdge должен быть с адресом 10.xxx.yyy.1/24 в каждой подсети. DHCP сервер выдал клиенту нужные параметры (ip-адрес, маску, шлюз, ДНС). Собственно вопрос: как SmartEdge-у присвоить адрес 10.xxx.yyy.1/24? Или как-то убедить клиента что у SE есть этот адрес... Или как-то извернуться через proxy-arp... ==== По идее, после аутентификации и авторизации пользователя, биллинг что-то должен передать какими-то атрибутами на SE100, чтобы он прописал себе адрес из этой сети. Вопрос: возможно ли это и как это сделать? Спасибо. |
Автор: | skyb [ 29 май 2012, 13:07 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
akornilov Событие изменение сервиса, вешается скрипт который заходит на se и делает что нужно |
Автор: | akornilov [ 29 май 2012, 13:17 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Ну может все-таки SE может по атрибутам как-то сам понять, что этот адрес его и ему его нужно прописать самому себе? |
Автор: | snark [ 20 июн 2012, 17:21 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
babay951 писал(а): интересует как ведет себе данная железка Я на наге спрашивал, да и тут, где-то, тоже (с ходу не нашел - поищите). babay951 писал(а): Будет ли успевать натить, шейпить и собирать статистику с 8000 абонентов, как заявлено? В теории - да, т.к. все на ASIC-ах, если, конечно, не выходить за оговоренные в даташите/доке рамки. P.S. Господа админы, вынесите, пожалуйста, обсуждение железки в отдельную тему, куда нить сюда. |
Автор: | Cromeshnic [ 18 июл 2012, 07:05 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Неудобно: Для SmartEdgeServiceActivator атрибуты опций Inet задаются через префикс "sa.radius.option.", а для ISGPPPoEServiceActivator - через "nas.radius.inetOption." |
Автор: | Amir [ 18 июл 2012, 13:08 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Не понял, почему так. Возможно, из-за обратной совместимости. Чтобы было правильно и удобно, укажите в конфигурации устройства (типа устройства) Код: sa.radius.option.attributesPrefix=radius.inetOption. Тогда всегда будет "radius.inetOption.".Кстати, nas.radius.inetOption. - это устаревший вариант, правильно указывать "radius.inetOption.". При Access-Request по умолчанию именно оттуда берутся RADIUS-атрибуты. |
Автор: | Cromeshnic [ 25 июл 2012, 07:26 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Пробуем схему с Reject-To-Accept. Сервер: вер. 5.2 сборка 1241 от 20.07.2012 10:05:29 os: Linux; java: Java HotSpot(TM) Client VM, v.1.6.0_27 inet вер. 5.2 сборка 932 от 17.07.2012 14:25:38 Код: @redirect.attributes=HTTP-Redirect-Profile-Name=REDIRECT;Forward-Policy=in:HTTP-REDIRECT @const.access.attributes=Service-Type=2;Framed-Protocol=1;Acct-Interim-Interval=900;Sub-Profile-Name=base-unlimited # #test sa.radius.disable.attributes={@const.access.attributes};{@redirect.attributes} # sa.radius.connection.withoutBreak=1 # Коды ошибок, при которых пользователю выдается серый адрес и устанавливается HTTP-редирект. realm.reject.error=1,2,3,4,10,11,12 # Используемый для отключенных пул адресов и параметры http-редиректа. nas.radius.realm.reject.pool=7 nas.radius.realm.reject.attributes={@const.access.attributes};{@redirect.attributes} Клиент подключается, ему выдаётся Ip из пула - всё ок. Но после этого приходит ServiceActivatorEvent с oldState=1 и уже редиректнутому клиенту посылается CoA Цитата: 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 Т.е. при старте oldState=0, а потом становится =1: Цитата: 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 Как правильно реализовать Reject-To-Accept? |
Автор: | Cromeshnic [ 25 июл 2012, 13:03 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Ещё такой момент. Подключаем сессию при положительном балансе, затем загоняем в минуса - всё ок, отрабатывает connectionModify, уходит CoA с редиректом. Но после этого, если баланс опять сделать положительным, connectionModify не вызыватеся - только serviceModify. Это нормально? |
Автор: | Amir [ 25 июл 2012, 14:14 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Нужно, чтобы модуль знал, в каком состоянии сейчас сессия. У вас ограниченный доступ идет отдельным сервисом в SE? |
Автор: | Cromeshnic [ 26 июл 2012, 07:27 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Вот же: Код: @redirect.attributes=HTTP-Redirect-Profile-Name=REDIRECT;Forward-Policy=in:HTTP-REDIRECT @const.access.attributes=Service-Type=2;Framed-Protocol=1;Acct-Interim-Interval=900;Sub-Profile-Name=base-unlimited # #test sa.radius.disable.attributes={@const.access.attributes};{@redirect.attributes} # sa.radius.connection.withoutBreak=1 # Коды ошибок, при которых пользователю выдается серый адрес и устанавливается HTTP-редирект. realm.reject.error=1,2,3,4,10,11,12 # Используемый для отключенных пул адресов и параметры http-редиректа. nas.radius.realm.reject.pool=7 nas.radius.realm.reject.attributes={@const.access.attributes};{@redirect.attributes} При подключении с отриц. балансом работает reject.attributes, а при уходе активного в минус работают disable.attributes |
Автор: | Cromeshnic [ 26 июл 2012, 08:19 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Цитата: На данный момент с 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 редиректом. (c) zzeka Так вот, при первой схеме клиенту дополнительно посылаются через CoA атрибуты по второй схеме. А при втором алгоритме не срабатывает CoA при включении (не вызывается connectionModify) |
Автор: | Amir [ 26 июл 2012, 14:44 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Когда настраивали SE у одного клиента - сначала редирект просто отображался в аккаунтинг пакетах родительской сессии, как дополнительный атрибут, а в конфигурации устройства было прописано: Код: #атрибуты, при наличии которых соединение должно считаться в состоянии DISABLE (т.е. с ограниченным доступом) Но аккаунтинг сессии приходит редко, поэтому клиент перенастроил SE так, что редирект шел отдельной сервисной сессией, т.е. нужно отключить - посылается CoA, приходит стоп сервисной сессии INET и старт сервисной сессии NOAUTH. radius.disable.pattern.attributes= убрали. Добавили # Используемый для отключенных пул адресов и параметры http-редиректа. radius.disable.pattern.attributes=HTTP-Redirect-Profile-Name=NOAUTH Код: radius.serviceName.disable=NOAUTH (см. ru.bitel.bgbilling.modules.inet.dyn.device.redback.SmartEdgeProtocolHandler).Также добавили Код: connection.start.fromAccept=1 чтобы Access при Access-Accept добавлял соединение в базе со статусом WAIT и указанием выданного состояния и опций. В данном случае это вроде бы не обязательно, т.к. старты родительской и сервисных приходят одновременно.При таких настройках Accounting будет знать, в каком состоянии сессия и будет правильно переключать ее. |
Автор: | Amir [ 26 июл 2012, 14:46 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Цитата: При подключении с отриц. балансом работает reject.attributes, а при уходе активного в минус работают disable.attributes Параметры reject и disable - должно означать тоже самое, просто на каком-то этапе создания модуля переименовали reject в disable. В wiki http://wiki.bgbilling.ru/index.php/RedBack_CLIPS и документации уже вроде бы давно по другому. |
Автор: | zzeka [ 08 авг 2012, 11:23 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
В wiki нет настроек с отдельным сервисом NOAUTH, можете их показать? Такой вариант может нам не подойти, т.к. скорее всего придется менять Subscriber-Profile. Возможно ли реализовать наши варианты? |
Автор: | Amir [ 10 авг 2012, 17:31 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
К сожалению, настроек Redback не знаем. Если нельзя сделать отдельным Redback-сервисом, то рекомендую в конфигурации устройства указать: connection.start.fromAccept=1 убрать: radius.serviceName.disable=... radius.disable.pattern.attributes=... а в SmartEdgeClipsServiceActivator.connectionDisable() и в SmartEdgeServiceActivator.connectionModify() добавить e.setConnectionStateModified( true ); Хотя последнее мы сами, наверно, добавим, потому что для обычного CoA есть параметр в конфигурации sa.radius.connection.stateModify. В этом случае после отрабатывания метода Access сам будет менять состояние сессии, и модуль, таким образом, будет знать в каком состоянии сейчас сессия (т.е. открыт или закрыт ли доступ), что очень важно для правильной отправки CoA. |
Автор: | Brodayga [ 17 авг 2012, 13:02 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
настраиваем следующую схему клиент -des3028(local relay) - dgs3627 (l3 relay)-se100 Возникла следующая проблема клиент шлёт запрос на получение ip , всё как положено отрабатывает за исключением того что в сессиях не отображается ip адрес клиента (видимо связано с тем что в предобработке удаляется фреймд Ip). Далее когда время аренды истекает клиент начинает слать запросы на продление но уже в юникасте на адресс se100, des3028 не добаляет опцию в unicast запрос. билинг ругаеться Код: Message type: BOOT_REQUEST Dhcp message type: DHCP Request{3} htype: 1, hlen: 6, hops: 1 xid: 1632206202, secs: 2816, flags: 0 Client IP: 10.84.1.51 Your IP: 0.0.0.0 Server IP: 0.0.0.0 Relay IP: 10.84.0.1 Client MAC: {0026B909F7AB} {61}={010026B909F7AB} Host name{12}={admin-��} {81}={00000061646D696E2D8F8A} {60}={4D53465420352E30} Parameter request list{55}={1, 15, 3, 6, 44, 46, 47, 31, 33, 121, -7, 43} 08-17/02:14:44 WARN [dhcpLstnr-p-9-t-9] InetDhcpHelperProcessor - DHCP request without Options.82! И далее два варианта развития либо клиент успеет до истечения аренды на se, броодкастом запросить по новой ip и сессия не сорвётся, либо не успеет и se стопонёт сессию и авторизует его заново по приходу реквеста. пытался сделать так Код: dhcp.option.serverIdentifier=0.0.0.0 но se упорно меняет на свой ip Код: Aug 17 10:08:36: [0001]: [2/1:511:63:31/7/2/412]: %DHCP-7-PKT: Option: server id received as 0.0.0.0 Aug 17 10:08:36: [0001]: [2/1:511:63:31/7/2/412]: %DHCP-7-PKT: Using laddr 10.10.2.9 from svr_p as server-id Aug 17 10:08:36: [0001]: [2/1:511:63:31/7/2/412]: %DHCP-7-PKT: Proxy: Option 54 found: reset to 10.10.2.9 Ответ от тех.под. DLINk Цитата: На DHCP сервере используйте опцию stash-agent-options.
|
Автор: | Amir [ 17 авг 2012, 13:18 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
В сессии не будет адреса, если в аккаунтинг пакетах его нет. По протоколу DHCP на SE напрямую запрос должен идти только в стадии RENEW - она начинается за половину времени до истечения срока lease. За четверть срока до lease, если на RENEW не получил ответа, DHCP клиент переходит в стадию REBINDING и начинает слать запросы как обычно. Т.е. в том, что он не получает ответ на RENEW не должно быть ничего страшного. Поэтому не понятно, как он не успевает нормально запросить адрес в стадии REBINDING. |
Автор: | Brodayga [ 17 авг 2012, 13:34 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Amir писал(а): В сессии не будет адреса, если в аккаунтинг пакетах его нет. По протоколу DHCP на SE напрямую запрос должен идти только в стадии RENEW - она начинается за половину времени до истечения срока lease. За четверть срока до lease, если на RENEW не получил ответа, DHCP клиент переходит в стадию REBINDING и начинает слать запросы как обычно. Т.е. в том, что он не получает ответ на RENEW не должно быть ничего страшного. Поэтому не понятно, как он не успевает нормально запросить адрес в стадии REBINDING. В в аккаунтинг пакетах его нет. Конфиг se делал по примеру в вики. Клиент win7. Если ставить lease 120. то REBINDING приходит(если приходит) когда остаёться 10-15 секунд. |
Автор: | Amir [ 17 авг 2012, 14:10 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Т.е. получается, в каких-то случаях он вообще не приходит? А если не приходит - он просто заново авторизируется на SE? Попробуйте также протестировать с параметром в конфгурации устройства dhcp.alwaysBroadcast=1, как поведет себя. В принципе, для таких пакетов можем попробовать сделать, чтобы по адресу находил сессию и, наверное, дополнительно проверял (для большей безопасности), что MAC-адрес совпадает с callingStationId сессии. |
Автор: | Brodayga [ 17 авг 2012, 14:28 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Amir писал(а): Т.е. получается, в каких-то случаях он вообще не приходит? А если не приходит - он просто заново авторизируется на SE? Попробуйте также протестировать с параметром в конфгурации устройства dhcp.alwaysBroadcast=1, как поведет себя. В принципе, для таких пакетов можем попробовать сделать, чтобы по адресу находил сессию и, наверное, дополнительно проверял (для большей безопасности), что MAC-адрес совпадает с callingStationId сессии. Спасибо попробую. Именно так. Было бы хорошо. |
Автор: | Brodayga [ 17 авг 2012, 15:29 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Насчёт ip в старых хендлерах была конструкция Integer ipaddr = request.getIntAttribute( 2352, 132, null ); if( ipaddr != null ) { request.setIntAttribute( -1, 8, ipaddr ); } В последнем SmartEdgeClipsProtocolHandler отсутствует. Так и должно быть? Просто поле Assigned-IP-Address присутствует в update добавил ip появился попутный вопрос. В мониторе сессий сессия в дереве показывается только для редбека, а в 3028 пусто так и должно быть. Авторизация по коммутатору и номеру порта |
Автор: | Brodayga [ 17 авг 2012, 17:04 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
Amir писал(а): Попробуйте также протестировать с параметром в конфгурации устройства dhcp.alwaysBroadcast=1, как поведет себя. Ситуация не поменялась. в дебаге видно что бит установлен. |
Автор: | Brodayga [ 17 авг 2012, 17:14 ] |
Заголовок сообщения: | Re: Решение SmartEdge 100 с авторизацией по порту коммутатор |
есть ещё одна ошибка в логе dhcp Код: 08-17/14:11:38 INFO [dhcpLstnr-p-9-t-5] InetAbstractDhcpProcessor - REQUEST: Message type: BOOT_REQUEST Dhcp message type: DHCP Inform{8} htype: 1, hlen: 6, hops: 2 xid: -1496754165, secs: 0, flags: 0 Client IP: 10.84.1.2 Your IP: 0.0.0.0 Server IP: 0.0.0.0 Relay IP: 10.84.1.1 Client MAC: {0026B909F7AB} {61}={010026B909F7AB} Host name{12}={admin-��} {60}={4D53465420352E30} Parameter request list{55}={1, 15, 3, 6, 44, 46, 47, 31, 33, 121, -7, 43, -4} Agent information{82}= sub{1}={000407D10001} sub{2}={00060022B00408E7} 08-17/14:11:38 ERROR [dhcpLstnr-p-9-t-5] InetDhcpHelperProcessor - Unsupported message type: 8 Насколько я понимаю не особо критично. следует сразу после выдачи адреса. |
Страница 4 из 7 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |