23 de diciembre de 2006

5 puntos que se deben tener en cuenta

El mundo del networking, es un ámbito técnico. Pero no es únicamente técnico. Lo es también empresarial, comercial. Y en este sentido estamos sometidos a las reglas de las áreas de comercialización de cada una de las empresas.

En este sentido, muchas veces el lenguaje comercial genera confusiones y nos arrastra de la base técnica, induciéndonos a un error.

Un router es siempre un router. Pero, como dispositivo, ¿es lo mismo lo que se ofrece como router de banda ancha que un router Cisco 1800? Si fuera así, entonces, ¿porqué la diferencia de precios?

Los switches LAN FastEthernet muestran grandes diferencias de precios, en nuestro medio, desde los u$s 30, hasta los 1200. ¿Son lo mismo? ¿En qué está la diferencia? ¿Sencillamente en la marca y nada más?

Es por esto que creo bueno cada tanto volver a los conceptos sencillos, vistos en sí mismos. Esto nos permite recuperar la precisión del lenguaje, y apreciar adecuadamente la naturaleza de nuestra tarea.

.1. Hay diferencias entre un router hogareño y un router enterprise.
No es extraño encontrarnos con que al momento de realizar implementaciones en estudios profesionales o pequeñas y medianas empresas, se proponga el uso de dispositivos de baja gama tipo D-Link, Netgear o Linksys para brindar conectividad. Por cierto que se encuentran configuraciones por demás interesantes en este tipo de equipos.

Sin embargo, hay que tener en cuenta que así como sería un exceso pensar en utilizar un router Cisco 1800 para administrar la conexión de banda ancha de mi casa, es un error pensar primariamente en dispositivos diseñados para el entorno hogareño para implementaciones de tipo empresario.

Este tipo de dispositivos carecen de muchos de los features de administración que pueden ser necesarios (aún cuando en muchos casos son administrables), carecen de features avanzados para diagnóstico y resolución de fallos, tienen recursos de seguridad muy limitados, y los protocolos y módulos que permiten implementar están limitados a su objetivo primario que es el entorno hogareño, o de oficina hogareña.

Es posible que en algún caso solamente se trate de un administrar un acceso de banda ancha que debe dar servicios a un conjunto reducido de terminales. Sin embargo, si este punto de acceso requiere de features de seguridad robustos, de administración avanzada, recursos de calidad de servicio y escalabilidad, la mejor respuesta no será un dispositivo de linea hogareña, sino enterprise.

.2. Tener siempre presente la diferencia entre un router y un switch.
Este punto puede parecer muy básico, pero si prestamos atención al modo en que hablamos y a muchos trabajos que se publican, nos daremos cuenta que no lo es tanto.

Un router es un dispositivo que opera principalmente conmutando tráfico a nivel de la capa 3 del modelo OSI. Es un dispositivo diseñado específicamente para conectar la red LAN a la WAN o a Internet según corresponda. Su capacidad es consecuencia primariamente de su sistema operativo (Cisco IOS en el caso de los dispositivos Cisco), y las prestaciones que ofrece dependen esencialmente de la versión de sistema operativo que corre.

Un switch en cambio, es un dispositivo dotado de un hardware radicalmente diferente, que está diseñado para el desarrollo de tareas específicas (circuitos ASICs). Estas características de hardware son las que le dan una capacidad de procesamiento mayor que la de los routers, si bien paralelamente tienen menor flexibilidad en su configuración.

Inicialmente cuando se hablaba de switch se hacía referencia a dispositivos LAN que operan en la capa 2 del modelo OSI, conmutando tramas. En la actualidad hay también switches multilayer o switches layer 3, que sobre la misma base (un hardware específico), pueden operar además en la capa 3 del modelo OSI. En todos los casos, estos switches son dispositivos LAN que pueden conmutar a nivel de capa 2 o capa 3 según el caso.

.3. Comprender cómo es el flujo de tráfico de una red.
Muchas veces al revisar el reporte de dificultades de un usuario se tiende a revisar en primer lugar la configuración de los dispositivos.

En realidad es imprescindible partir de una adecuada comprensión del flujo de tráfico de nuestra red. En muchas ocasiones los problemas del usuario final no son provocados directamente por la infraestructura sino por dificultades que surgen de la interacción entre la infraestructura de red y el modo de operación de TCP y los protocolos de capa superior.

En este sentido es esencial el monitoreo del tráfico de la red, la captura de tráfico, el análisis de las transacciones TCP de esas capturas, etc.

Por esto, al momento de diagnosticar la causa de un reporte del usuario es preciso evaluar en primer lugar si se trata de un problema de infraestructura o de flujo del tráfico de la red.

.4. Tener presente lo que un firewall puede, y no puede hacer.
Si bien hoy es frecuente que el término "firewall" esté incorporado en el lenguaje de los usuarios de la red, es más frecuente aún que sólo se tenga una vaga idea de lo que realmente hace un firewall (incluidos algunos Administradores, desafortunadamente).

Hay diferente tipos de firewall:

  • Firewalls de software.
    Tales como el firewall de Windows, o el ZoneAlarm.
  • Firewalls de hardware:
    Es el caso de Cisco ASA o Checkpoint.

En términos generales, los firewall de software son adecuados para usuarios finales, tales como terminales de uso hogareño o personal; los firewall de hardware son el recurso adecuado para redes corporativas.

Por otra parte, el firewall es un dispositivo de seguridad prácticamente imprescindible para la segurización de las redes de la mayor parte de las organizaciones actuales. Pero un firewall por sí sólo (aún adecuadamente configurado) no es una garantía de que la red esté segurizada adecuadamente. Por ejemplo, un firewall no protege por sí solo de ataques de phishing o virus distribuidos a través del correo electrónico.

.5. Nunca olvidar las bases del direccionamiento IP.
Es un hecho que la mayoría de los usuarios no tienen una comprensión adecuada de los principios básicos del direccionamiento IP.

Ante todo, hay que tener presentes los términos básicos:

  • Dirección IP - Todo dispositivo, con más precisión todo puerto, debe tener asignada una dirección IP que la identifica unívocamente en la red.
  • Máscara de subred - Le indica al dispositivo qué porción de la dirección IP define la red y cuál el ID del nodo. Es la que le permite identificar si la dirección IP de destino de un paquete es una dirección local o no. Todos los puertos de una subred deben tener asignada la mísma máscara de subred.
  • Default gateway - Se utiliza para poder establecer conexiones con dispositivos remotos. Cuando el dispositivo determina que un paquete tiene como destino un nodo que pertenece a otra red o subred (lo hace utilizando la dirección IP de destino y su propia máscara de subred), entonces el paquete debe ser enviado al default gateway para su enrutamiento hacia la red remota.
    Una red que no se comunica con otras redes, no necesita de un default gateway.

¿Tenés algún tip para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

15 de diciembre de 2006

10 comandos a configurar en un dispositivo nuevo


Cada vez que debemos configurar un dispositivo que se incorpora a la red, gran parte de la configuración depende tanto del dispositivo como del diseño de la red en la que ese dispositivo va a incorporarse. Sin embargo, hay también un conjunto de features que siempre podemos o debemos tener en cuenta, independientemente del dispositivo y la red.

Dependiendo de las implementaciones y del mismo Administrador, siempre hay una lista de cosas que "siempre hay que hacer": claves, nombres de dispositivos... etc. Esta es una lista posible de "10 cosas que siempre hay que configurar" en los dispositivos de una red:

  • Configurar cuentas de acceso a los dispositivos.
  • Configurar un hostname que lo identifique.
  • Configurar una clave de acceso al modo privilegiado.
  • Encriptar las claves.
  • Deshabilitar el acceso vía http.
  • Configurar un servicio de traducción de nombres.
  • Configurar commandos alias.
  • Configurar el reloj de los dispositivos.
  • Evitar que los mensajes logging molesten durante las tareas de configuración.
  • Configurar el servicio de logs.

Algunas de estas tareas ya las consideré en otros artículos, a los que procuraré referir en cada cado. Si tenés tu propia lista de "cosas que siempre hay que hacer" o algún elemento más para agregar, por favor, incorporalo como comentario a esta nota.

Configuración de cuentas de acceso a los dispositivos
Es altamente recomendable que los accesos a los dispositivos estén asegurados requiriendo la identificación de usuario y clave. No estamos hablando de una simple clave de acceso a modo usuario para la conexión a través de telnet o consola. La sugerencia es que ese acceso requiera del ingreso de usuario y clave.

Adicionalmente, Cisco IOS nos brinda la posibilidad de que esa clave se encripte utilizando MD5, como un forma adicional de segurizar nuestros dispositivos. El comando de configuración para realizar esta tarea es:

Router(config)#username [usuario] secret [clave]

Luego de configurado usuario y clave, es necesario aplicarlo a cada una de las líneas de acceso:

Router(config)#line con 0
Router(config-line)#login local
Router(config)#line aux 0
Router(config-line)#login local
Router(config)# line vty 0 4
Router(config-line)# login local

Obsérvese, para los que están acostumbrados a configurar una clave de acceso a modo usuario, que espre procedimiento reemplaza aquel.

Configurar un hostname
Todos los dispositivos Cisco tienen un nombre configurado por defecto: Router ó Switch, según corresponda. La configuración de un nombre que identifique claramente al dispositivo es de gran utilidad para el desarrollo de tareas de administración y monitoreo de los dispositivos y en términos generales debe responder a una acción planificada y parametrizada por el Administrador de la red.

La modificación de este nombre por defecto es extremadamente sencilla:

Router(config)#hostname [nombre]

Adicionalmente, Cisco IOS permite configurar un nombre de dominio de modo que el dispositivo "conozca" en qué dominio DNS se encuentra:

Router(config)#ip domain name [dominio]

Configurar una clave de acceso al modo privilegiado
Un elemento de seguridad muy importante es bloquear el acceso al modo privilegiado de los dispositivos (desde el que se accede al modo configuración) utilizando una clave de acceso. Adicionalmente Cisco IOS brinda la posibilidad de que la clave configurada sea encriptada utilizando MD5.

Esta es una tarea extremadamente sencilla:

Router(config)#enable secret [clave]

Encriptar todas las claves no encriptadas
No todas las claves configuradas en dispositivos Cisco IOS están encriptadas por defecto. Esto se puede solucionar fácilmente activando el servicio de encipción de claves que ofrece IOS:

Router(config)#service password-encryption

Deshabilitar el acceso vía http
Acceder a interfaces de administración a través de un web browser es una facilidad buscada por muchos Administradores. Todos sabemos que la configuración por CLI es más tediosa; pero también es más precisa y flexible... y más segura. De aquí que se recomiende fuertemente que, por seguridad, se desactive el acceso vía http (o web broser) a los dispositivos.

Los dispositivos Cisco permiten por defecto el acceso utilizando navegadores web. Si este acceso no va a ser utilizado, es más seguro desactivarlo. Es otra tarea simple:

Router(config)#no ip http server

Configurar un servicio de traducción de nombres
Cuando se ingresa una cadena de caracteres en la CLI de Cisco IOS, por defecto, IOS la interpreta como si se tratara de un comando. Si no puede asociar un comando a esa cadena de caracteres, entonces interpreta que el operador está requiriendo hacer telnet a un dispositivo al que identifica con un nombre, y por lo tanto procura traducir ese nombre a una dirección IP.

Esto suele provocar inconvenientes durante el proceso de configuración ya que, ante un error de tipeo al ingresar un comando el dispositivo comienza inmediatamente a intentar una traducción de nombres hasta que falla (dns lookup en inglés).

Esto tiene 2 soluciones posibles. La primera solución es desactivar el servicio de traducción de nombres que Cisco IOS tiene activado por defecto:

Router(config)#no ip domain-lookup

La otra opción, es configurar un servidor DNS real para que el dispositivo pueda hacer las búsquedas que sean necesarias:

Router(config)#ip name-server [IP]

Configurar comandos alias
El comando alias es un recurso interesante que permite a los Administradores generar su propio conjunto de comandos abreviados para realizar aquellas tareas más repetitivas.

Un ejemplo de las posibilidades que brinda:

Router(config)#alias [modo] [abreviado] [comando]
Router(config)#alias exec s show running-config

De este modo, ingresando una sola letra se ejecuta un comando más complejo.

El comando alias: un modo abreviado de realizar tareas repetitivas.

Configurar el reloj de los dispositivos
La mayoría de los dispositivos Cisco están dotados de un reloj interno que requieren de configuración. Esta tarea es de suma importancia al momento de revisar archivos logs, ya que es la base de información para estampar fecha y hora en los registros del log.

En principio este requisito se puede cubrir configurando, además de fecha y hora en el reloj, el uso horario:

Router#clock set [hh]:[mm]:[ss] [mmm] [dd] [aaaa]
Router#configure terminal
Router(config)#clock timezone [huso] [GMT]

En el caso de países o regiones que modifican el uso horario de acuerdo a la estación:

Router(config)#clock summer-time [huso] recurring

Ahora bien, en redes con numerosos dispositivos, es conveniente configurar el acceso a un servidor NTP a fin de asegurarnos que el reloj de todos los dispositivos se encuentre debidamente sincronizado, de modo que se facilite la tarea de diagnóstico y monitoreo. De este modo el dispositivo siempre buscará la información en el servidor al momento de inicializarse:

Router(config)#ntp server [IP]

Configuración de hora y zona horaria en dispositivos.

Evitar que los mensajes logging molesten
Cuando se está configurando o revisando el resultado de un comando show resulta muy molesta la interrupción que provocan los mensajes de logging de algunos sucesos estándar (p.e. el estado de las interfaces) o de un debug.

Esto es fácilmente solucionable, con una mínima previsión al momento de realizar la configuración. Un modo, no aconsejable, es eliminar sencillamente estos mensajes:

Router(config)#no logging console

El que quizás es el mejor modo (porque nos permite seguir recibiendo estos mensajes de estado, que son de gran importancia), es sincronizar estoa mensajes con el ingreso de comandos en el prompt del sistema operativo:

Router(config)#line con 0
Router(config-line)#logging synchronous
Router(config)#line aux 0
Router(config-line)#logging synchronous
Router(config)#line vty 0 4
Router(config-line)#logging synchronous

Configurar el servicio de log
Los mensajes de estado por defecto son enviados a la consola y no se almacenan. Sin embargo, es muy probable que los eventos que nos preocupan (fallos, actualizaciones de rutas, etc.) ocurran mientras no hay un operador conectado al puerto consola que pueda evaluarlos.

Es por esto de gran utilida indicarle al dispositivo que se desea enviar esta información a un servidor de syslog, o al menos, almacenarlos en un buffer de memoria en el mismo dispositivo:

Router(config)# logging buffered [tamaño]

¿Tenés algún tip para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

8 de diciembre de 2006

Introducción a túneles GRE

Hoy es tema de todos los días, para los que trabajamos en el ámbito del networking, la referencia a las VPNs. Desde grandes empresas con miles de VPNs, hasta pequeñas PyMEs con una o varias VPNs, el tema está al orden del día.
Cuando abordamos el tema VPNs subyacen detrás dos conceptos:
  • La red virtual, a la que también llamamos túnel, que emula una conexión punto a punto entre 2 nodos conectados a Internet.
  • La encripción de los datos que circulan sobre esa red virtual para darle seguridad al intercambio privado de información sobre una red pública.
Como siempre, hay protocolos involucrados en ambos aspectos. Protocolos de tunelización y protocolos de encripción. Para la tunelización uno de los protocolos más utilizados (quizás porque es el que implementa Microsoft) es PPTP (Point-to-Point Tunneling Protocol). PPTP de hecho utiliza GRE para generar los túneles.
¿Qué es GRE?
Genereric Routing Encapsulation (GRE) es un protocolo originalmente desarrollado por Cisco Systems que se ha convertido en un estándar de la industria definico en las RFC 1701, 1702 y 2784. Es un protocolo de túnel, es decir, que permite transportar paquetes de una red a través de otra red diferente. Por ejemplo, permite establecer un enlace de la red 10.0.0.0 a través de la red 172.16.0.0.

¿Cuándo utilizar GRE?
  • Cuando, por ejemplo, es necesario trabajar con un protocolo que no es enrutamble como NetBIOS o con protocolos enrutables diferentes de IP a través de una red IP. Se puede constituir un túnel GRE para trabajar con IPX o AppleTalk sobre una red IP.
  • Cuando debemos conectar dos puntos remotos de una misma red (antes mencioné el ejemplo de la red 10.0.0.0) y para ello necesitamos utilizar enlaces que pertenecen a una red diferente (en el ejemplo, la 172.16.0.0).
¿Cómo se configura un túnel GRE?Configurar el túnel GRE es en principio una tarea relativamente sencilla. Para revisar los comandos debemos considerar ambos extremos del enlace a través del cual debe operar el túnel:
Router A
interface Ethernet0/1
ip address 10.2.2.1 255.255.255.0
!

interface Serial0/0
ip address 172.16.4.1 255.255.255.252
!
interface Tunnel0
ip address 10.10.10.2 255.255.255.252
tunnel source Serial0/0
tunnel destination 172.16.4.2
!

Router B
interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.0
!
interface Serial0/0
ip address 172.16.4.2 255.255.255.252
!
interface Tunnel0
ip address 10.10.10.1 255.255.255.252
tunnel source Serial0/0
tunnel destination 172.16.4.1
!

En este sencillo ejemplo se ha creado una interfaz virtual en cada router: las interfaces túnel. Estas interfaces utilizan su propia red, comportándose como un enlace punto a punto. El tráfico de este túnel será físicamente enviado a través de las interfaces seriales.
De este modo, entre ambos routers aparecerán ahora 2 rutas posibles: la ruta a través de las interfaces seriales y la ruta a través de la interfaz túnel. Este túnel puede transportar tanto tráfico no ruteable como que utilice otros protocolos enrutados.
En el caso del ejemplo el túnel se realiza sobre un enlace privado que podría pertener, por ejemplo, a un red frame-relay. También puede realizarse sobre Internet; en este caso se puede utilizar algún protocolo de encripción como IPSec para brindar privacidad y seguridad.
Tenga en cuenta que la configuración es bastante sencilla. Lo realmente importante aquí es el diseño: definir con claridad los puntos de inidio y fin del túnel, y el tráfico que se va a enviar a través del mismo.
Las interfaces túnel son interfaces virtuales que son tratadas por Cisco IOS como una interfaz más:
RouterB# sh ip int brief
Interface . . . . IP-Address .OK? .Method .Status . . . Protocol
FastEthernet0/0 . 10.1.1.1 . .YES .manual .up . . . . . up
Serial0/0 . . . . 172.16.4.2 .YES .manual .up . . . . . up
Serial0/1 . . . . unassigned .YES .unset . admin down . down
Tunnel0 . . . . . 10.10.10.1 .YES .manual .up . . . . . up

Consideraciones adicionales
  • GRE toma un paquete ya existente, con su encabezado de capa de red, y le agrega un segundo encabezado de capa de red, lo que implica que el paquete que se envía a través del túnel es de mayor longitud por lo que puede ocurrir que esté excediendo la longitud permitida en la interfaz física. Esto provoca el descarte de ese paquete.
    Para solucionar este inconveniente se puede aplicar el comando ip tcp adjust-mss 1436 sobre la interfaz túnel para asegurarse de que no se supere el MTU permitido sobre el enlace.
  • El enlace sobre el túnel GRE no requiere ninguna información de estado, por lo que puede ocurrir que un extremo del túnel se encuentre en estado de down y el otro continúe presentándose como up.
    Para evitar esta situación habilite keepalive en cada extremo del túnel. De este modo cada extremo enviará mensajes de keepalive sobre el túnel y si un extremo no recibe los mensajes enviados por el otro entonces pasará al estado de down.
Recuerde que GRE no provee encriptación de la información. No constituye propiamente una VPN segura.
¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

3 de diciembre de 2006

Template de configuración básica Cisco Catalyst 2950

El uso de "templates" de Excel nos permite automatizar procesos de configuración de dispositivos. Con este propósito les ofrezco este template Excel para relizar la configuración básica de un switch Catalyst 2950.

¿Qué hace este template?
Estos templates permiten generar los comandos de configuración necesarios para completar una tarea, utilizando la información (claves, direcciones IP, etc.) que nosotros proporcionamos.

Para esto el archivo cuenta con 2 hojas:

  • Una hora de referencias, en la que encontramos los comandos que han de utilizarse para desarrollar la tarea. Estos comandos están acompañados de una brevísima descripción de su propósito.
  • Una segunda hoja de variables, en la que debemos ingresar los parámetros específicos que deseamos sean aplicados al dispositivo.

Completada la información, los macros del archivo generarán automáticamente una nueva hoja con los comandos de configuración que deben ser utilizados para conseguir la configuración objetivo.

En este caso particular, la hora de referencias realiza las siguientes acciones:

  • Habilita el servicio de encripción de claves.
  • Configura un hostname.
  • Habilita el dispositivo como servidor http para utilizar la interfaz web para administración y monitoreo remotos.
  • Configura claves de acceso al modo usuario para los accesos por consolo o por terminal virtual (telnet).
  • Configura una clave de acceso encriptada para el modo privilegiado.
  • Sincroniza los accesos por consola y por telnet con los mensajes de logging, de modo que no haya interrupciones en el ingreso de comandos.
  • Configura un servidor DNS para la traducción de nombres.
  • Configura el reloj: hora y fecha.
  • Habilita el servicio de "estampado" de hora y fecha en los mensajes de logging (mensajes en pantalla, debug, etc.).
  • Asigna una dirección IP a la interfaz VLAN1 para permitir el acceso por telnet y configura un default gateway para permitir el acceso remoto.
  • Configura todos los puertos del switch como puertos de acceso.
  • Graba la configuración en la NVRAM.

Cómo se utiliza

  1. Baje el template a su terminal.
  2. Abra el archivo Microsoft Excel y permita la ejecución de macros.
  3. Diríjase a la hoja "Variables".
  4. Complete la información específica que corresponde al dispositivo que desea configurar en la columna blanca titulada "Definición del usuario".
  5. Verifique que la información ingresada sea la correcta.
  6. Seleccione el botón "Reemplazar" que está a la derecha de la tabla que ha completado.
  7. Se generará una nueva hoja en el archivo con los comandos necesarios para obtener la configuración deseada.
  8. Ingrese por consola a la línea de comando del dispositivo que desea configurar y diríjase al modo de configuración:
    Switch>enable
    Switch#configure terminal
    Switch(config)#_
  9. Copie los comandos de configuración (no los comentarios) y péguelos directamente en la línea de comando del dispositivo.

Como resultado de esta acción se han de ejecutar todos los comandos y grabar la configuración en la NVRAM del dispositivo. El mismo ya está configurado de acuerdo a su diseño.

Tenga en cuenta que este archivo de configuración configura solamente puertos FastEthernet, no incluye ningún puerto GigabitEthernet. Tampoco genera VLANs ni aplica features de seguridad. Implementa solamente los features de una configuración básica de un switch Catalyst 2950.

¿Tenés alguna información o referencia adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

27 de noviembre de 2006

Infraestructura escalable con 10Gb Ethernet

Cuando abordamos el tema de la disponibilidad de ancho de banda de nuestras redes de datos muchas veces tengo la sensación de que estamos hablando de automovilismo. El concepto general es : cuando más rápido, mejor.

Y es que la realidad de nuestras redes ha sido esa: en la década de los '90 el estándar eran redes Ethernet de 10Mbps, y las redes Token Ring de 16 Mbps y FDDI de 100Mbps (sobre fibra óptica) se veían como "redes muy rápidas". Ya hacia el fin del siglo, el estándar típico eran redes FastEthernet de 100Mbps sobre cobre. Hoy ya a nadie le admira escuchar hablar de enlaces de 1Gb Ethernet, lo que empieza a verse casi como una norma; y el estándar de !0Gb Ethernet ya está presente para quedarse.

Por lo tanto, si estamos encarando el proyecto de una nueva red, o de actualizar una infraestructura ya existente, se debe tener presente y asegurarse que sea fácilmente escalable a los nuevos estándares Ethernet. Esto significa cubrir una serie de requisitos que permitan incrementar la velocidad de la red (la tecnología está disponible, la infraestructura debiera permitirnos implementarla) de modo que sea posible implementar nuevas aplicaciones e incrementar el tráfico sin dificultades.

La necesidad de velocidad
¿Porqué habría que pensar en 10Gb Ethernet?

Aunque nuestras terminales de escritorio funcionan excelentemente con accesos FastEthernet de 100Mbps; y las terminales wireless operan a 54 Mbps o menos, hay una serie de puntos que se deben considerar seriamente:

  • El tamaño de nuestros archivos está creciendo diariamente de modo alarmante. Y transferir archivos de mayor tamaño requieren más tiempo completar la transmisión o aumentar la velocidad para reducir los tiempos.
  • Progresivamente en el ámbito empresarial se implementan cada vez más aplicaciones, especialmente algunas que trabajan en tiempo real, que requieren disponibilidad de abundante ancho de banda para trabajar adecuadamente. Y la proyección que se observa en cuanto al desarrollo de nuevas aplicaciones, va en el mismo sentido.
  • Hay que tener en cuenta que el ancho de banda total de los backbone es compartido por todos los usuarios. Y nuestras redes tienen cada vez más cantidad de usuario, que utilizan archivos de mayor tamaño y corren aplicaciones en tiempo real simultáneamente.
  • Se implementan switches de alta velocidad para administrar el tráfico que se recibe desde los escritorios hacia servidores que en términos generales tienden a trabajar a 1 Gbps.

Una recomendación que suele darse en diseño al momento de planificar una nueva red o una actualización de infraestructura existente, es que se estimen los requerimientos a corto plazo y se multipliquen al menos por cinco.

10Gbps sobre cobre
Ethernet opera en las capas 1 y 2 del modelo OSI, y ha sido definida en la IEEE 802.3. El estándar de 10Gbps Ethernet se encuentra definido en la IEEE 802.3ae, utilizando los mismos estándares que el Ethernet original (direccionamiento físico, estructura y tamaño de tramas, etc.); esto es lo que asegura la compatibilidad de todas las implementaciones Ethernet desde 10Mbps hasta 10Gbps, incluyendo las redes wireless LAN 802.11. La diferencia más significativa es que no utiliza CSMA/CD ya que sólo opera en arquitecturas full dúplex.

Inicialmente los estándares 10Gbps Ethernet operaban exclusivamente sobre fibra óptica, pero la fibra es aún, no sólo más costosa que el cobra, sino también y especialmente, de implementación más compleja. De allí los esfuerzos que se han realizado para lograr estándares que operen a 10Gbps sobre cableado de cobre.

Los nuevos estándares pueden trabajar sobre cableado UTP categoría 5e o 6 con distancias de hasta 55 metros. Una alternativa aún mejor es operar con cableado categoría 6e o 7, con lo que se obtienen distancias de hasta 100 metros ya que reducen los problemas de alien crosstalk (ATX). Varios fabricantes ya están ofreciendo soluciones de este tipo.

Estos mismos estándares permiten tendidos de hasta 40 kilómetros, con el mismo ancho de banda, sobre fibra óptica. De este modo ya es posible desarrollar backbones para redes de campus, MANs y WANs de 10Gbps Ethernet.

Consideraciones para el planeamiento
En principio, al ser un estándar que operaba solamente sobre fibra óptica, se concibió 10Gbps Ethernet como un estándar para redes de backbone; pero con la aparición de estándares sobre cobre, es ahora posible pensar en un estándar (en principio) para granja de servidores y redes de almacenamiento.

En cuanto a costo, siguen siendo los enlaces de mayor costo en la actualidad, pero mucho menos costosos que en el año 2003 cuando se aprobaran los primeros estándares.

Por lo tanto, si bien es posible que la red actual no requiera o no cuente con el presupuesto para implementar 10Gbps Ethernet, es muy posible que en pocos años más se plantee reemplazar los backbone actuales de 1Gbps, o los accesos en servidores de esa velocidad. Por lo tanto, si bien es posible que no se instalen dispositivos de 10Gbps hoy, sí es preciso prever que el nuevo cableado de red (especialmente el de backbone y data center) sea categoría 6 o 7 de modo de soportar a futuro un upgrade de este tipo.

10Gbps Ethernet se presenta hoy como la próxima generación Ethernet que se convertirá en un estándar de la industria. Por lo tanto, nuestras redes deben estar preparadas para esto.

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

25 de noviembre de 2006

Controle las actualizaciones de los protocolos de enrutamiento

La administración del uso del ancho de banda de nuestros enlaces es un punto sensible en la tarea diaria del Administrador de la red.

En este punto es importante considerar el tráfico que generan los protocolos de enrutamiento que se implementan. Muchas veces carece de sentido el envío de actualizaciones de enrutamiento a través de interfaces a las que no hay conectados dispositivos que dialoguen utilizando ese mismo protocolo. En otras ocaciones, razones de seguridad hacen aconsejable no publicar el estado de nuestras redes a través de determinadas interfaces.

Filtrar el envío de actualizaciones de enrutamiento brinda 2 ventajas: optimiza el uso del ancho de banda de nuestros enlaces, a la vez que reduce el uso de la CPU de nuestros dispositivos.

Hay dos modos básicos de filtrar el envío de actualizaciones de enrutamiento: el pasivado de interfaces y el uso de listas de distribución. En este artículo he de centrarme en el pasivado de interfaces utilizando el comando passive-interface.

El comando passive-interface
Cuando se desea configurar apropiadamente un protocolo de enrutamiento, este es un comando que es necesario conocer.

Es un comando de configuración del protocolo de enrutamiento y se utiliza para indicar al protocolo que se está configurando que NO envíe actualizaciones de enrutamiento a través de una interfaz determinada.

  • Este comando está disponible para ser utilizado con todos los protocolos de enrutamiento excepto BGP.
  • En RIP, IGRP y EIGRP, indica simplemente que no se envían actualizaciones, pero la interfaz seguirá copiando las que reciba de sus colindantes.
  • En OSPF la interfaz pasivada no recibirá ni enviará actualizaciones de enrutamiento.
  • Y OSPF y EIGRP, suprime el envío de paquetes hello, por lo que se impide el establecimiento de relaciones de vecindad con los colindantes. Por este motivo, en estos protocolo la sugerencia es implementar listas de distribución.

Primera forma de implementación
La primera forma de implementar el pasivado de interfaces es indicar qué interfaces deben pasar al estado pasivo, o no han de enviar actualizaciones.

Un ejemplo de configuración:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 172.16.0.0
Router(config-router)#network 172.17.0.0
Router(config-router)#network 172.18.0.0
Router(config-router)#passive-interface fastethernet 0/0

De este modo, luego de activar el protocolo en todas las redes directamente conectado indicamos que no se publiquen actualizaciones de enrutamiento a través de la interfas FastEthernet 0/0, a la que, por ejemplo, está conectada nuestra red LAN.

Segunda forma de implementación
Otra forma de pasivar interfaces es pasivar todas las interfaces que están comprometidas en el proceso de enrutamiento y luego habilitar el envío solamente a través de las interfaces elegidas.

Volviendo a nuestro ejemplo:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 172.16.0.0
Router(config-router)#network 172.17.0.0
Router(config-router)#network 172.18.0.0
Router(config-router)#passive-interface default
Router(config-router)#no passive-interface serial 0/1

En este caso se está bloqueando el envío de actualizaciones de enrutamiento a través de todas las interfaces del dispositivo, excepto la interfaz serial 0/1.

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

18 de noviembre de 2006

Configuración de hora y zona horaria en dispositivos

Cuando se configura un router o un switch, no es realmente necesario configurar la hora y la zona horaria del dispositivo para que este opere correctamente en la red. Realmente la configuración de hora en los dispositivos no es en nada necesario para que el dispositivo desarrolle sus tareas tal como se espera. Sin embargo, esto no significa que no sea necesario configurar la hora y el huso horario de los dispositivos. Algunos de los beneficios de realizarlo son:

  • Los archivos log y los mensajes debug mostrarán la fecha y hora correctos. Esto es de suma importancia de en las tareas de diagnóstico de fallos.
  • Configurar el uso horario correcto, hace posible establecer comparaciones entre la operación de dispositivos instalados en diferentes regiones.
  • Permite agendar la ejecución de comandos utilizado el feature kron de Cisco IOS.
Cisco IOS permite realizar este ajuste horario de 2 modos diferentes:
  • Configurando hora y huso horario en cada dispositivo individualmente.
    Es un modo adecuado para ajustar este recurso cuando se desea configurar solamente un grupo pequeño de dispositivos.
  • Implementar el uso de NTP (Network Time Protocol) en todos los dispositivos de la red.
    Este es el método ideal para establecer un indicador horario sincronizado en dispositivos que operan en redes de mediano o gran tamaño.
Configuración de hora y huso horario en dispositivos individualmente.
Si un dispositivo Cisco conserva su configuración horaria por defecto (no ha sido modificada por configuración), la fecha ha de estar fijada en el día lunes 1 de marzo de 1993:

Router#show clock
*02:37:22.871 UTC Mon Mar 1 1993
Router#


Si se obtiene este valor como respuesta a un show clock, esto nos indica que nadie a configurado una fuente de sincronía o una hora localmente.
Configuración del huso horario
El primer paso es configurar correctamente el huso o zona horaria. Si se configura primero la hora y luego el huso horario, al configurar el huso horario se reiniciará el reloj.

Para esta tarea, es necesario conocer como información previa la diferencia horaria respecto de Greenwich Mean Time (GMT). En el caso de Argentina, nuestro huso horario es GMT -3.
Para configurar el uso horario, debe utilizar el comando:
Router(config)#clock timezone AR -3
Router(config)#_

