Mystray

У версий, которые MX5/10/40-80 и MX5-104 (то есть изначально урезанные софтово, но при этом железно полноценные) штатные десятки открываются лицензиями. Еще были изначально разлоченные бандлы mx80/mx104, у них все порты должны быть открыты. Но в случае вторички, скорее всего, все и так уже будет разлочено. В любом случае можно проверить при покупке, лишь бы был актуальный софт установлен. Отдельно лицензируется сабскрайбер менеджмент (динамические интерфейсы, дхцп по радиусу, пулы айпишников и прочее для браса). У них есть огромный, даже не подводный, а надгробный камень: 1GHz MIPS CPU, из-за которого флапы тяжелых BGP-пиров обрабатываются едва ли не десятки минут. А в случае MX80 еще и 2 гига оперативки. Да и на MX80 уже даты EOL объявили и они не за горами.

Погуглите tc nat он именно это и делает. Только селектор наверное надо будет городить, да и вообще у tc синтаксис марсианский.

Используем MX204 под бордеры, с портами 10 и 40Г. К SFP+/QSFP+ вроде нетребовательные, лишь бы не совсем треш был в прошивках. Несколько фулвью в нескольких VRF, с MPLS, VPLS, OSPF, flowspec, jflow. Процессорной дури за глаза, всасывает и наливает все 800 тыщ за секунды даже с достаточно развесистыми роутмапами. Оперативки внутри управляющей виртуалки под его задачи с головой. Глюки, конечно же, бывают - безглючного софта не существует. Но пока ничего критичного не случалось.

Если джун получил по ebgp более лучшие маршруты (в том числе благодаря локалпреф), и отдал их на Циску, а Циска тоже посчитала их более лучшими, чем те, что есть у нее - то она не будет анонсить джуну свои заведомо более худшие маршруты. Ну и на крайний случай есть show route hidden, show route receive-protocol bgp x.x.x.x all, да и show bgp summary/show bgp neigh x.x.x.x цифры не врут, как правило

На 17 не заведется, там нет vpls на ps-интерфейсах, надо 19+. нет, routing-instance включает в себя bridge-domain, на каждый такой routing-instance - отдельная пара psX.0 и psX.1 интерфейсов. На соответствующий psX.1 вешаем family inet и все необходимые роуты прям как на ge-.

Начиная с 19.1 можно попробовать искостылиться через vpls routing-instance и Pseudowire Subscriber Logical Interface (к примеру ps0.0 - encap vpls и мембер вплс-инстанса вместе с остальными езернет-портами; ps0.100, ps0.200 - family inet с unnumbered-address)

Не уверен, как было в 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 ?

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

Ясно, спасибо. Смутили изменения в 14.1X53-D40: Надеялся, что разрешили qinq вланам быть номерными, но похоже вместо этого разрешили l3-interface на неномерных, завтра смогу проверить все предположения на D47.

Каким образом у вас qinq влан создан? он имеет явный vlan-id в иерархии vlans? добавляете еще через vlans <vlan> interface xe-0/0/x.<unit> и на клиентский порт и на аплинк отдельным юнитом или иначе как? Аналогичный вопрос: у влана, привязанного к этому IFL, явно прописан vlan-id? как сам влан на qinq интферфейс и на аплинк привязан?

Автор полгода не появляется на форуме. Может, у кого-нибудь есть его альтернативные контакты?