Layer-2 Connection Guidelines
The following must be followed if you are connecting via a layer-2 device - which we do not recommend:
- You must be sure that only traffic to and from your layer-3 router's interface goes to and from the exchange port
- You must make sure that all legitimate traffic to/from your layer-3 interface goes to/from the exchange port (MLD snooping may block legitimate ICMPv6 neighbor solicitations.)
- You must disable spanning tree on your link to the exchange.
It is recommended that you configure port-based VLANs for your traffic to reduce the chances of something unexpected coming up down the road. We also recommend a dedicated VLAN for this connection for the same reason
Below are some general issues we have run into
Cisco BGP Routers
We have run into multiple scenarios with Cisco devices that require the command no bgp enforce-first-as added to the configuration in order to turn up peering to the route servers
Spanning Tree (STP)
The device(s) connected to the exchange are not allowed to be visible as layer-2 bridges - therefore absolutely no spanning tree or other layer-2 specific protocol
The only allowed routing protocol on the exchange is BGP (Border Gateway Protocol). There is no reason to attempt to use any other protocols over the exchange as none will be allowed
Cisco KeepalivesBorrowed from the ams-ix exchange
By default Cisco routers and switches periodically test their (Fast) Ethernet links by sending out Loopback frames (ethertype 0x9000) addressed to themselves. Call it a "L2 self-ping" if you will. In a switched environment it can be used to test the functionality of the switch and/or keep the router's MAC address in the switch's address table.
In the exchange environment, this is not useful since we use MAC timeouts that are larger than the typical BGP and/or ARP timeouts. In fact, the keepalives may actually cause port security violations if they are being sent by an intermediate switch.
IGMP, DHCP, TFTP (Non-unicast protocols)
The only non-unicast protocol we allow is ARP. Please make sure you have disabled all other mulicast protocols
Proxy ARPBorrowed from the ams-ix exchange
Since traffic over OmahaIX is exchanged based on BGP routes, there is no reason to answer ARP queries for any
other IP address(es) than those that are configured on your exchange interface.
Unfortunately, some vendors (e.g. Cisco) ship their products with proxy ARP enabled by default.
Proxy ARP is not only sloppy, it can lead to unwanted traffic on your network. Consider that if you have it enabled at the AMS-IX, it'll likely be enabled at other peering points, allowing parties on both sides to use you as a transit.
Proxy ARP is not allowed.