Contents
1. Technical Requirements
2. Route Server Policies
3. Ts & Cs
4. GIBIRIX Privacy
1. Technical Requirements
GIBIRIX Ports
The common network platform of the GIBIRIX nodes is based on Ethernet technology (IEEE 802.3).
Interfaces GIBIRIX Offers
- Copper port 100/1000 Mbps RJ45 (802.3u, 802.3ab)
- Optical 1Gbps port with SFP module LX (13100nm singlemode, 802.3z)
- Optical 10Gbps port with LR module (1310nm singlemode, 802.3ae)
- Optical 25Gbps port with LR module (1310nm singlemode, 802.3cc)
- Optical 40Gbps port with LR4 module (1310nm singlemode, 802.3ba)
- Optical 100Gbps port with LR4 module (1310nm singlemode, 802.3ba)
- Other, not mentioned above modules, specified by responsible engineers of GIBIRIX (e.g. modules SX, ER, ZR, SR etc.)
Physical Requirements
All Ethernet interfaces attached to GIBIRIX shall be explicitly configured with duplex, speed and other configuration settings and shall not be auto-sensing.
Technical Requirements
Member's use of GIBIRIX services shall at all times conform to the standards as laid out in IETF STD0001 and associated Internet STD documents.
MAC Layer
Frames forwarded to GIBIRIX ports shall have one of the following ether types:
- 0x0800 - IPv4
- 0x0806 - ARP
- 0x86dd - IPv6
All frames of a service forwarded to an individual port shall have the same source MAC address. Only one predefined MAC address is allowed on a service port. If any additional need arise, the number of associated MAC addresses may be increased by GIBIRIX. In the event of exceeding the maximum number of allowed MAC addresses the related GIBIRIX port is automatically blocked to ensure stability for the entire platform.
Member shall send Ethernet frames from an interface connected to GIBIRIX only to MAC addresses learned via that interface.
All frames forwarded to GIBIRIX ports shall not be addressed to a multicast or broadcast MAC destination address, with the following exceptions:
- Broadcast ARP packets
- Multicast IPv6 Neighbor Discovery (ND) packets
- Others, if explicitly allowed for that port (e.g. multicast service)
Traffic for link-local protocols shall not be forwarded to GIBIRIX ports except for the following:
- ARP except proxy ARP
- IPv6 Neighbor Discovery
These link-local protocols include but are not limited to the following list:
- IRDP
- ICMP redirects
- IEEE802 Spanning Tree
- Vendor proprietary discovery protocols (e.g. CDP)
- Interior routing protocol broad/multicasts (e.g. OSPF, IS-IS, IGRP, EIGRP)
- BOOTP/DHCP
- PIM-SM
- PIM-DM
- DVMRP
Use of proxy ARP on the router's interface to the GIBIRIX is not allowed.
IP Layer
On all interfaces connected to GIBIR Internet Exchange network only IP address and network mask assigned by GIBIRIX shall be used.
IPv6 addresses shall be statically configured (no use of automatic configuration). IPv6 site local addresses shall not be used.
IP packets addressed to GIBIRIX peering LAN directed broadcast address shall not be automatically forwarded to GIBIRIX ports.
Routing
All exchange of routes across the GIBIRIX network shall be via BGP4(+).
All AS numbers used for peering sessions across the GIBIRIX network shall not be from range reserved for private use (64512-65535).
Member shall forward traffic via GIBIRIX only to addresses announced to the member via GIBIRIX.
IP address space assigned to GIBIRIX peering LAN shall not be advertised to other networks without explicit permission of GIBIRIX.
Member shall not announce to Route Server (59510) private addresses, private ASes or default route.
The members are recommended to:
- Register their routing policy for each connected ASN in the appropriate RIR database and keep it updated.
- For all networks advertised via BGP register a route (or route6) object in the RIPE database or other public routing register and keep it updated.
- Use an as-set object registered in RIPE database or similar register.
- GIBIRIX members are encouraged to do the best to aggregate their routes in accordance with RFC2519 (A Framework for Inter-Domain Route Aggregation).
- All prefixes advertised across the GIBIRIX network shall have their next-hop attribute pointing to the IP address of the advertising router UNLESS agreement has been made in advance in writing by GIBIRIX and the members involved.
- Newly installed ports are initially connected to the isolated testing segment to verify whether the member’s equipment is configured correctly. Connection to the production network is possible only after all detected defects are removed.
2. Route Server Policies
About Route Server
The Route Server (RS) is used to facilitate interconnection between multiple Internet routers. It is a network service that reduces the number of individually configured peering sessions between GIBIRIX participants. GIBIRIX operates two geographically diverse Route Servers for resilience.
Start Using Route Server
| RS1 | RS2 | |
|---|---|---|
| AS Number | 59510 | 59510 |
| IPv4 address | 185.1.221.100 | 185.1.221.200 |
| IPv6 address | 2001:7f8:11d::64 | 2001:7f8:11d::c8 |
| AS-SET | AS-GIBIRIX-NET | AS-GIBIRIX-NET |
| Platform | BIRD | BIRD |
Route Server Policy
Two policy groups are present:
Routing Policy
-59510:peer-as - Announce a route to a certain peer-59510:59510 - Announce a route to all peers
-0:59510 - Prevent announcement of a prefix to all peers
-0:peer-as - Prevent announcement of a prefix to a peer
-59510:0:peer-as - Prevent announcement of a prefix to a peer
-59510:1:peer-as - Announce a route to a certain peer
-59510:0:0 - Prevent announcement of a prefix to all peers
-59510:1:0 - Announce a route to all peers
-59510:101:peer-as - Prepend to peer AS once
-59510:102:peer-as - Prepend to peer AS twice
-59510:103:peer-as - Prepend to peer AS three times
-59510:666 Blackhole Prefix up to /32
Prefix Validation
GIBIRIX validates prefixes at ingress on all route servers. The validation is based IRR Object presence. We are looking for a valid Route Origin Authorization (ROA) for all the announced prefixes in RADB Internet Routing Registry (IRR).
For any additional information on this matter you can contact us on [email protected].