Перейти к содержимому
Калькуляторы

Отказоустойчивая схема связи филиалов и офиса по OpenVPN с применением OSPF

Здравствуйте.

 

Есть офис и 30 филиалов (территориально-удаленных подразделений), количество которых будет увеличиваться со временем до 100 – 150.

 

На данный момент в офисе организован шлюз, к которому по схеме точка – многоточка через интернет с использованием туннелей OpenVPN подключаются все филиалы, используется статическая маршрутизация.

Организованная схема на данный момент не удовлетворяет требованиям надежности, требуется модернизация.

 

В офисе и каждом филиале организованы вторые каналы интернет. Планируется организовать по два туннеля от каждого филиала до офиса (обеспечив резервирование каналов интернет), используя два шлюза в офисе и по два шлюза в каждом филиале (обеспечив резервирование самих шлюзов), внедрить динамическую маршрутизацию. Желательно организовать балансировку нагрузки между туннелями.

 

Проект конфигурации сети отражен на схеме.

 

Ядро сети офиса организовано на двух маршрутизирующих коммутаторах CoreSw1 и CoreSw2 серии HP A5500. К каждому из них подключено некоторое множество серверов, абонентских коммутаторов и иное оборудование. Обеспечивается коммутация, маршрутизация, фильтрация трафика, в некоторых подсетях внедрены STP, VRRP.

К коммутаторам ядра подключены новые программные шлюзы GatewayA и GatewayB на базе pfSense, каждый из которых подключен к интернет (с использованием независимых каналов), подняты OpenVPN сервера.

На CoreSw1, CoreSw2, GatewayA, GatewayB поднят OSPF (area 0.0.0.0).

 

В каждом из филиалов с условными номерами XYZ=1…N планируется организовать по два программных шлюза XYZ-Gateway1 и XYZ-Gateway2 на базе pfSense, каждый из которых будет подключен к интернет. Шлюзы будут в виде виртуальных машин Hyper-V: один – на сервере, второй – на постоянно включенной рабочей станции.

Шлюзы должны резервировать друг друга, предполагается использовать CARP для интерфейсов внутренней сети.

Шлюзы должны обеспечивать выход в интернет из внутренней сети филиала, поддерживать туннель, DNS и DHCP.

Шлюзы должны обеспечивать динамическую маршрутизацию трафика из сети филиала в сегменты офисной сети.

Для синхронизации состояния DNS и DHCP серверов, а также ряда других параметров будет использован функционал XMLRPC Sync, реализованный в pfSense.

 

На данный момент сегмент офиса настроен, макет филиала с условным номером 199 в процессе настройки.

 

Будут ли CARP и OSPF в сегменте филиала корректно работать вместе в данной конфигурации?

В сетях филиала использовать OSPF area 0.0.0.0 или вводить новую область?

Возможно, есть еще какие-то способы обеспечения отказоустойчивости с заданными требованиями?

 

Прошу дать комментарии, замечания или любые другие соображения по схеме организации связи.

 

Заранее спасибо.

post-137717-093613000 1476894690_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В сетях филиала использовать OSPF area 0.0.0.0 или вводить новую область?

 

OSPF для маршрутизации в удаленных офисах не лучшее решение из-за специфики дизайна протокола: LSDB маршрутизаторов в пределах area идентична. При использовании area 0 любое изменение LSA (флапнул интерфейс на офисном свитче) потребует передачу обновленного LSA во все удаленные офисы; это не имеет смысла раз у удаленного офиса всего один или два маршрута в центральный офис, достаточно иметь туда маршрут по умолчанию; если каналы в офисы медленные или с потерями то возможны периодические разрывы OSPF соседства, OSPF к этому чувствителен.

 

