Un collègue tente d'implémenter le multihébergement Internet actif / passif. La conception implique l'envoi de communautés (répertoriées ci-dessous) au fournisseur passif pour réduire la préférence locale au niveau des AS distants pour les routes annoncées. La documentation indique à plusieurs reprises que les communautés sont réservées à l'usage des clients et que nous ne sommes pas clients de ces fournisseurs. Je pense que donner à l'Internet dans son ensemble la possibilité de modifier les préférences locales est un énorme risque pour la sécurité. Est-ce que cela aurait une chance de faire boule de neige en enfer de fonctionner réellement?
1273:70 cable and wireless plc local pref 70
2828:1507 xo local pref 70
3356:70 level3 local pref 70
3549:100 global crossing local pref 100
4323:80 twtelecom local pref 80
1299:50 teliasonera local pref 50
Réponses:
Il est peu probable (mais pas impossible) que les communautés que vous marquez sur vos itinéraires se propagent en amont de votre amont. La plupart des prestataires élimineront les communautés avant de ré-annoncer les itinéraires en amont / en aval.
Si vous souhaitez influencer plusieurs AS distants de cette manière, vous devez utiliser le préfixe AS_PATH. Ajoutez 2-3 fois à votre fournisseur de sauvegarde / passif, puis la plupart / tout le trafic circulera sur votre chemin actif jusqu'à ce qu'il échoue. Ensuite, le trafic devrait se déplacer vers votre chemin passif une fois que l'itinéraire échoué est retiré.
la source
Le fournisseur doit avoir un filtre entrant pour garantir que ces communautés ne sont acceptées que par les clients. Sinon, c'est le problème des fournisseurs.
Cependant, certains fournisseurs de niveau 1 acceptent ce type de communautés de n'importe où. Ceci est basé sur RFC 1998: http://tools.ietf.org/html/rfc1998.html
la source
Le mieux que vous puissiez faire est généralement de rechercher des communautés avec votre fournisseur qui vous permettent d'indiquer les préfixes par pair de votre fournisseur. Cela suppose que votre fournisseur dispose de telles communautés et a les relations de peering pour que cela fonctionne. La préparation de vos propres annonces à votre homologue n'aurait aucune variation en amont de votre fournisseur. Bien que cette méthode ne modifie pas localpref un AS supprimé de votre fournisseur, elle a un impact similaire en rendant ce chemin de retour moins souhaitable. Il y a une exception à influencer localpref en amont que je décrirai en bas, bien que ce soit probablement un cas de bord.
Certains fournisseurs tels que XO [AS2828] vous permettent d'annoncer vos préfixes de telle manière que votre fournisseur annonce vos itinéraires avec des préfixes spécifiques pour certains de leurs pairs.
Par exemple, XO accepte:
2828:1108
ajoute une fois pour AT&T2828:1207
ajoute deux fois pour Level32828:1303
ajoute trois fois pour SprintSur Savvis, la communauté se
3561:30151
prépare une fois pour AT&T.Ces fournisseurs ont généralement des communautés pour indiquer les communautés bien connues de NO_EXPORT ou NO_ADVERTISE à des pairs spécifiques.
Un fournisseur de niveau 2 que je connais, InterNAP, est capable d'influencer les références locales en amont parce qu'ils achètent du transport en commun, ils sont donc un client des niveaux 1. Ils ont des communautés que vous pouvez utiliser lorsqu'ils tentent de les traduire en communautés de niveau 1 spécifiques pour vos publicités en amont qui définissent localpref sur des valeurs de niveau pair , moyen ou élevé. Voir http://www.onesc.net/communities/as6993/Internap-Customer-Guide-1.3.pdf .
Exemples de références: les
communautés XO qui modifient les annonces des clients en certains homologues à AS2828 Border
Savvis Prepend Community Attributes
Je n'ai aucune affiliation avec les prestataires utilisés dans les exemples autres que l'expérience directe en tant que client.
la source