Usine VxLAN. Partie 3

Bonjour Habr. Je termine une série d'articles, dédié au lancement du cours "Ingénieur réseau" par OTU, utilisant la technologie VxLAN EVPN pour le routage au sein de la structure et utilisant un pare-feu pour restreindre l'accès entre les services internes

Les parties précédentes de la série peuvent être consultées sur les liens suivants :

• 1 partie du cycle - Connectivité L2 entre les serveurs
• Partie 2 de la série - Routage entre VNI
• Partie 2.5 de la série - Digression théorique

Aujourd'hui, nous continuerons à étudier la logique de routage à l'intérieur de la structure VxLAN. Dans la partie précédente, nous avons examiné le routage intra-fabric au sein d’un seul VRF. Cependant, il peut y avoir un grand nombre de services clients dans le réseau, et tous doivent être répartis dans différents VRF pour différencier l'accès entre eux. En plus de la séparation des réseaux, une entreprise peut avoir besoin de connecter un pare-feu pour restreindre l'accès entre ces services. Oui, cela ne peut pas être qualifié de meilleure solution, mais les réalités modernes nécessitent des « solutions modernes ».

Considérons deux options de routage entre les VRF :

1. Routage sans quitter la structure VxLAN ;
2. Routage sur équipement externe.

Commençons par la logique de routage entre les VRF. Il existe un certain nombre de VRF. Pour acheminer entre les VRF, vous devez sélectionner un périphérique dans le réseau qui connaîtra tous les VRF (ou les parties entre lesquelles le routage est nécessaire). Un tel périphérique pourrait être, par exemple, l'un des commutateurs Leaf (ou tous à la fois). . Cette topologie ressemblera à ceci :

Quels sont les inconvénients de cette topologie ?

C'est vrai, chaque Leaf doit connaître tous les VRF (et toutes les informations qu'ils contiennent) sur le réseau, ce qui entraîne une perte de mémoire et une augmentation de la charge du réseau. Après tout, bien souvent, chaque commutateur Leaf n'a pas besoin de connaître tout ce qui se trouve sur le réseau.

Однако рассмотрим такой способ подробнее, так как для небольших сетей такой вариант вполне подойдет (если нет каких-либо специфичных требований бизнеса)

À ce stade, vous vous demandez peut-être comment transférer des informations de VRF à VRF, car le but de cette technologie est précisément de limiter la diffusion des informations.

Et la réponse réside dans des fonctions telles que l'export et l'import d'informations de routage (la mise en place de cette technologie a été envisagée dans deuxième parties du cycle). Permettez-moi de répéter brièvement :

Lors du réglage du VRF dans AF, vous devez spécifier route-target pour obtenir des informations sur le routage d’importation et d’exportation. Vous pouvez le spécifier automatiquement. Ensuite, la valeur inclura l'ASN BGP et le L3 VNI associés au VRF. C'est pratique lorsque vous n'avez qu'un seul ASN dans votre usine :

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Cependant, si vous disposez de plusieurs ASN et devez transférer des itinéraires entre eux, la configuration manuelle sera une option plus pratique et plus évolutive. route-target. La recommandation pour la configuration manuelle est le premier numéro, utilisez celui qui vous convient, par exemple : 9999.
Le second doit être défini pour être égal au VNI de ce VRF.

Configurons-le comme suit :

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

À quoi cela ressemble dans la table de routage :

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Considérons la deuxième option de routage entre les VRF - via un équipement externe, par exemple un pare-feu.

Il existe plusieurs options pour travailler via un périphérique externe :

1. L'appareil sait ce qu'est VxLAN et nous pouvons l'ajouter à une partie de la structure ;
2. L'appareil ne sait rien de VxLAN.

Nous ne nous attarderons pas sur la première option, car la logique sera presque la même que celle indiquée ci-dessus - nous apportons tous les VRF au pare-feu et configurons le routage entre les VRF sur celui-ci.

Considérons la deuxième option, lorsque notre pare-feu ne sait rien de VxLAN (maintenant, bien sûr, des équipements prenant en charge VxLAN apparaissent. Par exemple, Checkpoint a annoncé son support dans la version R81. Vous pouvez en savoir plus à ce sujet ici, cependant, tout cela est au stade des tests et il n'y a aucune confiance dans la stabilité de fonctionnement).

Lors de la connexion d'un périphérique externe, nous obtenons le schéma suivant :

Comme vous pouvez le voir sur le schéma, un goulot d'étranglement apparaît au niveau de l'interface avec le Firewall. Ceci devra être pris en compte à l'avenir lors de la planification du réseau et de l'optimisation du trafic réseau.

Cependant, revenons au problème initial du routage entre VRF. Suite à l'ajout du pare-feu, nous arrivons à la conclusion que le pare-feu doit connaître tous les VRF. Pour ce faire, tous les VRF doivent également être configurés sur les Border Leafs, et le Firewall doit être connecté à chaque VRF avec un lien distinct.

En conséquence, le schéma avec pare-feu :

Autrement dit, sur le pare-feu, vous devez configurer une interface pour chaque VRF situé sur le réseau. En général, la logique n'a pas l'air compliquée et la seule chose que je n'aime pas ici, c'est le grand nombre d'interfaces sur le pare-feu, mais ici il est temps de penser à l'automatisation.

Bien. Nous avons connecté le pare-feu et l'avons ajouté à tous les VRF. Mais comment pouvons-nous maintenant forcer le trafic de chaque Leaf à passer par ce pare-feu ?

Sur Leaf connecté au Firewall, aucun problème ne surviendra, puisque toutes les routes sont locales :

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Mais qu’en est-il des Leafs distants ? Comment leur transmettre la route externe par défaut ?

C'est vrai, via le type de route EVPN 5, comme tout autre préfixe sur la structure VxLAN. Cependant, ce n’est pas si simple (si nous parlons de Cisco, car je n’ai pas vérifié auprès d’autres fournisseurs)

La route par défaut doit être annoncée à partir de la feuille à laquelle le pare-feu est connecté. Cependant, pour transmettre l’itinéraire, Leaf doit le connaître lui-même. Et ici un certain problème se pose (peut-être seulement pour moi), la route doit être enregistrée statiquement dans le VRF où vous souhaitez annoncer une telle route :

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Ensuite, dans la configuration BGP, définissez cette route dans AF IPv4 :

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Cependant, ce n'est pas tout. De cette façon, l'itinéraire par défaut ne sera pas inclus dans la famille l2vpn evpn. En plus de cela, vous devez configurer la redistribution :

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Nous indiquons quels préfixes entreront dans BGP via la redistribution

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Maintenant le préfixe 0.0.0.0/0 tombe dans le type de route EVPN 5 et est transmis au reste de Leaf :

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

Dans le tableau BGP, nous pouvons également observer le type de route 5 résultant avec la route par défaut via 10.255.1.5 :

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Ceci conclut la série d’articles consacrés à EVPN. À l'avenir, j'essaierai d'envisager le fonctionnement de VxLAN en conjonction avec Multicast, car cette méthode est considérée comme plus évolutive (pour le moment, une déclaration controversée)

Si vous avez encore des questions/suggestions sur le sujet, considérez n'importe quelle fonctionnalité d'EVPN - écrivez, nous y réfléchirons plus en détail.

Source: habr.com