9 de mayo de 2016

Redes inalámbricas: opciones de despliegue

Muchas veces hablamos de redes inalámbricas con excesiva simplicidad dando por supuestos muchos elementos importantes y sin acabado conocimiento de la complejidad de la operación de los sistemas IEEE 802.11, y la variedad de formas de implementación disponibles.
Si bien hay muchos elementos a considerar en una implementación inalámbrica hay una en particular a la que no solemos prestar la debida atención. Hablamos de la red inalámbrica como si fuera simplemente una cuestión de accesss points y clientes inalámbricos olvidando que detrás de toda red de comunicaciones hay ante todo un planteo de diseño y arquitectura.

Hay 2 arquitecturas básicas a considerar (con algunas variantes adicionales que podemos encontrar en el mercado):

1. La red inalámbrica como servicio (NaaS)
En el caso de Cisco Systems la propuesta de NaaS para despliegue de redes inalámbricas es el conocido como Cloud Managed.
  • Es la propuesta de Meraki.
  • Hay diferente tratamiento para el tráfico de datos y de control del que se da al tráfico de gestión.
  • El tráfico de gestión (management) se concentra en la nube.
  • El tráfico de datos y de control se resuelve localmente.
  • Es muy escalable y de despliegue rápido.
  • El costo inicial de la inversión es más reducido (menor Opex).
2. Arquitectura Cisco Unified Access
Se trata en todos los casos de implementaciones completas en las instalaciones corporativas, sin dependencia de servicios de nube adicionales en las prestaciones básicas. En el caso de Cisco esta arquitectura puede ser desplegada en 4 modalidades diferentes.
  • Access Point Autónomos.
    Se trata de una implementación dotada solamente con APs capaces de operar por sí mismos sin necesidad de ningún dispositivo adicional.
    Tanto el tráfico de datos, como el de control y el de gestión se resuelven en cada AP individualmente y de modo local.
    Requiere una cuidadosa planificación (diseño) y la configuración individual de cada dispositivo.
    Es adecuado para pequeñas implementaciones de pocos APs.
    Es escalable, pero de modo progresivamente más trabajoso en la medida en la que la implementación crece.
    Se complica notoriamente cuando el número de APs comienza crece más allá de los 5 APs en un único dominio RF.
    En Cisco se utilizan APs Aironet autónomos, basados en IOS.
  • Centralizado.
    Este modelo de implementación requiere de APs capaces de operar en sistemas centralizados y de al menos un controlador.
    En este caso, el tráfico de datos, de control y gestión se resuelve de modo centralizado en el controlador. Los APs derivan la totalidad del tráfico al controlador utilizando un túnel encriptado gestionado utilizando CAPWAP (protocolo abierto de la IETF).
    El controlador es un punto de concentración de tráfico, con los riesgos inherentes a esta situación.
    Simplifica (aunque no resuelve todos) los desafíos de diseño de las redes inalámbricas y las tareas de configuración y monitoreo ya que todo se concentra en el controlador. La configuración responde de modo dinámico a las condiciones cambiantes del dominio de RF.
    Es adecuado para implementaciones de tipo corporativo, con múltiples APs. Optimiza sensiblemente el servicio de roaming y facilita la introducción de otros servicios como es el tracking en tiempo real de los clientes.
    El crecimiento de la red no presenta desafíos particulares ya que es fácilmente escalable.
    En Cisco se utilizan los APs Aironet basados en controlador, con controladores basados en AireOS.
  • Flex Connect
    Variante del despliegue centralizado que utiliza también APs y controladores.
    En este tipo de implementación, mientras el tráfico de gestión se mantiene centralizado en el controlador, el tráfico de datos se puede resolver localmente en cada AP o de modo centralizado en el controlador según convenga y se requiera.
    A las características de un despliegue centralizado le agrega la flexibilidad para la gestión del tráfico de datos eliminando el controlador como un potencial cuello de botella o punto de fallos para el tráfico de datos. Esto lo hace adecuado para implementaciones corporativas con múltiples puntos remotos que se conectan entre sí a través de una red WAN o Internet.
    Estas características facilitan la ampliación de la red, sobre todo su extensión en base a puntos remotos: apertura de sucursales, home office, etc.
    En el caso de Cisco se utilizan los mismos APs Aironet (solamente deben soportar este modo de operación) y controladores basados en AireOS.
  • Convergente
    Este modelo de despliegue supone un diseño que considera la red en su integridad, más allá de solamente la red inalámbrica. Apunta a una red en la que se gestiona el acceso sea inalámbrico o cableado de modo unificado.
    En este caso el controlador inalámbrico se encuentra integrado en el mismo switch de acceso, con lo que si bien el tráfico de datos, control y gestión sigue centralizado en el controlador, el mismo se encuentra en el switch de acceso con lo que se elimina el controlador dedicado como un único punto de concentración de tráfico dentro de la red.
    Es una solución adecuada para despliegues corporativos, con o sin extensión a través de la WAN o Internet, permitiendo la concentración del tráfico y el roaming (cuando sea necesario) aplicando este modelo en combinación con controladores convencionales para centralizar el tráfico o funciones que sean requeridas.
    Es tan escalable como los modelos de despliegue centralizado y flex connect.
    En este caso se utilizan los mismos APs Aironet basados en controlador (se sigue implementando CAPWAP para la operación entre AP y controladores) con switches LAN basados en IOS-XE (Catalyst 3650 y 3850).


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


1 de mayo de 2016

ip helper-address

Muchos estamos habituados a implementar servicios DHCP proxy, y en dispositivos Cisco IOS eso significa utilizar el comando ip helper-address. Sin embargo, este comando ofrece mucho más que sencillamente un servicio de proxy o relay para servicios DHCP.

¿Qué es un DHCP relay?
En redes extensas o con múltiples subredes en la que se debe atender solicitudes de  clientes DHCP es habitual que el servidor DHCP se encuentre centralizado.
Sin embargo esto implica una dificultad ya que las solicitudes DHCP se realizan en formato de broadcast (en redes IPv4), y como todos sabemos, los paquetes de broadcast no son reenviados por los dispositivos de capa 3. Esto significa que una solicitud DHCP no va más allá del segmento de red en el cual se encuentra el cliente que la genera, ¿cómo podría entonces alcanzar un servidor que se encuentra en una red o segmento de red diferente?
Para esto se utiliza un DHCP proxy. El proxy recibirá la solicitud en formato de broadcast y la convertirá en un paquete unicast cuya dirección destino será la del servidor. De esta manera la solicitud se convierte en completamente ruteable y podrá alcanzar el servidor con la única condición de que exista ruta que permita llegar a esa dirección de destino.

ip helper-addreess
En redes Cisco IOS esto se puede implementar utilizando el comando ip helper-address en cliente que requiere una configuración IP utilizando DHCP. Sin embargo este comando no solamente reenvía solicitudes DHCP.
Varios servicios críticos para el funcionamiento de la red utilizan broadcast como DHCP: TACACS, DNS, TFTP, NetBios, etc.; y es común que en redes complejas y extensas estos la interfaz que opera como default-gateway del segmento de red en el que se encuentra el servidores se encuentren en un área de red específica, en otro segmento de red. Esto implica que es necesario enrutar solicitudes de todos estos servicios, que en su definición original se propagan por broadcast.
Esta es la situación a la que responde el comando helper-address; permite que los routers actúen como proxies al reenviar solicitudes de estos servicios que corren sobre UDP.
El router recibe las solicitudes UDP en formato de broadcast y las reenvía como paquetes unicast a una dirección IP específica. También puede reenviarlas a una red o subred en particular.
El comando ip helper-address reenvía por defecto 8 servicios UDP: Time, TACACS, DNS, DHCP server, DHCP client, TFTP, NetBios name service y NetBios datagram service.

Router#configure terminal
Router(config)#interface GigabitEthernet 0/0
Router(config-if)#ip helper-address 172.18.1.3
    Reenvía el tráfico de servicios UDP que se recibe a través de la interfaz GigabitEthernet a la dirección 172.18.1.3 . Este comando se puede repetir si es necesario direccionar hacia más de un servidor.
Router(config-if)#ip helper-address 172.18.1.255
    Reenvía el tráfico de servicios UDP que se recibe a través de la interfaz Fastethernet a la subred 172.18.1.0/24. Esta es la forma de aplicación cuando los diferentes servicios no están en una única dirección IP sino en varias de un mismo segmento de red, como ocurre en una granja de servidores.
Router(config-if)#interface GigabitEthernet 0/1
Router(config-if)#ip directed-broadcast
    Cuando se direccionan los servicios UDP a una granja de servidores, es preciso indicar a la interfaz del router que da acceso a la graja de servidores que los servicios que recibe redirigidos a una dirección de broadcast (p.e. 172.18.1.255), debe encapsularlos como broadcast de capa 2 para que entonces puedan ver la petición todos los nodos de la subred.
Router(config-if)#exit
Router(config)#ip forward-protocol udp 517 
    Agrega a la lista de 8 servicios que se reenvían por defecto, el tráfico de UDP que está dirigido al puerto 517.
Router(config)#no ip forward-protocol udp 49 
    Retira de la lista de servicios que se reenvían, el tráfico de TACACS (puerto 49).

Esta configuración puede verificarse utilizando el comando show ip interfaces. 

Post Relacionado:


Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


20 de abril de 2016

Unidades de medición de datos

En los tiempos de Big Data y el crecimiento de los sistemas de almacenamiento, es bueno recordar algunos elementos básicos de las unidades de medición que se utilizan en la industria y su notación.

¿Bits o Bytes?
En primer lugar debemos tener presenta la diferencia entre bits o bytes.
Bits es la unidad de medición utilizada en los sistemas de transporte de datos. Es la unidad utilizada, por ejemplo, para expresar la capacidad de una conexión a Internet. Un bit refiere a un solo dígito binario y su símbolo es una "b" minúscula:

1 bit = 0

Byte es la unidad de medición utilizada en los sistemas de almacenamiento de datos digitales. Es la unidad que utilizamos para dimensionar memorias, discos rígidos y archivos. Un byte es un conjunto de 8 bits y su símbolo es una "B" mayúscula.

1 Byte = 01010101

1 Byte = 8 bits


En el mundo de los bits
La capacidad creciente de las redes de transporte digitales ha dado lugar a la aparición de nuevas unidades para expresar de modo más simple volúmenes muy grandes de información:

1 Kb (Kilobit)     = 1.000 bits
1 Mb (Megabit)  = 1.000 Kb = 1.000.000 bits
1 Gb (Gigabit)   = 1.000 Mb = 1.000.000.000 bits
1 Tb (Terabit)    = 1.000 Gb = 1.000.000.000.000 bits
1 Pb (Petabit)    = 1.000 Tb = 1.000.000.000.000.000 bits
1 Eb (Exabit)     = 1.000 Pb = 1.000.000.000.000.000.000 bits
1 Zb (Zettabit)   = 1.000 Eb = 1.000.000.000.000.000.000.000 bits
1 Yb (Yottabit)   = 1.000 Zb = 1.000.000.000.000.000.000.000.000 bits

Estas son medidas de capacidad, no de velocidad. Pero solemos convertirlas en medidas de "velocidad" cuando referimos la cantidad de datos que pueden ser transmitidos en la unidad de tiempo.
Por ejemplo 10 Gbps (Gigabits por segundo) o 10 Gb/s.
Sin embargo debemos tener presente que esta unidad propiamente indica la cantidad de bits binarios que pueden ser transmitidos en un segundo, no la velocidad a la que esos datos son transmitidos.

El universo de los bytes
La capacidad de almacenamiento y el tamaño de los archivos también es creciente, y en este sentido también se han introducido nuevas expresiones para simplificar las referencias. Sin embargo, en este caso no se escala de 1000 en 1000, sino de 1024 en 1024.

1 KB (Kilobyte)    = 1.024 Bytes
1 MB (Megabyte) = 1.024 KB  = 1.048.576 Bytes
1 GB (Gigabyte)   = 1.024 MB = 1.073.741.824 Bytes
1 TB (Terabyte)    = 1.024 GB = 1.099.511.627.776 Bytes
1 PB (Petabyte)    = 1.024 TB = 1.125.899.906.842.624 Bytes
1 EB (Exabyte)     = 1.024 PB = 1.152.924.504.606.846.976 Bytes
1 ZB (Zettabyte)   = 1.024 EB = 1.180.591.620.717.411.303.424 Bytes
1 YB (Yottabyte)   = 1.024 ZB = 1.208.925.819.614.629.174.706.176 Bytes

Los sistemas operativos de escritorio, al expresar la velocidad a la cual se descarga, copia o mueve un archivo, hacen referencia al volumen del archivo mismo y por lo tanto lo expresan en Bps, no en bps.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


19 de abril de 2016

Las interfaces del wireless LAN controller

Cuando intentamos comprender cómo opera un WLC (Wireless LAN Controller), uno de los puntos complejos a resolver es la relación entre WLANs, VLANs, Interfaces y Puertos. Una serie de elementos que aparecen en la configuración del controlador y cuya relación no siempre nos queda del todo clara.
Por eso me pareció interesante dedicar algo de atención al tema de las interfaces del controlador, un elemento central de su operación y que no siempre conocemos con precisión.

En primer lugar debemos considerar que en los controladores AireOS de Cisco Systems hay 2 tipos diferentes de interfaces: interfaces estáticas e interfaces dinámicas.

Interfaces estáticas
Se trata de interfaces de red lógicas que permiten recibir y enviar diferente tipo de tráfico (según su función) desde y hacia la red cableada. Estas interfaces pueden o no estar directamente vinculadas a un puerto físico del controlador y se encuentran definidas en la misma estructura lógica del dispositivo. No son definibles por el Administrador.
Las interfaces estáticas del controlador AireOS son las siguientes:
  • Interfaz de Management
    Es la utilizada por defecto para la gestión in-band del controlador.
    Es el origen y destino del tráfico del controlador hacia y desde diferentes servicios de la red tales como RADIUS y otros.
    También es la interfaz utilizada para la comunicación entre controladores que conforman un mismo grupo de movilidad o de RF.
    Es la interfaz que utiliza el controlador para la comunicación hacia y desde los access points y la que opera como origen y destino de los túneles CAPWAP que genera con cada access point asociado.
    Generalmente se le asigna una dirección IP de una subred dedicada a la operación del controlador y access points. Por defecto está asociada a la VLAN 0 que es la VLAN nativa en el caso del controlador.
  • Interfaz Virtual
    Interfaz para uso interno de la operación del controlador que interviene en procesos específicos. Se utiliza específicamente como dirección de DHCP relay para el servicio DHCP; también es la dirección del portal web de autenticación cuando se activa autenticación web con el portal interno del controlador; y es la dirección utilizada para la gestión de movilidad (roaming) de un cliente entre múltiples controladores.
    Se sugiere asignarle una dirección IP no ruteable, en muchos casos se utiliza para ella la IP 1.1.1.1. Por defecto está asociada a la VLAN 0 (nativa) del controlador.
  • Interfaz de Servicio
    Es la interfaz lógica asociada al puerto de servicio que se utiliza para la gestión out-of-band del controlador.
    Esta interfaz no soporta tráfico IEEE 802.1Q.
    Se sugiere que se utilice una subred diferente de la utilizada en la interfaz de management. Habitualmente se utiliza una dirección IP de la subred de gestión.
    Esta interfaz no soporta la configuración de default-gateway, por lo que si se desea hacer gestión remota del dispositivo es necesario asociar a la interfaz una ruta default estática hacia el gateway.


Interfaces dinámicas

Las interfaces dinámicas reciben también, en algunos casos, el nombre de interfaces VLAN. Son las interfaces definidas por el Administrador.
Son las interfaces en las que se mapean las redes inalámbricas (WLAN) a las diferentes redes en la infraestructura cableada (VLAN).
Su definición responde a ciertas reglas:
  • Múltiples WLANs pueden ser mapeadas a una única interfaz dinámica, y en consecuencia a una misma VLAN.
  • Múltiples interfaces dinámicas pueden ser asociadas a un mismo puerto físico (es el puerto a través del cual ingresará y saldrá el tráfico perteneciente a esa interfaz).
  • Cada interfaz dinámica puede ser asociada a un único puerto físico.
Estas interfaces dinámicas pueden actuar también como relay DHCP para los clientes inalámbricos asociados a los respectivos SSIDs.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


9 de abril de 2016

¿Qué es Meraki?

En diciembre del año 2012 Cisco adquirió una empresa declarando que su propósito era proveer una solución de redes escalable y fácil de implementar. Sobre la compra inicial Cisco incorporó recursos de investigación y desarrollo con el propósito de lograr un producto de nube de próxima generación.
Desde ese entonces Meraki es parte del portafolios de productos de Cisco, aunque una parte casi desconocida. Muchos creen que se trata de una propuesta de red inalámbrica alternativa a la red Aironet tradicional, pero en realidad es mucho más.

¿Qué es Meraki?
Meraki es una oferta de NaaS (Network as a Service) innovadora que desplaza el plano de gestión de los dispositivos de la red a un servicio de nube brindado desde los data centers de Meraki. Hardware y tráfico de datos en instalaciones de la empresa, gestión desde la nube.



¿Cuál es la oferta de Meraki?
Meraki cubre los requerimientos de una infraestructura de red completa a partir de 3 diferentes tipos e dispositivos:
  • Access Points
    Quizás el dispositivo más conocido. Se trata de una línea completa de dispositivos indoor y outdoor que permiten un despliegue rápido de una red inalámbrica de nivel enterprise.
  • Switches
    Switches tipo enterprise capa 2 y 3, de entre 8 y 48 puertos, para el despliegue de la red de acceso cableado con capacidad PoE.
  • Apliance de seguridad
    Dispositivo de acceso WAN que reúne en un único equipo las prestaciones de un router, un firewall statefull de próxima generación, terminador de VPNs IPsec, IPS de próxima generación, etc. Un gateway de la LAN hacia la WAN o hacia Internet con capacidad de inspección de aplicaciones e implementación de políticas de seguridad avanzadas.
A estos productos de hardware se suma el Systems Manager, que es una especie de cliente instalable en dispositivos terminales (Mac OSX, Microsoft, iOS o Android) que permite tener gestión y monitoreo remoto desde la nube de los terminales de la empresa. Incluye prestaciones como la de acceso de escritorio remoto, posibilidad de instalación remota de aplicaciones y borrado remoto de información almacenada en el dispositivo. Un gestor de terminales corporativas.

Estos dispositivos de hardware instalados en las facilidades de la empresa y las terminales que operan con Systems Manager, son administrados desde un sistema de gestión que opera en la nube de Meraki y que se accede con cualquier navegador web, desde cualquier ubicación.
Para dar soporte a este despliegue el servicio implementa:
  • 5 data centers distribuidos en diferentes regiones que operan en redundancia en caliente asegurando una disponibilidad mínima del 99,99% anual.
  • Los datos de cada cliente se encuentran replicados, en tiempo real, en al menos 3 de estos 5 data centers.
  • Acceso seguro con doble verificación incluyendo llaves RSA.
  • Toda la información del cliente (configuraciones, claves, etc., NO datos de los usuarios) se almacena encriptada.
Algunas características de la red Meraki
  • Solamente el tráfico de gestión de los dispositivos va a la nube de Meraki. El tráfico de datos de los usuarios se resuelve localmente y en ningún momento pasa por la nube.
  • Si se interrumpe el acceso a la red de Meraki por algún motivo, el tráfico local sigue sin complicaciones quedando limitada solamente la posibilidad de realizar cambios de configuración o monitorear la red.
  • En el caso de interrupciones en la conexión con la red, la información de estadísticas de tráfico y otras similares se almacena localmente hasta que se retome la conexión y se pueda descargar a la nube.
  • El hardware Meraki sólo puede ser operado desde la nube Meraki.
  • La nube Meraki solo opera hardware Meraki.
  • La asociación del hardware a la interfaz web del cliente se hace utilizando el número de serie del dispositivo.
  • Es posible el despliegue mixto de tecnologías, por ejemplo, switches Catalyst con access points Meraki. En este caso la nube Meraki solamente gestiona los access points.
  • Las prestaciones del sistema son de nivel enterprise avanzado. Incluye por ejemplo servicios de localización en tiempo real, reporting, filtrado y monitoreo a nivel de usuarios o aplicaciones, etc.
Para ampliar:

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.