Для схемы точка-много точек лучше подходят distance-vector протоколы - EIGRP, BGP, в крайнем случае RIP. Там можно настроить какие именно маршруты анонсировать в удаленные офисы, какие принимать. В идеале анонсировать стоит в офисы только default и/или агрегированные сети, принимать от офиса только анонсы сетей данного офиса. В EIGRP/BGP/RIP это относительно легко настраивается и масштабируется, с OSPF решение не элегантное: нужно помещать удаленные офисы в отдельную area (в идеале каждый офис в свою area) и использовать totally-stub или not-so-totally-stub area.

 

Почитайте документацию Cisco по реализации DMVPN, там хорошо расписаны варианты подключения удаленных офисов и использование протоколов маршрутизации со всеми плюсами и минусами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на хабре была статья про fullmesh vpn на tinc как раз для подобных целей

 

UPD. https://habrahabr.ru/post/185624/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

OSPF для маршрутизации в удаленных офисах не лучшее решение из-за специфики дизайна протокола: LSDB маршрутизаторов в пределах area идентична. При использовании area 0 любое изменение LSA (флапнул интерфейс на офисном свитче) потребует передачу обновленного LSA во все удаленные офисы; это не имеет смысла раз у удаленного офиса всего один или два маршрута в центральный офис, достаточно иметь туда маршрут по умолчанию

Маршрут по умолчанию на всех шлюзах в филиалах направляет трафик в интернет (он не заворачивается в туннели).

Маршрутов из филиалов в центральный офис чуть больше, чем 1-2, но всё же не так много - десятка 2-3.

 

если каналы в офисы медленные или с потерями то возможны периодические разрывы OSPF соседства, OSPF к этому чувствителен.

Интернет в филиалах в основном достаточно приличный: как правило, один канал - медный или оптический кабель ("выделенка"), второй - радиоканал (промышленный Wi-Fi), скорости - по 10 МБит/с, задержки небольшие, стабильность связи достаточно хорошая.

Редко, но все-таки встречается в качестве аварийного варианта, подключение через 4G сеть (YOTA).

Фактический трафик (нагрузка), как правило, составляет 5-8 МБит/с.

Так что по идее проблем с разрывами соседства OSPF из-за нестабильной связи быть не должно.

 

Для схемы точка-много точек лучше подходят distance-vector протоколы - EIGRP, BGP, в крайнем случае RIP.

К сожалению, EIGRP мне не подходит, не cisco у меня.

 

На данный момент настроил стенд следующим образом:

Между CoreSw1, CoreSw2 и еще парой маршрутизаторов центрального офиса, не отображенных на схеме, маршрутизация осталась по протоколу OSPF (area 0). Трогать работающую 24 часа в сутки "боевую" систему не хочется лишний раз.

На CoreSw1 и CoreSw2, помимо OSPF, поднял RIP в сторону GatewayA и GatewayB соответственно, настроил двухстороннюю редистрибьюцию маршрутов между протоколами.

На GatewayA, GatewayB, XYZ-Gateway1, XYZ-Gateway2 также поднял RIP.

Конструкция получилась "слегка не оптимальная" из-за двух протоколов динамической маршрутизации, конструкция работает, однако есть пара нюансов.

 

Там можно настроить какие именно маршруты анонсировать в удаленные офисы, какие принимать.

К сожалению, pfSense не позволяет это сделать (в его веб-интерфейсе настройки RIP-а ограничиваются указанием активных интерфейсов, версии протокола и пароля для RIP v2).

Таким образом, в таблицы динамических маршрутов попадают в том числе и default маршруты (в сторону интернет-провайдеров) со всех программных шлюзов, которые отфильтровать нет возможности.

 

К сожалению, с учетом редистрибьюции маршрутов между протоколами, получилось очень большое время "подъема" связи между узлами в сети офиса и узлами в сети филиала при разрыве связи по туннелю №1 - около 3 минут.

 

Кстати, RIP каждые 30 секунд транслирует полную таблицу маршрутов. Не вызовет ли (как в случае с OSPF) нестабильная связь проблемы с маршрутизацией?

 

Планирую в ближайшие дни, как будет немного времени, организовать подобный стенд с BGP. Я с ним на практике практически не работал, буду изучать.

 

