[raydo]

Пытаемся настроить ISG. Сам ISG настроили, не можем настроить сброс сессии.

Конфиг радиуса биллинга касательно POD

 

nas.inspector.class=bitel.billing.server.processor.PoDNASConnectionInspector
nas.inspector.radius.port=1812
nas.inspector.radius.attributes=Framed-IP-Address;Acct-Session-Id

 

Конфиг cisco касательно POD и навсякий полисимапы

 

aaa new-model                                                           
aaa session-mib disconnect
aaa session-id unique
aaa server radius dynamic-author
client X.X.X.X server-key xxxxx
port 1812
auth-type any

policy-map type control RULE_IP_SESSION2a
class type control always event session-start
  30 authorize aaa list AUTHOR_LIST1 password password identifier circuit-id plus mac-address
!
class type control always event session-restart
  30 authorize aaa list AUTHOR_LIST1 password password identifier circuit-id plus mac-address
!
class type control always event account-logon
  10 authenticate aaa list AUTHEN_LIST1

 

Вроде бы все не плохо идет. Стоп пакет уходит, сессия сбрасывается. Только ни в какую не поднимается. При чем у меня такое ощущение, что начинают полностью пакеты игнорироваться для данного интерфейса.Если же меняем команду aaa session-id unique на aaa session-id common то убиваются вообще все сессии и точно также не переподнимаются. Пакеты игнорируются со всех виланов, на которых были пользователи.

Тоже самое случается, если убиваем сесиию по SNMP.

Может, я что-то в полисе-мапе недопрописываю? Хотя если я сбрасываю сессию с самой циски, сессия прекрасно переподнимается сама.

[errno]

Посоветовать что-либо конкретное пока не могу, сам еще не до конца разобрался в ISG-шной кухне, но позадаю наводящие вопросы:

 

Какую имено сесию хотите сбросить, конкретный сервис или parent?

Почему POD, а не CoA?

 

Не совсем понятно какую технологию доступа вы используете (IP, PPPoE, etc.), а потому не понятно что имеется ввиду под "Только ни в какую не поднимается".

[tuneil]

POD (Packet of disconnect) специально для этих нужд (сброс сесии) и придуман. CoA же вы можете менять аттрибуты сесии.

raydo: дебаг покажите

Изменено 18 марта, 2010 пользователем tuneil

[raydo]

Дебаг aaa pod

00:22:32:  ++++++ POD Attribute List ++++++
00:22:32: 6390C2F8 0 00000001 addr(8) 4 172.30.30.2
00:22:32: 6390C6A0 0 00000001 session-id(363) 4 19(13)
00:22:32:
00:22:32: POD: Converted to internal Session-Id of 00000013
00:22:32: POD: X.X.X.X user  172.30.30.2 sessid 0x13 key 0x0
00:22:32: POD:      Line     User     IDB          Session Id Key
00:22:32: POD: KILL FastEthe 0004012d x.x.x.x  0x13       0xE4666E78
00:22:32: POD: Sending ACK from port 1812 to x.x.x.x/43090

 

Проходит 5 таких пакетов, потом идут несколько ватчдогов (в конфиге апдейт стоит 1минута)

А потом идет стоп-пакет

