Enrutamiento con un enlace WAN separado para copias de seguridad

10

Tenemos dos centros de datos separados geográficamente. Nos estamos preparando para implementar una nueva conexión WAN (nube oscura) que se usaría solo para el tráfico de respaldo. Los servidores tendrán dos tarjetas NIC (producción y respaldo) pero ¿cuál es la mejor manera de garantizar que el tráfico de producción y respaldo no se mezcle? Por el momento, solo estamos utilizando rutas estáticas para llegar a la WAN, pero estamos buscando implementar BGP entre nuestro SP y nosotros mismos. Internal RP es una mezcla de EIGRP y OSPF. Los núcleos son Cisco 6500 y los enrutadores WAN pronto se actualizarán a ASR.

Sugerencias sobre soluciones? Enrutamiento basado en políticas (PBR)? VRF?

Diagrama de Red

cisco routing backups

— Peter
fuente

Sin conocer más detalles, no veo cómo mezclar el tráfico de respaldo a través del enlace principal entre DC y viceversa es un problema. Suponiendo que la LAN del servidor principal y su LAN de tráfico de respaldo son subredes diferentes, entonces se pueden anunciar a través de sus dos enlaces entre DC con diferentes métricas de ruta. No veo cómo puedes mezclarlos accidentalmente. Puede usar VRF y VLAN, pero esto parece demasiado complejo cuando solo puede cambiar la métrica de la ruta. ¿Me estoy perdiendo de algo?

— jwbensley

Por el momento, es un requisito comercial que permanezcan separados. También debemos asegurarnos de que las copias de seguridad no conmuten por error o intenten equilibrar la carga en los enlaces de producción.

— Peter

Ah, bueno, eso todavía no es demasiado difícil usando diferentes métricas de ruta y solo anunciando una ruta para cada subred para evitar el escenario de conmutación por error no deseado. Sin embargo, los VRF ahora se convierten en una solución simple y directa aquí como lo menciona ioshints.

— jwbensley

9

Suponiendo que las dos NIC en los servidores se usan para separar el tráfico de producción y copia de seguridad, use VRF. Esa es la mejor técnica de separación de tráfico que existe. Para obtener más escalabilidad (no estoy seguro de que lo necesite según el diagrama), agregue MPLS / VPN completo en la mezcla, se ejecuta tanto en Cat 6500 como en ASR.

— Iioshints
fuente

El uso de dos NIC requiere la creación y el mantenimiento de tablas de enrutamiento en los servidores. ¿A menos que alguien sepa algunos trucos que yo no?

— Peter

Si. Debería configurar rutas en los servidores para señalar las subredes de respaldo fuera de la interfaz de respaldo. Si esta es una tarea demasiado desalentadora, siempre puede hacer algunas cosas interesantes con las métricas. Suponiendo que sus servidores de respaldo estén en su propia subred ... pero, de nuevo, la solución MPLS también asume eso. Si no están en su propia subred y no tiene un / 32 para los servidores de respaldo, entonces creo que el enrutamiento basado en políticas podría ser su única opción.

— Bigmstone

Donde hay voluntad, hay un truco;) Use / 16s en los servidores y / 24s en los enrutadores. Proxy ARP hará el enrutamiento por usted;)

— ioshints

1

Para los IGP, ¿no puedes usar la afinación métrica regular? EIGRP: solo manipule el retraso y para OSPF el costo. Una vez que llega al núcleo de BGP, no puede usar medicamentos BGP. Para mi empresa (intuición financiera) sé que eso es lo que hacemos. Tenemos una alimentación A y una alimentación B. Un feed tendrá mejores métricas internas que B. Una vez que llegue a nuestro núcleo de BGP, es más o menos lo que mencioné anteriormente.

— Michael Moore
fuente

0

Otra opción que podría dar más flexibilidad es usar QoS y simplemente PbR en función de las colas, si lo diseñas correctamente, incluso obtienes una conmutación por error automática desde el primario al respaldo, pero no al revés.

De esa manera, puede elegir compartir o no compartir cualquier enlace o enrutador con un cambio de política.

— LapTop006
fuente