VLAN NAT con las mismas subredes IP

Tengo un entorno VMware en el que las máquinas virtuales ejecutan una suite de simulación. El software utilizado tiene direcciones IP codificadas, alrededor de 10-15 máquinas virtuales, y estamos ejecutando varias instancias de este software cada una en diferentes grupos de puertos distribuidos. Entonces, el conjunto de SIM1 VM tiene 192.168.1.0/24 en VLAN10 y SIM2 tiene 192.168.1.0/24 en VLAN20, etc.

Esto funciona bien, no es necesario que las máquinas virtuales SIM1 hablen con las máquinas virtuales SIM2, etc. Ha surgido un nuevo requisito y ahora necesito poder monitorear de forma remota el progreso, administrar y compartir datos de un conjunto físico de máquinas. Las PC de administración vivirán en VLAN200 conectadas a un conmutador Cisco de Cisco.

Tengo 4x10gbe enlaces ascendentes en el conmutador distribuido. Iba a ejecutar esos en algún Cisco 10gbe Router (quiero mantener la conectividad de 10gbe a las máquinas virtuales, no estoy seguro exactamente qué modelo haría esto) y usar VRF en las subinterfaces para cada VLAN usando esa interfaz como puerta de enlace y NAT estática cada virtual máquina. Entonces SIM1 machine1 tiene IP 192.168.1.2 que sería NAT públicamente a 10.0.10.2. El cuarto octeto coincidiría con la IP vm privada y el tercer octeto coincidiría con la VLAN. Entonces SIM2 machine1 (192.168.1.2) sería NAT a 10.0.20.2. El lado de la administración también podría ser una subinterfaz en un puerto diferente y vivir en un VRF global o compartido. Para administrar SIM2 machine1, debería poder usar 10.0.20.2. Si las rutas compartidas entre los VRF y NAT funcionaban.

Comencé a tratar de construir algo similar en GNS3 y rápidamente me sentí abrumado. Así que quiero asegurarme de que mi diseño sea sensato o si hay otra forma mejor y más sensata de abordar el problema. ¿O algún consejo o sugerencia sobre cómo lograr esto?

¡Gracias!

Editar: se agregó un diagrama:

La idea sería que SIM1-S1 sería NAT a 10.0.10.2, SIM1-S2 sería NAT a 10.0.10.3, etc. SIM2-S1 sería NAT a 10.0.20.2, SIM2-S2 sería NAT a 10.0.20.3, etc. ...

— umhelp
fuente

¿Puedes proporcionar un diagrama simple? Asumiendo que todo está en una ubicación, sí, NAT es el camino a seguir. Sin embargo, no creo que necesite usar VRF.

— Ron Trunk

Convenido. No veo ningún punto en el uso de VRF.

— Tommiie

¡Edité la publicación anterior e incluí una imagen con suerte que ayude a darle más sentido! R1 en el diagrama sería el dispositivo NAT. La subinterfaz f0 / 0.10 sería la puerta de enlace para VLAN10 con 192.168.1.254 y la subinterfaz f0 / 0.20 sería la puerta de enlace para VLAN20 con 192.168.1.254, etc. Por eso estaba pensando en VRF.

— umhelp

Suponiendo que tendrá subinterfaces fast0/0.10y fast0/0.20y fast0/0.nn(con su respectiva etiqueta 802.1Q) en ese router, dudo que le permitirá configurar la superposición de rangos de IP en las subinterfaces. Cuando intenté, mi C891-24X solo ladró: % 192.168.1.254 overlaps with GigabitEthernet0/1.10. No veo que esto suceda sin VRF. ¿Qué modelo de enrutador tiene allí y cuántas interfaces tiene?

— Marc 'netztier' Luethi

Todavía no hemos decidido ningún hardware, pero tengo un ASR-1001-X para jugar y la única imagen que tengo para GNS3 es una c7200 para jugar. De cualquier manera, ninguno de ellos permitiría la superposición de IP.

— umhelp

Con un poco de VRF-lite y VRF-aware-NAT y la ayuda de la capacidad de enrutamiento del Cat-3850, aquí hay algunos fragmentos de configuración que deberían funcionar, o al menos llegar hasta la mitad, todo basado en el diagrama que mostró.

Algunas advertencias:

Este ejemplo supone que el Cat-3850 puede actuar como un interruptor L3 y que puede enrutar al menos entre subredes / vlans conectadas directamente.
Cisco IOS e IOS-XE tienen algunas pequeñas diferencias con respecto a NAT, especialmente cuando se trata de NATting de un VRF a otro, pueden surgir algunas preguntas de licencia. Sin embargo, no creo que esto nos lastime aquí.
Este es un "pseudocódigo" compuesto de forma independiente, puede que no sea completamente copiable y pegable, pero debería llevarlo hacia una solución.
La separación de los entornos SIM no se aplica; un entorno puede "hablar" con las direcciones NAT de los otros. Si eso es un problema, no establezca la ruta predeterminada en cada VRF (solo una ruta estática para el sistema de administración o su subred), o use ZBFW en el ASR-1001

Comencemos con R1 y configuremos las interfaces.

interface fastEthernet0/0
 desc * Vmware-dSwitch *
 no ip address

interface Fasterthern0/1
 desc * Cisco-3850 Port 1* 
 no ip address

Luego, tendrá que repetir lo siguiente para cada SIM o sub-entorno: Tenga en cuenta que el ejemplo usa la misma etiqueta VLAN en ambos lados de R1. Pueden ser diferentes para que coincidan con el entorno VMware de un lado y el entorno LAN del otro lado.