00:10:17: RADIUS(0000000B): Send Accounting-Request to X.X.X.X:1813 id 1646/8, len 426
00:10:17: RADIUS:  authenticator AB 48 50 46 CF 53 E3 5F - CF E2 C3 D2 7F 0E 28 C6         
00:10:17: RADIUS:  Acct-Session-Id     [44]  10  "00000003"                                
00:10:17: RADIUS:  Framed-Protocol     [7]   6   PPP                       [1]             
00:10:17: RADIUS:  Framed-IP-Address   [8]   6   172.30.30.2
00:10:17: RADIUS:  User-Name           [1]   29  "0004012d0102:00eb.0101.200e"
00:10:17: RADIUS:  Acct-Authentic      [45]  6   RADIUS                    [1]
00:10:17: RADIUS:  Vendor, Cisco       [26]  32
00:10:17: RADIUS:   Cisco AVpair       [1]   26  "connect-progress=Call Up"
00:10:17: RADIUS:  Vendor, Cisco       [26]  16
00:10:17: RADIUS:   ssg-control-info   [253] 10  "I0;20511"
00:10:17: RADIUS:  Vendor, Cisco       [26]  12
00:10:17: RADIUS:   ssg-control-info   [253] 6   "O0;0"
00:10:17: RADIUS:  Acct-Session-Time   [46]  6   384
00:10:17: RADIUS:  Acct-Input-Octets   [42]  6   20511
00:10:17: RADIUS:  Acct-Output-Octets  [43]  6   0
00:10:17: RADIUS:  Acct-Input-Packets  [47]  6   313
00:10:17: RADIUS:  Acct-Output-Packets [48]  6   0
00:10:17: RADIUS:  Acct-Terminate-Cause[49]  6   admin-reset               [6]
00:10:17: RADIUS:  Vendor, Cisco       [26]  34
00:10:17: RADIUS:   Cisco AVpair       [1]   28  "disc-cause-ext=Radius Disc"
00:10:17: RADIUS:  Acct-Status-Type    [40]  6   Stop                      [2]
00:10:17: RADIUS:  NAS-Port-Type       [61]  6   Ethernet                  [15]
00:10:17: RADIUS:  Vendor, Cisco       [26]  36
00:10:17: RADIUS:   Cisco AVpair       [1]   30  "vendor-class-id-tag=MSFT 5.0"
00:10:17: RADIUS:  NAS-Port            [5]   6   1
00:10:17: RADIUS:  NAS-Port-Id         [87]  11  "0/0/0/301"
00:10:17: RADIUS:  Vendor, Cisco       [26]  35
00:10:17: RADIUS:   Cisco AVpair       [1]   29  "circuit-id-tag=0004012d0102"
00:10:17: RADIUS:  Vendor, Cisco       [26]  38
00:10:17: RADIUS:   Cisco AVpair       [1]   32  "remote-id-tag=00060012cfc85d60"
00:10:17: RADIUS:  Vendor, Cisco       [26]  36
00:10:17: RADIUS:   Cisco AVpair       [1]   30  "vendor-class-id-tag=MSFT 5.0"
00:10:17: RADIUS:  Service-Type        [6]   6   Framed                    [2]
00:10:17: RADIUS:  NAS-IP-Address      [4]   6   X.X.X.X
00:10:17: RADIUS:  Unsupported         [151] 10
00:10:17: RADIUS:   39 32 44 41 33 36 34 44          [ 92DA364D]
00:10:17: RADIUS:  Event-Timestamp     [55]  6   1268961364
00:10:17: RADIUS:  Nas-Identifier      [32]  11  "cisco-ISG"
00:10:17: RADIUS:  Acct-Delay-Time     [41]  6   0
00:10:17: RADIUS: Received from id 1646/8 X.X.X.X:1813, Accounting-response, len 20
00:10:17: RADIUS:  authenticator 3B A7 62 7D 1D F1 9D CD - A0 67 F7 06 C6 8F D3 B1

 

 

Технология ip, точнее сессии поднимаются на основании DHCPDISCOVER

interface FastEthernet0/0.301
encapsulation dot1Q 301
ip address 172.30.30.1 255.255.255.0
no cdp enable
service-policy type control RULE_IP_SESSION2a
ip subscriber routed
  initiator dhcp class-aware

 

После сброса дебаг молчит. И дебаг aaa acc, aaa author, aaa aythen и дебаг dhcp. Более того, если на сетевой карте тестовой машины ручками прописать ip-addres и пинговать циску - в ответ тоже тишина, пакеты не проходят.

 

Попробовали поменять порт на стандартный (1700) - тоже не помогло

Изменено 19 марта, 2010 пользователем raydo

[errno]

POD (Packet of disconnect) специально для этих нужд (сброс сесии) и придуман. CoA же вы можете менять аттрибуты сесии.

Для чего POD я знаю :)

Просто это технология более ранняя и с ISG не связанная, а CoA может уже использоваться (для той же смены атрибутов), а значит не должно быть проблем заюзать Account Logoff. Тоесть, вместо POD + CoA использовать только CoA. Так должно быть проще и надежнее.

[zander]

Для сброса сессии использую CoA Request:

 

Cisco-AVPair=subscriber:command=account-logoff
User-Name=vasiliy
Cisco-Account-Info=S10.10.10.15

 

[raydo]

zander

Насколько я понимаю, данный пакет применим к логофу при использовании портала. А я портал не использую.

Я правильно понимаю, в моем случае должно быть что-то вроде

Packet-Type = CoA-Request
Cisco-command-code = "0x2ЧТО-ТО"
User-Name = "0004012c0101:00eb.0101.200e"
Cisco-AVPair="subscriber:command=account-logoff"

 

Вот с ЧТО-ТО не совсем понимаю. Там имя пользователя должно стоять? Или что?

[inkelyad]

У меня работает

Packet-Type=CoA-Request,
User-Name="undef"
Cisco-AVPair="subscriber:command=account-logoff"
Acct-Session-Id=<вытаскиваем из таблицы активных сессий>

[raydo]

А подопция

 

Cisco-command-code = "0x2ЧТО-ТО"

 

Для чего нужна? И нужна ли вообще?