Frequently Asked Questions (FAQ)

The Vienna Internet eXchange (VIX) is a highly available peering infrastructure for Internet Service Providers, Cloud Providers, Content Providers, Content Delivery Networks and Research and Education Networks in Austria and the Central and Eastern European region. It is used by its participants to exchange Internet traffic at the regional level. The University of Vienna operates the redundant VIX infrastructure at three sites in Vienna, ensuring a neutral, robust, high-performance peering environment for all participants.

• more

In addition to national and international Internet Service Providers and Research and Education Networks, Cloud Providers, Content Providers and Content Delivery Networks are also welcome at VIX (see the list of participants).

Yes, IPv6 is productive at VIX since 2005. This means that all VIX Connection Agreements are valid for IPv6 as well as for IPv4. If you want to enable IPv6 peerings on your VIX interface, please contact us at noc (at) vix.at. We will be happy to send you a suitable IPv6 address for your interface and include this address in our database.

A 10 Gbps port on the VIX does not mean that you have a 10 Gbps Internet connection. The amount of Internet traffic that you can handle through VIX depends primarily on the type and number of your peering agreements with other VIX participants.

There is a non-recurring setup fee of 1000 EUR (as of 06/2021) once per contract. The monthly port costs depend on the number and speed of the requested ports. Participants with connections at two VIX sites (including VIX1) may, under certain conditions, receive a dual-site discount.

• more

No, the setup fee is charged only once per contract.

VIX, as a neutral Internet Exchange Point, provides only a complementary peering infrastructure. Commercial agreements between participants - involving physical VIX infrastructure - are not prohibited, but are not supported by VIX.

In our experience, this decision depends on several circumstances, including: Does the potential participant already have infrastructure at a VIX location? If not, how expensive is it to set up a connection? Is it economically reasonable? Does the potential participant follow a policy that states, for example, that there are only private interconnects to non-Tier 1 networks?

Sometimes a decision to participate in VIX is also triggered by expressions of interest from existing participants. Therefore, it may be useful to communicate such considerations to the appropriate peering contact of the desired network. Usually these contacts can be found in the PeeringDB. We gladly accept suggestions for connecting a specific network to VIX, but ask for your understanding that we cannot make any statements or even promises in this regard.

The essential precondition for a connection to VIX is a unique AS (Autonomous System) Number with an already established global Internet connectivity. Participants are expected to use their VIX connection as a complementary tool for optimizing regional Internet traffic flows. The only permitted routing protocol on the VIX infrastructure is BGP4.

• more

Unfortunately, no. As with any other Internet Exchange Point, a unique AS Number is a technical necessity for peerings at VIX. The reason is that VIX uses the Border Gateway Protocol (BGP) as a routing protocol, and BGP requires distinct AS numbers.

The Border Gateway Protocol (BGP) is the default routing protocol used by Internet Service Providers to exchange routes and routing information between Autonomous Systems. At VIX, BGP is the technical basis for bilateral peering agreements between participants.

• more

Only the BGP routing protocol allows you to exchange routing information (and thus also IP traffic) with other VIX participants.

Yes, via "Remote Peering". This means that a carrier of your choice provides a connection via a transparent Layer2 Ethernet Service which allows you to connect your peering router to VIX, even over long distances. You are the contractual partner of the carrier and also of VIX, and thus accountable to VIX for the quality of your remote connection. We reserve the right to turn off an unstable remote line if it compromises the stability or operation of the Exchange Point.

The current VIX hardware platform is built for physical bandwidths of 10 and 100 Gbps. Each bandwidth transition contains conflict potential in terms of queuing, buffering, etc. Lower connection bandwidths are probably offered by a reseller who handles these transitions - adapted to the circumstances - in his own network.

It's an organization that has made a separate agreement with VIX to divide its physical connection into several logical connections with agreed individual bandwidths. These logical connections are then freely offered to other suitable participants - generally uplink and connection as a package. The contractual relationship is concluded between the participant and the reseller. Participants who are connected to VIX via a reseller will of course (to an adapted extent) also receive appropriate support from the VIX NOC.

