home | Participants & Partners | VIX Participation | How to join VIX
last change: November 14, 2019

How to join VIX: A Step-by-Step Instruction

First of all, please note that the Vienna Internet eXchange does not serve as an upstream connectivity provider! We offer peering only, not transit.

1. Preparations
1.1 Get your numbers
1.2 Choose your VIX location(s)
1.3 Choose your connection speed

2. Formalities
2.1 Connection Agreement
2.2 Setup Fee
2.3 Portal Account
2.4 Mailing List

3. Setup Process - Part I
3.1 Physical Connection
3.2 Configuration
3.3 Quarantine Stage

4. Setup Process - Part II
4.1 Moving into Production
4.2 Further BGP Peerings
4.3 ICMP Pings
4.4 Reverse DNS Entry

5. Common Pitfalls
5.1 no bgp enforce-first-as
5.2 Wrong TTL

1. Preparations

1.1 Get your numbers

Make sure that you meet the requirements: You need an AS number, IP address space, and global connectivity. If you don't have that yet, please turn to RIPE.

1.2 Choose your VIX location(s)

The Vienna Internet eXchange is present at three locations in Vienna. To connect to VIX you need to install a BGP4 peering router at at least one of these sites. Alternatively, you might use a carrier or a VIX reseller. In this document, however, we only consider direct participation.

It is advisable to connect at more than one VIX site. If you choose VIX1 and one other site you are, under certain conditions, eligible for a dual-site discount.

1.3 Choose your connection speed

VIX offers connections only via single-mode fiber and only at speeds of 2.5 Gbps, 10 Gbps and 100 Gbps. The physical interfaces used at VIX are either 10GBase-LR or 100GBase-LR4.

2.5 Gbps are achieved by rate-limiting a 10 Gbps connection. Thus, if you subscribe to 2.5 Gbps only, you will actually connect to a 10 Gbps port. For lower speeds you may turn to a VIX reseller and see what they have to offer.


2. Formalities

2.1 Connection Agreement

First, you need to create a connection agreement draft. This is done by filling in the corresponding webform. As you complete the form a PDF is generated and sent to you and to us for review. Afterwards, we will contact you to discuss the details.

When all questions have been cleared up you need to print the agreement twice, sign both copies and send them to:

Vienna University Computer Center
ACOnet & Vienna Internet eXchange
Universitaetsstrasse 7
1010 Vienna
Austria

We will sign them as well and return one copy to you.

If you merely wish to change an existing agreement, e.g. to add more ports, you can expedite the process by sending us a scan of the signed agreement by e-mail (in addition to the paper work). New customers who need to save a few days also have this option. However, setup works will not commence until your setup fee has been received (see section 2.2).

Once the connection agreement is signed, it has legal validity. Thus, if any information contained in the agreement changes, a new (modified) agreement must be generated and signed (or, at least, a legally signed addendum must be sent by post). This is quite simple if you log into the VIX portal (see section 2.3), as most information will be pre-filled in the contract generation form.

2.2 Setup Fee

New customers are required to pay a setup fee of EUR 1000 before we start committing resources. As soon as we have received your signed agreement (two copies) and your payment of the setup fee we will get to work on your connection. To do this, we will ask you for some more information (see section 3).

2.3 Portal Account

As a VIX participant, you need at least one account at the VIX portal. In fact, we encourage multiple portal accounts per participant - they are free of charge, so don't be shy. To receive a VIX portal account, please complete the request form and follow the instructions on that web page. To verify that you are eligible for an account we will contact one of the administrative contacts named in your connection agreement.

In the portal you can view statistics, activate or deactivate the use of our route servers (we strongly recommend to use it), configure their default peering behavior and peerings with other participants and find some hints for troubleshooting.

2.4 Mailing List

"vixoper@vix.at" is a low-volume mailing list for announcements of maintenances, new or leaving participants etc. It would be a good idea for technical staff to subscribe to this moderated list. You can do that in the web portal.


3. Setup Process - Part I

3.1 Physical Connection

The procedure to establish the physical connection depends on the site you are connecting at:

  • VIX1: If you already have equipment at VIX1, simply tell us which interface to connect to at your Meet-Me panel. If you have no equipment on-site, you will need to negotiate a housing agreement, first. Housing is readily available there for non-active equipment, but power-hungry devices should be kept to an absolute minimum, as power (and cooling) supply is limited. Please write to noc(at)vix.at for inquiries.

  • VIX2: If you are present at Interxion, simply tell us the patch coordinates for your cross-connect. We will then order it from Interxion. The fee for the cross-connect is already included in your monthly participation fee. A LOA (Letter Of Authority) is helpful or, in some cases, absolutely necessary.

  • VIX3: At e-shelter, you will need to order the cross-connect yourself. We will provide you with the necessary patch coordinates and LOA (Letter Of Authority) to do so.

