IXLeeds is based on a Cumulus and Extreme platform.
We operate a Cumulus based 10Gbit switch that is linked on a 20G aggregated connection to our copper port switch, an Extreme X440. We plan capacity within the network such that we never fill links between switches.
Our current site is aql Leeds DC2 although we will consider expanding to other sites should they become viable.
Connection is relatively straightforward as we are a simple layer 2 platform and your router can directly reach the edges of the other participants.
We support 1 gigabit over copper and 10 gigabit over single mode fibre connections to our fabric.
Here is an example configuration for a Cisco switch port:
interface TenGigabitEthernet0/2 description IXLeeds switchport access vlan 774 switchport mode access switchport nonegotiate no cdp enable no lldp transmit no lldp receive spanning-tree bpdufilter enable end
Here is an example for a Cisco router:
interface Vlan774 description IXLeeds ip address 10.123.45.67 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp ipv6 address 2001:DB8:67::FFFF:1/64 ipv6 nd dad attempts 0 ipv6 nd prefix default no-advertise ipv6 nd ra suppress no ipv6 pim end
The first thing you want to configure is a connection to our collector. This router will send you no routes, but gives us a very important diagnostic view into how your side is configured.
IPv4: 188.8.131.52 IPv6: 2001:7f8:67::1 AS: 51526
If you haven't already got one, then we really recommend creating a PeeringDB account. It contains details of other networks peering and contact data, and allows you and them to automate the process of creating the sessions that will interlink your networks. Being present on PeeringDB even if you don't use this automation yourself will greatly increase your chances of having peering requests accepted.
We operate route servers that make exchanging routes with other participating members a lot easier.
IPv4: 184.108.40.206 and 220.127.116.11 IPv6: 2001:7f8:67::2 and 2001:7f8:67::3 AS: 57932
If you're running Cisco, you will want "no bgp enforce-first-as" in your BGP configuration. This stops it enforcing the first AS in the received AS path being the same as the peer's AS. Other vendors will have equivalent commands. Without it, your route server connection probably won't establish.
The route servers filter against IRR data, and you can use communities to influence the propagation of your routes.
|Send your prefix to all participants||None|
|Send your prefix to a RS participant with a specific AS||57932:ASN|
|Do not send your prefix to a RS participant with a specific AS||0:ASN|
|Do not send your prefix to anybody||0:57932|
Should you want to send your routes to only specific peers, you will need to add the global deny community
0:57932 to your prefix, for example to only advertise to AS 1234, you would tag your route with