Mostrando entradas con la etiqueta Telecomunicaciones. Mostrar todas las entradas
Mostrando entradas con la etiqueta Telecomunicaciones. Mostrar todas las entradas

domingo, 7 de junio de 2020

Instala el gestor de paquetes macOS Homebrew 馃嵑


        En lo personal me gusta el macOS pero a menudo ten铆a problemas para obtener aplicaciones 煤tiles de programadores diversos en ocasiones no verificados por apple, esto se debe a la naturaleza del sistema operativo que es cerrado, pero, he encontrado un gestor de paquetes por l铆nea de comandos que resuelve este problema, es sencillo y seguro de usar.

Para m谩s informaci贸n de Brew visita https://brew.sh/index_es

El proceso de instalaci贸n no puede ser m谩s simple que esto:

- Presiona Command+Space

- Busca terminal y ejecuta

- Ejecuta el comando para descargar e instalar Brew
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null y presiona ENTER.

- Si la pantalla solicita que ingreses una contrase帽a, ingresa la contrase帽a de usuario de tu Mac para continuar. 
Cuando escriba la contrase帽a, no se mostrar谩 en la pantalla, pero el sistema la aceptar铆a. 
Tan solo escribe tu contrase帽a y presione la tecla ENTER. 
Luego espera a que termine el comando.

Esto es todo para instalar el gestor.

Ahora puedes instala aplicaciones de macOS, fuentes y plugins y otro software de c贸digo no abierto.
La lista completa la encuentras aqui: https://formulae.brew.sh/formula/

Por ejemplo para instalar wakeOnLAN
brew install wakeonlan


Para instalar ipcalc
brew install ipcalc

s谩bado, 8 de agosto de 2015

T煤nel Dynamic Multipoint VPN (DMVPN) Fase II

La fase II consiste en establecer el modelo de t煤neles pero de forma din谩micos tanto en el Hub como en los Spoke, el esquema de interconexi贸n es el siguiente:


Los estados de DMVPN son:

R1:

jueves, 6 de agosto de 2015

T煤nel Dynamic Multipoint VPN (DMVPN)

Una de las principales preocupaciones y desaf铆os que pertenecen a la implementaci贸n de VPN sitio a sitio usando la topolog铆a Hub & Spoke con un gran n煤mero de sitios es la escalabilidad. Con el hecho de que la implementaci贸n de muchos t煤neles GRE sobre IPSec con un protocolo de ruteo din谩mico pueda escalar bien. Sin embargo el n煤mero de listas de acceso y de t煤neles punto a punto ser谩 dif铆cil de administrar cuando hay un gran n煤mero de sitios remotos usando completa o parcialmente la topolog铆a mallada. Adem谩s de los problemas de escalabilidad, la implementaci贸n de un gran n煤mero de VPN sitio a sitio usando la topolog铆a Hub & Spoke con un gran n煤mero de comunicaciones spoke to spoke, dar谩 lugar a una sobrecarga alta en el CPU y a la memoria del hub router porque todo el tr谩fico spoke to spoke debe transitar por el hub

En este modelo el tr谩fico de Spoke a Spoke no necesariamente debe pasar por el Spoke para ello Next Hop Resolution Protocol NBMA (NHRP) definido en el RFC 2332 es usado para el registro de direcci贸n de los spokes en las implementaciones DMVPN. Con DMVPN cualquier flujo de tr谩fico entre los routers se env铆a v铆a un t煤nel GRE, pero la caracter铆stica interesante que distingue a DMVP entre otras implementaciones de VPN es que este t煤nel GRE es un t煤nel multipunto GRE. Es decir el hub y los spokes requerir谩n un t煤nel cada uno para alcanzar una conectividad DMVPN completamente mallada.

De la informaci贸n dada es obvio que DMVPN puede proporcionar las siguientes ventajas:


  • Simplificar la porci贸n de la configuraci贸n del hub router eliminando la necesidad de configurar crypto maps, las interfaces de t煤nel, y ACL de cada spoke.

  • Los spoke routers  pueden obtener sus direcciones IP din谩micamente, por ejemplo un router de borde de Internet conectado con un enlace ADSL puede obtener su IP autom谩ticamente del ISP y entonces el t煤nel se registrar谩 con el hub usando NHRP.


Basado en el esquema de Hub & Spoke el siguiente tipo de GRE utiliza un NHS como HUB el cual establece un t煤nel din谩mico DMVPN de forma din谩mica con los SPOKE utilizando el protocolo NHRP, este ejemplo es b谩sico y no ocupa seguridad, m谩s adelante voy a subir el ejemplo con seguridad.


Para este ejemplo el esquema de interconexi贸n es el mismo que en el ejempo T煤nel GRE VPN Punto-a-Punto pero esta vez consideramos que podemos tener m谩s sitios remotos los cuales ser谩n agregados de manera din谩mica.












