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	10km	-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
100 Gbps
LR4*	SingleMode fibre 9/125	1310 nm	10km	-10.6 … 4.5 each lane	-4.3 … 4.5 each lane

*only available in 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).

Port Speed/Duplex

For copper ports, GR-IX explicitly configures speed and full-duplex on its side; and auto-negotiation is enabled (so that these settings are advertised to the members). Members can explicitly configure speed/full-duplex, or rely on auto-negotiation, or do both (explicitly configure speed/full-duplex and keep auto-negotiation active) — the latter is the safest option, thus suggested.

Public Peering LAN Specifications

Addressing

 

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

MAC address policy and MAC address change

For each assigned GR-IX IP address, members need to specify a single corresponding MAC address. Based in this correlation, GR-IX statically configures the provided MAC addresses on the relevant ports (static mac learning and layer2 access lists that drop traffic sourced from other MAC addresses).

In case of hardware replacement (router, port, card etc), the member need to contact GR-IX personnel in order to explicitly allow the new MAC. To facilitate the transition, both old and new MAC can be permitted for a limited period of time.

Please note that, after a MAC change, the other members’ ARP tables need to be updated. This process relies on appropriate ARP/gARP messages between the replaced equipment and the equipment of each of the member’s peers. If, for any reason, this process fails for a peer, significant downtime might occur. In order to resolve such a problem, the member will need to communicate directly with the affected peer(s) — GR-IX is unable to trigger such an ARP update.

Static MAC allocation

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

• GR-IX::Athens: ee:01:26:38:0X:XX
• GR-IX::Thessaloniki: ee:01:26:38:1X:XX

(where X:XX = the last 3 decimal digits of the corresponding IP address)

Although the use of statically assigned MAC addresses is optional, it is highly recommended: Hardware can be replaced without affecting the MAC address in use. Hence, no communication, scheduling or coordination with GR-IX or other members is required. Apart from that, the use of such MAC addresses makes debugging and troubleshooting is easier, as MAC<->IP correlation is evident.

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: The members are allowed to exchange a limited amount of internal traffic (i.e between a member’s own ports) over the GR-IX infrastructure. See “terms of use” for more details.
• 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 restrictions 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 forwarded 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 Practices

• 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.