Blog personal de Sergio Madrigal donde encontrar textos sobre ciencia y tecnología, psicología, cine y literatura y quizá alguna cosita más.

Etiqueta: network (página 1 de 1)

Análisis de rendimiento de aplicaciones

Una de las partes importantes de un análisis de rendimiento de cualquier desarrollo o aplicación es el que se dirige hacia el comportamiento de la aplicación bajo diferentes entornos/contextos y con unas condiciones determinadas.

Este tipo de análisis nos van a permitir definir los límites de funcionamiento de la aplicación así como identificar las causas que pueden estar limitándolo.

Para poder realizar este tipo de análisis debemos tratar de, en la medida de lo posible, elegir una variable significativa y mantener el resto de variables estables mientras se realiza la prueba.

Dentro de las pruebas de comportamiento (Behaviour Tests) nos encontramos con dos tipos:

Test de carga (Load test)

Se modela el uso esperado de la aplicación realizando pruebas con accesos simultáneos por parte de los usuarios dentro de un comportamiento normal. De esta forma se puede analizar la respuesta de los sistemas ante un uso que se considera “normal” de la aplicación y si cumple con los requerimientos iniciales.

Test de estrés (Strees test)

En este caso se trata de buscar el punto de ruptura en el que la aplicación, incrementando la variable hasta por encima de su límite tolerado, deja de responder correctamente.

Como variables significativas que podemos emplear en estos tipos de pruebas, podrían ser:

  •  Usuarios
  •  Consultas
  •  Archivos
  •  Transacciones

Laboratorio de Redes #102 – BGP y OSPF – Redistribución 2

Ya tenéis disponible para descargaros el segundo capítulo de la serie de tutoriales de redes de sergiomadrigal.com.

En este capítulo abordo la implantación en una red CORE de un proveedor de servicios de un protocolo de enrutamiento dinámico, en este caso OSPF, cuya única finalidad será la de publicar las direcciones IP de las interfaces loopback de los dispositivos que van a componer la red BGP.

Esto se realiza de esta forma como parte de las buenas prácticas a la hora de configurar iBGP.

Así mismo configuro la redistribución de los dos procesos OSPF iniciales que publican las redes LAN de Madrid y Valencia con el núcleo BGP proporcionando así la estructura de enrutamiento dinámico necesaria para que ambos entornos, LAN de Valencia y LAN de Madrid sean accesibles entre sí.

Si tenéis cualquier duda o consulta disponéis de los comentarios tanto en el vídeo como en el blog.

