Michael, Le 02/09/10 11:15, Michael VILLAR a écrit : > Certain opérateurs te permettent de setter des communauté aux prefix annoncé > pour changer les Local-Pref sur leur réseaux ou pour choisir des politique > d'annonce (tes prefix seront ou pas annoncé dans les zone Géographique > NA,AP,EMEA). > > Il est donc possible de gérer par ces mécanismes les flux entrant, il serait > possible de généraliser ce principe.
Le problème, c'est que c'est assez rare et pas assez granulaire.
Tu peux effectivement éviter des allers-retours trans-océaniques avec ce
genre de configs, quoique typiquement, c'est pas en place chez certains
transitaires quasi-T1. Mais il n'y a pas de consensus pour la mise en
place de ce genre de politique sur des zones plus réduites, genre FR ou EU.
Cas typique : le peering en région. Entre Free et OVH, ça s'est fait (si
j'ai bien tout compris) parce que Free utilisait déjà pas mal de
communautés et d'AS privés, et qu'OVH est centralisé. Du coup, ça doit
faire 40Gbps de moins à transporter sur les 600km de l'aller retour
Lille-Paris.
Autre cas typique, imagine un grand réseau national d'eyeball qui reçoit
tout youredpornmotiontube via l'AMS-IX. Les vendeurs de video se chient
dessus, ou l'AMS-IX plante (un jour ou le RIPE a le vent dans le dos,
par exemple), et pouf, tout le trafic se reporte sur un autre IX, en
général DECIX ou LINX. 500 Gbps qui changent de route d'un coup. Tous
les liens qui se mettent à saturer. Ca te rapelle quelque chose ?
Comment tu fais, dans ce genre decas de figure pour t'entendre avec tous
les fournisseurs de contenus pour équilibrer entre les IX plutot que de
tout balancer sur un ou deux seuls liens ?
(bon, c'est encore plus compliqué de s'entendre quand tu veux le faire
payer son transport et qu'il te réponds "toi tu vas disparaitre du Net")
Donc, plusieurs possibilités :
- Tu analyses avec un maximum de précision toutes les routes actives de
ton réseau et tu modules tes annonces pour chaque session BGP :
* Ca oblige à superviser TOUS les liens avec une grande précision, et à
scripter des modifications d'annonces assez fines, tout en anticipant
les congestions classiques
* Tu t'interdis l'usage des route-servers de certains IX qui ne feront
pas forcement la distinction entre tes annonces et les routes fournies
par tous les peers
* Tu dois être proactif et anticiper les variations d'usage (patch-day,
botnet,... ) pour pas être pris au dépourvu
* Enfin, tu vas fragmenter tes annonces et donc contribuer au
morcellement de la table de routage globale. Enfoiré.
Mais le principal problème, c'est que ça rends ton réseau statique. A
force d'y ajouter des règles d'optimisation et de répartition, tu vas au
mieux pas pouvoir t'adapter à un gros incident, faire exploser tes coûts
d'exploit et au pire, a force d'ajouter de l'intelligence dans le
réseau, en faire une boite noire pas neutre. BOOUHOUHOU !
- Autre option, tu utilises des "boitiers d'optimisation BGP". Sur le
principe, c'est sensé faire la même chose que ce que je viens d'énoncer,
mais en mal. Comme tout est automatisé, forcement, c'est moins efficace.
Ces boitiers coutent un bras (ticket d'entrée à 40k€) mais peuvent être
de bons compléments car pas de mauvais outils pour la supervision.
- Reinventer BGP en y intégrant une meilleur connaissance de l'entourage
de l'instance.
En fait, ça consisterait à intégrer la supervision des liens et des
sessions dans le protocole de base. Le problème là dedans c'est la
nécessité pour chaque bordure de connaitre l'état de tout l'interne.
Ca induit des contraintes d'interopérabilité énormes parce que la
découverte par chaque routeur de toute la topologie est nécessairement
complexe. La mise à jour de la topologie interne serait lourde et la
moindre erreur aurait un impact énorme. Alors elle pourrait être faite
au moins en partie manuellement, et dans ce cas ça ajoute encore une
couche d'erreur et un coût à l'exploitation.
Outre les problèmes de fragmentation, de quantité de données de
supervision à analyser en temps réel, d'interopérabilité, et le risque
qu'il y a à rendre les routeurs trop intelligents, tu vas aussi avoir un
problème de sécurité et d'exposition de ton réseau. Pour bien
fonctionner, et proposer aux voisins des routes efficaces, tu dois leur
fournir pas mal d'infos dans tes annonces. A priori suffisamment pour
voir, de l'extérieur, tous les points faibles de ta topologie...
Il y a enfin le problème du Least Cost Routing. Ce genre de protocoles
ou d'approches d'optimisation a principalement pou bute de maximiser
l'usage des routes les moins chères, tout en conservant un niveau de
qualité acceptable.
"Price, Speed, Quality, pick two". Ca, tout le monde connait. "Qui qui
paye cette route là ?", ça viendrait ensuite. Puisque tout le monde a
intérêt à optimiser le coût de ses intercos, et que le paid-peering est
plus à la mode que les peering-policies constructives, on pourrait finir
par assister à un jeu ou "je t'envoie les infos de routage pertinentes
que si tu payes, et à défaut, tu feras trois fois le tour du monde avant
d'arriver dans un tarpit".
C'est un peu négatif, mais je ne vois pas d'autre issue à l'ajout
d'intelligence dans les protocoles de routage. Alors pour le coup, BGP
et ses attributs optionnels me semblent largement satisfaisants...
--
Jérôme Nicolle
signature.asc
Description: OpenPGP digital signature
