Mikrotik.moscow [тема: BGP / Синхронизация конфигурации]

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 17:41:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Хе-хе, возвращаю тему к нормальному руслу... Может так и кажется, но если у вас есть пара роутеров с резервированием и между ними напрямую проложен кабель, то на самом деле между роутерами есть два пути. Есть прямой кабель И есть интерфейсы LAN, с которыми работают клиенты, там и происходит резервирование (сеть, защищённая VRRP). В этом конкретном случае это особо не меняет ситуацию, но представьте, что у вас два пограничных роутера находятся в разных местах и соединены разными каналами связи. Тут очевидно, что один канал может отвалиться, и роутеры перейдут на другой канал. Это как раз тот случай, когда в конфигурации BGP с двумя роутерами стоит использовать loopback-интерфейсы. В общем, я не могу придумать причин в рамках «лучших практик» специально выбирать физический интерфейс для связи между двумя iBGP-роутерами, чтобы они не общались, если этот линк падает, а другие пути при этом доступны. Короче говоря, проще сразу приучить себя применять лучшие практики во всех случаях, чтобы не пришлось помнить «делай так в этой ситуации, а в других — иначе».
03.08.2017 17:41:00, ZeroByte.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 17:30:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Да, я уже пробовал это. Если бы проблема была в фаерволе, то соединение просто прервётся по таймауту, а у меня BGP-сессия устанавливается, но сразу же разрывается с обеих сторон. Проблема не в таймерах — они настроены правильно и уже давно работают, не вижу, почему они начали бы сбоить только потому, что я изменил remote-address у пиров. Я также пробовал опцию update source, но она тоже не сработала. Точно не помню, что именно она делает. Надо ли выбирать интерфейс или вводить IP loopback в это поле? Позже посмотрю, сейчас дневное время и не хочу усугублять флаппинг в сети.

Кстати, немного в стороне, так как я немного уводил тему. Использование loopback IP для iBGP-пиров нужно только при трёх и более маршрутизаторах в одном AS, правильно? То есть, если всего два маршрутизатора (как настаивает packetkicker), альтернативного пути от R1 к R2 нет. Но понимаю, что в любом случае это считается лучшей практикой.
03.08.2017 17:30:00, Cha0s.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 17:19:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Я бы сказал, что нужно убедиться, что на обоих роутерах для удалённого и локального IP используется один и тот же адрес. В WinBox настройки соседей выглядят примерно так:

Вкладка General:
Remote Address: loopback IP удалённого роутера
Remote AS: такой же, как и локальный ASN (именно поэтому это iBGP-сессия)
Nexthop Choice: по умолчанию

Я не уверен, обязательно ли BGP требует совпадения таймеров с настройками пира, как это делает OSPF, но совпадение настроек может помочь. Route Reflector тут роли не играет, но если у вас в сети используется RR, то у всех клиентов RR должна быть включена эта опция. Для iBGP-пиров ставить галочку “multihop” не нужно.

Вкладка Advanced:
Обязательно укажите Update Source как ваш loopback-интерфейс. Можно задать разные источники обновлений для каждого пира, так что не забывайте настраивать это каждый раз.

Полагаю, это недостающий элемент вашей настройки, хотя могут быть и другие причины, например, правила firewall и так далее.
03.08.2017 17:19:00, ZeroByte.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 17:02:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Вау! Спасибо за подробное объяснение! Я предполагал, что дело в сценарии отказа, но не анализировал это настолько глубоко, чтобы понять, что именно происходит. Теперь всё стало на свои места. Я быстро проверил это в своей сети (топология похожа на вашу лабораторную), но у меня не получилось запустить — как только устанавливается iBGP-сессия, она сразу же разрывается. Но зато я увидел (и подтвердил), что происходит, когда iBGP-пир выходит из строя. Придётся разобраться. У меня эта настройка уже больше десяти лет, и я в шоке, что раньше не замечал эту проблему! Частично помогло то, что BGP-сеть (не интернет) состоит только из транзитных AS без какого-либо фильтрации и с кучей альтернативных путей, поэтому проблема была не так заметна (всё продолжало работать, хоть и по более длинным маршрутам в зависимости от представления сети каждого роутера). Отличный день сегодня! Узнал что-то новое.
03.08.2017 17:02:00, Cha0s.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 15:42:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Просишь — получаешь. Так получилось, что у меня в GNS3 как раз есть лабораторка, которая идеально это иллюстрирует:

Детали конфигурации:
R1, R2 и R3 все настроены на iBGP-пиринги друг с другом в полном меше (без route reflectors).
В качестве router ID у них используются IP-адреса loopback.
В качестве адреса пиринга — loopback удалённого роутера.
Источник трафика — loopback-интерфейс.
Внутри AS100 используется OSPF как IGP.

Почему для iBGP нужно пириться по loopback IP:
Предположим, что R2 и R3 настроены пириться по IP, назначенным на линк (10.2.3.2 и 10.2.3.3). И вот этот линк падает. R2 перестанет видеть 10.2.3.3, R3 — 10.2.3.2. Сессия iBGP между ними разорвётся.

Так как это полный меш iBGP-пирингов внутри AS, R2 узнаёт про существование AS600 только от R3. Когда сессия R2<>R3 падает, R2 теряет путь BGP к AS600, а значит, AS500 больше не сможет достучаться до AS600. Аналогично R3 теряет маршруты к AS500.

Это нелепо, ведь R2 всё ещё может добраться до R3 через R1, а OSPF внутри ASN быстро найдёт этот альтернативный путь. То есть путь от AS500 до AS600 есть — но он не работает из-за неправильной настройки iBGP в AS100.

Почему OSPF не спасёт ситуацию?
Кто-то может спросить: «Если OSPF видит обход через R1, почему R2 не может достучаться до 10.2.3.3 через R1?»

Потенциально может, но только не используя исходный IP 10.2.3.2 — сейчас разберёмся. Есть три варианта отказа линка:

1. Линк падает так, что оба роутера видят интерфейс как down — тогда IP-адреса недоступны, так как сеть неактивна.
2. Линк физически поднят, но передача пакетов не работает — тогда оба роутера считают сеть 10.2.3.0/24 локально подключённой и всегда пытаются слать пакеты напрямую, а не через OSPF-обход.
3. R2 видит интерфейс как down, а R3 — как up. В таком случае R2 узнаёт о сети 10.2.3.0/24 через OSPF по R1 и может пинговать 10.2.3.3, но не с IP 10.2.3.2 — вместо этого будет использовать IP другого интерфейса. Но даже если R2 будет использовать 10.2.3.2, R3 не сможет нормально ответить, отправляя пакеты напрямую по link’у, который уже не работает.
То же самое если R3 видит интерфейс down, а R2 — up.

В любом случае нет полноценной двунаправленной связи между 10.2.3.2 и 10.2.3.3. Если iBGP настраивается на эти IP-адреса интерфейсов, iBGP сессия упадёт при отказе линка.

Loopback IP всегда доступен
Если хотя бы один сосед OSPF активен, loopback адрес объявляется в OSPF и всегда доступен, независимо от изменений топологии. Если R2 и R3 используют для iBGP свои loopback IP, сессия между ними не упадёт даже при изменениях физической топологии.

Помните: iBGP не работает как IGP, например OSPF.
Next hop в iBGP — это всегда IP, полученный от исходного eBGP пира. Например, когда R3 узнаёт о 6.0.0.0/8 от AS600, next hop будет 10.3.6.6, который он потом передаёт R1 и R2. В базе R1 next hop стоит 10.3.6.6, который должен быть доступен через другие маршруты (обычно OSPF).

