Mystray

Не уверен, как было в Comware 5, но в HPE-шном Comware 7 есть display device [verbose] и display boot-loader Можно документацию поискать на брендированный HP-шный аналог(если такой есть), там вроде и старые версии на My Networking Portal должны оставаться

С тем, что установлено на железке, то что после Release <..>display version H3C Comware Software, Version 7.1.045, Release R7178 ...

у вас роутмап есть, который матчит acl all: route-map set-nexthop permit 10 match ip address all но самой ацлки all то есть access-list all permit any я не нашел. Соответственно никакие адреса не подпадают под данный терм, а других термов там нет.

Должна быть связность внутри автономной системы: бордеры должны иметь маршрут к выданному адресу внутри своей АС, тогда не важно, сколько аплинков и сколько бордеров.

Клиент сам определяет, к кому из брасов обращаться. Максимум - можно вносить задержку ответа в конфиге браса, тогда клиент, скорее всего, обратится к первому, но и это не точно и не гарантированно. Клиент кидает широковещательный PADI (с, возможно, именем сервиса) - ему отвечают все брасы PADO (просто сигнализируя "я тут, с такими-то именами сервисов"), дальше клиент сам выбирает тот брас, что ему нравится, и уже ему кидает PADR юникастом, а тот устанавливает PPPOE-туннель и отвечает PADS. На всем этом пути нет ни логинов, ни паролей, ни состояний вплоть до padr/pads (когда уже выбран брас), так что радиусы прикручивать на этих этапах несколько проблемно будет: что именно передавать в радиус?

разве так не работает?

Мы не телефонный, мы ШПД юрлицам даем. Я говорил не о размере базы, а количестве (пере)записанной информации на сторедж, для оценки износа.

Об SSD в серверах: используем Intel DC S3510 (перебрендованные в HPE Read Intensive что-то там), под основной сторедж в гипервизорах. Сами ссд 5 шт. собраны в рейд5 (средствами HP P440ar, не столько для сохранности данных, сколько для отсутствия простоя при проблемах и заменах), поверх еще сетевой рейд1. На серверах - почти все (биллинги, статистика/графики, логи, днсы, и остальная провейдерска мелочь) кроме вторичных экземпляров важных сервисов. За полтора года рейдовая тулзень показывает такой износ: Usage remaining: 87.70% Power On Hours: 13728 Estimated Life Remaining based on workload to date: 4078 days Гипервизор говорит, что за 230 дней аптайма записано 172ТБ. Нас более чем устраивает (сказевые винты столько не прожили, сколько вангует тулза). Флоу не храним, но БД биллинга при периодических джобиках поворочать базой любит (примерно 20ТБ записано за 230 дней от нее).

Вы знаете, как на Github делается pull request?

Здравствуйте! Есть ли у кого-то положительный опыт покупки и/или прошивания QSFP+ для закоса под HP JG661A?

в отсутствии разрешающего правила в цепочке FORWARD? А зачем там еще и SNAT?

а то что разные интерфейсы в оспф включены - ничего? network=172.16.0.0/24 на микротике, значит будет включен осфп на интерфейсе vlan10 а network 172.16.1.0/24 на SNR, предполагаю, включит ospf на vlan11, но никак не на vlan10

Одна из причин появления этих двух уродцев в том, что изначально IPSec на многих платформах был только policy-based, когда выбор шифровать или не шифровать трафик был только по каким-то параметрам пакета (ip/proto/port, в лучшем случае - interface), и не было простого и понятного route-based vpn. ipsec over gre или gre over ipsec как раз из таких целей: делается политика "шифровать ip proto GRE" (или "шифровать все на интерфейсе gre*" если платформа умеет), а все остальное (какой трафик куда толкать, динамическая маршрутизация, фаерволы) навешивалось уже на конкретные GRE-туннели понятным человеку образом.

в качестве логина микротику используйте "oxidized+ct", он тогда не будет пытаться понять, что за терминал посредством управляющих символов.

/proc/sys/net/ipv4/icmp_ratelimit /proc/sys/net/ipv4/icmp_ratemask /proc/sys/net/ipv4/icmp_msgs_burst /proc/sys/net/ipv4/icmp_msgs_per_sec ?