Como limitar ancho de banda en interfaces SVI

¿Sabes como limitar ancho de banda a ciertos usuarios? Es común que nuestra red por momentos se presente lentitud, debido a que algunos usuarios consumen altos anchos de banda por ejemplo con videos, transferencia de archivos, entre otros, es en estos casos que debe limitar ancho de banda.

Debido a lo anterior es necesario que sepamos como limitar ancho de banda, asignando un  ancho de banda máximo que pueden utilizar los usuarios de nuestra red, de esta forma cuando el uso de la red del usuario excede el ancho de banda asignado, simplemente se descartarán los paquetes; lo que ayudará a que no te consuman ancho de banda de servicios de otros usuarios. De esta forma podrás limitar ancho de banda de los usuarios y tenerlos bajo control.

Topología. Conexión de usuarios donde se puede limitar ancho de banda a Vlans

Acerca de la topología

En la topología vemos que tenemos un router que es el que sirve de Gateway para los usuarios, el cual enruta el tráfico hacia la red o hacia internet. El router utilizado en el ejemplo es marca Cisco de la serie 1941 con una tarjeta HWIC GigabitEthernet (4 puertos GigabitEthernet capa2).

Ejemplo

Para este ejemplo tenemos dos switches en los cuales se encuentran conectados cuatro usuarios asignados a las vlan 10 y 20 respectivamente. Lo que haremos es limitar el ancho de banda para que los usuarios de la vlan 10 solo puedan utilizar un ancho de banda máximo de 128Kb y los de la vlan 20 un máximo de 5 Mb (Un poco injusto verdad, pero así es el ejemplo xD).

Configuraciones

Veamos a continuación las configuraciones que debemos aplicar en las Interfaces Virutales SVI (Switch Virtual Interface) de la vlan 10 y 20.

Recuerda que las configuraciones deben ser aplicadas en modo configuración global:

Router> enable
Router #configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router (config)#

Veamos las configuraciones para limitar ancho de banda

! limtar ancho de banda a 128Kbps class-map match-all SERVICES_128K match any ! limtar ancho de banda a 5Mbps class-map match-all SERVICES_5M match any ! policy-map SERVICIOS_128K class SERVICES_128K police cir 128000 bc 192000 be 19 302000 conform-action transmit  exceed-action drop ! policy-map SERVICIOS_5M class SERVICES_5M police cir 5120000 bc 960000 be 1920000 conform-action transmit   exceed-action drop ! aplicar policy para limitar ancho de banda en SVI interface Vlan10 description USUARIOS_VLAN10 ip address 192.168.1.1 255.255.255.0 service-policy input SERVICIOS_128K service-policy output SERVICIOS_128K ! aplicar policy para limitar ancho de banda en SVI interface Vlan20 description USUARIOS_VLAN20 ip address 192.168.2.1 255.255.255.0 service-policy input SERVICIOS_5M service-policy output SERVICIOS_5M !

Comentarios de configuraciones:

!
class-map match-all SERVICES_128K	Creamos Clas Map con nombre SERVICES_128K
match any	Se aplicará a todo el tráfico
!
class-map match-all SERVICES_5M	Creamos Class Map con nombre SERVICES_5M
match any	Se aplicará a todo el tráfico
!
policy-map SERVICIOS_128K	Creamos politica con nombre SERVICIOS_128K
class SERVICES_128K	Aplicaremos política a toda la interface
police cir 128000 bc 192000 be 192000 conform-action transmit exceed-action drop	Indicamos que cuando exceda los 128Kb descarte los paquetes
!
policy-map SERVICIOS_5M	Creamos politica con nombre SERVICIOS_5M
class SERVICES_5M	Aplicaremos política a toda la interface
police cir 5120000 bc 960000 be 1920000 conform-action transmit exceed-action drop	Indicamos que cuando exceda los 5M descarte paquetes
!
interface Vlan10	Ingresamos al modo configuración de interface SVI 10
description USUARIOS_VLAN10	Colocamos descripción a la interface
ip address 192.168.1.1 255.255.255.0	Colocamos dirección IPv4 del gateway de la vlan 10
service-policy input SERVICIOS_128K	Aplicamos politica de servicio para tráfico de entrada haciendo referencia a la policy-map SERVICIOS_128K
service-policy output SERVICIOS_128K	Aplicamos politica de servicio para tráfico de salida haciendo referencia a la policy-map SERVICIOS_128K
!
interface Vlan20	Ingresamos al modo configuración de interface SVI 20
description USUARIOS_VLAN20	Colocamos descripción a la interface
ip address 192.168.2.1 255.255.255.0	Colocamos dirección gateway de vlan 20
service-policy input SERVICIOS_5M	Aplicamos politica de servicio para tráfico de entrada haciendo referencia a la policy-map SERVICIOS_5M
service-policy output SERVICIOS_5M	Aplicamos politica de servicio para tráfico de salida haciendo referencia a la policy-map SERVICIOS_5M

El corazón de las configuraciones para limitar ancho de banda la tenemos en la política donde:

cir = velocidad máxima en bits ejemplo: 5Mb * 1000 Kb *1024 bits = 5120000
bc = (velocidad máxima / 8bits)*1.5 = 960000
be = bc*2= 1920000
Police cir 5120000 bc 960000 be 1920000 conform-action transmit exceed-action drop

A continuación les presento mucho más ejemplos:

SERVICIOS A 256K
class-map match-all SERVICES_256K
match any
!
Policy-map SERVICIOS_256K
class SERVICES_256K
police cir 256000 bc 192000 be 192000 conform-action transmit exceed-action drop
————————————————————————————-

SERVICIOS A 384K
class-map match-all SERVICES_384K
match any
!
Policy-map SERVICIOS_384K
class SERVICES_384K
police cir 384000 bc 72000 be 1440000 conform-action transmit exceed-action drop
————————————————————————————-

SERVICIOS A 512K


class-map match-all SERVICES_512K
match any
!
Policy-map SERVICIOS_512K
class SERVICES_512K
police cir 512000 bc 96000 be 192000 conform-action transmit exceed-action drop
————————————————————————————-

SERVICIOS A 1 MB
class-map match-all SERVICES_1M
match any
!
policy-map SERVICIOS_1M
CLASS SERVICES_1M
police cir 1024000 bc 192000 be 384000 conform-action transmit exceed-action drop
————————————————————————————-

