Häufig gestellte Fragen (FAQs)

Was ist der Vienna Internet eXchange?
Wer ist am VIX angeschlossen?
Unterstützt der VIX IPv6?
Habe ich automatisch 10 Gbit/s Richtung Internet, wenn ich mich am VIX mit 10 Gbit/s anschließe?
Wie hoch sind die Kosten für eine VIX-Teilnahme?
Muss ich für einen zusätzlichen oder leistungsfähigeren VIX-Anschluss erneut Setup-Kosten bezahlen?
Darf ich Upstream über den VIX einkaufen?
Wann kommt endlich ein bestimmtes, für mich wichtiges Netzwerk an den VIX?

Welche Voraussetzungen muss ich erfüllen, um am VIX teilzunehmen?
Kann ich auch ohne eigene AS-Nummer am VIX teilnehmen?
Was ist BGP?
Warum muss ich meinen Router mit BGP konfigurieren, wenn ich an den VIX will?
Kann ich am VIX teilnehmen, ohne meinen Router direkt an einem VIX-Standort aufzustellen?
Die niedrigste angebotene Bandbreite ist 2,5 Gbps - ich brauche aber keine 2,5 Gbps. Wieso gibt es keine Gigabit-Interfaces mehr?
Was ist ein VIX-Reseller?

Was muss ich tun, wenn ich am VIX teilnehmen will?
Was passiert, nachdem ich das Connection Agreement an den VIX gesendet habe?
Wie bestelle ich eine Patchung zum VIX bei Interxion?
Wie bestelle ich eine Patchung zum VIX bei e-shelter?
Wie peere ich dann?

Wie erfolgt die Rechnungslegung?
Ich brauche ein steuerliches Formular (Certificate of Residence, US W-8 etc.) vom VIX - wie bekomme ich das?

Was gibt es im Webportal zu sehen?
Gibt es eine Liste von IP-Adressen und MAC-Adressen der Teilnehmer-Router am VIX?
Kann ich herausfinden, wie viel Verkehr ich mit meinen Peering-Partnern am VIX austausche?

Wieso muss ich zuerst in ein Quarantäne-Setup?
Wie stelle ich eine BGP-Test-Verbindung im Quarantäne-Setup her?
Was sind Site-Specific BGP Communities?
Warum darf mein Equipment kein Spanning Tree Protocol (oder Sonstiges) verwenden?
Warum darf ich nur eine MAC-Adresse am VIX haben?
Was ist zu tun, wenn ich die Router-Hardware am VIX-Anschluss tausche?

Warum kann ich kein Peering mit den Route-Servern des VIX aufbauen?
Warum sind alle vom Route-Server angebotenen Routen invalid?
Warum sendet mir der Route-Server keine Prefixes von einem bestimmten AS?
Warum fehlen mir Prefixes aus einem AS, die ich aber über meinen Transit bekomme?
Hilfe, mein Prefix wird von jemandem anderen announced!
Hilfe, mein VIX-Anschluss ist saturiert!
Hilfe, ich werde von einem IaaS/CDN-Provider von einzelnen IP-Nummern mit UDP attackiert!
Wie erreiche ich das VIX Network Operations Center (NOC)?

Ich versuche, meine Erreichbarkeit im Internet unter anderem mittels eines ICMP Echo Requests (Ping) an ein Interface am VIX zu bestimmen, die Antwort bleibt aber manchmal aus. Ist da ein Fehler?
Mein Traceroute zu einem VIX-Teilnehmer zeigt ab einem VIX-Interface Sternchen oder Sonstiges, aber jedenfalls keine Antwortzeiten. Ist da ein Fehler?

Der Vienna Internet eXchange (VIX) ist eine neutrale Peering-Infrastruktur für Wissenschaftsnetze (NRENs), Internet Service Provider (ISPs), Content Delivery Networks (CDNs) und Content Provider in Österreich sowie in Zentral- und Osteuropa. Er dient seinen Teilnehmern zum Austausch von nationalem und internationalem Internetverkehr. Die Universität Wien betreibt die redundante VIX-Infrastruktur an drei Standorten in Wien. Ziel ist es, ein neutrales, robustes Non-Profit-Peeringumfeld für alle Teilnehmer bereitzustellen. mehr Infos

Neben nationalen und internationalen Internet Service Providern und Wissenschaftsnetzen sind auch Content Provider und Content Delivery Networks am VIX willkommen (siehe Teilnehmerliste).

Ja, IPv6 ist auf dem VIX produktiv - das bedeutet, dass Ihr Connection Agreement für IPv6-Datenverkehr ebenso gültig sind wie für IPv4. Ist Ihr Router IPv6-fähig, können Sie Ihre IPv6-Adresse nach einer speziellen Syntax bilden, um IPv6-Peerings an Ihrem VIX-Interface zu ermöglichen. Wie diese Syntax aussieht, ist auf der IPv6-Seite genau beschrieben.

Ein 10 Gbit/s-Port am VIX bedeutet nicht automatisch, dass man einen 10 Gbit/s-Internetanschluss hat. Die Menge des Internetverkehrs, die Sie über den VIX abwickeln können, hängt in erster Linie von der Art und Anzahl der Teilnehmer ab, mit denen Sie Peering-Vereinbarungen treffen können.

Für die Errichtung ist ein einmaliger Betrag von 1000 EUR (Stand 07/2019) zu leisten. Die monatlichen Portkosten richten sich nach der Anzahl und der Geschwindigkeit der gewünschten Ports. Teilnehmer mit Anschlüssen an zwei VIX-Standorten (darunter VIX1) haben unter bestimmten Voraussetzungen die Möglichkeit, einen Rabatt zu erhalten. Die genauen Kosten und Rabattbedingungen entnehmen Sie bitte unserer Kostenübersicht.

Nein, die Setup Fee wird nur einmal bei Vertragsabschluss verrechnet.

Der VIX stellt als neutraler Internet Exchange Point eine komplementäre Peering-Infrastruktur dar. Kommerzielle Vereinbarungen zwischen Teilnehmern - unter Einbeziehung physischer VIX-Infrastruktur - sind nicht verboten, werden aber seitens des VIX nicht unterstützt.

Diese Entscheidung hängt nach unserer Erfahrung von mehreren Gegebenheiten ab, unter anderem: Hat der potentielle Teilnehmer bereits Infrastruktur an einer VIX-Location? Wenn nein, wie aufwendig ist es, eine Zuleitung herzustellen? Ist es kommerziell sinnvoll? Folgt der potentielle Teilnehmer einer Policy, die z. B. besagt, dass es zu Netzen, die kein Tier-1 sind, nur "Private Interconnects" gibt?

Manchmal wird eine Entscheidung für eine VIX-Teilnahme auch durch Interessensbekundungen von bereits bestehenden Teilnehmern angestoßen. Daher kann es sinnvoll sein, derlei Überlegungen beim entsprechenden Peering-Kontakt des gewünschten Netzwerks zu deponieren. Üblicherweise findet man diese Kontakte in der Peering Database. Wir nehmen Anregungen, ein bestimmtes Netzwerk an den VIX anzubinden, gerne entgegen, bitten aber um Verständnis, dass wir dazu keine Aussagen oder gar Zusagen machen können.

Die wesentliche Voraussetzung für einen VIX-Anschluss ist eine eindeutige AS(Autonomous System)-Nummer mit bereits etablierter globaler Internetverbindung. Der VIX versteht sich als komplementäre Infrastruktur zur Optimierung von regionalem Internetverkehr. Das einzig erlaubte Routing-Protokoll am VIX ist BGP4. Mehr Informationen dazu finden Sie unter Voraussetzungen.

Leider nein. Wie an jedem anderen Internet Exchange Point ist am VIX eine eigene AS(Autonomous System)-Nummer eine technische Notwendigkeit für Peerings. Der VIX verwendet das Border Gateway Protocol (BGP) als Routing-Protokoll, das eine eigene AS-Nummer voraussetzt.

Das Border Gateway Protocol (BGP) ist das zwischen Internet Service Providern standardmäßig verwendete Routing-Protokoll. Damit werden Routen und Routing-Informationen zwischen Autonomen Systemen (Autonomous Systems) ausgetauscht. BGP bildet am VIX die technische Basis für die bilateralen Peering-Vereinbarungen zwischen den Teilnehmern. mehr Infos

Ohne das Routing-Protokoll BGP können Sie keine Routing-Informationen (und somit auch keinen IP-Verkehr) mit anderen Teilnehmern austauschen.

Ja, über "Remote Peering". Dabei stellt ein Carrier Ihrer Wahl eine Verbindung mittels eines transparenten Layer2-Ethernet-Service zur Verfügung, über die Sie Ihren Peering-Router auch über große Distanzen hinweg an den VIX anbinden können. Sie sind Vertragspartner des Carriers und des VIX, und somit dem VIX gegenüber für die Qualität Ihrer Anbindung verantwortlich. Wir behalten uns das Recht vor, eine instabile Remote-Leitung abzudrehen, wenn sie die Stabilität oder den Betrieb des Exchange Points gefährdet.

