Vlans, Enrutamiento entre Vlans y Seguridad de puertos con dispositivos Cisco.

REDES VIRTUALES

VLAN

Una red totalmente construida sobre dispositivos de capa 2 es una red llamada “red plana”. Este tipo de redes se componen de un único dominio de difusión, es decir, los broadcast inundan toda la red, lo que hace que al aumentar el número de host aumente el número de broadcast disminuyendo el desempeño de la red. Sin embargo las redes conmutadas permiten eliminar las limitaciones impuestas por las redes planas dividiendo dicha red en varias redes virtuales (VLAN)

Las VLAN (Virtual LAN) proveen seguridad, segmentación, flexibilidad, y permiten agrupar usuarios de un mismo dominio de broadcast con independencia de su ubicación física en la red. Usando la tecnología VLAN se pueden agrupar lógicamente puertos del switch y los usuarios conectados a ellos en grupos de trabajo con interés común. Una VLAN por definición es un dominio de difusión creado de forma lógica.

A.Ernesto, B. Enrique 2010, Redes Cisco CCNP a Fondo, Alfaomega RA-MA 

El ejemplo que se muestra en la gráfica siguiente es el que se estará desarrollando para explicar el objetivo de este post. 

 

Este será en escenario a desarrollar en este post, le sugerimos desarrollar el mismo paso a paso vía packet tracert

Para iniciar, comenzaremos configurando el Switch Multicapa via CLI de la siguiente forma:

Añadir leyenda

1)   Nos conectamos via cable consola, SSH o telnet nosotros lo haremos vía puerto consola, es posible que tenga que administrar el switch via http(s) para habilitar la administración por ssh o telnet. 

1)   Crearemos las tres Vlans que se muestran en nuestro diagrama inicial con los siguientes comandos:

Enable

Configure terminal 

Con estos comandos habremos creados las tres Vlan.

Para comprobarlo utilizaremos el comando show vlan

Luego procederemos a configurar las redes para estas Vlans y lo haremos con los siguientes comandos.

Habilitamos la consola de comandos y entramos en modo de configuración.

Enable

Configure terminal

Nos debe aparecer como se muestra en la captura a continuación:

Posteriormente introducimos los siguientes comandos:

Luego procedemos a configurar los puertos que conectan con los Switchs como puertos troncales.

Utilizaremos los siguientes comandos para configurar los puertos resaltados como troncales:

Switch Servidores

En modo de configuracion de interfaz

Inteface fastethernet 0/1

Switchport mode trunk

Estos comandos los utilizaremos en los Switch de capa 2 y debido a que en el otro extremo se encuentra un switch de capa 3 no debemos realizar configuración adicional debido a que la negociación se encuentra en auto, este al detectar los puertos de nuestro Switch de capa 2 en modo trocal se auto configura en modo troncal, como lo pueden ver con el siguiente comando: 

Show interfaces trunk

Procedemos a configurar los puertos en el Switch de Ventas y Operaciones:

Switch Ventas

Switch Operaciones

Comprobamos los extremos:

Como podemos ver el otro extremo negoció un enlace trocal al detectar el puerto en modo troncal del otro extremo.

Seguido a esto configuraremos un servidor DHCP de prueba en el Switch Multicapa con los siguientes comandos. 

Vlan 10 Servidores

    Vlan 20 Ventas

Vlan 30 Operaciones

Luego vamos configurar VTP para que nuestra Vlans se repliquen a todos los Switchs, lo hacemos de la siguiente forma:

El Switch multicapa será nuestro servidor VTP principal el que replicara los cambios de Vlan hacia los demás Switchs,

Los comandos son los siguientes:

Administramos el Switch en modo privilegiado nos debe aparecer de la siguiente forma: 

Con un numeral al final, agregamos los siguientes comandos: 

Los demás Switch los debemos configurar en modo cliente y lo hacemos con los siguientes comandos: 

Una vez hagamos esto, podemos ver con el comando show vlan, que las mismas se crean automáticamente: 

Estos comandos los usaremos en todos aquellos switchs que formen parte de nuestro despliegue de vlans, a excepción del switch principal el cual será configurado como servidor.

Observacion: El password y el nombre de dominio deben ser iguales en todos los Switchs, los que utilizamos anteriormente son de ejemplo.

