Technical Specifications

Physical Interface Specifications

The following types/speeds of Ethernet interfaces are available:

If/ce

Cable/Fibre Type

WaveLength Distance Input
(dbm)
Output
(dbm)
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 ATH01 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

Addressing

The public peering LAN address space is:
  • IPv4: 176.126.38.0/25
  • 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.

 

MAC addresses

Only the MAC addresses that correspond to the assigned GR-IX IPs are allowed on the GR-IX ports. A single MAC address is allowed per assigned IP; and this MAC address is statically configured (static mac learning & l2 access lists) on the port that correlates to that IP.

Instead of using the hardware address of the port of their routers, the members may use MAC addresses statically assigned by GR-IX to them. These MAC addresses belong to the Locally Administered Address Range and are of the form:

ee:01:26:38:YX:XX

where:
– X:XX = the last 3 digits of the corresponding IP address,
– Y = 0, other values are reserved for future use)

Although the use of statically assigned MAC addresses is optional, it is highly recommended: By using the assigned MAC address, members can replace their hardware without changing MAC address. This allows the works to be carried out without requiring any configuration changes on the GR-IX gear and without requiring an arp update by the member’s peers. Apart from that, debugging and troubleshooting is easier, as MAC addresses can be easily correlated and mapped to IP addresses.

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.