270 likes | 394 Views
Aspects Techniques du Peering. Session 4. Vue d'ensemble. Liste de contr ô le /conditions pr é alables pour le Peering Peering pas à pas Arrangements et options de Peering Exercices. Conditions de Peering.
E N D
Aspects Techniques du Peering Session 4
Vue d'ensemble • Liste de contrôle /conditions préalables pour le Peering • Peering pas à pas • Arrangements et options de Peering • Exercices
Conditions de Peering • Un routeur compatible BGP4 avec assez de mémoire pour recevoir toutes les routes: • Minimum 256MB pour la table de routage globale • 32MB pour toutes les routes africaines • Moins pour seulement votre pays • Espace d’adresses portables (non reçu de votre FAI ascendant ; cet espace est déjà annoncé aux pairs en amont) • Un nombre de système Autonome AS • Les deux disponibles à AfriNIC
Conditions additionnelles • Liste de préfixes qui seront annoncés et reçus des pairs • ADRESSE IP de chaque pair (y compris votre propre routeur de bord) • Nombre maximum de saut entre les routeurs BGP s'ils ne sont pas adjacent • la connexion multiple entre deux noeuds eBGP n'est pas recommandée, et n'est pas incluse dans ces notes
Peering point par point : Étape 1 “John Doe Communications” veut faire du peering avec “Experts Network”. Étape 1 : Noter toute l'information nécessaire pour chaque partie : A : • Nom de Societe : John Doe Communications • nombre AS: AS100 • Plage d’adresse : 12.1.1.0/24, 196.25.0.0/16 • Routeur de bord : Cisco 2621 • Adresse de pair BGP : 12.1.1.10 B : • Nom de Societe : Networks Experts • nombre AS: AS200 • Plage d’adresse : 150.200.54.0/23 • Routeur de bord : Quagga sur un PC Linux Adresse de pair BGP : 150.200.54.125 A :
Étape 2.1 • Configurer une interface “loopback” sur le routeur. C'est nécessaire afin d'avoir une interface qui sera toujours “up” même si certaines interfaces physiques sur le routeur tombent. (particulièrement utile avec le iBGP.) interface loopback0 ip address 12.1.1.10 255.255.255.255
Étape 2.3 • Définir les filtres pour annoncer et recevoir uniquement les routes que nous connaissons . C'est très important. Si ceci est omis n'importe quel pair peut inonder votre table de routage avec des entrées fausses. Il peut également cracher votre routeur si trop de préfixes sont acceptés par votre routeur. ! accepter tous les préfixes plus petits ou à égal/24, ! mais seulement les plages d’adresse que nous ! connaissons appatenant à chaque AS. AS 100 est ! notre propre AS. ip prefix-list AS100 seq 5 permit 12.1.1.0/24 ip prefix-list AS100 seq 10 permit 196.25.0.0/16 le 24 ! AS200 est notre pair ip prefix-list AS200 seq 5 permit 150.200.54.0/23 le 24
Étape 2.4 • Tout le reste des arrangements réside dans la section BGP de la configuration. Indiquer ici votre nombre AS. ! configurer les sessions de BGP routeur bgp 100 • Par défaut le BGP n'annonce pas les routes jusqu'à ce que tous les routeurs dans le AS aient appris les routes par IGP. Cette commande permet au BGP d'annoncer des routes aux pairs sans les avoir synchroniser avec l'IGP. no synchronization
Étape 2.5 • Noter dans le journal tous les changements tels que des raccordements BGP qui tombent. Ces changements peuvent être suivis en exportant les journaux du routeur vers un serveur syslog. La plupart des FAIs ont un serveur central des journaux et ont des techniciens pour surveiller tous les événements. bgp log-neighbour-changes • Ne pas utiliser la commande "redistribute" pour entrer des routes dans le BGP. Cela peut faciliter l’apparution des routes non desirees d'apparaître dans votre table BGP.
Étape 2.5 • Ajouter une commande “network” pour chaque route que vous annoncerez. Ajouter en outre une route nulle pour les agrégats qui pourraient ne pas être encore dans votre table de routage IGP. Sans ces commandes aucune route dans notre table de routage ne serait annoncée à aucun pair. ! S’assurer la route agregée est toujours presente ip route 196.25.0.0 255.255.0.0 null0 254 ! Ajouter vos propres réseaux au BGP router bgp 100 network 12.1.1.0 mask 255.255.255.0 network 196.25.0.0 mask 255.255.0.0 • Faire ce qui précède sur seulement un routeur, ou seulement quelques routeurs dans votre AS, pas sur chaque routeur.
Étape 2.6 • Ne pas essayer de regrouper les routes. Cette commande est nécessaire si nous voulons échanger des routes sans classes (c.-à-d. route autre que des routes de la classe A, B, ou C). no auto-summary • Nous installons maintenant une session de peering avec “Experts Networks” (AS 200). S'il y avait plus d'un pair nous aurions écrit les commandes semblables pour chaque pair. La première commande indique le nombre AS du pair (également connu sous le nom de voisin). neighbor 1.2.3.4 remote-as 200
Étape 2.6 • Ajouter une description. S'il y a beaucoup de voisins définis, il est utile de trouver le voisin approprié quand des changements de configuration doivent être faits en regardant ces descriptions. neighbor 1.2.3.4 description Experts Networks
Étape 2.7 • Cette commande demande au routeur pour placer les passerelles pour toutes les routes supplémentaires à la table de routage vers lui-même. Toujours activer ceci quand vous faites du peering avec d'autres systèmes autonomes. neighbour 1.2.3.4 next-hop-self
Étape 2.8 • Demander au routeur de stocker les mises à jour reçues. Ceci nous permet de mettre à jour une session BGP sans devoir redémarrer la session. neighbour 1.2.3.4 soft-reconfiguration inbound • Ceci consomme la mémoire supplémentaire. Dans l’IOS 12 ou plus, vous pouvez obtenir les mêmes avantages en utilisant les possibilites BGP “route refresh” au lieu d'employer la mémoire. Employer “show ip bgp neighbor x.x.x.x“ pour vérifier que le pair le supporte
Étape 2.8 • Seulement annoncer et accepter les routes permises par nos filtres afin d'empêcher l’inondation de notre table de routage. neighbour 1.2.3.4 prefix-list AS100 out neighbour 1.2.3.4 prefix-list AS200 in
Étape 3 : Vérifier • Les commandes suivantes peuvent être employées pour diagnostiquer les problèmes avec votre configuration BGP : ! Montrer un sommaire des sessions de peering show ip bgp summary ! Montrer les détails du voisin show ip bgp neighbor ! Montrer les routes recus des voisins show ip bgp ! Montrer les routes recues du voisin 192.168.4.1 show ip bgp neighbor 192.168.4.1 received-routes show ip bgp neighbor 192.168.4.1 route ! Momtrer les routes annoncees au voisin 192.168.4.3 show ip bgp neighbor 192.168.4.3 advertised-routes ! Montrer toutes les routes connues a partir de tous les ! protocoles show ip route
Option 1 : Peering multilatéral Obligatoire • Tous les participants au PE sont pairs avec un serveur central des routes. Ceci force tous de faire du peering avec tous et réduit le nombre de sessions de peering qui doivent être maintenues par chaque pair. • Un serveur central des routes ! = un réflecteur des routes ! ! Les réflecteurs des routes sont utilisés dans le iBGP pour éliminer le besoin de réseau totalement maillé.
Avantages Peering automatique avec tous - faciles La complexité est centralisée – facile pour les FAIs Facile pour se connecter – une seule session BGP Inconvénients Peering obligatoire avec tous - inflexibles La complexité est centralisée – dur pour l'opérateur du PE Les politiques complexes sont impossibles Option 1 : Peering multilatéral Obligatoire
Option 2 : Peering bilatéral • L'option 1 ne dimensionne pas bien : certains PEs laissent tous les participants négocier leurs propres arrangements. • Ce réseau maillé dimensionne bien, mais il prend beaucoup plus le travail pour chaque FAI. • Si quelques participants choisissent de ne pas faire du peering l'un avec l'autre, alors il y aura une maille partielle au lieu d'une maille totale.
Avantages Choisir avec qui être pair ou pas Tous les routeurs sont contrôlés par les FAIs, pas par l'opérateur du PE Les politiques complexes sont possibles Inconvénients Le Non-peering peut causer le routage inefficace La configuration du routeur du FAI devient complexe Difficile pour un nouveau participant se connecter Option 2 : Peering bilatéral
Option 3 : Hybride • Il est possible d'avoir les deux modèles fonctionner simultanément à un PE, avec certains FAIs faisant du peering avec le serveur central des routes et les autres configurant manuellement leurs routeurs pour un peering bilatéral avec les pairs choisis. • Pas le plus souhaitable ! • Mais peut se développer par exemple si des très grands FAIs et des très petits font partie du même PE – donne un contrôle des rapports d'affaires. • Une option est de commencer avec un serveur central des routes et le peering multilatéral, et permettre par la suite le peering bilatéral.
Exercice 1 • Plusieurs FAIs • Chaque FAI a un routeur au QG, lié au fournisseur ascendant • Chaque FAI ajoute un nouveau routeur au point d'échange (PE), relié au routeur du QG • Lancer le iBGP entre le QG et le PE • Pas encore encore de peering avec d'autres FAIs
Exercice 2 • Suite de l'exercice 1 • Chaque FAI commence une session BGP avec tous les autres (peering bilatéral)
Exercice 3 • Suite de l'exercice 1 • Défaire une partie de l'exercice 2 d'abord • Chaque FAI commence une session BGP avec un serveur des routes (peering multilatéral)
Routeurs PE Routeurs QG R AS w a b z R R y x p AS w Switch Point d’Exchange a b R Fournisseur Ascendant z R y x p AS w a b z R R p y x Serveur Route