Почитайте документацию Cisco по реализации DMVPN, там хорошо расписаны варианты подключения удаленных офисов и использование протоколов маршрутизации со всеми плюсами и минусами.

Спасибо за подсказку, есть кое-что интересное, однако реализовать на не-cisco эту конструкцию не получится.

 

на хабре была статья про fullmesh vpn на tinc как раз для подобных целей

UPD. https://habrahabr.ru/post/185624/

Посмотрел, проект достаточно интересный, спасибо за ссылку. Обязательно рассмотрю как вариант после изучения документации.

Full-mesh сеть как таковая мне не нужна, т.к. трафик между филиалами отсутствует. Всё взаимодействие организуется только через центральный офис.

Пока для меня остаются открытыми вопросы относительно сетевой безопасности tinc (шифрование трафика, работа с сертификатами и их отзывом/заменой), несколько усложняются вопросы фильтрации трафика, т.к. появляется транзитный.

 

И всё же решение с OpenVPN, поднятом на pfSense, остается приоритетным, в том числе поскольку другие наши технические специалисты (те, что филиалы эксплуатируют) к нему привыкли и готовы эксплуатировать только Web интерфейс.

 

Если отвлечься от вопросов маршрутизации между офисом и филиалами, а рассматривать отдельно-взятый филиал в отдельности.

Насколько оправдано будет использование CARP на двух софтовых маршрутизаторах? Есть ли другие способы обеспечить отказоустойчивость маршрутизаторов филиала?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

будет увеличиваться со временем до 100 – 150

 

Переезжайте на циску, пока не поздно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Маршрутов из филиалов в центральный офис чуть больше, чем 1-2, но всё же не так много - десятка 2-3.

 

не важно, для подключения через интернет, link state протокол моветон, он жрет полосу, и плохо фильтруется, и суммировать маршруты сложно. в общем геморой один.

Много офисов которые подключены к центру - тем более, фильтровать, в центре в нул0 завернуть все пулы серых сетей и анонсировать эти агрегаты в офисы - с bgp так получится, с оспф - нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В сетях филиала использовать OSPF area 0.0.0.0 или вводить новую область?

 

OSPF для маршрутизации в удаленных офисах не лучшее решение из-за специфики дизайна протокола: LSDB маршрутизаторов в пределах area идентична. При использовании area 0 любое изменение LSA (флапнул интерфейс на офисном свитче) потребует передачу обновленного LSA во все удаленные офисы; это не имеет смысла раз у удаленного офиса всего один или два маршрута в центральный офис, достаточно иметь туда маршрут по умолчанию; если каналы в офисы медленные или с потерями то возможны периодические разрывы OSPF соседства, OSPF к этому чувствителен.

 

Для схемы точка-много точек лучше подходят distance-vector протоколы - EIGRP, BGP, в крайнем случае RIP. Там можно настроить какие именно маршруты анонсировать в удаленные офисы, какие принимать. В идеале анонсировать стоит в офисы только default и/или агрегированные сети, принимать от офиса только анонсы сетей данного офиса. В EIGRP/BGP/RIP это относительно легко настраивается и масштабируется, с OSPF решение не элегантное: нужно помещать удаленные офисы в отдельную area (в идеале каждый офис в свою area) и использовать totally-stub или not-so-totally-stub area.

 

Почитайте документацию Cisco по реализации DMVPN, там хорошо расписаны варианты подключения удаленных офисов и использование протоколов маршрутизации со всеми плюсами и минусами.

Вот это все в теории. На практике для 30 100 150 филиалов это ~ 500 префиксов в LSDB и любой флап для OSPF что слону дробина. Ну флапнуло там и там, ну пережевал спокойненько, вальсируем дальше.

У меня подобного рода решения жили с 3000 префиксов и 500 роутеров в одной области и нормально жили.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Переезжайте на циску, пока не поздно.

У j тоже есть аналог dmvpn

"C" или "J" - не панацея, да и денег стоят...

 

