А как проверяешь настройку?

Подскажите, а есть ли где-то converter конфигурации 6 в 7 отдельно от ROS?

Дык там несколько параметиов всего поменяно имя. Обычный sed справляется.

Дык там несколько параметиов всего поменяно имя. Обычный sed справляется.

угу ... расскажите это routing filter например

Пытаешься подключаться? Тут же и клиента настраивать надо

как sed-ом убрать пробелы в командах, и заменить их на "/" (да, я знаю что это необязательно - но путешествовать за 800 км не очень хочу)

как sed-ом убрать пробелы в командах, и заменить их на "/" (да, я знаю что это необязательно - но путешествовать за 800 км не очень хочу)

как sed-ом убрать пробелы в командах, и заменить их на "/" (да, я знаю что это необязательно - но путешествовать за 800 км не очень хочу)

sed -i -e 's/\s\+/\//g' conf.txt

Ну тут я думаю вы навряд что-то найдете - там только ручки. Оно ж все переделано. Хотя я просто сделал кусок коефига для filters и потом в конечном файле правил руками.

Все по мануалу, за исключением ip и порта

у других вендоров существует в таком случае алгоритм миграции, там всякие разные страшные слова про zero-day / second day - они описаны и документированы, например. — в случае MT все это придется делать самому, по следующей схеме: -как-то обновиться, одновременно сбросится в дефолт, загрузить скрипт который добавит внешнее подключение и пользовательские учетные данные для авариного доступа (zero day); - дальше зайти на устройство и залить заранее подготовленный конфиг (вот для чего нужен конвертер) - для минимизации простоя (day 2) ; - если шаг выше выполнить невозможно, повторить конфиг руками (всю жизнь мечтал, да)

Ну подробно смотреть не могу. Общие вещи 1. Allowed ip - типа политик IPsec - определяет шифр трафик. 2 ВСЯ маршрутизация на тебе - Вг даже не знает внутренний ИП другого конца. Успехов.

у других вендоров существует в таком случае алгоритм миграции, там всякие разные страшные слова про zero-day / second day - они описаны и документированы, например. — в случае MT все это придется делать самому, по следующей схеме: -как-то обновиться, одновременно сбросится в дефолт, загрузить скрипт который добавит внешнее подключение и пользовательские учетные данные для авариного доступа (zero day); - дальше зайти на устройство и залить заранее подготовленный конфиг (вот для чего нужен конвертер) - для минимизации простоя (day 2) ; - если шаг выше выполнить невозможно, повторить конфиг руками (всю жизнь мечтал, да)

Я бы предложил разбить процедуру перехода на две части тогда: базовая конфигурация (сброс конфигурации с последующей автозагрузкой из скрипта) с настройками для удаленного входа. И донастройка до требуемой конфигурации путем импорта остальной части конфигурации.

это ооочень долго

Вг у тебя поднялся. Концы туннеля друг друга пингуют?

Вг у тебя поднялся. Концы туннеля друг друга пингуют?

Почему? Первый скрипт делает настройки интерфейсов и адресов и базовую маршрутизацию, подтягивает вторую часть через фтп с именем auto.что-то.rsc и ребут. Это как пример конечно, но не думаю что будет сильно долго 😁

Это прекрасно, более того у меня все это работает на 6.x. Где гарантия, что все это заработает на 7.x - хотя бы по синтаксису. Выход один - собирать и тестировать на столе, но это прям очень долго и больно

нет

Это прекрасно, более того у меня все это работает на 6.x. Где гарантия, что все это заработает на 7.x - хотя бы по синтаксису. Выход один - собирать и тестировать на столе, но это прям очень долго и больно

Погоди. Я же видел где-то отдельный апп для конвертации

Вот, а я нет - буду очень признателен

Это п2п. Укажи явный маршрут до другого конца /32

Через час-два стукни, если будет ещё нужно

Всем привет! Подскажите, как можно на микротике сделать передачу маршрутов от одного BGB пира другому с изменением rd?

прямого способа скорее всего нет, имхо. согласно теории это д.б. routing filters c назначением bgp-communities тьфу ... если без фильтрации должно работать import / export c перечислением RD в определении vrf

сейчас микротик принимает префиксы с удаленного ВРФ в глобальную таблицу. Что-то не соображу как принять префиксы в отдельную таблицу

это как ?

juniper экспортирует префиксы из определенного routing-instance, микротик все это получает в таблицу main. Как на микротике сделать таблицу, например REMOTE и все префиксы засунуть туда?

Повесить community со стороны juniper и настроить фильтры на стороне микротика

Лвдно. Как это на микротике делается?

Routing filters

Я имел в виду как полученные префиксы воткнуть в нужный врф на микротике

Я имел в виду как полученные префиксы воткнуть в нужный врф на микротике

Лвдно. Как это на микротике делается?

я показывал выше пример - там как раз то что вам нужно, только global нет

что-то не нашел где это выше пример

что-то не нашел где это выше пример

https://wiki.mikrotik.com/wiki/Manual:Virtual_Routing_and_Forwarding https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328206

тут к ВРФ прикручивается интерфейс и следовательно конектед-маршрут. В моем примере нет интерфейса и поэтому не совсем ясно что втыкать в ВРФ

https://t.me/mikrotikclub/254895

что увас живет на interfaces=vlan1109 ? Какую роль этот влан выполнят в конфиге микротика для понимания

хорошо, тогда зачем они нужны ? дальше отдавать или где ? ну и vrf - может быть определен, но не содержать интерфейсов

локалка, которой нужны маршруты в указанном VRF

во. на моем роутере такого нет. он просто как транзитер должен быть

что значит транзитер ?? в bgp нет такого понятия ... iBGP / eBGP ?

это не термин, а описание задачи) передача префиксов от одного пира другому

На juniper BGP пир прописывается прямо внутри routing-instance и поэтому все префиксы попадают сразу в нужный VRF. В микротике BGP пир объявляется как бы голобально? и все префиксы попадают в main? (если не настраивать фильтры)

что вы уперлись в этот juniper, везде все одинаково - если понимать суть процесса

что вы уперлись в этот juniper, везде все одинаково - если понимать суть процесса

/routing bgp instance vrf add in-filter=to-CCR out-filter=to-peer1 routing-mark=from-peer1 /routing bgp peer add address-families=ip,vpnv4 in-filter=to-CCR name=peer-peer1 out-filter=to-peer1 remote-address=a.b.c.d remote-as=65000 update-source=gre-tunnel-peer1 /ip route vrf add export-route-targets=65000:10442 import-route-targets=65000:10442 interfaces=gre-tunnel-peer1 route-distinguisher=65000:10442 routing-mark=from-peer1 такой же принцип настройки врф на микротике?

зачем туннель добавлен в vrf ?

пир работает на той стороне туннеля.

еще раз - зачем ?

взял по аналогии с примером с вики

могу порекомендовать прочесть теорию, да и сам пойду еще раз почитаю. ИМХО: туннель должен быть построен в global в общем случае; по нему должна быть обеспечена связность между loopback-ами тем или иным способом + настроено управление устройствами; далее между loopback-ами строится LSP для MPLS и поднимаются BGP соединения.