StSphinx

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/unicast/nexus3000_unicast_config_gd_503_u1_1.html

@flamaster, даже не пытались. Мы используем исключительно SFU терминалы. Приходите в чатик: https://t.me/gpon_gepon , возможно народ что-то подскажет.

@flamaster, есть на сети 1608S-B0. В нашей схеме предоставления услуг B0 ни чем не отличается от GS. По эксплуатации тоже пока все ок.

@serego, а PREFIX это у вас что? IP адрес клиента? Скорее всего такой вариант авторизации вы реализовать не сможете, так как: То есть, IP адрес клиента появляется на сцене уже после стадии авторизации. Для реализации такого проще изменить логику авторизации в биллинге, если это в принципе возможно.

Конкретно такое не делал, но вроде как pmacct должен подойти для решения задачи. Он там всякое умеет.

@bladezz, у меня раньше получилось собрать стенд... Клиенты L2 connected, инициация сессии по src IP(без DHCP). Для L3 connected, изменится только routing-options. Вот такая конфигурация: Железо: MX80, софт: 19.4R3.11 Профиль сессии: routing-instances { //у меня клиенты живут в отдельном instance "$junos-routing-instance" { interface "$junos-interface-name"; routing-options { access-internal { route $junos-subscriber-ip-address { qualified-next-hop "$junos-interface-name"; } } } } } interfaces { demux0 { unit "$junos-interface-unit" { actual-transit-statistics; demux-options { underlying-interface "$junos-underlying-interface"; } family inet { demux-source { $junos-subscriber-ip-address; } unnumbered-address "$junos-loopback-interface"; } } } } Настройка subscriber-faced интерфейса: #show configuration interfaces xe-0/0/1 unit 112 description IPoE-test; demux { inet { address source; auto-configure { address-ranges { dynamic-profile IPoE { network 172.30.8.128/25 { range R1 { low 172.30.8.129/32; high 172.30.8.253/32; } } } authentication { password radPASSWORD; username-include { source-address; } } } } } } vlan-id 112; family inet { unnumbered-address lo0.10 preferred-source-address 172.30.8.254; } Ну и loopback: #show configuration interfaces lo0 unit 10 description Inet; family inet { filter { input-list [ icmp icmp-other icmp-frag trace-tcp trace-udp nothing-else ]; } address 192.168.4.10/32; address 172.30.8.254/32; } Профиль сервиса не показываю. Он довольно развесистый, единый у меня как для IPoE так и для PPPoE.

@AAS , можете и мне ссылочку кинуть на 9.3.8 ?

sessions per-mac limit 10 - а как это решает вашу проблему? У нас сейчас вот так настроено: bba-group pppoe global virtual-template 1 vendor-tag circuit-id service vendor-tag strip sessions max limit 65530 sessions per-mac limit 1 sessions per-vlan limit 1024 sessions per-mac throttle 6 60 240 sessions auto cleanup

@alibek я опять побуду в роли Кэпа - не мешало бы посмотреть, PADI от проблемных клиентов прилетают или нет. monitor capture ... либо debug pppoe events interface | rmac .... На старом BRAS'е pado delay не настраивали? А то может ASR просто отрабатывает медленнее чем старый и сессия уходит туда.

@alibek а саппорт биллинга не помогает или оно таки уже все?

@Andrei, то что вы описываете больше похоже на Idle-Timeout. То описание, что вы привели конечно находится в первой строке поисковой выдачи, но работает фактически не так как описано. Session-Timeout задает именно максимальную длительность сессии. @alibek насколько мне известно, дефолтного значения этого атрибута нет. Вам бы стоит посмотреть дамп трафика между БРАСом и Radius'ом. Возможно вы задаете правильно в тарифе, но где-то в настройках есть глобальная политика , которая это переопределяет.

Bill-Master еще живо??? А по сути вопроса, попробуйте отдавать атрибут Session-Timeout с нужным вам значением.

@orlik стоял до этого MX80. Было примерно так же стыков. Принимал 2 FV + 2 IX. Но таки да - при флапах он крепко задумывался минут на 15 при обработке маршрутов. Благо на форвард трафика это никак не влияет. @Urs_ak вас понял. Но вы же в курсе, что FIB это активные маршруты и там то, что вы разрешили/не порезали. А вот в RIB все что вам скормили ваши пиры.

@Urs_ak, да он по толще будет и у него FIB 1.8M. Но вы так и не сказали, а вам реально нужно столько активных маршрутов? У вас IX или вы транзитный оператор с большим кол-вом клиентов?

Согласен с UglyAdmin. Эра провайдинга "just for fun" давно закончилась и сейчас все про деньги. Пока в IPv6 не появится именно коммерческая необходимость, никуда оно широкими шагами не пойдет. Могу сказать на примере нас, небольшого оператора масштаба города и района прилегающего к городу. Запросов на IPv6 за все время было примерно ноль... Внедрять, конечно, будем... Благо железо в основном позволяет. Но в свободное от текущих задач время, то есть неспешно.