9 de febrero de 2007

10 causas frecuentes de baja performance de la red

Una red "lenta" o de baja performance es un verdadero problema, no sólo para el Administrador, sino también para la empresa: mal humor en los usuarios, pérdidas de productividad, sobrecarga de trabajo para el personal de soporte...

Como Administradores suele ocurrirnos que cuando esto ocurre (sobre todo si estamos en medio de un proyecto nuevo o una implementación) pensemos inmediatamente que se trata de un problema de alto nivel. Pero no siempre es así y muchas veces se puede obtener una mejora importante son sólo resolver (y si es posible prevenir) algunos de los elementos que suelen contribuir más frecuentemente a generar problemas o congestión en la red.

Por eso es importante que antes de apuntar a problemas de configuración o implementación más serios revisemos la la siguiente lista de problemas que afectan con mayor frecuencia la performance de la red:

  • Placas de red defectuosas.
    Un problema frecuente es la presencia de nodos con placas de red defectuosas. Cuando se detectan errores intermitentes, sobre todo cuando están relacionados con una estación de trabajo o servidor en particular, suelen deberse generalmente a este problema.
    En este caso el primer paso es verificar el LED de la placa de red. Un LED que está fijo en verde indica en general una placa de red con una conexión física en buen estado. Un LED que parpadea suele indicar que la conexión está activa y procesando tráfico de la red.
    Si el LED no se ilumina en verde, nos está indicando que la placa está deshabilitada en Windows o que no tiene una conexión activa con la red. Puede ser que el cable de conexión esté defectuoso, no sea el correcto, o está conectado a una boca de switch que está deshabilitada.
    Si la conexión a la red es correcta (se puede verificar fácilmente conectando en el mismo cable una terminal que sabemos funciona correctamente), y la placa está adecuadamente habilitada y configurada en Windows, el paso siguiente es reemplazar la placa de red.
  • Fallas en switches o routers.
    En algunos casos los problemas de la red pueden parecer inconsistentes. Por ejemplo, mientras no perdemos navegación web en la red, el servicio de correo electrónico "se pierde", o falla otro tipo de servicios como el de https. En otros casos, aún cuando mantenemos una buena conexión de red el acceso a Internet es imposible.
    Si tenemos conectividad local pero se ha perdido parcial o totalmente el acceso a recursos de Internet, el problema puede solucionarse frecuentemente reiniciando el equipo de acceso a Internet.
    Cuando los problemas son de conectividad local, o simplemente se trata de una red switcheada pero excesivamente lenta, el problema puede solucionarse reiniciando el switch de acceso.
    Si estos problemas son consistentes y frecuentes, es necesario revisar ante todo la calidad del suministro eléctrico, las fluctuaciones en el suministro de energía puede provocar errores e incluso daños en el hardware de routers y switches. Si no se trata de un problema de suministro eléctrico, la solución más cierta será el reemplazo del dispositivo defectuoso.
  • Conexión de dispositivos en "daisy chaining".
    Aún en redes corporativas importantes, el crecimiento de los requisitos de conectividad suele ser "causa de problemas": para dar lugar a una nueva conexión la solución más simple para el usuario suele ser conectar un hub o pequeño switch a una boca de red ya existente.
    Cuando esto ocurre, las tramas de datos deben recorrer cada vez mayor cantidad de saltos para alcanzar su destino. Cada salto que se agrega puede ser un problema potencial. No sólo porque agrega uno o varios puntos de fallos nuevos, sino también porque introduce mayor delay en la transacción. En muchos casos el agregado de uno o dos saltos en una comunicación es una diferencia notable en la performance.
    Hay que resistirse a "cascadear" o "encadenar" switches o hubs. Hay que reemplazar esta mala práctica por una adecuada planificación de los recursos en función del crecimiento. Y si el crecimiento explosivo produce este efecto no querido, reorganizar la red procurando consolidar lo que está disperso en varios dispositivos pequeños en un único dispositivo más potente y escalable.
  • Conflictos de NetBIOS.
    NetBIOS es aún un protocolo implementado en muchas redes para administrar algunos recursos. Sin embargo frecuentemente no trabaja adecuadamente provocando que algunos recursos como los archivos compartidos se vuelvan inaccesibles provocando congestión en la red y a veces cortes de servicio.
    Comportamientos extraños en los recursos de red se pueden producir cuando dos sistemas tienen el mismo nombre o cuando cumplen el mismo rol. Deshabilitar el servicio de resolución de nombres WINS/NetBT (cuando no es necesario) puede solucionar este problema.
    Si no es posible deshabilitar el servicio, se deberá entonces identificar cuáles son los dispositivos en conflicto para poder renombrar a uno de ellos.
  • Conflictos de IP.
    Los servicios de DHCP en general, implemetan sistemas que les permiten prevenir que 2 nodos utilicen la misma dirección IP (en el caso de Cisco IOS, antes de asignar una dirección IP verifica que no se encuentra activa en la red utilizando ping). Sin embargo, ocasionalmente puede ocurrir que 2 dispositivos tengan asignada la misma dirección IP, por ejemplo porque uno de ellos ha sido configurado estáticamente. Este conflicto provoca una caída de performance de la red.
    Para solucionar este problema ante todo es conveniente asegurarse de que no se haya conectado un servidor DHCP clandestinamente en la red. A continuación es necesario verificar la configuración de DHCP para asegurarse de que no haya superposición de rangos de direcciones IP con aquellas direcciones IP que se asignan estáticamente a servidores y demás dispositivos.
  • Exceso de aplicaciones que operan sobre la red.
    En muchos casos se corren aplicaciones que requieren recursos superiores a los que puede proporcionar la red y que no han sido adecuadamente previstos.
    Por ejemplo, es frecuente que en empresas que utilizan sistemas de información que realizan consultas frecuentes sobre bases de datos, no se haya previsto adecuadamente el modo en que opera la aplicación, y que las consultas a la base de datos generen congestión sobre la red en los horarios pico.
    Adicionalmente hay que tener presente que en la actualidad hay múltiples aplicaciones (desde los sistemas de VoIP hasta aplicaciones de audio y video sobre Internet) que generan tráfico de cadenas de paquetes sobre UDP que tienden a ocupar todo el ancho de banda disponible. Una combinación de estos elementos puede volver excesivamente lenta aún una red FastEthernet de 100Mbps.
    En estos casos la definición de políticas, y en algunos casos la implementación de filtros basados en hardware, son necesarios para preservar la performance de la red y reservar los recursos necesarios para las aplicaciones que son críticas para el desenvolvimiento de la empresa. Cuando se trabaja con sistemas de Telefonía IP es preciso asegurarse antes que se cuenta con los recursos necesarios para manejar el tráfico de voz y el de datos.
  • Infecciones con spyware.
    El spyware es ciertamente un problema creciente en aquellas redes que tienen algún tipo de acceso a los servicios de Intenet.
    La implementación de políticas de uso en la empresa, a la par que la implementación de herramientas anti-spyware son necesarios para reducir el impacto de este tipo de ataque sobre el desenvolvimiento de la red.
  • Infecciones de virus.
    No por conocido está suficiente previsto este riesgo.
    Hay múltiples posibilidades de infección con virus, sobre todo en redes que operan conectadas a Internet (lo que hoy es casi regla).
    En este punto la insistencia sobre el respecto estricto de las políticas de uso, y la permanente actualización de la infraestructura de seguridad de la red son elementos necesarios.
    Ante un problema de performance que irrumpe de un momento a otro, nunca está de más un escaneo de virus en las temrinales de la red. Una sola terminal infectada accidentalmente puede estar generando miles de correos electrónicos que congestinan todos nuestros recursos.
  • Insuficiente ancho de banda.
    A veces, ciertamente se trata sólo de que el comportamiento actual de la red requiere mayor ancho de banda. Sobre todo cuando se han revisado las aplicaciones de red en uso, y se acuerda en que es necesario mantenerlas en su uso actual, entonces es evidente que el ancho de banda actual es insuficiente.
    Dependiendo de la estructura y uso de la red, en este caso suele ser recomendable un rediseño que considere tanto los accesos WAN o a Internet, como la expansión de ancho de banda en distintos puntos del backbone y el reemplazo de hubs y switches genéricos. Muchas veces un rediseño con una mejor asignación de subredes y VLANs permite un mejor aprovechamiento de los recursos de ancho de banda existentes.
  • Errores de configuración de DNS.
    Los errores en la configuración de DNS pueden provocar numerosos herreres y una baja de performance generalizada.
    Cuando no hay un servidor DNS local, o cuando el servidor está ubicada a varios saltos dentro de la red, las estaciones de trabajo pueden experimentar un delay importante en el acceso a algunos recursos por la demora que se introduce en el proceso de resolución de nombres.
    Lo ideal es que el servidor DNS esté ubicado tan próximo como sea posible a los recursos de red.
    Es importante verificar periódicametne que las terminales cuentan con la configuración adecuada y que se servidor DNS primario es el que puede alcanzar con mayor facilidad y rapidez.

Estos son algunos puntos, quizás los más recurrentes. Si de tu experiencia se desprenden otras recomendaciones o ítems a tener encuenta, agregalos en forma de comentario en el presente post.

Muchas gracias.

Oscar Gerometta

2 de febrero de 2007

Cisco PIX - Cisco ASA

Una definición bastante arraigada en el ámbito del networking es que el PIX es el firewall de Cisco. Esto no es tan así desde hace unos años; en el mes de mayo de 2005 Cisco Systems introdujo una nueva línea de firewalls: ASA (Adaptive Security Appliance).

¿Cuáles son las diferencias entre un dispositivos Cisco PIX y un Cisco ASA?

La línea Cisco PIX
Un dispositivo Cisco PIX es un firewall de hardware totalmente dedicado a este tipo de funciones de seguridad.

Todas las versiones de Cisco PIX tienen un número de modelo 5xx. Uno de sus modelos más populares es el PIX 501, diseñado para oficinas hogareñas y pequeñas redes. Otro de los muy conocidos es el PIX 515, para redes de tamaño medio.

El sistema operativo de estos dispositivos es el PIX Operating System (PIX OS), el cual si bien es similar a Cisco IOS, es lo suficientemente diferente como para frustrar a todo operador que no esté interiorizado en su línea de comando. Para facilitar la tarea de configuración y administración, el PIX ofrece una interface gráfica denominada PIX Device Manager (PDM). Esta interfaz es una aplicación desarrollada en Java que se ejecuta desde un navegador.

Típicamente un PIX posee una interfaz outside que se suele conectar a la interfaz inside del router de acceso a Internet; y una interfaz inside que se suele conectar al switch LAN para enlazar con la red privada interna.

La línea Cisco ASA
La línea Cisco ASA es una nueva línea de dispositivos de Cisco Systems que conjuga un firewall de hardware con una implementación anti-malware.

En el caso de Cisco ASA los modelos existentes corresponden a la serie 55xx. Hay cuatro versiones enterprise: Firewall, IPS, Anti-x y VPNs; y una versión business para empresas medianas y pequeñas. Un total de 5 modelos.

Todos los ASA operan con el software ASA versión 7.2.2 con una interfaz más cercana al Cisco IOS que PIX OS.

Estos dispositivos incluyen servicios de prevención de intrusiones (IPS) y concentrado de VPNs. Es por esto que Cisco Systems indica que un ASA realizar por sí solo las tareas que hasta ahora requerían 3 dispositivos separados: un firewall PIX, un VPN Concentrator (como el VPN 3000) y un IPS como el Cisco IPS 4000.

Comparación PIX / ASA
Cisco PIX es y ha sido un excelente firewall, pero en los últimos años los requerimientos de prestaciones de seguridad de las redes ha variado sensiblemente.

Ya no resulta suficiente proteger a la red con un firewall en capacidad de realizar un filtrado de paquetes stateful. Han aparecido nuevos riesgos que incluyen virus, gusanos, phishing, ataques de capa de aplicación, la ejecución de aplicaciones no deseadas como mensajería instantánea, programas P2P, juegos, etc. El dispositivo que protege de este tipo o variedad de riesgos de seguridad es lo que denomina un Anti-X, o sea un dispositivo que brinda protección contra múltiples riesgos.

Un PIX no puede brindar este nivel de protección. Sin embargo muchas organizaciones buscan concentrar su implementación de seguridad en un único dispositivo, o lo que se suele denominar un dispositivo UTM (Unified Threat Management). O sea un dispositivo que brinde los servicios "todo en uno".

Cisco ASA es una respuesta a esta necesidad ya que ofrece protección a estos diferentes tipos de ataques. Los ASA soportan la posibilidad de inclusión de un módulo CSC-SSM (Content Security and Control Security Service Module). Este módulo es el que realiza las tareas de Anti-X constituyendo a los ASA en verdaderos dispositivos UTM. Sin el módulo CSC-SSM un ASA es muy semejantes en sus capacidades a un PIX, aunque siempre con mayor performance.

¿Cuáles son las razones por optar por un ASA en lugar de un PIX hoy?

En primer lugar, porque a similares funcionalidades del dispositivo el costo de un ASA tiende a ser menor que el de un PIX. Esto sin ignorar que en cuestiones de tecnología siempre la primer opción es por la tecnología más nueva y más rápida.

Pero cual es la razón más importante a mi juicio. Hoy no es suficiente descansar en un firewall para proteger la red corporativa de la variedad de potenciales riesgos de seguridad que existen. Se requiere una política que contemple los múltiples frentes existentes, y en la implementación de esa política siempre es útil un dispositivo que brinde servicios múltiples de modo integral y unificado. Pero con cuidado, un Cisco ASA no soluciona todo. En primer lugar se requieren políticas adecuadas claramente enunciadas e implementadas de un modo consistente, y esas políticas van mucho más allá de la configuración de un ASA.

Por el momento no hay anuncio de parte de Cisco Systems respecto de un End Of Sale de los Cisco PIX, pero no sería de extrañar que progresivamente la línea PIX comience a ser discontinuada. Para aquellos que implementan en la actualidad Cisco PIX se ha publicado una Guía de Migración.

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

26 de enero de 2007

Funcionalidades SPAN para monitoreo de tráfico a través de switches

En la tarea de administración de redes LAN es de fundamental importancia mantener un atento monitoreo del tráfico y del desempeño de los dispositivos de la infraestructura de red. En este contexto es frecuente que por diferentes motivos (detección de tráfico no deseado, relevamiento de actividad de ciertos protocolos, etc.) el Administrador requiera utilizar un analizador de protocolos (p.e. Ethereal) para monitorear, decodificar y comprender el tráfico de la red. Para esta tarea, luego de instalar el analizador de protocolos en una terminal, se ha de conectar la estación de monitoreo a un switch o hub a fin de capturar y revisar el tráfico que está atravesando la red.

Si la infraestructura de la red está compuesta de hubs, esta es una tarea relativamente sencilla. Sin embargo la mayoría de nuestras redes actuales utilizan switches. Y no es posible monitorear el tráfico de la red si la estación de monitoreo está sencillamente conectada a un puerto de un switch.

Cuando se monta una estación de monitoreo, en principio se busca capturar tanto tráfico como resulte posible para luego filtrarlo y de ese modo quedarse con lo que verdaderamente se está buscando. Sin embargo, si la estacion de monitoreo está conectada a una boca de un switch lo único que se puede capturar es el tráfico generado en la misma terminal o que tiene a esa terminal como destino, así como el tráfico de broadcast que esté circulando por ese segmento de red.

¿Porqué ocurre esto?
Pues simplemente porque el switch divide dominios de colisión. O lo que es lo mismo, cuando su tabla de direcciones MAC ya está poblada, establece circuitos punto a punto entre los puertos que desean entablar la comunicacion evitando inundar todos los puertos con el tráfico, como lo haría un hub. Los switches sólo inundan los puertos con tráfico de broadcast, o que tiene una dirección MAC destino desconocida. Por este motivo, nuestra estación de monitoreo al estar conectada a un switch ya no puede capturar todo el tráfico que circula por él sino solamente el que tiene su dirección MAC como origen o destino, o tráfico de broadcast.

Lo que necesitamos en nuestra tarea es que el switch envíe una copia de toda trama que circule por él al puerto en el que hemos conectado nuestra estación de monitoreo. Para esto podemos recurrir a un feature de los switches Cisco llamado Switched Port ANalyzer (SPAN) o una variante, Remote SPAN (RSPAN). Se trata de una funcionalidad semejante a la que en otros fabricantes se conoce como "port mirroring".

¿Cómo trabaja SPAN?
SPAN permite tomar el tráfico que atraviesa por un puerto, grupo de puertos o VLAN completa de un switch y lo copia en el puerto de destino, que es el puerto en el que debemos conectar nuestra estación de monitoreo. Adicionalmente, al configurar esta funcionalidad se especifica no sólo los puertos de origen y destino, sino también si se desea copiar el tráfico que tiene ese puerto como origen, destino o ambos.

Por su lado, RSPAN permite que el tráfico generado en múltiples switches distribuidos en la red pueda ser reenviado al puerto al que hemos conectado nuestra estación de monitoreo. Así, por ejemplo, si una VLAN cualquiera se encuentra configurada en múltiples switches de la red, RSPAN permite que todo el tráfico que tiene como destino puertos de la VLAN en cuestión, de cualquiera de los switches involucrados sea copiado a nuestro puerto de trabajo

¿Cómo se configura SPAN?
La configuración es simple. Sin embargo tiene sus complejidades cuando se trata de protocolos como STP,VTP y CDP, por lo que es sumamente aconsejable revisar la documentación oficial en el sitio de Cisco Systems.

Veamos un ejemplo de configuración. Suponemos que se trata de un switch de 24 puertos. Conectamos nuestra estación de monitoreo al puerto Fastethernet 0/24 y deseamos monitorear todo el tráfico que pasa a través de los restantes 23 puertos del dispositivo. Por lo tanto debemos indicar al dispositivo que envíe copia al puerto F0/24 de cada trama que ingrese o salga a través de los puertos F0/1 a 0/23.

Switch(config)#monitor session 1 source interface fastethernet 0/1 - 23 both
Switch(config)#monitor session 1 destination interface fastethernet 0/24

Es preciso tener presente que este tipo de operaciones son un requerimiento intensivo para el dispositivo, y que consecuentemente pueden afectar sensiblemente la performance del mismo. Asegúrese de deshabilitar esta función cuando haya terminado la tarea utilizando el comando

Switch(config)#no monitor session 1

Para verificar si se está ejecutando alguna sesión de monitoreo en el dispositivo, utilice el comando:

Switch#show monitor

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

22 de enero de 2007

Control del tráfico no deseado utilizando CAR

Muchas de nuestras redes se encuentran hoy "enfermas" de tráfico innecesario, tráfico que no responde a los objetivos de negocio de la empresa y que muchas veces afecta de modo directo la disponibilidad de recursos para la administración del tráfico crítico de la red. Este tráfico "no deseado" puede ser administrado utilizando CAR.

Una situación habitual es la que se provoca cuando un usuario se encuentra "bajando" información de un sitio web (un archivo de gran tramaño, video, música, etc.). Este tráfico puede afectar seriamente el desenvolvimiento normal de la red, o lo que es peor, hacer inaccesible en algún momento los servidores de producción.

CAR (Committed Access Rate) es un método que permite adminsitrar el tráfico no deseado de modo de asegurarnos que no afecte el tráfico propio de la operación de la red. Hay que tener en cuenta algunas consideraciones previas:

  • CAR solamente afecta el trafico IP. No opera sobre el tráfico no-IP.
  • Para utilizar CAR es necesario habilitar CEF en el router.
  • Esencialmente, CAR controla el ancho de banda que puede ocupar cierta tipo de tráfico, que es definido a través de una ACL.
  • CAR puede referirse tanto al tráfico que ingresa, como al que sale a través de la interfaz en la que se aplica CAR.

La implementación de CAR se realiza en 2 pasos sencillos:

  • Creación de una ACL para definir el tráfico que se desea limitar.
  • Utilizar el comando rate-limit, referenciando la ACL anterior en la interfaz más cercana posible al origen del tráfico, para indicar el ancho de banda que se asignará a este tráfico.

Para ver cómo opera esta solución, revisaremos un ejemplo:

Supongamos una red corporativa que une una casa central con sucursales. Una de esas sucursales (que tiene asignada la subred 10.10.20/24) está conectada utilizando una línea punto a punto de 128 Kb, lo que se ha mostrado eficiente para permitir trabajar con la aplicación desarrollada para la operación de la empresa. Ahora bien, se le acaba de dar acceso a la navegación web de Internet a esta sucursal a través de este enlace de 128 Kb, lo que ha afectado notoriamente la performace de la aplicación de trabajo que se encontraba corriendo. El acceso a Internet se da a través del enlace que posee la Casa Central.

Aún cuando la navegación de Internet es una herramienta conveniente en la sucursal en cuestión, está afectando negativamente la performace de la aplicación de producción.

Para controlar esta situación implementaremos CAR en el router de la casa central. El primer paso s definir el tráfico que se desea limitar n el router de casa central, utlizando una ACL. Siguiendo nuestro ejemplo:

Router(config)#access-list 110 permit tcp any eq www 10.10.20.0 0.0.0.255

En este caso estamos definiendo un filtro que seleccionará todo el tráfico originado en cualquier web server de Internet que tenga como destino un nodo de la subred 10.10.20/24 (la sucursal en cuestión).

El próximo paso es implementar el comando rate-limit en la interfaz que conecta a la sucursal:

Router(config)#interface serial0/0
Router(config)#rate-limit output access-group 110 50000 10000 20000 conform-action transmit exceed-action drop

Este comando aplica un límite de uso de ancho de banda en esta interfaz, en función de la selección de tráfico que realiza la lista de acceso 110. Está aplicada sobre el tráfico saliente a través de la interfaz (outup) porque lo estamos aplicando en el router de casa central, de modo de limitar el tráfico no deseado lo más cerca posible de su origen y evitar que afecte el uso del enlace WAN en cuestión.

Las cifras 50000, 10000 y 20000 establecen los límites (en bits por segundo) que se aplicarán al tráfico seleccionado por la ACL. La primera cifra (50000) indica la tasa de transmisión que se asigna para este tráfico. La segunda cifra (10000), el tamaño reservado para una ráfaga de datos. La tercera (20000) indica el tamaño máximo permitido para una ráfaga. En la medida en que el tráfico se ajusta a estos parámetros de requerimiento de ancho de banda disponible, será transmitido (conform-actio transmit).

Si el tráficoi excediera estos parámetros de ancho de banda, será descartado por el router (exceed-action drop).

Sintetizando. La configuración propuesta sobre la interfaz que conecta hacia la sucursal en cuestión hará que el tráfico web que está causando dificultades quede acotado y no pueda consumir más de 50 kbps de los 128 kbps del enlace.

Es preciso tener en cuenta que CAR limita todo y sólo aquel tráfico que se indica en la ACL.

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

12 de enero de 2007

Template de configuración básica de un firewall Cisco PIX

Como ya hemos visto en el caso de switches Catalyst, el uso de "templates" de Excel nos permite automatizar procesos de configuración. Con este propósito les presento este nuevo template Excel, en este caso para relizar la configuración básica de un nuevo firewall Cisco PIX 501 versión 6.3.

¿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 hoja 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:

  • Configura un hostname.
  • Genera una clave de acceso al dispositivo.
  • Crea una clave de acceso al modo enable.
  • Habilita el web server del PIX para posibilitar la administración remota utilizando el PDM (PIX Device Manager).
  • Configura los parámetros necesarios para sincronizar el reloj del dispositivo utilizando NTP.
  • Configura las direcciones IP de las interfaces inside y outside, y habilita ambas interfaces.
  • Asigna un default gateway para el PIX.
  • Configura PAT (Port Address Translation) de modo que todos los dispositivos de la red interna (inside) puedan acceder a la red externa (outside).
  • Genera una ACL en el firewall de modo que los usuarios de la LAN (inside) solo pueden acceder a http y ftp en la red externa.
  • Graba la configuración en la NVRAM.

Cómo se utiliza

  • Baje el template a su terminal.
  • Abra el archivo Microsoft Excel y permita la ejecución de macros.
  • Diríjase a la hoja "Variables".
  • Complete la información específica que corresponde al dispositivo que desea configurar en la columna blanca titulada "Definición del usuario".
  • Verifique que la información ingresada sea la correcta.
  • A la derecha de la tabla hay una casilla en color verde con el título "Nombre de Referencia". Ingrese allí el nombre que desea que Excel le asigne a la hoja que se creará a continuación.
  • Seleccione el botón "Reemplazar" que está a la derecha de la tabla que ha completado.
  • Se generará una nueva hoja en el archivo con los comandos necesarios para obtener la configuración deseada.
  • Ingrese por consola a la línea de comando del dispositivo que desea configurar y diríjase al modo de configuración.
  • 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 sólo realiza una configuración básica y no aplica features avanzados de seguridad.

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