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

20 de abril de 2019

768k day

He visto varias publicaciones, algunas de ellas bastante confusas, respecto de un nuevo hito en el desarrollo de Internet que debiera alcanzarse dentro de los próximo 30 días según prevén algunos especialistas: el 768k Day.
Como he notado cierta imprecisión en algunas de estas publicaciones me pareció conveniente revisar algunos aspecto desde una perspectiva más técnica, para comprender de qué se trata.

Algo sobre Internet
Internet es hoy una realidad muy diferente de lo que se concibió inicialmente.
En sus inicios a fines de los años '60 no sólo la población mundial era menos de la mitad de la población actual sino que el acceso a la tecnología y a la conectividad era claramente minoritario. Nadie podía en aquellos inicios anticipar que hoy Internet contaría con más de 4.200.000.000 de usuarios conectados y más de 2.400.000.000 de usuarios en una sola red social (Facebook).
Uno de los cimientos sobre los que se asienta este crecimiento actual de Internet es el protocolo de direccionamiento puesto en operación a inicios de la década de los '80, el protocolo IPv4 cuyo agotamiento se anunció en el año 1994 y que está aún en proceso de reemplazo por IPv6 (al momento de escribir este post, casi el 75% del tráfico de Internet aún circula utilizando IPv4).
El otro, no menos relevante, es BGPv4. El protocolo de enrutamiento que sostiene toda la infraestructura de Internet y que permite localizar y alcanzar cualquier red remota (IPv4 o IPv6) dentro de la red global.

Algo sobre BGPv4
BGPv4 es el protocolo de enrutamiento diseñado específicamente para mantener el enrutamiento de Internet.
  • Apunta primariamente a la estabilidad de las tablas de enrutamiento.
  • Requiere muchos ciclos de procesamiento y espacio de memoria RAM.
    Es un protocolo intensivo en el uso de recursos.
  • Sobre él descansa toda la infraestructura de enrutamiento de Internet.
  • Transporta tanto rutas IPv4 como IPv6.
  • Mantiene tablas independientes para el enrutamiento IPv4 y el enrutamiento IPv6.
  • Propone la mejor ruta a cada destino posible a la tabla de enrutamiento del dispositivo.
Y aquí está la base del "problema".
Las tablas TCAM en las que se mantienen las tablas de reenvío rápido del tráfico tienen un tamaño limitado.

Un primer antecedente: 512k Day
El 512k Day tuvo lugar el 12 de agosto de 2014.
En ese día las tablas TCAM de los routers responsables del mantenimiento del enrutamiento de Internet alcanzaron el límite del espacio reservado para el mantenimiento de rutas IPv4 a diferentes destinos: 524.288 registros o rutas (512k). Hasta ese momento el espacio asignado se consideraba más que suficiente y no se advirtió que las tablas TCAM estaba llegando a su límite.
En esa fecha Verizon publicó 15.000 nuevas rutas BGP lo que provocó que las tablas de enrutamiento superaran rápidamente y sin previo aviso el límite que tenían asignado. Como consecuencia de esto los dispositivos de los principales proveedores de conectividad de Internet comenzaron a presentar dificultades para actualizar sus tablas de enrutamiento.
Esto requirió en algunos casos el reemplazo de hardware, pero en la mayoría se solucionó con una actualización de sistema operativo o firmware para ampliar la porción de memoria TCAM asignada para mantener la tabla de enrutamiento global.

Ahora, el 768k Day
En el año 2014, cuando se decidió ampliar la porción de memoria asignada a las tablas de enrutamiento IPv4 la mayoría de los administradores siguieron la recomendación que se hizo en el momento y que sugería llevar esa capacidad hasta 786.432 registros (768k).
Ahora, los especialistas que siguen la evolución del enrutamiento de Internet acaban de realizar una advertencia el pasado 17 de abril debido a que las tablas de enrutamiento IPv4 han alcanzado los 767.392 registros.
Una cifra nuevamente próxima al límite establecido.
El estado actual puede sintetizarse en estos números:
  • 767.392 prefijos IPv4.
  • 57,37% son prefijos /24.
  • 64.222 sistemas autónomos en total, de esos 47.607 están publicando solamente prefijos IPv4.
Los especialistas estiman que al ritmo actual de crecimiento de las tablas, en los próximos 30 días se alcanzará el límite de los 768k prefijos. Pero más allá del conteo de prefijos, esperan que no provoque inconvenientes globales como ocurrió en el año 2014.
La mayoría de los grandes proveedores de conectividad tienen el equipamiento adecuado, están prevenidos y pueden tomar las medidas necesarias para evitar inconvenientes; sin embargo, es de esperar que proveedores de servicios locales, pequeños, y algunas empresas u organizaciones que no están preparados se vean afectados.

Para tener en cuenta:
  • Los dispositivos obsoletos deberán ser reemplazados con equipamiento nuevo que permite el ajuste necesario de las tablas TCAM.
  • Los ajustes de las tablas TCAM son posibles en la medida en que no se esté utilizando todo el espacio reservado para rutas IPv6 (la tabla TCAM es físicamente una única tabla que se utiliza para almacenar tanto rutas IPv4 como rutas IPv6, la tablas de rutas IPv6 son mucho más cortas).
  • Los cambios de configuración de las tablas TCAM requiere el reinicio de los dispositivos.
  • No se cuenta con información que permita estimar la cantidad y ubicación de los routers que puedan ser afectados por esta situación.


Podés participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


6 de marzo de 2018

Estado de IPv6

Periódicamente vuelvo a encontrarme con diferentes publicaciones en las que se pone en dudas o se cuestiona la implementación de IPv6. Incluso algunas que siguen considerándola como una propuesta a futuro que podría o no darse.
Ya muchas veces he abordado el tema en este blog, incluso he publicado un manual con los conceptos básicos de IPv6. Pero evidentemente es necesario cada tanto volver sobre el tema.

La implementación de IPv6 no es una posibilidad, es una realidad que no podemos desconocer. Hay mucha información disponible sobre el tema.

La implementación al día de hoy
Como dije, IPv6 no es un proyecto a futuro sino una tecnología ya implementada cuya penetración es creciente cada día.
Así lo muestra la información disponible.

Un ejemplo.
Google publica en línea el porcentaje de tráfico de sus data centers que utiliza IPv6. Este es el reporte al día de hoy que, como podemos ver, muestra que el 21,09% del tráfico de los data centers de Google es tráfico IPv6 nativo:


Esta información está disponible en línea para quien quiera consultarla en este enlace.

Si lo que queremos es conocer la disponibilidad de conectividad IPv6 a nivel global, este mapa puede servir de primera aproximación:


Una mirada rápida nos permite verificar que el despliegue actual está centrado en América del Norte, Brasil, Europa, India, Japón, Australia y otros países asiáticos. El país con mayor nivel de adopción en este momento es Bélgica con el 62,59% de sus usuarios conectados utilizando IPv6.

Se puede acceder a la información detallada, país por país, desde este enlace.

¿Qué pasa en América Latina?
Como muestra el mapa global, si bien América Latina no se encuentra a la cabeza de la implementación global, tampoco está a la cola de la misma. En los últimos años varios países han disparado sus procesos de adopción

La vista regional del estado de adopción está volcada en este mapa en el que la intensidad del color verde indica un porcentaje creciente de usuarios conectados a IPv6.


Si consideramos el porcentaje de usuarios conectados con IPv6 un índice adecuado de evaluación del proceso, el líder en la región es entonces Uruguay con un 28,4% de sus usuarios conectados a la red IPv6.

Claro que por sus dimensiones, población y peso en la región no podemos ignorar a Brasil que se presenta con un 23,5% de sus usuarios conectados a IPv6.

Lo que es posible verificar de la observación de la información histórica de implementación en la región es que la misma se ha comenzado a desarrollar con mayor intensidad a partir del año 2015.

