orlik

ну если лень , то конечно только страдать

может лучше использовать какти, или для отрисовки графиков - графану ?

RFC уже успели написать ?

ну а ты попробуй дропать пакеты размером в 1500 байт , и посмотри на результакт

снимите дамп трафика , и посмотрите почему у вас tcp сессия рассыпается (в первую очередь mss) запустите iperf с udp со скоростью в 50mbps и проверьте какие у вас при этом будут дропы. А то устроили тут гадание ...

mtu проверьте

трудности ... сделайте vrrp и поднимите bgp c vip адреса. тупое решение , но при ваших входных данных - это идеальное решение

повесьте разные localpref на разные роутеры на клиентские маршруты и забудьте о проблеме

написать скрипт который будет это делать, команды такой - нет ну или вот так ещё можно ну или еще смотрите hold-down на этой же странице

ну и второй вопрос . зачем вам обязательно ed25519 ?

Так не надо менять для всех , сделайте измененя только для github.com Host github.com KexAlgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,curve25519-sha256 Ciphers aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr

мозг надо включить, и всё сразу заработает

Обязаны и пропускают ничего не блокируя. Примите как факт Всё что у вас заблокировано, вКазахстане работает

в пределах одного логического интерфейса придётся. в forward-only mx добавляет в opt82 название интерфейса , с которого прилетел запрос. кому как. сложно слишком универсально и не понятно P.S. сможете ли вы такое сконфигурить - сомневаюсь, но попробуйте :)

@Ser, ну тогда проще , конфигурите dhcp-relay с forward-only опцией. Но не понятно о какой opt82 может быть речь на mx ? что вы хотите там вставлять ? Не понятно зачем тогда dhcp-relay. Так и аутентифицируйте нормально клиента и возвращайте ему всегда один и тот же адрес. Мне в данном случае не понятна логика работы MX, он должен пропускать dhcp запросы прозрачно , но потом авторизовать по src-ip ? Но при этом клиент прописывает адрес статикой и не понятно, накой в этой схеме dhcp (для первый раз подключившегося абонента )? Мне кажется вы сильно усложнили схему , достаточно было просто сделать dhcp-server/dhcp-relay и забыть обо всех этих сложностях. Особенно учитывая что из примера @StSphinx, видно что на каждый интерфейс у него привязывается определеный пул. никакого unnumbered

Врятли , как вы себе представляете и dhcp и инициализация по src-ip ? это система должна выставить приоритеты для одного и другого способа аутентификации, чтобы не перепутать абонента и не авторизовать его дважды. А вообще , если вас устраивает dhcp-relay , то непонятно зачем вам нужен не сильно стабильно работающий l3-connected ?

Единственный вариант формировать логин/пароль из получаемых атрибутов прям на радиусе и логин возвращать на мх. Но схема странная …

1 наверняка должна быть опция advertise-inactive 2 маркируйте пакет на входе и потом разруливайте куда его маршрутизировать. iptables/iproute такое умеют

@StSphinx, у mx104 в отличии от MX80, 2GB на PFE, и 4GB на RE, так что он точно должен прожевать 1М в FIB. mx80 совсем кастрированный , у него на PFE 1GB памяти и на RE всего 2GB.

не надо бояться 1М рпрефиксов. С такой точки зрения можно порезать FIB (на MX это делается без проблем), а клиенту отдать FV из RIB. Default у вас в сети по любому должен быть. Это конечно немного извращение, зато без лишних финансовых затрат

просто коробка кеширует данные и обновляет их реже чем 1 раз в минуту

MX80 спокойно вытянет более 1М фиб. :) А за эти деньги вы точно ничего не найдёте

Есть , никуда он не делся. Только делать там нечего, как раз потому, что там мало народу. Идите в телеграм в тематические группы, там быстрее получите совет

обновитесь , это баг. как вариант можно mgd рестартануть, возможно это поможет.

так что мешает удалить текущий ios и залить правильный ? Или у вас там отключаю электричество каждые несколько минут ? P.S. зачем заливать через xmodem если можно на ноуте поднять tftp/dhcp и сделать гораздо быстрее ?