Sobrecarga de protocolo. Códecs.

Hoy vamos a explicar el concepto de la sobrecarga de protocolo. Veremos como el ancho de banda de una señal, aún comprimida, aumenta considerablemente a la hora de ser transmitida en una red de conmutación de paquetes.

Y para ello, vamos a tomar un ejemplo típico en comunicaciones, la voz.

La señal de audio (musical) presenta información en todo el espectro audible, esto es 20Hz a 20KHz. La mayoría de sonidos por encima de los 16KHz son prácticamente inaudibles, cuando no enmascarados por las frecuencias inferiores.

Una señal que represente voz humana (señal vocal) no suele tener información relevante más allá de los 10 kHz, y de hecho en telefonía se toman sólo los primeros 4 kHz. Con 2 kHz bastaría para que la voz fuese inteligible, pero no para reconocer al hablante.

Bajo esta premisa y con el criterio de Nyquist, la voz telefónica se muestrea a 8KHz.

Read more

OC vs NOC : ¿Orientado o No Orientado a la Conexión?

Esta es la pregunta que muchos de vosotros os habréis hecho cada vez que os presentan un protocolo nuevo. A veces se habla de puertos y decimos… será orientado a la conexión. Bueno, pues no siempre es así.

A veces hablamos no de conexión, sino de conmutación de paquetes, datagramas, establecimiento de circuitos virtuales, etc.

Estos conceptos, cuando nos alejamos del mundo académico parecen distintos pero están relacionados, y hoy venimos a aclararlos:

Protocolo no orientado a la conexión

En telecomunicaciones, no orientado a la conexión significa una comunicación entre dos puntos finales de una red (equipos terminales de datos, ETD) entre los que un mensaje puede ser enviado sin acuerdo previo. El dispositivo en un extremo de la comunicación transmite los datos al otro, sin tener que asegurarse de que el receptor esté disponible y listo para recibir los datos. El emisor simplemente envía un mensaje dirigido al receptor. Cuando se utiliza esta forma de comunicación son más frecuentes los problemas de transmisión que con los protocolos orientados a la conexión, y puede ser necesario reenviar varias veces los datos. Los protocolos no orientados a la conexión a veces son rechazados por los  cortafuegos porque los paquetes maliciosos son más difíciles filtrar. El protocolo IP (nivel 3) y el protocolo UDP (nivel 4) son protocolos no orientados a la conexión, pero TCP (nivel 4) es un protocolo orientado a la conexión.

Read more

Cómo hacer telnet udp o tcp (sin telnet)

Muchas veces nos ocurre que nos resulta imposible testear si un puerto esta abierto o no ya que puede que no dispongamos del comando telnet o bien por que necesitemos chequear un puerto udp.

Desde Linux lo tenemos fácil desde la utilidad nmap:

Ejemplo:

nmap -p 161 -sU -P0 127.0.0.1

Pero desde windows la cosa cambia, aunque si que es cierto disponemos de nmap nos obliga a tener que instalarlo y quizas esto no le guste a todos.

Pero para salvar este problema disponemos de portqry que es una utilidad de la propia Microsoft para estos casos.

La sintaxis es muy sencilla:

portqry -n reskit.com -p tcp -e 25

El comando siguiente intenta resolver “169.254.0.11” como un nombre de host y después consulta los puertos TCP 143, 110 y 25 (en ese orden) en el host que seleccionó. Este comando también crea un archivo de registro (Portqry.log) que contiene un registro del comando que ejecutó y su resultado.

portqry -n 169.254.0.11 -p tcp -o 143,110,25 -l portqry.log

El comando siguiente intenta resolver miServidor como una dirección IP y después consulta el intervalo especificado de puertos UDP (135-139) en orden secuencial en el host correspondiente. Este comando también crea un archivo de registro (miServidor.txt) que contiene un registro del comando que ejecutó y su resultado.

portqry -n miServidor -p udp -r 135:139 -l miServidor.txt

Comparando iSCSI, FC y FCoE. MTU y Jumbo Frames

Continuando con el anterior post acerca del almacenamiento, en el que veíamos como configurar el protocolo iSCSI con tgt-adm en RHEL/CENTOS, he encontrado un estudio comparativo de los diferentes protocolos que encontramos para acceder a la red de almacenamiento (SAN).

Básicamente, este estudio nos cuenta en sus conclusiones que, a pesar de la creencia extendida de que iSCSI empeora el rendimiento de acceso a disco, este protocolo puede resultar no sólo más barato sino incluso más eficiente que FC y FCoE.

