Häufig gestellte Fragen (FAQ)

Der Vienna Internet eXchange (VIX) ist eine hochverfügbare Peering-Infrastruktur für Internet Service Provider, Cloud Provider, Content Provider, Content Delivery Networks und Wissenschaftsnetze in Österreich sowie in Mittel- und Osteuropa. Er dient seinen Teilnehmern zum Austausch von regionalem Internetverkehr. Die Universität Wien betreibt die redundante VIX-Infrastruktur an drei Standorten in Wien. Ziel ist es, ein neutrales, robustes Hochleistungs-Peeringumfeld für alle Teilnehmer bereitzustellen.

• mehr

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

Ja, IPv6 ist seit 2005 am VIX produktiv. Alle Anbindungsvereinbarungen (VIX Connection Agreements) sind für IPv6 ebenso gültig wie für IPv4. Wenn Sie IPv6-Peerings auf Ihrem VIX-Interface ermöglichen wollen, kontaktieren Sie uns bitte unter noc (at) vix.at. Wir senden Ihnen gerne eine geeignete IPv6-Adresse für Ihr Interface und nehmen diese Adresse in unsere Datenbank auf.

Ein 10 Gbit/s-Port am VIX bedeutet nicht, 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 1.000 EUR (Stand 06/2021) 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 Dual-Site-Rabatt zu erhalten.

• mehr

Nein, die Errichtungsgebühr wird nur einmal bei Vertragsabschluss verrechnet.

Der VIX als neutraler Internet Exchange Point bietet lediglich eine komplementäre Peering-Infrastruktur an. 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 PeeringDB. Wir nehmen Anregungen, ein bestimmtes Netzwerk an den VIX anzubinden, gerne entgegen, bitten aber um Verständnis dafür, dass wir dazu keine Aussagen oder gar Zusagen machen können.

Die wesentliche Voraussetzung für einen VIX-Anschluss ist eine eindeutige AS-Nummer (AS = Autonomous System) 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

Leider nein. Wie an jedem anderen Internet Exchange Point ist am VIX eine eigene AS-Nummer (AS = Autonomous System) 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 Autonomous Systems ausgetauscht. BGP bildet am VIX die technische Basis für die bilateralen Peering-Vereinbarungen zwischen den Teilnehmern. 

• mehr

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 Anbindung 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.

Alle nötigen Schritte sind unter Formalitäten detailliert beschrieben.

Das VIX-Team wird Ihr Connection Agreement bearbeiten und sich innerhalb von 5 Werktagen bei Ihnen melden. Falls Sie einen Anschluss bei Digital Realty oder NTT 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 Digital Realty 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 diesen LOA von Ihrem Carrier. Der Patch wird vom VIX-NOC bei Digital Realty bestellt und ist in der Teilnahmegebühr enthalten (Stand 06/2021).

Bitte bestellen Sie die Patchung direkt bei NTT, mit CC an noc (at) vix.at. Als Ziel der Patchung nennen Sie einfach "Vienna Internet eXchange" mit den von uns angegebenen Daten zu Gerät und Portnummer.

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

• Route-Server des VIX:
  Wenn Sie unsere Route-Server nutzen, können alle anderen Teilnehmer dort Ihre Peering Policy sehen - von der Nicht-Teilnahme bis hin zum Default-Peering mit allen. 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 Ihr eigenes Netz besonders wichtig erscheinen, zusätzlich bilaterale Peerings zu errichten.
• Bilaterale Peerings:
  Peering direkt zwischen den Teilnehmer-Routern, frei vereinbart zwischen zwei Teilnehmern. Versuchen Sie dazu, mit dem Peering-Team des gewünschten VIX-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.

Unter dem Punkt Your Profile erhalten Sie Einsicht in Ihre eigenen Daten. Mit Hilfe der Web-Interfaces für die Route Servers können Sie Peerings mit wenigen Mausklicks konfigurieren. Der Bereich Network Status bietet unter anderem Peering-Verkehrsanalysen, Port-Statistiken und eine Layer2-Ansicht.

• mehr

Ja, eine solche Liste gibt es im Webportal unter dem Menüpunkt Network Status / Layer2 View.

Ja, das ist unter dem Menüpunkt Network Status / Peering Traffic im Webportal ersichtlich.

Sie brauchen einen gültigen Portalaccount, um auf das VIX-Webportal zuzugreifen. Seit November 2015 ist die Mailadresse, die Sie bei Ihrem Portalaccount-Antrag angegeben und verwendet haben, auch Ihr Benutzername bei der Anmeldung am Webportal.

Benutzername-/Passwort-Kombinationen, die vor November 2015 eingerichtet wurden, sind nicht mehr gültig. Bitte setzen Sie in diesem Fall ein neues Passwort mit der Funktion "Forgot your password?" auf der Login-Seite.

• Wenn Sie von der Funktion "Forgot your password?" keine E-Mail-Nachricht erhalten, überprüfen Sie bitte zuerst Ihren Spam-Ordner. Falls Sie die Nachricht dort nicht finden, haben Sie vermutlich noch keinen Portalaccount, oder Ihrem Portalaccount ist eine andere Mailadresse zugeordnet. Bitte wenden Sie sich an webmaster (at) vix.at.
• Wenn Sie nach dem Setzen eines neuen Passworts beim Loginversuch die Meldung "Login failure. You don't have permissions to access the VIX web portal." erhalten, sind Sie bei uns zwar als Kontaktperson einer Teilnehmerorganisation vermerkt, haben aber noch keinen Portalaccount. Bitte schicken Sie uns ein vollständig ausgefülltes Antragsformular, um Zugang zum Webportal zu erhalten.
• In allen anderen Fällen senden Sie bitte eine genaue Fehlerbeschreibung an webmaster (at) vix.at.

Hier wird standardmäßig überprüft, ob eine Anbindung 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 Peering-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 (das MD5-Secret wird Ihnen jeweils mitgeteilt):

• AS-Nr. 1853 ACOnet Backbone: IP-Adresse 193.203.0.1
• AS-Nr. 1853 ACOnet Backbone: IP-Adresse 193.203.0.2
• AS-Nr. 1120 ACOnet/VIX Service: IP-Adresse 193.203.0.25

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

• mehr

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

An einem Internet Exchange Point ist jeder Teilnehmerport für die Anbindung 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:

• Der Teilnehmer verwendet die Route-Servern nicht oder hat eine Peering-Policy, die einen Austausch mit Ihrem AS verhindert. Dies ist in der Konfiguration der Route-Server im Webportal ersichtlich.
• 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 aufwendig 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.

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 Internet, 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 (siehe vorige Frage).