Luego de esto procedemos a configurar los puertos para asignación de Vlan en nuestros Switch de capa 2, aquellos donde están conectados los dispositivos de usuarios. 

En el switch de servidores procedemos a configurar el puerto f0/2 con el siguiente comando. 

Al hacer esto nuestro servidor debe tomar una IP de del segmento de red de la Vlan 10, lo comprobamos con el siguiente comando en Windows ipconfig. En Linux ifconfig.

ipconfig

Pruebas de ping a nuestro Gateway

De esta misma forma haremos con todos los Switchs y puertos donde tengamos conectados dispositivos.

Procedemos a configurar los Switchs de Ventas y Operaciones.

Verificamos la IP

Seguimos con el Switch de Operaciones

Configuramos el puerto con la Vlan correspondiente

Comprobamos la IP de nuestra PC conectada al Switch de Operaciones.

Ahora realizaremos algunas pruebas de alcance:

Desde el equipo en la vlan de servidores le haremos ping a las demás Vlans

Podemos visualizar que le llegamos a los equipos de las demás redes, esto es posible porque nuestro Switch Multicapa está haciendo el enrutamiento  inter-vlan adicionalmente que las redes están conectadas directamente a él, en caso de que tengamos redes en otros routers, debemos utilizar algún protocolo de enrutamiento dinámico o rutas estáticas.

Seguridad de puerto

En algunos entornos la red debe estar asegurada para controlar qué estaciones terminales podrán tener acceso a la red. Cuando las estaciones de trabajo son estacionarias, sus direcciones MAC siempre se espera que se conecten al mismo puerto de la capa de acceso. En estaciones móviles la MAC puede ser aprendida dinámicamente o ser añadida en una lista de direcciones que se esperan en ese puerto. Los switches Catalyst de Cisco poseen una característica llamada port-security que controla las direcciones MAC asignadas a cada puerto. Para iniciar la configuración de seguridad de puertos en un switch se comienza con el siguiente comando.

Switch(config-if)#switchport port-security

Hasta este punto ya tenemos nuestra red operativa con las Vlans, ahora vamos a agregar seguridad a los puetos de los Switch

Primero configuraremos el puerto FastEthernet 0/2 de nuestro Switch de servidores, nos vamos a modo de configuración en la consola del Switch,

Enable

Configure terminal

switchport port-security mac-address sticky  con este comando configuramos el puerto para que aprenda la MAC del primer equipo que se conecte al puerto, también podemos configurar la MAC de forma estática con el siguiente comando:switchport port-security mac-address (direccion mac)

switchport port-security máximum 1 Este comando se configura para indicar que solo una dirección MAC es permitida por el puerto, la cual fue aprendida con el comando anterior, este aprendizaje tiene un tiempo de caducidad, si el host deja de transmitir por un tiempo específico se olvida la MAC y se aprende cuando el host vuelva a transmitir.

