Техника

Техника

/

Участник IX должен выполнять следующие условия:

•‎ явно указать скорость порта: 1Ge / 10Ge / 40Ge / 100Ge, а также тип используемого модуля: 1000Base-T, 1000Base-LX, 10000Base-LR/ER, QSFP 40Ge-LR4/ER4, QSFP28 100Ge-CWDM4/LR4/ER4;
•‎ иметь номер автономной системы — AS;
•‎отражать информацию о политике маршрутизации своей AS и записи о префиксах (route-object) в RIPE NCC;
•‎при приеме анонсов от rs анонсировать rs свои сети в соответствии с отраженной в RIPE Routing Policy. Это необходимо для исключения несимметричного трафика;
•‎ отключить Proxy ARP, Spanning Tree, IP redirects, протоколы канального уровня (LLDP и др.) и протоколы производителей оборудования, инициирующие рассылку посторонних Ethernet-фреймов (CDP, Layer 2 keepalive и др.), исключая протокол LACP (в случае подключения по технологии EtherChannel);
•сообщить используемые mac-адреса;
•‎использовать только выданные Piter-IX ip-адреса;
•‎не анонсировать ip-адреса Piter-IX другим операторам;
•не анонсировать в Piter-IX сети клиентов без согласия владельца

Условия подключения и настройки портов

Для реализации политики связности в каждой географической точке присутствия Piter-IX размещены два сервера обмена маршрутами (Route Server), c которыми участники настраивают взаимодействие по протоколу BGP.

Для более детальной настройки используется Личный кабинет участника.

В Личном кабинете участник может:
•‎ напрямую указать всех, с кем хочет обмениваться анонсами
или
•‎ сформировать черный или белый список, с учетом которого строится конфигурация обоих Route Server для каждой локации

Route server. Описание использования

Параметры для настройки bgp-сессий с Route Servers

Для быстрой смены активных маршрутов в случае падения интерфейса или bgp-сессии используется протокол BFD.
Протокол активирован по умолчанию для всех участников.

Параметры:

• интервалы 1000-2000 ms
• множитель 5
• без эхо-мода, без пассивного режима

Если возникли вопросы по BFD, свяжитесь, пожалуйста, с менеджером: noc@piter-ix.ru

Использование BFD

В качестве первичного механизма защиты от DDoS-атак мы используем механизм Blackhole Community.
Это перенаправление трафика на атакуемые адреса с интерфейса участника на систему фильтрации или «в /dev/null» — так называемую «черную дыру».

• Анонсируйте на роут-серверы любой /32, входящий в подсети Вашего as-set, с community 65 535:666.
• Так Вы перекроете поступление трафика от участников на этот /32.
• Чтобы это срабатывало в случае исходящих атак с Вашей стороны, разрешите на своих бордерах приём связки /32+65 535:666 от наших R/S.

Защита от DDoS-атак методом Blackholing

При анонсе своих маршрутов в сторону роут-серверов Вы можете дополнительно пометить их нашими BGP сommunity.
BGP сommunity — это 32-битное число, записываемое обычно как пара 16-битных, разделенных знаком «:». Например «1:6939». Таких кодов может быть сразу несколько.

Комбинируя их, Вы управляете трафиком, прибывающим в вашу сторону от участников.
Как это работает?

Пример 1

1. Вы решили запретить анонс в сторону некоторого участника с автономной системой номер 64 519
2. Применили для этого «0:64 519».
3. Роут-сервер при экспорте вашего маршрута в asn 64 519 «увидит», что есть блокирующее community, и отбросит его.
4. В результате AS 64 519 не будет «знать» о Ваших сетях, трафик от этого участника к Вам не поступит.

Пример 2
Как быть с ASN в 32-битном диапазоне? Ведь в код community помещается лишь 16 бит.
Ответ на этот вопрос — AsnID (AID)-маппинг 16/32 бит. Вы найдете актуальный перечень AID в RIPE/AS50817 (whois as50817).
Там же представлены прочие управляющие и информационные community: группы, локации, препенды, локалпрефы и т. д.

BGP-communities