Вот почему iBGP использует «рекурсивный next hop» — роутер может принимать решение, оценивая расстояние до next hop. В маленькой топологии это не очевидно, но в большой сети с множеством путей к удалённым AS это важно. Например, роутер X выбирает между двумя путями до Google от пиров Y и Z через iBGP. Если метрики равны, выбор делается по расстоянию до Y или Z. Обычно путь до Y ближе, но если топология поменяется и Z станет ближе, X выберет маршрут через Z и оповестит об этом eBGP соседей. Если соседям не понравится то, что через Z, они могут выбрать другой пир, и когда снова станет короче путь через Y, X обновит маршрут и eBGP соседи опять предпочтут ваш маршрут.

Я не хотел столько вдаваться в теорию BGP, но важно понять, почему iBGP сохраняет next hop IP, тогда как IGP меняет next hop на адрес соседа. Из-за этого ваш iBGP сосед должен быть доступен в любых условиях — вот почему для iBGP используют loopback интерфейсы.
03.08.2017 15:42:00, ZeroByte.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 13:55:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Можешь рассказать об этом подробнее? Впервые слышу подобное про iBGP-пиры.
03.08.2017 13:55:00, Cha0s.

BGP / Синхронизация конфигурации

Thu, 03 Aug 2017 13:53:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Надеюсь, вы используете безсостоянный 1:1 NAT (action=netmap), чтобы любой из маршрутизаторов мог корректно выполнять NAT без необходимости хранения состояния. Если вы применяете stateful NAT, при переключении соединения с одного маршрутизатора на другой всё временно сломается, потому что маршрутизаторы не могут обмениваться информацией о состоянии. Ещё момент — пиринг iBGP (R1<>R2) должен происходить по loopback IP-адресам, а не по /30 адресам линка между ними. (Это распространённая ошибка новичков в BGP)

Если хотите простое переключение с основного канала на резервный, сделать это довольно просто, особенно если ISP2 позволяет передавать community-листы в анонсах. Если у ISP2 есть community, которое говорит их сети снижать local_preference для префикса, используйте его, чтобы сделать предпочтение ниже, чем у маршрутов, полученных от их пиров или транзитных провайдеров. Это значит, что ваши анонсы в ISP1 будут идти через интернет и в итоге достигать ISP2 по косвенным маршрутам. Вам нужно, чтобы ISP2 выбирал этот путь вместо прямого канала к вам. Если поддержки community для снижения local_pref у ISP2 нет, придётся использовать AS-Path-Prepend. Добавьте что-то нелепое к AS-PATH во всех анонсах, например, 5-кратное препендирование. Возможно, ISP2 всё же отдаст предпочтение прямому пути из-за local_preference внутри своей сети, но когда ваши анонсы через ISP2 выйдут за пределы их сети, они будут выглядеть хуже на этапе выбора по AS-PATH по сравнению с анонсами через ISP1. С вашей стороны просто сделайте инбаунд-фильтр с ISP2, который всегда ставит local-pref=90, и всё готово. Ваш исходящий трафик всегда будет выбирать ISP1 вместо ISP2 (если только ISP2 не пришлёт более специфичный маршрут).

Если у вас есть блок /23 или больше, вы легко можете заставить переключение работать без настройки метрик. Допустим, у вас /22. Анонсируйте весь /22 в ISP2, а два /23 префикса — в ISP1. Так вы получите желаемое поведение с основным и резервным путём, и никакие настройки метрик от ISP2 уже не смогут повлиять на это.

Я обычно стараюсь избегать такого приёма, потому что он увеличивает глобальную таблицу BGP. Многие организации так делают, и из-за этого сейчас глобальная таблица BGP насчитывает около 641 тысячи префиксов.
03.08.2017 13:53:00, ZeroByte.

BGP / Синхронизация конфигурации

