ollsanek

Круто, если "-ifa" именно подменяет src ip. man так написан, что я б из него не догадался без помощи зала. сам такую задачу решал несколько лет назад, через pf натом собственного трафика в адрес лупбека. Работало отлично.

т.е. в отдельную Totally Stubby Area хотите его засунуть? У кого работает, напишите в такой ли конфигурации? А то микротиков, например, дико плющило в Stub ...

А почему там пусто? вы ж вроде, дефолт редистрибьютите в ОСПФ? т.е. GWP1 должен быть известен дефолт через GWP2, верно?

ТС не хочет пилить свич, он хочет в уже полноценный свич свич впилить что-то своё.

а что arista никто не посоветовал? Офицально поддерживаемая фича: https://eos.arista.com/package-rpms-into-an-arista-swix-extension/ (увы сам не пробовал)

тут в какой-то теме про bdcom упоминали эту проблему, вроде так: 1 - да 2 - да 3 - хз

сори за офтоп, но точно будет тупить? У меня на кое-где на 650SRX-ах (а они софтовые) тоже по 10 минут перестраивается и проц в полку, но на форвардинг не влияет.

баги активно в 12.3 чинят, попробуйте 12.3R11 - рекомендованая сейчас для ЕХ-ов.

книжка 2011г., т.е. написана в 2010. в 2004 писали про 50-60 роутеров в ареа. Закон Мура ... Так что произвольно экстраполируя можно утверждать, что ~1,5k нормальных, современных железок в одной ареа вполне могут существовать. (ещё пару лет назад некоторые большие провайдеры утверждали, что так и живут) как бы да, но всегда найдётся какой-то микротик или с2811, которых боязно выпускать в ареа 0.0.0.0

>> Почему вложенные объекты bond0 и vmbr0 не наследуют родительские свойства (qlen 10000 и qdisc mq) объектов eth0 и eth1? удивлён такому вопросу от ТС, у меня стойкое ощущение, что об этом написано на каждом углу. или это такой изящный троллинг? а если порассуждать почему так... С одной стороны тот же микротик наследует. с другой стороны в бондинг/бридж вы добавляете объект из 2го уровня модели OSI, т.о. наследовать свойства 3го уровня - неоднозначное решение.

бриджей нужно столько же сколько вланов "+1". эти 50 бриджей - заглушка для возможности поменять мак на микротике. нет, это тот самый "+1" бридж да :) сумбурно написано, согласен. этот бридж, который "+1", как раз выполняет роль такого PtMP пачкорда

Бугага! ТС я решил твою задачку, рецепт: итак, маки меняются на бриджах, бриджи прибиваются к ВЛАНам, это понятно. вланы, допустим от 100 до 150, выпускаешь в коммутатор (порт1) с тегом (подключение к провайдеру без тега). на коммутаторе эти тегированые вланы с тегом выносишь в порт2 который соеденяешь пачкордом с портом3 коммутатора. порт3 коммутатора настраиваешь аксесом для влан 200 (qnq), и влан 200 засовываешь через порт1 обратно в микротик. в микротике создаёшь 50 (?) интерфейсов с двойным тегом, объеденяешь их в бридже и в этот же бридж добавляешь аксесный влан порта микротика. (это даже заработает если сумеете увидеть и победить некоторые подводные камни) успехов!

если знаете как сделать в Linux, может через metarouter?

да

просто LACP часто любой LAG называют, даже если LACP там фактически нет. А кроме полудохлых портов ещё бывают кривые руки, включающие пачкорды не туда. >никогда к примеру не видели, как LACP на дешевых свичах разваливается, и вместо транка получается кольцо? :) тут, кстати, LACP должно было бы помочь живому свичу понять, что партнёр сошёл с ума и просто заблокировать этот линк.

о, точно, а какой длины цепочки у вас реально достигают?

