Bonjour la liste, Le RIPE nous a alloué le mois passé un /21 dédié à nos sites de Bruxelles et du Luxembourg. Ce /21 est déjà annoncé tel quel depuis quelques semaines à nos upstreams (Colt + Verizon) de Bruxelles et sera annoncé tel quel à nos upstreams (EPT + Verizon) du Luxembourg dès ce mercredi.
4 Assignations ont été effectués dans ce /21: 1 /24 par pays (site) pour l'addressage réseau 1 /23 par site pour les différents services offerts Le problème est que si nous ne cassons pas ce /21 en les différents sous-réseaux définis ci-dessus nous allons faire face à quelques problèmes menant à des incohérences de routages. Un exemple parmi d'autres est le suivant: Nous avons des VPN's avec nos partenaires à Bxl ainsi que des backups de chacuns de ces VPN's au Luxembourg. Ces VPN's (après migration et renumérotation de notre réseau vers des IPs du /21) auront des endpoints définis dans ce /21. Ce qui veut dire qu'en fonction du chemin BGP, chaque VPN (ainsi que son backup) sera routés vers un site ou l'autre. Ce que nous ne voulons pas. Nous voulons que chaque type de VPN arrive vers son site respectif. La solution contournant le problème pourrait être l'une des suivantes: 1. Annoncer le /21 sur les deux sites, annoncer des sous-ranges de ce /21 sur chaque site et demander à nos upstreams d'aggréger et de router en conséquence vers chaque site. Ceci ne sera valable que pour Verizon car il est le seul à couvrir les deux sites. _Avantages_: - Transparent pour la table de routage globale. C'est l'upstream qui fait tout le travail. _Désavantages_: - Vérizon est le seul à couvrir les deux sites et donc la solution n'est pas implémentable. 2. Annoncer des sous-ranges du /21 sans aggrégation par nos upstreams sur chaque site et annoncer globalement le /21 avec une priorité moins élevée (prepending, MED, communities, etc). _Désavantages_: - Etre mal vu de la communauté et risque de se faire filtrer du fait d'avoir découpé un /21. - Devoir utiliser des paramètres "avancés" de BGP pour contourner le problème avec le risque que nos upstreams ne suivent pas ou ne veuille pas nous suivre. 2. Faire des tunnels NxN entre Bruxelles et le Luxembourg sur les routeurs d'accès internet et router le traffic en fonction de la destination des assignations. _Avantages_: - Super clean vu de l'extérieur car seuls les /21 sont envoyés à nos upstreams. _Désavantages: - Création de beaucoup de tunnels, typiquement NxN ou N est le nombre de liens que nous avons avec nos upstreams (2 pour chaque upstream: main + shadow). - Routage statique - Gaspillage de bande passante car si un traffic devant arriver au Luxembourg arrive d'abord sur Bruxelles du fait d'un chemin optimal passant par Bruxelles, il y aura un gaspillage de 2x la bande passante requise par le flux sur Bruxelles. 3. Router le traffic via des liens L2 privés existant entre les deux sites _Avantages_: - Super clean vu de l'extérieur car seuls les /21 sont envoyés à nos upstreams. - Pas de gaspillage de bande passante internet. _Désavantages_: - Gaspillage de bande passante sur le lien privé. - Mix de traffic interne et externe rendant la solution non implémentable à cause de contraintes de confidentialité. => Possible si on achète de nouveaux liens privés mais augmentation des coûts non désirable. 4. Demander au RIPE de nous échanger ce /21 PA par deux /22 PA indépendants et les router chacuns indépendamment à partir de chaque site. _Désavantages_: - /21 est la plus petite allocation PA dans la zone RIPE. - Releasing de la range /21 et nouvelles demandes au RIPE (range PI /22?) avec risque que cela échoue. Que pensez-vous? Qu'auriez-vous implémenté? Y-a-t-il d'autres solutions? Merci d'avance pour vos suggestions, idées, commentaires, Arnaud. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
