Participants of IX must fulfill the following conditions:
- explicitly specify the type of port: 1000BaseT, 1000BaseFX, 10000BaseF 40GBase-LR4 or 100G;
- have an Autonomous System number – AS;
- reflect information about the AS routing and announcing prefixes (route-object) in RIPE NCC;
- when receiving announces from rs, announce their prefixes to the rs in accordance with the ripe routing policy reflected in order to exclude the appearance of asymmetric traffic;
- disable ARP proxy, spanning tree, IP redirects, channel Link Layer Discovery Protocols (LLDP, etc.) and protocols of equipment manufacturers that initiate the distribution of extraneous Ethernet frames (CDP, Layer 2 keepalive, etc.), excluding LACP protocol in case of connection using EtherChannel technology;
- report your router’s addresses;
- use only the IP addresses provided by PITER-IX;
- do not announce PITER-IX IP addresses to other telecom operators;
- do not announce networks of customers without the consent of the owners within PITER-IX.

Description of using route-server

To implement the connectivity policy in Piter-IX, two route-servers are located at each geographical point of presence (POP), with which [participants] IX members configure interaction over the BGP protocol. For more detailed configuration, the [participant's] member’s personal account is used, where everyone can either directly specify everyone with whom they want to exchange announcements, or create a black or white list, taking into account which the configuration of both route-servers is built for each location.

Using Bidirectional Forwarding Detection (BFD)

The BFD protocol is used to quickly change active routes in the event of an interface or a BGP session down; It is activated by default for all participants. Parameters: intervals of 750 ms, multiplier 5. If you have any questions about BFD, please contact noc@piter-ix.ru.

Protection against DDoS attacks by Blackholing

As the primary mechanism of protection against DDoS attacks in Piter-IX, the blackhole-community mechanism is used - redirecting traffic to the attacked addresses from the participant's interface to the filtering system or "to /dev/null". Announce to the router servers any /32 included in the subnet from your as-set, with the community 65535:666 - so you block the traffic from the participants to this /32. So that it works in case of outgoing attacks from your border, allow the reception of the bundle /32+65535:666 from our route servers.

BGP Communities

When announcing your routes towards the router servers, you can additionally mark them with our BGP-community. The latter is a 32-bit number, usually written as a pair of 16-bit ones separated by a ":" sign, for example "1:6939". There can be several such codes at once. By combining them, you control the inbound traffic arriving in your direction from the participants. For example, you decided to prohibit the announcement in the direction of a participant with an AS number 64519 and used "0:64519" for this. When exporting your route to ASN 64519, the route server will "see" that there is a blocking community and discard it. As a result, AS 64519 will not know about your networks and traffic from this participant will not come through to you.
What about ASN in the 32-bit range? After all, only 16 bits fit into the community code, in the right part of which the target ASN is encoded. The answer to this question is the so-called AsnID (AID) - mapping 16/32 bits. You will find the current list of AID in RIPE/AS50817 (whois as50817). There are also other management and information community groups, locations, prepends, localprefs, etc.