switchport port-security violation shutdown (Este comando permite configurar una opción para cuando se viole la configuración del comando anterior, en este caso tenemos tres opciones:

Shutdown: el puerto automáticamente se pone en el estado errdisable, lo que hace dejarlo inoperable y tendrá que ser habilitado manualmente o utilizando la recuperación de errdisable.

Restrict: el puerto permanente activo pero los paquetes desde las direcciones MAC que están violando la restricción son eliminados. El switch continúa ejecutando el temporizador de los paquetes que están violando la condición y puede enviar un trap de SNMP a un servidor Syslog para alertar de lo que está ocurriendo.

Protect: el puerto sigue habilitado pero los paquetes de las direcciones que están violando la condición son eliminados, no queda ninguna constancia de lo que está aconteciendo en el puerto.

Procedemos a configura los puertos TRONCALES

En el Switch Multicapa configuraremos el puerto FastEthernet 0/1 y estas mismas configuraciones la replicaremos a los demás puertos troncales,

Switchport trunk allowed vlan 10,20,30

Se agregan tantas Vlans como tengamos o las que queramos que pasen por los puertos troncales.

Los switch utilizados en los ejemplos son:

1 Switch multicapa 3560

3 Switch de Capa 2 2960

Observación: Algunos comandos pueden sufrir pequeñas variaciones, dependiendo del modelo del Switch.

Carlos Palomo.
Analista II/ Desarrollo de Proyectos.
Servicios de Proyectos y Consultoría SGSI 0526

Configuración de un FireCluster para redundancia y balanceo de carga perimetral en dispositivos Watchguard

Clúster master: Es el dispositivo que actualiza y mantiene toda la información de conexión y sesión del clúster y sincroniza esa información con el maestro de respaldo. En un clúster activo / activo, el maestro de clúster asigna conexiones y sesiones a sí mismo o al maestro de respaldo.

Backup master: El dispositivo que supervisa el maestro de clúster y asume automáticamente el rol de maestro de clúster en caso de una conmutación por error

En un clúster activo/activo, ambos miembros del clúster comparten la carga de tráfico que pasa a través del clúster. Un clúster provee escalabilidad porque ambos dispositivos comparten la carga. Si algunos de los miembros del clúster Activo/Activo falla, el otro miembro toma toda la carga del clúster, entonces para agregar redundancia y balanceo de carga en su red, seleccione un clúster activo/activo.

Metodos de balanceo de carga

Un Firecluster activo/activo soporta dos métodos de balanceo de carga.

-      Least connection  (Menos conexión): el clúster maestro asigna cada flujo de tráfico nuevo al miembro del clúster que tenga el número de conexiones abiertas más bajo

-      Round-robin: El maestro del clúster se alterna cada nuevo flujo de tráfico entre el maestro y su respaldo (Backup Master).

Requerimientos y restricciones de un FireCluster

-      Los Firebox deben ser el mismo número de modelo (FireCluster es totalmente compatible con todos los dispositivos Firebox o XTM, excepto los siguientes: Los dispositivos Firebox T10 no son compatibles con FireCluster.

• Los dispositivos XTM 25-W y 26-W sólo admiten FireCluster activo / pasivo.

• Los dispositivos XTM 21, 22 y 23 no son compatibles con FireCluster

• Los dispositivos FireboxV y XTMv admiten FireCluster activo / pasivo solamente, en un entorno VMware ESXi.

• Cada Firebox de un clúster debe utilizar la misma versión de Fireware. 

• Cada Firebox de un clúster debe tener una suscripción activa para los servicios de soporte, enumerados en el feature key como Servicio de LiveSecurity.

•  Para un clúster activo / pasivo, las interfaces de red deben estar configuradas en modo de enrutamiento mixto o en modo routing.

•  Para un clúster activo / activo, las interfaces de red deben configurarse en modo de enrutamiento mixto.

• FireCluster no admite el modo de red de puente.

• Para un clúster activo / activo, recomendamos que todas los Firebox tengan licencias activas para los mismos servicios opcionales de suscripción, como WebBlocker o Gateway AntiVirus.

• Debe tener un conmutador de red o VLAN para cada interfaz de tráfico activa.

• Para un clúster activo / activo, debe conocer la dirección IP y la dirección MAC de cada conmutador de capa 3 conectado al clúster. A continuación, puede agregar entradas ARP estáticas para estos dispositivos de red a la configuración de FireCluster.

Antes de empezar:

1) Asegúrese de tener estos elementos

-Dos Fireboxes activados con el mismo número de modelo.

-La misma versión de Fireware instalada en cada Firebox. -Los mismos módulos de interfaz instalados en cada Firebox (sólo M4600 y M5600). -La feature key para cada Firebox, guardada en un archivo local.
-Un conmutador de red para cada interfaz habilitada, opcional, personalizada o externa.
-Cables Ethernet para conectar las interfaces de ambos dispositivos a los conmutadores de red.

-Un cable cruzado para cada interfaz de clúster (Si configura una interfaz de clúster con backup master, debe utilizar dos cables de cruzados).

Requerimientos para los Switches y Routers

Todos los conmutadores y enrutadores en un dominio de difusión activo / activo de FireCluster deben cumplir estos requisitos.

1)      Todos los Switch y Routers del dominio de difusión no deben bloquear las solicitudes ARP si la respuesta contiene una dirección MAC de multidifusión.

- Este es el comportamiento predeterminado para la mayoría de los conmutadores de la capa 2.

- Para routers y switches de capa 3, el comportamiento predeterminado es esta en el siguiente RFC 1812, y dice que el enrutador no debe considerar cualquier respuesta ARP que afirma que la dirección de la capa de enlace de otro host o enrutador es una transmisión o dirección de multidifusión. Si es posible, deshabilite este configuración. Si no puede bloquear la compatibilidad con RFC 1812, es posible que deba configurar entradas estáticas MAC y ARP en su dispositivo de enrutamiento o capa 3.

Nota: Algunos conmutadores de capa 3 no le permiten configurar direcciones MAC estáticas en varios puertos. Si es posible, recomendamos que utilice un conmutador de capa 2, que requiere menos configuración y es más fácil de configurar

2)      Todos los conmutadores del dominio de difusión deben configurarse para reenviar el tráfico a todos los puertos cuando la dirección MAC de destino es la dirección MAC de multidifusión del FireCluster.

-      Para los conmutadores no administrados de la capa 2, este debe ser el comportamiento predeterminado.

-      Para los switches gestionados, podría necesitar agregar entradas MAC estáticas y ARP estáticas para FireCluster.

3)      Es posible que deba agregar la dirección IP y la dirección MAC de cada enrutador o conmutador de capa 3 en el dominio de difusión como una entrada ARP estática en la configuración de FireCluster.

Una dirección MAC de multidifusión es compartida entre el par. La dirección MAC comienza con 01: 00: 5E. Puede encontrar las direcciones MAC de multidifusión para un clúster en la ficha Informe de estado de Firebox System Manager o en el cuadro de diálogo de configuración de FireCluster en Policy Manager.

2) Conecta los dispositivos a la red, como se muestra a continuación

En este ejemplo, FireCluster tiene una interfaz externa y una confiable conectada a conmutadores de red. Las interfaces de clúster principales se conectan mediante un cable de cruzado.

 

Configure FireCluster

1) En WatchGuard System Manager, conéctese al Firebox que tenga la configuración que desea utilizar para el clúster. Después de habilitar FireCluster, este dispositivo se convierte en el maestro de clúster la primera vez que guarda la configuración.
2)  Haga clic en el icono de Policy Manager.
O bien, seleccione Herramientas> Administrador de políticas.
Policy Manager abre el archivo de configuración del dispositivo seleccionado.
3)  Seleccione FireCluster> Configuración.

Se inicia el Asistente para la configuración de FireCluster.

4)  Haga clic en Siguiente.

5)   Seleccione el tipo de clúster que desea habilitar:

Clúster activo / pasivo
Habilita el clúster para una alta disponibilidad, pero no para compartir cargas. Si selecciona esta opción, el clúster tiene un Firebox activo que maneja todas las conexiones y un Firebox pasivo que gestiona las conexiones sólo si se produce una conmutación por error del primer dispositivo.

Clúster activo / activo
Habilita el clúster para la alta disponibilidad y el uso compartido de la carga. Si selecciona esta opción, el clúster equilibra las solicitudes de conexión entrantes en ambos dispositivos del clúster.

6)  Seleccione la ID de clúster.

El ID de clúster solo identifica este clúster si configura más de un clúster en el mismo dominio de difusión de la capa 2. Si sólo tiene un clúster y su red no tiene dispositivos HSRP o VRRP, puede utilizar el valor predeterminado.

Para un clúster activo / pasivo, el Clúster ID determina las direcciones MAC virtuales utilizadas por las interfaces de los dispositivos agrupados. Si configura más de un FireCluster activo / pasivo en la misma subred, es importante saber cómo configurar la ID de clúster para evitar un posible conflicto de direcciones MAC virtuales. También es posible que las direcciones MAC virtuales de FireCluster puedan entrar en conflicto con dispositivos configurados HSRP y VRRP en su red.

6)  Si selecciona un cluster Activo/Activo, seleccione el método Balanceo de   carga.

El método balanceo de carga es el método usado para balancear conexiones entre los miembros del clúster activo. Hay dos opciones:

Menos conexión

Si selecciona esta opción cada nueva conexión es asignada al miembro del clúster activo con el menor número de conexiones abiertas, esta es la configuración por defecto.

Round-Robin

Si selecciona esta opción, las nuevas conexiones se distribuirán entre los miembros activos del clúster en orden de turno. La primera conexión va a un miembro del clúster. La siguiente conexión va al otro miembro del clúster, y así sucesivamente.

7) Seleccione las interfaces de clúster principal y backup. Las interfaces de clúster están dedicadas a la comunicación entre los miembros del clúster y no se utilizan para otros tráficos de red. Debe configurar la interfaz principal. Para redundancia, le recomendamos que también configure la interfaz de backup.

Primario
La interfaz de dispositivo que se dedica a la comunicación primaria entre los miembros del clúster. Seleccione el número de interfaz que utilizó para conectar los dispositivos FireCluster entre sí.

Apoyo/Respaldo
La interfaz de dispositivo que se dedica a la comunicación entre los miembros del clúster si falla la interfaz primaria. Seleccione el segundo número de interfaz que utilizó para conectar los dispositivos FireCluster entre sí, si los hubiera.

Observación: Las interfaces de clúster principal y backup deben estar en diferentes subredes. Si utiliza un conmutador entre cada miembro para las interfaces de clúster, las interfaces de clúster deben estar separadas lógicamente entre sí en VLAN diferentes.

8) Seleccione la interfaz para la dirección IP de administración. Utilice esta interfaz para conectarse directamente a los miembros de FireCluster para operaciones de mantenimiento. Esto no es una interfaz dedicada. También se utiliza para otro tráfico de red. No puede seleccionar una interfaz externa que utilice PPPoE como interfaz para la dirección IP de administración. Le recomendamos que seleccione la interfaz a la que normalmente se conecta el equipo de administración.

9) Cuando el asistente de configuración lo solicite, agregue estas propiedades de miembro de FireCluster para cada dispositivo:

Feature Key

Para cada dispositivo, importe o descargue la Feature Key para habilitar todas las funciones del dispositivo. Si ha importado previamente el Feature Key en Policy Manager, el asistente utiliza automáticamente esa Feature Key para el primer dispositivo del clúster.

Nombre de miembro

El nombre que identifica cada dispositivo en la configuración de FireCluster.

Número de serie

El número de serie del Firebox. El número de serie se utiliza como ID de miembro en el cuadro de diálogo Configuración de FireCluster. El asistente establece esto automáticamente cuando importa o descarga el Feature Key para el Firebox

Dirección IP de la interfaz principal del clúster

La dirección IP que utilizan los miembros del clúster para comunicarse entre sí a través de la interfaz principal del clúster. La dirección IP principal de FireCluster para cada miembro del clúster debe ser una dirección IPv4 en la misma subred.

Si ambos miembros del clúster se inician al mismo tiempo, el miembro del clúster con la dirección IP más alta asignada a la interfaz principal del clúster se convierte en el maestro.

Dirección IP de la interfaz del clúster de respaldo

La dirección IP que utilizan los miembros del clúster para comunicarse entre sí a través de la interfaz del clúster de respaldo. La dirección IP FireCluster de respaldo de cada miembro del clúster debe ser una dirección IPv4 en la misma subred.

No establezca la dirección IP del clúster principal o de backup en la dirección IP predeterminada de ninguna interfaz del dispositivo. Las direcciones IP de la interfaz predeterminada están en el rango 10.0.0.1-10.0.26.1. Las direcciones IP del clúster principal y de copia de seguridad no deben utilizarse para ningún otro elemento de la red, como las direcciones IP virtuales para VPN móvil o las direcciones IP utilizadas por las redes de sucursales remotas.

Dirección IP de administración

Una dirección IP única que puede utilizar para conectarse a un Firebox individual mientras está configurado como parte de un clúster. Debe especificar una dirección IP de administración diferente para cada miembro del clúster. Si la interfaz que ha elegido como Interfaz para la dirección IP de gestión tiene habilitada IPv6, puede configurar opcionalmente una dirección IP de gestión IPv6.

La dirección IP de gestión IPv4 puede ser cualquier dirección IP no utilizada. Le recomendamos que utilice una dirección IP en la misma subred que la interfaz que seleccione como interfaz para la dirección IP de gestión. Esto es para asegurarse de que la dirección es enrutable. La dirección IP de administración debe estar en la misma subred que el servidor de registro de WatchGuard o el servidor de syslog al que el FireCluster envía mensajes de registro.

La dirección IP de gestión IPv6 debe ser una dirección IP no utilizada. Le recomendamos que utilice una dirección IPv6 con el mismo prefijo que una dirección IPv6 asignada a la interfaz seleccionada como interfaz para la dirección IP de gestión. Esto es para asegurarse de que la dirección IPv6 es enrutable.

10) Revise el resumen de configuración en la pantalla final del Asistente de configuración de FireCluster. El resumen de configuración incluye las opciones seleccionadas y las interfaces que se supervisan para el estado del enlace.

Carlos Palomo.
Analista II/ Desarrollo de Proyectos.
Servicios de Proyectos y Consultoría SGSI 0526

Configuración de servicio de internet dedicado en Firebox WatchGuard sin Router.

Cuando configuramos el direccionamiento en la interfaz ethernet de un Router, no necesitamos configurarle un direccionamiento o gateway adicional, caso contrario cuando configuramos un enlace de internet en una interfaz de en un Firebox WatchGuard, en esta guía se mostrará con poner en funcionamiento un enlace dedicado (Frame-Relay, MPLS) en dispositivos WatchGuard cuando el proveedor nos suministra el servicio de internet a través de VLAN y nos proporciona un direccionamiento IP privado que va de cara al ISP y un direccionamiento IP público (sin Gateway) que va de cara al Firebox ya que no tenemos Router.  

El siguiente ejemplo muestra la configuración de un servicio dedicado Frame-Relay o MPLS en un dispositivo Firewall WatchGuard ajustando este para que haga uso de sus capacidades de capa 3.

Situación

Tenemos el servicio de internet de la empresa a través VLAN sobre MPLS, para su respectiva configuración el proveedor nos suministra un direccionamiento IP privado y un direccionamiento IP público que para su configuración necesitamos un router en el cual se debe configurar la IP privada en una de las interfaces y la dirección IP publica en otra de sus interfaces.

Ejemplo:

Direccionamiento

VLAN sobre MPLS

Privado Vlan X	Publico
192.168.180.0/30	200.200.40.80/28

En este tipo de configuraciones el proveedor de servicios, no suministra Gateway para el segmento de red público el cual es necesario para configurar la interfaz del Firebox Watchguard, entonces de momento pensaríamos que si no tenemos un Router no podremos utilizar el enlace, pero no es así, y aquí la solución:

Los dispositivos Firebox Watchguard puede configurado para que cumplan el rol de dispositivos de capa 3, adicional de su función principal como dispositivo Firewall.

Para ello debemos configurar en la interfaz correspondiente los siguientes parámetros: 

Se debe configurar la interfaz Eth0, o cualquier interfaz seleccionada como miembro de la Vlan (x),  que nos suministra el proveedor de servicio y asignarle una dirección IP disponible del pool de direcciones IP suministrado.

Para utilizar el enlace se debe forzar en las políticas que las peticiones hacia internet con NAT Dinámico con la dirección IP pública que nos suministró el proveedor, en este caso 200.200.40.80 el resto de las direcciones quedan disponibles para otros servicios, esto es debido a que el direccionamiento IP privado que aparece en la gráfica  2 pertenece a una Vlan por lo cual el dispositivo de borde del ISP está preparado para recibir tráfico de esta determinada VLAN (tráfico etiquetado respectivamente).

En enlaces dedicado donde el servicio no se suministre a través de Vlan (por ejemplo: Frame Relay)  no se debe forzar el tráfico hacia ninguna IP pública, esto debido a que el Gateway suministrado por el proveedor estará listo para recibir peticiones de cualquier subred interna de la empresa. 

Configuración:

A nivel de Firebox, a través del Policy Manager, vamos a las siguientes opciones:

Network > Configuración > Vlan

Creamos una nueva Vlan con los parámetros suministrados por el ISP. (La que se muestra es de ejemplo)

Luego nos dirigimos a Interfaces y seleccionamos la interfaz donde conectamos el enlace y la configuramos tipo Vlan. Interface Type= VLAN

Luego tildamos la opción Send and receive tagged traffic for VLANs y seleccionamos la vlan anteriormente creada.

Después procedemos a configurar las IPs públicas suministradas por el ISP como secundarias para ello nos vamos a VLAN y seleccionamos la VLAN creada y procedemos a agregar las IPs secundarias.

Aceptamos y procedemos al último paso, que consiste en dirigirnos a la política de navegación, configuramos el enlace para que sea usado por la política.

