Хотим поделиться переводом серии заметок из блога Расса Уайта (Russ White), где он поднимает вопрос использования AS-PATH Prepend при подключении к Интернет-провайдерам по BGP.
При подключении организации к двум и более провайдерам по BGP могут возникать несколько задач. Например, избежать асимметричной маршрутизации, т. е., добиться, чтобы ответные пакеты возвращались через того же провайдера, через которого инициируется сессия. Или, наоборот, добиться равномерного распределения трафика по каналам провайдеров, не принимая во внимание асимметричную маршрутизацию. В обоих случаях влиять на маршрутизацию Интернет-провайдеров в сторону корпоративной сети можно с помощью BGP-атрибута AS-PATH. Но, к сожалению, данный подход далеко не всегда помогает добиться нужного результата. О проблемах использования AS-PATH Prepend как раз и пойдёт речь.
Почему не работает AS-Path Prepend?
Итак, вы хотите улучшить распределение нагрузки на входящих каналах. Поискав в Интернете, вы довольно быстро найдёте сайт, где объясняется, как настроить для данной задачи AS-Path Prepend. Во время следующих профилактических работ вы всё это проделаете и… обнаружите, что какое-то количество трафика перенаправляется, но не так много, как хотелось бы. Вы дожидаетесь следующих плановых работ на канале и настраиваете ещё несколько prepend-ов. Опять всё запускаете и… видите, что почти ничего не изменилось. Почему так? Есть несколько причин, по которым prepend не всегда оказывается эффективен. Но главным образом это связано с тем, как сам по себе устроен Интернет. В качестве примера сети возьмём изображение ниже.
Вы находитесь в AS65000 и пытаетесь отбалансировать трафик межу каналами 65001->65000 и 65004->65000. Допустим, prepend вы настроили для AS65001, поскольку этот провайдер шлёт вам больше трафика. Предположим, что AS65003 принимает маршруты от AS65001 и AS65004 на равных условиях. Настроив prepend, вы сделали так, что маршрут к вашим сетям в AS65000, с точки зрения AS65003, стал выглядеть длиннее через AS65001. Здесь первый prepend сработает.
Но что будет, если мы добавим ещё один дополнительный prepend? Повлияет ли он как-нибудь на поток трафика? У AS65003 есть только два возможных пути к пунктам назначения: один через AS65001, второй через AS65004. Он может выбрать только один из этих двух маршрутов. Если здесь сработал один prepend, второй уже ничего не сделает. Это подводит нас к первой проблеме с использованием prepend: он эффективен только когда задан в пределах реалистичных параметров AS-Path. Дополнительные 256 prepend-ов в этой сети не дадут большего эффекта, чем тот, что был от первого их них.
Если эффективность использования prepend связана с общей длиной маршрута по сети, то первый вопрос, который следует задать — какова средняя длина маршрута в Интернете? Оказывается, есть организации, которые проводят такие замеры регулярно и уже довольно давно (по меркам Интернета). К примеру, у аналитиков CAIDA, RIPE и Potaroo есть данные масштабных измерений, поведённых в Internet Default-Free Zone (DFZ). Вот график средней длины AS Path в DFZ с 1998 года:
Как видим, средняя длина AS Path мало изменилась за последние 8 лет — даже несмотря на то, что количество маршрутов и подключенных автономных систем за это же время разительно возросло. Это позволяет понять, что в большинстве случаев первый AS-path prepend будет иметь наибольший эффект, второй повлияет меньше, а все остальные уже будут просто для красоты.
Есть две причины, почему prepend может вообще не работать.
Первая: возьмём соединение между AS65001 и AS65004. Мы знаем, что между ними существуют какие-то пиринговые взаимоотношения: возможно, с оплатой, возможно, без — это нам неизвестно. Но мы знаем наверняка, что AS65001 всегда предпочтёт ваш маршрут, полученный от вас, этому же маршруту, полученному от AS65004. И это предпочтение настроено у AS65001 через LOCAL_PREF, приоритет у которого всегда будет выше, чем у вашего AS-Path Prepend. Вывод? Как ни старайтесь, у вас не получится направить трафик по пути 65004->65001 с помощью prepend.
Вторая: обратите внимание на AS65002 в углу. AS65001 всегда будет отдавать предпочтение маршруту к клиенту, полученному от самого клиента. Так что, помимо вышесказанного, вам также никак не заставить трафик от AS65002 идти через AS65004 вместо AS65001.
Теперь, зная, почему prepend не всегда срабатывает, давайте подумаем, что мы можем предпринять.
Что делать?
Когда мы определили, что AS-Path prepend нам уже ничем не поможет, каковы наши дальнейшие действия?
Маршрутизация основывается на выборе самого длинного префикса, совпадающего с адресом назначения. Это верно и при сравнении BGP маршрутов, безотносительно AS-PATH. Так что, один из вариантов здесь — разделить ваше адресное пространство на более длинные анонсируемые префиксы и анонсировать часть каждому из ваших вышестоящих провайдеров (для обеспечения отказоустойчивости можно настроить анонсирование префикса через другого провайдера на основе условия недоступности первого — BGP conditional advertisement feature — прим. ред.). На рис. 3 показано, что AS65000 разделяет свой /44 IPv6-префикс на два и анонсирует их AS65001 и AS65004 соответственно, из-за чего половина трафика подсети AS65000 приходит от одного конкретного провайдера. Этот приём можно использовать вместе с AS-Path prepend, чтобы эффективнее распределять нагрузку.
Использование более длинных префиксов для направления трафика по предпочтительному входящему каналу — уже неплохой шаг к формированию желаемого паттерна входящего трафика. Некоторые сценарии требуют более гранулярного управления.
Но что делать, если у нас нет возможности создавать более длинные префиксы в вашей ASN (например, в /24 для IPv4 и /48 для IPv6)? В таких случаях нам может помочь атрибут community протокола BGP. Использование community позволяет влиять на то, как ASN анонсируется внутри сети нашего вышестоящего провайдера и его пирам. Пример можно видеть на рис. 4. AS65002 — клиент AS65001, согласно политике маршрутизации внутри 65001, префиксы, полученные от клиентов, имеют приоритет над теми, что получены от BGP-пиров. Это значит, что несмотря на AS prepend, анонсируемый для AS65001 с нашего канала, AS65002 всё равно будет использовать 1-гигабитный канал. Если AS65002 шлёт нам много трафика, мы можем столкнуться с перегрузкой входящего соединения через AS65001. С помощью BGP community можно сделать так, чтобы AS65001, несмотря на собственную политику, направлял трафик к AS65004.
У большинства провайдеров есть документ, в котором указано, какие community он принимает и использует для таких задач — почти никто из провайдеров не использует community, обозначенные в RFC1998. К примеру, вот старый документ по L3, и вот список политик BGP community, которые сейчас использует провайдер JT. Лучший способ выяснить такие вещи — спросить непосредственно у провайдера.
AS prepend, разделение префиксов и BGP community можно использовать одновременно, но при этом очень важно хорошо продумать политику BGP.
Стабильность, которую даст более сложная политика, может сказаться на устойчивости системы в случае отказа или породить излишнюю сложность в настройке, логику которой будет непросто понять в два ночи. Главный вопрос, которым должен задаться инженер при создании политики — что будет, если что-нибудь отвалится? На рис. 5 политики с рис. 3 и рис. 4 применены одновременно. О чем сразу следует подумать:
- Нужно ли нам анонсировать агрегированный маршрут вместе с нашими длинными префиксами? Подсказка: ответ на этот вопрос почти всегда утвердительный.
- Нет ли у AS65004 противоречивой политики внутренней маршрутизации?
- Что произойдёт в случае отказа канала?
- Должны ли ответы на исходящие пакеты возвращаться по тем же каналам (stateful firewalling или NAT)?
О чём стоит задуматься, прежде чем решать проблему?
Этот небольшой цикл начался с простой проблемы — что делать, если у нас не отбалансирован входящий трафик на двух каналах с выходом в Интернет. Другими словами, как реализовать распределение нагрузки в BGP. Первая часть касалась проблем с AS-Path prepend, а вторая – деагрегации и использования атрибута communitу для модификации local preference в сети вашего провайдера.
В последней части мы снова коснёмся деагрегации. Анонсирование более длинных префиксов — это «тяжёлая артиллерия» маршрутизации. С анонсированием большего числа префиксов следует быть осторожнее. Default Free Zone — это общественная собственность. Таблица маршрутизации в Интернете никому не принадлежит, но все ею пользуются. Деагрегация не стоит вам ничего, но всем остальным приходится расплачиваться. Добавить ещё один маршрут в таблицу маршрутизации несложно, но помните, что более длинный префикс, который вы добавите, будет виден всему Интернету. За решение своей проблемы вы расплачиваетесь небольшим количеством памяти с каждого маршрутизатора в мире, подключенного к DFZ. Если все начнут бездумно деагрегировать — всем придётся покупать более мощные маршрутизаторы и дополнительную память. Включая вас.
Есть тонкая грань между использованием общественного ресурса и злоупотреблением им. Если все будут злоупотреблять общественным ресурсом, потому что им это «ничего не стоит», результат будет губительным для этого ресурса. А разрушив общественную собственность, будет очень непросто восстановить изначальные доверительные отношения, благодаря которым она появилась. Так что, прежде чем настраивать деагрегацию, подумайте, действительно ли без этого вам не обойтись.
Так ли это необходимо? Действительно ли так важно отбалансировать эти два входящих канала? На то могут быть финансовые причины, например, стоимость использования двух каналов или цена превышения трафика на одном из них. Конечно, это всё лишь предположения, но, быть может, было бы разумнее изменить ширину доступных каналов, чем внедрять техническое решение, которое нужно будет обслуживать и поддерживать.
Помните, что всё, что вы настраиваете, однажды откажет. А отказы нередко выливаются в звонки ночью. Рассмотрите разные варианты, прежде чем настраивать оптимизацию.
Как мне уменьшить ущерб общественной собственности?
Возвращаясь к сети из нашего первого примера — можно ли реализовать деагрегацию так, чтобы перевести трафик с AS65001 на AS65004, не влияя на размер таблицы у всех, к кому подключены эти провайдеры? Собственно, большинство провайдеров не только принимают присылаемые вами community для настройки local preference в их AS, но также позволяют блокировать анонсирование своим пирам любого указанного маршрута. Вам может потребоваться немного поиграть с этими community, чтобы понять, как они влияют на поток входящего трафика. Например, как скажется блокировка анонсирования более длинных префиксов транзитным пирам вышестоящего провайдера, в сравнении с блокировкой анонсирования этих же префиксов для определённой группы клиентов провайдера. Поскольку вы не можете напрямую определить, как и где подключён этот провайдер, можно связаться с ним и выяснить, что и где следует анонсировать, чтобы минимизировать глобальное влияние, либо же попробовать различные сочетания и в процессе определить лучший вариант.
Правильно ли у меня устроен пиринг? Ещё один вариант — обратить внимание, через каких провайдеров вы подключаетесь в глобальной сети. Предположим, что это один региональный и один глобальный провайдер. В таком случае, то, какой из них шлёт вам больше трафика, будет сильно зависеть от вашей клиентской базы.
К примеру, если вы местная компания вроде регионального банка или медицинского учреждения, то большинство ваших клиентов будет подключено к региональному провайдеру (а не к tier-1), и, скорее всего, большую часть трафика вы будете получать с его канала. Если же ваш бизнес не так привязан к географическому расположению, то от регионального провайдера трафика будет приходить не так много — по большей части от людей, которые заходят в вашу сеть, находясь в вашем регионе. В таких случаях неравномерная нагрузка на этих двух каналах — вещь вполне ожидаемая.
Если ситуация именно такова, возможно, было бы правильнее наладить взаимодействие с двумя провайдерами так, чтобы оно сближало вас с вашими клиентами. Если ваши клиенты находятся по всему миру, скорее всего, вам лучше быть подключённым к двум провайдерам национального или глобального уровня, чем к одному региональному и одному глобальному. По возможности, лучше балансировать входящий трафик, отталкиваясь от того, кто ваши клиенты и как лучше их охватить, вместо того чтобы идти на различные инженерные ухищрения, пытаясь заставить сети двух провайдеров совершенно разного типа слать вам одинаковое количество трафика.
Вывод здесь следующий: инженерное решение должно быть последним выходом, когда больше ничего не помогает. Разумеется, все мы здесь инженеры, и для нас ничто так не оправдывает деньги, потраченные на покупку железок, как изящный и объёмный набор команд и конфигураций этих железок, с помощью которого мы решили проблему высокой загрузки канала. Но всё же настоящее инженерное искусство — находить первоисточник, углубляясь в саму суть проблемы, а не бороться с вторичными последствиями.