Esto es para empresas, ¿no para conexiones domiciliarias?

Este es otro prejuicio falso respecto a la implementación de IPv6.
No hay un Internet corporativo y otro hogareño. Claro que todo depende de nuestro proveedor de acceso.
Pero como un ejemplo, yo estoy en este momento utilizando una conexión hogareño de cable módem, y estoy conectado utilizando IPv6:


Y no se trata solamente de recibir direccionamiento IPv6 global unicast, sino que también opero utilizando IPv6 como primer opción:


Si querés saber si estás verdaderamente operando en la red IPv6 hay varios sitios que permiten verificar esto.
Uno de ellos es el sitio de verificación en línea dispuesto por Google:


También es posible utilizar servicios en línea con un análisis más detallados como el de IPv6 Test:


¿Qué debemos esperar a futuro?

A futuro debemos esperar un despliegue creciente de IPv6. Tanto en el ámbito corporativo como en el hogareño.


  • Hace ya tiempo que se han agotado las direcciones IPv4 para seguir creciendo.
  • El despliegue de IoE es una realidad que ya está instalada y sigue creciendo.
  • El requerimiento de direccionamiento IP global es consecuentemente creciente.
  • La respuesta para los requerimientos actuales de entonces IPv6.
Podemos discultir la velocidad con la que se realiza el despliegue, pero ya no es posible poner en dudas que se ha de hacer y que debemos ponernos en esta línea de trabajo.
Para quienes mayores precisiones sobre el crecimiento, hay un sitio que hace proyecciones para el despliegue de IPv6 a nivel global y por países. De acuerdo a vyncke.org el despliegue previsible para los próximos 2 años, a nivel global, es el siguiente:


Poner en dudas la implementación de IPv6 parece, entonces, un acto de ignorancia. La pregunta, creo, no es ya si IPv6 se implementará o no sino cuándo la implementaremos y si estamos listos para hacerlo.

Enlaces útiles:



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


13 de febrero de 2017

BGP para CCNA

BGP es un protocolo de enrutamiento robusto y escalable diseñado para responder a las necesidades complejas del enrutamiento de Internet.
El protocolo utiliza un paradigma de enrutamiento salto por salto. Cada router BGP solamente puede publicar a los sistemas autónomos vecinos únicamente aquellas rutas que él mismo utiliza.

Sus características más destacadas son:

  • Actualizaciones utilizando TCP puerto 179.
  • Luego de negociar la sesión TCP 2 dispositivos se denominan peer routers o vecinos.
  • Una vez negociada la sesión ambos vecinos intercambian su tabla de enrutamiento completa.
  • Luego del intercambio inicial las actualizaciones son incrementales, solamente cuando hay cambios.
  • Los vecinos intercambian mensajes keepalive periódicos para mantener activas las sesiones.
  • Métrica compleja basada en atributos.
  • Pensado para el intercambio de rutas entre redes muy grandes.
  • ID en la tabla de enrutamiento: B
  • Recibe la denominación de eBGP el intercambio de información de enrutamiento entre dispositivos peer que pertenecen a diferente sistema autónomo.
  • La denominación de iBGP corresponde al intercambio de rutas entre dispositivos peer que pertenecen al mismo sistema autónomo.
  • Distancia Administrativa por defecto:
      Rutas eBGP  20
      Rutas iBGP  200
  • BGP Router ID: 32 bits (4 bytes).
  • Es un protocolo de vector ruta: Su paradigma de enrutamiento se basa en la distancia entre origen y destino ponderada salto por salto.
  • Cada dispositivo establece y mantiene adyacencia con sus vecinos BGP.
       No hay un mecanismo de descubrimiento de vecinos.
       Los vecinos deben ser declarados explícitamente por configuración.
       Antes de establecer una relación de vecindad se negocia un circuito TCP sobre el puerto 179.
       Para mantener la relación de vecindad es necesario mantener activo el circuito TCP.
       Para detectar una relación de vecindad activa se envían keepalives periódicos.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


14 de agosto de 2016

Free WiFi

Un tema recurrente de consideración en el despliegue de acceso inalámbrico a Internet es el de las zonas WiFi libres.
Si bien es un concepto extendido no es un concepto uniformemente aceptado y que tiene diferentes manifestaciones. Por lo que me parece interesante aportar algunos elementos para el debate.
  • En mi consideración hay una primera dificultad que surge de confundir acceso gratuito con acceso sin condiciones.
    Desde mi perspectiva los accesos públicos y gratuitos a Internet no deberían ser sin condiciones ya que las infraestructuras públicas de comunicaciones no debieran estar disponibles para un uso abusivo de las mismas como puede ser la generación de spam o ataques de diferente tipo a objetivos conectados a Internet.
    Es por esto que creo importante incorporar mecanismos de autenticación en este tipo de accesos, mecanismos que obliguen a identificar de alguna manera al usuario y que permitan en consecuencia aplicar mecanismos de limitación y control de ese acceso. En muchos casos el solo requerimiento de autenticación ayuda a favorecer el uso responsable del recurso.
  • ¿Cuál es la solución para asegurar entonces estos accesos públicos?
    En primer lugar debiera ser un acceso basado en autenticación de usuario. Por lo tanto NO un sistema de PSK, con clave uniforme. Este tipo de autenticación es quizás suficiente para redes de acceso hogareñas pero no para redes públicas.
    Para implementar autenticación de usuario en redes inalámbricas sin demasiada complejidad hoy es posible utilizar portales web. Es una solución muy extendida, disponible en múltiples plataformas y relativamente sencilla de implementar.
    Otra opción podría ser implementar IEEE 802.1X, aunque en este caso la propuesta requiere un nivel de elaboración más complejo pero siempre posible.
  • Otro punto de discusión en estos servicios es la necesidad o no de cifrar el tráfico de los usuarios para asegurarlo.
    En este sentido creo que hay que tener en cuenta que se trata de acceso a Internet y por lo tanto de una red pública. Cifrar el trayecto inalámbrico de la comunicación es irrelevante cuando luego la comunicación continúa sin ningún tipo de protección. Las prevenciones de seguridad debieran provenir del hecho de encontrarse en una red pública, no por tratarse de un acceso inalámbrico.
    En este sentido, el tráfico de datos sensibles no debiera utilizar redes públicas, y si lo hace, debe tomar sus propios recaudos e implementación de seguridad. Para eso es posible levantar desde el cliente túneles basados en IPsec, SSL o semejantes pero entonces ya no es una definición del acceso.
    En mi opinión este recaudo de seguridad es responsabilidad del usuario que es propietario de los datos antes que de quien provee el acceso a una red pública.
  • Un punto no secundario es el tema de educación en el uso de sistemas de comunicaciones públicos como es Internet. Y digo Internet y no sólo las redes sociales, porque las características están dadas por el medio mismo: Internet es una red pública, no privada. La confidencialidad de las comunicaciones privadas sobre una red pública son responsabilidad de quienes participan de ello.
    Para esto es necesario que hoy todo ciudadano tenga conciencia de la potencialidad e infraestructura a la que accede cuando se conecta a Internet; sepa distinguir los distintos tipos de comunicación que se dan; comprenda la diferencia entre datos, información y conocimiento; entienda que no toda información a la que accede es necesariamente verdadera o precisa y por lo tanto debe evaluar su origen o fuente antes de prestarle credibilidad; asuma la responsabilidad de propagar información en la red y sea capaz de realizar un uso responsable de la misma.
En un tiempo en la escuela básica se enseñaban las reglas básicas de urbanismo y etiqueta que le permitían a cualquier ciudadano (sin importar su nivel social) desenvolverse de un modo aceptable en la sociedad. Hoy buena parte de esa dimensión social de la vida del ciudadano se ha desplazado a Internet que también tiene su propia "netiquette", pero que desafortunadamente muchos ignoran.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