Die derzeitige Hardwareplattform des VIX ist für physische Bandbreiten von 10 und 100 Gbit/s gebaut. Jeder Bandbreitenübergang enthält Konfliktpotential im Hinblick auf Queueing, Buffering etc. Niedrigere Anschlussbandbreiten bietet wahrscheinlich ein Reseller, der diese Übergänge - an die Gegebenheiten angepasst - in seinem Netz abwickelt.

Das ist eine Organisation, die eine gesonderte Vereinbarung mit dem VIX getroffen hat, wonach sie ihren physischen Anschluss in mehrere logische Anschlüsse mit vereinbarten Einzelbandbreiten aufteilen kann. Diese logischen Anschlüsse werden dann anderen, geeigneten Teilnehmern frei angeboten - im Allgemeinen Zubringung und Anschluss als Paket. Das Vertragsverhältnis besteht hierbei zwischen Teilnehmer und Reseller. Teilnehmer, die über einen Reseller an den VIX angebunden sind, erhalten natürlich (in angepasstem Umfang) ebenfalls entsprechenden Support vom VIX-NOC.

Um VIX-Teilnehmer zu werden, lesen Sie bitte die General Terms and Conditions und füllen Sie dann das VIX Connection Agreement aus. Nach Senden des ausgefüllten Webformulars erhalten Sie Ihr Connection Agreement per E-Mail. Schicken Sie uns davon bitte anschließend zwei gedruckte und unterschriebene Exemplare über den Postweg. Mehr Informationen dazu sowie unsere Postadresse finden Sie unter VIX-Teilnahme.

Das VIX-Team wird Ihr Connection Agreement bearbeiten und sich innerhalb von 5 Werktagen bei Ihnen melden. Falls Sie einen Anschluss bei Interxion oder e-shelter planen, können Sie in der Zwischenzeit bereits die erforderliche Patchung in die Wege leiten (siehe dazu die folgenden beiden Punkte).

Bitte nennen Sie uns bei der Errichtung Ihrer Anbindung Ihre Patchkoordinaten bei Interxion und händigen Sie uns einen dazu passenden LOA (Letter of Authorization) aus. Für Remote Peerings mit Anbindung durch einen Carrier benötigen wir dies von Ihrem Carrier. Der Patch wird vom VIX-NOC bei Interxion bestellt und ist in der Teilnahmegebühr enthalten (Stand 02/2019).

Bitte bestellen Sie die Patchung direkt bei e-shelter. Als Ziel der Patchung nennen Sie bitte nur "Vienna Internet eXchange” mit den von uns angegebenen Daten zu Gerät und Portnummer. Sobald Sie die Patchung in Auftrag gegeben haben, setzen Sie uns bitte davon in Kenntnis (entweder per CC ihres Auftragsmails oder mit einem separaten E-Mail an uns).

Am VIX haben sich zwei Varianten etabliert, die von jedem Teilnehmer voneinander unabhängig angewendet werden können:

a) Sie verwenden die Route-Server des VIX:
Alle anderen Teilnehmer haben dort Ihre Peering Policy abgebildet, von der Nicht-Teilnahme bis hin zu Default-Peering für alle. Sie müssen die Route-Server nicht verwenden - wir empfehlen es aber, da der Administrationsaufwand drastisch sinkt und schnell Verkehr mit anderen Teilnehmern ausgetauscht werden kann. Darüber hinaus empfehlen wir, zu jenen VIX-Teilnehmern, die für das eigene Netz besonders wichtig erscheinen, zusätzlich ein bilaterales Peering zu errichten.

b) Bilaterale Peerings:
Peering direkt zwischen den Teilnehmer-Routern, frei vereinbart zwischen zwei Teilnehmern. Versuchen Sie dazu, mit dem Peering-Team des gewünschten Teilnehmers Kontakt aufzunehmen, um eine (meist formlose) Vereinbarung zu schließen.

Grundsätzlich per PDF an den angegebenen Billing Contact. Die Rechnung enthält Umsatzsteuer, die (falls anwendbar) als Vorsteuer geltend gemacht werden kann. Bitte sorgen Sie für einen spesenfreien Zahlungseingang. Allfällig abgezogene Bankspesen werden mit dem nächsten Rechnungslauf gegenverrechnet.

Bitte wenden Sie sich an buchhaltung(at)vix.at.

Im Benutzerprofil erhalten VIX-Teilnehmer Einsicht in ihre eigenen Daten. Der Bereich Netzwerk-Status bietet Statistiken, Peering-Verkehr-Analysen und eine Layer2-Ansicht. Im Event-Manager besteht die Möglichkeit einer persönlichen Anmeldung zu Veranstaltungen. mehr Infos

