25 de abril de 2019

El modelo OSI en funcionamiento

Siempre es bueno volver a lo esencial, y eso en el estudio de las redes de datos es volver a revisar el modelo OSI.

Recordemos.
El modelo OSI es un modelo estándar desarrollado por la ISO y publicado en el año 1984. Gestado a partir de modelos precedentes (DecNet, SNA y TCP/IP). No es el adoptado por la IETF para Internet (el modelo adoptado por Internet es TCP/IP) pero sí el utilizado masivamente por la industria del networking para su desarrollo, documentación y entrenamiento.
De aquí surgen expresiones tales como "switch capa 3" o "protocolo de capa 4". Y también su importancia para el diseño de redes y la resolución de problemas. 

Es el modelo de arquitectura primaria para redes de datos que describe de manera pormenorizada el flujo de la información desde un dispositivo de origen, a través de los medios de conexión, hasta un dispositivo destino.
Divide el proceso global en agrupaciones lógicas más pequeñas que reciben la denominación de capas o layers en inglés. en cada una de las cuales se desarrolla una operación diferente.
Para la transferencia de información entre las diferentes capas se definen interfaces estándar de intercambio tanto hacia las capas superiores como inferiores.
Cada capa proporciona diferentes servicios a las capas que están por encima y por debajo de ella para establecer y sostener una conexión extremo a extremo con la misma capa en el sistema destino.



A medida que la información desciende o asciende a través de las diferentes capas durante el proceso de transmisión, cada protocolo implementa información adicional específica que permite asegurar la recuperación de la integridad de la información en su formato original luego de completar la transmisión.

El formato, contenido y extensión de esta información es determinada por los diferentes protocolos que se implementan en cada capa, de acuerdo a su función.

Al agregar en cada capa información complementaria necesaria para la transmisión se generan unidades de transmisión de datos (PDUs) que reciben denominaciones específicas de acuerdo al nivel de la capa OSI en la que se encuentran: segmento, paquete, trama, bit.



Los encabezados se agregan en el transmisor al pasar de una capa superior a una inferior (encapsulado), y se retiran en el receptor al pasar de una capa inferior a una capa superior (desencapsulado).



Un ejemplo.
Al intentar navegar un sitio web, esta navegación se establece utilizando el protocolo HTTP. Para eso utilizamos una aplicación que es un cliente HTTP como puede ser un navegador web; el navegador web permite interactuar utilizando el protocolo HTTP con un servicio HTTP hospedado en un servidor web.
La negociación de HTTP se realiza directamente (peer to peer) entre cliente en servidor. Pero para poder establecer esta negociación es necesario pasar por una serie de capas intermedias que permiten localizar el servidor, establecer un circuito virtual y transferirle la información de modo seguro y en un formato adecuado. Esto se realiza utilizando diferentes protocolos en cada una de las diferentes capas a fin de lograr esa transferencia.








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.


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.


16 de abril de 2019

IDs de VLANs en switches Catalyst

Cada VLAN en la red es identificada a través de un VLAN ID (VID) que puede tener hasta 12 bits de longitud. 
De ahí que el rango de IDs utilizables para troncales 802.1Q es de 0 a 4096, pero no todos esos valores son igualmente utilizables.
La siguiente tabla presenta los diferentes rangos dentro de ese espacio de 10 bits que se utilizan con diferente propósito.




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.


2 de abril de 2019

Error disabled

Cuando el puerto de un switch se encuentra activo es posible que por diferentes motivos el sistema operativo del dispositivo detecte diferentes situaciones de error que requieren que el puerto se inactive. En estos casos el sistema operativo desactiva el puerto automáticamente.

Este estado de un puerto desactivado automáticamente por el sistema operativo es el que se identifica como error disabled (errdisable).

En los switches Catalyst, cuando un puerto es colocado en estado de error disabled:
  • El puerto no envía ni recibe tráfico.
  • El LED del puerto se coloca en color naranja.
  • Cuando se verifica el estado del puerto se reporta como err-disabled.
Cuando un puerto es automáticamente colocado en modo error disabled se generan mensajes de notificación de eventos como este:

%SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.
%PM-SP-4-ERR_DISABLE: bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state

El mensaje que completa la notificación depende de la razón que ha generado la condición de error.

La condición de error disabled apunta a 2 propósitos:
  • Poner en conocimiento del Administrador que hay un problema en ese puerto.
  • Eliminar la posibilidad de que el problema registrado en ese puerto pueda generar una falla en otros puertos del dispositivo..
Causas de un estado error disabled
Las siguientes condiciones provocan que el puerto sea colocado en error disabled por defecto.
  • La detección de un número excesivo de colisiones (más de 16) en el medio o de colisiones tardías (late collisions).
    Una de las causas de colisiones tardías puede ser un error de configuración en el modo dúplex de las interfaces.
  • Dúplex mismatch.
  • Error de configuración de port channel.
  • Condición unidireccional con UDLD
  • Detección de flapeo de un enlace.
  • Violación de seguridad port-security.
  • Flapeo con PAgP.
  • L2TP guard.
  • Límite de tasa en DHCP snooping.
  • GBIC o SFP incorrecto.
  • Violación de ARP inspection
  • Inline power.
Para desactivar la detección de errores en alguna causa específica, se utiliza el comando

Switch(config)# no errdisable detect cause [causa]

Verificación de puertos en estado error disabled
Los siguientes comando permiten verificar el estado de los puertos del switch:

Switch# show interfaces gigabitethernet 0/1 status 

Port   Name          Status        Vlan   Duplex  Speed Type

Gi0/1                err-disabled  100    full    1000  1000BaseSX

Es posible implementar la recuperación automática de la operación del puerto utilizando el comando errdisable recovery. En este caso se puede utilizar el siguiente comando para determinar cuál ha sido la causa de que un puerto entre en modo error disabled.

Switch# show errdisable recovery
ErrDisable Reason    Timer Status
-----------------    --------------
udld                 Enabled
bpduguard            Enabled
security-violatio    Enabled
channel-misconfig    Enabled
pagp-flap            Enabled
dtp-flap             Enabled
link-flap            Enabled
l2ptguard            Enabled
psecure-violation    Enabled
gbic-invalid         Enabled
dhcp-rate-limit      Enabled
mac-limit            Enabled
unicast-flood        Enabled
arp-inspection       Enabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:
Interface      Errdisable reason      Time left(sec)
---------    ---------------------    --------------

  Gi0/1                bpduguard          273

El comando show error disabled detect permite verificar en un dispositivo particular las situaciones que pueden colocar un puerto en modo error disabled.

Switch> show errdisable detect
ErrDisable Reason    Detection    Mode
-----------------    ---------    ----
arp-inspection       Enabled      port
bpduguard            Enabled      vlan
channel-misconfig    Enabled      port
community-limit      Enabled      port
dhcp-rate-limit      Enabled      port
dtp-flap             Enabled      port
gbic-invalid         Enabled      port
inline-power         Enabled      port
invalid-policy       Enabled      port
l2ptguard            Enabled      port
link-flap            Enabled      port
loopback             Enabled      port
lsgroup              Enabled      port
pagp-flap            Enabled      port
psecure-violation    Enabled      port/vlan
security-violatio    Enabled      port
sfp-config-mismat    Enabled      port
storm-control        Enabled      port
udld                 Enabled      port


Los comandos presentados en este post
aplican tanto a IOS como a IOS XE.




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.


30 de marzo de 2019

Estado de las interfaces de switches Cisco IOS

Una herramienta de diagnóstico esencial para quienes operan switches Cisco Catalyst son los comandos show que permiten verificar el estado operacional de las interfaces.
En este punto hay 2 comandos principales:
  • show interfaces
    Este comando permite verificar el estado, configuración y estadísticas de operación de cada una de las interfaces físicas o lógicas del dispositivo.
    La primera línea del resultado que arroja para cada interfaz presenta el estado de operación de capa 1 y capa 2 de la interfaz. En el caso de interfaces Ethernet señala a continuación entre paréntesis una indicación adicional del estado de la interfaz.
    Para ver el análisis detallado del comando, ingrese aquí.
  • show interfaces status
    Comando que permite verificar de modo sintético y simple el estado operativo de cada interfaz.
    Es un comando propio de switches Catalyst, no está presente en routers.
    Para ver el análisis detallado del comando ingrese aquí.


Otros comandos a utilizar en esta tarea:
Para revisar las posibles causas de un puerto en err-disabled, consulte este documento.


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.



9 de marzo de 2019

Captura de tráfico en IOS-XE

La captura de tráfico es una herramienta de diagnóstico de suma importancia.
Para esta tarea se puede utilizar una herramienta de software dedicada como un analizador de tráfico. Para esto hay algunas aplicaciones disponibles, entre ellas Wireshark (free) u Omnipeek (licenciada, ofrece una demo gratuita por tiempo limitado).
Estas herramientas pueden montarse en una terminal desde la cual se realiza la captura de tráfico. 
Pero esta metodología tiene la limitación de que a la herramienta llega solamente el tráfico que arriba a la placa de red de la terminal, y ese tráfico no siempre es representativo de los flujos de tráfico que se desea analizar.

Para realizar análisis del tráfico que atraviesa las interfaces de los dispositivos de infraestructura de la red, algunos dispositivos (IOS, IOS XE, ASA) permiten realizar la captura de tráfico en la interfaz misma del dispositivo.
Esto es posible en routers y firewalls de Cisco.
La herramienta para esto en IOS e IOS XE es Embedded Packet Capture (EPC).

Dado el contexto de transición de IOS a IOS XE en el que nos encontramos, la revisión de comandos la haré directamente sobre IOS XE

Embedded Packet Capture
La herramienta captura los paquetes que se envían y reciben en el dispositivo.
Los paquetes se almacenan inicialmente en un buffer de memoria RAM.
Una vez que los datos son capturados pueden ser examinados en modo sintético o detallado en el mismo dispositivo.
Adicionalmente, los datos pueden ser exportados como archivo PCAP para ser examinados posteriormente con un analizador de tráfico.

Está diseñada como una herramienta de uso temporal para asistir en un proceso de diagnóstico, no como un feature permanente. Por este motivo la configuración se realiza en modo privilegiado (no en modo configuración) y no se almacena con el archivo de configuración del dispositivo por lo que no persiste luego de un reinicio.

Para facilitar la configuración en IOS, IOS XE y ASA Cisco pone disponible en línea una herramienta: Packet Capture Config Generator and Analyzer

Ejemplo de configuración en IOS XE
La captura de tráfico se introdujo en IOS XE 3.7 - 15.2(4)S.
Es diferente a la configuración en IOS.

Router# monitor capture CAP1 interface Gi0/0 both
  • Define la interfaz en la que se ha de realizar la captura de tráfico (la identifica con un nombre, en este caso CAP1) y define el sentido en el que se realiza la captura (en este caso se captura tráfico entrante y saliente).
  • Puede realizarse captura de tráfico en interfaces físicas, interfaces de túnel y sub interfaces.
Router# monitor capture CAP1 match ipv4 protocol tcp any any
  • Asocia a la captura (CAP1) un filtro de tráfico para seleccionar los paquetes que se desea capturar. en este caso se capturará tráfico TCP IPv4.
    También se puede asociar una lista de acceso o un class-map.
  • Con esto se completa la definición de la captura de tráfico.
Router# monitor capture CAP1 start
  • Arranca el proceso de captura identificado como CAP1.
    A partir de este momento se inicia la captura de tráfico en la interfaz.
  • La captura se mantendrá hasta tanto se concluya la captura de tráfico.
Router# monitor capture CAP1 stop
  • Detiene la captura.
    A partir de este punto no se captura más tráfico en la interfaz.
La captura realizada puede ser revisada en la línea de comando del router mismo, o exportarse para luego ser revisada utilizando un analizador de tráfico.

Router# show monitor capture CAP1 buffer brief
  • Permite una visión sintética de la captura realizada.
Router# show monitor capture CAP1 buffer detailed
  • Da una visión detallada de la captura de tráfico.
Router# monitor capture CAP1 export ftp://198.168.10.10/CAP1.pcap
  • Exporta la captura de tráfico en un archivo .pcap utilizando FTP.
  • El archivo puede ser luego revisado importándolo en un analizador de tráfico como Wireshark.

El siguiente es un ejemplo de captura filtrada utilizando una ACL:

Router# configure terminal
Router(config)# ip access-list extended FILTRO
Router(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any
Router(config-ext-nacl)# permit ip 192.168.2.0 0.0.0.255 any
Router(config-ext-nacl)# end
Router# monitor capture CAP2 access-list FILTRO interface Gi0/1 both





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.



25 de febrero de 2019

Voice VLAN

Cisco ofrece en los switches Catalyst un feature específico denominado Voice VLAN que permite la superposición de una topología de voz a una red de datos. Esto permite segmentar la red de telefonía IP compartiendo la infraestructura física de la red de datos.
  • Coloca los teléfonos en una VLAN independiente sin necesidad de intervención del usuario.
  • La asignación de VLAN se puede mantener uniforme aún en caso de que el teléfono sea cambiado de ubicación.
  • El usuario simplemente conecta el teléfono al switch, y el switch le provee con la información necesaria.
  • Esto facilita la segmentación y control del tráfico para preservar el tráfico de voz.
  • La asignación de un segmento IP propio para los teléfonos depende solamente del servicio DHCP.
  • Permite aplicar políticas de seguridad y QoS propias de la red de telefonía.
  • En síntesis, se genera una topología lógica independiente con las mismas ventajas de una topología física separada, con menos complejidad.
Para esto los switches soportan la posibilidad de un puerto de acceso que sea multi-VLAN. A la VLAN de acceso convencional se agrega ahora la VLAN de voz o VLAN auxiliar. De este modo el puerto de acceso queda asociado a 2 VLANs:
  • Una VLAN nativa identificada por el PVID para el servicio de datos.
  • Una VLAN de voz identificada por el VVID

La operación de esta función depende de CDP.
  • Durante el intercambio inicial de CDP con el switch el teléfono es configurado con el VVID.
  • Utilizando CDP también se puede proporcionar configuración de QoS al teléfono.
Los paquetes de datos que tenera la terminal son intercambiados con el switch utilizando la VLAN nativa del puerto del switch, por lo que no llevan etiqueta de modo que no se requiere ninguna configuración en la terminal.
El teléfono IP marca las tramas utilizando la información de VLAN proporcionada por CDP.
El puerto del switch no es un puerto troncal sino que es considerado un puerto de acceso que transporta su VLAN nativa y la voice VLAN.

Configuración

Es una variación de la configuración de un puerto de acceso.

Switch(config)# interface gigabitethernet 0/10
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport voice vlan 100
Switch(config-if)# exit
Switch(config)# exit
Switch#show vlan brief

VLAN Name                     Status    Ports
---- ----------------------- --------- ----------------------------
1    default                  active
10   Datos                    active    Gi0/1, Gi0/2, Gi0/3, Gi0/10
100  Voz                      active    Gi0/10
...



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.



17 de febrero de 2019

La dirección de loopback

La dirección IP loopback es una dirección ip (también conocida como localhost) reservada específicamente para probar el funcionamiento de TCP/IP en un dispositivo.
  • La dirección reservada del espacio de direccionamiento IPv4 es el que corresponde al segmento 127.0.0.0/8
  • La dirección reservada del espacio de direccionamiento IPv6 es solamente una IP ::1
¿Para qué se necesita una dirección de loopback?
Las tareas de diagnóstico de una conexión de red, en principio, requieren siempre de 2 terminales: un transmisor y un receptor.
Cuando Internet estaba en sus primeros pasos era posible que ambos terminales estuvieran a cientos o incluso miles de kilómetros de distancia. Y cuando se realizan la misma prueba es deseable que tanto transmisor como receptor se encuentren en el mismo ámbito para tener control de la totalidad de la conexión; esto inicialmente no era posible no sólo por cuestiones de espacio, sino también de tiempo. Por eso es deseable que el inicio y el final del circuito se puedan encontrar en el mismo dispositivo.
De aquí que se introdujera el concepto de loopback originado en las redes analógicas.
Por ello, al diseñar el stack a utilizan en la operación de las redes de datos se introdujo la posibilidad de probar un circuito TCP/IP sin siquiera necesidad de contar con una interfaz de red operativa.
De esta manera es posible  verificar la operación de todos los protocolos de red instalados simplemente ejecutando un ping al localhost o a la dirección IP de loopback.

¿Cuándo se introduce la dirección de loopback?
No está muy claro el momento de introducción de las direcciones de loopback.
Sí es claro que se introducen con IPv4. Uno de los primeros rastros de su implementación está en el código fuente de BSD Unix 4.1a que data de 1983, donde ya se utiliza la red 127, último bloque de direcciones de la Clase A de IPv4:

1  # define LONET   127
2  # define LOHOST  1 / * no puede ser 0, se transmite * /

3  # define LOMTU   ( 1024 + 512 )

El uso del segmento se documentó recién en 1986, en el RFC 990:
Direcciones especiales : 
En ciertos contextos , es útil tener direcciones fijas con significado funcional más que como identificadores de hosts específicos.
  • La dirección cero debe ser interpretada como significado "este" , como en "esta red". Por ejemplo, la dirección 0.0.0.37 podría ser interpretada como "el host 37 en esta red". 
  • La dirección de todos unos debe interpretarse como que significa "todos", como en "todos los hosts". Por ejemplo, la dirección 128.9.255.255 podría ser interpretada como "todos los hosts en la red 128.9".
Al número de red de clase A 127 se le asigna la función "loopback", esto es, un datagrama enviado por un protocolo de nivel superior a una dirección de la red 127 debe devolverse dentro del host . El datagrama "enviado" a una dirección de red 127 no debería aparecer en ninguna red en ningún momento.

¿Por qué en IPv4 es la red 127.0.0.0/8 completa?
En los inicios del desarrollo de Internet, en el despliegue inicial de ARPANET era reducido en cuanto a la cantidad de nodos conectados, tan reducido que las redes conectadas utilizaban todas aúna direccionamiento clase A.


Diagrama de ARPANET en el año 1982
En ese momento era inimaginable la proporción que tomaría la red en los próximos años, y quizás por eso asignar el último bloque de la clase A parecía lógico y conveniente.

No hay una declaración explícita de por qué se eligió la red 127 y no otra clase B o C. Son muchas las suposiciones que se han hecho al respecto, la más habitual es la facilidad de codificar y reconocer una dirección definida solamente por 1111111.


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.



1 de febrero de 2019

IEEE 802.11ax (2)

Voy ahora a continuar con la revisión de algunos aspectos importantes del nuevo estándar de redes LAN inalámbricas IEEE 802.11ax.

Si querés revisar el inicio de esta serie de posts, por favor, ingresá aquí
Solo a modo de repaso revisemos las principales características del estándar:
  • Compatibilidad con todos los estándares de capa física anteriores: 802.11a/b/g/n/ac
  • Prestación por usuario muy superior en escenarios de alta densidad de clientes.
  • Introducción de codificación 1024-QAM logrando mayores tasas de transferencia de datos.
  • Modulación OFDMA con MU-MIMO tanto en el downlink como en el uplink.
  • Modificaciones en la modulación OFDM FFT para lograr mayor robustez y rendimiento en entornos con múltiples reflejos y atenuación.
  • Mejor flujo de tráfico y acceso a canales.
  • Mejor administración de potencia para lograr mayor duración de la batería de los terminales.

Operación de múltiples usuarios
802.11ax tienes 2 modos de operación:
  • Single User MIMO.
    Cada una de las terminales asociadas al AP envían y reciben tramas de datos una a la vez, de modo secuencial.
    Es el modo de operación tradicional de redes 802.11.
  • Multiple User MIMO.
    Varias terminales conectadas al mismo AP pueden operar de modo simultáneo ya sea en el downlink como en el uplink.
    - En el downlink posibilita  que el AP transfiera datos a múltiples terminales de modo simultáneo. Esto ya estaba soportado en 802.11ac.
    - En el uplink posibilita que múltiples terminales transmitan simultáneamente hacia el AP. Esta es una novedad introducida por 802.11ax.
En el modo MU-MIMO también se especifican 2 formas diferentes de multiplexación: MU-MIMO con OFDM y MU-MIMO con OFDMA.
Para posibilitar esto el AP actúa como un controlador central que gestiona de modo independiente la operación de todos los aspectos de cada uno de los múltiples enlaces que la conectan con las terminales que tiene asociadas.

MIMO con Múltiples Usuarios
Ya 802.11ac implementaba MU-MIMO combinado con beamforming logrando una multiplexación espacial que permite mantener comunicación simultánea del AP con varias terminales diferentes.
Para esto el AP mantiene una matriz con la información correspondiente a cada enlace de cada terminal.

IEEE 802.11ax soporta la implementación simultánea de hasta 8 enlaces o cadenas de transmisión diferentes. A cada uno de estos enlaces de conexión a cada una de las diferentes terminales en la matriz corresponde su propio MCS (tasa de transferencia) y cantidad de cadenas de transmisión en paralelo.
En el uplink los APs 802.11ax mantienen esta matriz de conexiones para identificar cuál es la terminal que está transmitiendo en cada una de esas cadenas de transmisión y a qué conexión corresponde cada porción de información.

OFDMA
Para lograr mantener la conexión de mayor cantidad de terminales de modo simultáneo y aprovechar mejor el ancho de banda del canal, 802.11ax implementa OFDMA.
Las transmisiones IEEE 802.11a/g/n/ac ya utilizaban modulación OFDM (modulación por división de frecuencias ortogonales).
Sobre este esquema OFDMA introduce una modificación de relevancia: se asignan subportadoras específicas a cada terminal; es decir, divide el ancho de canal utilizado (20,40,80 o 160 MHz.según se haya definido) en subcanales, cada uno con un número específico de subportadoras.
Tomando como base la terminología propia de LTE (de dónde se ha tomado este tipo de modulación) se denomina Resource Unit (RU) a cada subcanal o bloque de 26 o más subportadoras.


El AP asigna cada subcanal en base a las necesidades de tráfico de downlink hacia los múltiples terminales buscando asignar todas las RUs disponibles.

De esta manera, un AP 802.11ax puede asignar todo el canal a un único usuario (como hace 802.11ac) o lo puede dividir para dar servicio a múltiples usuarios simultáneamente.

Este mecanismos permite, en entornos de "alta densidad" de terminales generar una celda en la que los terminales no necesitan competir por tiempo de uso del medio como ocurre habitualmente con CSMA/CA. OFDMA permite brindar espacio a múltiples terminales simultáneamente utilizando subcanales más pequeños pero dedicados.
Para esto el AP puede utilizar diferentes tamaños de RU, según se requiera. En su expresión más exigente este mecanismo permite asignar espacio en el downlink hasta a 9 terminales en un canal de 20 MHz.

Uplink de múltiples usuarios
Para coordinar las transmisiones MU-MIMO y OFDMA del uplink (desde las terminales hacia el AP), el AP envía una trama gatillo a la celda indicando el número de cadenas de transmisión espaciales y de asignaciones OFDMA (tamaño del RU) disponibles. 
A esto se agrega información de control de potencia para adecuar la potencia de los terminales de modo de intentar igualar la potencia con la que el AP recibe a todos los terminales para mejorar la recepción de tramas generadas por las terminales más alejadas.
El AP indicará a las terminales cuándo comenzar y terminar su transmisión. De esta manera las terminales comienzan y cesan sus transmisiones al mismo tiempo de modo que el AP envía un único acknowledge para las transmisiones de todos los terminales.



Uno de los objetivos principales de estos procedimientos (MU-MIMO de uplink y downlink y OFDMA) es optimizar el tiempo de operación de cada terminal para aumentar (hasta 4 veces) la cantidad de información transmitida (throughput) por cada terminal en entornos con alta densidad de usuarios.




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.