lm

ASR 9k при работе в качестве BNG для IPoE и PPPoE клиентов со временем теряет стабильность - растут задержки на операциях с клиентскими сессиями от создания до закрытия, теряется синхронизация групп GeoRedundancy. Сильнее всего это проявляется после интенсивных операций CoA/Disconnect (например, массовая блокировка неоплативших за месяц), вплоть до невозможности создания новых сессий при одновременном умирании старых.Апгрейд IOS-XR с 5.3.3 на 5.3.4 ничего принципиально не изменил.Также не работает GeoRedundancy для PPPoE сессий, на слейве количество "кривых" сессий в разы превышает количество нормальных на мастере, а после switchover все они оказываются неработоспособны.Обе проблемы зависят от масштаба, на тестовых моделях с единичными сессиями не проявляются. Кто-нибудь сталкивался с похожими проблемами?

Эти строчки конфига фрирадиуса относятся к его связи с sql, а не вашим хотелкам )) Хотелки реализуются только на asr9k

Подскажите по лицензиям. По мануалу для работы BNG на каждые 16к пользователей нужна пара лицензий: A9K-BNG-LIC-8K + A9K-BNG-ADV-8K Для того, чтобы пользоваться натом, нужна A9K-XLAT-LIC-5M и еще для самого VSM-модуля A9K-VM-LIC Для vrf нужна A9K-IVRF-LIC Бандл с ебея едет без этих лицензий. Их реально прийдется докупать, или есть шансы что будет работать и без лицензий?

Про лицухи читал, но пока не знаю по-чем обойдется. Касательно роста, то при текущей его динамике и схеме с двумя бордерами запаса хватит лет на 5 минимум.)

Вместо 1+1 планируем ставить два бордера на разных IX и объединять их с ядром в кольцо через MLAG

Выбираем бордер+нат (2FV + IX), трафик 20-25Г, минимум 6х10G-портов, который планируется разместить на площадке IX. Стоимость размещения ~40-50евро/юнит. Два варианта, какой выбрать? 1. Bundle ASR1006 (ESP100+RP2+2xSIP40+6xSPA10GE) ~$30k 6 юнитов 2. ASR1002-HX ~$35k 2 юнита Оба варианта вроде примерно равны по возможностям/производительности. 1002-HX - в 3 раза меньше размером, 8х10G-интерфейсов, но это моноблок.

Есть два BRAS из ESR10k, на них раскиданы вланы доступа по схеме влан-на-свитч. ip unnumbered привязано к lo, на котором висит ip с маской /32, для каждого BRAS свой. Клиентам выдается привязанный к порту по opt82 ip (динамического пула нет) и широкая маска /16 для "серых" ip или меньшая, но тоже широкая, для "белых". На arp-запрос отвечает тот BRAS, на который заведен влан (причем не важно, висит ли на этом bras запрошенный ip). За счет этого ip клиента не зависит от того, к какому bras он подключен. В ядро брасы отдают по ospf маршрут на каждого клиента. В случае проблем с одним из брасов нужно перебросить все его вланы на оставшийся, например, скриптом. Существует-ли вариант, чтобы оба браса работали параллельно и самобалансировались, как на PPPoE, когда более нагруженный bras просто подтупливает с выдачей pado и клиент коннектится к более шустрому?

Ну х/з, у нас встречаются по несколько раз на дню.

Многие не дожидаются отсыхания даже 5-минутного таймаута сессии и звонят в техподдержку.

Может немного не в тему. Кто как решает вопрос при IPoE, если клиент переткнул свой входящий сетевой кабель из одного домашнего устройства в другое, например, из роутера в комп. напрямую? На BRASе нужно положить и поднять DHCP-сессию заново, но проблема в том, что BRAS об этом не знает.

При использовании IPoE значительное количество сессий "проваливается" через авторизацию по опции 82. При этом количество таймаутов в статистике по show aaa servers незначительно. В качестве "костыля" добавлена повторная авторизация по мак-адресу, которая скриптами в радиус-сервере переводит мак в порт свитча и далее проходит по основной базе. Количество сессий, авторизованых по опции82, относится к количеству сессий, авторизованых по маку, примерно как 2:1, то есть каждая третья сессия "проваливается". Что может приводить к неудачной авторизации, кроме таймаутов радиуса и возврата радиусом отрицательного ответа? Полиси-мап следующая: policy-map type control PM_X class type control CM_redir_timeout event timed-policy-expiry 1 service disconnect ! class type control always event session-start 10 authorize aaa password XXX identifier circuit-id plus remote-id 15 authorize aaa list KOSTYL password XXX identifier mac-address 20 service-policy type service name SVC_REDIR 30 service-policy type service name SVC_SRV 40 set-timer TIMER_unauth 5 ! class type control always event account-logon 10 authenticate aaa list L1 20 service-policy type service unapply name SVC_REDIR ! class type control always event session-restart 10 authorize aaa password XXX identifier circuit-id plus remote-id 15 authorize aaa list KOSTYL password XXX identifier mac-address 20 service-policy type service name SVC_REDIR 30 service-policy type service name SVC_SRV 40 set-timer TIMER_unauth 5 ! !

Спасибо. Поставили sb13, с марта и по сей день больше проблем не возникало.

На днях приобрели сабж: На неделе поставим на 5-км линк. О результатах отпишусь.

Крэшинфы нет. В release notes 14 версии написано, что устранен баг с самопроизвольной перезагрузкой при работе в режиме ISG.

Буду благодарен и 13-й. Вполне возможно, что с ней тоже будет работать стабильнее.