Практика BGP

Привет, CiscoGuy! Вчера вечером я провёл несколько тестов, и с утра всё работает нормально. Я проверил через другой looking glass, и там тоже всё в порядке. Я только что настроил опцию prepend, чтобы предпочесть одного провайдера над другим, и отправил это своим ISP.

Предполагаю, ты делаешь это только чтобы сократить один прыжок? Если твой BGP настроен правильно и пакет, направленный в Интернет, приходит на роутер B, то роутер B должен отправить его на роутер A, который уже вышлет его наружу по своему соединению. Единственная причина менять метрику вот так — попытаться заставить пакеты идти сразу на роутер A, а не через роутер B, а затем роутер A.

П.С. Только что заметил: ты сказал, что используешь статический маршрут по умолчанию к своему провайдеру. Зачем? Провайдер должен предоставлять тебе маршрут по умолчанию через BGP, и ты можешь им пользоваться.

Ты можешь настроить нужный уровень избыточности, да, но ситуация здесь сложнее, чем у большинства новичков. К сожалению, такой взгляд на топологию сети слишком упрощённый, потому что я не вижу всей картины, но предполагаю, что роутеры C, D и F образуют своего рода ядро, а роутеры A и B — это граничные устройства. Нужно очень внимательно продумать, что именно может пойти не так.

Вижу несколько проблем:
Если роутеры A и B будут заниматься BGP, они должны быть связаны друг с другом, чтобы их таблицы маршрутизации совпадали. Обычно они находятся рядом, но в твоём случае между ними несколько переходов. Это может привести к проблеме «раздвоения мозга» (split brain) при определённых сбоях, о чём поговорим позже.

Имей в виду, что если пакет всё-таки приходит на роутер B для выхода в Интернет, а роутер A работает исправно, пакет будет отправлен через роутер A, если тот установлен как предпочтительный шлюз, ведь их маршруты должны совпадать.

Если на роутерах A и B есть статический маршрут по умолчанию, а BGP-пиринг упадёт, но Ethernet-связь останется, маршрут по умолчанию в OSPF всё равно пойдёт через роутер A, поскольку маршрут будет активен. Можно решить эту проблему, попросив у обоих провайдеров давать только маршрут по умолчанию вместо полной таблицы маршрутов. Тогда этот маршрут исчезнет, если BGP-пиринг упадёт.

Если ты выберешь вариант №2 (вероятно, лучший), тогда вопрос будет в том, как распространять маршрут по умолчанию через OSPF. RouterOS теоретически может делать это через опцию «redistribute default if-installed», но на практике это не всегда надёжно и может работать неправильно.  
У нас на работе мы обходим это, запуская второй автономный номер (частный AS) на ядре, в отличие от граничных устройств с публичным AS. На ядре ставим статический маршрут «чёрная дыра» по умолчанию (blackhole default route), который перераспределяется в OSPF. Когда пакет доходит до ядра, оно получает маршрут по умолчанию через BGP и направляет его на нужный граничный роутер.

Если ты возьмёшь такой подход, то тебе нужно будет выбрать приватный номер AS из диапазона 64512–65535 и настроить BGP на роутерах C, D и F с этим номером AS. Придётся установить пиринги между C и D, D и F, и C и F (если не используешь route reflectors). Также нужно запиринговать роутер F с роутером B (публичный AS) и роутер C с роутером A (публичный AS).  

Кроме того, стоит включить опцию «remove private AS number» на внешних пирингах с провайдерами на роутерах A и B, чтобы случайно не отправлять провайдерам маршруты с приватным AS в AS path.

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

Если ты сделал то, что описано в пункте №3, то OSPF будет перераспределять маршрут по умолчанию, вероятно, на всех роутерах C, D и F, с статическим «чёрная дыра» по умолчанию на каждом. Тогда OSPF направит трафик с других роутеров (не из этих пяти) туда, где BGP возьмёт на себя дальнейший роутинг. Статический маршрут «чёрная дыра» по умолчанию — это способ обойти ненадёжность опции «redistribute if-installed», потому что потом можно использовать «redistribute always», так как статический маршрут «чёрная дыра» воспринимается как статический маршрут по умолчанию для остальных роутеров.

Ещё одна проблема — возможная ситуация split-brain. Нужно подумать, что произойдёт, если внутри сети упадёт какая-то связка. Два последствия:

1. Самое безобидное — если граничные роутеры потеряют пиринг, они оба установят маршрут по умолчанию от своего провайдера. Что касается маршрутов в приватном AS для роутеров C, D и F — тут непредсказуемо. Трафик может пойти не тем шлюзом, но связь останется.

2. Сеть может разделиться на две части из-за разрыва соединения. Твоя схема выглядит как цепочка: потеря связи между A и C, или C и D, или D и F, или F и B разделит сеть на две части. Я не вижу, что у тебя построено для отказоустойчивости, ты показываешь только пять роутеров, будто они выстроены в цепочку. Если так и есть, то разрыв в любом месте сети повлечёт разделение. Обе части смогут отправлять трафик наружу (если A и B в порядке), но если входящий трафик идёт на роутер A, то ответный трафик во вторую половину сети не попадёт из-за разрыва.

Худший вариант, который я вижу (хотя полностью не продумал) — потеря линка между роутерами A и C, при этом роутер A будет работать и успешно пирован с ISP1. Значит, роутер A окажется в изоляции, а роутеры B-F останутся связаны, но без связи с A. В этом случае весь входящий трафик пойдёт на A, но он не сможет передать пакеты дальше по сети из-за разрыва. Тогда твоё переключение на резервное соединение не сработает, как надо.

Проблема split-brain в пункте 4 кажется мне серьёзной, и возможно есть другие нюансы, которые я не учёл. Нужно тщательно продумывать, какие курьёзы могут случиться при каждом возможном сбое, прежде чем разворачивать определённую топологию.

Граничные роутеры должны иметь резервное соединение друг с другом, чтобы исключить проблему split-brain.

Ещё один вариант — изменить дизайн так, чтобы публичные префиксы исходили из более внутренних роутеров, например, C, D или F, или их комбинации.

Для более детальной информации смотри https://www.noction.com/knowledge-base/bgp-configuration в разделе «Where to originate prefixes».

Сначала проверьте с помощью просмотрщика, чтобы убедиться, что вы добавляете префикс с точки зрения интернета достаточное количество раз. Для некоторых пирингов требуется несколько попыток, чтобы получить нужный эффект. Второе, что можно сделать — просто изменить локальные предпочтения у маршрута по умолчанию, который рекламируется через ISP2, чтобы он стал предпочтительным для внутреннего выбора. Вам нужно будет убедиться, что метрики IGP корректны для оптимизации пути. Асимметричная маршрутизация в основном влияет на трафик только тогда, когда используются средства безопасности, а в больших и небольших сетях с асимметричной маршрутизацией часто проблем нет.