El comando permite asignar un nombre al huso horario que estamos configurando, de modo de identificarlo luego.
Debemos considerar también que hay países y regiones que modifican su huso horario de acuerdo a la estación del año con fines de ahorro de energía. En estos casos podemos indicar al dispositivo que debe cumplir con esta norma utilizando el comando:
Router(config)#clock summer-time AR recurring
Router(config)#_

De este modo se le indica que actúe de modo automático atrasando o adelantando el uso horario de AR (si bien este no es aplicable a Argentina) de acuerdo a las fechas estándar internacionalmente utilizadas (abril y octubre). También se puede establecer manualmente la fecha de cambio con este mismo comando pero con la variante date en lugar de recurring.
Configuración de la hora
El siguiente paso es configurar el reloj del dispositivo. Esta tarea se realiza desde el modo privilegiado, no desde el modo configuración global.

Esta tarea se realiza con el siguiente comando:
Router(config)#exit
Router#clock set 19:24:00 Nov 18 2006
Router#_

Tenga en cuenta las siguientes particularidades:
  • Se configura en modo privilegiado.
  • El comando requiere que se incorporen todos los elementos: la hora debe incluir segundos y la fecha debe ser completa.
  • El mes se ingreso utilizando las 3 primeras letra del mes en inglés.
Para ver la hora
Para visualizar la hora configurada utilice:

Router#show clock
19:27:38.311 Arg Sat Nov 18 2006
Router#_

Más allá de lo hasta aquí dicho, es preciso tener en cuenta que muchos dispositivos Cisco carecen de un reloj interno que almacene esta información. Por lo tanto, si el dispositivo es reiniciado se pierde la configuración de la hora local. La configuración de huso horario se mantiene pues se almacena con el archivo de configuración.
Otro inconveniente que presenta este comando, es que al configurar individualmente dispositivo por dispositivo, se dificulta la comparación de archivos log (registro de sucesos) de diferentes dispositivos. Muchas veces la tarea de diagnóstico de fallos requiere que se comparen sucesos ocurridos en múltiples dispositivos. En este caso es muy importante y altamente recomendable, que todos los dispositivos sincronicen sus relojes con una única fuente de modo que el registro horario de todos esté sincronizado.
Sincronización del reloj de los dispositivos utilizando NTPPara el diagnótico de fallos de una red es casi imperativo que los relojes de los dispositivos (inclídos también por ejemplo el de los servidores y firewalls) estén sincronizados entre sí. Con este propósito Cisco IOS implementa Network Time Protocol. En el caso de los dispositivos Cisco, la implementación de este protocolo permite superar la limitación que impone la falta de un reloj interno.
NTP es un protocolo diseñado específicamente para sincronizar los relojes de los procesadores que operan en una red. NTP versión 3 es un protocolo estándar definido en RFC 1305 que utiliza para su operación el puerto 123 de UDP.
Un cliente NTP sincroniza su fecha y hora con un servidor NTP. El servidor NTP ha de ser una fuente confiable de información horario, como puede ser un time server de Internet. Hay varios servicios públicos y gratuitos de este tipo. Uno ampliamente utilizado es el servicio basado en el reloj atómico del National Institute of Standards and Technology (NIST).
Para aplicar NTP a la red corporativa se puede implementar una fuente horaria propia, o utilizar un servicio libre de Internet. Para implementar una fuente propia se debe adquirir una fuente de clock que puede obtener la información precisa a través de GPS u otro método.
Para configurar NTP en dispositivos Cisco IOS, ante todo tenga en cuenta:
  • NTP es un protocolo lento por lo que formar una asociación NTP toma tiempo. Si desea verificar que se esté realizando la asociación con el servidor NTP puede utilizar el comando debug ntp.
  • Si se utiliza un servidor NTP de Internet (como en el ejemplo de abajo), asegúrese de que se puede abrir una sesión UDP a través del puerto 123 (verifique el firewall).
Una vez que se ha asegurado estos puntos, siga el siguiente procedimiento:
  1. Seleccione un servidor NTP a utilizar.
    Por ejemplo, en el caso de Argentina: tock.nap.com.ar
  2. Obtenga la dirección IP del servidor.
    En el caso de nuestro ejemplo: 200.49.40.15
  3. Configure el servidor NTP en el dispositivo.
  4. Verifique la configuración utilizando los comandos show ntp status y show ntp associations.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ntp server 200.49.40.15
Router(config)#_


¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

16 de noviembre de 2006

Índice de artículos sobre tecnologías

Este índice de artículos está siempre disponible en
la columna de la derecha del weblog; en el área titulada "Enlaces Útiles".
Consúltelo siempre que le resulte necesario.

Este es un listado de los artículo publicados hasta el momento en el weblog, referidos a tips de configuración, tecnologías, etc.

Cisco IOS
Comandos
Diagnóstico de Fallos
Routing
Seguridad
Subredes, VLSM, CIDR
Switching
Tecnologías Ethernet
VoIP
Wireless