В этой небольшой заметки хочу коснуться некоторых интересных моментов и особенностей управления трафиком (или попыток управления трафиком) в случае использования протокола BGP. Статья не даст ответ на вопрос о том, как сделать счастье в сети!
Изложенная информация носит познавательный характер и будет полезна как легкое чтиво специалистам связанных с телекоммуникациями. Сведения будут изложены в достаточно свободной форме, без излишнего насыщения спецификой. Попробуем ответить на вопрос: «почему трафика нет там, где он должен быть, и есть там, где быть его не должно».
Мы не будем рассматривать назначение протокола BGP со всеми вытекающими последствиями, а сразу возьмем быка за рога.
Исходные данные
Начнем с того, что мы имеем собственную автономную систему, делегированный блок(-и) адресов и одного провайдера. В данном случае связь нашей AS с сетью Интернет осуществляется используя один единственный канал с провайдером. Трафик в нашу сеть (к нашим префиксам) пройдет через этот логический канал, второго мнения тут быть не может. Аналогично с входящим трафиком, весь исходящий трафик пойдет через единственный существующий канал.
Все работает хорошо, но рано или поздно приходит момент, когда возникает необходимость подключения к дополнительному провайдеру. Причин этому множество, но хотел бы немного остановиться на этом моменте. Подключая второго (третьего ...) провайдера клиент пытается обеспечить резервирование каналов, повысить связность, оптимизировать затраты на Интернет (у провайдера А дешевый «мировой» канал, провайдер В может обеспечить скоростное и дешевое включение в локальные точки обмена трафиком) и <добавьте свой вариант>.
Ситуация с резервированием канала может иметь два основным сценария:
1) имеется основной канал емкостью 1Гбит. Резервный (только на случай резерва) покупается значительно меньшей пропускной способность — например, 100 Мбит. В этом случае стоит осознавать последствия выхода из строя основного канал — конца света не наступит, но клиенты ощутят перемены;
2) резервный канал покупается аналогичной (или близкой к тому) пропускной способность. Такой канал получается не совсем дешевый и очень не хочется что бы он простаивал. Тут администратор начинает шаманить с разными балансировками.
Природно, что сетевой администратор хочет абсолютно точно поминать как трафик входит/выходит/проходит через его сеть. А бы даже сказал — его автономную систему. Так вот, в этом можно на 100% быть уверенным только в том случае, если используется один провайдер. Если провайдера два или более — можно предполагать, с очень высокой долей вероятности, как трафик войдет/выйдет из AS и вот почему.
В рукаве администратора несколько механизмом повлиять на информационные потоки (local preference, weight, med, as-path, med, etc.), но на сколько они эффективны? Скажу отвечу, что они достаточно эффективны (кто-бы сомневался), но не до конца. Ниже приведу парочку интересных примеров.
1. Исходящий трафик
Предположим что от двух провайдеров мы получаем Full View. Первый провайдер у нас будет основной, второй — резервный. Определяем политику обработки анонсов от провайдера: устанавливаем на префиксы, полученные от первого провайдера, больший local preference (как вариант) чем на префиксы, полученный от второго провайдера.
Рис. 1
В итоге весь исходящий трафик должен пойти по основному каналу. Визуализируем логические каналы (например с помощью Cacti Weathermap) и наблюдаем странную картину: трафик уходит не только через основной канал, но и через резервный. Как же так?
Все дело в том, что один Full View другому — рознь. Посмотрим на то, что мы получаем от провайдеров, в частности, на количество получаемых префиксов PfxRcd (пример взят с реального маршрутизатора):
#sh ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
X.X.X.X 4 AAAAA 3582179 106997 96854566 0 0 4w6d 392986
Y.Y.Y.Y 4 BBBBB 772880 508161 96854556 0 0 6d02h 400394
Сессия с оборудованием X.X.X.X (AS-AAAAA) — основная.
Видим разницу в количестве в 8000 префиксов. Это означает, что если мы будет запрашивать ресурсы, находящиеся в этих 8000 сетях, то будет использоваться резервный канал. Почему так получается? Обратив внимание на эти префиксы (дельту) я заметил, что и от основного провайдера я их получаю, но в агрегированном виде. Имеется ввиду, что вместо 4*/24 мы получаем 1*/22. Кто делает эту сумаризацию? Тяжело сказать, наверное, кто-то из upstream'ов.
Небольшой подитог: даже исходящий трафик способен вытекать тудой, кудой мы не ожидаем.
2. Входящий трафик
В этом случае все с одной стороны проще, с другой сложнее.
Каким образом мы можем влиять на поведение входящего трафика? Классика — искуственно удлинять AS-PATH (prepend), отправлять анонсы провайдеру с некоторыми communities для занижения провайдерского local preference (сражу скажу, что такую возможность предоставляют не все провайдеры, а у некоторых, достаточно не маленьких, даже нет looking-glass. В таком случае коллеги звонят провайдеру и дежурный администратор в телефонном режиме рассказывает какие префиксы он «видит» и с какими атрибутами) и другие значительно менее эффективные методы.
Но как бы мы не старались, в большей мере все зависит от политик провайдера. И если с балансировкой/нагрузкой исходящего трафика все более менее хорошо, то входящий трафик мы будем получать в оба канал, причем в достаточно непредсказуемом соотношении.
Например. Наша AS-A имеет связи с двумя провайдерами: AS-B (основной) и AS-C (резервный). Свои сети мы анонсируем обоим провайдерам, но в сторону резервного мы специально удлиняем AS-PATH (хотим получить трафик в этот канал только при неисправностях с основным).
Рис. 2
Резервный провайдер получает анонсы о наших сетях из двух источников: непосредственно от клиента (от нас) и от своих пиринговых партнеров (пунктирная линия). Во многих случаях приходится сталкиваться с тем, что провайдер считает более приоритетным путем в клиентскую сеть тот путь, который пройдет через линк, непосредственно соединяющий его с клиентом. Для этого он (резервный провайдер) увеличивает значения local preference на анонсы, полученные непосредственно от клиента (в данном случае 200), а не от пира (в данном случае 100). Всем своим соседям он расскажет именно об удлененном пути (анонсах полученных от клиента), так как BGP маршрутизатор анонсирует дальше только лучший маршрут.
Значит, если трафик будет проходить через автономную сеть провайдера AS-B, то получать мы его будем в основной канал, если через сеть провайдера AS-C — в резервный. В итоге, хотим мы того или нет, но входящий трафик к нам будет «заходить» с обоих каналов. В добавок мы получаем ассиметрию: всячески пытаемся отправить трафик в основной канал, а получаем его и с основного, и с резервного.
Небольшой подитог: при двух и более провайдерах, трафик будет «литься» со всех сторон.
3. Иногда, даже порядок установки сессий играет роль
1. Рассмотрим пример.
Рис. 3
Наша сеть (AS-A) связана с провайдером (AS-B). AS-C, AS-D — другие провайдеры, AS-E — такой-же клиент как и мы. Зеленой стрелкой показано распостранение маршрутной информации, синей — входящий трафик.
2. И тут мы решаем установить связь с AS-E (это наш партнер, не провайдер). Суть связи не в организации дополнительного канала, а в обеспечении резервирования — страховки друг друга. По умолчанию, линк должен быть не нагружен. При возникновении аварий, одна AS подстраховывает другую.
Для этого мы устанавливаем политику на исходящие анонсы в сторону партнера, а именно удлиняем AS-PATH. Для партнерской сети этот анонс не является лучшим, поэтому дальше AS-E его не распространяется.
Рис. 4
3. Но так случилось, что наша сессия с основным провайдером порвалась (или это мы тестировали). В таком случае происходит: красные стрелки — распостранение удлиненного маршрута, синие стрелки — путь трафика в сеть.
Рис. 5
И тоже все в порядке.
Сессия с основным провайдером поднимается. Следует отметить, что провайдер AS-D — это тот случай о котором мы говорили ранее (для клиентов устанавливают повышенный local preference), остальные провайдеры такого не делают, то есть выбор пути основывается на AS-PATH.
4. AS-B принимает анонс от AS-A. Анонс без prepend, стало быть этот путь теперь лучший, и именно он анонсируется далее.
Рис. 6
Видим как далее распостраняется анонс и меняются источники трафика:
Рис. 7
5. В конце концов информация о доступности собственных префиксов AS-A доходит до AS-D. Для этой автономной системы такой путь считается менее приемлемым, так как ранее на обновления от клиента (от AS-E) были установлены более высокие local preference. Итогом этих процессов является такое установившееся состояние:
Рис. 8
Прошу обратить внимание на рис. 4 и рис. 8. Как видно, характер входящего трафика существенно меняется. В этом случае наш резервный канал стал если не основным, то далеко не резервным. Как исправить ситуацию? Для возвращения на круги своя можно положить/поднять сессию с партнером (AS-E), но метод далеко не научный.
Небольшой подитог: я хотел продемонстрировать, что иногда даже порядок установки сессий играет роль и влияет на характер трафика. Можно сказать, что случай слегка надуманный, но взят он из реальной жизни и имеет место быть.
Итог
Управления трафиком используя протокол BGP и маршрутизация между автономными системами — комплексный и интересный процесс. Количество факторов, влияющих на информационные потоки, даже больше, чем нам может показаться.
Удачной маршрутизации!
Автор: dovecot
