Re: Tacacs+ сервер
Alexey Pechnikov <pechnikov@sandy.ru> wrote:
> В сообщении от Wednesday 02 July 2008 09:59:23 Andrey Melnikoff написал(а):
> > Alexey Pechnikov <pechnikov@sandy.ru> wrote:
> > > В сообщении от Tuesday 01 July 2008 23:31:59 Dmitriy Sirant написал(а):
> > > > Alexey Pechnikov пишет:
> > > > > В сообщении от Tuesday 01 July 2008 16:44:43 Andrey Melnikoff
> написал(а):
> > > > >> А можно поинтересоваться - почему благородных донов не устраивает
> > > > >> radius ? На свой фирменный протокол tatacs cisco забило болт уже как
> > > > >> лет 8, и всё что умело в то время tacacs давно научилось radius.
> > > > >
> > > > > Кстати, радиус только UDP умеет или можно через TCP прикрутить? UDP
> > > > > для телефонии не годится, потеря 5% это кирдык статистике.
> > > >
> > > > Ммм... а у Вас access server и billing (radius) териториально разнесены
> > > > ? Даже если да, то в радиусе есть настройки таймаута и количество
> > > > повторных отправок данных, поэтому вероятность потери стремится к нулю
> > > > (я надеюсь).
> > >
> > > Да, разнесены. А настройки повторов касаются авторизации, на которую
> > > циска ждет ответ и может узнать, надо повторять или нет, а поскольку
> > > аккаунтинг это только передача данных с циски, то никакой гарантии
> > > доставки нет и проверить доставку по UDP нельзя. И NetFlow уж лучше
> > > напрямую гонять с циски на
> >
> > В случае tcp - тоже. Потеря 5% пакетов и для tcp тоже станет проблемой.
> > Собственно поэтому мы tacacs+ и выкинули. Трафика между NAS'ами и сервером
> > авторизации оно жрет больше, тормозит вследствии tcp. Да, radius послыает
> > Accounting response на каждый accounting пакет. Так что кошка может
> > догадаться, что пакет радиус не получил. И еще один большой плюс -
> > Inteim-update - в такасе такого нету и не будет, ибо протокол сессионный.
> >
> > Выжми из такаса вот это:
> > .....
> > Connect Info Attribute (77), length: 26, Value: 46666/26400 V90/V44/LAPM
> > Vendor Specific Attribute (26), length: 55, Value: Vendor: Cisco (9)
> > Vendor Attribute: 1, Length: 47, Value: v92-info=V.92 QC MOH/QC Short
> > Train Success/0/0 .....
> > или вот это:
> > Vendor Specific Attribute (26), length: 41, Value: Vendor: Cisco (9)
> > Vendor Attribute: 1, Length: 33, Value:
> > client-mac-address=0030.9412.f919
> Это что?
Атрибуты.
> По протоколу такакс циска честно рассазывает все что знает. Разве что
> мак-адрес в такаксе не знаю как получить, но польза его сомнительна, ибо
Утож. Это вам в телефонии сомнительна, а во всяких там вайфаях очень даже
полезна, ибо по нему можно клиентов сортировать и управлять миграцией.
> смотреть на него если и нужно, то в процессе аутентификации, а не после.
> Информация о звонке идет в основном в атрибутах с префиксом "h323-":
> h323-call-type=Telephony subscriber=RegularLine
> h323-connect-time=14:10:45.996 MSK Wed Jun 25 2008
> h323-disconnect-time=14:11:39.971 MSK Wed Jun 25 2008
> h323-disconnect-cause=10 h323-ivr-out=Tariff:Unknown h323-voice-quality=0 и
> т.п.
всё то-же самое отдается в радиусе.
> >
> > > коллектор, а не через радиус на коллектор.
> >
> > У вас замутнен разум. netflow и radius это две разные разницы а не "муж и
> > жена" (C)
> А разве ваш радиус отдает логи не в формате NetFlow? Сама циска их шлет как
> раз в NetFlow?
Точно, на лоботомию пора. Это два РАЗНЫХ сервиса со своими протоколами. И
одних версий данный netflow порядка 10 разновидностей.
А то, что всякие биллингисты мешают их в одно ядро - так это им просто
удобно, ибо не надо морочиться с IPC.
Reply to: