El servicio de routing en VMware NSX
Hoy en esta nota sobre NSX explicaré como configurar el servicio de routing provisto por VMware NSX.
El servicio de routing en VMware NSX se basa en el servicio de nivel 2 provisto por VXLAN ya explicado en las notas anteriores a esta.
El servicio de routing en el NSX está diferenciado por dos tipos de tráfico
- Tráfico Norte/Sur, que representa el tráfico entre las VMs y la red externa
- Tráfico Este/Oeste, que identifica el tráfico entre las VMs.
La primera clase de tráfico es controlada por una o varias VMs que se crean mediante el NSX Manager, luego de haber hecho el deployment del NSX Controller Cluster y del Logical Distributed Switch (LDS).
La segunda clase es otro tipo de router, uno distribuido entre todos los host que forman parte del NSX.
En la figura del encabezado, podemos ver la interface que nos permite crear los dos tipos de router.
Dependiendo de si seleccionamos el Edge Service Gateway (ESG) o el Logical Distributed Router (LDR), crearemos una u otra clase de router.
El Edge Service Router es una VM que cumple las funciones de un router de perímetro.
En este tipo de router crearemos como mínimo dos interfaces, una externa, que nos conectaré a la red física y otra interna que nos conectará al router distribuido. Todo el tráfico de las VMs que necesite salir hacia afuera o tráfico externo que vaya hacia las VMs deberá pasar a través del ESG.
La cantidad de interfaces a crear dependerá de los segmentos externos y de los tenants internos que tengamos en nuestro escenario. En esta nota y por razones de simplicidad usaremos solo dos.
El resultado del depolyment es una VM que correrá en alguno de los ESXi que pertenezcan al cluster que hayamos designado en el momento de su creación (preferiblemente un cluster de administración, y no de producción).
Los pasos para configurar el Edge Service Gateway (ESG) consisten en crear las interfaces y asignarles las direcciones IP.
En este ejemplo vemos un ESG con dos interfaces. La IF de uplink (0) es multihome, lo que significa que tiene más de una dirección IP. La IF 1 tiene solo una dirección IP con máscara de 29 bits.
Mediante la IF interna, el router se conectará con el LDR (Transit-if).
Como podrá observar en la figura este tipo de router soporta múltiples servicios tal como Firewall, DHCP, NAT, Routing, Load Balancing, VPN, SSL VPN y Grouping Objects.
En la siguiente figura podemos ver un LDR:
Este router cuenta con cuatro IF, una que conecta al ESG y otras tres que conectan a 3 LDS, donde conectamos VMs de tres segmentos distintos y por lo tanto tres subnets distintas (172.16.10.0/24, 172.16.20.0/24 y 172.16.30.0/24) que son los segmentos de una aplicación multitier. Puede apreciar que la vNic 2 pertenece a la misma subnet que la vNic 1 del ESG. (192.168.10.2 y .1 respectivamente). Las IPs correspondientes a las vNics 10,11 y 12 serán los DGs de las VMs en cada tier.
También puede apreciar que los servicios ofrecidos por el Distributed Router son mucho mas limitados, incluyendo Firewall, Routing y Bridging.
A nivel de routing ambos routers soportan rutas estáticas o protocolos dinámicos, como OSPF y BGP. El ESG soporta además IS-IS.
Ambos soportan Redistribución de rutas.
Las vNICs 2, 10, 11 y 12 se han creado en cada uno de los host que forman parte del NSX, en forma automática. No son realmente VMkernel ports, pero actúan como tal, ya que asumen una dirección IP, que es la que debemos definir como DG en las VMs.
A nivel 2 forman un LDS, que es representado por PortGroups en cada vdSwitch.
A dichos PG se conectarán las VMs que formen parte del mismo LDS.
Cabe destacar que los nombres de los PG no son uniformes en los distintos vdSwitches. En nuestro ejemplo el LDS llamado Web-Tier tiene como nombre a nivel del vdSwitch Compute_VDS vxw-dvs-44-virtualwire-7-sid-5001-Web-Tier y en cambio en el vdSwitch Mgmt_Edge_VDS se llama vxw-dvs-16-virtualwire-7-sid-5001-Web-Tier.
Debido a esto, la asignación de las VMs al LDS debería hacerse desde el NSX manager, y no desde el vSphere web client.
A nivel del host la información correspondiente al Port Group correspondiente al Web-Tier Logical Switch es la siguiente:
General
Name: vxw-dvs-16-virtualwire-7-sid-5001-Web-Tier
Port binding: Static binding
Port allocation: Elastic
Number of ports: 8
Network resource pool: (default)
Advanced
Configure reset at disconnect: Enabled
Override port policies
Block ports: Allowed
Traffic shaping: Disabled
Vendor configuration: Disabled
VLAN: Disabled
Uplink teaming: Disabled
Network I/O Control: Disabled
Security policy: Disabled
NetFlow: Disabled
Traffic filtering and marking: Disabled
Security
Promiscuous mode: Reject
MAC address changes: Reject
Forged transmits: Reject
Ingress traffic shaping
Status: Disabled
Average bandwidth: —
Peak bandwidth: —
Burst size: —
Egress traffic shaping
Status: Disabled
Average bandwidth: —
Peak bandwidth: —
Burst size: —
VLAN
Type: None
Teaming and failover
Load balancing: Route based on IP hash
With IP hash load balancing policy, all physical switch ports connected to the active uplinks must be in link aggregation mode.
IP hash load balancing should be set for all port groups using the same set of uplinks.
Network failure detection: Link status only
Notify switches: Yes
Failback: Yes
Active uplinks: dvUplink1
Standby uplinks:
Unused uplinks:
Monitoring
NetFlow: Disabled
Traffic filtering and marking
Status: Disabled
Miscellaneous
Block all ports: No
De esta manera hemos visto como los servicios de nivel 3 (routing), se relacionan con los de nivel 2 (VXLAN). Te espero en mi próxima nota para hablar otros servicios ofrecidos por NSX.
Gracias por leer nuestro blog, participar y compartir.