buckethead

Три радиуса это преступно мало :) По хорошему радиус должен быть отдельно для клиентских сессий, отдельно для клиентских сервисов, это без учёта их дублирования. Я вас понял, буду знать теперь, ещё бы рассказали, как делали, для потомков)

Идея интересная. Но обычно архиважные b2b приземляются без ISG, потому как всё на словах и честном слове, а сервис прерывать нельзя даже после не оплаты. Стоит ли овчинка выделки? Что касается RADIUS, то он прекрасно скейлится, даже если группа серверов выйдет из строя, есть фолбек механизмы, которые могут обеспечить беспрепятственный доступ клиента к Сети. Мне ваше решение кажется странным, потому что в идеале весь контроль над политиками должен быть максимально дистанцирован от BRAS в сторону серверов с политиками.

Большое спасибо за кусок конфига. "authorize aaa password cisco identifier nas-port " это всё равно не помогло (хотя счётчик на данное действие каждый раз увеличивается, значит оно выполняется?..). Сессия стартует, но имя юзера пустое. Мне получается на данном этапе и не нужен RADIUS, мне нужно просто чтобы ASR подставил в качестве имени юзера имя порта (что вполне логично на interface-сессии). А в дальнейшем планировал с помощью COA - запросов управлять данной сессией - накидывать или убирать редиректы, opengarden'ы и проч политики. По какому именно параметру надо включить дебаг в данной ситуации, чтобы понять, что происходит, и где затык при работе этой control-policy? BNG без RADIUS это как-то странно, с таким никогда не сталкивался и не понимаю, зачем такое вообще может понадобиться.

Чтобы понимать нужно еще знать вашу статистику по GGC-сервервам. Ну или кол-во абонентов. От какой базы вообще стоить начинать заморачиваться такой штукой. GGC отдаёт 9-11G в сторону клиентов.

Не, там только график рисуется, что-то в районе гига отдаёт, до 300 mbps максимум на входе. Чуваки говорят, что там nginx как кэширующий прокси, если руки из нужного места растут, то делается легко, плюс есть саксес стори в сети.

Сами ребята собирали, могу только сказать, что работает до сих пор, лично не участвовал, так как не мой профиль.

Пробовали, работает.

В вашем же документе указывается: Ничего общего с длиной префикса вроде.

Если не сложно, приведите кусок конфига (control-policy), который авторизует такие сессии. А в общем случае,как я понимаю ip subscriber interface сессии можно авторизовать без радиуса, если в качестве имени пользователя использовать nas-port? policy-map type control pm-interface-sessions class type control Unauth event timed-policy-expiry 1 service disconnect ! class type control always event session-start 1 authorize aaa password cisco identifier nas-port 3 set-timer Unauth 3 ! class type control always event session-restart 1 authorize aaa password cisco identifier nas-port 3 set-timer Unauth 3 ! class type control always event access-reject 1 service-policy type service name OpenGarden 2 service-policy type service name L4R 3 set-timer Unauth 3 ! !

Каким образом можно сделать ip subscriber interface сессию authen? Мне казалось, что там по автомату имя интерфеса и именем пользователя. В каком мануале можно об этом прочитать? ISG configuration guide, раздел Control Policies или в другом мануале циски? Это же зависит от идентификатора, который вы примените в политике. У нас настроен nas-port, оттуда на RADIUS регуляркой просто забирается пара STAG/CTAG. Ничего сложного.

Вопрос больше в сторону Quagga, поведение у J согласно стандарту.

на большом количестве маков она актуальна почти для всех свежих свичей, вопрос лишь в масштабе коллизий. Много маков на аксесе? Сам себе злобный буратино.

QinQ делают на агрегации или пред-агрегации, зачем qinq делать на доступе? На агрегации можно каждый downlink в свой stag засовывать или так же сделать traffic segmentation/port isolation.

Разве в 2k17 ещё остались те кто не понимает: что колизия может возникнуть и между двуми мас в одном vlan вопрос лишь с какой вероятностью. что есть особо одарённые производители которые совмещают номер vlan и мас в одном хэше. ;) В 2k17 есть те, кто понимают, что flood forwarding в пайпе от filter forwarding по сути не отличается ничем :)

L2 до BRAS это наиболее распространённый кейс, как в BNG-решениях (некоторые из них вообще l3-connected не умеют), так и в крупных операторских сетях. Это позволяет держать доступ относительно простым, так как авторизация в основном делается по паре stag/ctag непосредственно BRAS'ом, нет необходимости в opt82 и прочих костылях на доступе, dual-stack также делается гораздо проще. L2-connected даёт полное управление трафиком клиента по всем направлениям. L2 поднимается на L3 при помощи MPLS, поэтому с резервированием L2 проблем никаких нет. Плюс в крупных сетях BRAS всё таки не один, и в коре у вас по сути уже L3, но не между "цисками на узле", а между полноценными сервисными шлюзами. Если сеть маленькая -- просто тяните QinQ до BRAS. Всё остальное -- колхоз и костыли.

В 2k17 остались коммутаторы с проблемами коллизий хэша? (В 2k17 кто-то строит не vlan на абонента? :D)

Да, такой же кабель абсолютно.

Ну там есть же два порта -- console и aux, в обоих глухо?

Это ещё почему? В AUX подключались? Вообще весь процесс загрузки видно, правда, не могу сказать, что это актуально для схемы a/s или stand-by модуля. У нас одно время несколько раз умирала файлуха на CF, тоже всё пинговалось, но не пускало, в AUX было видно, как линуха по кругу перезагружалась. В неё там даже можно провалиться и посмотреть чего-нибудь.

Тоже долго плевались на 1210ME после 3000, но что поделать? Сейчас нашли для себя более-менее стабильный софт, не смотря на наличие нескольких новых билдов. Работает коммутатор нормально, так как по словам D-Link это их основная линейка коммутаторов, ориентированных на SP рынок в России, выбирать особо не из чего. Так же говорят, что цикл разработки, выпуска новых билдов и правки багов на этой линейки самый высокий (по релизам на ftp заметно, кстати), среди других линеек (включая 1510), так как R&D для них расположен в Рязани. Ну и наличие этих коммутаторов на складах, плюс какие-никакие основания рассчитывать на длинный life cycle линейки в отличие от dgs-3000 (а ведь был такой замечательный коммутатор!).

IP helper address работает 100%, но сессия, разумеется, должна быть authen. C unnumbered работает в таком ключе: тянет маршрут с лупбека, но на один лупбек можно указать лишь одну interface session. Однако, тут форумчанин нашёл способ обойти это ограничение: на интерфейсе не указывается ip unnumberd, так же как и ip address, но ip unnumbered передаётся в AVpair с RADIUS, и тогда с одного лупбека можно сколько угодно (сколько именно -- не известно) поднять interface session. Мне бы это сильно помогло в своё время, если бы не перешёл на другого вендора, где это из коробки работает.

Единственное, на mx 80 re не то чтобы шустрый, если есть возможность, лучше смотреть в сторону mx 104.

Можно, там же junos, filter based forwarding в гугле.

Ладно. Huawei S5320, 1 RU, 4x10G (SFP+), 1G по вкусу. 12K ARP.

Rack-space driven-networks это сильно :D