vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

На краю пиринга (методы оптимизации AS-Path) 27

Дата публикации: 10.07.2015
Количество просмотров: 10967

Дисклаймер

Написать данную статью побудило общение в кулуарах КРОС-2015, в котором обсуждались механизмы "захвата" трафика на свою сеть для его последующей продажи клиентам. Одна из идей, а именно вырезание своей AS из транзитной BGP-информации, показалась не очень реалистичной, но все же требовала осмысления и проверки. Проверка подтвердила, что такой способ реально существует и практически уже используется.

Данная статья является техническим взглядом на методы, используемые операторами для оптимизации AS-Path с целью увеличения доли продаваемого ими трафика.

Вся информация в статье взята из открытых источников и не является инсайдом ни в какой ее части.  При проведении анализа использована информация со следующих ресурсов:

  • radar.qrator.net
  • ripe.net
  • cisco.com и juniper.net
  • RFC 4271
  • открытого листинга участников локальных и распределенных пиринговых систем
  • cli собственного бордера
  • открытых looking glass и route-server операторов

 

Pipe-IX

В борьбе за клиентов операторами сломано много копий, отгремели пиринговые войны 00-х, наступила эра "pipe-ix". Последние, построив инфраструктуру на "неожиданно" появившемся рынке оптического транспорта, продают недорогую распределенную, в отличие от классических IX, пиринговую связность на всей им доступной территории РФ. Распределенность pipe-ix делает их продукт более привлекательным, чем точечная пиринговая связность классических IX’ов. Благодаря этому они уже стали самостоятельным классом игроков на межоператорском рынке интернет провайдеров.

Пайпиксы, такие как W-IX, Cloud-IX и Data-IX за последние годы подключили основную массу тех клиентов, которых могли. При этом они набрали хорошую скорость и их потенциал, по крайней мере, внутренний, далеко не исчерпан. Однако емкость их рынка не так велика и при отсутствии свежих идей они неизбежно попадают на конкурентное поле настоящих магистралов, где демонстрировать дальнейший рост будет не так просто, так как в отличии от классических магистралов их канальная емкость практически полностью является арендованной.

Свежая идея нашлась в использовании уже построенной сети для предоставления клиентам распределенных IX’ ов не только пиринговой, но и полной связности, не уходя при этом из поля Distributed-IX. Упрощенно говоря, надо решить задачу: как приобрести и продать full-view, оставаясь при этом "pipe-ix".

Для этого Pipe-IX нужно добавить в пиринговую сеть апстримовую связность и остаться при этом похожим на IX, то есть прозрачным в смысле отсутствия лишнего (своего) as-hop’а между клиентами распределенной сети обмена. Сама идея несложная, но ее корректное технологическое решение делает из нее новый продукт – распределенный IX c полной связностью. И эта задача решена – транзитная сеть со своей автономной системой, полноценной маршрутизацией пакетов внутри и с взаимодействием с клиентами по BGP является прозрачной для остального мира.

Зачем это нужно тоже ясно - желание оператора сократить AS-PATH и стать более привлекательным в борьбе за клиента вполне понятно. Профиты, которые даст короткий AS-Path - это видимость более короткого маршрута к себе и своим клиентам тоже очевидны: чем короче AS-PATH, тем больше шансов при равном LocalPref получить трафик на себя и продать его клиенту.

Как "выпилить" свою AS из AS-Path

Итак, давайте попробуем разобраться, как это делается. Начать нужно с технического понимания, когда в BGP добавляется своя автономная система. Я думаю, что многие знают, что в BGP своя AS добавляется к исходящему анонсу, вернее должна добавляться, чтобы взаимодействующие операторы по принимаемым от сопредельных сетей AS-Path’ам могли по полным данным оценить выгодность и целесообразность тех или иных маршрутов для выбора лучших путей передачи пакетов данных.

Информация о своей AS должна добавляться в исходящие анонсы. Для сомневающихся ниже приведена пара выдержек из RFC 4271 (первая о транзите анонса и вторая об оригинации оного) для EBGP.

If the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message).

When a BGP speaker originates a route then: the originating speaker includes its own AS number in a pathsegment, of type AS_SEQUENCE, in the AS_PATH attribute of all UPDATE messages sent to an external peer.  In this case, the AS number of the originating speaker"s autonomous system will be      the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute.

Кстати тут есть забавный хинт. Если смотреть на Cisco или Juniper-анонсы, которые мы объявляем, то там мы свою AS не увидим, хотя она есть. Это может вызывать небольшое недоумение, если не знать данный факт.

 

 

Итак, с этим понятно. Но это еще не все. Правило приема анонса с первой AS отличной от AS пира, не регламентированы в RFC, то есть отданы на усмотрение вендорам. Cisco не примет его, если первой в AS-PATH будет не AS пира, а какая-то другая. Об этом нам может сказать cisco.com

By default, the software requires the first autonomous system (in the AS path) of a route received from an eBGP peer to be the same as the remote autonomous system configured.

Вот здесь уже без удаленного пира не обойтись. Для того чтобы обойти это правило на Cisco (XR) есть команда. Впрочем, на IOS она тоже есть с немного другим синтаксисом:

enforce-first-as disable

Для Juniper же наоборот дефолтным является поведение, при котором такая проверка отсутствует. Включить ее можно командой:

bgp enforce-first-as

Данная опция не является новым словом в BGP и уже давно успешно применяется в классических IX, для которых она и была создана.

Пиринг без границ

Получается, что технически "выпиливание" из AS Path информации о своей автономной системе возможно при согласии взаимодействующих сторон.

Со стороны клиентов распределенных IX’ов это не вызывает вопросов и проблем – IX анонсирует им всех своих участников "напрямую". Так и должен поступать IX, чтобы быть привлекательным.

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

Отсутствие такой проверки означает, что анонс клиентов pipe-IX появится в мире без AS транзитного провайдера и условный Distributed-IX может остаться таковым, но при этом анонсировать своего клиента в мир от имени своего аплинка и получить существенный прирост трафика через себя.

Если распределенный IX сумеет убедить классического магистрала, продать ему недорого Full-View для обслуживания "не своих" анонсов, то путь к новому транзитному мироустройству открыт.

Возникает резонный вопрос, что выигрывает классический магистрал от такой сделки с распределенным IX’ом, а что проигрывает.

Выигрыш прост и сразу виден – Pipex новый клиент с новыми доходами, пусть и не самый выгодный с точки зрения места подключения, но все же.

Риски не так очевидны потому, что они отложены во времени. Я вижу два:

  1. Возрастание вероятности потерять текущих собственных клиентов и не включить новых потенциальных;
  2. Усиление конкурентного давления на цены в регионах.

Первый и главный риск - потерять прямой трафик своих собственных клиентов. Если клиент включен одновременно и в магистрала и в pipex, то при равном AS-PATH, а в этом случае он будет именно таким, в игру вступают другие атрибуты. В этом случае даже не обязательно бить сеть на специфики. Достаточно задать origin code – incomplete для менее предпочтительного маршрута, чтобы получить трафик через более дешевую пиринговую связность. Как защитится от этого? Естественно через LocalPref, сделав его для pipex меньше, чем для всех остальных клиентов, но больше пирингового. В этом случае трафик будет отправлен клиенту сразу, если есть прямая сессия. Если прямой сессии нет, то трафик уйдет без проблем в сторону pipex, которую последний и оплатит.

Однако защита своих коммерческих интересов с помощью LocalPref не столь крепка, ведь против LP есть специфики (More specific routes) и с ними магистрал уже ничего сделать не сможет. Конечный оператор получит искомый трафик от pipex, если захочет. И по минимальной цене, оставив магистралу роль дорогого бэкапа, что при наличии тарификации берст сделать весьма не сложно ☺.

Второй риск – ценовая конкуренция за клиента. Ведь конечный оператор может использовать возможность получить трафик от pipe-ix, как инструмент давления на своего аплинка. Впрочем, этот риск я пока воздержусь комментировать. Станет ли повсеместное внедрение новой услуги фактором изменения цены на региональном операторском рынке? Этот вопрос я оставлю для обсуждения с читателями.

Итак, техническая возможность нового BGP мироустройства есть, драйверы его внедрения понятны, кандидаты намечены. Попробуем посмотреть внутрь сетей.

О чем говорит BGP

Для анализа я взял трех кандидатов (W-IX, Data-IX, Cloud-IX) и попробовал проанализировать анонсы их участников. Методика будет понятна из первого примера.

Берем список участников одного из pipex’ов - W-IX. Берем первого участника, кто попадется, и изучаем его апстримы:

Через куратор проверим, кто анонсит его в мир:

Берем AS I-home – A25478 и проверяем там же его аплинков:

Видим пересечение по 3-м из них: ТТК, Раском и Телия. Теперь на lg.rascom.ru проверяем префикс данного клиента:

 

 

Что видим? Клиентская AS анонсируется с некой пиринговой сети, Next-hop там сразу клиентский стоит. Local Pref – 99 (Customer 100 – 1). Наличие Community c AS I-Home. Чтобы окончательно убедиться, что Раском отдает эту сеть своему аплинку Level3 – смотрим на его LG:

 

 

Думаю, можно не комментировать. Level3 принял клиентский анонс и сделал его бэстом с достаточно коротким AS-Path. Ну, разве, что community по дороге стоило зачистить. ;) 

Давайте посмотрим на ТТК. Вот с их LG.

 

 

Картина та же: с того же RS анонс, да и NEXT-HOP совпадает. Опять LocalPref 100-1. Проверяем этот анонс на пире ТТК Мегафоне. Он там есть и он там бэстом.

 

 

Ну, и Телия в Москве.

 

 

О чем это свидетельствует? О том, что новое BGP-мироустройство уже действует. Telia, ТТК и Раском – формально апстримы I-HOME, но фактически их участие прозрачно с точки зрения BGP.

Transit-IX

Можно сделать вывод, что схема не такая уж тайная, коль 3 аплинка согласились сделать нетрадиционные настройки для своего клиента. И то, что реальный трафик с сети наших тирванов идет через W-IX, это уже серьезный бизнес-драйвер для привлечения/удержания клиентов и конкурировать с таким провайдером классическому агрегатору будет совсем непросто. Более того, в том, что данные изыскания являются секретом Полишинеля, говорит тот факт, что на сайте i-home.ru данная услуга анонсирована как вполне полноценный дополнительный сервис к w-ix. Вот выдержка оттуда:

Услуга предоставляет собой аналог пиринговой площадки (L2 транспорт), участники которой находятся в общем VLAN. Обмен маршрутной информацией осуществляется через RS, что позволяет не устанавливать индивидуальные BGP сессии между отдельными участниками. На одной площадке присутствуют как операторы-клиенты, так и провайдеры верхнего уровня, предоставляющие полную таблицу маршрутизации (full view).

К сожалению, ссылка на подробное описание услуги недоступна, но работоспособность данной схемы взаимодействия не вызывает никаких сомнений, и ТТК с Телией можно смело записать в участники Inet2. Раском же заявлен как участник W-IX, что подразумевает более сложные отношения с пиринговой сетью.

А что другие? А ничего.:) Я не нашел явных доказательств наличия такой схемы у Cloud-IX и Data-IX для анонсирования своим аплинкам, хотя слышал, что они также могут ее реализовать, может мало примеров посмотрел. Что я увидел, так это то, что Cloud-IX анонсирует свою пиринговую сеть как клиентский префикс в сторону Cogent, что еще не дает возможность включать аплинка в свою пиринговую сеть, но теоритически это возможно.

Если же конкуренты действительно не играют в эти игры, (если вы знаете, кто играет, напишите на форуме), то остается поздравить W-IX с хорошим конкурентным преимуществом. Остальным же можно посоветовать спросить у своих аплинков "А что! Так можно было?"

 
От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/27766/na-krayu-piringa-metodyi-optimizatsii-as-path-.html

Комментарии:(27) комментировать

10 июля 2015 - 17:09
Robot_NagNews:
#1

Материал:
Написать данную статью побудило общение в кулуарах КРОС-2015, в котором обсуждались механизмы «захвата» трафика на свою сеть для его последующей продажи клиентам. Одна из идей, а именно: вырезание своей AS из транзитной BGP информации, показалась не очень реалистичной, но все же требовала осмысления и проверки. Проверка подтвердила, что такой способ реально существует и практически уже используется.

Полный текст


10 июля 2015 - 17:09
alex213:
#2

Приветствую.

Конечно эта схема "ломает" привычные устои и протокол BGP, который по сути является основой глобальной маршрутизации... На мой взгляд один из недостатков схемы PIPEX - в том, что оператора, идущего на клиента, включенного в PIPEX по сути лишают возможности выбора по длине маршрута. И имея сильно распределенный PIPEX может так сложиться, что у оператора будет побеждать маршрут через Амстердам, несмотря на наличие пиринга в Москве, потому что там путь может сказаться короче. Словом создание "мнимого L2" на половину земного шара кончится плохо и операторам придется искать другие пути... Собственно говоря схема с "выкусыванием" AS из AS_PATH появилась по просьбе IX сообщества с целью создания "прозрачных" классических точек обмена.. А в итоге вышло все совсем иначе...


