Technical Specifications

Physical Interface Specifications

The following types/speeds of Ethernet interfaces are available:


Cable/Fibre Type

WaveLength Distance Input
1 Gbps
TX UTP cat5e N/A 100m N/A N/A
SX* MultiMode fibre 62.5/125μm OM1 850 nm 275m 0 … -21 ~-3
LX SingleMode fibre 1310 nm Tbd -3 … -25 -3
10 Gbps
SR* MultiMode Fibre 62.5/125μm OM1 850 nm 33m -1 … -9.9 ~ -1
LR SingleMode fibre 9/125 1310 nm 10KM 0.5 … -18 ~0.5
ER SingleMode fibre 1550 nm 40KM -1 … -15.8 ~4

*only available at EIE POP.



Ethernet Specifications

Framing & Ethertypes

The GR-IX infrastructure offers ports that implement the Ethernet standard (IEEE 802.3-2012 / Ethernet II).

The members’ ports are, by default, in “access” mode, which means that only untagged Ethernet Frames are allowed. 802.1q-tagged frames can be supported, if necessary (e.g., for private peerings).

Allowed ethertypes are: IPv4 (0x0800), IPv6 (0x06dd), ARP (0x0806) and 802.3ad – LACP (0x8809). Traffic with any other ethertype may be dropped without notice.

Maximum Transmission Unit (MTU)

The allowed L2 payload (L3 MTU) for GR-IX is 9000 bytes. Frames exceeding this payload may be dropped without further notice.

Link Aggregation (a.k.a link-bundling, ether-channel, port-channel)

Links of the same speed, on the same device, can be bundled into a single logical interface. Bundling can be configured statically or dynamically through LACP (802.3ad).

In both cases, per-flow load-balancing is implemented  (source/destination IP addresses & ports).



Public Peering LAN Specifications


The public peering LAN address space is:
  • IPv4:
  • IPv6: 2001:7f8:6e::/64

Members are assigned one IPv4 and one IPv6 address per physical port or bundle in order to connect their router on the public peering LAN. Under certain circumstances, a second IPv4 and a second IPv6 address can be assigned for redundancy.

Members are not allowed to use IPs other that the ones assigned to them on the ports connecting to GR-IX. Proxy-ARP is not allowed on the GR-IX ports; and NAT is not allowed on the GR-IX IPs.

Members are not allowed to redistribute the peering LAN address space into their eBGP and announce it to other AS.


Number of MAC addresses

Only MAC addresses that correspond to the GR-IX assigned IPs are allowed (one MAC address per assigned IP).

The member can choose one of the following methods of enforcement:

  • Automatic: A single MAC is expected on the port. The number of MACs on the port are constantly monitored. If two or more MACs are detected simultaneously, the port will automatically get into an error-disable mode and the connection will be dropped. Every 1 minute, or if a physical link down-up is detected. the port will attempt to recover.
    Pros/cons: This option allows the member to replace its equipment without prior notice; but a misconfiguration (i.e, a MAC leak) can bring the port down.

    • This is the default option for access ports with a single router
    • This option cannot be implemented on trunk ports, or when multiple routers exist behind this port
  • Manual: The member’s router MAC addresses are statically configured on the corresponding ports.
    Pros/cons: This mode prevents accidental port blocks, but requires human interference (i.e. from GR-IX personnel) whenever the member needs to change the MAC address of the router (eg port change due to hardware failure).

Port Limitations

  • Spanning tree & BPDUs: Incoming BPDUs are ignored (and dropped). The GR-IX infrastructure will not send or forward BPDUs towards its members.
  • Broadcast traffic (destination MAC FF:FF:FF:FF:FF): Broadcast traffic, with the exception of ARP broadcasts, is dropped
  • Storm Control: No more than 50Mbps of the incoming traffic of each port can be unknown unicast, multicast or broadcast. Traffic above this level is dropped.
  • ICMP redirects: ICMP redirects are not allowed and dropped.

Traffic Limitations

  • Internal Traffic: Members are not allowed to route traffic (through static, IGP or iBGP routing) between their own ports over the GR-IX infrastructure. However, small amounts of traffic for management/troubleshooting reasons (eg ping) is allowed.
  • Members are not allowed to advertise spoofed or private address space and AS numbers.
  • Multicast is not allowed on the public peering LAN



Private Interconnects

  • Point-or-point or Multipoint private interconnects can be provided between two or more members, on a single or on several POPs. The same specifications and restictions with the public peering LAN apply.
  • Especially for point-to-point private interconnects between two ports on the same POP, the above restrictions can be removed, if requested; in that case all traffic received at each endpoint will be transparently forwareded to the other one.
  • Private interconnects require an 802.1q trunk port between GR-IX and the member; VLAN tags on that port separate this traffic from the public peering lan or other private interconnects on the same port.



Implementation Directives

The members are encouraged to implement the following directives:

  • Disable spanning tree on the GR-IX port. Disable outgoing BPDUs and ignore incoming BPDUs (although no BPDUs should be received from a GRIX port).
  • Disable all unnecessary protocols. Take extra care with link-local protocols, esp. discovery protocols such as LLDP or CDP and VLAN propagation protocols such as VTP or GVRP/MRP.
  • If possible, terminate the GR-IX connection on a L3 port rather than using a switchport and a SVI/IRB interface, and avoid using L2 switches between GR-IX infrastructure and your L3 device.
  • Terminating LACP and L3 on different devices is not recommended.



Other Good Practice

  • Keep your IRR records updated (eg, on RIPE whois database). Create route objects for all prefixes that may be advertised to your peers
  • If other AS’s are advertised by you, create an appropriate AS-SET object and share it with your peers. Ask your downlink customers to keep their own IRR records updated.
  • Register GR-IX as an exchange point in your peeringdb entry. If your network is not registered, please do.
  • If possible, create and maintain ROAs. Even if you do not implement RPKI on your network, the existence of ROAs may protect your prefixes from hijacking. (for RIPE members, this can be done easily through the LIR portal)
  • Several GR-IX members (including GR-IX route servers) implement automation that relies on the accuracy of IRR and/or peeringdb data. Failing to keep this data updated may result into dropped bgp prefixes or even peering requests getting rejected.