Un route reflector (RR) reflète un préfixe appris via iBGP du client A vers le client B, mais le client B ne peut pas atteindre le next-hop de la route. Quelle configuration sur le RR garantira que le client B reçoit un next-hop atteignable pour les routes réfléchies ?

L'option "next-hop-self" est la bonne car elle force le route reflector (RR) à annoncer sa propre adresse IP comme next-hop pour les routes iBGP réfléchies. Par défaut, iBGP préserve le next-hop original. Si le client B ne peut pas atteindre le next-hop original (qui est l'adresse IP du client A), la route est inutilisable. En configurant "next-hop-self", le RR garantit que le next-hop annoncé est directement atteignable par le client B, résolvant ainsi le problème d'accessibilité. Les autres options sont incorrectes : L'ajout de chemins AS (AS path prepending) manipule le chemin AS pour influencer la sélection de route, mais n'affecte pas l'atteignabilité du next-hop. L'activation d'une route-map pour définir le poids (weight) est une métrique locale à un routeur et n'est pas transmise aux pairs BGP, n'ayant donc aucun impact sur le next-hop. Convertir le RR en un haut-parleur eBGP changerait la nature du peering BGP, ce qui n'est pas la solution appropriée pour un problème de next-hop au sein d'un domaine iBGP.