Вернуться к старой версии портала ПЕРЕЙТИ
Оставить отзыв
  1. Статьи
Заметки пользователей
09.11.2018 08:40
PDF
6871
34

Игры с анонсами less specific и more specific, или из-за чего страдают клиенты

К написанию данной статьи меня сподвигли участившиеся случаи обращения сторонних провайдеров с проблемами о недоступности части ресурсов отдельных наших клиентов.

Суть подобных проблем довольно проста, и заключается в желании клиентов получать более дешевый трафик с обменников с одной стороны, и нежелании ISPs осуществлять транзит трафика своих клиентов по схемам Uplink-->ISP-->IX-->Client, Uplink-→ISP-→Uplink-→Client, IX-→ISP-→IX-→Client, IX-→ISP-→Uplink-→Client с другой стороны.

Рассмотрим один из возможных вариантов на нижеприведенном рисунке.

Multihomed Client, имеющий подключения к ISP и IX, анонсирует менее специфичный префикс 172.16.0.0/16 своему ISP и более специфичный 172.16.0.0/24 на обменник. ISP принимает клиентский более специфичный маршрут 172.16.0.0/24 от IX, так как тоже является его участником. Принимаемый непосредственно от клиента префикс 172.16.0.0/16 ISP анонсирует своим аплинкам, не являющимися участниками пиринга на IX (как правило, это Tier1, или национальные Операторы, полностью отсутствующие на IX-ах, или присутствующие там со значительными ограничениями маршрутных политик). В результате подобной "кривизны" в анонсах трафик, предназначенный Client, из сетей Tier1 попадает в сеть ISP, откуда должен доставляться клиенту через IX по более специфичному маршруту 172.16.0.0/24, который будет всегда активным в сравнении с менее специфичным.

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

Какие существуют способы борьбы с подобными явлениями на сетях ISPs? Самым простым покажется фильтрация более специфичного префикса на сети ISP. На самом деле это далеко не так. Основной его проблемой является то, что подобные аномалии не являются статичными и их необходимо каким-то образом выявлять.

Другим, более распространенным способом, применяемым в сетях крупных ISPs, является выявление подобного трафика и его drop на форвардинге. Рассмотрим данный способ более подробно с примерами конфигурации для оборудования Juniper. Основной смысл его заключается, что префиксы, принимаемые от Uplinks и IXs, раскрашиваются BGP communities, на основании которых формируется, знакомый многим по предыдущим публикациям, destination-class. Сформированный destination-class и интерфейсы включения Uplinks и IXs являются основными критериями match для firewall фильтра с опцией then discard, который применяется на форвардинге.

Ниже приведены примеры конфигурации с короткими аннотациями:

1) Создаются community для раскраски принимаемых анонсов от аплинков и обменников:

set policy-options community mark-tier1_1 members 65001:30203
set policy-options community mark-tier1_2 members 65001:30204
set policy-options community mark-ix members 65001:20204

2) Созданные community включаются в policy, которое, в свою очередь, применяется на import в конфигурации протокола BGP для соответствующих групп аплинков и обменников:

set policy-options policy-statement mark-tier1_1 term mark-upstream then community add mark-tier1_1
set policy-options policy-statement mark-tier1_2 term mark-upstream then community add mark-tier1_2
set policy-options policy-statement mark-ix term mark-upstream then community add mark-ix

3) Создается community для определения ранее раскрашенных маршрутов:

set policy-options community type_peer-and-upstream members "^65001:[2,3]....$"

4) По определяющему community с помощью policy формируется destination-class:

set policy-options policy-statement set-class term peer-and-upstream from protocol bgp
set policy-options policy-statement set-class term peer-and-upstream from community type_peer-and-upstream
set policy-options policy-statement set-class term peer-and-upstream then destination-class peer-and-upstream

5) Policy с destination-class применяется на export для forwarding-table:

set routing-options forwarding-table export set-class

6) Создается firewall filter, основными критериями которого являются сформированный ранее destination-class и интерфейсы включения аплинков и обменников, а в качестве action данного фильтра discard и подсчет пакетов:

set firewall filter forward_firewall term drop-peers-to-other-peer from destination-class peer-and-upstream
set firewall filter forward_firewall term drop-peers-to-other-peer from interface ae7.0
set firewall filter forward_firewall term drop-peers-to-other-peer from interface ae6.0
set firewall filter forward_firewall term drop-peers-to-other-peer from interface ae5.0
set firewall filter forward_firewall term drop-peers-to-other-peer then count peers-to-other-peers-drop
set firewall filter forward_firewall term drop-peers-to-other-peer then discard
set firewall filter forward_firewall term any then accept

