This guide explains how to connect and peer correctly across our Internet Exchange Points.
All sites use IXP Manager and BIRD Route Servers.
Support & Contact
For any technical or peering support:
support@canix.ca
General Recommendations
- Keep your PeeringDB profile up to date. It is a good practice and also required to establish peering with certain networks.
- Use PeeringDB Single Sign-On (SSO) to access the member portals for each IXP.
- Configure your routers with valid IRR and ROA entries — route servers will only accept validated prefixes.
Interface Configuration Best Practices
Disable Layer 2 Protocols
Disable all protocols that generate control or discovery traffic on the exchange fabric:
no lldp transmit
no lldp receive
no cdp enable
no spanning-tree portfast
no spanning-tree bpduguard disable
no spanning-tree guard none
- No BPDUs: STP (Spanning Tree Protocol) frames must not be sent or processed.
- No CDP/LLDP: Disable link discovery advertisements.
- No LACP or port-channeling on peering interfaces unless explicitly supported.
IPv6 Router Advertisements
Do not send IPv6 Router Advertisements (RA) on the peering interface.
The exchange fabric is not a routed network.
Use static addressing only.
Recommended Interface Settings
| Setting | Recommendation |
|---|---|
| Dot1q | This depends on your specific cirucit configuration. We typically recommend using Dot1q (trunk) ports for maximum flexibilty to enable multi-service ports. |
| MTU | 1500 (standard Ethernet) |
| Speed/Duplex | Fixed (no auto-negotiation if possible) |
| VLAN | Varies on your port configuration |
| IPs | Use addresses assigned via IXP Manager |
| Filters | Block ARP/NDP storms and non-BGP traffic |
To ensure a stable and safe peering LAN, all participants must follow the same Layer 2 guidelines, consistent with AMS-IX, LINX, and other major IXPs.
Each member is responsible for ensuring their interface behaves as a clean, BGP-only endpoint.
Route Server Peering
Each IXP operates two redundant route servers (RS1 and RS2).
These route servers are for multilateral peering — they simplify peering by automatically exchanging routes with other connected members.
For redundancy, peers should peer with both route servers.
| IXP Location | RS ASN | RS1 IPv4 | RS1 IPv6 | RS2 IPv4 | RS2 IPv6 |
|---|---|---|---|---|---|
| Montreal | AS55176 | 198.179.18.249 | 2001:504:2d::18:249 | 198.179.18.250 | 2001:504:2d::18:250 |
| Toronto | AS25858 | 149.112.135.253 | 2602:f777:400::135:253 | 149.112.135.254 | 2602:f777:400::135:254 |
| Ottawa | AS18655 | 206.82.110.1 | 2001:504:96::110:1 | 206.82.111.1 | 2001:504:96::111:1 |
| Quebec City | AS15037 | 149.112.119.253 | 2602:f777::253 | 149.112.119.254 | 2602:f777::254 |
BGP Communities
Both standard (16-bit) and large (32-bit) BGP communities are supported.
However, we recommend using large communities going forward.
Tip: The ASN in the community examples below changes depending on which IXP you peer with.
For example, replace rs-asn with 55176 for Montreal, or 25858 for Toronto.
Standard Communities (for legacy support)
| Description | Community Format |
|---|---|
| Prevent announcement of a prefix to a peer | 0:peer-as |
| Announce a route to a specific peer | rs-asn:peer-as |
| Prevent announcement to all peers | 0:rs-asn |
| Announce route to all peers | rs-asn:rs-asn |
Standard Communities example
Example for Montreal (AS55176):
Prevent to all peers: 0:55176
Announce to all peers: 55176:55176
Large BGP Communities (recommended)
| Description | Community Format |
|---|---|
| Prevent announcement of a prefix to a peer | rs-asn:0:peer-as |
| Announce a route to a specific peer | rs-asn:1:peer-as |
| Prevent announcement to all peers | rs-asn:0:0 |
| Announce route to all peers | rs-asn:1:0 |
Large Communities example
Example (Montreal RS ASN 55176):
Announce to peer AS1234: 55176:1:1234
Announce to all peers: 55176:1:0
Prevent to all peers: 55176:0:0
AS Path Prepending (with Large Communities)
| Description | Community Format |
|---|---|
| Prepend to peer once | rs-asn:101:peer-as |
| Prepend to peer twice | rs-asn:102:peer-as |
| Prepend to peer three times | rs-asn:103:peer-as |
AS Prepending example
Example for Ottawa (AS18655):
- Prepend twice to peer AS1234 →
18655:102:1234
Do not mix standard and large communities on the same prefix.
RFC1997 Passthru
RFC1997 (NO_EXPORT / NO_ADVERTISE)
All route servers have RFC1997 Passthru enabled.
This means you can use well-known BGP communities such as:
| Purpose | Community |
|---|---|
| Do not export beyond this IXP | 65535:65281 (NO_EXPORT) |
| Do not advertise to any peers | 65535:65282 (NO_ADVERTISE) |
These are passed through transparently by the route servers.
Background: RFC 1997 defines these communities and RFC 7947 recommends that IXPs pass them through rather than interpret them.
Quick Summary
| IXP | RS ASN | Use Large Communities Example |
|---|---|---|
| Montreal | 55176 | 55176:1:peer-as |
| Toronto | 25858 | 25858:1:peer-as |
| Ottawa | 18655 | 18655:1:peer-as |
| Quebec City | 15037 | 15037:1:peer-as |
AS Path Policy and “No Enforce First AS”
Our route servers operate in transparent mode, meaning:
- The RS ASN is not included in the AS-PATH of routes you receive.
- Routes are re-advertised as if they came directly from the peer’s ASN.
- This makes routing cleaner and prevents unnecessary path length inflation.
However, some vendor defaults (notably Cisco IOS and IOS-XE) enforce the “first AS” check.
If enabled, your router will reject any routes where the first AS in the path doesn’t match the neighbor ASN — which will happen with transparent route servers.
Solution:
On Cisco routers, use the following command under your BGP neighbor configuration for the route servers:
no bgp enforce-first-as
Without this, your device may ignore all prefixes learned via the RS.
This behavior is normal and expected with transparent route servers across most IXPs globally.
Peering optimization
Some peers not only do not peer via the route servers but require special steps. Once you are connected and live, consider making contact with the following networks if they are available in your CANIX IXP.
Cloudflare
Cloudflare does not advertise all their routes on the route servers. Establish bilateral peering with them at: https://www.cloudflare.com/partners/peering-portal/
Microsoft
Microsoft requires bilateral peering.
– If you wish to go through the process yourself and meet their minimum requirements, you can request peering via the Azure portal https://learn.microsoft.com/en-us/azure/peering-service/about
– If you don’t meet the requirements or want a simpler peering process, contact CANIX to use managed MAPS peering.
Google
Google is moving away from IXP peering in favor of layer 3 services. If you can’t deploy a 100G PNI, contact CANIX to use our partial Layer 3 transit service to Google – a.k.a Google VPP
Amazon
Amazon also require bilateral peering sessions – their portal is available at https://aws.amazon.com/peering/
Other peers
Now that you have established peering with most major networks, consider looking at the Peering Matrix in your IXP’s portal. It will help you spot ASNs that you cannot reach via the route servers so you can reach out to them and establish bilateral peering sessions with them.
Support & Contact
For any technical or peering support:
support@canix.ca
If you wish to chat with peers in your CANIX community, join the CANIX community Slack.