Construisez la frontière EVPN autour de la politique d'export, pas des attaches
Décidez d'abord les routes qui traversent et la relation ASN. L'attache Layer 2 découle ensuite d'une exigence, et chaque locataire ne reçoit que l'export dont il a besoin.
L'hypothèse courante est que le modèle d'attache Layer 2 à la frontière détermine tout ce qui se trouve au-dessus, si bien que la conception part d'une paire vPC et remonte. Cela finit généralement par des décisions de routage prises par accident. Une frontière EVPN est d'abord une frontière de routage : un contexte de routage de locataire rencontre un domaine de routage externe, et ce qui franchit cette ligne est une déclaration de politique. Choisissez les routes, la relation ASN et les chemins de défaillance avant que quiconque ne discute des port-channels. Le modèle d'attache découle ensuite d'une exigence au lieu de la dicter.
Commencez par ce qui franchit la frontière
Écrivez les routes qui doivent être visibles de chaque côté, la direction qu'elles prennent et qui approuve une modification de cette liste. Une frontière qui accepte tout et annonce tout n'a pas de politique, seulement un câble.
Nommez ensuite la défaillance que vous comptez exploiter : un uplink en panne, un border leaf en panne ou tout le domaine externe injoignable. Chaque réponse change la nécessité de deux voisins indépendants, d'une attache Layer 2 partagée, ou des deux.
Ce n'est qu'une fois ces deux listes établies que la question de l'attache devient soluble. Avant cela, chaque mécanisme paraît également valable. Après, la plupart s'éliminent d'eux-mêmes. C'est tout l'argument pour faire le travail de routage en premier.
Fixez la frontière ASN et peering
Une fabric à AS privés fait généralement du peering avec le domaine de frontière public via eBGP, et la partie intéressante est la politique des deux côtés. Décidez quels préfixes sont acceptés, lesquels sont annoncés et quel AS path l'upstream doit recevoir.
RFC 6996 réserve une plage d'ASN à usage privé, et ces ASN ne sont pas censés apparaître dans les annonces globales. Appliquez la politique de suppression ou de filtrage prise en charge par la plateforme et vérifiez l'annonce obtenue au lieu de supposer que l'équipement l'a fait. Cette étape ne vous autorise pas non plus à annoncer un préfixe public arbitraire, c'est une conversation séparée avec le propriétaire de l'adresse.
Une confédération ou une fonction local-AS est un choix de conception pour une topologie donnée. Aucune n'est obligatoire simplement parce que la fabric et l'upstream utilisent des rôles ASN différents, et en adopter une sans l'exigence ajoute des pièces mobiles à chaque changement futur.
Les uplinks Layer 3 n'ont pas besoin de multichassis LAG
Des interfaces routées indépendantes avec leurs propres voisins BGP donnent deux chemins clairs et deux domaines de défaillance clairs. vPC ou un autre multichassis LAG répond à une exigence d'attache Layer 2, et c'est le bon outil quand cette exigence existe.
Une règle générale selon laquelle chaque paire de frontière doit utiliser vPC, ou doit l'éviter, masque les conditions qui décident réellement du cas. Demandez ce que l'attache doit transporter, puis choisissez le mécanisme qui le transporte avec le moins de modes de défaillance partagés.
La politique de routage que vous avez écrite en premier ne change pas quand le mécanisme d'attache change, ce qui est bon signe que l'ordre était correct.
N'exportez que ce dont le locataire a besoin
Un locataire peut avoir besoin d'une route par défaut, d'un ensemble de préfixes externes choisis ou d'une table bien plus grande. Choisissez cette portée en fonction de la capacité réelle de transfert et de plan de contrôle, et non d'un ancien décompte de routes internet que personne n'a remesuré.
La route EVPN IP Prefix, communément appelée Type 5 et définie dans RFC 9136, transporte les informations de préfixe dans l'overlay. L'implémentation a encore besoin de politiques d'export et d'import correspondantes plus la résolution du next-hop, donc recevoir une route BGP externe à la frontière ne signifie pas que chaque VRF de locataire l'importe.
Chaque leaf n'a pas besoin de la table complète simplement parce que la frontière la détient. Distribuez ce que le trafic du locataire exige, et laissez la frontière posséder le reste.
Vérifiez un préfixe de bout en bout
Choisissez un préfixe externe représentatif et suivez-le dans le VRF prévu de la frontière, la politique d'export, le contexte de transfert du leaf récepteur et le chemin de retour vers une source de locataire. Un préfixe qui apparaît à un endroit et pas au suivant localise l'erreur immédiatement.
Confirmez comment le next hop se résout via l'overlay, car une route présente avec un next hop non résolu ne transmet rien. Répétez ensuite le contrôle après un changement d'uplink, car c'est là que politique et résolution du next-hop divergent le plus souvent.
Ordre du travail : listez les routes qui traversent, convenez de la politique ASN, choisissez l'attache pour son travail réel, cadrez l'export par locataire, puis vérifiez un préfixe et son chemin de retour.