Access list para ver si el tráfico está pasando

Una funcionalidad muy útil que se puede sacar a las accesss-list es la de comprobar si algún tráfico está atravesando el router, es algo parecido a activar un tcpdump en una maquina unix, pero bastante mas rudimentario.

Simplemente consiste en crear una access list en la que configurarmos un permit para el tipo de tráfico que estamos esperando encontrar, junto con la clausula log, y una segunda linea que ponga permit ip any. Lo que conseguimos con esto es, que si el tráfico que estamos buscando pasa por el router nos lo muestre en el log, pero en ningún caso vamos a cortar tráfico.

La verdad es que así contado quizá no se entienda bien, pero vamos a poner un ejemplo en el que se ve bastante claro.

access-list 10 permit 192.168.1.1 log <--- si entra tráfico de este origen meteme una entrada en el log y déjalo pasar

access-list 10 permit any <--- deja pasar el tráfico restante

Si hacemos un show access list vemos que el tráfico de la 192.168.1.1 está atravesando el router.

 Router#show access-lists 10
Standard IP access list 10
    10 permit 192.168.1.1 log(40 matches) <----40 paquetes de origen 192.168.1.1 

    20 permit any(149407 matches) <---- el resto de paquetes viene de otros orígenes

Lo bueno que tiene esta práctica es que no tiene en principio impacto sobre el tráfico, ya que en realidad todo el tráfico está permitido. La cagada puede ser que se te olvide poner el permit any, pero bueno, son cosas que pasan :D .

Sobre el impacto en el router, para dispositivos con tarjetería con algo de inteligencia es nulo, ya que el router trabaja con las ACL a nivel de hardware. Para plataformas de routers de gama baja puede tener algo de impacto en la CPU del router, y si tienes la CPU al 98% no sería una buena idea aplicarlo, aunque claro, en un router con una CPU a ese nivel nada que no sea un upgrade de dispositivo es una buena idea.

Aquí os detallo una serie de links a otros artículos sobre ACL.

Access list Standard y extendidas: Filtrando en un router/firewall cisco

Access list Standard y extendidas: Filtrando en un router/firewall cisco

Las ACL son posiblemente el mecanismo mas sencillo para filtrar tráfico del que disponemos en un equipo de red.

Este es el primero de una serie de artículos en los que se tratarán los diversos tipos de ACL, desde los tipos mas sencillos, hasta funciones mas avanzadas.

Una ACL simplemente es un filtro en el que se especificará una lista del tráfico que se deja pasar y se deniega en una serie de tarjetas. 

A la hora de crear access list lo primero que debemos tener en cuenta es, que tan solo se puede especificar una access list para entrada, y otra para salida en la misma interfaz, el numero de lineas de la ACL es ilimitado. De la mano de esto podemos decir que una misma ACL se puede aplicar a múltiples interfaces, no hace falta crear una ACL por interfaz.

También hay que tener en cuenta que las ACL se evalúan de manera secuencial, si un tráfico esta afectado por un permit o un deny en una ACL en la linea número 1, no seguirá leyendo la ACL, el tráficos será denegado o permitido. Por ello es importante en las ACL establecer las sentencias mas específicas al inicio de la ACL, y las secuencias mas generales al final de la ACL, sin olvidar que por defecto toda ACL lleva implícito un deniega todo el tráfico en la última linea.

Las máscaras que se utilizan en las ACL son máscaras de Wildcard, que son inversas a las máscaras de red, para leer un poco sobre wildcard dejo este enlace.

Por último, las listas de acceso están identificadas con un número de lista de acceso, según el número de  la lista, esta lista será de un tipo u otro, a continuación la tabla de rangos disponibles para cada tipo de ACL:

1 99 IP standard access lists

100 199 IP extended access lists

200 299 Protocol type-code access lists

300 399 DECnet standard access lists

400 499 XNS standard access lists

500 599 XNS extended access lists

600 699 AppleTalk cable range access lists

700 799 MAC address access lists

800 899 Novell IPX standard access lists

900 999 Novell IPX extended access lists

1000 1099 Novell IPX SAP access lists

1100 1199 MAC address access lists (extended range)

1200 1299 Novell IPX NLSP access lists

1300 1999 IP standard access lists (extended range)

2000 2699 IP extended access lists (extended range)

En este artículo en concreto vamos a tratar dos tipos de ACL , la standard y las extendidas, que son las identificadas por los dos primeros rangos, con el tiempo se añadieron los dos últimos rango ya que a veces podemos necesitar mas de 100 listas de acceso diferentes en un equipo.

Listas de acceso standard:

Las listas de acceso standard permiten filtrar el tráfico en función del origen del paquete.

access-list <Numero_de_ACL> <deny/permit> <red_origen> <mascara_origen>

Numero de ACL: Es el número que identifica a la ACL, y todas las lineas de ACL que incluyan ese número formaran parte de la ACL.

Permit/deny: como os podeis imaginar es si queremos dejar pasar el tráfico o lo queremos filtrar.

Red origen y mascará de origen: El tráfico que queremos filtar. Se puede utilizar la sentencia host si solo queremos afectar a una única IP, como veremos en el siguiente ejemplo.

access-list 10 permit host 192.168.1.1
access-list 10 deny 192.168.1.0 0.0.0.255
access-list 10 permit any

En este ejemplo permitiríamos el tráfico con origen de la ip 192.168.1.1, pero denegaríamos el de toda la subred a la que pertenece la 192.168.1.1. El resto del tráfico estaría permitido.

Para aplicar la access list a una interfaz:

router(config)# int fast0/0
router(config-if)#ip access-group 10 <in/out>

Listas de acceso extended:

Las listas de acceso extendidas son parecidas a las standard, pero permiten elegir origen, destino, puerto y protocolo, en el fondo los firewalls tradicionales se componen de listas de acceso extendidas, teniendo en cuenta las nuevas opciones de las ACL extendidas su funcionamiento es mayormente igual al de las listas de acceso standard.

access-list <Numero_ACL> <deny/permit>  <protocolo> <red_origen> <mascara_destino> <red_origen> <mascara_destino> <eq/gt/lt> <numero puerto>

Protocolo permite seleccionar el tipo de protocolo que queremos usar, ya sea tcp, udp, icmp...etc. Para seleccionar todos usaremos ip como protocolo.

Red de destino y máscara su nombre lo indica, en ellos también podemos especificar la sentencia host, o la sentencia any.

eq/gt/lt: Eq se utilizará para decir que un puerto igual a x. gt que el puerto sea mayor a x , y por último lt   para especifcar que puertos sea menor a x.

Ejemplo:

interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group 101 in
access-list 101 deny icmp any 10.1.1.0 0.0.0.255
access-list 101 permit ip any 10.1.1.0 0.0.0.255

Un último dato importante para TODAS las ACL es, que el tráfico con origen desde el propio router nunca es evaluado en las ACL, las ACL solo funcionan cuando el tráfico entra al router y sale del router, NUNCA para el tráfico originado desde el propio router.

Comandos relacionados:

show access-list

IP SLA: Configuración

Una vez que en el anterior artículo tratamos que es IP SLA, ahora ha llegado la hora de configurar.

Existen varios tipos de IP SLA a configurar, pero en esta ocasión voy a explicar como se configura un IP SLA que haga un ping a una ip.

r(config)#ip sla (ip_sla_number)
r(config-ip-sla)#icmp-echo (Destination_IP) source-ip (source_ip)
r(config-ip-sla-echo)#frequency (seconds)
r(config-ip-sla-echo)#timeout (milliseconds)
r(config-ip-sla-echo)#vrf (vrf_name)

Se configura un número de IP SLA, que contendrá la dirección IP a la que se hace el ping, la que usamos de origen para hacer el ping, cada cuantos segundos lo hacemos, cuanto tiempo damos de margen para saber si esta caido, y por último el VRF al que pertenece en caso de estar usando VRF.


Después configuramos cuando queremos que se ejecute el IP SLA, y por cuanto tiempo.

r(config)#ip sla schedule (ip_sla_number) start-time ( now | hh:mm:ss | after hh:mm:ss ) life ( time_in_seconds | forever ) 

 Creamos un tracker, cuya función es saber si el IP SLA está respondiendo correctamente, o ha dejado de respondernos a ping el otro extremo.

r(config)#track (sla_tracking number) ip sla (sla_number) state

Y por último creamos la ruta, que se mantendrá en la tabla de rutas siempre que el tracker de nuestro IP SLA siga respondiendo, si falla la ruta desaparece, y si vuelve a responder, la ruta vuelve a la tabla de routing.

