Написать данную статью побудило общение в кулуарах КРОС-2015, в котором обсуждались механизмы "захвата" трафика на свою сеть для его последующей продажи клиентам. Одна из идей, а именно вырезание своей AS из транзитной BGP-информации, показалась не очень реалистичной, но все же требовала осмысления и проверки. Проверка подтвердила, что такой способ реально существует и практически уже используется.
Данная статья является техническим взглядом на методы, используемые операторами для оптимизации AS-Path с целью увеличения доли продаваемого ими трафика.
Вся информация в статье взята из открытых источников и не является инсайдом ни в какой ее части. При проведении анализа использована информация со следующих ресурсов:
В борьбе за клиентов операторами сломано много копий, отгремели пиринговые войны 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 получить трафик на себя и продать его клиенту.
Итак, давайте попробуем разобраться, как это делается. Начать нужно с технического понимания, когда в 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 не увидим, хотя она есть. Это может вызывать небольшое недоумение, если не знать данный факт.
SIS-CISCO7606#sh ip bgp neighbors 213.248.0.9 advertised-routes
BGP table version is 12952075, local router ID is 172.31.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i172.31.0.0/21 172.31.255.2 100 0 i
Итак, с этим понятно. Но это еще не все. Правило приема анонса с первой 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 новый клиент с новыми доходами, пусть и не самый выгодный с точки зрения места подключения, но все же.
Риски не так очевидны потому, что они отложены во времени. Я вижу два:
Первый и главный риск - потерять прямой трафик своих собственных клиентов. Если клиент включен одновременно и в магистрала и в pipex, то при равном AS-PATH, а в этом случае он будет именно таким, в игру вступают другие атрибуты. В этом случае даже не обязательно бить сеть на специфики. Достаточно задать origin code – incomplete для менее предпочтительного маршрута, чтобы получить трафик через более дешевую пиринговую связность. Как защитится от этого? Естественно через LocalPref, сделав его для pipex меньше, чем для всех остальных клиентов, но больше пирингового. В этом случае трафик будет отправлен клиенту сразу, если есть прямая сессия. Если прямой сессии нет, то трафик уйдет без проблем в сторону pipex, которую последний и оплатит.
Однако защита своих коммерческих интересов с помощью LocalPref не столь крепка, ведь против LP есть специфики (More specific routes) и с ними магистрал уже ничего сделать не сможет. Конечный оператор получит искомый трафик от pipex, если захочет. И по минимальной цене, оставив магистралу роль дорогого бэкапа, что при наличии тарификации берст сделать весьма не сложно ☺.
Второй риск – ценовая конкуренция за клиента. Ведь конечный оператор может использовать возможность получить трафик от pipe-ix, как инструмент давления на своего аплинка. Впрочем, этот риск я пока воздержусь комментировать. Станет ли повсеместное внедрение новой услуги фактором изменения цены на региональном операторском рынке? Этот вопрос я оставлю для обсуждения с читателями.
Итак, техническая возможность нового BGP мироустройства есть, драйверы его внедрения понятны, кандидаты намечены. Попробуем посмотреть внутрь сетей.
Для анализа я взял трех кандидатов (W-IX, Data-IX, Cloud-IX) и попробовал проанализировать анонсы их участников. Методика будет понятна из первого примера.
Берем список участников одного из pipex’ов - W-IX. Берем первого участника, кто попадется, и изучаем его апстримы:
Через куратор проверим, кто анонсит его в мир:
Берем AS I-home – A25478 и проверяем там же его аплинков:
Видим пересечение по 3-м из них: ТТК, Раском и Телия. Теперь на lg.rascom.ru проверяем префикс данного клиента:
show bgp ipv4 unicast 37.26.232.1
Thu Jun 4 12:58:14.923 MSK
BGP routing table entry for 37.26.232.0/21
Versions:
Process bRIB/RIB SendTblVer
Speaker 568048833 568048833
Last Modified: Nov 8 13:07:25.422 for 29w4d
Paths: (10 available, best #2)
Path #2: Received by speaker 0
57662
85.112.122.43 from 85.112.122.1 (85.112.122.1)
Origin IGP, metric 0, localpref 99, valid, external, best, group-best, multipath, import-candidate
Received Path ID 0, Local Path ID 1, version 568048833
Community: 20764:1440 20764:1460 20764:1470 20764:1500 20764:1530 20764:1550 20764:3002 20764:3011 20764:3021 20764:3136 25478:1000
Origin-AS validity: not-found
Что видим? Клиентская AS анонсируется с некой пиринговой сети, Next-hop там сразу клиентский стоит. Local Pref – 99 (Customer 100 – 1). Наличие Community c AS I-Home. Чтобы окончательно убедиться, что Раском отдает эту сеть своему аплинку Level3 – смотрим на его LG:
BGP Routing table entry for 37.26.232.0/21
Paths: (2 available, best #1)
20764 57662
AS-path translation: 37.26.232.0/21
None (metric 0)
Community: Lclprf_100 Backbone_2 Level3:10725 Frankfurt Germany Europe Level3_Customer 20764:1440 20764:1460 20764:1470 20764:1500 20764:1530 20764:1550 20764:3002 20764:3011 20764:3021 20764:3136 25478:1000 Cluster : No
Origin: IGP, metric 0, localpref 100, Used Valid Best IGP Group-Best
Originator: None
Думаю, можно не комментировать. Level3 принял клиентский анонс и сделал его бэстом с достаточно коротким AS-Path. Ну, разве, что community по дороге стоило зачистить. ;)
Давайте посмотрим на ТТК. Вот с их LG.
Thu Jun 4 13:23:36.556 UTC
BGP routing table entry for 37.26.232.0/21, Route Distinguisher: 20485:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 950080862 950080862
Local Label: 16028
Last Modified: May 21 13:22:39.804 for 2w0d
Paths: (6 available, best #1)
Advertised to update-groups (with more than one peer):
0.2 0.4
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2 0.4
85.112.122.43 from 85.112.122.1 (85.112.122.1)
Origin IGP, metric 1000, localpref 99, valid, external, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 950080862
Community: 20485:11799
Extended community: RT:20485:1
Картина та же: с того же RS анонс, да и NEXT-HOP совпадает. Опять LocalPref 100-1. Проверяем этот анонс на пире ТТК Мегафоне. Он там есть и он там бэстом.
inet.0: 545696 destinations, 2219897 routes (543847 active, 4 holddown, 4234 hidden)
37.26.232.0/21 (6 entries, 1 announced)
*BGP Preference: 170/-281
Next hop type: Indirect
Address: 0x4b998b58
Next-hop reference count: 43860
Source: 10.222.253.253
Next hop type: Router, Next hop index: 2097311
Next hop: 83.169.204.25 via ae11.0, selected
Label operation: Push 4097
Label TTL action: no-prop-ttl
Session Id: 0x4cd
Next hop: 83.169.204.33 via ae22.0
Label operation: Push 4321
Label TTL action: no-prop-ttl
Session Id: 0x4ce
Protocol next hop: 10.222.253.177
Indirect next hop: 26c34938 2098630 INH Session ID: 0x242
State: <Active Int Ext>
Local AS: 31133 Peer AS: 31133
Age: 2w0d 0:03:45 Metric2: 200
Validation State: unverified
Task: BGP_31133.10.222.253.253+???
Announcement bits (5): 0-KRT 2-RT 8-BGP_RT_Background 9-Resolve tree 4 10-Resolve tree 6
AS path: 20485 57662 I (Originator)
Cluster list: 10.222.253.253
Originator ID: 10.222.253.177
AS path: Recorded
Communities: 20485:11799 31133:200 31133:300 31133:46090 target:20485:1
Accepted Multipath
Localpref: 280
Router ID: 10.222.253.253
Ну, и Телия в Москве.
inet.0: 598479 destinations, 2406022 routes (598463 active, 172 holddown, 90 hidden)
+ = Active Route, - = Last Active, * = Both
37.26.232.0/21 *[BGP/170] 3w4d 13:12:43, MED 0, localpref 200, from 85.112.122.1
AS path: 57662 I, validation-state: unverified
> to 85.112.122.43 via ae5.888
[BGP/170] 3w4d 13:12:34, MED 0, localpref 200, from 85.112.122.2
AS path: 57662 I, validation-state: unverified
> to 85.112.122.43 via ae5.888
О чем это свидетельствует? О том, что новое BGP-мироустройство уже действует. Telia, ТТК и Раском – формально апстримы I-HOME, но фактически их участие прозрачно с точки зрения BGP.
Можно сделать вывод, что схема не такая уж тайная, коль 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 с хорошим конкурентным преимуществом. Остальным же можно посоветовать спросить у своих аплинков "А что! Так можно было?"
Материал:
Написать данную статью побудило общение в кулуарах КРОС-2015, в котором обсуждались механизмы «захвата» трафика на свою сеть для его последующей продажи клиентам. Одна из идей, а именно: вырезание своей AS из транзитной BGP информации, показалась не очень реалистичной, но все же требовала осмысления и проверки. Проверка подтвердила, что такой способ реально существует и практически уже используется.
Полный текст
Приветствую.
Конечно эта схема "ломает" привычные устои и протокол BGP, который по сути является основой глобальной маршрутизации... На мой взгляд один из недостатков схемы PIPEX - в том, что оператора, идущего на клиента, включенного в PIPEX по сути лишают возможности выбора по длине маршрута. И имея сильно распределенный PIPEX может так сложиться, что у оператора будет побеждать маршрут через Амстердам, несмотря на наличие пиринга в Москве, потому что там путь может сказаться короче. Словом создание "мнимого L2" на половину земного шара кончится плохо и операторам придется искать другие пути... Собственно говоря схема с "выкусыванием" AS из AS_PATH появилась по просьбе IX сообщества с целью создания "прозрачных" классических точек обмена.. А в итоге вышло все совсем иначе...
идея "прозрачного BGP" хорошо ложится на идею колхоза
но в итоге из-за жадности председателя колхоза это может привести к плохим последствиям для связности =(
А кто подскажет, как при таком подключении считают/ограничивают арендуемую ёмкость канала? В общем влане для такого ж уже надо как-то заморачиваться.
Вообще-то IX по жизни прозрачен, потому как формально L2-структура :)
А прозрачность нужна для RS-ов. Которые участвуют в обмене маршрутами, но никак не в форвардинге трафика. Так что с этой точки зрения всё честно. В отличие от случая колхозных апстримов imho. Есть определённые сомнения, что кто-то из перечисленных в статье магистралов в курсе, что он обеспечивает связность всем поголовно участникам какой-либо точки обмена трафиком
Evd, не сомневайся. Апстримы в курсе. Они же снимали проверку с анонсов пайпикса.
Почитал статью, категорически не согласен с мнением автора.
Pipe-IX это IX предоставляющий трубу до других IX в которые он включен.
Автор же пишет:
Скажу только по поводу DataIX(почему сравнение с Pipe-IX некорректно) - Мы с самого начала строили свой собственный, нейтральный IX, который потом вырос в IXN (internet exchange network).
В нашей сети нет трафика с DE-CIX, NY-IX, AMS-IX и т.п точек обмена трафиком - есть только трафик бегающий только между нашими участниками.
Это нормальная работа роутсервера, он никогда не добавляет свою 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 написана чья-то другая, просто прочтите этот текст еще раз.
>.. и редистрибутим из OSPF в BGP...
Это уже Бангладеш-телеком получится.
Не поверишь - встречается и такое.
Ну а /23 дробленые на /32 уже даже не вызывают улыбку.
Тема названа неверно как то , "методы оптимизации AS-Path"... лучше "методы кастрации AS-Path".