All necessary steps are described in detail on the Formalities page.

The VIX team will process your Connection Agreement and contact you within 5 working days. If you are planning to connect at Digital Realty or NTT, you can already initiate the required patch in the meantime (see next two items).

When establishing your connection, please tell us your patch coordinates at Digital Realty and send us a suitable LOA (Letter of Authorization). For remote peerings with a carrier connection, we need this from your carrier. The patch is ordered from Digital Realty by the VIX NOC and is included in the participation fee (as of 06/2021).

Please order the patch directly from NTT, with CC to noc (at) vix.at. Simply indicate "Vienna Internet eXchange" as destination point and pass on the data about device and port number given by us.

At VIX, two variants have been established which can be used independently by each participant:

• VIX route servers:
  If you use our route servers, every other participant has the possibility to view your respective peering policy with them - from non-participation to default peering with all. You don't have to use the route servers. However, we recommend it because the administration effort decreases drastically and traffic can be exchanged quickly with other participants. Besides, we recommend setting up additional bilateral peerings to those VIX participants that appear to be particularly important for your own network.
• Bilateral peerings:
  Direct peering between participant routers, freely agreed between two participants. Try to contact the peering team of the desired VIX participant in order to conclude a (mostly informal) agreement.

Basically by PDF to the specified billing contact. The invoice contains VAT, which (if applicable) can be claimed as input tax. Please ensure that your payment is received free of charge. Any deducted bank charges will be offset against the next invoice run.

Please contact buchhaltung (at) vix.at.

Your Profile shows your own data. Using the web interfaces for the Route Servers, you can configure peerings with just a few mouse clicks. The Network Status section includes peering traffic analyses, port statistics, and a Layer2 view.

• more

Yes, you can find such a list at the web portal (menu item Network Status / Layer2 View).

Yes, this information is available in the web portal (menu item Network Status / Peering Traffic).

You need a valid portal account to access the VIX web portal. Since November 2015, the e-mail address that was used and disclosed in your portal account application has to be entered as your username when logging in.

Usernames and passwords created before November 2015 are no longer valid. In this case, please set a new password using the "Forgot your password?" function at the login page.

• If you don't receive an e-mail from the "Forgot your password?" function, please check your spam folder first. If you can't find the message there, you probably do not yet have a portal account, or there is a different e-mail address registered with your portal account. Please contact webmaster (at) vix.at.
• If you have already reset your password, but have received the message "Login failure. You don't have permissions to access the VIX web portal." after the login, you are known as a contact person of a VIX participant, but do not yet have a portal account. Please send us a completed application form to gain access to the web portal.
• In all other cases please contact webmaster (at) vix.at with a detailed error description.

In the course of this standard procedure, it is checked whether a connection complies with the guidelines/BCPs and whether the BGP announcements are within reasonable limits. So this is a contribution to operational safety. After adjusting the self-selected MD5 secret, you may continue to use the quarantine settings for using the route servers in the Peering LAN - the IP numbers there are identical.

There are three route servers in the quarantine setup that simulate the ACOnet routers in the Peering LAN. Once you have successfully established a BGP connection to these route servers, we will test your announcements and filter settings. When we subsequently move you into the Peering LAN, these test peerings automatically become true peerings with the ACOnet networks.

The three test devices are to be configured as follows (the respective MD5 password will be provided to you):

• AS Number 1853 ACOnet Backbone: IP Address 193.203.0.1
• AS Number 1853 ACOnet Backbone: IP Address 193.203.0.2
• AS Number 1120 ACOnet/VIX Service: IP Address 193.203.0.25

Site-specific BGP communities serve to optimize traffic flows between VIX participants.

• more

The Spanning Tree Protocol is designed to prevent Ethernet loops within an organization, but not on Internet Exchange Points. We use other techniques to ensure that no loops can affect the IXP infrastructure.

• more