Может кто поделится опытом использования иерархического шейпера с использованием именно этой фичи на полную. т.е. несколько (десятков?) тысяч Q c глубиной вложености больше полутора десятков или около того. несколько лет назад использовал HFSC на фре 6/7, очень понравилось, но там были скорости в несколько десятков мегабит, около сотни очередей... и уже пришлось пересобирать ядро. как сейчас работает pf/altq паралелится? сколько уровней вложености поддерживается? стоит использовать? последние пару месяцев тестировал микротиковский Queue tree, вроде неплохо, но ограничение в 8 уровней вложености, и внезапно чудесатое поведение (которое лечится перезагрузкой) отбивают желание жить с ним всерьёз и надолго. Linux HTB, дела не имел, но вроде как, это почти что предыдущий пункт. Предполагаю, что ограничение на вложеность можно полечить в исходниках и за стабильность люди должны бороться активнее... поделитесь, у кого есть опыт? Linux HFSC, якобы он даже есть, но смущает минимальное количество материала на эту тему, подозреваю, что его как впилили 10 лет назад так и не занимались после этого серьёзно. Насколько я заблуждаюсь? очень хочется ошибаться, т.к. для меня этот вариант потенциально самый вкусный. сразу отвечаю на вопросы "зачем это нужно?" и советы "делайте по другому ..." есть несколько кусков сети полностью построеных на медленных линкам радио/дсл/10М/100М и т.п. клиентов много и на медленных тарифах, хочется при гарантированой минимальной скорости, давать им по возможности максимальную услугу. переделывать каналы (физику) никто не будет. "по другому" уже сделано и работает, но хочется удобно и гибко, чтоб дерево шейпера отображало топологию фрагмента сети, экспериментирование с микротиком показало, что это действительно удобно ( до тех пор пока работает :) ). так что если получится найти производительную и стабильную альтернативу, будет замечательно.

нипишите, что делали и как поняли, что не получилось. тут у всех получается...

У вас что, нат? Если нет - то ниего не должно рушиться, и conntrackd не спасет. А если трафик криво ходит - смотрите rp_filter не, там скорее всего, просто стейтфул фаервол и конекты отлетают по таймауту, т.к. на "2" нет ответного трафика, а на "1" соединение не создано и пакеты вообще дропаются. landy - пишите как получается.

А что не подходит? вроде бы, как раз то что вы просите: " it reads each 'back-end' stream only once, regardless of how many separate clients are streaming from the proxy server. This makes the proxy server ideal, for example, for streaming from a RTSP-enabled video camera (which might not be able to handle more than one connection at a time)."

попробуйте убрать keepalive в настройках тунеля на микротике

3/4 ставьте просто в ДМЗ, не надо "между", и "дружите" их с 1/2 по iBGP, потом на 3/4 делаете редистрибъют коннектед, на 1/2 - не делаете. тогда если 2 видит 3/4, то отдаёт провайдеру маршруты, если не видит, то не отдаёт. если работает правильно, коментарии в коде/конфигах есть и в вики всё задокументировано, то это фантомные ароматы.

каждому vrf - своя OSPF area, сводится всё на фаервол - ABR, каждая area/vrf - отдельная security zone, для трафика между security zone - описаны правила. ИМХО, между врф если объеденять в единый роут домен - обязательно стейтфул фаервол. (в данном случае)

Тоже на форуме часто видел такое утверждение, кто-то может объяснить откуда ноги растут? т.к. /32 маршруты redistribute (т.е. external) то отсылки к сложности SPF будут неуместны, алгоритмическая сложность как у дистанс вектор. Количество записей в FIB - не зависит от протокола... У ТС - проблем нет, но "кажется ... и говорили ...." существует ли сейчас какая-либо объективная причина уходить от OSPF? или кто-то реально сталкивался с проблемами на софте младше 5ти лет?

пакет-то понимает что ему делать, но если второй роутер это stateful фаер (что-то типа SRX), то т.к. трафик получается несимметричный получаются "странности". пишите второе правило для обратного трафика.