Step by Step to VIX
These instructions describe the necessary technical procedures for setting up a local connection to the Vienna Internet eXchange. If you have chosen a remote connection, you should additionally coordinate with your carrier.
Please note that your VIX Connection Agreement must be signed and your setup fee paid before you can start with the steps below (see Formalities for details).
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 NTT, 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. Please send your order as CC also to noc (at) vix.at.
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).
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. This helps us ascertain that things basically work, including personal communication.
Later, when your interface has been moved into the production peering VLAN, the sessions with our route servers will continue seamlessly.
BGP setup in quarantine
In quarantine, you should configure direct peerings with our redundant route servers:
- AS number: 1121
- IPv4: 22.214.171.124/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!
You will need a MD5 password hash to configure the session. You may request a specific password, or we will set a random one.
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 126.96.36.199/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.
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.
Further BGP Peerings
In the production VLAN, we would like you to configure a few direct peerings:
- ACOnet - AS1853@188.8.131.52 / 2001:7f8:30:0:1:1:0:1853
- ACOnet - AS1853@184.108.40.206 / 2001:7f8:30:0:2:1:0:1853
- Service Network AS1120 - AS1120@220.127.116.11 / 2001:7f8:30:0:1:1:0:1120
The peerings with ACOnet are necessary for monitoring the connection and for generating the statistics that you will find in the VIX portal. In addition, we strongly recommend peering with Service Network AS1120: it contains a small number of prefixes that offer useful services (see infobox).
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 (18.104.22.168/23 and 2001:7f8:30:0/64) nor from our monitoring LAN (22.214.171.124/24 and 2001:628:100::/48).
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. Just tell us by e-mail to noc (at) vix.at which FQDN you want.
First of all: Please follow our Best Current Practices to avoid problems!
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.
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.
At VIX, we offer a peering with
AS1120@126.96.36.199 | 2001:7f8:30:0:1:1:0:1120
AS1120 contains a small number of prefixes offering useful services hosted by the Vienna University Computer Center:
- ns5.univie.ac.at and ns10.univie.ac.at (name servers at the University of Vienna)
- ts11.univie.ac.at (NTP/NTS hosted at the University of Vienna)
- German ccTLD root servers (DENIC)
- Brazil ccTLD root servers (BRNIC)
- North Macedonian ccTLD root servers
All of these services are provided for free and we strongly recommend peering with AS1120.
However, please note that the list of services available in AS1120 may change over time.