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

Categoría: Tecnología (página 2 de 7)

Información tecnológica relacionada con el IT.

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»]

Facebook compra Whatsapp por 19.000 M$

Es la noticia del día, de la semana, del mes y muy probablemente del año. 

Facebook, en un movimiento sorprendente, ha desembolsado la mayor cantidad de dinero que jamás había puesto encima de la mesa para adquirir la aplicación de mensajería instantánea Whatsapp. Estamos hablando de 16.000 millones de dólares más un extra de 3.000 más que suman la mareante cifra de 19.000 millones de euros. 

Un movimiento que me sorprende por dos motivos: la cantidad desembolsada y la necesidad estratégica.

¿Nueva burbuja?

La cifra sorprende por la cantidad de ceros. Está claro que lo que Facebook adquiere, más allá de la aplicación, es la inmensa red de usuarios que utilizan Whatsapp. Se habla de más de 450 millones de usuarios que pasarán a formar parte del ecosistema de Facebook de un modo u otro. 

Pero estamos hablando de 16.000 millones de dólares. Es mucho, muchísimo dinero. 

Si bien es cierto que llevamos ya bastantes meses hablando de la posible burbuja de las empresas de Internet todavía nada indica que la tendencia vaya a cambiar . Aunque en realidad es así com funcionan las burbujas, de un día para otro: explotan. 

Una estrategia que está por ver.

El otro punto más allá del económico que me resulta interesante es el de la estrategia empresarial que está siguiendo Facebook. 

El gigante creado por Zuckerberg dispone ya de un sistema de mensajería instantánea, su «Facebook Messenger». Disponible además en todas las plataformas: móvil, tablet, PC, etc.

¿Qué necesidad tenía de adquirir WhatsApp?

Tal vez lo que quiera es todo el pastel. Meterse en el bolsillo a la práctica totalidad de usuarios de teléfono móvil (usen o no Facebook) convergiendo ambas plataformas: la basada en su aplicación y la que hace uso de los contactos del teléfono del usuario.

 

Más si cabe ahora que alternativas como Line o Telegram parecen disponer de la estabilidad necesaria como para empezar a plantarle cara al rey del «doble check». 

 

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.

Primeros pasos con Prezi

Hace unos días, por motivos de trabajo, tuve que lidiar brevemente con la plataforma de publicación de presentaciones online Prezi.

Pese a que he oído hablar mucho de ella en los últimos años, de hecho recuerdo que algunas de las presentaciones que se realizaron en la primera edición del 49k fueron hechas mediante esta plataforma, nunca le había dado una excesiva relevancia.

Prezi es entorno de diseño y publicación de presentaciones que añade un concepto nuevo al conocido mundo dominado por PowerPoint y Keynote.

La diferencia más sustancial de Prezi es que parte de un único lienzo donde están contenidas todas las diapositivas. Mediante constantes movimientos de zoom y perspectiva es posible desarrollar conceptos muy visuales de una forma coherente e integrada. Esto ayuda bastante a una compresión global del tema que se quiere presentar dando la sensación de que todo forma parte de una misma estructura.

El principal problema que considero tiene este entorno es que en su versión gratuita la edición es exclusivamente online y, por tanto, totalmente dependiente del navegador.

Muchos habréis experimentado la desazón que produce cuando una WebApp consume muchos recursos de nuestro navegador y, por ende, de nuestro sistema.

Con Prezi esta sensación se multiplica al estar realizando una edición intensiva en un entorno fácilmente sobrecargable.

No obstante, Prezi pone a disposición de sus usuarios una versión de escritorio (sólo para Windows y Mac) previo paso por caja.

En definitiva, Prezi aparece como una alternativa a las grandes dominadoras, lo cual no está de más y además ha conseguido introducirse en este mercado mediante un modelo de negocio y unos servicios totalmente diferenciados.

Aquí tenéis un ejemplo:

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:

https://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/