At an Internet Exchange Point, each participant port is designed to connect exactly one peering router. If a VIX participant is sending data packets from more than one MAC address this usually indicates a misconfiguration. In many of these cases, a loop occurs that could theoretically paralyze the operation of the Exchange Point. We prevent this by ignoring traffic from unregistered MAC addresses for security reasons.

If the MAC address changes, please make sure you give us the new address! In emergency situations this can also be done via telephone or outside office hours via voicemail message (see "How can I contact the VIX NOC?").

One reason may be that the route servers are not activated in the web portal. Someone in your organization whose VIX portal account is qualified as "Route Server Admin" must enable the route servers there. An MD5 secret is obligatory.

If the route servers are enabled and still no peering occurs, the reason is probably the TTL. Please make sure that the TTL of the peering session is 1 or 255.

On some platforms, a known issue with "bgp enforce-first-as" also leads to a termination of the peering session - please check and correct if necessary! If that doesn't help, please contact the VIX NOC.

Some router manufacturers have the default setting in their software to compare the first AS of the received route with the AS of the peer. If these are not identical, the route is marked as invalid. The route server has its own AS, but does not add it to the path. Please configure your router accordingly, e.g. "no bgp enforce-first-as".

The most common reasons for this behavior are:

• The participant does not use the route servers, or has a peering policy that prevents any exchange with your AS. This can be seen in the configuration of the route servers in the web portal.
• The prefixes are not, or not properly, registered in the RIPE database (inetnum with matching route-object). Please contact the peering team of the other AS. If it is a network from another RIR, you can also change the peer in the route server configuration so that you get all the prefixes from this AS - whether documented or not.

This occurs especially with Content Delivery Networks (CDNs). It is then part of the CDN's load sharing concept not to announce everything on every POP.

There is often a configuration error behind it, but sometimes it is malicious intent. Please check your documentation in the RIR first. The VIX route servers shouldn't pass on such announcements if the receiving participants have activated the RIPE filter option. However, you'll have to contact the source of the misannouncements and ask them to stop. The VIX NOC can help to find the contact, but we don't have any authorization whatsoever to request changes, especially if it is not a VIX participant.

First, try to find out if it's a volume attack or legitimate traffic. The identification of the source peer in the VIX web portal can help with this distinction. In the case of legitimate traffic, traffic engineering (i.e. the processing of traffic via other routes) might provide a short-term remedy. In the medium term you should consider an upgrade of your VIX connection. In the event of an attack, all that remains is other mitigation (e.g. in the transit network) or a shutdown of the source(s) - but this can be quite laborious or practically infeasible. In any case, all these measures are beyond the control of VIX.

This is most likely a download via QUIC and not an attack.

In most router types, an answer to ICMP echo requests is given by the control plane - this is the part of a router that is busy, among other things, exchanging information with other routers about available paths on the Internet and making decisions about paths it uses itself. In its role as the central point of a router, this control plane is normally protected against load that does not directly serve the operational purpose. In other words, a participant router has enough other things to do than answer pings from somewhere - so sometimes, depending on the situation, it just doesn't answer.

Because of this behavior, echo requests (or replies) do not allow any conclusions about a connection problem or the performance of the network - only the participant's NOC can clarify this. If you suspect connection problems, please contact your ISP. If necessary, the ISP can contact the other participants involved in order to locate a possible problem.

Traceroutes are bundles of IP packets with ascending TTL that are supposed to cause the corresponding routers in the path to generate ICMP unreachables of the type "TTL expired" and send them back to the sender of the IP packets (i.e. the initiator of the traceroute). These unreachables, evaluated by the traceroute software, give hints on a chosen (outward) path through the Internet.

Please note, however, that asymmetries in the outward and return routes can only be assumed or are not recognizable at all, and that the return path can partly run over completely different routes. Moreover, due to protection considerations for their own network some ISPs do not allow their routers to respond to such requests, or they only answer a certain total number of requests per time unit. Beyond that, the same applies as for ICMP Echo Requests (see previous question).