IX: Detailed Infomation

Megaport owns and operates a series of Internet peering exchanges in the majority of our networks globally. 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, information can be found here: https://en.wikipedia.org/wiki/Internet_exchange_point.

There are two main types of IX peering arrangements, multi-lateral and bi-lateral. A multi-lateral session is the default when you connect to MegaIX and means that you will BGP peer with both route servers (RS1 and RS2) for a given IX market, 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 this is required for specific peers that do not participate in multi-lateral peering via the route servers. You may participate in both multi-lateral and bi-lateral peering across the Megaport IX infrastructure.

Joining an IX is the same as everything else with Megaport, you simply deploy a VXC from your chosen Port to your selected destination IX. To do this, select your Port, click the “+ Connection” button and then select the “Internet Exchange” button item. You’ll then be presented with the IX selection screen:

For Megaport/MegaIX locations you may simply select the IX and the below screen will display. If you are connecting to an AMS-IX location click on the ‘Cloud’ from the previous ‘Select Type’ screen and select AMS-IX from the cloud options. For further details on provisioning to AMS-IX please see this related post.

On the first screen presented, 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).

Select Next and you will be able to configure the IX specific details:

Preferred VLAN – The VLAN for this connection that you will receive via the Megaport. 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.

ASN – The Autonomous System Number (ASN) of your network. Please note that this cannot be modified once deployed and may be either a 16 bit or 32 bit ASN (2 or 4 byte) but must be a public AS.

MAC Address – The MAC Address of the Layer 3 Device which will establish the BGP Peering session on our IX. Note that connections to the IX on this VXC will be locked to this address for security purposes. If you do not have the correct MAC available at the time of ordering, you may enter a placeholder MAC such as 00:01:00:01:12:34 as this field remains editable even after deployment.

BGP Password – It is possible to add an optional BGP password to the VXC. This field may be left blank. Note that the BGP password cannot be modified after deployment.

Graph Visibility – Whether you wish to display your traffic graphs in our Looking Glass tool within the Megaport Portal. Public means other clients can see your IX throughput, Private will hide this info from other clients.

Invoice Reference – If you have a particular number or identifier that you require to be reflected on your regular invoices supplied by us, please enter this here.

Once you are happy with the configuration, simply 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).

To prevent customers sending all of the internets routes to us, which is certainly not what they intended to do, we limit customers to the number of maximum prefixes (MaxPFX) that they can send to us.

The default limit is 1000 IPv4 routes and 100 IPv6 routes. Excursions from this value will result in your session being torn down, however, this may be reset upon request via the support team online chat. 

All frames forwarded to the Internet Exchange must:
    • Have the same source MAC address (as entered on the Megaport Portal)
    • Be Ethernet II (“DIX”) frames, with Ethertypes matching either ARP, IPv4 or IPv6
The following frames are not permitted on the Internet Exchange:
    • Multicast and broadcast, with the exception of ARP and IPv6 neighbour discovery
    • Frames resulting from Proxy ARP
    • 802.2 LLC/SNAP frames
    • Layer 2 control and link local protocols such as:
      • All forms of spanning tree
      • Vendor Discovery Protocols (CDP, EDP, FDP, MNDP)
      • UDLD
      • DHCP
      • PIM
      • Layer 2 Keepalives
      • Internal routing protocols (OSPF, ISIS, etc)
    • IPv6 router advertisements
    • ICMP Redirects
MegaIX Route servers do not obey the well known BGP community no-export. This community is passed transparently to the other peers connected to the route server.
Multiple Exit Discriminator values (MED) are considered in the route selection rules only when the advertising ASN is the same for candidate routes. MED values are not modified by the route servers. Values advertised to the route servers are passed unaltered to other peers.
All routes on the IX are given equal local preference by the route servers. The route servers do not compare BGP router ID for best route selection, instead preferring the oldest route when all other attributes are equal.

BGP Communities

MegaIX route servers support a number of traffic engineering communities to assist peers in controlling route preference and distribution. BGP communities in the range
are stripped while all others are passed on to peers.
The following BGP communities affect export policy to peers with 2-byte autonomous system numbers (italics = community values):
◦ 64990:ASN
Do not advertise to ASN

◦ 64991:ASN
Prepend once to ASN

◦ 64992:ASN

Prepend twice to ASN
Extended BGP communities may be used for affect export policy for both 2-byte and 4-byte ASN peers (italics = extended community values):

◦ RT 64990:ASN
Do not advertise to ASN

◦ RT 64991:ASN
Prepend once to ASN

◦ RT 64992:ASN
Prepend twice to ASN

◦ RT 64999:0
Do not advertise this prefix unless explicitly permitted

◦ RT 64999:ASN
Permit this prefix to be advertised to ASN


Looking Glass

Megaport operates a public, web accessible looking glass for peers and network operators to investigate current routing state on the Mega IX. Both the primary and redundant route servers may be queried for live BGP data. The looking glass is available at https://lg.megaport.com

©2020 Megaport. Megaport, Virtual Cross Connect, VXC and MegaIX are registered trademarks of Megaport (Services) Pty Ltd ACN 607 432 646.

Log in with your credentials

Forgot your details?