Anschlussmöglichkeiten

Sie haben die freie Wahl an Colocations, Carrier und Anschlusspunkten. Da wir komplett neutral in der Region agieren, können Sie sich einen Anschlußpunkt heraussuchen und wir werden Sie dort anschliessen. Falls Sie gehobene Redundanzansprüche stellen, schließen wir Sie auch gerne an mehreren Orten gleichzeitig an. Die Preise bleiben überall dieselben.

Verfügbare Anschlusspunkte sind:

Standort Adresse
N-IX 1 Deutschherrenkarree, RZ 4 der noris network AG
N-IX 3 Thomas-Mann-Str. 16-20, RZ 6 der noris network AG
N-IX 4 Deutschherrenkarree, Colo der Core Backbone GmbH
N-IX 6 Sigmundstrasse 135, RZ der Hetzner Online GmbH

Anschlusspunkte

Hier herunterladen und ausfüllen:

❗️ Hinweis: Alle Preise richten sich ausschliesslich an Geschäftskunden und sind netto ausgewiesen, d.h. zzgl der aktuell gültigen USt in Deutschland.

1/10GbE Ports

Es werden z.Zt. ausschliesslich 10GE und 1GE optische Ports angeboten. Der Anschluss kann über SRL (Short Reach Lite), SR (Short Reach) und LR (Long Reach) sowie Single- und Multimode-Fasern an realisiert werden.

privates VLAN

Für direkte, bilaterale Verkehrsbeziehungen empfiehlt sich die Installation eines privaten VLANs, damit der transportierte Datenverkehr nicht durch dritte Teilnehmer gestört werden kann. Dieser Punkt trägt zur Erfüllung von SLAs (Service Level Agreements) bei, damit auch nicht Internet-lastige Dienste, oder Vertragsbestimmungen eingehalten werden können.

Einrichtungsgebühren für VLANs fallen nicht an.

Bitte beachten: die Kosten für ein VLAN fallen für jeden einzelnen Port an, der in dem VLAN erreichbar sein soll.

Offene und kooperative Policy

Am N-IX besteht kein Peering-Zwang. Für den öffentlichen Bereich wurde eine minimale AUP (acceptable use policy) erarbeitet. Prinzipiell kann jeder Teilnehmer seine Partner selbst aussuchen und so flexibel agieren. Um den Nutzen der Plattform zu maximieren bietet sich natürlich Peering mit möglichst vielen Beteiligten an. Es ist für ISPs auch möglich, über den N-IX Transit-/Backup-Bandbreiten zu kaufen bzw. verkaufen, allerdings wird dazu die Verwendung eines privaten VLANs empfohlen. Ebenso bieten sich Partnerschaften bzw. Backup-Transit zwischen ISPs an, sodass keiner teuere WAN-Leitungen für Backup-Zwecke vorhalten muss. Somit profitieren gleich zwei Teilnehmer voneinander und sparen effektiv direkte Kosten ein.

Es gibt eine AUP, nach der sich alle Teilnehmer richten müssen und im Falle eines Verstoßes damit rechnen müssen, daß der Port bis zur Behebung des Fehlers abgeschalten wird. Es wird angeraten, daß für einen Teilnehmer die N-IX Infrastruktur nicht zum single-Point-of-Failure wird. Ein Ersatzweg über andere Strukturen wird weiterhin stark empfohlen. Wir arbeiten jedoch daran, daß die Plattform durch Höchstverfügbarkeit im Design keine Ausfallzeiten bei den Teilnehmern erzeugt.

Anschlußrichtlinien - AUP

Für den Betrieb einer Infrastruktur ist eine Teilnehmerrichtlinie (AUP = acceptable use policy) unumgänglich.

Hier wird die aktuelle Richtlinie veröffentlicht, nach der wir den Betrieb aufrecht erhalten:

  1. Ein Teilnehmer muss dafür sorgen, daß keine anderen Teilnehmer von Ihm gestört werden.

  2. Nach Aufforderung durch den Betreiber oder einem anderen Teilnehmer muss ein Teilnehmer bei der Fehlerfindung behilflich sein.

  3. Weigert sich der Teilnehmer, oder verstreichen mehr als 30 Minuten Antwortzeit, so ist der Betreiber berechtigt den fehlerverursachenden Port des Teilnehmer so lange zu blockieren, bis der Normalbetrieb wieder garantiert werden kann.

  4. Betriebsunterbrechnungen von Seiten des Teilnehmers müssen mindestens einen Werktag vor der geplanten Arbeit angezeigt werden. Ziel dabei ist es, die anderen betroffenen Teilnehmer von der Unterbrechung zu informieren. Dabei ist der geplante Zeitraum der Unterbrechung zu benennen, sowie ein Ansprechpartner für den entsprechenden Termin.

  5. Es wird nach Absprache mit den Teilnehmer ein Wartungsfenster vereinbart, welches 1x pro Woche die Möglichkeit zu Änderungen am Setup bietet, ohne dass eine Vorankündigung vonnöten ist. Falls für das Wartungsfenster keine Arbeiten geplant sind, wird dies auf einer Webseite zu lesen sein.

  6. Für öffentliche Peering-Beziehungen sollte die Policy als AS-Macro/Objekt in der RIPE, oder anderen entsprechenden IRR-Datenbank eingetragen werden. Falls die interne Firmenpolitik die Veröffentlichung verbietet, so ist es dem Teilnehmer freigestellt diese Policy zu veröffentlichen.

  7. Es besteht kein Peering-Zwang

  8. Es ist den Teilnehmern freigestellt jegliche Vertragsvereinbarungen für den Datenaustausch einzugehen.

  9. Es gilt das Deutsches Recht für die Legalität der Inhalte, die am N-IX ausgetauscht werden.

Cisco Interface Konfiguration

Das Peering LAN ist relativ empfindlich gegen Einflüsse von aussen. Im Peering LAN stehen neben den zwei Route-Reflektoren und dem sponge nur Router, die verschiedenen Alters und damit von verschiedener Leistung sind. Aeltere oder Kleinere Router koennen schon von relativ wenig Traffic, der durch die Control Plane muss, unter Last gesetzt werden. Daher ist es unabdingbar, dass saemtlicher Traffic, der nicht Unicast ist, vor dem Senden in das Peering LAN unterdrückt wird.

Wünschenswert wäre ausserdem, dass Traffic für nicht genutzte IPs (das sind im Zweifelsfall alle, die nicht in der Teilnehmerliste dokumentiert sind), verworfen wird. Das kann im Zweifelsfall passieren, in dem man das Netz auf dem Router auf Reject setzt und nur die IP Adressen, mit denen man sprechen will, explizit auf Accept setzt. Wir werden verstärkt das Peering LAN auf “unerwünschten” Traffic abklopfen und Peers entsprechend in Kenntnis setzen.

Beispiel Cisco-Interface configuration:

Interface GigabitEthernet3/0
ip address 195.85.217.xx 255.255.255.0
no ip redirects
no ip proxy-arp
no ip directed-broadcast
no cdp enable
no lldp receive
no lldp transmit
no udld enable
ipv6 nd suppress-ra
ntp disable

Bitte das xx durch die vergebene IP-Adresse ersetzen.

Noch detailreichere Informationen lassen sich bei den Kollegen zB vom AMSIX finden.

Technik

Der N-IX besteht aus Juniper Switches und Routern, darunter EX4500, EX4550, QFX5100 und MX204.

IP-Adressen und mehr …

Am N-IX werden zwei Route Reflektoren betrieben:

Jeder N-IX Peer kann an einem oder beiden Route Reflektoren peeren, um mit anderen zu den RR konnektierten AS Routen auszutauschen.

Anders als bei anderen Exchanges filtern die Route Reflektoren allerdings keine Prefixe, sondern setzen lediglich Communities um Empfehlungen abzugeben. Das Filtern ist dem empfangenden AS vorbehalten.

Der Route Reflektor versteht bzw sendet folgende Communities, die Richtung ist dabei aus Sicht des Reflektors zu sehen, d.h. “inbound” bedeutet, dass der Peer zum Reflektor sendet, “outbound” sendet der Reflektor zum Peer. Sind beide Richtungen angegeben, so tauscht der Route Reflektor die Communities entsprechend aus.

Aus technischen Gruenden ist es aktuell leider nicht moeglich, alle fuer eine Session unrelevanten Communities zu loeschen, daher werden bei einkommenden Routen erstmal nur die Communities geloescht, die der Routeserver selber setzen soll (21083:10xxx). (Sobald die Funktionalitaet verfuegbar ist, wird der Routeserver ausgehende alle Communities loeschen, die nicht 21083:, source-as: oder dest-as:* entsprechen.)

Der Routeserver agiert im transparenten Modus, das heisst das AS des RouteServer (21083) wird nicht in den AS-Pfad eingehaengt, wenn es der sendende Peer nicht explizit wuenscht (21083:10{1-3}).

Die für den Exchange verfügbaren Communities sind wie folgt:

inbound community explanation outbound community filter recommendation
tagging by routereflector
- invalid prefix 21083:10103 reject
- peer as is 21083 21083:10201 accept
- path doesnt contain peeras as first element 21083:10202 reject
- invalid prefix(2) 21083:10203 reject
- Net (Prefix) does match RPSL Data 21083:10300 accept
- Net does not match RPSL 21083:10301 reject
- ROA: No information about validity 21083:10400 accept
- ROA: signed and valid 21083:10401 accept
- ROA: signed, but invalid 21083:10402 reject
basic set peeras is Peer-AS, unless substituted.
0, peeras do not announce to peeras - /
21083, peeras announce to peeras - /
0, 21083 do not announce to any peer /
21083, 21083 announce to all peers - /
special set peeras is Peer-AS, unless substituted. 0 means ALL
peeras:10x prepend 0-9; (0 is default=transparent mode) 21083:10(1-9) /
peeras:660 announce prefix with no-export no-export /
peeras:666 Blackhole community 21083:666 discard

Ausserdem gibt es manchmal die Anforderung, ein AS in der Community gegen eine andere Nummer aus dem reservierten Bereich auszutauschen.

“real” ASN peeras-substitue reason
197540 65043 NetCup has 32bit ASN
21083 65235 21083 has special meaning already.

Anbei noch ein Juniper-kompatibler Konfig-Excerpt wie man die Communities filtern könnte:

[edit policy-options]
policy-statement nix_rr_example {
    term 10 {
        from community [ NIX_invalid NIX_NotMatchesRPSL NIX_ROAsignedAndInvalid NIX_notFirstAS ];
        then reject;
    }
    term 20 {
        from community NIX_blackhole;
        then {
            next-hop discard;
            accept;
        }
    }
    term 30 {
        from community [ NIX_ROAnoInformation NIX_ROAsignedAndValid NIX_matchesRPSL NIX_peer21083 ];
        then accept;
    }
}
community NIX_NotMatchesRPSL members 21083:10301;
community NIX_ROAnoInformation members 21083:10400;
community NIX_ROAsignedAndInvalid members 21083:104002;
community NIX_ROAsignedAndValid members 21083:104001;
community NIX_announceToAllPeers members 21083:21083;
community NIX_announceToNoPeer members 0:21083;
community NIX_blackhole members 21083:666;
community NIX_invalid members 21083:10103;
community NIX_matchesRPSL members 21083:10300;
community NIX_notFirstAS members 21083:10202;
community NIX_peer21083 members 21083:10201;

[edit policy-options]