30 de julio de 2016

Internet of Everything





Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


26 de agosto de 2015

IoE y las redes inalámbricas

Mucho se habla de Internet of Everything (IoE), la evolución de Internet en la que se interconectan personas, objetos, procesos y datos. Pero más allá de las posibilidades y realidades que se abren están los desafíos técnicos.
Dar base tecnológica a esta nueva Internet requiere el ajuste de muchos elementos: desarrollo de sistemas de sensores y aplicaciones, transporte, procesamiento y almacenamiento de grandes volúmenes de datos, conectividad, seguridad, etc. Por eso hay tecnologías de networking que adquieren nuevo relieve, como es el caso de RFID, IPv6, seguridad y conectividad inalámbrica. Esto significa adecuación de tecnologías a nuevos usos, y entrenamiento y capación para incorporar los conocimientos y habilidades necesarios para implementarlas y gestionarlas.

Tecnologías de conectividad inalámbrica
En este post quiero centrarme en las tecnologías de conectividad inalámbrica disponibles.
Un elemento clave de IoE es el despliegue de redes de sensores (WSN - Wireless Sensor Networks) para la recolección de información en línea que luego ha de ser procesada para generar reportes o impactar en procesos automatizados. 
Estas redes de sensores mayoritariamente utilizan conectividad inalámbrica para enviar los datos hacia los puntos de procesamiento. Para esto en la actualidad se utilizan diferentes tecnologías y esa multiplicidad constituye un problema. 
Las tecnologías actualmente desplegadas con este propósito son IEEE 802.15.4 (LR-WPAN), Zigbee, 6LoWPAN, Bluetooth (802.15.1), WiFi (IEEE 802.11) o soluciones propietarias. También se utilizan soluciones móviles como GPRS o EDGE.
Esta variedad de tecnologías se debe a la búsqueda en cada caso una solución adecuada para lograr la conectividad necesaria pero también genera la necesidad de una estandarización que permita cubrir los diferentes requerimientos y reducir los costos.
Una de las tendencias en el proceso de estandarización es la adopción de soluciones 4G como UMTS y LTE, y la proyección a 5G.

¿IEEE 802.11 no es una solución?
La aprobación de 802.11ac introdujo una tecnología inalámbrica de bajo costo y alto ancho de banda. Sin embargo aún tiene limitaciones importantes en función de los requerimientos del despliegue de WSN: No está adaptada a las necesidades de ahorro de consumo de energía de los sensores, y por otra parte, al operar sobre la banda de 5 GHz su radio de cobertura es limitado y requiere de nodos intermedios con una arquitectura compleja para asegurar la cobertura de superficies extensas.
Sin embargo, desde el año 2010 se está trabajando en el desarrollo de un nuevo estándar: 802.11ah que debería dar respuesta a estas limitaciones:
  • Opera en la banda de 900 MHz que es una banda no-licenciada con poca congestión y mucho mayor penetración (alcance).
  • Se estima un alcance de hasta 1000 metros en exteriores.
  • Permitirá la asociación de más de 8.000 dispositivos a un único access point (las tecnologías actualmente en uso permiten hasta 256 asociaciones).
  • Se está trabajando sobre tasas de transmisión de al menos 100 Kbps (las redes de sensores no requieren mucho ancho de banda).
  • Está preparado para topologías de un único salto.
  • Tiene un consumo de energía muy bajo.
  • Es además una solución de bajo costo.
De esta forma se espera superar las limitaciones actuales de las redes 802.11 para el desarrollo de WSN. Si bien la comisión responsable aún está trabajando en un borrador, se espera contar con una versión utilizable para el año 2016.

Enlaces


17 de noviembre de 2014

Ruta estática flotante + IP SLA

