Politique de pare-feu EVPN : passerelle centralisée ou IRB distribué

Deux conceptions EVPN placent la passerelle du locataire à des endroits différents, et le pare-feu voit un trafic différent dans chacune. Avec une passerelle centralisée, le trafic entre sous-réseaux atteint le pare-feu, car c'est là que le routage a lieu. Avec l'IRB distribué, les commutateurs leaf routent localement et le pare-feu ne voit rien, sauf si vous l'insérez délibérément. Aucun des deux modèles n'est faux. Ce qui est faux, c'est de raccorder un pare-feu à la frontière et de supposer que le fabric lui livrera le trafic.

Deux modèles, deux points d'inspection différents

Nommez d'abord les flux qui exigent une inspection, car les deux modèles les traitent différemment.

Le trafic au sein du même sous-réseau est la ligne que l'on oublie. Deux hôtes sur un même VLAN communiquent par pontage, et aucun pare-feu routé ne se trouve sur ce chemin, sauf si une conception d'inspection de couche 2 distincte l'intercepte. C'est vrai dans les deux modèles, donc c'est une lacune de conception et non une comparaison entre eux.

Les trois autres lignes sont là où les modèles divergent réellement.

Passerelle centralisée : inspection simple, coût de transit réel

Conservez les VLAN du locataire comme services de couche 2 et placez leurs passerelles de routage sur le pare-feu. Le trafic entre sous-réseaux se rend alors vers cette passerelle et revient, parfois même lorsque les deux hôtes sont sur le même leaf. Le point d'inspection est sans ambiguïté, et c'est tout l'argument de cette conception. Le coût est la charge de transit sur le pare-feu, plus une dépendance centrale de capacité et de disponibilité qu'il vous faut désormais concevoir.

Limitez le changement aux passerelles de locataire que vous visez. Retirer chaque adresse VLAN est trop large lorsque la gestion, l'underlay et les interfaces de la plateforme ont des rôles distincts. Vérifiez aussi une seconde passerelle active, car celle qui route encore autour du pare-feu annule la conception en silence.

Ce modèle est plus facile à expliquer à un auditeur. Il n'est pas automatiquement moins coûteux à exploiter.

IRB distribué : voie rapide, aucune inspection par défaut

Avec des passerelles anycast distribuées, chaque leaf route le trafic du locataire localement, et le RFC 9135 explique pourquoi cela évite le retour par une passerelle centralisée. Le bénéfice est réel, et il a une conséquence directe : l'inspection ne peut pas être déduite de l'endroit où le pare-feu est branché. Un pare-feu relié à un leaf de frontière voit le trafic externe et tout ce que vous y redirigez explicitement.

Insérez le service avec un mécanisme que la plateforme prend réellement en charge : redirection basée sur des politiques, nœud de service ou routage contrôlé entre VRF à travers le pare-feu. Faites correspondre le trafic prévu à son point d'entrée réel. Une politique écrite sur une interface orientée vers les hôtes ne couvre pas un paquet venant de l'overlay.

Lisez les routes installées plutôt que la route par défaut prévue. Un préfixe de locataire plus spécifique importé directement peut contourner la route par défaut qui pointe vers le pare-feu, et rien dans la configuration ne paraîtra anormal.

La symétrie est une propriété de routage, pas une garantie d'inspection

L'IRB symétrique décrit comment les nœuds provider edge d'entrée et de sortie gèrent le routage et le pontage d'un flux. Il ne dit rien sur la question de savoir si les deux directions atteignent le même équipement à état. ECMP, anycast et la haute disponibilité du pare-feu influent tous sur le nœud qui voit le trafic de retour, et le modèle d'état pris en charge par le cluster décide si cela est acceptable.

Suivez explicitement le chemin de retour pour chaque flux qui vous importe. NAT n'est pas un substitut universel à ce travail, et les conceptions qui s'appuient dessus trouvent généralement la lacune lors d'un basculement plutôt que pendant la construction.

Parcourez un flux obligatoire et un flux délibérément exclu, dans les deux sens, avant de valider la conception.

Comment choisir, et quoi tester dans les deux cas

Choisissez la passerelle centralisée lorsque la couverture d'inspection compte plus que la capacité de transit et que vous pouvez assumer la dépendance centrale. Choisissez l'IRB distribué lorsque le routage local est l'objectif, et budgétez l'insertion explicite de service au lieu de la supposer.

Testez ensuite le routage que vous avez réellement installé, car c'est là que les deux conceptions diffèrent le plus :

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Incluez la panne et le rétablissement du nœud de service dans le test. Une route de secours qui contourne discrètement l'inspection est une décision différente d'une politique fail-open planifiée, et une seule des deux est généralement voulue. La conception finalisée nomme où route chaque classe de trafic, où elle est inspectée et ce qui se passe lorsque ce chemin d'inspection est indisponible.