deseven

В общем корректный ответ в нашем случае выглядит как-то так (пока без политик). Framed-IP-Address = 10.100.31.254 Framed-IP-Netmask = 255.255.255.255 Service-Type = Outbound-User Idle-Timeout = 180 Session-Timeout = 180 Acct-Interim-Interval = 90 IP-Interface-Name = "vlan3004" Context-Name = "test"

Вот с логов на SE100 что удалось вытащить 24998 OUT Tue Jan 21 22:45:47.580048 IPC_ENDPOINT = CLIPSd, MSG_TYPE = DB_RESPONSE, authen response = 2 Username = 10.100.31.254, CCT_HANDLE = Unknown circuit Internal Circuit = 2/3:511:63:31/13/2/18750 aaa_idx = 5000493f, extern_handle = 2493e, pvd_idx = 40080201, Event code = 0 Жалуется на Unknown circuit. Как ему его передать?

Спасибо. А что такое Vendor-Specific?

Ну например дефолтный ответ Sending Access-Accept of id 47 to 195.191.220.17 port 1812 Framed-IP-Address = 10.100.31.254 Порылся в инете, у некоторых шлется еще Context-Name, Service-Type и IP-Interface-Name, но не помогает. Также в случае DHCP нужно отправлять DHCP-Max-Leases = 1, но мы то пытаемся сделать nonDHCP. В любом случае пробовал добавлять и это. p.s. ну тема то началась не с агрегации как таковой

Кто-нибудь использует nonDHCP схему авторизации по радиусу? Можете скинуть пример ответа от радиус-сервера? Сейчас приходит например вот такой запрос rad_recv: Access-Request packet from host 195.191.220.17 port 1812, id=118, length=148 User-Name = "10.100.31.254" User-Password = "Redback" Service-Type = Outbound-User NAS-Identifier = "se100" NAS-Port = 33751040 NAS-Real-Port = 33751040 NAS-Port-Type = Virtual NAS-Port-Id = "2/3 clips 150994" Medium-Type = DSL Platform-Type = SE-100 OS-Version = "12.1.1.5" Пробую по-всякому отвечать с Access-Accept, все равно в итоге в show subscribers висит статус AUTHENTICATING.

zstas А вы сами читаете что вы пишете? Почему обязательно через другой? Ну зашло нам 1Гбит трафика, почему мы его по тому же порту куда-нибудь еще отправить не можем раз у нас фуллдуплекс? Откуда место? Ну так исходящая полоса на этом канале же почти вся свободна. Хорошо, прям целиком 1Гбит мы конечно же по тому же порту никуда отправить не можем, но пусть это будут 700-800Мбит, какая разница то? Если бы аплинки и абонентов можно было повесить на одну агрегацию, то мы в пике имели бы это: - получаем с аплинков 4Гбита, отдаем обратно 2Гбита - отдаем абонентам 4Гбита, получаем обратно 2Гбита Вот они, 12Гбит из презентаций. Но так делать нельзя, поэтому: - получаем с аплинков 3Гбита, отдаем обратно 1.5Гбита - отдаем абонентам 3Гбита, получаем обратно 1.5Гбита Выходит 9Гбит. Разница есть? Чтобы при такой схеме были все 12Гбит задействованы, нужно поднять соотношения rx/tx до 1/1, чего никогда не будет и быть не может.

да с чего бы? пришел на один порт по одному влану, ушел по этому же порту по другому влану минус расходы на исходящий траф, конечно

zstas была заявлена общая производительность в 12Гбит (6 туда и 6 обратно, фулдуплекс) это во всех презентациях пишут да ладно не сможет? мы собственно сейчас так и делаем (не на SE100 конечно), 2Гбита из инета, 2 Гбита юзерам (реально чуть меньше, с учетом исходящего трафа) - все по двум гигабитным линкам

Т.е. в итоге получается, что при реальных задачах железка рассчитана не на 6Гбит, а на 3Гбит? Весь этот маркетинг дурно пахнет.

Нужна /22 или хотя бы /23 в долгосрочную аренду или покупку.

подробнее ~sybase/OCS-15_0/bin/isql -Spqbsyb1 -Usa -Ppcube2001 -D apricot alter table RPT_LUR drop IP_TYPE go таблица заполняется, графики строятся, спасибо

По-момему проще для вывода в консоль юзать тот же iconv. КОИ давно уже не актуален, забудьте про него.

Держите Принимает соединения как с пустым service-name, так и с рандомным