[su_youtube url=»https://www.youtube.com/watch?v=n-AaEOUNPMA»]

Redes: El comando network

Si precisamente hace unos días durante la realización del videotutorial #101 – OSPF y BGP – Redistribución | Capítulo 1 os comentaba la pequeña característica especial que tiene el comando «network» a la hora de emplearlo cuando configuramos IGPs (Interior Gateway Protocol) como OSPF o EIGRP, he encontrado esta estupenda entrada en el blog «Mis Libros de Networking» donde explican a la perfección su uso y sus características especiales.

Más allá de las configuraciones en sí mismas que podréis revisar accediendo al enlace, me parece realmente interesante mencionar el siguiente párrafo:

El comando network es el que se utiliza para definir en todos los casos qué interfaces del dispositivo participan del proceso de enrutamiento. Los efectos prácticos del comando son 3

1. Identifica las interfaces a través de las cuáles se publica información del protocolo de enrutamiento hacia los dispositivos vecinos.

2. Identifica las interfaces a través de las cuáles se recibe información del protocolo de enrutamiento publicada por los dispositivos vecinos.

3. La red o subred a la que está asociada la interfaz va a ser incluida en el proceso del protocolo de enrutamiento.

Queda bastante clara la explicación y lo que no es el comando network: no publica las redes que define sino que activa las interfaces que la dupla red / máscara incluye y son las redes asociadas a esas interfaces las que se terminarán publicando.

Os recomiendo que le echéis un vistazo al artículo al completo porque no tiene desperdicio.

# El comando Network en Mis Libros de Networking

Conceptos básicos de redes: Wildcards

La mayoría de veces que trabajemos con direcciones IPv4 haremos uso de las conocidas máscaras de red. Tenéis en el blog un post dedicado íntegramente al concepto de subnetting en el que se profundiza en el uso de las máscaras de red.

Si embargo no siempre se usan estas máscaras en las configuraciones de los routers. Existe otro concepto bastante extendido que, al igual que las máscaras de red, se usa como patrón para delimitar qué porción de la dirección IP introducida corresponde a la dirección de red y qué porción a las posibles direcciones de host. Este concepto se conoce como «wildcard». 

No conozco si existe una traducción al castellano de este mecanismo y su traducción literal queda demasiado mal como para utilizarla en este artículo.

Las wildcards se caracterizan por ser un elemento complementario a las máscaras de red. El patrón que se aplica es, a diferencia de en éstas últimas, el opuesto: cuando hay un 0 se mantiene el valor y cuando hay un 1 se sustituye por un 0.

La mejor forma de entenderlo es con un ejemplo:

Si disponemos de una red /24 como la 192.168.0.1/24, sabemos que el 24 nos indica el número de 1’s que tiene la máscara de red asociada: 255.255.255.0. Si aplicamos la lógica AND entre esta máscara y la dirección IP tendremos como resultado la dirección de red: 192.168.0.x (Siendo x cualquier valor entre 0 y 255)

En el caso de las wildcards tendríamos que usar el número opuesto: 0.0.0.255 para obtener el mismo resultado.

De esta forma la máscara sería 00000000.00000000.00000000.11111111 y sólo en el caso de los 1’s existiría una sustitución por valor 0 en la dirección de red.

Existe un pequeño truco para obtener rápidamente qué valores tenemos disponibles como direcciones de host en una dupla dirección IP + wildcard.

Si por ejemplo disponemos de la dirección 10.0.0.0 con la wildcard 0.0.0.3 las direcciones de host disponibles serían de la 10.0.0.0 a la 10.0.0.3 ¿Sencillo verdad?

Así mismo, como sabemos que la máscara de red es la complementaria, tendríamos que en el ejemplo anterior, para la wildcard 0.0.0.3, nuestra máscara de red debería ser: 255.255.255.252

Se trata de un concepto relativamente sencillo pero que es vital conocer puesto que muchas configuraciones de protocolos de enrutamiento dinámicos, ACLs, route maps, etc., usan este elemento en lugar de las conocidas máscaras de red.

Seguridad en Redes: Arquitectura AAA

En entornos de seguridad informática, AAA representan las siglas para: Authentication (Autenticación), Authorization (Autorización) & Accounting (Registro).

Se trata de una arquitectura de seguridad que permite la gestión de acceso definiendo políticas de seguridad.

Una forma sencilla de recordar las diferencias entre cada una de las “As” de AAA es la siguiente:

Authentication = ¿Quién?

Mediante la autenticación, el sistema descubre quién es el usuario que está tratando de acceder a determinado recurso y, una vez identificado, le aplica las políticas de seguridad definidas en función de su rol

Authorization = ¿Acceso a qué?

Una vez el usuario ha sido autenticado, es decir, identificado, se le aplican las directivas de seguridad necesarias que, finalmente, le permitirán acceso o no a determinados recursos de la red. Esta fase, conocida como autorización, es en la que se definen estos recursos accesibles para determinados roles.

Accounting = Log.

La última A es la encarga de registrar todos los accesos y movimientos que se realicen a través del sistema de seguridad para disponer de esa información en cualquier momento. Esta parte de la arquitectura puede parecer la menos importante al ser la menos crítica durante la fase de acceso a los recursos pero es de vital importancia cuando se realizan análisis post-incidente para poder encontrar las causas raíz de una brecha de seguridad.

Fundamentalmente existen dos protocolos muy extendidos para la implementación de servicios AAA: RADIUS y TACACS+.

RADIUS

Es la versión pública y más extendida de protocolo AAA. Se trata de un protocolo cliente-servidor que proporciona los tres servicios AAA de forma centralizada y que se ha convertido en el modelo estándar de IETF.

TACACS+

Es la evolución del protocolo TACACS realizada por Cisco que permite añadir a la original autenticación de la que disponía éste de autorización y registro para así convertirlo en un protocolo AAA completo.

Laboratorio de redes (I): Conexión serial entre routers Cisco.

El objetivo del laboratorio de redes es de disponer, para finales de este año, de todo un diseño de red complejo.

Pero como por algún sitio hemos de empezar, hoy nos dedicaremos a configurar la conexión entre dos routers Cisco.

En este ejemplo hemos empleado dos imágenes de un Cisco 3725 [ c3725-adventerprisek9-mz.124-25d ].

Screen1

Deberemos añadir en las ranuras de configuración de interfaces las correspondientes que necesitamos antes de encender ambos equipos. Como necesitamos al menos un puerto serie por cada uno de los dispositivos, configuraremos convenientemente el dispositivo tal y como muestra la figura.

Screen2

Una vez iniciados los dos equipos bastará con que accedamos por consola a ambos y configuremos las interfaces serie convenientemente.

Accederemos por consola al router 1 (R1):

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int serial 1/0
R1(config-if)#ip address 192.168.0.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#clock rate 64000

Una vez configurado el router 1, pasaremos a configurar el router 2:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int serial 1/0
R2(config-if)#ip add 192.168.0.2 255.255.255.0
R2(config-if)#no shut

Es importante tener muy presente que una conexión serie es una conexión síncrona lo que explica la necesidad de definir un «clock rate» (tiempo de reloj) para sincronizar el equipo DCE, que será el que marque el sincronismo con el equipo DTE, que será el que esté a la espera de recibirlo. La decisión de que R1 sea el DCE es totalmente aleatoria y este mismo diseño podría haberse realizado siendo R2 el equipo DCE.

De esta manera, los dos routers serán capaces de comunicarse sin problemas al haber establecido una conexión serie completa:

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/21/28 ms

R2#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/32 ms

 

Herramientas de redes: ping y traceroute.

Ante cualquier anomalía de red un técnico debe actuar de forma concisa y rápida buscando aislar por completo la fuente de error.

En la mayoría de los casos el primer paso será comprobar el alcance de la anomalía y qué servicios o equipos están inaccesibles debido a ella.

Para poder obtener esta información de forma rápida y más o menos precisa todo técnico de redes dispone de dos herramientas básicas para ello: el ping y el traceroute.

Ping

PING’ el acrónimo de Packet Internet Groper, el que puede significar «Buscador o rastreador de paquetes en redes» es una utilidad que envía paquetes ICMP de solicitud y respuesta y cuya finalidad es comprobar que el equipo destino está activo y disponible. También se puede emplear para obtener la latencia (o tiempo de respuesta RTT) entre dos equipos para tener una noción del retardo existente en la conexión. [fuente: Wikipedia]

Esta utilidad suele venir instalada en la práctica totalidad de sistemas operativos/equipos de red y de ahí que ante cualquier situación problemática con una red podamos hacer uso de ella.

Para poder emplearla bajo sistemas Microsoft Windows deberemos primero lanzar una ventana de MS-DOS:

blog_pingtracert_01

Una vez en ella bastará con que empleemos el comando: ping -equipo-, siendo equipo la dirección IP o el nombre de la máquina (siempre que dispongamos de su traducción DNS correspondiente):

Si el resultado es satisfactorio la respuesta nos dirá además el tiempo de respuesta o latencia y el TTL (Time-to-live). Este último parámetro indica el número de saltos que el paquete ha realizado hasta llegar a destino, pero es un número que depende de otros factores como el tipo de conexión y que explicaremos más adelante.

blog_pingtracert_03

Si, por el contrario, el equipo no es accesible, la respuesta obtenida será la siguiente.

blog_pingtracert_04

De este modo con una única utilidad podremos obtener información acerca de la disponibilidad de determinado equipo y, por ende, de determinado servicio.

Traceroute

Traceroute es una utilidad de diagnóstico que permite seguir la pista de los paquetes que vienen desde un host (punto de red). Se obtiene además una estadística del RTT o latencia de red de esos paquetes, lo que viene a ser una estimación de la distancia a la que están los extremos de la comunicación. [fuente: Wikipedia]

En este caso lo que se realizan son llamadas a cada uno de los saltos que realiza el paquete y, por tanto, se nos informa del camino (traza la ruta) que sigue el paquete.

Mediante esta utilidad podemos comprender de forma más coherente el camino que siguen los paquetes e identificar problemas de enrutamiento, balanceo, filtado, etc.

En los sistemas MS Windows la aplicación a emplear es tracert. El procedimiento a seguir es similar, deberemos abrir una ventana de MS DOS y lanzar la aplicación: tracert -equipo-

En la respuesta veremos reflejados todos y cada uno de los saltos que realiza el equipo

blog_pingtracert_05

Si observamos, algunas líneas muestran * en lugar de valores. Esto se debe a que en ese salto nuestro equipo no ha recibido respuesta del equipo destino: hay varias razones para ello pero entre otras el equipo puede tener deshabilitadas las respuestas por motivos de seguridad.

Generalmente si realizamos esta consulta dentro de nuestra red local deberíamos poder ver todas las respuestas.

Con estas dos utilidades, un técnico de redes puede en cuestión de minutos aislar casi por completo la fuente de error de la red y de este modo enfocar todos sus esfuerzos en resolver el punto de fallo. En entornos donde existen una gran cantidad de equipos de red funcionando resulta fundamental discriminar la mayor cantidad de equipos para poder comenzar con el proceso de análisis con un número de variables reducido.