Strabbo, вот спасибо за развёрнутый ответ, есть что почитать и в чём дальше разбираться! OSPF уже сейчас на лупбеках, как минимальными силами с BGP извернуться (не становясь экспертом по всем его нюансам :) - буду экспериментировать!
Strabbo, так, либо я очень туплю (бывает), либо всё ещё не до конца описал задачу.
Попробую ещё раз по порядку на упрощённом примере. Как оно сейчас:
- есть зарубежный сервер 10.0.0.1 (допустим, это адрес его loopback-интерфейса, который анонсируется по OSPF);
- есть российский роутер 10.1.1.1, который очень хочет ходить через 10.0.0.1 на неугодные РКН сайты;
- есть два VPN-тоннеля между 10.0.0.1 и 10.1.1.1, в первом из которых у них адреса 10.0.1.1 и 10.0.1.2, а во втором - 10.0.2.1 и 10.0.2.2 соответственно;
- на VPN-интерфейсах настроен OSPF, так что в зав-ти от того, какой из них поднят, маршрут от 10.1.1.1 до 10.0.0.1 строится или через 10.0.1.1, или через 10.0.2.1;
- есть BGP-сервер (его адрес вообще не важен, ну пусть будет 10.2.2.2), который собирает и парсит реестр РКН и отдаёт его роутеру 10.1.1.1 (и не только ему) по BGP с номером AS 64999 и community 100; каждая строчка с подсетью в конфиге bird выглядит как "route X.X.X.X/X via 10.0.0.1" (но на самом деле пофиг, какое там "via", т.к. мы его меняем на следующем шаге, и для каждого роутера будет свой шлюз);
- 10.1.1.1, получая по BGP маршруты от 10.2.2.2, прогняет их через фильтр "if (bgp-communities includes 64999:100) {set gw 10.0.1.1; accept} reject".
Что конкретно надо поменять в этой системе, чтобы когда тоннель 10.0.1.2->10.0.1.1 отвалится и маршрут до 10.0.0.1 на 10.1.1.1 будет построен OSPF через 10.0.2.1, полученные по BGP маршруты продолжали работать?
Спасибо за уделённое время заранее :)
P.S. Кажется, я понял, что Вы имели в виду (рисовать схемки полезно, наступает просветление :) Если по BGP маршруты будет отдавать не сторонний сервер (10.2.2.2), а сам тот сервер, через который и надо строить маршрут (10.0.0.1) - то он может указать next-hop self, и вместо этого self подставится тот адрес, который сейчас выбран OSPF. Так?
Это надо протестировать и если это работает - это решает одну половину проблемы (хоть и не без сложностей в реализации), спасибо! Но это не решает другую половину проблемы. На самом деле у нас не два роутера в сети, а изрядно больше. И может так получиться, что прямых тоннелей между 10.0.0.1 и 10.1.1.1 не останется живых, но останутся тоннели от каждого из них до какого-нибудь 10.3.3.3, и OSPF построит маршрут именно через этот 10.3.3.3... примерно вот так:
VPN1 отвалился, маршрут до 10.0.0.1 строится через два VPN и промежуточный узел 10.3.3.3. Как рассказать нашему 10.1.1.1, что полученные по BGP маршруты должны теперь идти через шлюз 10.0.2.1?
Strabbo, как оно работает?
У меня есть маршрут к 10.0.0.1 через 10.0.1.1 и маршрут к 10.0.0.1 через 10.0.2.1. В фильтре BGP я не могу указать или один, или другой. Допустим, я указал 10.0.1.1. А потом этот тоннель отваливается, OSPF меняет маршрут к 10.0.0.1 на 10.0.2.1. А фильтр BGP пытается установить маршрут через уже недоступный шлюз 10.0.1.1.
Руслан Федосеев, gateway - это шлюз, конечно, но почему только по умолчанию-то? :)
Я не хочу перенести маршруты из OSPF в BGP. Я хочу использовать для полученных по BGP маршрутов выбранный OSPF шлюз.
Конкретный упрощённый пример я в комментарии к первому ответу привёл.
Если совсем грубо, то хочется следующего:
- роутер получил по BGP пачку подсетей с номером community 100
- роутер знает, что к этим подсетям надо ходить через хост 10.0.0.1
- но к хосту 10.0.0.1 есть много потенциальных маршрутов, конкретный из которых выбирается OSPF
- надо указать шлюзом для этих подсетей тот, через который мы сейчас ходим к 10.0.0.1
Ну или если это невозможно - то достичь того же результата путём пересмотра схемы вообще.
P.S. Наверное, ещё забыл упомянуть важный момент. Почему я не анонсирую маршруты по OSPF с того самого хоста, через который они должны маршрутизироваться в итоге? Ну т.е. почему бы голландскому серверу не анонсировать все заблокированные РКН префиксы? Вроде бы, это решило бы проблему.
Но:
а) Во-первых, эти префиксы (которых МНОГО) прилетят и к тем роутерам, которым они вообще не нужны (какое дело турецкому роутеру или другому зарубежному серверу до блокировок РКН)?
б) Во-вторых, даже если оверхед от п. "а" окажется приемлемым, не всем роутерам нужны все префиксы. Сейчас каждый роутер в фильтре принимает те BGP comminities, которые ему актуальны (российский - списки РКН и турецкий GeoIP, турецкий - российский GeoIP и т.п.), а остальные игнорирует. Ну и шлюз тот или иной подставляет, в зависимости от community. В OSPF, вроде бы, есть аналог communities - теги, но работать на Микротике я их не смог заставить. На одном роутере указываешь тег, на другом он его не видит... и судя по гуглению, это by design, а не у меня руки кривые...
Спасибо за ответ, но ничего не понял :)
Мне default route как раз никуда дистрибьютить не надо, он у каждого роутера свой. Надо указать конкретный gateway (тот, который из всех возможных вариантов, ведущих к целевому хосту, сейчас доступен и выбран OSPF), чтобы к отдельным подсетям (полученным по BGP) ходить через него.
Спасибо за ответ. Сорри за "воду", я из того вымирающего поколения, которое ещё умеет читать и писать тексты длиннее 140 символов :)
Предлагаемый вариант не до конца понятен. Сейчас и без отдельного OSPF-инстанса всё работает примерно так же - получаем маршруты по BGP, применяем фильтр для подмены шлюза. Вопрос только в том, что этот шлюз в разные моменты разный, а написать прямо в фильтре "подставь тот шлюз, через который мы в данный момент времени ходим вот до этого хоста" не получится.
Можно вот прямо на пальцах на упрощённом примере?
Скажем, у нас роутер, который должен ходить к заблокированным сайтам через зарубежный сервер 10.0.0.1. К этому серверу у нас два VPN-тоннеля, в первом из них у него адрес 10.0.1.1, во втором - 10.0.2.1. По BGP мы получили 200 тысяч префиксов, которым надо шлюз указать или 10.0.1.1, или 10.0.2.1, смотря через какой из них у нас OSPF сейчас маршрут до 10.0.0.1 строит.
Что конкретно сделать на роутере, чтобы этого достичь? Заранее благодарю.
Спасибо за ответ. Модули сопряжения видел у того же Wirenboard, но они рассчитаны на типичный российский домофон.
Ссылка удалена модератором.
Там подразумевается, что в квартиру приходит 2 провода от вызывной панели к трубке, в разрыв которых мы и подключаем модуль. У меня же витая пара на 8 проводников (7 из них используется), и подключение последовательное, от соседа к соседу, а не напрямую к вызывной панели. Такой модуль сопряжения очевидно не подойдёт, а других я не нашёл. Если есть ссылки / названия на модули, которые могли бы подойти с моей схемой подключения - буду благодарен!
Прошу прощения за задержку с ответом, был не рядом с обсуждаемым девайсом. Вот фото со всех возможных сторон, заранее благодарю, если они натолкнут на какие-то идеи:
Нет, как раз видео там нет ни в квартире, ни внизу. В рамках этой же системы есть модели с видео, но у меня установлена простая голосовая. По ссылке в вопросе на неё можно посмотреть. Имеем две кнопки "говорить" и "открыть", одну лампочку (которая по неведомой причине загорается не только когда вызов идёт в мою квартиру, но и когда с гостем внизу общается или открывает ему дверь любой сосед) и динамик, играющий незамысловатую мелодию, когда вызывают конкретно меня. Ну и контакты для подключения дверного звонка на лестничной площадке, чтобы при его нажатии музыка играла на той же панели - но с ним-то вопросов нет.
Решение проблемы паяльником очевидно - подключаемся к тому самому динамику (ну или если смогу поймать какой-то более ранний участок цепи к нему, куда приходит один сигнал, а не музыка) и к кнопке открытия. От динамика реагируем на первые признаки жизни (и дальше игнорируем последующие ноты), контакты кнопки замыкаем.
Но хотелось без паяльника, просто и элегантно на ту клеммную колодку, куда приходит входящая и уходит уходящая витая пара, кинуть ещё свою и что-то там на другом конце с ней сделать. Но вот что конкретно, вопрос... Разбирать я эту панель уже разбирал, собрал обратно, если фото внутренностей поможет - разберу ещё раз.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