10 июля 2015 - 17:33
cmhungry:
#3

идея "прозрачного BGP" хорошо ложится на идею колхоза
но в итоге из-за жадности председателя колхоза это может привести к плохим последствиям для связности =(


10 июля 2015 - 18:30
OKyHb:
#4

А кто подскажет, как при таком подключении считают/ограничивают арендуемую ёмкость канала? В общем влане для такого ж уже надо как-то заморачиваться.


10 июля 2015 - 21:07
evd:
#5

Просмотр сообщенияalex213 (10 июля 2015 - 16:09) писал:

Собственно говоря схема с "выкусыванием" AS из AS_PATH появилась по просьбе IX сообщества с целью создания "прозрачных" классических точек обмена...


Вообще-то IX по жизни прозрачен, потому как формально L2-структура :)

А прозрачность нужна для RS-ов. Которые участвуют в обмене маршрутами, но никак не в форвардинге трафика. Так что с этой точки зрения всё честно. В отличие от случая колхозных апстримов imho. Есть определённые сомнения, что кто-то из перечисленных в статье магистралов в курсе, что он обеспечивает связность всем поголовно участникам какой-либо точки обмена трафиком


11 июля 2015 - 0:52
Клава Маус:
#6

Evd, не сомневайся. Апстримы в курсе. Они же снимали проверку с анонсов пайпикса.


11 июля 2015 - 4:03
Denis Samsonov:
#7

Почитал статью, категорически не согласен с мнением автора.
Pipe-IX это IX предоставляющий трубу до других IX в которые он включен.
Автор же пишет:

Цитата

Пайпиксы, такие как W-IX, Cloud-IX и Data-IX


Скажу только по поводу DataIX(почему сравнение с Pipe-IX некорректно) - Мы с самого начала строили свой собственный, нейтральный IX, который потом вырос в IXN (internet exchange network).
В нашей сети нет трафика с DE-CIX, NY-IX, AMS-IX и т.п точек обмена трафиком - есть только трафик бегающий только между нашими участниками.

Цитата

Как "выпилить" свою AS из AS-Path


Это нормальная работа роутсервера, он никогда не добавляет свою AS в AS-PATH, а так-же не маршрутизирует трафик между участниками IX. Прямая обязанность RS сообщить соседям Б и С что маршрут на сети соседа А пролегает через его IP в пиринговом vlan-е IX. Дальше бордеры участников взаимодействую по L3 напрямую между собой, на стороне IX остается только коммутация(L2)

Рецепт как для Pipe-IX как подробить клиентские префиксы с /20 до /32 прилагать не буду, кому надо и так это знают (/33 это не полайпишника) ;)
Дам только рецепт для "особо безбашенных".
1) поднимаем BGP сессию между участником IX и маршрутизатором (в качестве него может выступать L3 свитч с BGP)
2) поднимаем OSPF между всеми маршутизаторами в сети
3) поднимаем BGP сессию с другим IX и редистрибутим из OSPF в BGP, анонсируя чужие префиксы от своей ASN
4)...(в AS-PATH остается вместо AS123 AS456 => AS456
5) PROFIT!!!

как это проверить - заходите на looking glass того-же de-cix или ams-ix, вбиваете свой префикс и смотрите на AS-PATH.
Если в на lg ваш префикс присутсвует, а в AS-PATH вместо вашей AS написана чья-то другая, просто прочтите этот текст еще раз.


11 июля 2015 - 4:09
Atlant:
#8

>.. и редистрибутим из OSPF в BGP...
Это уже Бангладеш-телеком получится.


11 июля 2015 - 4:25
Denis Samsonov:
#9

Просмотр сообщенияAtlant (11 июля 2015 - 03:09) писал:

>.. и редистрибутим из OSPF в BGP...
Это уже Бангладеш-телеком получится.


Не поверишь - встречается и такое.
Ну а /23 дробленые на /32 уже даже не вызывают улыбку.


11 июля 2015 - 5:31
Alexandr N:
#10

Тема названа неверно как то , "методы оптимизации AS-Path"... лучше "методы кастрации AS-Path".


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться