DISEÑO DE RED
CAFE MADRID |
|
Un proyecto de enrutaciones entre sucursales con un propósito en especifico, un sistema de Fail Over hoy en día algo indispensable en una empresa con gran demanda de servicios de recursos internos y externos, la tolerancia a fallos dio pie de creación para este tipo de sistema y el uso de varios ISP simultáneos tanto para enlaces internos como enlaces hacia Internet. Como integrante del equipo de Ingenieros para dar una solución a este proyecto mis responsabilidades se centraba en la configuración de equipos y el diseño de enlaces con los diferentes proveedores.
1. El problema
La empresa en cuestión cuenta con múltiples sucursales alrededor del país y con el pasar del tiempo sus necesidades tecnológicas han ido aumentando y los antiguos esquemas de conexión ya no soy viables debido a que se requiere más ancho de banda, mayor tolerancia y una escalabilidad notable para poder implementar nuevos servicios en la red. Por estos factores la empresa comenzó a migrar sus enlaces antiguos Frame Relay a enlaces radiales con Ethernet a implementar sistemas Failover y mejorar sus equipos de borde.
El proyecto en cuestión está focalizado a los medios de conexión, configuraciones y los problemas más comunes en caso del uso de diferentes ISP omitiendo las configuraciones de VPN y encriptación por motivos de seguridad.
El proyecto en cuestión está focalizado a los medios de conexión, configuraciones y los problemas más comunes en caso del uso de diferentes ISP omitiendo las configuraciones de VPN y encriptación por motivos de seguridad.
2. Solución
El escenario en esta ocasión es una sucursal remota que tiene la compañía, los parámetro de configuración se duplican en cada router de borde de la red, el esquema de conexión es similar al siguiente.
En esta topología el punto focal son los Routers de borda, los cuales tienen interacción directa con los
diferentes ISP para lograr una comunicación exitosa con un sistema Failover debe cumplir ciertos
requisitos, la configuración debe ser capaz de:
diferentes ISP para lograr una comunicación exitosa con un sistema Failover debe cumplir ciertos
requisitos, la configuración debe ser capaz de:
- Verificar la conexión del ISP a la red.
- Cambiar y devolver el cambio de enlace sin intervención humana.
- Proveer un nateo automático de un enlace a otro
|
|
El direccionamiento en el ISP2 es otorgado por un servidor DHCP; se recomienda establecer un ancho de banda así el router sabrá hasta qué límite puede transmitir en ese canal y no se sobrepasa la tasa de transferencia. El IP SLA es el encargado de verificar mediante un ping el estado de la conexión del ISP1 en este caso, cumpliendo así el primer ítem de nuestra lista “Verificación de conexión”
El track verifica la conexión del ISP1 dejando la otra ruta flotante gracias a la distancia administrativa aplicada. Cuando el track está UP el tráfico se canaliza por el ISP1 pero cuando el track está DOWN los datos fluyen por el ISP2, el track seguirá intentando alcanzar su destino y en el momento que lo haga el cambio de ISP se devuelve quedando las conexiones como al principio, de esa manera marcamos el segundo ítem de nuestra lista de cambio y devolución de ISP.
El track verifica la conexión del ISP1 dejando la otra ruta flotante gracias a la distancia administrativa aplicada. Cuando el track está UP el tráfico se canaliza por el ISP1 pero cuando el track está DOWN los datos fluyen por el ISP2, el track seguirá intentando alcanzar su destino y en el momento que lo haga el cambio de ISP se devuelve quedando las conexiones como al principio, de esa manera marcamos el segundo ítem de nuestra lista de cambio y devolución de ISP.
|
|
El router-map nos permite hacer un match de las direcciones internas a la red externa y las Access-list confirman el pool de direcciones.
Como se destaca en la configuración del NAT el route-map entra en los parámetros de traducción y las
interfaces de los proveedores están declaradas ambas con overload para poder hacer una traducción
instantánea para las direcciones, de esa manera cumplimos con el ultimo ítem de la lista “Nateo
automático entre enlaces”. Los cambios deben ser imperceptibles para el usuario, todo el proceso debe ser automático y para lograrlo se implementó una configuración que involucra una combinación de políticas y protocolos de manera tal que trabajen unidos.
Como se destaca en la configuración del NAT el route-map entra en los parámetros de traducción y las
interfaces de los proveedores están declaradas ambas con overload para poder hacer una traducción
instantánea para las direcciones, de esa manera cumplimos con el ultimo ítem de la lista “Nateo
automático entre enlaces”. Los cambios deben ser imperceptibles para el usuario, todo el proceso debe ser automático y para lograrlo se implementó una configuración que involucra una combinación de políticas y protocolos de manera tal que trabajen unidos.
3. Resultados
Al finalizar el proyecto se entregó una red estable con un sistema funcional de Fail Over el cual cumple con los requisitos del cliente y da la confianza en la red que tanto se buscaba para brindar los nuevos servicios, entre las dificultades del proyecto se encontraba el uso de una sola interfaz por motivo de falta de recursos, usando un solo radio para los dos ISP y contando con un solo puerto Ethernet, no obstante la encapsulación trabaja perfectamente conjunto a todas las políticas de QoS y enrutamiento. El proyecto se ejecutó mediante conexiones segura SSH y en algunos casos conexiones directas por consola en sucursales remotas, el tiempo de trabajo para realizar todas las configuraciones tomó alrededor de tres (3) días en completar las 22 sucursales alrededor del país.
Se recomienda:
servicios internos y externos.
Se recomienda:
- Monitoreo de la red
- Implementar enlaces MPLS para la calidad de servicio
- Tener equipos de BackUp configurados
- Contar con un plan alterno debido a que un solo radioenlace no es suficiente
servicios internos y externos.