Physical Interface Specifications
The following types/speeds of Ethernet interfaces are available:
|SX*||MultiMode fibre 62.5/125μm OM1||850 nm||275m||0 … -21||~-3|
|LX||SingleMode fibre||1310 nm||Tbd||-3 … -25||-3|
|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.
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).
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
- IPv4: 18.104.22.168/25
- IPv6: 2001:7f8:6e::/64
- IPv4: 22.214.171.124/25/25
- IPv6: 2001:7f8:ce::/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 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).
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)
- 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.
- 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
- 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.
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.