Wed, 02 Aug 2017 15:49:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Итак, у меня теперь есть две BGP-сессии с нашим транзитным провайдером, которые анонсируют наш /24 по обеим сессиям и получают обратно маршрут по умолчанию. Я могу пинговать через любое из этих подключений, а входящий трафик идёт на r1. Также у меня есть BGP-сессия между r1 и r2, но пока я не анонсирую по ней никаких маршрутов. В идеале я хочу, чтобы весь трафик обрабатывался на r1, а в случае потери транзита на r1 или если r1 перестанет работать — весь трафик шёл через r2, включая все NAT-соединения.

Я попробовал убрать фильтры маршрутизации на BGP-сессии между r1 и r2, и это убрало моё объявление из таблицы объявлений в разделе Routing>BGP.

У меня два вопроса:
1. Как правильно настроить BGP между r1 и r2? Сейчас они напрямую подключены через кабель с линком /30. BGP построен на этих IP с использованием нашего публичного ASN.
2. Как настроить r2, чтобы он мог делать NAT, когда трафик приходит на него? Нужно ли зеркалить IP-адреса и правила файрвола, чтобы они совпадали с r1?

Спасибо, PK
02.08.2017 15:49:00, packetkicker.

BGP / Синхронизация конфигурации

Sun, 06 Aug 2017 20:06:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Привет, спасибо за совет. Я настроил /32 loopback-адреса на каждом маршрутизаторе и переключился на эти IP для пиринга. Изменил исходящий фильтр маршрутизации для R2 на:
add action=accept chain=isp-out prefix=12.34.56.0/24 set-bgp-prepend=3

Это заставляет весь входящий трафик идти на R1, а использование VRRP — исходящий трафик тоже через R1. Я добавил сетевое событие (netwatch) на R1, чтобы проверять доступ в интернет, и если связи нет — менять приоритет VRRP, чтобы перекинуть исходящий трафик на R2.

add down-script=vrrp-prio-down host=8.8.8.8 interval=5s up-script=vrrp-prio-up
add name=vrrp-prio-down owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=“/interface vrrp set priority=1 [find priority=255]”
add name=vrrp-prio-up owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive source=“/interface vrrp set priority=255 [find priority=1]”

Пока что в тестах всё работает нормально. Если пиринг BGP между R1 и провайдером теряется — трафик переключается на R2, и если R1 уходит офлайн, то тоже переходит на R2. Для меня это идеально на данный момент, так как защищает от аппаратных сбоев и позволяет спокойно делать обновления ПО без отключений.

Ещё раз спасибо за помощь.
С уважением, PK
06.08.2017 20:06:00, packetkicker.

BGP / Синхронизация конфигурации

Mon, 10 Jul 2017 18:37:00 +0300

BGP / Синхронизация конфигурации RouterOS в форуме RouterOS.
Привет! У меня есть CCR1009-8G-1S-1S+, который сейчас стоит в колокации и выполняет функции фаервола и маршрутизатора. Наш провайдер дата-центра объявляет /24, который принадлежит нам, используя свой ASN, и маршрутизирует его к нам через /29 из своего пула IP. Планируется добавить ещё один CCR1009-8G-1S-1S+ через пару недель, и я хотел бы получить обратную связь и, возможно, советы по правильной настройке.

Мы подтвердили, что можем настроить BGP с провайдером DC, используя наш собственный ASN, который у нас есть. На каждом CCR будет /30 (частные IP) для соединения с провайдером DC, затем на каждом маршрутизаторе запустим BGP с объявлением того же /24 в интернет. Внутри сети планирую использовать VRRP для всех шлюзов, чтобы при недоступности основного маршрутизатора исходящий трафик шел через резервный.

Полагаю, что мы не сможем контролировать входящий трафик, так как он может идти на любой из маршрутизаторов. Поэтому на обоих роутерах должны быть одинаковые правила фаервола, состояния и таблицы маршрутизации, для чего я собираюсь использовать скрипты для синхронизации. Это звучит как хороший подход? Спасибо, PK
10.07.2017 18:37:00, packetkicker.