Routage avec liaison WAN séparée pour les sauvegardes


10

Nous avons deux centres de données géographiquement séparés. Nous nous préparons à mettre en œuvre une nouvelle connexion WAN (cloud sombre) qui ne serait utilisée que pour le trafic de sauvegarde. Les serveurs auront deux cartes NIC (production et sauvegarde) mais quelle est la meilleure façon de s'assurer que le trafic de production et de sauvegarde ne se mélange pas? Pour le moment, nous utilisons simplement des routes statiques pour accéder au WAN, mais cherchons à implémenter BGP entre notre SP et nous-mêmes. Le RP interne est un mélange d'EIGRP et d'OSPF. Les cœurs sont des Cisco 6500 et les routeurs WAN seront bientôt mis à niveau vers des ASR.

Des suggestions de solutions? Routage basé sur des règles (PBR)? VRF?

Diagramme de réseau


Sans en savoir plus, je ne vois pas en quoi le mélange du trafic de sauvegarde sur le lien principal entre les contrôleurs de domaine et vice versa est un problème? En supposant que le LAN du serveur principal et leur LAN de trafic de sauvegarde sont différents sous-réseaux, ils peuvent être publiés sur vos deux liaisons inter-DC avec des métriques de route différentes. Je ne vois pas comment tu peux les mélanger accidentellement? Vous pouvez utiliser des VRF et des VLAN, mais cela semble trop complexe lorsque vous pouvez simplement changer la métrique de l'itinéraire. Suis-je en train de manquer quelque chose?
jwbensley

Pour le moment, il est impératif qu'ils restent séparés. Nous devons également nous assurer que les sauvegardes ne basculent pas ou ne tentent pas d'équilibrer la charge sur les liens de production.
Peter

Ah OK, eh bien, ce n'est toujours pas trop difficile d'utiliser différentes métriques de route et de ne publier qu'un seul chemin pour chaque sous-réseau pour éviter le scénario de basculement indésirable. Les VRF deviennent maintenant une solution simple et directe ici, comme le mentionne ioshints.
jwbensley

Réponses:


9

En supposant que les deux cartes réseau sur les serveurs sont utilisées pour séparer le trafic de production et de sauvegarde, utilisez les VRF. C'est la meilleure technique de séparation du trafic qui soit. Pour plus d'évolutivité (pas sûr que vous en ayez besoin sur la base du diagramme), jetez le MPLS / VPN à part entière dans le mélange, il fonctionne à la fois sur Cat 6500 et ASR.


L'utilisation de deux cartes réseau nécessite la création et la maintenance de tables de routage sur les serveurs. A moins que quelqu'un ne connaisse quelques trucs que je ne connais pas?
Peter

Oui. Vous devez configurer des itinéraires sur les serveurs pour pointer les sous-réseaux de sauvegarde hors de l'interface de sauvegarde. Si c'est une tâche trop intimidante, vous pouvez toujours faire des choses intéressantes avec des mesures. En supposant que vos serveurs de sauvegarde se trouvent sur leur propre sous-réseau ... mais là encore, la solution MPLS le suppose également. S'ils ne sont pas sur leur propre sous-réseau et que vous n'avez pas de / 32 pour les serveurs de sauvegarde, je pense que le routage basé sur des règles pourrait être votre seule option.
bigmstone

Là où il y a de la volonté, il y a une astuce;) Utilisez / 16s sur les serveurs et / 24s dans les routeurs. Le proxy ARP fera le routage pour vous;)
ioshints

1

Pour les IGP, ne pouvez-vous pas simplement utiliser le réglage métrique régulier? EIGRP - il suffit de manipuler le délai et pour OSPF le coût. Une fois qu'il atteint le cœur BGP, vous ne pouvez pas utiliser de médicaments BGP. Pour mon entreprise (intuition financière), je sais que c'est ce que nous faisons. Nous avons un flux A et un flux B. Un flux aura de meilleures métriques internes que B. Une fois qu'il atteint notre cœur BGP, c'est à peu près ce que j'ai énuméré ci-dessus.


0

Une autre option qui pourrait donner plus de flexibilité est d'utiliser QoS et simplement PbR basé sur les files d'attente, si vous le concevez correctement, vous obtenez même un basculement automatique du principal vers la sauvegarde, mais pas l'inverse.

De cette façon, vous pouvez choisir de partager, ou de ne pas partager, tout lien ou routeur avec un changement de politique.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.