3.2 Configuration

We will provide you one IPv6 and one IPv4 address for your interface on the peering LAN. Please configure it accordingly and make sure that any funny services are turned off. You should use only IP (v4 and v6), IPv6 ND and ARP, but nothing else (no cdp, no spanning tree, no v6 router advertisements, etc.). See our page on Best Current Practices for more information.

We apply access filters based on your interface's MAC address. Thus, if one day you need to exchange your equipment, you should remember to advise us of any changes to your MAC address!

For our setup, we also need your AS-Sets and a realistic number of prefixes you intend to announce (we can also obtain this information from PeeringDB).

3.3 Quarantine Stage

We put every newly setup interface in a quarantine VLAN for a few days to make sure the physical connection is stable and no unwanted packets (cdp, ra, etc.) are coming down the line. This is the time to ping about a bit (we will provide you appropriate ping destination IPs), and it is also the time to setup BGP sessions with our route servers (see section 3.3.1). This helps us ascertain that things basically work, including personal communication.

Later, when your interface has been moved into the production peering VLAN (see section 4), the sessions with our route servers will continue seamlessly.

3.3.1 BGP setup in quarantine

In quarantine, you should configure direct peerings with our redundant route servers:

  • AS number: 1121
  • IPv4: 193.203.0.251/23 and .252/23
  • IPv6: 2001:7f8:30:0:1:1:0:1121 and 2001:7f8:30:0:2:1:0:1121

Please note that the peering LAN is a /23 subnet and make sure you send BGP packets to our route servers with no other TTL than 1 or 255 (see section 5.2)!

You will need a MD5 password hash to configure the session. You may request a specific password, or we will set a random one.

3.3.2 Quarantine for additional ports

When an existing participant orders additional ports, the new ports need to go through quarantine as well. After all, they are new interfaces whose correct configuration and orderly operation need to be ascertained.

However, these ports usually are not assigned IPv4 addresses from the 193.203.0.0/23 range. After all, they often will be added to a LAG and will not need public IPs. Instead you will be given numbers from the 10.255.254.0/23 range for testing in quarantine.


4. Setup Process - Part II

4.1 Moving into Production

To be quite clear: Any issues with the connection must be resolved before we will move your interface into the production (peering) VLAN. This includes MAC access filters, no cdp packets on the line, sane numbers of announced prefixes and working BGP sessions with the route servers.

Before moving a new participant into production, we deactivate their use of the route servers. To re-activate them simply log in to the VIX portal and check the respective checkboxes for using IPv4 and IPv6 route services. By doing so, you also assume responsibility for your own peering setup.

At this point you can also choose your default peering behaviour, i.e., whether you want to peer with every participant that lets you except for those you explicitely de-select; or whether you want to peer only with those you explicitely activate.

4.2 Further BGP Peerings

In the production VLAN, we would like you to configure a few direct peerings:

  • VIX Service Network - AS1120@193.203.0.25 / 2001:7f8:30:0:1:1:0:1120
  • ACOnet - AS1853@193.203.0.1 / 2001:7f8:30:0:1:1:0:1853
  • ACOnet - AS1853@193.203.0.2 / 2001:7f8:30:0:2:1:0:1853

These peerings are necessary for monitoring the connection and for generating the statistics you find in the VIX portal.

4.3 ICMP Pings

Our monitoring system relies on the ability to ping your interface. Please make sure your interface doesn't discard ICMPs neither from the peering LAN (193.203.0.0/23 and 2001:7f8:30:0/64) nor from our monitoring LAN (193.170.1.0/24 and 2001:628:100::/48).

4.4 Reverse DNS Entry

You will probably want to have a reverse DNS entry for the IP numbers we provide you with, to make traceroutes more readable. Simply write us the FQDN you want.


5. Common Pitfalls

First things first: Be aware of our Best Current Practices page!

5.1 no bgp enforce-first-as

One very common pitfall is the fact that when using the route servers the first hop in the AS path is not authorized to announce the participants' ASNs. On your equipment you might need to disable this behaviour by issuing a "no bgp enforce-first-as" command. Otherwise it would typically result in BGP sessions being established but no prefixes being received.

5.2 Wrong TTL

Another common mistake is to send BGP packets with a wrong TTL. BGP packets to the route servers must have a TTL of either 1 or 255.