StSphinx

Для начала хотя бы разрешите пропуск BPDU.

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 за все время было примерно ноль... Внедрять, конечно, будем... Благо железо в основном позволяет. Но в свободное от текущих задач время, то есть неспешно.

А вам прямо точно нужно чтобы именно FIB был больше 1M? Вот с моего MX104: uplinks.inet.0: 934517 destinations, 4250377 routes (212029 active, 0 holddown, 3583637 hidden) Тут у нас 2 IX'а, 4 аплинка и так, по мелочи - GGC, сессии с клиентами...

Была проблема чем-то схожая с вашей - так же , гигабитные линки, низкий upload, pppoe. Долго не ковыряли, но помогло включение flow control на портах доступа. Попробуйте, чем черт не шутит.

Повторюсь.... Логика такова, что есть разметка протоколов, а есть шейпер(ТП). Разметка только определяет тип протокола и как его пометить(можно конечно и там сделать drop, но это будет для всех абонентов). В ТП вы определяете, что делать с трафиком помеченным определенным значением dscp. Таким образом: - помечаете нужный вам протокол свободным значением dscp(например cs7). - смотрите в какой htb_class попадает это значение dscp(например htb_class7). - создаете ТП, где для этого htb_class7 указываете скорость 8bit/s. - навешиваете ТП абоненту. Примерно так. Более элегантное решение, возможно, подскажет саппорт VasExperts.

https://wiki.vasexperts.ru/doku.php?id=dpi:dpi_options:opt_priority:priority_config:start https://wiki.vasexperts.ru/doku.php?id=dpi:dpi_options:opt_bandwidth_mgmt:bandwidth_conf:start

Как вариант: - выносите QUIC в отдельный класс - создаете ТП, в котором на нужный вам класс назначается скорость 8bit/s - назначаете ТП абоненту Альтернативный вариант: - заводите тикет у VasExperts

Вполне

https://files.ixnfo.com/Manuals/Juniper/Packet-Triggered-abonenti-MX-BNG-v01-2.pdf Вот, накопал примеры. Попробуете, дайте знать что и как получилось.

Тоже интересно. Ссылочку на доку киньте, пожалуйста.

В ASDM раздел Public server вам в помощь. https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113425-asdm-pub-server-00.html В cli будет примерно так: object network Cam-1 nat (Inside,Inet) static Public-Servers service tcp rtsp 65530 Где Cam-1 это network-object описывающий хост, для которого нужно опубликовать порт, Public-Servers - внешний IP, rtsp - внутренний порт, 65530 - внешний порт.