Selecionamos las opciones avazadas de esta política y seleccionamos la opción All traffic in this policy > Set source IP luego procedemos a configurar la IP pública asignada.

Una vez hagamos estos pasos guardamos los cambios en el Firebox WatchGuard y la política seleccionada quedara lista para usar el enlace dedicado.

Observación: Es importante tener en cuenta que con esta configuración el Failover no funcionará debido a que la política está forzada para que envié el tráfico a una dirección IP específica, en este caso el enlace dedicado. Para darle acceso a internet a los usuarios de esta política por otro enlace se debe reconfigurar la política para no forzar el tráfico por la dirección IP configurada. 

Diferencias entre MPLS y Frame Relay

MPLS

Frame-Relay

MPLS es un protocolo que utiliza etiquetas de paquetes para priorizar paquetes de red y para optimizar el rendimiento de la red. Si tiene aplicaciones sensibles a la calidad de servicio (QoS) como VoIP, videoconferencia, SAP, Oracle, Citrix u otras aplicaciones en tiempo real que se ejecuten en su WAN, debería considerar MPLS. MPLS es una tecnología de redes privadas similar al concepto de Frame Relay en que se entrega en la "nube". La principal diferencia con MPLS es que puede comprar calidad de servicio para aplicaciones a través de su WAN. Durante el proceso de aprovisionamiento, el transportista le entrevistará para determinar qué aplicaciones son importantes para su negocio, y luego construirá una plantilla de QoS para atender estas aplicaciones en su WAN. Estas aplicaciones tendrán prioridad sobre todo el resto del tráfico en tiempos de máxima carga. Aunque MPLS puede no ser la solución de menor costo, es la ÚNICA tecnología que soportará QoS. Para aplicaciones como Citrix, SAP, Oracle, Siebel, Peoplesoft, VoIP y Video, el rendimiento que utiliza las capacidades de QoS de MPLS puede mejorar drásticamente la calidad y la productividad. Si una aplicación funciona bien en un Frame Relay, funcionará mejor con MPLS. Si una aplicación no funciona adecuadamente en su VPN de Internet, si el problema es pérdida de paquetes o latencia, MPLS será la solución.

Puede ser implementado en software (por ejemplo en un encaminador), y por tanto puede ser mucho más barato. Está orientado a conexiones, como la mayoría de las WAN’s. Puede "empaquetar" tramas de datos de cualquier protocolo de longitud variable. La "carga del protocolo" (overhead) de Frame Relay es menor de un 5%. Ahorro en los costes de telecomunicaciones: Con el servicio Frame Relay los usuarios podrán transportar simultáneamente, compartiendo los mismos recursos de red, el tráfico perteneciente a múltiples comunicaciones y aplicaciones, y hacia diferentes destinos. Solución Compacta de Red: Según las necesidades del cliente, tras un estudio personalizado de las características del mismo, Telefónica Transmisión de Datos realiza el diseño de la red de comunicaciones Frame Relay. Tecnología punta y altas prestaciones: Frame Relay proporciona alta capacidad de transmisión de datos por la utilización de nodos de red de alta tecnología y bajos retardos como consecuencia de la construcción de red (backbone) sobre enlaces a 34 Mbps. y de los criterios de encaminamiento de la Red de Datos, orientados a minimizar el número de nodos de tránsito. Flexibilidad del servicio: Frame Relay es la solución adaptable a las necesidades cambiantes, ya que se basa en circuitos virtuales permanentes (CVP), que es el concepto de Red Pública de Datos, equivalente al circuito punto a punto en una red privada. Sobre una interfaz de acceso a la red se pueden establecer simultáneamente múltiples circuitos virtuales permanentes distintos, lo que permite una fácil incorporación de nuevas sedes a la red de cliente. Servicio normalizado: Frame Relay es un servicio normalizado según los estándares y recomendaciones de UIT -T, ANSI y Frame Relay Forum, con lo que queda garantizada la interoperabilidad con cualquier otro producto Frame Relay asimismo normalizado. Sólo ha sido definido para velocidades de hasta 1,544/2,048 Mbps. No soporta aplicaciones sensibles al tiempo, al menos de forma estándar. No garantiza la entrega de los datos.

Carlos Palomo.
Analista II/ Desarrollo de Proyectos.
Servicios de Proyectos y Consultoría SGSI 0526