не важно, для подключения через интернет, link state протокол моветон, он жрет полосу, и плохо фильтруется, и суммировать маршруты сложно. в общем геморой один.

Много офисов которые подключены к центру - тем более, фильтровать, в центре в нул0 завернуть все пулы серых сетей и анонсировать эти агрегаты в офисы - с bgp так получится, с оспф - нет

Серые сети в ядре в нул0 уже завернуты, куда ж без этого :)

Красивого суммирования, кроме как с использованием BGP, видимо сделать не получится.

Спасибо, попробую BGP на макете поднять на следующей неделе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"C" или "J" - не панацея, да и денег стоят...

 

Железка 800 серии стоит как приличный компьютер. Если новая.

Тут, на НАГе продают кучу б/у цисок, от 1841 до 881. Для небольших филиалов выше крыши.

 

В центр потребуется конечно пожирнее.

Зато работать будет как часики, годами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Схема рабочая, но я бы предложил отказаться от OpenVPN в пользу GRE over IPSec. CARP и OSPF отлично уживаются вместе, дополняя друг друга. Особого смысла вводить дополнительные арии для филиалов в вашем случае не вижу. Если хотите балансировку нагрузки между каналами, то проще всего, наверное, заменить OSPF на BGP и реализовать схему, при которой, пока живы оба канала, трафик в офис идёт по первому, а из офиса - по второму. Это хороший вариант, при условии, что каналы везде у вас приблизительно одинаковой ширины т.к. в этом случае вы получите фактически удвоение ширины канала + резервирование (при падении одного из каналов весь трафик пойдёт по оставшемуся).

Ещё могу порекомендовать отказаться от pfSense в пользу MikroTik RouterOS. Сам долго и активно пользовался pfSense, но в нашей сети его недостатки оказались существенными и пришлось искать замену, которой стала MikroTik RouterOS. Довольны полностью.

У pfSense есть несколько серьёзных недостатков:

- запустить на нём OSPF + BGP одновременно не получится, либо одно, либо другое;

- периодически (редко) намертво подвисает OSPF;

- до сих пор не устранён баг, приводящий к переполнению места на системном разделе после установки некоторых пакетов - критично, при сохранении любых изменений в Web-интерфейсе при переполненном корневом разделе слетает конфигурация начисто;

- настройка IPSec-а на pfSense не самое приятное занятие;

- реализация интерфейса для настройки DHCP сервера оставляет желать лучшего - конкретно добавление резервирования IP адреса...

Но у pfSense есть и существенные плюсы перед MikroTik RouterOS:

- замечательный файрвол, который предельно прост, логичен и настроен из коробки;

- XMLRPC Sync;

- бесплатность;

- возможность расширения функционала сверх стандартных функций для шлюза - к примеру из него можно сделать ещё и антиспам SMTP прокси;

- рабочий Proxy ARP для PPTP/L2TP (сомнительный плюс).

Ещё у Вас и в офисе и в филиалах есть дополнительная точка отказа - коммутаторы. По хорошему их тоже стоит резервировать, как минимум в офисе.

Изменено пользователем mutin.sa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Допустим у вас есть 2 канала в интернет, 2 роутера, которые полностью друг друга резервируют, и коммутатор, к которому подключены рабочие станции. Допустим первый роутер сломался, все работает через коммутатор через оставшийся, допустим сломался коммутатор, а роутеры работают. Все, приехали.

 

Поэтому нужно резервировать не оборудование, а каналы.

 

В данном случае подойдут 2 микротика для подключения к каждому каналу интернета в офисе, они же поднимают туннель в центр, и третий микротик подключен к ним и принимает маршруты через OSPF, и уже сам анонсирует нужные сети, раздает адреса по DHCP и прочее. В такой схеме никакие скрипты и т.п. не нужны, максимум пара правил в манглах, что бы трафик заворачивался в туннель, а не шел в интернет через каналы, имеющиеся в туннелях. Однако, если по туннелям идет только обращение на внутренние ресурсы, а сам интернет у каждого офиса свой, то и никакие правила манглов не нужны, то есть вообще ничего не надо настраивать, кроме туннелей и OSPF.

 