Ja, im Webportal gibt es eine solche Liste, die sich alle 2 Minuten automatisch aktualisiert.

Ja, das ist ebenfalls im Webportal ersichtlich.

Hier wird standardmäßig überprüft, ob ein Anschluss den Richtlinien/BCPs genügt und sich die BGP-Announcements im sinnvollen Rahmen bewegen. Dies ist also ein Beitrag zur Betriebssicherheit. Das Setup der Quarantäne kann im Peering-LAN, nach Anpassung des selbstgewählten MD5-Secret, gleich zur Verwendung der Route-Server genutzt werden - die IP-Nummern dort sind ident.

Im Quarantäne-Setup befinden sich drei Route-Server, die die ACOnet-Router im produktiven VIX-LAN simulieren. Sobald Sie erfolgreich eine BGP-Verbindung zu diesen Route-Servern hergestellt haben, testen wir Ihre Announcements und Filtereinstellungen. Wenn wir Sie dann in das Peering-LAN übersiedeln, werden diese Test-Peerings automatisch zu echten Peerings mit den ACOnet-Netzwerken.

Die drei Test-Geräte sind wie folgt zu konfigurieren:

Site-Specific BGP Communities dienen dazu, die Verkehrsströme zwischen VIX-Teilnehmern zu optimieren. mehr Infos

Das Spanning Tree Protocol ist zur Verhinderung von Ethernet Loops (Endlosschleifen) innerhalb einer Organisation geeignet, nicht jedoch an Internet Exchange Points. Wir verwenden andere Mechanismen, um sicherzustellen, dass keine Loops die IXP-Infrastruktur beeinträchtigen können. mehr Infos

An einem Internet Exchange Point ist jeder Teilnehmerport für den Anschluss genau eines Peering-Routers vorgesehen. Sobald ein VIX-Teilnehmer mit mehr als einer MAC-Adresse Datenpakete sendet, bedeutet dies normalerweise eine Fehlkonfiguration. In vielen Fällen tritt dann eine Schleife (Loop) auf, die theoretisch den Betrieb des Exchange Points lahmlegen könnte. Wir beugen hier vor, indem wir aus Sicherheitsgründen Verkehr von nicht registrierten MAC-Adressen ignorieren.

Sollte sich dabei die MAC-Adresse ändern, geben Sie uns die neue Adresse bitte unbedingt bekannt! In Notfallsituationen kann dies auch via Telefon bzw. außerhalb der Bürozeiten via Sprachspeicher-Nachricht geschehen (siehe "Wie erreiche ich das VIX-NOC?").

Ein Grund kann darin liegen, dass die Route-Server im Webportal nicht aktiviert sind. Jemand aus Ihrer Organisation, dessen VIX-Portalaccount als "Route-Server Admin" qualifiziert ist, muss die Route-Server dort aktivieren. Ein MD5-Secret ist dabei obligat.
Falls die Route-Server aktiviert sind und dennoch kein Peering zustandekommt, ist der Grund wahrscheinlich die TTL. Bitte stellen Sie sicher, dass die TTL der Peering-Session 1 oder 255 ist.
Auf einigen Plattformen führt auch ein bekanntes Problem mit "bgp enforce-first-as" zu einem Abbruch der Peering-Session - bitte kontrollieren und ggf. korrigieren! Wenn auch das nicht hilft, wenden Sie Sich bitte an das VIX-NOC.

Manche Router-Hersteller haben per Default die Einstellung in ihrer Software, das erste AS der empfangenen Route mit dem AS des Peers zu vergleichen. Sind diese nicht ident, wird die Route als ungültig markiert. Der Route-Server hat ein eigenes AS, fügt es aber nicht in den Pfad ein. Bitte konfigurieren Sie Ihren Router entsprechend, z. B. "no bgp enforce-first-as".

Die häufigsten Gründe dafür sind:
a) Der Teilnehmer verwendet die Route-Servern nicht oder hat eine Peering-Policy, die Austausch mit Ihrem AS verhindert. Dies ist in der Konfiguration der Route-Server im Webportal ersichtlich.
b) Die Prefixes sind nicht oder nicht ordnungsgemäß in der RIPE-Datenbank registriert (inetnum mit passendem route-object). Kontaktieren Sie bitte das Peering-Team des anderen AS. Sollte es sich um ein Netz aus einer anderen RIR handeln, können Sie auch den Peer bei der Route-Server-Konfiguration so verändern, dass Sie alle Prefixes aus diesem AS bekommen - egal, ob dokumentiert oder nicht.