7) Созданный фильтр применяется на форвардинге:

set forwarding-options family inet filter output forward_firewall

Посмотреть срабатывание счетчиков данного фильтра можно командой:

> show firewall filter forward_firewall
Filter: forward_firewall
Counters:
Name Bytes Packets
peers-to-other-peers-drop 14704283695 182675892
{master}

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

34 комментариев
BanZ4y
BanZ4y
Спасибо за статью. Насколько я понимаю, основная идея просто дропать транзитный трафик upstream-upstream ix-ix upstream-ix При этом мы по прежнему платим за входящий трафик который мы дропнем. Понятно, что он не большой т.к. там ничего не работает. Но при отсутствии lg клиент не понимает в чем дело и просто уводит трафик на другого isp. По чему бы, все таки не фильтровать маршруты своих клиентов от ix и upstream ? понятно, что они могут меняться, но в as-path AS client то будет. Выделять все маршруты полученные от ix и upstreams с AS Client и дропать или удалять с forwafding-tabel. При таком подходе и у клиента все работает и провайдер в плюсе или есть какие то вилы ?
vurd
vurd

Понять схему по set-ам тяжеловато, подскажите что будет при наличии таких фильтров если клиент уберет анонс своего /16 на стыке с isp, оставив его на ix?

P.S. Не принимать маршруты клиента с ix? Да не, бред какой-то, так он все поймет. Лучше в тихую подропать, пускай поищет почему у него что-то отъехало.

BanZ4y
BanZ4y
Зачем вам схема по set ? Если клиент уберет анонс в isp, то isp перестанет анонсить выше и трафика клиента не будет в обще. Бред ?, я думаю это самое разумное, что он поймет ? Да и как он поймет ? все равно это ваше право как isp. Если дропать, он ничего искать не будет просто напишет вам заявку, о чем автор и говорит. А вы будите ему объяснять какой он нехороший...
SyJet
SyJet

Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее.

BanZ4y
BanZ4y
Мы тут хотим уйти от ручной работы, а вы нас в каменный век...
tec1
tec1

Попытаюсь дополнить здесь содержимое статьи, заодно прокомментировать обсуждение.
Скрытой нитью в статье отражается преднамеренность подобных действий со стороны клиента, что подвтерждается и на практике. Наверное, только одна десятая из всех случаев - ошибка администрирования. Какой смысл отдавать более специфичный маршрут на обменник, при этом анонсировать менее специфичный своему аплинку? Почему нельзя аносировать во все линки одинаково? Все же знают, что у всех, кто пристутствует на обменнике, Local Preference для анонсов с IX всегда выше, чем для аплинков, и поэтому трафик от участников обменника клиент будет всегда получать через обменник. Специфики здесь абсолютно не нужны. "Обьяснения о нехорошости " все клиенты безоговорочно принимают и немедленно исправляют ситуацию, что подтверждает осознанность их действий.
Фильтровать все клиенсткие анонсы с IX? Конечно нет же. Правильно выразил причину, почему этого не стоит делать, vurd. Во-первых, на каком основании? Только из-за отдельных "мудрых" клиентов? Во-вторых, да, действительно, что произойдет, если клиент снимет анонс с вас (своего аплинка), оставит его только через IX, и вы его отфильтруете? В лучшем случае вы его увидите в FV от своих апстримов и весь ваш трафик на такие префиксы пойдет через линки с апстримами вместо обменника (экономически теряете вы же). В худшем, вы его совсем потеряете в своих таблицах, чем нарушите связность.
В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН...

 

Только что, BanZ4y сказал:

Мы тут хотим уйти от ручной работы, а вы нас в каменный век...

Все верно. Self Driving Network & Artificial Intelligence )))

tec1
tec1
15 часов назад, SyJet сказал:

Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее.

Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка.

vodz
vodz

Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами.

tec1
tec1
18 минут назад, vodz сказал:

Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами.

Почему жлобство ISP? Не клиента? Ведь ничего же не мешает отдавать свои анонсы ровно, и в IX-ы, и своим аплинкам, и не тянуть трафик тирванов через своих аплинков и обменник. Писалось же выше об этом.