Я хотел бы получить некоторые мнения относительно способов, которыми я могу улучшить дизайн BGP с двумя провайдерами и двумя маршрутизаторами. Каждый провайдер предоставляет / 24 общедоступную подсеть. Я буду ссылаться на маршрутизаторы, каналы, подсети, группы HSRP и провайдеров как A и B соответственно. Пропускная способность каждой цепи достаточна для всей нагрузки.
Текущий дизайн
Текущий дизайн пытается достичь симметрии для каждого поставщика. В устойчивом состоянии предполагаемая логика маршрутизации состоит в том, что трафик в / из подсети A проходит только по схеме A, а трафик в / из подсети B проходит только по цепи B. Схемы будут поддерживать друг друга в аварийном состоянии.
Поставщики объявляют только маршрут по умолчанию. Исходящая маршрутизация влечет за собой сочетание PBR и HSRP. Маршрутизаторы не имеют маршрутизации между ними: нет iBGP, нет OSPF, нет статической маршрутизации. Вместо этого есть две группы HSRP, отслеживающие маршрут по умолчанию. Маршрутизатор A является основным для группы A HSRP, а маршрутизатор B является основным для группы B. HSRP. Нисходящие устройства имеют маршрут по умолчанию, указывающий на группу A HSRP и PBR, который направляет трафик, исходящий из подсети B, в группу B. HSRP влияет на предварительную и сообщества. Подсеть A подключена и подключена к цепи B, а подсеть B подключена и подключена к цепи A.
Я вижу много возможностей для улучшения этого дизайна. Отсутствие осведомленности о топологии интернета в сочетании со схожестью каналов полностью исключает лучший выбор пути. Существуют опасения по поводу назначения уровня поставщиков, и дизайн был рационализирован как обеспечивающий «приемлемую производительность» и упрощающий поиск и устранение неисправностей. Действительно, дизайн не может быть проще. Я продемонстрировал, что транзитный дополнительный AS добавляет 6 переходов и 63 мс (+ 421%) к RTT. Я бы предпочел не соглашаться на приемлемое.
Лучший дизайн
Более совершенный дизайн обеспечивает максимально возможную осведомленность о топологии Интернета. Лучший алгоритм оставлен для определения логики входящей и исходящей маршрутизации. Цепи поддерживали бы друг друга в неисправном состоянии.
Поставщики рекламируют полный вид. Маршрутизаторы работают с iBGP и OSPF. HSRP устранен. Исходящая маршрутизация будет представлять собой наилучший путь, основанный исключительно на назначении, а входящая маршрутизация будет предоставлена алгоритму наилучшего пути и прихотям транзитного провайдера.
Теперь, когда я его набираю, это кажется проще. По крайней мере, потребовалось меньше слов, чтобы объяснить. Есть проблемы с асимметрией, но я видел много асимметрии в текущем проекте. Я думаю, что они, вероятно, одинаково склонны к асимметрии, и это действительно не беспокоит меня. Мы никогда не видели проблем в результате. В настоящее время это относится к сфере ifs: «Что,« если », мы должны были что-то устранить?»
Я здесь далеко от базы или ударил ногтем по голове? Как другие решили эту проблему? Что бы сделал Google?
Ответы:
Да, ты ударил ноготь по голове.
Вы получите асимметрию в улучшенном дизайне, но асимметрия является фактом жизни в Интернете, и на самом деле нет веских оснований ожидать симметричной маршрутизации трафика в / из. Во-вторых, вся концепция маршрутизации пакетов заключается в том, что отдельные пакеты маршрутизируются независимо друг от друга и могут проходить по разным путям, даже если пакеты идут в одном направлении.
Лично я ненавижу PBR. Это одна из тех технологий, которые, когда я решаю, что это лучшее решение проблемы, я останавливаюсь и делаю шаг назад, чтобы увидеть, действительно ли я понимаю реальную природу проблемы, даже возвращаясь к выяснению, какую бизнес-проблему нужно решить. является. Когда я делаю это, я почти всегда обнаруживаю, что есть способ решить проблему без использования подобной технологии.
Наличие полных интернет-маршрутов в ваших маршрутизаторах потребует некоторого привыкания, но как только вы к этому привыкнете, это действительно очень легко понять и устранить неисправности. Конечно, есть меньше «движущихся частей» различных протоколов, о которых нужно беспокоиться.
Вы не хотите иметь полные интернет-маршруты в своей базе данных OSPF, поэтому вы захотите объявить настройки по умолчанию через OSPF во внутреннюю часть вашей сети (или, возможно, статические значения по умолчанию ... лично я предпочитаю значения по умолчанию в OSPF). Это переместит трафик к BGP-говорящим интернет-маршрутизаторам, которые могут принять более полное решение о наличии полных интернет-маршрутов.
Это приблизит вас к «лучшему пути на основе пункта назначения». Все еще будут случаи, когда трафик будет делать то, что вы не совсем ожидаете, поэтому вы захотите ознакомиться с процессом выбора маршрута BGP.
источник
Предлагать другой подход к уже данным другим, который может или не может быть лучше, чем существующие идеи, но прежде всего через некоторые дополнительные идеи там;
Я бы сказал, что вы можете предпринять два простых шага для улучшения вашей текущей ситуации:
Шаг 1 ;
Получите полные таблицы BGP от обоих провайдеров. Теперь у вас будет более оптимальная исходящая маршрутизация, поскольку вы будете осуществлять маршрутизацию через транзитного провайдера с наименьшим путем AS к месту назначения. Как вы сказали, вы можете удалить HSRP и просто объявить маршрут по умолчанию в OSPF и запустить iBGP между двумя пограничными маршрутизаторами.
Шаг 2 ;
Настройте AS prepends, сообщества и т. Д. На двух пограничных маршрутизаторах для точного управления исходящим трафиком. Таким образом, у провайдера B может быть лучший маршрут к некоторой подсети, но вы можете купить больше транзита у провайдера A, а точнее - через него и так далее.
Предполагая, что два / 24, которые вы упомянули как имеющие, являются PI-независимым адресным пространством, поэтому вы объявляете их через обоих провайдеров, или оба провайдера согласились объявить одно и то же пространство IP-адресов для вас, теперь вы можете объявить оба префикса обоим провайдерам с обоих маршрутизаторов. без prepends или сообществ, а также получите лучшую входящую маршрутизацию (конечно, если у вас нет CDR, к которым вам нужно присоединиться или что-то подобное, в этом случае вы можете настроить по мере необходимости).
источник
Начните с простого, затем добавляйте сложность только при необходимости. Я бы задал вопрос, есть ли необходимость запускать OSPF на ваших пограничных интернет-маршрутизаторах. Загрузите PBR на обочину и используйте только в своей внутренней сети.
Все это можно упростить, если вы просто используете один / 24, рекламируемый как А, так и Б.
Позже рассмотрим усложнение для лучшего проектирования и защиты трафика:
Установите плавающий статический маршрут по умолчанию на обоих маршрутизаторах в качестве аварийной резервной копии всего остального на случай, если ваш BGP взорвется.
Изучите более сложные способы рекламы для управления своей входящей политикой, такие как половина вашего IP-пространства, проходящая через A, а другая половина - через B. Для заданного / 24 вы можете объявить / 24 для A и B, но разделить это на два / 25 и рекламируют нижний / 25 до А и верхний / 25 до Б.
Используйте мягкую реконфигурацию, чтобы вы могли настроить свои политики и сделать программный сброс в сеансе BGP, чтобы не вызывать демпфирование ваших префиксов на другой стороне, если вы полностью сбросили (или очистили) сеанс. Изменения в политике требуют сброса.
источник
Из того, что я понял из написанного, на самом деле вам не нужно принимать решения на основе путей AS для доступа к внешним подсетям, и единственная цель двойного подключения к двум провайдерам - это купить избыточность для доступа в Интернет. Если это так, то вам не нужно запускать BGP. Вы можете просто принять те же маршруты по умолчанию, которые вы уже получаете от вашего поставщика услуг. Теперь для локальной стороны сети, запустите одну область ospf на маршрутизаторах, которые подключаются к провайдеру на интерфейсе, обращенном к вашей локальной сети (не включайте интерфейс провайдера в процесс), и в зависимости от того, насколько простой дизайн должен быть Вы можете добавить маршрутизаторы в разных областях и суммировать подсети на границах сети, но для двух подсетей я думаю, что размер базы данных OSPF или количество затопления LSA не является большой проблемой,
На каждом маршрутизаторе OSPF, который подключается к провайдеру, перераспределите изученные маршруты по умолчанию в OSPF с помощью оператора «default-information originate».
Пара преимуществ:
С этим дизайном, когда вы расширяете сеть, вы можете включить BGP с поставщиками услуг и просто принять маршрут по умолчанию, не затрагивая никаких устройств ниже по течению. Пока вы не убедитесь, что вы получаете маршрут по умолчанию от BGP, вы в порядке.
Всякий раз, когда вам нужно направить трафик от поставщика услуг Интернета для обслуживания, просто удалите «источник информации по умолчанию» из-под процесса OSPF на этом маршрутизаторе и продолжайте обслуживание. Больше ничего не нужно.
И я согласен с предыдущим ответом в том, что симметричная маршрутизация переоценена, я предпочитаю масштабируемость и простоту обслуживания.
источник
Если полная таблица BGP слишком велика для вас, я думаю, вы могли бы подумать только о получении порции. Возможно, провайдеры A и B каждый объявляют маршрут по умолчанию и свои локальные маршруты AS. Вам нужно будет запустить iBGP внутри. Таким образом, у вас будет кратчайший маршрут для всего, что напрямую связано с провайдерами, и вы выберете любой из маршрутов AS ниже по течению.
источник