Если у вас в центре так же 2 канала интернета и поставите 2 железки от микротика, к которым уже по той же схеме с третьим микротиком подключите все сервера, то оба канала каждого из офисов будут загружаться примерно равномерно. Однако при обрыве связи по какому-то каналу, может быть кратковременная пауза, пока OSPF не оборвет соседство. Т.к. бывает так, что центральное устройство туннель потушило, а удаленное пока еще держит, центральное передает данные до офиса по оставшемуся туннелю, а в офисе продолжает отправлять пакеты в не рабочий туннель. Тут помогает уменьшение времени прекращения соседства с дефолтных 40 секунд до более низких значений, либо, использование BFD.

 

- рабочий Proxy ARP для PPTP/L2TP (сомнительный плюс).

 

Он и на микротике нормально работает.

 

Ещё у Вас и в офисе и в филиалах есть дополнительная точка отказа - коммутаторы. По хорошему их тоже стоит резервировать, как минимум в офисе.

 

В качестве коммутатора можно использовать Mikrotik CRS, у него достаточно много портов.

 

И тут вопрос в резервировании коммутаторов, а как к ним компьютеры-то подключать? Ставить по 2 сетевые платы и соединять их в мост, на который и вешать IP адрес?

 

OSPF для маршрутизации в удаленных офисах не лучшее решение из-за специфики дизайна протокола: LSDB маршрутизаторов в пределах area идентична. При использовании area 0 любое изменение LSA (флапнул интерфейс на офисном свитче) потребует передачу обновленного LSA во все удаленные офисы; это не имеет смысла раз у удаленного офиса всего один или два маршрута в центральный офис, достаточно иметь туда маршрут по умолчанию; если каналы в офисы медленные или с потерями то возможны периодические разрывы OSPF соседства, OSPF к этому чувствителен.

 

Вот оказывается как это работает? Странно, но даже 1000 и 2000 устройств в одной area работает без проблем. Ну изменился интерфейс и что с того? Полетят обновления маршрутов на все устройства, на прохождение трафика до остальных маршрутов, которые не меняются, это не повлияет. Ну будет OSPF чуть занимать ресурсы, так это мелочи на фоне других задач.

 

Тут самое главное не забыть указать Router-Id на основных устройствах вида 0.0.0.1 и 0.0.0.2, а еще лучше туда добавить еще парочку железок с 0.0.0.3 и 0.0.0.4, что бы какой-то самый дальний роутер через самый медленный канал не возомнил себя самым главным в сети, когда эти параметры не указаны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Тут самое главное не забыть указать Router-Id на основных устройствах вида 0.0.0.1 и 0.0.0.2, а еще лучше туда добавить еще парочку железок с 0.0.0.3 и 0.0.0.4, что бы какой-то самый дальний роутер через самый медленный канал не возомнил себя самым главным в сети, когда эти параметры не указаны.

т.е. микротиковцы так и не осилили реализовать router priority в ospf area, и вместо этого используют для определения priority router-id? мда, оригинальное понимание RFC...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Тут самое главное не забыть указать Router-Id на основных устройствах вида 0.0.0.1 и 0.0.0.2, а еще лучше туда добавить еще парочку железок с 0.0.0.3 и 0.0.0.4, что бы какой-то самый дальний роутер через самый медленный канал не возомнил себя самым главным в сети, когда эти параметры не указаны.

т.е. микротиковцы так и не осилили реализовать router priority в ospf area, и вместо этого используют для определения priority router-id? мда, оригинальное понимание RFC...

а чё помоему норм - MFC изобрели. RFC - устаревшая технология

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

l2tp 2 виртуалочки на линухах, в филиалах микротик внутри Ospf вот и отказоусточивость

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

OSPF внутри OVPN туннелей странно живет (если вообще заведется :-)), я в свое время городил BGP для такой задачи, с ним проблем не было

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

