AMS-IX operates a series of Internet Peering Exchanges (IXs) globally and partners with Megaport in several cities. IXs provide greater efficiency between networks and allow for traffic to be exchanged directly, thereby reducing bandwidth usage on client’s Internet connections. Traditionally the domain of Internet Service Providers, more enterprises are beginning to explore this solution. For those unfamiliar with IX peering as a concept, detailed information can be found in our previous article.
Joining an IX is just as easy as deploying most other services with Megaport; you deploy a VXC from your chosen port to your selected destination IX. To do this, in your Megaport account, select your port, click ‘+ Connection’. To connect to Megaport/MegaIX locations select ‘Internet Exchange’. You will then be presented with the IX selection screen to choose your MegaIX from.
If you are connecting to an AMS-IX location, click Cloud. For the purposes of this article, we will select AMS-IX.
Select the AMS-IX location to which you want to peer and then click Next in the lower right-hand corner. In this example, we will choose AMS-IX Chicago.
On the Connection Details stage, you will be able to fill in the following details:
Name Your Connection – A free text field allowing you to assign an easily identifiable name for this connection.
Rate Limit – The speed in Mbps for this connection (up to the maximum speed of the Port).
Preferred A-End VLAN – The VLAN for this connection that you will receive via the port. This must be a unique VLAN ID on this Port. You can also select the toggle to “Untag” this VXC. This will remove the VLAN tagging for this connection but will also mean only one (IX) VXC can be deployed on this Port.
Select ‘Next’ and you will be able to configure the IX specific details.
On this screen you will be able to fill in the following details:
Peer with Route Servers – The goal of the route server is to facilitate the implementation of peering arrangements. Normally, you need to maintain separate BGP sessions to each of your peers’ routers. With a route server, you can replace all or a subset of these sessions with one session towards each route server.
There are two main types of IX peering arrangements: multi-lateral and bi-lateral. A multi-lateral session is when you connect to BGP peer with the available route servers, whereby you will advertise your routes towards the route servers, and all routes available from all other multi-laterally peered connections will be advertised towards your peer from the route servers. The second type is bi-lateral peering which is by arrangement, and is required for specific peers that do not participate in multi-lateral peering via the route servers.
Detailed information including BGP peering addresses for AMS-IX route servers can be found here.
Select ‘Yes’ unless you plan to only bring up bilateral sessions.
Peering Policy – An IX member’s peering policy and policy URL go hand in hand and are generally used when other members want to peer with you.
- Open: The member opens peering on simple demand from any member present on the IX. Generally open to all requests.
- Closed: The member evaluates every demand before opening the peering. Generally closed to all requests.
- Restrictive: The member publishes restrictive objective criteria the other member has to meet in order to establish a peering. See Policy URL.
Policy URL – If you do have a peering policy, enter the URL for where the policy can be found. If you do not have a policy, you can simply enter your website here or a link to your peeringdb page.
Company Information – Please update the fields to provide the requested contact information.
Once you are happy with the configuration, simply select ‘Next’, add this service to your cart and proceed to checkout as normal. After deployment, an email will be sent to your registered email address with additional information on how to finish the BGP configuration.
Standard BGP implementations require the first ASN in the path to match the ASN of the peer, however, when engaged in multi-lateral peering, the first ASN will not be that of the peer (RS) but that of the downstream peer providing the routes. This is expected behaviour and is required in order to reduce AS path lengths for correct routing decisions. In order to correctly allow multi-lateral peering to proceed without issue, please configure your devices to not enforce the first AS requirement – such a command will be ‘no bgp enforce-first-as‘ or similar (Cisco).
Allowed Traffic Types on Unicast Peering LANs
Important: The AMS-IX NOC reserves the right to disable ports that violate the rules detailed here.