Ce guide explique comment se connecter et établir du peering correctement à travers nos points d’échange Internet (IXP) au Canada.
Tous les sites utilisent IXP Manager et les route servers BIRD.
Soutien et contact
Pour tout soutien technique ou question liée au peering :
support@canix.ca
Recommandations générales
- Gardez votre profil PeeringDB à jour.
- Utilisez l’authentification PeeringDB SSO pour accéder aux portails membres de chaque IXP.
- Configurez vos routeurs avec des enregistrements IRR et ROA valides — les route servers n’acceptent que les préfixes validés.
- Si vous avez des ASNs en aval, veuillez ouvrir un ticket pour que nous puissions configurer correctement votre AS-SET.
Configuration de l’interface — Bonnes pratiques
Désactiver les protocoles de couche 2
Pour assurer un LAN de peering stable et sécuritaire, tous les participants doivent suivre les mêmes lignes directrices de couche 2, semblables à celles d’AMS-IX, LINX, et d’autres grands IXPs.
Désactivez tous les protocoles qui génèrent du trafic de contrôle ou de découverte sur le fabric d’échange :
no lldp transmit
no lldp receive
no cdp enable
no spanning-tree portfast
no spanning-tree bpduguard disable
no spanning-tree guard none- Aucun BPDU : les trames STP ne doivent pas être envoyées ni traitées.
- Aucun CDP/LLDP : désactivez la découverte de lien.
- Aucun LACP ou port-channeling sur les interfaces de peering, sauf si cela est explicitement pris en charge.
Annonces de routeur IPv6 (RA)
Ne pas envoyer de Router Advertisements (RA) IPv6 sur l’interface de peering.
Le fabric d’échange n’est pas un réseau routé.
Utilisez uniquement des adresses statiques ou assignées via BGP.
Paramètres d’interface recommandés
| Paramètre | Recommandation |
|---|---|
| Dot1q | Ceci dépend de la configuration de votre circuit. On recommande typiquement la configuration du port en mode Do1q (trunk) pour avoir un maximum de flexibilité et l’activation de fonctionalités multi-services. |
| MTU | 1500 (Ethernet standard) |
| Vitesse / Duplex | Fixe (pas d’auto-négociation si possible) |
| VLAN | Selon votre configuration de port |
| Adresses IP | Celles assignées via IXP Manager |
| Filtres | Bloquer les tempêtes ARP/NDP et le trafic non-BGP |
Chaque membre est responsable d’assurer que son interface agit comme une interface d’interconnexion externe propre.
Informations sur les Route Servers
Chaque IXP opère deux route servers redondants (RS1 et RS2).
Ces serveurs facilitent le peering multilatéral, en échangeant automatiquement les routes entre tous les membres connectés.
Pour la redondance, les pairs doivent établir une session avec les deux route servers.
| Localisation IXP | ASN du RS | RS1 IPv4 | RS1 IPv6 | RS2 IPv4 | RS2 IPv6 |
|---|---|---|---|---|---|
| Montréal | 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 |
| Québec | AS15037 | 149.112.119.253 | 2602:f777::253 | 149.112.119.254 | 2602:f777::254 |
Conseil : Remplacez rs-asn par l’ASN du site correspondant (p. ex. 55176 pour Montréal, 25858 pour Toronto).
Communautés BGP
Les communautés BGP standard (16 bits) et larges (32 bits) sont toutes deux prises en charge.
Nous recommandons fortement d’utiliser les communautés larges.
Communautés standard (à éviter si possible)
| Description | Format de communauté |
|---|---|
| Empêcher l’annonce d’un préfixe à un pair | 0:peer-as |
| Annoncer une route à un pair spécifique | rs-asn:peer-as |
| Empêcher l’annonce à tous les pairs | 0:rs-asn |
| Annoncer à tous les pairs | rs-asn:rs-asn |
Exemples:
Exemple de communautés BGP standard
Empêcher à tous les pairs : 0:55176
Annoncer à tous les pairs : 55176:55176
Communautés BGP larges (recommandées)
| Description | Format de communauté |
|---|---|
| Empêcher l’annonce d’un préfixe à un pair | rs-asn:0:peer-as |
| Annoncer une route à un pair spécifique | rs-asn:1:peer-as |
| Empêcher l’annonce à tous les pairs | rs-asn:0:0 |
| Annoncer une route à tous les pairs | rs-asn:1:0 |
Exemple de communautés BGP larges
Exemple Montréal (RS ASN 55176) :
Annoncer à un pair AS1234 : 55176:1:1234
Annoncer à tous les pairs : 55176:1:0
Empêcher à tous les pairs : 55176:0:0
AS-Path Prepending (avec communautés larges)
| Description | Format de communauté |
|---|---|
| Préfixe prepended une fois | rs-asn:101:peer-as |
| Préfixe prepended deux fois | rs-asn:102:peer-as |
| Préfixe prepended trois fois | rs-asn:103:peer-as |
Exemple de prepending (communautés larges)
Exemple Ottawa (AS 18655) :
Prépend deux fois vers le pair AS1234 →18655:102:1234
Ne mélangez pas les communautés standard et larges sur un même préfixe.
RFC 1997 Passthru
RFC 1997 Passthru (NO_EXPORT / NO_ADVERTISE)
Tous les route servers ont RFC 1997 Passthru (NO_EXPORT / NO_ADVERTISE) activé
Vous pouvez donc utiliser les communautés BGP bien connues :
| But | Communauté |
|---|---|
| Ne pas exporter au-delà de cet IXP | 65535:65281 (NO_EXPORT) |
| Ne pas annoncer à aucun pair | 65535:65282 (NO_ADVERTISE) |
Ces valeurs sont transmises telles quelles par les route servers, sans interprétation.
Conformément à RFC 7947, les IXPs devraient les passer plutôt que les filtrer — nous appliquons cette recommandation.
Résumé rapide
| IXP | ASN du RS | Exemple de communauté large |
|---|---|---|
| Montréal | 55176 | 55176:1:peer-as |
| Toronto | 25858 | 25858:1:peer-as |
| Ottawa | 18655 | 18655:1:peer-as |
| Québec | 15037 | 15037:1:peer-as |
Politique AS-Path et « No Enforce First AS »
Nos route servers fonctionnent en mode transparent :
- L’ASN du RS n’est pas inclus dans le chemin AS-PATH.
- Les routes sont ré-annoncées comme si elles venaient directement du pair.
- Cela rend la topologie plus propre et évite l’allongement artificiel du chemin.
Cependant, certains systèmes (notamment Cisco IOS / IOS-XE) appliquent par défaut la vérification du « First AS ».
Si cette option est activée, votre routeur refusera les routes dont le premier AS ne correspond pas au voisin — ce qui arrivera avec un RS transparent.
Solution Cisco :
Dans la configuration BGP de votre voisin vers le RS :
no bgp enforce-first-as
Sans cela, votre équipement pourrait ignorer toutes les routes reçues du RS.
Ce comportement est normal et attendu sur la majorité des IXPs modernes.
Optimisation de peering
Certains réseaux ne se connectent pas aux serveurs de route et nécessitent des étapes particulières afin d’échanger du trafic avec eux. Une fois que votre port est actif, il est recommandé de prendre contact avec ces réseaux si ils sont disponibles dans la même région CANIX que vous.
Cloudflare
Cloudflare n’envoit pas toutes leurs routes sur les serveurs de routes. Configurez vos sessions via https://www.cloudflare.com/partners/peering-portal/
Microsoft
Microsoft ne se connecte jamais aux serveurs de routes
- Si vous rencontrez leurs requis minimum et souhaitez passer au travers du processus vous mêmes vous pouvez commencer le tout ici: https://learn.microsoft.com/fr-ca/azure/peering-service/about
Google
Google se retire activement des échanges Internet. Si vous ne pouvez pas déployer une interconnexion privée de 100G ou plus, contactez CANIX pour utiliser le service de transit partiel Google VPP.
Amazon
Amazon requiert également des sesssions BGP bilatérales. Contactez-les via https://aws.amazon.com/peering/
Autres réseaux
Maintenant que vous avez établit des sessions bilatérales avec la majorité des réseaux d’importance, jettez un coup d’oeil au « peering matrix » disponible dans votre portail CANIX. Cet outil vous montrera visuellement les réseaux disponibles avec qui vous pourriez vouloir vous interconnecter.
Soutien et contact
Pour tout soutien technique ou question liée au peering :
support@canix.ca
Pour prendre contact avec votre communauté d’interconnexion locale, rejoignez le Slack de la communauté CANIX.