OSPF внутри OVPN туннелей странно живет (если вообще заведется :-)), я в свое время городил BGP для такой задачи, с ним проблем не было

 

OVPN туннели уже устарели, вот OSPF и не работает. Используйте L2TP, PPtP или SSTP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

OVPN туннели уже устарели, вот OSPF и не работает. Используйте L2TP, PPtP или SSTP.

Еще +1 мем! Можно уже "Список устаревших технологий по версии Saab95" составлять.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К сожалению, немного выбился из графика в связи с огромным объемом других работ... Наконец-то нашлось время продолжить.

 

Схема рабочая, но я бы предложил отказаться от OpenVPN в пользу GRE over IPSec.

Не вижу смысла. Тем более, не везде получится реализовать - есть пара провайдеров, которые GRE режут.

 

Если хотите балансировку нагрузки между каналами, то проще всего, наверное, заменить OSPF на BGP и реализовать схему, при которой, пока живы оба канала, трафик в офис идёт по первому, а из офиса - по второму. Это хороший вариант, при условии, что каналы везде у вас приблизительно одинаковой ширины т.к. в этом случае вы получите фактически удвоение ширины канала + резервирование (при падении одного из каналов весь трафик пойдёт по оставшемуся).

Как таковой балансировки не получится, т.к. практически все каналы симметричные - 10 Мбит/с туда и 10 обратно. Итого те же 10 и получатся.

 

У pfSense есть несколько серьёзных недостатков:

- запустить на нём OSPF + BGP одновременно не получится, либо одно, либо другое;

- периодически (редко) намертво подвисает OSPF;

- до сих пор не устранён баг, приводящий к переполнению места на системном разделе после установки некоторых пакетов - критично, при сохранении любых изменений в Web-интерфейсе при переполненном корневом разделе слетает конфигурация начисто;

- настройка IPSec-а на pfSense не самое приятное занятие;

- реализация интерфейса для настройки DHCP сервера оставляет желать лучшего - конкретно добавление резервирования IP адреса...

Одновременно использовать OSPF и BGP не планирую, ядро уже перекинул на BGP, отказавшись от OSPF.

Пакетов стоит всего 2-3 штуки, и пока что ни разу с переполнением системного диска не сталкивался. Спасибо за предупреждение о таком баге :)

IPSec не используется. Ну а все остальное вполне устраивает.

 

Но у pfSense есть и существенные плюсы перед MikroTik RouterOS:

- замечательный файрвол, который предельно прост, логичен и настроен из коробки;

- XMLRPC Sync;

- бесплатность;

- возможность расширения функционала сверх стандартных функций для шлюза - к примеру из него можно сделать ещё и антиспам SMTP прокси;

- рабочий Proxy ARP для PPTP/L2TP (сомнительный плюс).

Эти плюсы отчасти и сыграли свою роль в выборе ПО. И к pfSense все сотрудники привыкли более-менее, переучиться будет сложновато.

 

Ещё у Вас и в офисе и в филиалах есть дополнительная точка отказа - коммутаторы. По хорошему их тоже стоит резервировать, как минимум в офисе.

Как показала практика, за несколько лет в филиалах из строя не вышел ни один коммутатор (только пара случаев выгорания портов).

Так что горячий резерв, который еще не понятно, как можно сделать, точно не актуален. А холодный резерв, готовый и настроенный, само собой в центральном офисе лежит.

 

И тут вопрос в резервировании коммутаторов, а как к ним компьютеры-то подключать? Ставить по 2 сетевые платы и соединять их в мост, на который и вешать IP адрес?

Сомневаюсь, что будет работать :)

 

OSPF внутри OVPN туннелей странно живет (если вообще заведется :-)), я в свое время городил BGP для такой задачи, с ним проблем не было

OVPN туннели уже устарели, вот OSPF и не работает. Используйте L2TP, PPtP или SSTP.

