Перейти к содержимому
Калькуляторы

tsolodov

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    83

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем tsolodov

  1. Опубликовано · Жалоба на ответ

    По поводу CoA - у нас настройки такие же. Только команду с сервера немного по-другому пишем:

    echo 'User-Name="10.10.99.4",Cisco-Account-Info="S10.10.99.4",cisco-avpair="subscriber:command=account-status-query"' | /usr/local/bin/radclient -x asr:1700 coa coa

    Ответ возвращается корректный.

    Вы используете VRF на BRAS????

  2. Опубликовано · Жалоба на ответ

    Вообщем чтобы не плодить сервисы с разной скоростью локально, надо сделать Policy-Server, который бы выдавал сервис с параметрами ограничения скорости.

    Чтобы работал CoA нужно

    1) сконфигурить portbundle

    2) добавить RADIUS-сервер в

    aaa server radius dynamic-author

    !

    aaa server radius dynamic-author

    client 1.1.1.1 server-key 7 121A0C041104

    auth-type any

    ignore session-key

    ignore server-key

    !

    Где 1.1.1.1 это IP адрес машины с которой я посылаю CoA запросы.

    Дело в том, что запрос Coa cisco принимает и отвечает на него

    [root@radius-new ~]# echo "User-Name=\"10.91.0.101\",Cisco-Account-Info=S10.91.0.101,Cisco-AVPair=\"subscriber:command=account-status-query\"" | radclient -x pogran-3:1700 coa сisco

    Sending CoA-Request of id 226 to 194.190.176.198 port 1700

    User-Name = "10.91.0.101"

    Cisco-Account-Info = "S10.91.0.101"

    Cisco-AVPair = "subscriber:command=account-status-query"

    rad_recv: CoA-NAK packet from host 194.190.176.198 port 1700, id=226, length=87

    User-Name = "10.91.0.101"

    Cisco-Account-Info = "S10.91.0.101"

    Cisco-Command-Code = "\0040"

    Reply-Message = "No valid Session"

    Error-Cause = Session-Context-Not-Found

    Да многие советуют включить этот самый portbundle, но зачем мне он если портала у нас нет(во всяком случае пока), да и в документации написано при coa запросе PBHK это необязательный параметр запроса, если кто обошелся без этого параметра, отпишите пожалуйста мне, не хочется городить то, без чего могу обойтись в данный момент.

     

    Чтобы не плодить сервисы локально можно сделать policy-server, что я впринципе и сделал, но беда в том, что сервисы множить буду уже не локально а в RADIUS.

    Кто и какую идеологию в данном случае использует?

    Например есть тариф, при которм после скачки допустим 30Гиг внешки, скорость должна падать до 256 Kbps. что получается, для одного тарифа нужно делать 2 сервиса(Скорость до исчерпания лимита и после)?

    Тут я вижу 2 варианта в нашей ситуайции:

    1) Использовать функционал Prepaid с лимитами и при исчерпании лимита привешивать сервис со скоростью после падения(пока только в теории представляю как это сделать)

    2) Сделать отдельный сервис для каждой скорости для uplod'a и downlod'a и просто менять атрибуты пользователя, изсходя из того, какую скорость "выдаст" наш биллинг, но при этом нужно будет делать обработчик, который будет отслеживать изменения атрибутов пользователей, и при этом обрабатывать эти изменения, запизивая их в RADIUS.

     

    И все таки, если кто пользовал параметрицеский QoS, отзовитесь!!!!!

     

     

  3. Опубликовано · Жалоба на ответ

    Добрый всем день,

    не бете сразу, уже много раз читал гугл и тому подобные сервисы про сабж.

    Есть пара вопросов:

    1)

    http://www.cisco.com/en/US/docs/ios/ios_xe....html#wp1058724

    RADIUS Attributes 250 and 252

     

    RADIUS uses attribute 250 in Access-Accept messages and attribute 252 in CoA messages to activate and deactivate parameterized services. ISG services are configured locally on the ISG device; RADIUS sends only the service name.

     

    Attributes 250 and 252 have the following syntax for service activation:

     

    Access-Accept Messages

    250 "Aservice(parameter1=value,parameter2=value,...)"

     

    CoA Messages

    252 0b "service(parameter1=value,parameter2=value,...)"

     

     

    RADIUS uses only Attribute 252 in a CoA message when deactivating a service. RADIUS sends the same information in Attribute 252 that was used for service activation, except that service deactivation uses 0c in the syntax instead of the 0b parameter used for service activation.

    Как я понял то можно создать один сервис и к каждому пользователю привесить атрибут со свим параметром(например скорость полисинга)

     

    Сейчас у меня:

    10.91.0.101 Password := "cisco"

    Cisco-Account-Info += "AWORLD2",

    Cisco-AVPair += "accounting-list=Account"

    Все прекрасно работает, но было бы круто податвлять для каждого абона свою скокрость, чтобы не плодить сервисы. Кто может дать рабочий пример или ссылку на адекватную доку?

     

     

    2)

    Пытаюсь отладить CoA, но не получается даже статус чела узнать.

     

     

    ISG#sh sss session

    Current Subscriber Information: Total sessions 1

     

    Uniq ID Interface State Service Identifier Up-time

    1 IP authen Local Term 10.91.0.101 00:47:27

    Вот что выдает команда
    [root@radius-new ~]# echo "User-Name=\"10.91.0.101\",Cisco-Account-Info=S10.91.0.101,Cisco-AVPair=\"subscriber:command=account-status-query\"" | radclient -x pogran-3:1700 coa cisco

    Sending CoA-Request of id 24 to 194.190.176.198 port 1700

    User-Name = "10.91.0.101"

    Cisco-Account-Info = "S10.91.0.101"

    Cisco-AVPair = "subscriber:command=account-status-query"

    rad_recv: CoA-NAK packet from host 194.190.176.198 port 1700, id=24, length=87

    User-Name = "10.91.0.101"

    Cisco-Account-Info = "S10.91.0.101"

    Cisco-Command-Code = "\0040"

    Reply-Message = "No valid Session"

    Error-Cause = Session-Context-Not-Found

    Вот дебаг

    ISG#

    Feb 7 17:20:54.371: RADIUS: COA received from id 122 195.122.226.59:51497, CoA Request, len 100

    Feb 7 17:20:54.371: COA: 195.122.226.59 request queued

    Feb 7 17:20:54.371: RADIUS: authenticator 98 7C E3 18 3F 5A 9F D3 - 00 3A 08 BF FE B6 5B 5C

    Feb 7 17:20:54.371: RADIUS: User-Name [1] 13 "10.91.0.101"

    Feb 7 17:20:54.371: RADIUS: Vendor, Cisco [26] 20

    Feb 7 17:20:54.371: RADIUS: ssg-account-info [250] 14 "S10.91.0.101"

    Feb 7 17:20:54.371: RADIUS: Vendor, Cisco [26] 47

    Feb 7 17:20:54.371: RADIUS: Cisco AVpair [1] 41 "subscriber:command=account-status-query"

    Feb 7 17:20:54.371: ++++++ CoA Attribute List ++++++

    Feb 7 17:20:54.371: 3B86B320 0 00000009 username(432) 11 10.91.0.101

    Feb 7 17:20:54.371: 3B86B248 0 00000009 ssg-account-info(468) 12 S10.91.0.101

    Feb 7 17:20:54.371: 3B86B258 0 00000009 ssg-command-code(470) 13 04 20 31 30 2E 39 31 2E 30 2E 31 30 31

    Feb 7 17:20:54.371:

    Feb 7 17:20:54.372: RADIUS/ENCODE(00000000):Orig. component type = Invalid

    Feb 7 17:20:54.372: RADIUS(00000000): sending

    Feb 7 17:20:54.372: RADIUS(00000000): Send CoA Nack Response to 195.122.226.59:51497 id 122, len 87

    Feb 7 17:20:54.372: RADIUS: authenticator AC D4 05 4F 8A 4C 17 A1 - C0 0A D8 20 06 23 8B 2F

    Feb 7 17:20:54.372: RADIUS: User-Name [1] 13 "10.91.0.101"

    Feb 7 17:20:54.372: RADIUS: Vendor, Cisco [26] 20

    Feb 7 17:20:54.372: RADIUS: ssg-account-info [250] 14 "S10.91.0.101"

    Feb 7 17:20:54.372: RADIUS: Vendor, Cisco [26] 10

    Feb 7 17:20:54.372: RADIUS: ssg-command-code [252] 4

    Feb 7 17:20:54.372: RADIUS: 04 30 [Account-Ping 0]

    Feb 7 17:20:54.372: RADIUS: Reply-Message [18] 18

    Feb 7 17:20:54.372: RADIUS: 4E 6F 20 76 61 6C 69 64 20 53 65 73 73 69 6F 6E [ No valid Session]

    Feb 7 17:20:54.372: RADIUS: Dynamic-Author-Error[101] 6 Session Context Not Found [503]

    Помогите кто чем сможет ))

  8. Опубликовано · Жалоба на ответ

    Идея проста, сделать кластер балансировки нагрузки из шейперов под фрей, в данный момент имеется грубо говоря по шейперу на микрорайон, какой то загружен сильно, какой то наоборот. Иногда если один шейпер падает, то юзеры одного из микрорайонов посасывают. Хочется сделать кластер с балансировкой нагрузки. Для шейпинга используется pipes+ipfw. Балансировка ИП трафика сделать несложно, но вот незадача: как расшарить между всеми нодами использование pipe'ов пользователями, т.к. если этого не сделать, то получится что полоса будет равна (количество нод * BW). Или нет?

     

     

    Кто делал подобные вещи, отзовитесь пожалуйста!!!

     

     

    Комментируем, делимся опытом!