Назад | Перейти на главную страницу

Как предотвратить асимметричную маршрутизацию с несколькими маршрутизаторами eBGP?

У меня есть 2 маршрутизатора, объявляющих подсеть / 22 различным поставщикам (один поставщик подключается к каждому из 2 маршрутизаторов). Я разделил / 22 на два / 23, чтобы объявить по одному / 23 на каждом из маршрутизаторов, плюс / 22 (провайдеры выберут более конкретный маршрут). Это позволяет мне переключаться при отказе и удерживать трафик внутри / 23 от одного и того же провайдера.

Какими еще способами я мог бы объявить только / 22 с обоими маршрутизаторами и получить пакеты с серверов в сети за маршрутизаторами, чтобы вернуться к тому же маршрутизатору, с которого они пришли?

РЕДАКТИРОВАТЬ:

Основная проблема, с которой я столкнулся, и на которую конечные пользователи и клиенты жалуются больше всего, заключается в том, что маршрут с наименьшим переходом иногда не является «оптимальным». В моем случае я знаю, что у провайдера B может быть лучшая задержка для X нации. Но когда пакеты приходят от поставщика B, они могут уходить от поставщика A или поставщика B. Верно и обратное. Если я отправлю пакет провайдеру A X нации, даже если у него может быть больше обратных переходов, пакет, скорее всего, придет от поставщика B (который может иметь более высокую задержку, потерю пакетов и т. Д. Для этой страны)

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

пример

Это один из примеров того, что может случиться. Предположим, у вас есть AS 777, которому принадлежит 2.2.0.0/22. У вас есть сервисы, к которым компания с маршрутизатором A должна получить доступ ... Предположим также, что у AS 100 нет хорошего канала связи с вами (возможно, он периодически портит трафик из-за проблем на физическом уровне, которые вы не смогли исправить. ). Итак, вы думаете про себя, «Я просто добавлю все свои объявления к AS100 с большим количеством ASN, поэтому никто не предпочтет канал AS100, пока я не исправлю это».

Проблема в том, что у вас есть только полный контроль над своим решения по исходящей маршрутизации. Вы не получаете полного контроля над входящими данными ... так что предположим, что администратор маршрутизатора A не знает, что ваша ссылка на AS100 плохая. Они имеют двойное подключение к AS200 и AS100, но AS100 предлагает гораздо более дешевый транзит на Мбит / с; поэтому инженер маршрутизатора A берет полные маршруты от AS100 и использует AS200 только в качестве резервной копии (принимая от них только значения по умолчанию).

Как администратор AS 777, вы можете принудительно направлять трафик к маршрутизатору A через AS 200, но трафик от маршрутизатора A до 2.2.0.0/22 ​​все равно будет принимать AS 100 (потому что лучший маршрут - через AS 100 на маршрутизаторе A).

Возможные решения

Обычно асимметричные пути имеют значение из-за балансировщика нагрузки или брандмауэра, который принимает трафик. Некоторые возможные решения:

  • Для предлагаемых услуг в других ASN, вы можете использовать NAT все исходящий трафик на адрес, который является локальным по отношению к ссылке, ведущей к определенной AS (хотя это не работает для поставщиков услуг)
  • Для предлагаемых услуг в вашем ASN, вы можете использовать NAT все входящий трафик на адрес, который является локальным для подсети на рассматриваемом пиринговом маршрутизаторе BGP (хотя это не работает для поставщиков услуг)
  • Вы можете настроить DMZ, которая принимает трафик от всех различных ASN и предлагает одну точку входа / выхода для трафика от ваших восходящих потоков. При некоторых обстоятельствах вы даже можете синхронизировать таблицу состояний на устройствах DMZ. (хотя это не подходит для поставщиков услуг)
  • Если вы хотите использовать такие функции, как Условное объявление BGP, иногда вы можете обойти подобные проблемы за счет отказа от использования других операторов для входящего трафика до 2.2.0.0/22.

Если вы предоставите более подробную информацию о характере услуг и проблеме, мы сможем предложить более конкретные рекомендации.

Какими еще способами я мог бы объявить только / 22 с обоими маршрутизаторами и получить пакеты с серверов в сети за маршрутизаторами, чтобы вернуться к тому же маршрутизатору, с которого они пришли?

а зачем тебе это? Или, точнее, почему вы хотите сила это поведение (поскольку обычно это происходит благодаря магии маршрутизации)?


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

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

Способ достижения симметрии здесь на самом деле не столько функция BGP, сколько NAT. Предположим, вы продолжаете схему объявления / 22 из обоих маршрутизаторов, а также по одному / 23 из каждого. Настройте NAT для исходящего трафика так, чтобы трафик, покидающий данный пограничный маршрутизатор, получал адрес источника в / 23 этого маршрутизатора. Чтобы обеспечить симметрию для входящего трафика, вам также понадобится NAT источника для преобразования подключений из глобальных источников в отдельные пулы, выделенные каждому пограничному маршрутизатору.

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

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