Los t煤neles se establecen de manera din谩mica en el Hub y de forma est谩tica en los Spoke:







T煤nel GRE VPN Punto-a-Punto

La popularidad de las VPNs ha crecido durante los 煤ltimos a帽os derivado del costo beneficio que puede proporcionar a las empresas el utilizar la infraestructura de Internet para interconectar sus redes y a flexibilidad que esto conlleva.

La implementaci贸n tradicional de GRE involucra la configuraci贸n de tunel punto a punto entre dos sitios, este tipo de soluci贸n funciona bien cuando son pocos sitios a interconectar y por consiguiente se tiene un bajo n煤mero de tuneles, el esquema de interconexi贸n clasico de esta soluci贸n se muestra a continuaci贸n:

jueves, 23 de julio de 2015

OSFP Virtual LInk

Tenemos a continuaci贸n un problema t铆pico de enrutamiento OSPF inter Area donde se hizo un mal dise帽o y el Area 0 no esta configurada adyacente al resto por lo cual se a铆sla el area que no hace el intercambio de paquetes directamente conectada al area de intercambio.

El esquema de interconexi贸n es el siguiente.

mi茅rcoles, 22 de julio de 2015

EIGRP sumarizaci贸n de rutas


EIGRP con sumarizaci贸n de rutas.

El esquema de interconexi贸n es el siguiente:


 Las rutas sin sumarizaci贸n en R1 se muestran a continuaci贸n:


OSPF Stub area

Un ejemplo simple de 谩rea stub se muestra en el siguiente ejemplo, el hecho de hacer un 谩rea stub significa que no recibe rutas inter-area o externas excepto la ruta por defecto.

El escenario es de 3 Routers interconectados entre si en Seattle, Chicago y New York respectivamente, el esquema de configuraci贸n debe cumplir con los siguientes requisitos:

  • El identificador del proceso de OSPF debe ser el mismo
  • El protocolo de ruteo no debe ser habilitado en la configuraci贸n de cada interface.
  • El 谩rea OSPF entre Seattle y Chicago no debe permitir rutas internas o externas.
  • Todo el sistema debe estar interconectado mediante el mismo protocolo. 
  • El direccionamiento de las interfaces ha sido previamente asignado.

Partiendo de estas premisas y del direccionamiento establecido el esquema de interconexi贸n es el siguiente:


lunes, 20 de julio de 2015

NAT-PT para IPv6

Network Address Translation (NAT)—Protocol Translation (PT).

NAT64 es un mecanismo que permite que hosts que solamente tienen conectividad IPv6 puedan comunicarse con hosts que solamente tienen conectividad IPv4.

Para lograr este objetivo se debe contar con un equipo de red que sea capaz de realizar una traslaci贸n de protocolos IPv4 <-> IPv6. Entre otras cosas, este mapeo debe incluir el mapeo de las direcciones de capa de red de uno y otro protocolo.

Del lado de la red solo-IPv6, las direcciones IPv4 se mapean dentro de un prefijo IPv6 el cual debe tener suficientes bits de host para mapear todo el espacio IPv4. Normalmente se utiliza el prefijo 64::ff9b/96.

Para que los hosts solo-IPv6 puedan comunicarse con los hosts solo IPv4 hace falta un componente adicional que es una traducci贸n a nivel de DNS. Este es el rol del DNS64, el cual se encarga de recibir las consultas DNS de los hosts solo-IPv6 y modificar las respuestas de tal manera de incluir registros AAAA que mapean las direcciones IPv4 dentro del prefijo NAT64.

Ambos procesos est谩n definidos en [RFC6146] y [RFC6147].

El diagrama general es:



jueves, 16 de julio de 2015

OSPF + EIGRP redistribuir rutas

Vamos a ver un caso muy particular para redistribuci贸n de rutas, en este ejemplo partimos del supuesto que tenemos un Router R4 en un sitio remoto que tiene configurado OSPF, tenemos en otro extremo Routers R1, R2 y R3 con enrutamiento EIGRP configurado entre ellos, se habilitan 2 interfaces en R4 para interconectar con el AS EIGRP entre R3 y R2 por cuestiones de contar con redundancia y requerimos lo siguiente:

  1. Habilitar enrutamiento entre los Routers sin eliminar las configuraciones previas, podemos agregar y cambiar valores por defecto.
  2. Permitir que la ruta por defecto de todos los Routers sea por medio de R4
  3. Establecer como ruta preferida para comunicar ambos sistemas mediante R3 y R4 quedando como ruta secundaria R2 y R4.
El esquema de interconexi贸n y direccionamiento utilizado es el siguiente.

martes, 16 de junio de 2015

PPPoP a trav茅s de un Cisco 871W

Recientemente fui como parte del staff de una expo a configurar la red de datos LAN y la salida a Internet el centro de exposiciones cambi贸 sus pol铆ticas de acceso a Internet y ahora el acceso lo teniamos que hacer v铆a PPPoE y prove铆an 煤nicamente el usuario y password para el acceso.

Como sabemos PPPoE (Point-to-Point Protocol over Ethernet o Protocolo Punto a Punto sobre Ethernet) es un protocolo de red para la encapsulaci贸n PPP sobre una capa de Ethernet. Es utilizada mayoritariamente para proveer conexi贸n de banda ancha mediante servicios de cablem贸dem y DSL. Este ofrece la autentificar directamente sin necesidad de tener ning煤n par谩metro IP configurado previamente.

mi茅rcoles, 13 de mayo de 2015

Configuraci贸n B谩sica eBGP


Este es el ejemplo b谩sico de iBGP en el cual se interconectan 3 sitios con su propio AS, la configuraci贸n permite que la ruta por defecto del router INET sea heredada a la tabla de ruteo de los routers ISP_A e ISP_B permitiendo la salida a internet, fue necesario configurar NAT.

El esquema de interconexi贸n es el siguiente:


mi茅rcoles, 29 de abril de 2015

Conectar Cable USB - DB9 (Consola) en Linux

Buen d铆a este tema es muy breve pero de importancia ya que para los Networkers el migrar de sistema operativo representa una adaptaci贸n de las actividades sobre las redes utilizando el nuevo entorno de trabajo, en este sentido la conexi贸n a la consola de las cajas de la red requiere en linux una configuraci贸n especial pero menos complicada que en Windows o Mac, a continuaci贸n explico los pasos.

El primer paso es descargar la aplicaci贸n "minicom" (para Ubuntu el comando es el siguiente)

 apt-get install minicom

Configuramos minicom

 minicom -s


Para confirmar el puerto serial debemos conectar el adaptador usb-db9 a algun puerto USB, ahora usar el comando "dmesg | grep USB"  y ver algo como lo siguiente.

[14157.468359] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
Y eso es todo.



viernes, 6 de febrero de 2015

Caracter铆sticas OSPF

Este es un Laboratorio de OSPF que pretende comprender el uso de las ar茅as y los tipos de LSA que maneja en la configuraci贸n.

Est谩 es la topolog铆a de red que he usado.


lunes, 29 de diciembre de 2014

Habilitar adaptador USB a Serial en OS X 10.9 Mavericks

Bueno este es un tema breve pero que me ha tomado mucho tiempo ya que desde que compr茅 el adaptador hace ya unos meses no hab铆a conseguido que funcionara de forma estable en mi mac, no fue hasta que por cuestiones de downgrade tuve que instalar desde cero el OS X 10.9 Maverick fue necesario reinstalar el controlador pero esta vez logre hacerlo funcionar estable.

El adaptador USB a DB9 que compr茅 es  Tripp Lite USB to Serial DB9M Adapter (U209-000-R) sin embargo por lo que he podido leer este procedimiento tambi茅n sirve para convertidor Usb/db9 Manhattan.

mi茅rcoles, 26 de junio de 2013

Problema para conectar mi VPN a trav茅s de TELMEX

Tengo un servicio Infinitum de TELMEX el cu谩l no me permitia conectar a mi empresa usando el cliente VPN de Cisco (Cisco VPN client), mi modem es un Technicolor TG582n http://wiki.aa.org.uk/Category:Router_TG582N.


El error es "Secure VPN Connection terminated locally by the Client. Reason 412: The remote peer is no longer responding:


martes, 31 de enero de 2012

Sistema aut贸nomo (ASN) 32 bits - LACNIC/Politicas


Cito textual. <<

ASN de 32 bits

Introducci贸n:

Desde el 1 de enero de 2007, al igual que los dem谩s RIRs, LACNIC est谩 asignando a sus miembros N煤meros de Sistemas Aut贸nomos (ASNs) de 32 bits.

Hasta ese entonces los ASNs asignados eran de 16 bits con lo que la cantidad m谩xima disponible era de aproximadamente 65 mil ASNs.

Anticipando un posible agotamiento del espacio de ASNs de 16 bits, se iniciaron en 2001 los primeros estudios y propuestas para expandir el formato del ASN para 32 bits.

El trabajo concluy贸 en 2007 con la publicaci贸n de un documento de la IETF (Internet Engineering Task Force), llamado RFC 4893. Este documento indica el nuevo formato de ASN, su utilizaci贸n en protocolos de ruteo como el BGP y tambi茅n su interacci贸n con otros sistemas y protocolos que todav铆a no han sido actualizados para soportar el nuevo formato.

Desde esa fecha, IANA asigna a los RIRs bloques de ASN de 32 bits para su subsecuente asignaci贸n dentro de cada regi贸n.


Pol铆tica:

Ya en el a帽o 2006 se estaba discutiendo a nivel de los RIRs propuestas de pol铆ticas para asignaci贸n de ASNs de 32 bits. En ellas se mantienen los criterios en cuanto a necesidad de que la organizaci贸n sea "multihomed" o de que tuviera una pol铆tica 煤nica de ruteo para justificar as铆 la asignaci贸n. 
Esa pol铆tica para asignaci贸n de ASN incluye tambi茅n criterios para la transici贸n entre la asignaci贸n de ASN 16 bits para la de 32 bits.

La pol铆tica regional adoptada en LACNIC (que es similar a las de otras regiones) establece que en las solicitudes de ASNs realizadas a partir del 1 de enero de 2007 se debe indicar expresamente que se desea un ASN de 32 bits. En caso contrario la asignaci贸n por defecto ser谩 de un ASN 16 bits.

De acuerdo con esta misma pol铆tica, ese criterio debe ser modificado a partir del 1 de enero de 2009. As铆, a partir de esa fecha, las solicitudes realizadas considerar谩n por defecto la asignaci贸n de ASNs de 32 bits, mientras que ASNs de 16 bits ser谩n asignados 煤nicamente cuando sean expl铆citamente solicitados.


Situaci贸n Actual:

Es importante recordar que por m谩s que a煤n existen ASNs de 16 bits disponibles, a partir de enero de 2009 solamente ser谩n asignados a quienes explicitamente lo soliciten.



Especialmente cuando como es sabido, existen sistemas y equipos que no soportan ASNs de 32 bits, lo que puede afectar a las organizaciones que est茅n optando por una pol铆tica de ruteo redundante, para lo que necesitar谩n de un ASN y, en algunos casos, de nuevos equipos de enrutamiento.

Entonces si bien no se trata de un problema urgente, pues las proyecciones actuales indican que a煤n existen ASNs de 16 bits para 2 o 3 a帽os m谩s, es un aspecto al que se le debe prestar especial atenci贸n.
Ante esta situaci贸n, creemos importante recomendar que en la planificaci贸n y proyectos de nuevas redes se considere la posible necesidad de utilizar ASNs de 32 bits, lo que puede repercutir en las decisiones de compra de nuevos equipos o sistemas de redes.

Se recomienda tambi茅n a los administradores de redes ya en operaci贸n que verifiquen junto a los proveedores de sus equipos y sistemas, el soporte de ASN de 32 bits en futuras versiones de sus productos.

Si bien los mecanismos para transici贸n son simples y permiten que sistemas m谩s antiguos funcionen con estos nuevos ASN sin necesidad de actualizaci贸n, es importante el soporte a esa nueva versi贸n del ASN para contar con todas las herramientas a la que los administradores est谩n habituados hasta este momento.

Por 煤ltimo, existe en la comunidad global un debate importante sobre el tipo de representaci贸n para los ASNs de 32 bits. Hasta el momento la representaci贸n elegida consiste en la denominada “as-dot2” donde los 32 bits se representan de la siguiente manera: <valor de 16 bits m谩s significativo en formato decimal>.<valor de 16 bits menos significativo en formato decimal>. La utilizaci贸n de esta representaci贸n ha sido cuestionada pues dificulta el trabajo con expresiones regulares ya construidas en diferentes herramientas, promovi茅ndose en cambio la representaci贸n “as-plain” donde se toma simplemente el valor decimal de ASN (dentro del rango decimal 0 – 4294967295).
Como forma de contribuir al debate que est谩 ocurriendo en estos momentos, en LACNIC creemos importante recibir comentarios de parte de la comunidad de nuestra regi贸n respecto de este tema.

>>Ahora bien.

Para conocer el ASN de un ISP utilizar la siguiente l铆nea de comando en un terminal linux:

Para el ejemplo solicitamos el ASN del ISP al cual pertenece la direcci贸n IP 201.151.157.1

:~$ whois -h whois.cymru.com 201.151.157.1
AS      | IP               | AS Name
11172   | 201.151.157.1    | Alestra, S. de R.L. de C.V.


El comando whois es un buscador que consulta un elemento en la base del RFC 3912.
La opci贸n -h indica que la consulta se realizara conectando con algun servidor, en este caso whois.cymru.com el cu谩l es un servidor especializado en hacer la conversi贸n IP a ASN.
Finalmente se ingresa la direcci贸n IP a la cual se requiere hacer lookup.

s谩bado, 3 de diciembre de 2011

Pi-hole + OMV

     Antecedentes      Estos son los pasos para el caso particular, instalar   Pi-hole como DNS para nuestra red local en nuestra Raspberry ...