К сожалению, могу перечислить касаемо OpenVPN больше плюсов, чем минусов, в сравнении с иными протоколами.

 

 

Возвращаясь к сути проблемы в комплексе с моими недостаточными знаниями относительно BGP, с которым на практике почти не сталкивался.

Итак, все по-прежнему соединено в соответствии со схемой, размещенной в 1-м посте этой темы.

 

На коммутаторах ядра CoreSw1 и CoreSw2 поднял BGP в минимальной конфигурации для обеспечения маршрутизации внутри центрального офиса, после чего отключил OSPF.

Все работает, маршруты между свитчами летают, трафик маршрутизируется.

Фрагмент конфига CoreSw1 (CoreSw2 - аналогично):

bgp 65000
router-id 172.20.255.251
preference 131 132 133
import-route direct route-policy DirectToBgp
import-route static route-policy StaticToBgp
undo synchronization
peer 172.20.251.200 as-number 65000
peer 172.20.251.200 description GatewayA
peer 172.20.251.200 connect-interface Vlan-interface2251
...
peer 172.20.255.252 as-number 65000
peer 172.20.255.252 description CoreSw2
peer 172.20.255.252 connect-interface Vlan-interface2255
...

 

На 2 шлюзах pfSense в центральном офисе - GatewayA и GatewayB - поставил пакет OpenBGPd, сделал минимальные настройки.

Фрагмент конфига GatewayA (GatewayB - аналогично):

AS 65000
fib-update yes
listen on 0.0.0.0
router-id 172.20.251.200
network 172.20.251.0/24
network 172.22.251.0/24
neighbor 172.20.251.251 {
descr "CoreSw1"
local-address 172.20.251.200 
remote-as 65000 
...
}
deny from any
deny to any
allow from 172.20.251.251
allow to 172.20.251.251

 

Для того, чтобы в iBGP маршруты, полученные например CoreSw1 от CoreSw2, передавались на GatewayA, включил Route Reflection.

 

BGP коннект между CoreSw1 и GatewayA - Established, роуты в таблице OpenBGPD Routing появились:

flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination          gateway          lpref   med aspath origin
I*>   10.10.0.0/16         172.20.251.251     100     0 ?
I*>   172.20.1.0/24        172.20.251.251     100     0 ?
I*>   172.20.5.0/24        172.20.251.251     100     0 ?
...
I     172.20.33.0/24       172.20.255.252     100     0 ?
I     172.20.37.0/24       172.20.255.252     100     0 ?
...

Однако флаги Selected и Valid отображаются только у маршрутов, которые GatewayA получил непосредственно от соседа CoreSw1 (подсети 10.10.0.0, 172.20.1.0, 172.20.5.0). Эти маршруты попали в системную таблицу маршрутизации.

Роуты, прилетевшие с CoreSw2 через CoreSw1 (подсети 172.20.33.0, 172.20.37.0) этих атрибутов не имеют и в системную таблицу маршрутизации не попали.

 

Что я забыл сделать?

Может быть есть какие-то рекомендации по настройке BGP в такой схеме?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что я забыл сделать?

роут до 172.20.255.252 есть в таблице маршрутизации?

 

OVPN туннели уже устарели

а по-моему микротик уже устарел, потому что не умеет работать нормально ни с одной сетевой технологией - ни с BGP (роут рефлекторы и не self-originated роуты с роутом до gw в bgp таблице в принципе не умеет никак), ни с OVPN, ни с OSPF (более одной area не осиливает без глюков), ни с прочим... да, PPTP тоже нормально не может.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что я забыл сделать?

роут до 172.20.255.252 есть в таблице маршрутизации?

Да, само собой, роут в таблице OpenBGPD Routing есть, пинги ходят.

flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination          gateway          lpref   med aspath origin
...
I*>   172.20.255.0/24      172.20.251.251     100     0 ?
...

В системной таблице маршрутизации маршрут также имеется:

> netstat -nr | grep 172.20.255.
172.20.255.0/24    172.20.251.251     UG1        vmx0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.