Posts in "Networking"

Telefónica migrará su infraestructura móvil a SingleRAN

Telefónica ha decidido dar el paso y renovar toda su infraestructura de telecomunicaciones a nivel nacional.
Esto implica, según comentan en Expansión.com, la sustitución de 18.000 emplazamientos donde tienen situadas las antenas de Ericsson, Nokia Solutions & Network (NSN) y, en menor medida Alcatel.

El objetivo de este cambio es migrar el actual despliegue que comprende antenas GSM (2G), UMTS(3G) y LTE(4G) a una tecnología conocida como Single RAN que va a permitir dar servicio de todas estas tecnologías simultáneamente.

Gracias a esta nueva implementación, más eficiente enérgitcamente y preparada para trabajar con las futuras frecuencias a las que podrá operar Telefónica una vez el Gobierno entregue la concesión, Telefónica se pone a la cabeza en infraestructura de comunicaciones móviles y da un paso adelante para ofrecer un servicio integral a sus usuarios.

Sin lugar a dudas es un movimiento positivo que hace más evidente el futuro de las telecomunicaciones a nivel de usuario en el que la convergencia de servicios es ya una realidad y que además abre un abanico enorme de posibilidades a desarrolladores de servicios y aplicaciones que van a disponer de una plataforma de distribución que les va a permitir proveer sus soluciones al cliente final a unas velocidades inconcebibles hace unos pocos años.

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

MPLS – Introducción

MPLS (Conmutación de etiquetas multiprotocolo) es un mecanismo empleado en redes de telecomunicaciones de alto rendimiento que es capaz de enrutar información de una red a otra basándose en etiquetas locales en lugar de emplear largas direcciones de red como lo hacen la mayoría de protocolos de enrutamiento.

Su uso está ampliamente extendido en entornos de provisión de servicios debido a su rapidez de conmutación y una serie de ventajas añadidas que convierten a MPLS en la solución idónea para dar respuesta a las necesidades que tienen estos entornos: grandes cantidades de redes, anchos de banda grandes, necesidad de minimizar el retardo y el jitter, etc.

Algunas de estas características son:

Multiprotocolo

MPLS proporciona el servicio de transporte conmutado extremo a extremo y es independiente del protocolo que se esté empleando tanto a nivel 2 como a nivel 3 incluyendo tecnologías de acceso como: T1/E1, ATM, Frame Relay, y DSL.

Traffic Engineering

Además, MPLS incluye su propio sistema de enrutamiento que va a permitir al ingeniero de redes modificar dependendiendo de las necesidades en cada momento haciendo uso de las etiquetas así como de ciertos atributos como medio para condicionar el camino empleado.

Túneles con RSVP

Una de las características más interesantes de MPLS es la creación de rutas dinámicas a través de su red que, a diferencia de otros IGPs (OSPF, EIGRP, IS-IS), sí que tienen en cuenta el estado actual de los enlaces.

Como muchos sabéis, OSPF o EIGRP por ejemplo, utilizan unos parámetros que caracterizan a cada uno de los enlaces o saltos para así decidir cuál es la ruta más óptima para alcanzar el destino. El problema de este mecanismo es que es estático: la definición de las características del enlace se realiza en la configuración de los equipos.

Esto puede dar lugar a la sobreutilización de determinados enlaces con buenas características y la infrautilización de enlaces alternativos con características inferiores.

Con MPLS esta situación se resuelve dado que emplea RSVP para establecer un camino basándose en el estado actual de la red. Asegura así que el ancho de banda que requiere la comunicación es, de hecho, el disponible y lo reserva para crear un túnel para esa comunicación.

Calidad de servicio

Traffic Engineering está muy relacionado con QoS (usa RSVP para establecer los túneles extremo a extremo) lo que va a permitir al ingeniero de redes integrar fácilmente mecanismos de QoS (Quality of Service) sobre el tráfico MPLS.

MPLS TE dispone de una extensión que permite implementar DiffServ Services

 

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

Laboratorio de Redes #101 – BGP y OSPF – Redistribución 1

Hoy os traigo el primer capítulo de esta serie de laboratorios de routing encaminados a explicar de una forma más práctica cómo configurar equipos Cisco con protocolos de enrutamiento dinámico.

En esta primera entrega os muestro la topología que voy a utilizar, las distintas direcciones IP de los equipos a configurar y una primera parte en la que configuraré OSPF y BGP comprobando así mismo su funcionamiento.

A lo largo de los siguientes episodios buscaré desarrollar por completo la topología para finalmente proporcionaros los archivos del laboratorio en GNS3 para que podáis jugar con ellos cuanto os plazca.

[su_youtube url=»https://www.youtube.com/watch?v=7d7IMTEAFLI»]

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.

LAB: Configuración Básica de OSPF

Dado el siguiente escenario:

LAB_1

Tenemos dos routers asociados a dos redes LAN independientes que no tienen conectividad entre sí. El objetivo de este laboratorio será definir un área OSPF común en el que los routers intercambien las rutas a su redes internas a través de la misma.

Para ello configuramos en primer lugar el router de Valencia:

Empezaremos definiendo las interfaces. Al tratarse de un router de la serie 1700 sólo disponemos de una interfaz FastEthernet que será la que emplearemos para conectarnos con el router del ISP. Para emular la subred de Valencia asignaremos la IP del rango 10.1.0.0/16 a una interfaz Loopback que hará las funciones de equipo dentro de la subred.

interface FastEthernet0
 description ENLACE CON MADRID
 ip address 10.0.0.1 255.255.255.252

interface Loopback0
 ip address 10.1.0.1 255.255.0.0
!

Realizaremos el mismo proceso en el router de Madrid:

interface FastEthernet0
 description ENLACE CON VALENCIA
 ip address 10.0.0.5 255.255.255.252

interface Loopback0
 ip address 10.1.0.1 255.255.0.0

Y por último el router del ISP dispondrá de dos enlaces FastEthernet dedicados a cada sede:

interface FastEthernet0/0
 description ISP TO VALENCIA
 ip address 10.0.0.2 255.255.255.252
!
interface FastEthernet1/0
 description ISP TO MADRID
 ip address 10.0.0.6 255.255.255.252
!

Una vez configurados los equipos podemos comprobar que desde la LAN de Valencia no se alcanza la LAN de Madrid.

VALENCIA#ping 10.2.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Si observamos la tabla de enrutamiento veremos cómo, como es obvio, el router de Valencia sólo puede alcanzar las redes a las que está conectado.

VALENCIA#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/30 is directly connected, FastEthernet0
C       10.1.0.0/16 is directly connected, Loopback0

Para solucionar esta situación haremos uso de un protocolo de enrutamiento dinámico: OSPF.

Debemos definir un Área OSPF en la que los tres dispositivos intercambien rutas. Como el Router ISP no tiene rutas propias que intercambiar nos servirá exclusivamente de pasarela entre Valencia y Madrid.

Configuraremos de forma análoga OSPF tanto en Valencia como en Madrid.

VALENCIA
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.3 area 0
 network 10.1.0.0 0.0.255.255 area 0

MADRID
router ospf 1
 log-adjacency-changes
 network 10.0.0.4 0.0.0.3 area 0
 network 10.2.0.0 0.0.255.255 area 0

Por último configuraremos OSPF en el ISP y observaremos como se producen las adyacencias oportunas.

router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.3 area 0
 network 10.0.0.4 0.0.0.3 area 0

Una vez el proceso converge, las rutas de todos los dispositivos han sido compartidas y nos encontramos con que las tablas de enrutamiento de los 3 routers han sufrido una actualización gracias al proceso OSPF. Esto nos va a permitir tener interconectividad entre las redes LAN de Madrid y Valencia.

VALENCIA#ping 10.2.0.1

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

ISP#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.0.0.8/30 is directly connected, FastEthernet2/0
O       10.2.0.1/32 [110/2] via 10.0.0.5, 00:07:28, FastEthernet1/0
O       10.1.0.1/32 [110/2] via 10.0.0.1, 00:07:28, FastEthernet0/0
C       10.0.0.0/30 is directly connected, FastEthernet0/0
C       10.0.0.4/30 is directly connected, FastEthernet1/0

Podéis descargaros la topología para GNS3  con la configuración aplicada desde el siguiente enlace:

http://www.sergiomadrigal.com/labs/OSPF1.zip

Introducción a la QoS

Con el aumento considerable de servicios proporcionados a través de las redes llegó un momento que se observó que existían dos recursos limitados: el ancho de banda y la latencia. 

Había llegado el momento de gestionar eficientemente estos dos recursos si se quería seguir prestando servicios de calidad puesto que se hacía inviable su aumento infinito. 

Parte de la solución para esta administración eficiente de recursos fue la llegada de la calidad de servicio o, en sus siglas en inglés: QoS. 

El mecanismo de la QoS es tan simple como efectivo. Entendemos que no todos los tráficos generados en nuestro ordenador tienen un comportamiento y un nivel de criticidad equivalente. No es lo mismo que una página web nos tarde un segundo más en cargar que el hecho de que una conversación a través de Skype tenga ese mismo retraso de un segundo. Para solucionar este problema se decidió priorizar el tráfico en función de su sensibilidad ante determinados factores inherentes a una red de computadores: latencia, pérdidas de paquetes, límite de ancho de banda, etc. 

Esta priorización se puede llevar a cabo en muchos niveles del modelo OSI pero la que aquí nos ocupa se realiza en el nivel 3, es decir, en los routers. 

¿Por qué? 

Fundamentalmente porque son elementos presentes en toda la cadena de comunicación desde el emisor de la información al receptor. Y aquí aparece la característica más importante a la hora de aplicar calidad de servicio a nuestro tráfico: todos y cada uno de los dispositivos que formen parte de la comunicación deben implementar QoS. En el momento en el que uno solo de estos dispositivos no tenga configurados los parámetros adecuados la QoS dejará de tener efecto. 

Esto es obvio si pensamos en que si nuestro objetivo es darle prioridad máxima a un tipo de tráfico, todos los dispositivos encargados de encaminar ese tráfico deben estar al tanto de esta situación. Si uno de ellos no lo hace, se producirá un retraso no previsto, una pérdida no deseada y, por tanto, una merma de la calidad del servicio. 

¿Cómo se prioriza?

La forma que tiene la QoS de ponerse a funcionar es tan simple como añadir una cabecera a los paquetes IP en la que se indique su nivel de QoS definido. La complejidad, esto es, el análisis y toma de decisiones, lo realizarán los routers dependiendo del tipo de QoS definida en ellos. La forma de decidir qué tráfico se marca con determinadas etiquetas se debe configurar y puede atender a variables de nivel 3: redes o subredes, vaiables de nivel 4: puertos/protocolos, interfaces específicas, etc. 

En la actualidad la QoS está muy presente en las empresas dado que debido a la convergencia de servicios, tráficos de voz, vídeo y datos suelen compartir medios de comunicación y es vital separar y dotar de la prioridad adecuada a cada uno de estos servicios.

Existe un interesante artículo que explica el tipo de marcado que se realiza a los paquetes IP en el siguiente enlace: http://diecarvi.wordpress.com/2013/05/05/understanding-qos-numbering/