ip route x.x.x.x y.y.y.y z.z.z.z  track (track_number) 

Ejemplo:

El ejemplo lo que hace es hacer ping a una ip, que es un router que tenemos conectado por medio de una fibra oscura, como en este tipo de enlaces es posible que se nos caiga el otro extremo pero sigamos teniendo link una ruta estática no funcionaría bien, en cambio lo que hacemos es monitorizar el otro extremo con un IP SLA. Si todo va bien usamos la fibra oscura, en caso de fallo usamos una conexión RDSI de respaldo.

r(config)#ip sla 1r(config-ip-sla)#icmp-echo 192.168.1.33 source-ip 192.168.1.1
r(config-ip-sla-echo)#frequency 2
r(config-ip-sla-echo)#timeout 8000

Hace un ping a la 192.168.1.33 con origen 192.168.1.1, la frecuencia de los ping es cada 2 segundos, y si en 8 segundos no hay respuesta se considera que el otro extremo está caído.

r(config)#ip sla schedule 1 start-time now life forever

Comando intuitivo donde los haya, empieza ahora, y sigue haciendo pings siempre.

r(config)#track 33 ip sla 1 state

Activamos tracking del estado del IP SLA, si responde ok todo correcto.

ip route 10.0.0.0 255.0.0.0 192.168.1.33 track 33 1
ip route 10.0.0.0 255.0.0.0 250 dialer 1 250

 Tenemos dos rutas para llegar al mismo destino, por defecto usamos la primera, esa ruta se mantendrá en memoria siempre que el IP SLA siga respondiendo, en caso de dejar de responder lanzaremos el dialer 1, que es una RDSI que tenemos como backup.

Comandos relacionados:

show ip route
show run | inc ip route
show ip sla
show ip sla statistics (sla_number)
debug track

Enlace al primer artículo sobre IP SLA

IP SLA: Añadiendo inteligencia a tu red

La primera vez que leí algo sobre IP SLA pensé, ¡¡¡Oh no, ITIL hasta en la sopa!!! , pero en cuanto empecé a leer un poco me di cuenta que no tenía nada que ver con ITIL y su documentación, en cambio si que podía ser una herra mienta muy util.

¿Que es IP SLA?

Es un software embebido dentro de IOS, el cual permite comprobar el estado de diferentes elementos y servicios de red, y en caso de superarse umbrales de error, generar alertas, modificar el routing, y algunas otras cosillas interesantes.

¿Que cosas interesantes podemos detectar?

Si tu red esta teniendo problemas de jittering UDP, y por tanto tu servicio de voz sobre IP esta empezando a tener problemas.

Si un servicio o servidor remoto ha dejado de responder a Ping, o lanzar una sesion TCP contra un puerto de ese servidor para comprobar si el servicio de ese puerto sigue activo.

El listado sacado de las Whitepapers de cisco es el siguiente:

	Measurement Capability	Key Applications
UDP Jitter	• Round-trip delay, one-way delay, one-way jitter, one-way packet loss • One-way delay requires time synchronization between the Cisco IOS IP SLAs source and target routers	Most common operations for networks that carry voice or video traffic, such as IP backbones
UDP Echo	Round-trip delay	Accurate measurement of response time of UDP traffic
UDP Jitter for VoIP	• Round-trip delay, one-way delay, one-way jitter, one-way packet loss • VoIP codec simulation G.711 ulaw, G.711 alaw, and G.729a • MOS and ICPIF voice quality scoring capability • One-way delay requires time synchronization between the Cisco IOS IP SLAs source and target routers	Useful for VoIP network monitoring
TCP Connect	Connection time	Server and application performance monitoring
Domain Name System (DNS)	DNS lookup time	DNS performance monitoring, troubleshooting
Dynamic Host Configuration Protocol (DHCP)	Round-trip time to get an IP address	Response time to a DHCP server
FTP	Round-trip time to transfer a file	FTP get performance monitoring
HTTP	Round-trip time to get a Web page	Web site performance monitoring
Internet Control Message Protocol (ICMP) Echo	Round-trip delay	Troubleshooting and availability measurement using ICMP ping
ICMP Path Echo	Round-trip delay for the full path	Troubleshooting
ICMP Path Jitter	Round-trip delay, jitter, and packet loss for the full path	Troubleshooting
Data Link Switching Plus (DLSw+)	Peer tunnel performance	DLSw peer tunnel performance monitoring

Pongo la url para mas datos:
http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white_paper0900aecd8017531d_ps6602_Products_White_Paper.html

¿Utilidad práctica?

Que tu red ya no genera tan solo alertas por caidas de interfaces o dispositivos, tu red es capaz de detectar que ciertos servicios críticos ya no funcionan, generando las correspondientes alertas de syslog, cosa que de cara a un posible análisis forense posterior a incidencia resulta muy útil.

Crear un cierto routing dinámico, basado en que ciertos servidores, routers, o lo que sea estan disponibles, y en caso de no estarlo eliminar ciertas rutas, dando paso a rutas de backup.

Las dos utilidades anteriores nos dan como conclusión que es una herramienta que permite optimizar tu red, y hacer que esta sea capaz de dar un servicio mejor, aprovechando todos los recursos.


En el siguiente artículo explicaremos su configuración y pondremos un ejemplo.

Enlace al articulo sobre configuración de IP SLA

Tipos de redes compatibles OSPF

En el artículo anterior escribimos sobre los tipos de redes en OSPF, en este artículo vamos a ver como hacer compatibles dos vecinos de OSPF que no tienen configurado el mismo tipo de red.

El principal criterio para que dos tipos de redes de OSPF sean compatibles es, ambas usen DR/BDR o ninguna lo use, pero si una de las redes usa DR/BDR y en el otro extremo está configurado con un tipo de red que no admite DR/BDR nunca existirá una adyacencia al 100%,

El segundo criterio es ajustar los temporizadores, para que ambos usen los mismos temporizadores, ya que si no se ajustan correctamente las adyacencias en ospf no se levantarán, o se levantarán y caeran constantemente.

Existe un cierto efecto espejismo si se ajustan los temporizadores de dos redes que son incompatibles por el tema de DR/BDR, parece que los dos routers han conseguido hacerse vecinos, pero no son capaces de ver las bases de datos del uno y el otro respectivamente. Cuando esta pasando esto, en la base de datos de OSPF aparece el siguiente mensaje respecto al vecino “Adv Router is not-reachable”.

Aquí se detalla un listado de las redes  que son compatibles:


NBMA con NBMA
Broadcast con Broadcast
Punto a punto con Punto a punto
Punto a multipunto con Punto a multipunto
Broadcast con NBMA  (ajustando los temporizadores de hello y dead interval)
Punto a punto con Punto a multipunto  (ajustando los temporizadores de hello y dead interval)

Comandos relacionados:

show ip ospf neighbors
show ip ospf database
(config-if)#ip ospf network broadcast
(config-if)#ip ospf network non-broadcast
(config-if)#ip ospf network  point-to-multipoint broadcast
(config-if)#ip ospf network  point-to-multipoint non-broadcast
(config-if)#ip ospf network  point-to-point

Tipos de redes en OSPF:

A la hora de configurar ospf, independientemente de los tipos de Areas y otras configuraciones especiales, hay que tener en cuenta los tipos de redes que se pueden configurar en OSPF, ya que estos van a delimitar algunas funcionalidades, y es algo que resulta realmente  importante si estas preparando el examen práctico del CCIE.

• Broadcast multiaccess
• Nonbroadcast multiaccess (NBMA)
• Point-to-point
• Point-to-multipoint broadcast
• Point-to-multipoint nonbroadcast

Broadcast multiaccess, NBMA y Point to Point son estandares que estan recogidos en la RFC 2338, mientras que point to multipoint brodcast , y point to multipoint non broadcast son tecnología propietaria de cisco.

La siguiente tabla muestra las diferencias respecto a cada tipo de red.

Para configurar el tipo de red hay que entrar en la interfaz e introducir el tipo de red que queremos, teóricamente deberíamos configurar el mismo tipo de red en ambos extremos, pero a esto hay excepciones, y lo trataremos en otro artículo.

R1(config-if)#ip ospf network ?
  broadcast            Specify OSPF broadcast multi-access network
  non-broadcast        Specify OSPF NBMA network
  point-to-multipoint  Specify OSPF point-to-multipoint network
  point-to-point       Specify OSPF point-to-point network