Un modelo de acceso a Internet habitual en redes de medianas dimensiones es el que está compuesto por 2 proveedores de acceso a Internet cuyo acceso se administra a partir de un único router de acceso.
Un modelo semejante al que ilustra el gráfico:
En este esquema, un requerimiento posible es que el enlace del ISP 1 sea el enlace activo y utilicemos el enlace al ISP 2 como enlace de respaldo.
Como se trata de enlaces a Internet, es siempre posible resolver el enrutamiento hacia Internet utilizando una ruta estática por defecto. Pero en este caso, si utilizamos 2 rutas estáticas por defecto (en principio) se balanceará tráfico entre ambos proveedores. Y no es este el requerimiento, no se desea balancear tráfico sino tener un enlace primario y otro de backup.

Una primera solución es dejar una ruta por defecto con la distancia administrativa por defecto (es decir 1), y utilizar distancia administrativa para dejar la otra ruta como flotante. La ruta flotante, al tener mayor distancia administrativa no irá a la tabla de enrutamiento sino que quedará como ruta de respaldo e irá a la tabla de enrutamiento cuando la ruta principal no esté disponible.

Router(config)#ip route 0.0.0.0 0.0.0.0 182.1.10.2
Router(config)#ip route 0.0.0.0 0.0.0.0 200.1.1.2 100

En este caso estamos utilizando como recurso la Distancia Administrativa de las rutas estáticas para definir cuál es nuestra ruta primaria y nuestra ruta de respaldo.
Hemos resuelto el requerimiento utilizando una ruta flotante. 
Pero esta solución no siempre es efectiva ya que dependiendo de la tecnología de acceso que esté utilizando el ISP es posible que perdamos el acceso primario a Internet mientras nuestra ruta por defecto sigue aún activa. Para resolver esta posibilidad es que se implementan las rutas por defecto vinculadas a un IP SLA:

Router#configure terminal
Router(config)#ip sla 1
Router(config-ip-sla)#icmp-echo 182.1.10.2 source-interface Se0/0/0
Router(config-ip-sla-echo)#timeout 500
Router(config-ip-sla-echo)#frequency 2
Router(config-ip-sla-echo)#exit
Router(config-ip-sla)#exit
Router(config)#ip sla schedule 1 life forever start-time now
Router(config)#track 1 ip sla 1 reachability
Router(config)#ip sla 2
Router(config-ip-sla)#icmp-echo 200.1.1.2 source-interface Se0/0/1
Router(config-ip-sla-echo)#timeout 500
Router(config-ip-sla-echo)#frequency 2
Router(config-ip-sla-echo)#exit
Router(config-ip-sla)#exit
Router(config)#ip sla schedule 2 life forever start-time now
Router(config)#track 2 ip sla 2 reachability
Router(config)#ip route 0.0.0.0 0.0.0.0 182.1.10.2 track 1
Router(config)#ip route 0.0.0.0 0.0.0.0 200.1.1.2 track 2 100

En este caso nuestras rutas por defecto ahora están asociadas a un track que hace seguimiento de un IP SLA específico, y luego calificadas por distancia administrativa.


24 de septiembre de 2012

Breve historia de Internet

Hace algunos años redacté una serie de apuntes en los que recogía información respecto de la historia de las modernas computadoras, el networking e Internet. Después de bastante tiempo he retomado ese apunte, lo revisé, le di un nuevo formato y lo publico hoy con la intención de que sirva de aporte para los que están buscando información sobre estos temas, y recibir los aportes de quienes deseen colaborar con correcciones, material nuevo, información adicional, etc.
El tema es muy amplio y obliga a hacer una selección de información y enfocarse en puntos específicos. Es por esto que me parece muy importante la opinión de todos: ¿están los hitos principales de esta historia contenidos en este relato? ¿es necesario agregar algo? ¿alguien le parece que es conveniente agregar alguna información adicional?
Cualquier aporte o comentario será bienvenido y agradecido, sólo pido que lo incorpores como un comentario en este post, de modo que quede todo integrado en un único lugar.
Breve historia de Internet, las computadoras y el networking