!
! Start of per VRF or per SIMn section
!
! replace VRF names, dot1q tags, interface names as appropriate

vrf defintion VRF-SIM1
 address-family ipv4
 exit-address-family

interface fast0/0.10
 description * SIM1 inside subinterface *
 vrf forwarding VRF-SIM1
 encapsulation dot1q 10
 ip address 192.168.1.254 255.255.255.0
 ip nat inside

interface fast0/1.10
 description * SIM1 outside subinterface *
 vrf forwarding VRF-SIM1
 encapsulation dot1q 10
 ip address 10.0.10.1
! ip nat inside           <--- dear me! how could I copy&waste that one! (edited after comment)
 ip nat outside

ip nat inside source static 192.168.1.2 10.0.10.2 vrf VRF-SIM1
ip nat inside source static 192.168.1.3 10.0.10.3 vrf VRF-SIM1
ip nat inside source static 192.168.1.4 10.0.10.4 vrf VRF-SIM1

ip route vrf VRF-SIM1 0.0.0.0 0.0.0.0 fast0/1.10 10.0.10.254

!
! End of per VRF or per SIMn section
!

Tenga en cuenta: la parte nat podría necesitar algunos ajustes aquí, pero dado que la interfaz interna y externa están en el mismo VRF, no creo que se necesite más magia de configuración.

Luego, en el Cat3850, necesitará un conjunto de VLAN y SVI ( interface vlan) para que coincida con el lado "derecho" de R1:

vlan 10 
 name SIM1-TRANSIT

vlan 20
 name SIM2-TRANSIT

vlan 30
 name SIM3-TRANSIT

int g1/0/1
 desc * R1 fast0/1 *
 switchport mode trunk
 switchport nonegotiate
 switchport trunk allowed vlan 10,20,30
 spanning-tree portfast trunk

interface vlan 10
 desc * transit subnet to SIM1 *  
 ip address 10.0.10.254 255.255.255.0

interface vlan 20
 desc * transit subnet to SIM2 *  
 ip address 10.0.20.254 255.255.255.0

interface vlan 30
 desc * transit subnet to SIM3 *  
 ip address 10.0.30.254 255.255.255.0

— Marc 'netztier' Luethi
fuente

Tu pseudocódigo estaba bastante cerca. Cambio la interfaz fast0 / 1.10 a ip nat outside. Las declaraciones internas de ip nat necesitaban una coincidencia en vrf al final y, por alguna razón, las rutas enumeradas no funcionaban, pero ip route vrf SIM1 0.0.0.0 0.0.0.0 10.0.10.254 sí funcionaba. Tuve que usar un conmutador virtual L3 Extreme Networks en GNS3 ya que no puedo cargar un 3850 pero los principios son efectivamente los mismos.

— umhelp

La configuración del enrutador único en pocas palabras, evita la necesidad de VLAN adicionales, SVI y un Troncal 802.1q en el Cat3850: 1. Configuración en el lado de SIM / laboratorio como arriba, un VRF por entorno SIM. 2. Cada VRF-SIMn tiene un subif en la interfaz lateral de la SIM (como antes) y (nuevo) un subif etiquetado 802.1q en la interfaz "izquierda" del cable de bucle. 3. Cada VRF-SIMn hace su propia función NAT (como antes). 4. un VRF-FRONT adicional tiene n subifs etiquetados 802.1q en la interfaz "derecha" del cable de bucle, y una única interfaz hacia el cat3850. 5. Cat3850 necesita enrutar los rangos IP de NAT hacia VRF-FRONT.

— Marc 'netztier' Luethi

@umhelp el enrutador único lo hace todo necesitará al menos 4 interfaces / puertos (puertos enrutados adecuados, no puertos de un módulo de conmutador integrado como se puede encontrar en 800series o similar). Interface1 hacia el VMware vSwitch. Interfaz 4 hacia el cat-3850, más interfaz2 e interfaz3 conectadas entre sí con un cable de "bucle" u "oído" . Ese cable de bucle tiene un extremo "izquierdo" y "derecho". En su extremo izquierdo, hay n subifs asignados al n VRF-SIMn. En su extremo derecho, también hay n subinfs, todos asignados a VRF-FRONT. VRF-FRONT está tomando el rol de rutina que tenía el 3850 antes.

— Marc 'netztier' Luethi

@umhelp dependiendo de la licencia dada, un enrutador IOS XE puede simular dicho cable de bucle con pares internos de interfaces completamente virtuales llamados vasileft<number>/vasiright<number>. Con estos, puede conectar VRF sin desperdiciar interfaces y sin el dolor de cabeza de la fuga de rutas, y aún tener la mayoría de las características (enrutamiento dinámico, NAT, etc.). Consulte cisco.com/c/en/us/support/docs/ip/… para ver ejemplos.

— Marc 'netztier' Luethi

@umhelp: con respecto al rendimiento: tendrá que decidir usted mismo si el tráfico dado puede pasar por un enrutador dos veces (recuerde que incluso los ASR tienen un modelador de plataforma que limita el rendimiento general). Con un cable de bucle, cualquier tráfico cuenta doble contra el límite del modelador. Y habrá un tiempo adicional de espera / latencia / tiempo de serialización (probablemente muy bajo de todos modos, pero hay aplicaciones que no les gusta). Estos efectos son probablemente un poco más débiles cuando se usan las interfaces vasileft <número> / vasiright <número>. Entonces ... no puedo dar ninguna recomendación para ninguno.

— Marc 'netztier' Luethi