Dies tritt vor allem bei Content Delivery Networks (CDNs) auf. Es ist dann Teil des Load-Sharing-Konzepts des CDN, nicht alles an jedem POP zu announcen.

Dahinter steckt oft ein Konfigurationsfehler, manchmal aber auch böse Absicht. Kontrollieren Sie bitte zuerst Ihre Dokumentation in der RIR. Die Route-Server des VIX sollten solche Announcements nicht weitergeben, sofern die empfangenden Teilnehmer die RIPE-Filter-Option aktiviert haben. Dennoch wird es Ihnen nicht erspart bleiben, den Ursprung des Fehlannouncements zu kontaktieren und ihn aufzufordern, das einzustellen. Das VIX-NOC kann helfen, den Kontakt zu finden. Wir haben aber keine wie auch immer gestaltete Ermächtigung, Änderungen einzufordern - insbesondere dann nicht, wenn es sich nicht um einen VIX-Teilnehmer handelt.

Versuchen Sie zunächst herauszufinden, ob es sich um eine Volumen-Attacke oder um legitimen Verkehr handelt. Dabei hilft die Identifikation des Quell-Peers im VIX-Webportal. Bei legitimem Verkehr kann Traffic Engineering (d. h. die Abwicklung des Verkehrs über andere Wege) kurzfristig Abhilfe schaffen, mittelfristig ein Upgrade des VIX-Anschlusses. Im Falle einer Attacke bleibt nur eine anderwärtige Mitigation (z. B. im Transit-Netz) oder ein Abstellen der Quelle(n) - das kann aber durchaus aufwändig bis praktisch undurchführbar sein. Alle genannten Maßnahmen befinden sich jedenfalls außerhalb des Einflussbereichs des VIX.

Das ist mit hoher Wahrscheinlichkeit ein Download per QUIC und keine Attacke (siehe https://de.wikipedia.org/wiki/Quick_UDP_Internet_Connections).

Entweder über die Mailadresse noc(at)vix.at oder zu Bürozeiten (Mo-Fr 8:00-17:00 ME(S)Z) unter der Telefonnummer +43 1 4277-14030. Außerhalb unserer Bürozeiten ersuchen wir, ausschließlich in Notfällen eine Nachricht unter dieser Nummer zu hinterlassen. In dringenden Fällen werden wir Sie so bald wie möglich zurückrufen. mehr Infos

Eine Antwort auf ICMP Echo Requests erfolgt in den meisten Router-Typen durch die Control Plane - das ist jener Teil eines Routers, der u. a. damit beschäftigt ist, den Informationsaustausch mit anderen Routern über verfügbare Pfade im Interne, sowie Entscheidungen über selbst verwendete Pfade abzuwickeln. In ihrer Rolle als zentraler Punkt eines Routers will man diese Control Plane normalerweise gegen Last, die nicht unmittelbar dem Betriebszweck dient, schützen. Anders gesagt: Ein Teilnehmer-Router hat genug anderes zu tun als Pings zu beantworten, die von irgendwoher kommen, und er macht es je nach Situation einfach nicht.

Aufgrund dieses Verhaltens ist anhand von Echo Requests (bzw. der Replies) weder ein Rückschluss auf ein etwaiges Verbindungsproblem noch auf die Laufzeit des Nutzverkehrs zulässig - so etwas kann einzig und allein das NOC des Teilnehmers klären. Bei vermuteten Verbindungsproblemen wenden Sie sich bitte an Ihren ISP. Dieser kann im Anlassfall die weiteren beteiligten Teilnehmer kontaktieren, um ein allfälliges Problem zu lokalisieren.

Traceroutes sind Bündel von IP-Paketen mit aufsteigender TTL, die die entsprechenden Router im Pfad dazu bewegen sollen, ICMP Unreachables vom Typ "TTL expired" zu erzeugen und diese zurück an den Absender der IP-Pakete (also denjenigen, der das Traceroute macht) auf den Weg zu schicken. Diese Unreachables, entsprechend durch die Traceroute-Software ausgewertet, geben Hinweise auf einen eingeschlagenen (Hin-)Weg durch das Internet.

Beachten Sie aber, dass Asymmetrien in Hin- und Rückweg damit nur vermutbar bzw. gar nicht erkennbar sind, und der Rückweg teilweise über ganz andere Routen verlaufen kann. Weiters: Aus Schutzüberlegungen für das eigene Netz erlauben manche ISPs ihren Routern die Antwort auf solche Anfragen nicht, oder sie beantworten nur eine bestimmte Gesamtanzahl pro Zeiteinheit. Im Übrigen gilt das Gleiche wie für ICMP Echo Requests.