Technical Requirements

Security policy of the shared Layer 2 infrastructure

Extreme IX aims to ensure the Members reliable and uninterrupted Service as well as to limit the risks of deliberate or accidental mistakes, defective equipment or lack of speed of certain Member to reflect the quality of the others.

According to this the following restrictions and rules apply:

MAC Layer

  1. Extreme IX PHYSICAL INTERFACES and MEMBERS PHYSICAL INTERFACES shall work in full-duplex regime.
  1. Frames forwarded to Extreme IX ports shall have one of the following ethertypes:
    – 0x0800 – IPv4
    – 0x0806 – ARP
    – 0x86dd – IPv6
    and restricts all other ethertypes.
  1. Only one MAC address is allowed on a service port and all traffic originating from this port should come with the same source MAC address, otherwise traffic will be discarded.
    In case of VLAN Interconnect service, we allow one MAC address per VLAN ID.
  1. Frames forwarded to Extreme IX ports SHALL NOT be addressed to a multicast or broadcast MAC destination address except as follows:
    – broadcast ARP (Address Resolution Protocol) packages
    – multicast IPv6 Neighbor Discovery (ND) packages
  1. Maximum broadcast packages forwarded from the MEMBER’S equipment must not exceed 50 (fifty) in number per second per PHYSICAL INTERFACE.
  1. Members SHALL NOT announce to the ROUTE SERVERS IP address space reserved for Private networks (Private IPs).
  1. Members SHALL NOT announce to the ROUTE SERVERS AS numbers reserved for private use (Private AS).
  1. The Member must aggregate as far as possible the announced prefixes (MEMBER ADDRESS SPACE).
    The smallest IP address block allowed to be announced is /24 (256 IP addresses).
    It is NOT ALLOWED to use Spanning Tree Protocol enabled on a port connected to Extreme-IX
    It is NOT ALLOWED to use proxy ARP enabled on a router port connected to Extreme-IX.
    NOTE: DO NOT advertise the full routing table to us, we need your DNS IP Pools and End user IP Pools only!
  1. Extreme IX can limit the PUBLIC PEERING traffic in both directions (source and destination), when source IP address space or destination IP address space is not part of the prefixes announced by the Member to ROUTE SERVERS.
  1. For the purpose of monitoring on Extreme IX site, Members should not forbid ICMP (Internet Control Message Protocol) communication from/to Extreme IX IP address space.
  1. Extreme IX has implemented Quarantine VLAN. Аll new ports are placed in their own separate VLAN, together with a monitor port.

IP Layer

  1. Interfaces connected to Extreme IX ports SHALL ONLY use IP addresses (IPv4 and IPv6) and netmasks assigned to them by Extreme IX.
  1. IP packets addressed to Extreme IX Peering LAN’s directed broadcast address SHALL NOT be automatically forwarded to Extreme IX ports.
  1. IP address space assigned to Extreme IX Peering LANs SHALL NOT be advertised to other networks.


IP Traffic Exchange

IP traffic should be exchanged between Extreme IX members using BGP protocol by the following ways:

  1. Using Route Servers (RS) – two RSs for redundancy and resilience.
  2. Bilateral BGP sessions between Extreme IX Members / Content providers with theirs mutual agreements.


Route Servers Peering Policies

  1. Disabling first AS check
    The Route Servers do not have their AS first in the AS_PATH. In some cases you might need to disable the first AS check in your BGP configuration.
    On Cisco routers please specify ‘no bgp enforce-first-as’ or ‘bgp enforce-first-as disable’ to disable the enforcement.
  1. Autonomous System Number (ASN)
    Extreme IX supports both 16-bit and 32-bit AS numbers.
  1. Incoming Prefixes Sanitization
    The Extreme IX route servers implement very basic incoming filters for private ASNs and prefixes received from clients. Extreme IX BLOCKs private ASNs, RFC1918 ranges, bogon prefixes and the default route.


Route Servers Details


Route Servers RS 1 RS 2
ASN AS49378 AS49378
IPv4 Address
IPv6 Address 2001:df2:1900:2::200 2001:df2:1900:2::240




All members to Extreme IX route servers can use communities to control incoming and outgoing information.

In relation to the incoming traffic (which announces are accepted) the control is in the client – he can filter which ones of the received from RS announces he will accept.

Extreme IX RSs remove its own AS from the route, which will make them seem directly connected without a necessary BGP session between them.

With the help of BGP Community Extreme IX member may decide who he wants to “give” the traffic to. The following BGP Community is maintained for every announced prefix.

Communities coming from Extreme IX RS:

0:peer AS Prefix is announced from peer AS


Communities that are accepted from Extreme IX RS:

49378:0 Block Your prefix to all peers
49378:0 49378:ASPEER Block Your prefix to all peers EXCEPT ASPEER
49378:ASPEER Block Your prefix to ASPEER


Communities for peers with 32-bit ASNs:

Extreme IX implements N:M filtering based on standard community strings. As standard BGP communities support only 4
bytes, this only works for 2-byte ASNs and peers with 2-byte ASNs.

For BGP peers with 32-bit ASN use current table for community:

Peer 32-bit ASN BGP Community
Cloudnet Communications 135207 65001
Logon Broadband 133968 65002
Jet Netcom Broadband 134009 65003
CreenceIS Computing 135262 65004
Utopia Networks 133315 65005
Multinet Udaipur 133469 65007
Clear Beam Communications 135762 65008
I Network Solutions 135739 65009
Syntego Technologies 135826 65011
Capsule Networks 133658 65012
Sukain Infoway 134937 65013
Optical Broadband Communications 135839 65015
Tracknet Services 133638 65016


Extreme IX Operations

Extreme IX provides 24/7/365 First level of support and Business hours Second Level of support to all its members.