La supuesta pérdida de rendimiento, llegando incluso a afirmar algunos que el protocolo se vuelve impredecible, se debe al considerable aumento de información, no de datos, que ha de viajar por la red TCP/IP con iSCSI. Esta información corresponde precisamente a las cabeceras TCP, ya que encontramos el disco a nivel 4(TCP, transporte). Sin embargo, el estudio defiende que aumentado el parámetro JUMBO-FRAMES en todos los dispositivos de red implicados, el rendimiento llega incluso a superar como decíamos a FC o FCoE.

JUMBO-FRAMES define el tamaño del datagrama a nivel 2(Ethernet), esto es la MTU (maximum transfer unit) en los switches, routers, etc. Por defecto, las redes TCP operan con MTU por defecto de 1500 bytes, pero este valor puede elevarse hasta 9000 bytes. Precisamente si aumentamos el tamaño de MTU al máximo, 9000 sería el tamaño de la trama ethernet, y por lo tanto, habría menos tramas que transmitir, es decir, menos cabeceras a nivel 2.  Esto según el estudio redunda en un mejor rendimiento del protocolo iSCSI.

El único problema es que la mayoría de los servidores y aplicaciones, en redes TCP/IP funcionan con el tamaño MTU por defecto (1500bytes). Antes de cambiar este tamaño de MTU hemos de tener muy claro qué implicaciones va a tener sobre la red TCP/IP y nuestra infraestructura, ya que la compartimos con el almacenamiento, o de lo contrario, deberíamos tener la red redundada: TCP/IP por un lado con direccionamiento determinado, y SAN por otro lado, con diferente direccionamiento y diferente switchería. Lo recomendable sería lo primero.

El estudio procede de DELL, y se encuentra en:

http://en.community.dell.com/techcenter/storage/w/wiki/2722.aspx/

Limitación de Ancho de Banda de un interfaz CISCO (I)

Dimensionar el Ancho de Banda de un interfaz de red nos sirve fundamentalmente para repartirlo de tal manera que puedan garantizarse los niveles de calidad de servicio deseados. Es decir, limitar el Ancho de Banda permitido para un servicio implica que los servidores dedicados a él no saturarán el interfaz y por lo tanto se mantendrán todos los servicios que lo necesitan.

Normalmente limitaremos el ancho de banda de los servicios que más tráfico requieren, por ejemplo tráfico web o correo.

La forma de hacerlo en CISCO es a través de rate-limit. La sintaxis de este comando la encontramos en:

http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd8.html

Para el ejemplo que nos ocupa, hemos de definir unas listas de acceso extendidas y a continuación aplicarlas en el interfaz correspondiente:

Para correo entrante una limitación de 10Mbps .
Para correo saliente una limitación de 8Mbps .
Para tráfico Web una limitación de salida de 20Mbps .

Para restringir el ancho de banda a los servicios se utilizara una ACL.

Configuración:

Router(config)# access-list 100 permit tcp any <o IPs Web> eq www any

(trafico Web saliente)

Router(config)# access-list 101 permit tcp any any <o IPs POP3> eq pop3

(trafico smtp entrante)

 Router(config)# access-list 102 permit tcp any <o IPs SMTP> eq smtp any

(trafico smtp saliente)

A continuación, hay que implementar el comando rate-limit en la interfaz que conecta a internet o a cualquier otro Router los servidores conectados:

Router(config)# interface GigabitEthernet0/1

 
Router(config-if)#
rate-limit output access-group 100 20000000 3750000 7500000 conform-action transmit exceed-action drop

(limitado el ancho de banda del trafico Web saliente)

 
Router(config-if)# 
rate-limit input access-group 101 10000000 1875000 3750000 conform-action transmit exceed-action drop

(limitado el ancho de banda del correo entrante)

Router(config-if)#
rate-limit output access-group 102 8000000 1500000 3000000 conform-action transmit exceed-action drop

(limitado el ancho de banda del correo saliente)

Para configurar el rate-limit hemos necesitado dos valores más que se recomienda calcular con la formula proporcionada por Cisco. Estos valores son el “normal burst” y el “extended burst”.

 Según Cisco estos valores se calcula por:

 “normal burst” = rate * (1 byte)/(8 bits) * 1.5 seconds

“extended burst” = 2 * “normal burst”

 

Comando para verificación:

 show interfaces rate-limit