Alternativas a múltiples proveedores de servicios

Tengo un SP en este momento que sirve a 100 sitios y actualmente estamos planeando migrar todos los sitios a un nuevo SP. Sin embargo, esta será una migración por fases, por lo que tendremos algunos sitios en la nueva nube SP y otros en la antigua. Los SP no ejecutarán ningún tipo de Inter-AS entre ellos.

¿Qué otras alternativas tenemos para mantener la comunicación entre los sitios en la antigua nube SP y en la nueva nube SP?

EDITAR :

Los sitios ahora están conectados a través de una sola nube MPLS, no hay IPSec. Todos los sitios se conectan en una sola nube MPLS. Vamos a mover algunos sitios a la nueva nube MPLS y dado que no hay conexión entre las dos nubes MPLS (SP diferentes) y no están ejecutando Inter-AS, la pregunta es qué otras alternativas tenemos para mantener los sitios, vamos a digamos, MPLS-A comunicándose con sitios en MPLS-B.

Es MPLS VPN con rutas BGP que se intercambian con los enrutadores PE para el proveedor de servicios. Entonces es básicamente MPLS L3VPN. Avísame si necesitas información adicional ...

Tuve este problema No indicó si tiene un centro de datos o no. Suponiendo que el tráfico entre sitios remotos es manejable, en sus centros de datos permite que se anuncien prefijos entre las dos nubes SP utilizando sus centros de datos como trasits. Es cierto que el sitio remoto al lado remoto dará un salto en sus centros de datos, pero no hay mucho que hacer. También supongo que primero adjuntará sus centros de datos a ambos proveedores, luego migrará sitios remotos y eliminará sus centros de datos del antiguo ISP. Esto sucederá por defecto. Si no corta sus sitios remotos (ambos proveedores están conectados por un tiempo), use una lista de filtros en BGP para bloquear el tránsito en los sitios remotos.

Si está utilizando BGP como protocolo de enrutamiento PE a CE, esto sucederá casi de forma predeterminada; de lo contrario, indique cómo está enrutando PE a CE.

Esta es una situación muy común, que he visto muchas veces a lo largo de los años. Independientemente de si está rechazando y reemplazando circuitos T1 punto a punto heredados, integrando redes en una adquisición / fusión, o simplemente cambiando de proveedor como en esta pregunta, la solución casi siempre involucrará la utilización de su configuración de enrutamiento / equipo de red existente para transitar el tráfico entre las diferentes redes. Esa es la solución más simple y le brinda el mayor nivel de control.

Para entrar en mi caja de jabón por un minuto, aquí es donde un diseño de red jerárquico claramente definido es útil. Si está utilizando un diseño con capas Core-Aggregation-Distribution (o incluso una simple configuración de capa Core-Distribution), simplemente conectaría cada proveedor de servicios MPLS por separado a su equipo Core / Aggregation.

Una vez que las rutas a cada sitio (independientemente del proveedor) estén en su equipo Core / Agregación, los protocolos de enrutamiento existentes de su red pueden manejar la distribución del tráfico entre las dos redes. Para cualquier enrutador, simplemente serán subredes separadas disponibles en su red.

Configuración actual:

 MPLS Service Provider A
            |
           BGP
            |
       -~-~-~-~-~-
       |100 Sites|
       -~-~-~-~-~-

Configuración final deseada:

 MPLS Service Provider B
            |
           BGP
            |
       -~-~-~-~-~-
       |100 Sites|
       -~-~-~-~-~-

Y está buscando la estrategia de puente / migración entre los dos.

EDITAR: aclarando la descripción de la solución a continuación según los comentarios de @ fredpbaker.

Veo dos soluciones, que implican conectar sus proveedores de MPLS en una capa central en una ubicación (aunque dos serían mejores para fines de redundancia, y eso es lo que se muestra a continuación). Esto permitiría que su equipo de red existente conecte los sitios de cada proveedor.

En todas las demás ubicaciones / sitios, el proveedor de MPLS sería irrelevante. Podrían estar conectados al Proveedor A o al Proveedor B (o ambos), y el tráfico fluiría entre ellos.

Primero, puede redistribuir BGP en su IGP existente y permitir que su equipo enrute el tráfico en tránsito entre cada proveedor:

    Redistribute into OSPF/EIGRP
     /                      \
-~-~-~-~-~-             -~-~-~-~-~-
| Core A  |-\         /-| Core B  |
-~-~-~-~-~-   \     /   -~-~-~-~-~-
    |           \ /           |
    |           / \           |
   BGP       BGP    BGP      BGP
    |        /       \        |
 -~-~-~-~-~-~-       -~-~-~-~-~-~-
 | MPLS SP A |       | MPLS SP B |
 -~-~-~-~-~-~-       -~-~-~-~-~-~- 
             |       |
            BGP     BGP
             |       |
             |       |
             |       |       
         -~-~-~-~-~-~-~-~-~
         | 98 Other Sites |
         |  Connected to  |
         |   Either MPLS  |
         |    Provider    |
         -~-~-~-~-~-~-~-~-~

En segundo lugar, si no tiene un IGP en ejecución, o no desea redistribuirlo, puede utilizar el enrutamiento Inter-VRF con VRF lite (como lo describe Stretch en PacketLife) y tomar las rutas de cada proveedor en un VRF en cada enrutador Core y expórtelos al VRF apropiado:

Import/Export routes between VRF's as needed
         /                      \
    -~-~-~-~-~-             -~-~-~-~-~-
    | Core A  |VRF-B   VRF-A| Core B  |
    -~-~-~-~-~-   \     /   -~-~-~-~-~-
      VRF-A         \ /         VRF-B
        |           / \           |
       BGP       BGP    BGP      BGP
        |        /       \        |
     -~-~-~-~-~-~-       -~-~-~-~-~-~-
     | MPLS SP A |       | MPLS SP B |
     -~-~-~-~-~-~-       -~-~-~-~-~-~- 
                 |       |
                BGP     BGP
                 |       |
                 |       |
                 |       |       
             -~-~-~-~-~-~-~-~-~
             | 98 Other Sites |
             |  Connected to  |
             |   Either MPLS  |
             |    Provider    |
             -~-~-~-~-~-~-~-~-~

Si está utilizando enrutadores Cisco, es posible que desee investigar el protocolo LISP

La tecnología LISP se puede implementar fácilmente como una superposición que interconecta sin problemas sus dos sitios a través de SP.

Hay múltiples presentaciones que detallan los casos de uso más comunes, pero se puede extender fácilmente a su caso para proporcionar extensibilidad del sitio a través de SP o incluso ayudarlo en la transición utilizando su solución de movilidad de host.