SERVICIOS A 2M

class-map match-all SERVICES_2M
match any
!
Policy-map SERVICIOS_2M
class SERVICES_2M
police cir 2048000 bc 384000 be 768000 conform-action transmit exceed-action drop
————————————————————————————-

SERVICIOS A 3M

class-map match-all SERVICES_3M
match any
!
Policy-map SERVICIOS_3M
class SERVICES_3M
police cir 3072000 bc 576000 be 1152000 conform-action transmit exceed-action drop

————————————————————————————-

SERVICIOS A 5 MB

class-map match-all SERVICES_5M
match any
!
policy-map SERVICIOS_5M
class SERVICES_5M
police cir 5120000 bc 960000 be 1920000 conform-action transmit exceed-action drop

Fuente: http://tututo.net/

Cisco presenta 2 nuevos tracks de certificación

Por Oscar Gerometta

Cisco Systems acaba de presentar dos nuevos tracks de certificación:

• Cloud.
  Con las certificaciones CCNA Cloud y CCNP Cloud.
• Industrial
  Por ahora con solamente la certificación CCNA Industrial.

CCNA Cloud

Se trata de una certificación orientada a ingenieros y administradores de de sistemas cloud, así como ingenieros de redes que desean desarrollar y validar conocimientos y habilidades requeridas por estas nuevas tecnologías de certificación. Es la certificación de acceso al mundo de las soluciones cloud propuestas por Cisco.

• Pre-requisitos: No tiene
• Exámenes requeridos:
       210-451 CLDFND - Understanding Cisco Cloud Fundamentals
       210-455 CLDADM - Introducing Cisco Cloud Administration
                                       Este examen estará disponible a partir del mes de julio.
• Validez: 3 años (ver aparte los criterios de re-certificación).

CCNP Cloud

En este nivel de certificación se consideran tanto redes públicas, privadas e híbridas como soluciones intercloud. Es una certificación basada en entrenamientos sobre laboratorios orientados a ingenieros, diseñadores, administradores y arquitectos de data centers.

• Pre-requisitos: CCNA Cloud o una certificación CCIE.
• Exámenes requeridos:
       300-504 CLDINF - Implementing and Troubleshooting the Cisco
                                     Cloud Infrastructure.
       300-505 CLDDES - Designing the Cisco Cloud.
       300-506 CLDAUT - Automating the Cisco Enterprise Cloud.
       300-507 CLDDACI - Building the Cisco Cloud with Application
                                        Centric Infrastructure.
       Estos exámenes estarán disponibles a partir del mes de agosto.
• Validez: 3 años (ver aparte los criterios de re-certificación).

CCNA Industrial

Orientado a profesionales de las áreas de operaciones, control y redes IT que trabajan en plantas industriales y requieren conocimientos y habilidades necesarios para implementar y gestionar las redes de estas plantas en las cuales se da la convergencia de IT con redes industriales. Se centra en los estándares más comunes utilizados en la industria, incorporando las mejores prácticas de conectividad en esas redes.

• Pre-requisitos:
        CCENT
        o Cisco Industrial Networking Specialist.
• Examen requerido:
        200-601 IMINS2 - Managing Industrial Networking for Manufacturing
                                      with Cisco Technologies
• Validez: 3 años (ver aparte los criterios de re-certificación).

De esta manera, Cisco ofrece ahora 9 rutas de certificación, con la incorporación de Cloud e Industrial, mientras se retira Video y Voice.

Por el momento no hay anuncio de una posible certificación CCNP Industrial y nuevos CCIEs.

Para verificar pre-requisitos y requisitos de recertificación, puede revisar la presentación en nuestro repositorio de SlideShare:

El sistema de certificaciones de Cisco Systems from Educática

Enlaces de referencia:

• Página de CCNA Cloud en Cisco Learning Network (requiere CCO).
• Información de CCNA Cloud.
• Información de CCNP Cloud.
• Página de CCNA Industrial en Cisco Learning Network (requiere CCO).
• Información de CCNA Industrial.

Diagnóstico de interfaces en Cisco IOS

Por Oscar Gerometa

Hace ya algún tiempo que me solicitaron un esquema de diagnóstico del estado de las interfaces en dispositivos Cisco IOS.

Si bien el proceso de diagnóstico de una situación o dispositivo no es fruto exclusivamente de un procedimiento pre-definido sino que depende en mucho de la experiencia y conocimientos de quien lo realiza, creo que es posible revisar el conjunto de herramientas que ofrece Cisco IOS para el diagnóstico de interfaces de routers de un modo relativamente ordenado.

Lo que elaboro a continuación es un esquema personal, que pretende ordenar un proceso de diagnóstico genérico del estado de interfaces de un router Cisco que utiliza Cisco IOS 15.4 y al que se está accediendo remotamente. En cada comando he agregado el enlace para revisar el comando en la command guide para que quienes quieran profundizar en él puedan hacerlo en la fuente misma.

show ip interface brief

A mi modo de ver, el primer comando de diagnóstico a ejecutar cuando se está accediendo remotamente a un equipo es show ip interface brief.

Este comando nos permite requerir al sistema operativo una tabla sintética que nos permite visualizar de modo rápido y sencilo el estado de cada una de las interfaces que tiene configuración IP:

En un dispositivo operativo:

• La columna IP-Address nos muestra la dirección IP configurada en cada interfaz.
• La columna OK? debe indicarnos YES. La leyenda NO indica que se ha asignado a la interfaz una dirección IP inválida.
• La columna Method indica el método a través del cual se ha obtenido la configuración IP de la interfaz: NVRAM refiere al archivo de configuración almacenado en la NVRAM, manual indica que ha sido cambiada la dirección IP utilizando configuración por CLI, DHCP refiere que la interfaz está configurada como cliente DHCP y ha obtenido dirección por ese método.
• La columna Status muestra el estado de las interfaces (up | down | administratively down). Para estar operativa la interfaz debiera aparecer como up.
• La columna Protocol indica que la interfaz se encuentra operativa a todo nivel.

En condiciones de operación, el comando debiera mostrarnos up/up todas las interfaces en uso, y como administratively down las interfaces que no se encuentran en uso.

Enlace de referencia: aquí.

Si una interfaz aparece como down/down, es posible que tenga inconvenientes a nivel de capa física. Es por esto que para diagnosticar adecuadamente necesitamos revisar capa física.

show controllers

Este comando nos permite revisar la información referente a hardware y software de la interfaz, y consecuentemente el estado físico de la misma.

La información que brinda este comando es variable de acuerdo al tipo de interfaz de la que se trate (Ethernet, FastEthernet, GigabitEthernet, Serial, etc.)

Es un comando con abundante información que generalmente es requerido en solicitudes de soporte a Cisco TAC. Sin embargo, nos brinda información útil también a nosotros, p.e., en interfaces seriales permite verificar si hay cable conectado y si el mismo es DCE o DTE, el clockrate que utiliza, el estado de la interfaz, etc.

Enlace de referencia: aquí.

show interfaces

En interfaces que se encuentran operativas permite visualizar el estado y estadísticas de operación de las interfaces.

Este comando permite verificar: estado de la interfaz, tipo de hardware que utiliza, dirección MAC, dirección IP y máscara de subred, parámetros de operación (MTU, BW, etc.), protocolo de encapsulación, y estadísticas de tráfico tanto entrante como saliente. El resultado específico y los parámetros que se muestran dependen de la configuración y tipo de interfaz.

Este comando lo utilizamos específicamente para, además de verificar el estado de la interfaz, verificar la actividad de la misma utilizando los contadores de paquetes y bytes que nos permiten corroborar la actividad que hay sobre la misma y la tasa y tipo de errores.

Enlace de referencia: aquí.

show interfaces accounting

Este no es más que un subcomando del comando anterior.
 
Si lo que necesitamos es verificar actividad de tráfico entrante y saliente a través de las interfaces, este es un comando que muestra de modo sintético la actividad de tráfico entrante y saliente a través de cada interfaz del dispositivo.

Las interfaces que no se encuentran operativas muestran la leyenda is disabled.

show ip interfaces

Este comando nos permite verificar, además del estado y dirección IP de la interfaz, la configuración y operación de la misma: proxy ARP, ICMP, presencia o no de ACLs asociadas, implementación de políticas, o de CEF, etc. 

Enlace de referencia: aquí.

Sintetizando:

• Revisar el estado de las interfaces utilizando show ip interface brief.
• Si alguna interfaz está down / down, verificar la operación a nivel de capa física utilizando show controllers.
• Si una interfaz está up / down, verificar la operación la operación a nivel de capa de enlace y capa de red utilizando show interfaces.
• Si las interfaces se encuentran up / up, verificar el flujo de tráfico y la tasa de errores utilizando show interfaces o show interfaces accounting.
• Ante dificultades en la operación de la interfaz, verificar el modo de operación y la configuración utilizando show ip interface.

En términos generales, verifique el estado de las interfaces utilizando show ip interface brief según lo que indiquen las columnas status y protocol:

• administratively down / down - la interfaz no ha sido habilitada administrativamente. Requiere no shutdown para ser operativa.
• down / down - posible problema a nivel de la capa física. Inicie verificando la interfaz utilizando show controllers.
• up / down - Posible problema a nivel de capa de enlace de datos o de red puede comenzar utilizando show interfaces.
• up / up - La interfaz se encuentra operativa, verifique la existencia de tráfico a través de la interfaz utilizando show interfaces o show interfaces accounting.
• Si la interfaz está operativa y persisten los problemas de comunicación, verifique la operación de la interfaz utilizando show ip interface.

Vea el video de este post en el canal de YouTube de LibrosNetworking


 

Fuente: http://librosnetworking.blogspot.com/

Protocolos de redundancia: GLBP

Gateway Load Balancing Protocol (GLPB) es una solución propietaria de Cisco para la redundancia y balanceo de carga en una red IP.
 
GLBP permite la selección automática y recuperación simultánea de los fallas de router de primer salto.

GLBP proporciona equilibrio de carga a través de múltiples puertas de enlace (Router) mediante una única dirección IP virtual y múltiples direcciones MAC virtuales. 

Cada host está configurado con la misma dirección IP virtual, y todos los routers en el grupo de router virtual participan en el envío de paquetes. 

Como funciona GLBP

GLBP funciona haciendo uso de una sola dirección IP virtual, que se configura como la puerta de enlace predeterminada en los hosts.
 
Los diferentes routers que asumen el papel de reenvío utilizan diferentes direcciones MAC virtuales para la misma dirección IP virtual que se utiliza para enviar paquetes.
 
A diferencia de HSRP y VRRP , GLBP no utiliza una única dirección MAC virtual para todo el grupo. En cambio, el AVG asigna diferentes direcciones MAC virtuales para cada uno de los routers físicos del grupo.

Hay dos tipos de routers en una utilización grupo GLBP en redundancia y el equilibrio de carga:
 
Active Virtual Gateway (AVG):
Dentro de un grupo GLBP, un router virtual (puerta de enlace) es elegido como el Active Virtual Gateway (AVG), y es el responsable de la operación del protocolo. 

Este router AVG tiene el valor de prioridad o la dirección IP más alta en el grupo, responde a todas las solicitudes ARP para direcciones MAC que se envían a la dirección IP del router virtual.
 
Active Virtual Forwarder (AVF)
Un router dentro de un grupo GLBP es elegido como Active Virtual Forwarder (AVF). Este AVF es responsable de reenviar paquetes que son enviados a la dirección mac asignada por el router AVG. 

Pueden existir múltiples AVF para cada grupo GLBP.
 
Así, cuando un cliente necesita enviar paquetes al  AVG con la dirección IP configurada, solicita la dirección MAC enviando una solicitud ARP (protocolo de resolución de direcciones) en la subred.
 
El AVG responderá a estas peticiones ARP con la dirección MAC virtual de cada AVF, basado en un algoritmo de reparto de carga configurado.

La siguiente imagen muestra una topología típica con GLBP.

La siguiente imagen muestra una topología GLBP con IPv6.

Tipos de mecanismos de balanceo de carga en GLBP

Existen tres mecanismos de equilibrio de carga que se utiliza con GLBP. 

Estos incluyen:

1. Round-robin: Es el método por defecto. Cada AVF es elegido secuencialmente en la resolución de direcciones respuestas para la dirección IP virtual. A cada solicitud ARP se le responde con la dirección MAC del siguiente AVF y al llegar al final se comienza desde el inicio.
2. Host-dependent: Basado en la dirección MAC de un host, el mismo AVF se utiliza siempre para un host en particular.
3. Weighted: Sobre la base de la cuota depende del peso del usuario entre los routers.

Estados del balanceo de carga en GLBP

Existen diferentes estados de AVG y AVF en un grupo GLBP.
 
El AVG pueden tener seis estados. Estos incluyen:

1. Disabled: significa que no hay dirección IP virtual configurada.
2. Initial: significa que la dirección IP virtual configurada pero la configuración de puerta de enlace virtual esta incompleta.
3. Listen: Se reciben paquetes Hello y el equipo pasará a "Speak" estado si no escucha mensajes de un AVG disponible.
4. Speak: Significa que el equipo está tratando de convertirse en el AVG y está informando a los demás equipos.
5. Standby: Listo para convertirse en el próximo AVG.
6. Active: significa que el equipo actual es el AVG y es responsable de responder a las solicitudes ARP para la dirección IP virtual.

 El AVF puede tener cuatro estados. Estos incluyen:

1. Disabled: significa que no hay dirección MAC virtual asignada.
2. Initial: La dirección MAC virtual está bien, pero la configuración de AVF está incompleta.
3. Listen: El AVF está recibiendo Hello y está listo para pasar al estado "activo" como AVF (Existe un AVG).
4. Active: El equipo actual es AVF y es responsable de reenviar paquetes enviados a la dirección MAC virtual que le ha sido asignada. 

Beneficios de GLBP

• Balanceo de carga. Puede configurar GLBP de tal manera que el tráfico de clientes de LAN puede ser compartido por múltiples routers, compartiendo así la carga de tráfico de manera más equitativa entre los routers disponibles.
• Múltiples routers virtuales. GLBP soporta hasta 1.024 routers virtuales (grupos GLBP) en cada interfaz física de un router, y hasta 4 forwarders virtuales por grupo.
• Preemtion. El esquema de redundancia de GLBP le permite definit un AVG con una prioridad configurable predefinida.
• Autenticación. Puede utilizar un esquema simple de autenticación de contraseña de texto entre los miembros del grupo GLBP. Un router dentro de un grupo GLBP con una llave de autenticación diferente a otros routers será ignorada por otros miembros del grupo.

Puntos para recordar sobre GLBP:

1.  Protocolo propietario de Cisco (2005)
2.  Usa el puerto 3222 UDP
3.  Envia mensajes Hello a la dirección Multicast 224.0.0.102
4.  Prioridad por defecto 100
5.  Peso (weight) por defecto 100
6.  Preempt deshabilitado por defecto
7.  Decremento de peso (weight) usando track = 10
8.  Algoritmos de blanceo de carga
1.     Round Robin
2.     Weighted
3.     Host Dependent
9.  Algoritmo de balanceo de carga por defecto: Round robin.
10.  Frecuencia de Hello – 3 sec
11.  Temporizador Hold – 10 sec
12.  No hace seguimiento (track) por defecto
13.  En GLBP configuramos track externo.
14.  Soporta autenticación con MD5 & texto plano

Fuentes de este artículo:

• http://orbit-computer-solutions.com/CCNA%3A-Redundancy-Protocol---Understanding-GLBP.php
• http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_glbp.html#wp1043431
• http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-services/product_data_sheet0900aecd803a546c.html
• http://blog.eincop.com/2014/12/Redundancy-and-Load-Balancing-Protocol-GLBP.html

Protocolos de redundancia: VRRP

Por Alberto Castillo 

En la entrada anterior, “Protocolos de redundancia: HSRP”, vimos el protocolo propietario de Cisco HSRP. Si los equipos que tenemos en nuestra red son todos Cisco, no tendremos mayor problema en utilizar este protocolo… ¿Pero que hacemos si tenemos equipos de diferentes fabricantes?

En ese caso la solución pasa por utilizar un protocolo no propietario y la alternativa estándar al HSRP sería el protocolo VRRP.

El funcionamiento de VRRP es similar al de HSRP. VRRP también utiliza una IP y MAC virtual por grupo. En base a la prioridad configurada en cada Router del grupo, VRRP elegirá un Router “master”, que es el que hará uso de la IP virtual y el resto de Routers del grupo permanecerán en estado “backup”, hasta que ocurra un fallo en la red que provoque la elección de un nuevo Router “master”… VRRP envía paquetes a la dirección multicast 224.0.0.18, de forma que los Routers “Backup” puedan detectar si ha habido un fallo en la red que haga necesaria la elección de un nuevo Router “master”.

A continuación veremos un ejemplo simple de como configurariamos VRRP en un Router Cisco y en un Router Juniper.

En el ejemplo primero vamos a configurar un Router Cisco, al que le configuraremos una prioridad mas alta para que actúe de “master”. Como podemos observar la config es similar a HSRP, donde definimos los siguientes parámetros:

• IP Virtual: 172.16.1.254
• Prioridad: 110
• Track: que determinará el decremento en la prioridad (Por defecto es 10 por lo que no aparece en la config).

Exactamente igual que como hicimos con HSRP, la condición que determinará el decremento, la hemos especificado unas lineas mas arriba en el modo de configuración global, donde hemos definido un track hacia la ruta 8.8.8.8. En caso de que la IP definida en el track se vuelva inalcanzable, se producirá un decremento de 10 en la prioridad.

...
!
track 1 ip route 8.8.8.8 255.255.255.255 reachability
!
!
interface GigabitEthernet0/0
ip address 172.16.1.2 255.255.255.0
duplex auto
speed auto
media-type rj45
vrrp 1 ip 172.16.1.254
vrrp 1 priority 110
vrrp 1 track 1

Ahora configuramos el Router Juniper que actuará de “backup”.Al igual que con el Cisco, definimos los siguientes parámetros:

• IP Virtual: 172.16.1.254
• Prioridad: 105 (como va a ser “backup”, será menor que la del “master”)
• Track: En este caso no sería necesario configurar el track, sin embargo os lo pongo para que veáis como se configuraría.

...
set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 vrrp-group 1 virtual-address 172.16.1.254
set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 vrrp-group 1 priority 105
set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 vrrp-group 1 track route 8.8.8.8/32 routing-instance default priority-cost 10

Como hemos explicado VRRP envia paquetes multicast , pero a diferenca de en HSRP estos paquetes solo los envia el Router que actúa de “master”.

En la siguiente captura vemos uno de esos paquetes:

Si el Router “master” pierde el track que hemos definido, se aplicará el decremento en la prioridad y el Router “backup” pasará a ser el “master”.

En la siguiente captura vemos como en el Router Cisco, el track aparece down y se ha decrementado su prioridad a 100, por lo que su estado actual es “backup”:

Por otro lado vemos como ahora el estado del Router Juniper es “master”:

Y si realizamos una captura de paquetes, vemos como ahora es el Router Juniper el que envía los paquetes multicast:

Fuente: Échale un vistazo…

Protocolos de redundancia: HSRP

Por Alberto Castillo

https://echaleunvistazo.wordpress.com/2015/02/13/protocolos-de-redundancia-hsrp/

HSRP (Hot Stand-by Redundancy Protocol) es un protocolo de capa 3, propietario de Cisco, que proporciona redundancia a nivel de gateway.

HSRP utiliza una IP y MAC virtual, que es la misma para todos los routers de un mismo grupo. En cada grupo hay un router en estado “active” que es el que hace uso de esa IP virtual y el resto de routers del grupo permanecen en estado “standby”. Para determinar cual es el router “active” y cual o cuales estarán en “stanby”, HSRP hace uso de la prioridad configurada en cada router. El router con mayor prioridad será el router “active” y se encargará de  enrutar los paquetes a través de la IP virtual.

EL metodo que utiliza HSRP para determinar cuando se ha producido un fallo en la red y por tanto un router “standby” debe tomar el rol de “active”, es bastante simple, se basa en el envío de paquetes Hello a la dirección multicast 224.0.0.2 puerto 1985 UDP.

Ahora  mostraré un pequeño ejemplo de cómo se configurarían dos routers Cisco para hacer uso del protocolo HSRP.

En primer lugar configuraremos el Router que va actuar como activo, para ello tendremos que definir los siguientes parametros:

• IP virtual: 172.16.1.254
• Prioridad: 115
• Preempt: por defecto desactivado, pero necesario si queremos que el router activo sea siempre el de mayor priridad.
• Track: que determinará el decremento en la prioridad(10 en el ejemplo) una vez se produce la falla.

En este caso la condición que determinará el decremento, la hemos especificado unas lineas mas arriba en el modo de configuración global, donde hemos definido un track hacia la ruta 8.8.8.8.

En caso de que la IP definida en el track se vuelva inalcanzable, se producirá un decremento de 10 en la prioridad.

...
!
track 1 ip route 8.8.8.8 255.255.255.255 reachability
!
interface Ethernet0/1
 ip address 172.16.1.1 255.255.255.0
 standby 1 ip 172.16.1.254
 standby 1 priority 115
 standby 1 preempt
 standby 1 track 1 decrement 10

Para configurar el router “standby” configuraremos lo siguiente:

• IP virtual: 172.16.1.254 (es la misma para todos los routers del grupo)
• Prioridad: 110 (tiene que ser menor que en el router activo)
• Preempt: Al igual que en el router activo.

En este caso no es necesario configurar un track.

 !
interface Ethernet0/1
 ip address 172.16.1.2 255.255.255.0
 standby 1 ip 172.16.1.254
 standby 1 priority 110
 standby 1 preempt

Como se ha explicado al principio, el protocolo HSRP se basa en el envío de paquetes Hello. Si analizamos la captura de uno de esos paquetes podemos ver la información que contiene.

Vemos en la siguiente imagen un paquete Hello enviado por el router activo, en el cual se informa del estado, prioridad, grupo, ip virtual…

A continuación vemos una captura similar pero en este caso de un paquete Hello correspondiente al router “standby”:

Como hemos visto en la configuración, hemos definido un track a la ruta 8.8.8.8.

¿Que ocurre si  el router activo no puede alcanzar esta ruta?

Podemos ver el resultado en la siguiente imagen, vemos que aparecen una serie de avisos, estado del track down, y cambio a estado “standby”… Si miramos el estado del protocolo vemos como ahora este router ha pasado al estado “standby” y ahora su prioridad es de 105:

Vemos como ahora el otro router ha pasado a ser “active”:

Si realizamos ahora una captura de los paquetes Hello, podemos ver como ahora se ha invertido el estado de los routers y como efectivamente se ha producido el decremento de prioridad:

Y el paquete Hello del nuevo router active:

Como bootear el router desde una memoria USB

Por Oscar Gerometta

http://librosnetworking.blogspot.com/2011/01/booteo-del-router-desde-una-memoria-usb.html

Típicamente los routers Cisco almacenan una copia del sistema operativo (Cisco IOS) en su memoria flash; y por defecto utilizan esa imagen del sistema operativo durante el proceso de inicialización o booteo.

Sin embargo puede ocurrir que por diferentes causas esa imagen del sistema operativo no esté disponible: corrupción del archivo, corrupción de la memoria flash, borrado accidental, etc. 

En ese caso el dispositivo no tiene una imagen válida para cargar y arrancará en modo Monitor de ROM (Rommon). Este modo nos da un conjunto reducido de comandos que esencialmente permiten ejecutar manualmente la secuencia de inicio.

Para estos casos, y aprovechando el modo Rommon, los routers ISR cuentan con 1 o 2 puertos USB que podemos utilizar para cargar la imagen de sistema operativo desde una memoria flash USB.

Booteo desde una memoria USB

El pre-requisito obvio de este procedimiento es contar con una imagen de IOS válida para el dispositivo que deseamos poner en operaciones, guardada en una memoria USB.

Una vez que contamos con este recurso, debemos ingresar al modo Monitor de ROM.

Si el dispositivo no contaba con una imagen válida de IOS en la memoria flash quedará directamente en ese modo. Si no es así, podemos forzar el ingreso al modo Rommon utilizando la secuencia de interrupción del booteo: Ctrl+Break.

A partir de este punto, reconocemos el modo Rommon por el prompt:

rommon 1>

Ya en este modo, podemos acceder al listado de comandos disponibles utilizando el comando de llamada al listado de comandos:

rommon 1>?
o
rommon 1>help

A continuación debemos chequear la imagen que tenemos almacenada en la memoria USB:

rommon 2>dir usbflash0:
program load complete, entry point: 0x8000f000, size: 0x3d240
Directory of usbflash0:
2......14871760..-rw-...c2800nm-ipbase-mz.124-3.bin

Nota: el comando es dir usbflashx: donde x asume el valor de 0 o 1 según en qué puerto del router se ha insertado la memoria USB.

A continuación se ejecuta el comando que ordena el booteo del dispositivo utilizando la imagen almacenada en la memoria USB:

rommon 3>boot usbflash0:c2800nm-ipbase-mz.124-3.bin
program load complete, entry point: 0x8000f000, size: 0x3d240
program load complete, entry point: 0x8000f000, size: 0xe2eb30
Self decompressing the image :
##########################################################################################
############################################################### [OK]

Una vez que el equipo ha booteado y ya opera con la interfaz de línea de comando EXEC tradicional, podemos copiar la imagen que tenemos en nuestra memoria USB a la memoria flash del router:

Router>enable
Router#copy usbflash0:c2800nm-ipbase-mz.124-3.bin flash:c2800nm-ipbase-mz.124-3.bin

Gracias a Internet de todo, nunca más tendrá que hacer una larga fila para pagar

http://gblogs.cisco.com/la/gracias-a-internet-de-todo-nunca-mas-tendra-que-hacer-una-larga-fila-para-pagar/

Blair Christie | mayo 7, 2015 at 11:47 am CET

Todos hemos pasado por eso. En una tienda de comestibles, en una tienda de ropa, incluso en un café, hemos esperado durante una eternidad para pagar parados en una larga fila. Entonces, en ese momento usted se pregunta: “¿vale la pena esta compra?”.  Para un tercio de los clientes, la respuesta es negativa si tienen que esperar más de cinco minutos. (Fuente: Brickstream)

Imagine si pudiésemos eliminar de nuestras vidas esas largas filas de espera. En Cisco lo hemos logrado.  

En nuestra última conversación sobre Internet de todo, imaginamos más posibilidades con nuestra campaña “Museo de las últimas veces”: el último embotellamiento, el último apagón, la última reunión a la que se falta, y también podríamos agregar la última fila para pagar.

Cada vez más, los comerciantes minoristas comprenden la importancia de tener una presencia física y digital, y cómo el poder de Internet de todo digitalizará esas experiencias.

Gracias a tecnologías tan innovadoras como el análisis predictivo −que detecta el tráfico de clientes y notifica cuándo se deben abrir más cajas− y los sensores ubicados en las estanterías, que permiten controlar el inventario y realizan los pedidos automáticamente, los clientes y los comerciantes están más cerca que nunca.

¿Pero estas tecnologías ayudan a los comerciantes a mejorar la experiencia del cliente? ¿Es posible que alguna vez se haga realidad la idea de la última fila para pagar? La respuesta es sí.

El mes pasado, compartí los resultados de un estudio reciente de Cisco que brindó información muy importante sobre los comportamientos de compra de los consumidores en Estados Unidos y el Reino Unido.

En la era digital es fundamental que los comerciantes ofrezcan experiencias “sumamente relevantes” sabiendo que, por ejemplo, los compradores que no tienen hijos no necesitan recibir cupones para pañales. Por eso, los comerciantes deben comprender el motivo y el contexto detrás de la experiencia de compra de cada usuario y actuar en consecuencia.

Los clientes eligen innovación

Los datos más significativos del estudio –principales hallazgos– distinguieron que los compradores no desean esperar en una larga fila. El 77% elegía pagar en la caja −siempre que fuera un servicio optimizado− con un tiempo de espera promedio, mientras que el 60% pensaba en utilizar su smartphone para escanear los códigos de barras de los productos y posteriormente efectuar el pago en un punto de autoservicio.

Estos son las experiencias digitales que los compradores buscan y que ayudarán a eliminar las filas para pagar.

Imagine un mundo donde los comerciantes apliquen las nuevas tecnologías y de esta manera los clientes puedan obtener todos los productos que buscan, y hagan el pago sólo pasando su dispositivo móvil. Las transacciones se podrían realizar en cualquier lugar de la tienda y el cliente, luego, podría salir sin perder un minuto de su tiempo. Ya es hora de olvidar las largas filas.


Y este mundo ideal no está tan lejos. Los comerciantes creen que para el año 2017, el 56% de todas las transacciones se completará mediante un punto de venta móvil, una caja autoservicio en un terminal o un dispositivo móvil. (Fuente: Motorola)

Algunos comerciantes ya han comenzado este proceso innovador para mejorar la experiencia del cliente, eliminando las largas filas para pagar.

Intu, un caso éxito

Intu, el administrador, desarrollador y propietario de centros comerciales especializados más importante del Reino Unido, invirtió en la estructura de red y en funcionalidades multicanal para lograr una movilidad mejorada.

Y a los cuatro meses de tener Wi-Fi en sus centros, aumentó su base de datos de clientes en un 25%. 

Así entendió que es posible atraer a los clientes que prefieren la movilidad y desarrollar relaciones más sólidas y personalizadas con ellos.

A medida que la movilidad avanza, es esencial para una mejor experiencia del cliente, y la necesidad de extenderla a las filas para pagar, garantizará el éxito de los comerciantes. El comercio minorista del futuro está llegando.

Gracias a Internet de todo, una larga fila para pagar puede ser verdaderamente una cosa del pasado.

Mientras celebramos nuestro trigésimo  aniversario, seguimos esperando un futuro en el que los desafíos cotidianos como la última fila para pagar, el último embotellamiento y tantas otras cosas, se hagan realidad.

Cisco y sus partners están trabajando conjuntamente para hacer que estas cosas increíbles ocurran con la tecnología.

Me encantaría no esperar nunca más en una larga fila para pagar cuando estoy en una tienda de comestibles. ¿Y usted?

La tabla de enrutamiento en Cisco IOS

http://librosnetworking.blogspot.com.ar/2015/05/la-tabla-de-enrutamiento-en-cisco-ios.html

Por Oscar Gerometta

En Cisco IOS la información de enrutamiento se incorpora en la tabla de enrutamiento (básicamente una base de datos de información de enrutamiento) utilizando varios procedimientos diferentes:

• Redes Locales (L)
  * Identifican las direcciones IP asignadas a las interfaces del propio dispositivo.
  * Las rutas locales IPv4 poseen máscara de subred /32, las rutas locales IPv6 tienen prefijos /128.
  * Las rutas locales tienen una distancia administrativa de cero.
  * Se utilizan para procesar los paquetes que tienen como destino interfaces del mismo dispositivo. Estas rutas no son redistribuidas.
  * Si la interfaz deja de estar operativa, esta ruta es removida automáticamente de la tabla.
• Redes directamente conectadas. (C)* Identifican el segmento de red directamente conectado a cada interfaz del dispositivo.
  * El origen de la información es el segmento de red directamente conectado a las interfaces del dispositivo.
  * Si la interfaz deja de ser operativa la red asociada es removida automáticamente de la tabla de enrutamiento. Su distancia administrativa es 0 y son preferidas a cualquier otra ruta.
• Rutas estáticas. (S)* Son ingresadas manualmente por el Administrador de la red.
  * Su distancia administrativa por defecto es 1.
• Rutas dinámicas.* Son rutas aprendidas automáticamente a través de del intercambio de información con dispositivos vecinos generado por los protocolos de enrutamiento.
  * Estas rutas se modifican automáticamente en respuesta a cambios en la red.

Cisco IOS construye la tabla de enrutamiento utilizando un algoritmo para seleccionar la mejor ruta a cada destino conocido, a partir de los siguientes 2 parámetros: la distancia administrativa y la métrica.

Cuando se encuentras múltiples rutas de igual origen (igual distancia administrativa) e igual métrica , por defecto Cisco IOS incorpora hasta 4 rutas en la tabla de enrutamiento.

Cisco ASA: Configuración del NAT básica

Cisco ASA 5510

Nota extraída del documento: http://www.cisco.com/cisco/web/support/LA/111/1118/1118174_asa-config-dmz-00.html con mejoras realizadas por el editor del blog.

Introducción

Este documento proporciona un ejemplo simple y directo de cómo configurar el NAT y el Listas de control de acceso (ACL) en un Firewall ASA para permitir la Conectividad saliente así como entrante. 

Este documento fue escrito usando un Firewall ASA 5510 que funcionaba con la versión del código ASA 9.1(1) pero éste puede aplicarse fácilmente a cualquier otra plataforma del Firewall ASA. 

Si usa una plataforma tal como un ASA 5505, que utiliza los VLA N en vez de la interfaz física, usted necesita cambiar los tipos de interfaz como apropiados.

Contribuido por Magnus Mortensen, ingeniero de Cisco TAC.

Componentes Utilizados

La información en este documento se basa en el Firewall ASA 5510 que funciona con la versión del código ASA 9.1(1).

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 

Si la red ya está en producción, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Metas

En este ejemplo de configuración, usted puede considerar qué configuración NAT y de lista de control de acceso serán necesarias configurar para permitir el acceso entrante a un web server en el DMZ de un Firewall ASA, y permite la Conectividad saliente de los hosts internos y DMZ. Esto se puede resumir como dos metas:

1. Permita los hosts en el interior y la Conectividad saliente DMZ a Internet.
2. Permita que los hosts en Internet accedan un web server en el DMZ con una dirección IP de 192.168.1.100.

Descripción de la lista de control de acceso

Las listas de control de acceso (ACL) son el método por el cual el Firewall ASA determina si se permite o se niega el tráfico. 

Por defecto, el tráfico que pasa de un Nivel más bajo al mayor nivel de seguridad se deniega. Esto se puede reemplazar por un ACL aplicado a esa interfaz de menor seguridad. 

También el ASA, por defecto permitirá el tráfico de una interface de mayor nivel de seguridad a una de menor seguridad. Este comportamiento se puede también reemplazar con un ACL.

Descripción general de NAT

El NAT en el ASA en la versión 8.3 y posterior está dividido en dos tipos que se conocen como NAT auto (objeto NAT) y NAT manual (dos veces NAT). 

El primero de los dos, el objeto NAT, se configura dentro de la definición de un objeto de red. Un ejemplo de esto se proporciona más adelante en este documento. 

Una ventaja principal de este método NAT es que el ASA pide automáticamente las reglas para procesar y evita conflictos. Ésta es la forma más fácil de NAT, pero con esa facilidad viene una limitación en la granularidad de la configuración. Por ejemplo, usted no puede tomar la decisión de la traducción basada en el destino del paquete, lo que si puede lograrse con el segundo tipo de NAT manual. 

El NAT manual es más robusto en su granularidad, pero requiere que las líneas estén configuradas en la orden correcto para alcanzar la conducta correcta. Esto complica este tipo NAT y como consecuencia, no será utilizada en este ejemplo de configuración.

Configuración

La configuración básica de la configuración ASA es de tres interfaces conectadas con tres segmentos de red. 

El segmento de la red ISP está conectado con la interfaz del Ethernet0/0 y etiquetado Outside con un nivel de seguridad de 0. 

La red interna ha estado conectada con Ethernet0/1 y etiquetada como Inside con un nivel de seguridad de 100. 

El segmento DMZ, donde reside el web server está conectado con Ethernet0/2 y etiquetado como dmz con un nivel de seguridad de 50.

La configuración de la interfaz y los IP Addresses por el ejemplo se considera aquí:

interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 198.51.100.100 255.255.255.0
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 192.168.0.1 255.255.255.0
!
interface Ethernet0/2
 nameif dmz
 security-level 50
 ip address 192.168.1.1 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 198.51.100.1

Aquí usted puede ver que la interfaz Inside ASA está fijada con la dirección IP de 192.168.0.1, y es el default gateway para los host internos. 

La interfaz eOutside ASA se configura con una dirección IP obtenida del ISP. 

Hay una ruta predeterminado en el lugar, fijando el Next-Hop para ser el gateway ISP. 

Si usted utiliza el DHCP esto se proporciona automáticamente. 

La interfaz del dmz se configura con la dirección IP de 192.168.1.1, y es el default gateway para los hosts en nuestro segmento de la red DMZ.

Topología

Aquí está una mirada visual en cómo se cableó y se configuró esto:

Paso 1 - Configuración NAT para permitir que los hosts salgan a Internet

Para este objeto NAT del ejemplo, se usará el método conocido como AutoNAT. 

Lo primero que configuraremos son las reglas NAT que permiten a los hosts en Inside y a los segmentos del dmz conectarse con Internet. 

Debido a que estos hosts están utilizando direcciones IP privadas, usted necesita traducirlas  a direcciones que sean enrutables en Internet. 

En este caso traduzca el direccionamiento de modo que parezcan la dirección IP de la interfaz Outside ASA. Si su IP externa cambia con frecuencia (quizás debido al DHCP) ésta es la manera más directa de configurar esto.

Para configurar este NAT, usted necesita crear un objeto de red que represente la subred Inside así como uno que represente la subred del dmz. 

En cada uno de estos objetos, configure una regla NAT dinámica que traduzca a estos clientes como el paso de sus interfaces respectivas a la interfaz Outside.

Esta configuración se vería así:

object network inside-subnet
 subnet 192.168.0.0 255.255.255.0
 nat (inside,outside) dynamic interface
!
object network dmz-subnet
 subnet 192.168.1.0 255.255.255.0
 nat (dmz,outside) dynamic interface

Si usted revisa la configuración (con el comando show run), usted verá que la definición del objeto está partida en dos partes de la salida. La primera parte indica solamente cuál está en el objeto (host/subred, dirección IP, etc), mientras que la segunda sección muestra que regla NAT atada a ese objeto. Si usted toma la primera entrada en la salida arriba:

Cuando la dirección de los hosts coincide con la red 192.168.0.0/24 de la interfaz Inside hacia la interfaz Outside deben ser traducidos dinámicamente a la interfaz Outside

Paso 2 - Configuración NAT para acceder el web server de Internet

Ahora que los hosts en las interfaces interiores y del dmz pueden salir a Internet, usted necesita modificar la configuración de modo que los usuarios en Internet puedan acceder nuestro web server en el puerto TCP 80. 

En este ejemplo, la configuración está hecha de modo que los usuarios en Internet puedan conectarse con una dirección IP pública que el ISP proporcionó. 

Para este ejemplo, utilice 198.51.100.101. Con esta configuración, los usuarios en Internet podrán alcanzar el web server del dmz accediendo 198.51.100.101 en el puerto TCP 80. 

Utilice el objeto NAT para esta tarea, y el ASA traducirá el puerto TCP 80 en el web server (192.168.1.100) para parecer 198.51.100.101 en el puerto TCP 80 en el Outside. 

De forma similar a la qué fue hecha arriba, se define un objeto y se definen las reglas de traducción para ese objeto. También, defina un segundo objeto para representar el IP al que usted está traduciendo este host.

Esta configuración debería ser así:

object network webserver-external-ip
 host 198.51.100.101
!
object network webserver
 host 192.168.1.100
 nat (dmz,outside) static webserver-external-ip service tcp www www

Solo para resumir lo que significa esa regla NAT en este ejemplo:

Cuando un host que coincide con la dirección IP 192.168.1.100 en el segmento dmz establece una conexión originada en el puerto TCP 80 (WWW) y esa conexión sale la interfaz Outside, queremos traducir eso para ser el puerto TCP 80 (WWW) en la interfaz Outside y para traducir esa dirección IP por 198.51.100.101

Esta sentencia parecería tener un sentido incorrecto… “originada en el puerto TCP 80 (WWW)”, si solamente del tráfico de la Web se destina al puerto 80. Pero aquí es importante entender que estas reglas NAT son bidireccionales por naturaleza. Como consecuencia usted puede reformular esta frase moviendo de un tirón la fraseología alrededor. El resultado tiene mucho más sentido si lo ponemos de esta forma:

Cuando los hosts en Outside establecen una conexión a 198.51.100.101 en el puerto 80 (WWW) del TCP de destino, traduciremos la dirección IP de destino para ser 192.168.1.100 y el puerto destino será el puerto TCP 80 (WWW) y  se lo mandará al segmento dmz

Esto tiene más sentido cuando está expresada esta manera. Luego usted necesita configurar los ACL.

Cisco ASA 5505

Paso 3 - Configuración ACL

El NAT ya está configurado y ya estamos cerca de terminar. Recuerde, los ACL en el ASA permiten que usted reemplace la conducta de seguridad predeterminada que es como sigue:

• El tráfico que va de una interfaz de menor seguridad se niega al ir a una interfaz de mayor seguridad
• El tráfico que va de una interfaz de mayor seguridad se permite al ir a una interfaz de menor seguridad

Entonces sin agregar ningun ACL en absoluto a la configuración, el tráfico siguiente en este ejemplo trabaja de la siguiente forma:

• Los hosts en Inside (nivel de seguridad 100) pueden conectar con los hosts en el dmz (nivel de seguridad 50)
• Los hosts en Inside (nivel de seguridad 100) pueden conectar con los hosts en el Outside (nivel de seguridad 0)
• Los hosts en el dmz (nivel de seguridad 50) pueden conectar con los hosts en el Inside (nivel de seguridad 0)

Sin embargo, se niega el tráfico siguiente:

• Los hosts en Outside (nivel de seguridad 0) no pueden conectar con los hosts en Inside (nivel de seguridad 100)
• Los hosts en Outside (nivel de seguridad 0) no pueden conectar con los hosts en el dmz (nivel de seguridad 50)
• Los hosts en el dmz (nivel de seguridad 50) no pueden conectar con los hosts en Inside (nivel de seguridad 100)

Debido a que el tráfico del Outside hacia lared del dmz es denegado por el ASA con su configuración actual, los usuarios en Internet no pueden alcanzar el web server a pesar de la configuración del NAT en el paso 2. 

Usted necesita permitir explícitamente este tráfico. 

Una vez que se crea el ACL, usted necesita aplicarlo entrante en la interfaz exterior.

La configuración se verá algo así:

access-list outside_acl extended permit tcp any object webserver eq www
!
access-group outside_acl in interface outside

Las sentencias del ACL indican:

Permitir el tráfico de any (de donde) hacia el host representado por el objeto web server (192.168.1.100) en el puerto 80

Es importante que la configuración use la palabra clave any aquí. Como el origen de los clientes del Web Server podría ser cualquiera, la opción any significa "cualquier dirección IP".

Vea mas ejemplos de configuración en el sitio web de Cisco: http://www.cisco.com/cisco/web/support/LA/111/1118/1118174_asa-config-dmz-00.html