Участник IX должен выполнять следующие условия:
- явно указать тип подключаемого порта: 1000BaseT, 1000BaseFX, 10000BaseF или 40GBase-LR4;
- иметь номер автономной системы – AS;
- отражать информацию о политике маршрутизации своей AS и записи о префиксах (route-object) в RIPE NCC;
- при приеме анонсов от rs анонсировать rs свои сети в соответствии с отраженной в ripe routing policy для исключения появления несимметричного трафика;
- отключить ARP proxy, Spanning tree, IP redirects, протоколы канального уровня (LLDP и др.) и протоколы производителей оборудования, инициирующие рассылку посторонних Ethernet-фреймов (CDP, Layer 2 keepalive, и др.), исключая протокол LACP в случае подключения по технологии EtherChannel;
- сообщить используемые им mac-адреса;
- использовать только выданные PITER-IX ip-адреса;
- не анонсировать ip-адреса PITER-IX другим операторам;
- не анонсировать в PITER-IX сети клиентов без согласия владельца.

Описание использования route-server

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

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

Для быстрой смены активных маршрутов в случае падения интерфейса или bgp-сессии используется протокол BFD; Активирован по-умолчанию для всех участников. Параметры: интервалы 750 ms, множитель 5. В случае вопросов по BFD свяжитесь пожалуйста с noc@piter-ix.ru.

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

В качестве первичного механизма защиты от DDos-атак в Piter-IX используется механизм blackhole-community - перенаправление трафика на атакуемые адреса с интерфейса участника на систему фильтрации или "в /dev/null". Анонсируйте на роут-серверы любой /32 входящий в подсети из вашего as-set, с коммьюнити 65535:666 - так вы перекроете поступление трафика от участников на этот /32. Чтобы это срабатывало в случае исходящих атак с вашей стороны разрешите на своих бордерах приём связки /32+65535:666 от наших R/S.

BGP Communities

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