points of presence

You have the free choice of colocations, carriers and points of presence. Choose any pop you like and we will connect you there. If you need redundancy, we’re happy to connect you to multiple pops simultaneously. Prices are the same on every pop.

Available points of presences are:

location adress
N-IX 1 Deutschherrenkarree, DC 4 of noris network AG
N-IX 3 Thomas-Mann-Str. 16-20, DC 6 of noris network AG
N-IX 4 Deutschherrenkarree, colo of Core Backbone GmbH
N-IX 6 Sigmundstrasse 135, DC of Hetzner Online GmbH

Anschlusspunkte

download application form and TOS (only in german - email us if that is not sufficient):

❗️ Attention: all prices are exclusively for companies and are netto, VAT will be added.

10GbE Ports

Currently we offer 10GbE Ports only. SRL, SR, LR, ER on singlemode and multimode fibres are possible

private VLAN

If you need direct, bilateral traffic between two parties only, you can book a private VLAN between those parties, so the traffic can not be affected by other participants. This helps fulfilment of SLAs.

please note: costs of a VLAN are to be paid for every port that should be reachable on this vlan.

open and cooperative policy

No participant is forced to peer, neither directly nor via the route reflectors. For the Peering, we have a minimal AUP. Every participant can choose its peering partners freely. To maximize the usefulness it is ofcourse advised to peer with as many parties as possible. You are free to buy or sell backup-bandwidths over the N-IX, we recommend a private VLAN for this, though.

There is an AUP that every participant has to adhere to, and in the event of a violation, the violating participant will be disconnected physically until the cause has been fixed. It is advisable that any peer doesnt make the N-IX to its own single point of failure. Atleast one backup path over alternative means is strongly recommended. We’re working on maximum availability though.

AUP

This is the current AUP, which we work with:

  1. participants have to take care that no other participants are disruped by itself.

  2. if the platform operator or any other participant request assistance with troubleshooting, any other participant must be assisting.

  3. does the participant refuse cooperation or in the case that he doesnt answer within 30 minutes, the platform operator is allowed to take action by physically disconnecting or blocking the port of the violating participant.

  4. planned maintenances of participants have to be announced one working day before the planned maintenance. goal is to inform other participants about the interruption. the time frame of the maintenance has to be named, as well as contact person for that time frame.

  5. prior discussion with the participants, there is a maintenance windows, which is available one per week for maintenance withouth announcement.

  6. for publib peering, the policy should be documented in the AS or AS-Macro object in the RIPE database or any other equivalent IRR database.

  7. no participant is forced to peer

  8. participants are allowed to create any form of contracts for exchange of traffic - or not doing any contract at all

  9. german law applies for the legality of contents, that are exchanged at the N-IX

cisco interface configuration

the Peering LAN is pretty much sensitive against external influences. In the peering LAN, besides our route reflectors and the sponge, devices will have a varying age and therefore performance. Smaller and older routers may be negativly affected already by little traffic travelling through the control plnce. That is why it is imperative to suppress all traffic aside from Unicast (and ARP) before sending it to the Peering LAN.

We would like our participants to also suppress traffic for not used IPs (which means all IPs not documented in the participants list - or any IP which your device is not talking to).

exmaple of basic cisco 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

Please replace xx with your own IP address

our colleauges at AMSIX have a much more complete guide on how to configure devices properly for an IX.

technic

N-IX consists of various Juniper devices, for example EX4500, EX4550, QFX5100 and MX204.

IP-adresses and more

N-IX utilizes two route reflectors

every participant is free to peer with any one or both route reflectors to exchange prefixes with other rr-connected peers.

the route reflectors are not activaly filtering prefixes, they are setting communities as recommendation. Filtering is the receiving ASs choice.

the route reflectors understand and send these communities, “direction” mens from the POV of the route reflect, i.e. “inbound” means that the peer sends to the reflector, “outbound” sends from the reflector to the peer. If both directions are mentioned, the route reflector will swap the communities accordingly.

For technical reasons it is currently not possible to delete all communities that are irrelevant to the session, thats why incoming routes get all communities deleted, that the router is supposed to set itself (21083:10xxx).

the route reflectors are operating in transparent mode, which means the AS of the route server will NOT be injected in the AS-Path, if the peer doesnt want it explicitely.

available communities for the nuremberg internet exccange are:

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

Occasionally we will need to swap the AS of the community against another value, because there are reasons.

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

and finally a juniper-comptible config snippet on how to use these communities.

[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]