Seleccionar página
Configuración de DHCP Cisco IOS y Port Address Translation (PAT)

Configuración de DHCP Cisco IOS y Port Address Translation (PAT)

Diagrama topológico

 

Direccionamiento IP

  • PC0 –> DHCP Client
  • PC1 –> DHCP Client
  • Router1 –> G0/0 –> 192.168.1.1/24
  • Router2 –> G0/1 –> 209.123.234.1/24
  • Server0 –> 209.123.234.100/24

 

Configuración Router1 – Servicio DHCP

ip dhcp pool DHCP-POOL-01

 network 192.168.1.0 255.255.255.0

 default-router 192.168.1.1

!

ip dhcp excluded-address 192.168.1.1 192.168.1.10

 

 

Configuración Router1 – PAT

 

access-list 1 permit 192.168.1.0 0.0.0.255

!

ip nat inside source list 1 interface GigabitEthernet0/1 overload

!

interface GigabitEthernet0/0

 ip address 192.168.1.1 255.255.255.0

 ip nat inside

!

interface GigabitEthernet0/1

 ip address 209.123.234.1 255.255.255.0

 ip nat outside

 

Pruebas de DHCP Client en PC0 y PC1

 

 

Pruebas de Conectividad PC0 y PC1 a Server0

 

 

 

 

Revisión de traducción de direcciones PAT en Router1

 

Router1# sh ip nat translations

  

Configuración de DHCP en Cisco Router

Configuración de DHCP en Cisco Router

 

1.      Introducción

 

DHCP es el “Dynamic Host Configuration Protocol”, que en español sería el “Protocolo de configuración dinámica de host “.

DHCP es un servicio que permite configurar los parámetros de TCP/IP, como la dirección IP y la máscara de subred en los clientes (PC, computadora portátil, impresora, etc.) automáticamente.

Por lo general, DHCP se configura en un servidor dedicado para un mejor rendimiento. El servidor puede estar basado en Windows o en Linux.

DHCP también se puede configurar en un router o switch Cisco. Sin embargo, algunas funcionalidades avanzadas pueden no ser compatibles con el servidor DHCP configurado en un router Cisco.

En este LAB explicaremos como configurar el servicio de DHCP en un Cisco Router

 

2.      Comandos IOS

 

  • Configuración de la interfaz G0/0 de Router0

Router0(config)# int Gi0/ 0

Router0(config-if)# ip add 172.16.0.1 255.255.0.0

Router0(config-if)# no shut

 

  • Creación del DHCP Pool llamado “DHCP-POOL-01”

Router0(config)# ip dhcp pool DHCP-POOL-01

Router0(dhcp-config)# default-router 172.16.0.1

Router0(dhcp-config)# dns-server 172.16.0.1

Router0(dhcp-config)# network 172.16.0.0 255.255.0.0

Router0(dhcp-config)# exit

 

  • También podemos excluir direcciones IP del DHCP Pool

Router0(config)# ip dhcp excluded-address 172.16.0.1 172.16.0.99

Router0(config)# exit

 

3.      Pruebas de obtención de parámetros de direccionamiento IP

 

Como se puede ver en la siguiente imagen, PC toma dirección IP del DHCP Server

 

Tomando como primera dirección IP, la 172.16.0.100, con máscara clase B, Gateway y DNS Server de 172.16.0.1

 

Configuración de IP Helper Address Cisco

Configuración de IP Helper Address Cisco

Configuración de IP Helper Address

 

¿Para qué sirve el comando ip helper-address en equipos Cisco?

 

Este comando sirve para cuando un cliente requiere de una configuración IP utilizando un DHCP Server, como se muestra en la siguiente figura:

 

Este comando permite que el Router0, reciba  las solicitudes UDP en formato de broadcast y las reenvía como paquetes unicast a una dirección IP específica, que en este caso es la dirección IP del DHCP Server

 

De la figura desprendemos lo siguiente:

 

PC0 –> Es el cliente que requiere de una configuración IP de un DHCP Server

Switch0 –> Conecta en capa 2 a PC0 con Router0 (Gateway para PC0)

Router0 –> Conecta las redes 192.168.1.0/24 con la red 192.168.2.0/24

Switch1 –> Conecta en capa 2 a DHCP, DNS y Web Server con Router0 (Gateway para DHCP, DNS y Web Server)

DHCP Server –> Contiene el servicio de DHCP

DNS Server –> Contiene el servicio de DNS

Web Server –> Contiene el servicio de Web

 

Configuraciones de los equipos:

 

PC0:

Switch0:

Switch0#sh run

hostname Switch0

interface FastEthernet0/1

interface FastEthernet0/24

 

Router0:

Router0#sh run

hostname Router0

interface FastEthernet0/0

ip address 192.168.2.1 255.255.255.0

ip helper-address 192.168.1.10

interface FastEthernet0/1

ip address 192.168.1.1 255.255.255.0

 

Switch1:

Switch1#sh run

hostname Switch1

interface FastEthernet0/1

interface FastEthernet0/2

interface FastEthernet0/3

interface FastEthernet0/24

 

DHCP Server:

 

DNS Server:

 

Web Server:

 

Pruebas

 

  • En PC0 pasemos de “IP Configuration” Static a DHCP

 

Tomando la dirección IP 192.168.2.101

 

  • Ahora realicemos pruebas de conectividad a DHCP, DNS y Web Server:

C:\>ping 192.168.1.10

 

Pinging 192.168.1.10 with 32 bytes of data:

 

Reply from 192.168.1.10: bytes=32 time=1ms TTL=127

Reply from 192.168.1.10: bytes=32 time<1ms TTL=127

Reply from 192.168.1.10: bytes=32 time<1ms TTL=127

Reply from 192.168.1.10: bytes=32 time=1ms TTL=127

 

Ping statistics for 192.168.1.10:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms

 

C:\>ping 192.168.1.20

 

Pinging 192.168.1.20 with 32 bytes of data:

 

Request timed out.

Reply from 192.168.1.20: bytes=32 time=1ms TTL=127

Reply from 192.168.1.20: bytes=32 time<1ms TTL=127

Reply from 192.168.1.20: bytes=32 time<1ms TTL=127

 

Ping statistics for 192.168.1.20:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms

 

C:\>ping 192.168.1.30

 

Pinging 192.168.1.30 with 32 bytes of data:

 

Request timed out.

Reply from 192.168.1.30: bytes=32 time=1ms TTL=127

Reply from 192.168.1.30: bytes=32 time<1ms TTL=127

Reply from 192.168.1.30: bytes=32 time<1ms TTL=127

 

Ping statistics for 192.168.1.30:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms

 

  • Pruebas de conexión web a eclassvirtual.com

 

 

Pack Cisco CCNA 200-301, con oferta de descuento aquí

Como configurar QoS Trust Boundary en switches Cisco

Como configurar QoS Trust Boundary en switches Cisco

QoS Trust Boundary o “límite de confianza”

 

QoS Trust Boundary o “límite de confianza”, básicamente significa que vamos a confiar en el marcado de los paquetes y las tramas Ethernet que ingresan a nuestra red.

Por ejemplo, si usamos teléfonos IP, podemos marcar y configurar el switch para confiar en el tráfico que viene del teléfono IP.

Veamos el caso de 3 ejemplo de límite de confianza

 QoS Trust Boundary 01

En la imagen de arriba, el límite de confianza está en el teléfono IP y la computadora en cambio está fuera del límite de confianza QoS. Por lo que confiaremos en el marcado del teléfono IP, al contrario del computador que no confiaremos en su marcado.

 

Ahora observemos la siguiente figura:

 QoS Trust Boundary 02

 

En la imagen de arriba, no confiamos en la marca que el teléfono IP envía al switch de la capa de acceso. Esto significa que haremos clasificación y marcado en los switches de la capa de acceso.

 

Mirando la siguiente imagen:

 QoS Trust Boundary 03

Arriba podemos ver que no confiamos en nada antes de que cambie a la capa de distribución. Esto es algo que no ve muy seguido, pero es posible si no se confía en los switches de su capa de acceso. Quizás otras personas administren los switches de la capa de acceso y desee evitar que envíen paquetes o tramas Ethernet que estén marcados hacia los switches de la capa de distribución.

 

Ahora pasemos a configurar un switch

 

Primero activamos QoS con el siguiente comando:

 

Switch(config)# mls qos

 

 Algo que se debe tener en cuenta es que tan pronto como se habilita QoS en el switch, se borrará el marcado de todos los paquetes que se reciban. Si no se desea este comportamiento, se puede usar el siguiente comando para que no cambie el marcado entrante:

 

Switch(config)# no mls qos rewrite ip dscp

 

Podemos ver la configuración de QoS para una interfaz y ver si confía en el marcado del paquete o trama, con el siguiente comando:

 

Switch# show mls qos interface fastEthernet 0/1

 FastEthernet0/1

 trust state: not trusted

 trust mode: not trusted

 COS override: dis

 default COS: 0

 DSCP Mutation Map: Default DSCP Mutation Map

 Trust device: none

 

 

El comando de arriba nos muestra que no confiamos en nada que es el valor por defecto en los switch Cisco. Podemos confiar en paquetes basados ​​en el valor de DSCP, tramas en el valor de CoS o podemos confiar en el teléfono IP. Aquí hay unos ejemplos:

 

Switch(config-if)# mls qos trust cos

 

Con el comando de arriba, le decimos a la interfaz que confie en el valor CoS de todas las tramas que ingresan a la interfaz, como se ve en la siguiente salida de comando:

 

Switch# show mls qos interface fastEthernet 0/1

 FastEthernet0/1

 trust state: trust cos

 trust mode: trust cos

 COS override: dis

 default COS: 0

 DSCP Mutation Map: Default DSCP Mutation Map

 Trust device: none

 

 

 

Por default, el switch sobrescribirá el valor de DSCP del paquete dentro de la trama de acuerdo con el mapa cos-a-dscp. Si no queremos esto, podemos usar el siguiente comando:

 

Switch(config-if)# mls qos trust cos pass-through

 

La clave de pass-through es asegurar que el switch no sobrescriba el valor de DSCP. Además del valor de CoS, también podemos confiar en el valor de DSCP, con el siguiente comando:

 

Switch(config-if)# mls qos trust dscp

 

 

Usando el comando de arriba, no se confiará en el valor de CoS, sino en el valor de DSCP de los paquetes que lleguen a la interfaz, como se muestra en la siguiente salida de comando:

 

Switch# show mls qos interface fastEthernet 0/1

 FastEthernet0/1

 trust state: trust dscp

 trust mode: trust dscp

 COS override: dis

 default COS: 0

 DSCP Mutation Map: Default DSCP Mutation Map

 Trust device: none

 

 

Confiar en el valor Cos o DSCP en la interfaz establecerá su límite de confianza en el nivel de switch. Ahora, ¿qué pasa si queremos establecer nuestro límite de confianza en el teléfono IP de Cisco?. Para esto necesitamos otro comando:

 

 

Switch(config-if)# mls qos trust device cisco-phone

 

El comando de arriba le indica al switch que confíe en todos los valores de CoS que recibe del teléfono IP de Cisco:

 

Switch# show mls qos interface FastEthernet0/1

 FastEthernet0/1

 trust state: not trusted

 trust mode: not trusted

 COS override: dis

 default COS: 0

 DSCP Mutation Map: Default DSCP Mutation Map

 Trust device: cisco-phone

 

 

El comando de arriba sobrescribirá el valor de CoS de todas las tramas Ethernet recibidas de la computadora que está detrás del teléfono IP. Por lo que tendremos que establecer un valor de CoS nosotros mismo. También podemos confiar en la computadora, con este otro comando:

 

 

Switch(config-if)# switchport priority extend trust

 

 

Con el siguiente comando estableceremos un valor de CoS en todas las tramas sin etiquetar. Cualquier trama que ya esté etiquetada no se remarcará con este comando:

 

 

Switch(config-if)# mls qos cos 4

 

 

Ahora veamos la salida del siguiente comando:

 

 

Switch# show mls qos interface FastEthernet0/1

 FastEthernet0/1

 trust state: not trusted

 trust mode: not trusted

 COS override: dis

 default COS: 4

 DSCP Mutation Map: Default DSCP Mutation Map

 Trust device: none

 

 

El comando de arriba muestra que CoS override está deshabilitado. Pero en el caso que la trama Ethernet ya tenga un valor de CoS, pero de igual forma queremos remarcarlo tendremos que aplicar el siguiente comando:

 

 

Switch(config-if)# mls qos cos override

 

 

Override (remarcar) se ha habilitado, como resultado, todas las tramas Ethernet etiquetadas y sin etiquetar tendrán un valor CoS de 4. Eso es todo lo que hay que hacer para confiar en el teléfono CoS, DSCP o Cisco IP y (re) marcar su tráfico.

Si quieres aprender mas sobre redes de datos, consigue el pack de 10 cursos AQUÍ

 

La ruta del aprendizaje CCNA

Introducción a la Calidad de Servicio QoS para el Parte 2

Introducción a la Calidad de Servicio QoS para el Parte 2

Calidad de Servicio QoS

 

Siguiendo con la «Calidad de Servicio QoS para el CCNA parte 1» que vimos en un artículo anterior, ahora veremos un poco mas en profundidad las herramientas QoS

 

Herramientas QoS

Las herramientas que nos permiten implementar QoS son las siguientes:

 

Clasificación y marcado: si queremos dar a ciertos paquetes un tratamiento diferente, debemos identificarlos y marcarlos.

Queueing – Gestión de la congestión: en lugar de tener una gran cola en la que los paquetes se tratan con FIFO, podemos crear múltiples colas con diferentes prioridades.

 

Shaping and Policing: estas dos herramientas se utilizan para limitar el tráfico.

 

Congestion Avoidance: hay algunas herramientas que podemos usar para administrar la pérdida de paquetes y reducir la congestión.

 

Clasificación y marcado:

 

Con esta herramienta, se clasifica los paquetes en función del contenido de su encabezado, luego se marca el mensaje cambiando algunos bits en campos específicos del encabezado.

 

Conceptos básicos de clasificación:

 

Las herramientas de QoS se habilitan en las interfaces por dirección entrante o saliente de la interface.

 

Las herramientas de QoS realizan la clasificación (coincidencia de campos de encabezado) para decidir qué paquetes tomar contra ciertas acciones de QoS.

 

Acá un ejemplo:

 

Calidad de Servicio QoS para el CCNA 01

 

En la figura de arriba, se ha habilitado la herramienta en la cola de salida de una interfaz. En los routers, usan esta herramienta para colocar paquetes en una cola de salida, otros paquetes en otra cola y así sucesivamente. Programando/priorizando el tráfico en función de las reglas configuradas por el ingeniero de red.

 

Pasos que suceden con el paquete durante el procesamiento interno del router:

 

Paso 1: El router toma una decisión de reenvío (enrutamiento).

 

Paso 2: La herramienta de cola de salida utiliza la lógica de clasificación para determinar qué paquetes entrar en la cola de salida.

 

Paso 3: El router retiene los paquetes en la cola de salida esperando en la interfaz de salida, disponibilidad para enviar el siguiente mensaje.

 

Paso 4: La lógica de programación de la herramienta de puesta en cola elige el próximo paquete, priorizando con eficacia un paquete sobre otro.

 

Queueing – Gestión de la congestión:

  

Todos los dispositivos de red usan colas. Los dispositivos de red reciben mensajes, hacen una decisión de reenvío, y luego envían el mensaje, pero a veces la interfaz de salida está ocupada. Así que, el dispositivo mantiene el mensaje saliente en una cola, esperando que la interfaz saliente esté disponible.

 

El término “gestión de la congestión”, se refiere al conjunto de herramientas QoS

para gestionar las colas que contienen paquetes mientras esperan su turno para salir de una interfaz (y en otros casos en los que un router contiene paquetes esperando algún recurso). Pero la gestión de la congestión, se refiere más a una idea, por lo que debe mirarse dentro de los dispositivos para pensar sobre cómo funcionan.

 

 

Calidad-de-Servicio-QoS-para-el-CCNA-02

 

La figura muestra la cola de salida, un aspecto de la gestión de la congestión, en el que

el dispositivo retiene mensajes hasta que la interfaz de salida esté disponible. El sistema de colas puede usar una sola cola de salida, con un programación de, el primero en entrar, es el primero en salir (FIFO).

 

Muchos dispositivos de redes pueden tener un sistema de colas con múltiples colas. Para usar múltiples colas, el sistema de colas necesita una función de “clasificador” para elegir qué paquetes se colocan en qué cola. El sistema de colas también necesita un programador (Scheduler) , para decidir qué mensaje tomar a continuación cuando la interfaz está disponible, como se muestra en la siguiente Figura

 

 

Calidad-de-Servicio-QoS-para-el-CCNA-03

 

Existen varios tipos de Scheduler como:

 

Round Robin Scheduling (Prioritización)

 

Round robin, pasa por las colas en orden, turnándose con cada cola. En cada ciclo, el Scheduler toma un mensaje o toma una cantidad de bytes de cada cola tomando suficientes mensajes para totalizar esa cantidad de bytes. Toma algunos mensajes

de la cola 1, avance y tome algunos de la cola 2, luego tome algunos de la cola 3,

y así sucesivamente, comenzando en la cola 1 después de terminar un pase completo a través de todas las colas.

 

La programación de Round Robin también incluye el concepto de ponderación (generalmente denominado ponderado round robin). Básicamente, el planificador toma una cantidad diferente de paquetes (o bytes) de cada cola, dando más preferencia a una cola sobre otra.

 

Por ejemplo los routers usan una herramienta llamada Class-Based Weighted Fair Queuing (CBWFQ) para garantizar una cantidad mínima de ancho de banda para cada clase. Es decir, cada clase recibe al menos la cantidad de ancho de banda configurada durante los momentos de congestión, pero podría ser más. Internamente, CBWFQ usa un algoritmo ponderado de programación de round robin, por ejemplo en las tres colas del sistema se han dado 20, 30, y 50 por ciento del ancho de banda para cada uno, respectivamente.

 

 

Calidad-de-Servicio-QoS-para-el-CCNA-04

Con el sistema de cola mostrado en la figura, si el enlace saliente está congestionado, el programador garantiza el porcentaje de ancho de banda que se muestra en la figura para cada cola. Es decir, cola 1 obtiene el 20 por ciento del enlace, incluso durante las horas punta.

 

Low Latency Queuing (LLQ)

 

Un sistema “round robin queuing” agrega demasiado retraso para los paquetes de voz y video. Debido a que a pesar de tener asignado un % del ancho de banda, los paquetes de voz y dato debe esperar a que se envíe algunos mensajes de las otras colas para enviar nuevamente paquetes de voz y datos, lo que agrega retraso y jitter.

 

LLQ le dice al planificador que trate una o más colas como cola de prioridad especial. El planificador de LLQ siempre toma el siguiente mensaje de una de estas colas de prioridades especiales. Problema resuelto: muy poco retraso para los paquetes en esa cola, lo que resulta en muy poco jitter también. Además, la cola nunca tiene tiempo para llenarse, por lo que no hay caídas debido al llenado de la cola, como se muestra en la siguiente figura:

 

 

Calidad-de-Servicio-QoS-para-el-CCNA-05

 

El uso de LLQ, o cola de prioridad, proporciona bajo retardo, jitter y de pérdida de tráfico en esa cola. Sin embargo, pensemos en las otras colas. Qué sucede si la velocidad de la interfaz es de X bits / segundo, pero vienen más de X bits / segundo en la cola de voz? El Scheduler nunca dará servicio a las otras colas. Para solucionar este problema usamos “policing”, por ejemplo reservando el 20% del ancho de banda para la cola de voz, si sobrepasa este valor, el router descarta el exceso.

 

Limitar la cantidad de ancho de banda en la cola de prioridad protege las otras colas, pero causa otro problema. La voz y el video necesitan poca pérdida, y con LLQ, ponemos la voz y video en una cola de prioridad que descartará el exceso de mensajes más allá del ancho de banda límite. ¿La solución? Encontrar la forma de limitar la cantidad de voz y video que la red rutea de este enlace, para que el “policer” nunca descarte nada del tráfico. Hay herramientas de QoS para ayudar a hacer justamente eso, llamadas herramientas de control de admisión de llamadas (Call Admission Control (CAC)).

 

 

Shaping and Policing

 

Estas herramientas se usan con mayor frecuencia en el borde WAN en un diseño de red empresarial.

 

Tanto policing y shaping, supervisan la tasa de bits de los mensajes combinados que fluyen a través de un dispositivo. Una vez habilitado, el policer o shaper toma nota de cada paquete que pasa, y mide la cantidad de bits por segundo a lo largo del tiempo. Ambos intentan mantener la velocidad de bits en o por debajo de la velocidad configurada, pero utilizando dos acciones diferentes: policers descartar paquetes y shapers mantiene los paquetes en colas para retrasar los paquetes.

 

Policing

 

Esta herramienta descarta paquetes mientras mira la tasa de tráfico versus la tasa policing configurada para un momento dado.

El tráfico llega a los dispositivos de red a un ritmo variable, con valles y picos, como se muestra en la siguiente figura

 

Calidad de Servicio QoS para el CCNA 06 

En la siguiente figura muestra un gráfico de lo que sucede con el tráfico cuando un policer descarta cualquier mensaje. En efecto, el policer corta la parte superior del gráfico a la tasa del policing configurada.

 

También se muestra en la figura de arriba que un policer permite un pico o “Burst” de tráfico. Los “policers” permiten un estallido más allá de la tasa de policing durante un corto período de tiempo, después de un período de baja actividad. Entonces, ese pico que excede la tasa de policing en el gráfico permite la naturaleza de las aplicaciones de datos en ráfagas.

 Calidad de Servicio QoS para el CCNA 07

Shaping

 

Shaping es una técnica de QoS que podemos usar para aplicar tasas de bits más bajas que las que la interfaz física es capaz de hacer. La mayoría de los proveedores de servicios de Internet utilizarán shaping o policing para hacer cumplir los «contratos de tráfico» con sus clientes. Cuando usamos shaping almacenamos el tráfico a una cierta tasa de bits, en cambio policing eliminará el tráfico cuando exceda una cierta tasa de bits.

 

Por ejemplo, si nuestro ISP nos vende una conexión de fibra con un contrato de tráfico y un ancho de banda garantizado de 10 Mbit, pero la interfaz de fibra es capaz de enviar 100 Mbit por segundo. La mayoría de los proveedores de servicios de Internet configurarán policing para reducir todo el tráfico por encima de 10 Mbit, por lo que no podrá obtener más ancho de banda de lo que está pagando. También es posible hacer shaping hasta 10 Mbit, pero shaping significa que tienen que almacenar datos mientras que policing significa que pueden descartarlo. Los 10 Mbit que pagamos se llaman CIR (Commited Information Rate (tasa de información comprometida)).

 

Hay dos razones por las que quizás queramos configurar shaping:

  • En lugar de esperar a que el policy del ISP elimine nuestro tráfico, podriamos querer hacer shape para que no sea elimininado el tráfico hacia el ISP
  • Para evitar el bloqueo de salida. Cuando se pasa de una interfaz de alta velocidad a una interfaz de baja velocidad, es posible que se pierda paquetes en la cola saliente. Podemos usar shaping para asegurarnos de que se enviará todo (hasta que el búfer esté lleno).

En la siguiente figura podemos ver el gráfico del uso de shaping:

 

 Calidad de Servicio QoS para el CCNA 08

 

 

Podemos resumir de shaping que:

  • Shapers miden la tasa de tráfico a lo largo del tiempo para compararla con la tasa shaping configurada.
  • Shapers permiten picos o bursting después de un período de inactividad.
  • Los shapers están habilitados en una interfaz de salida (paquetes salientes).
  • Los shapers reducen la velocidad de los paquetes al ponerlos en cola, y con el tiempo los liberan de la cola en la tasa shaping.
  • Los shapers utilizan herramientas de puesta en cola para crear y programar las colas de shaping

 

Congestion Avoidance

 

La función de QoS llamada prevención de la congestión (congestion avoidance) intenta reducir la pérdida general de paquetes de forma preventiva descartando algunos paquetes usados ​​en conexiones TCP. Para ver cómo funciona, primero

necesitamos ver cómo funciona TCP en lo que respecta a ventanas, y luego ver cómo funciona Congestion Avoidance

 

 

Conceptos básicos de TCP Windowing

 

TCP usa un mecanismo de control de flujo llamado windowing. Cada receptor TCP otorga una ventana al remitente. La ventana, que es un número, define la cantidad de bytes que el emisor puede enviar a través de la conexión TCP antes de recibir un acuse de recibo TCP. Más exactamente, el tamaño de la ventana es la cantidad de bytes no reconocidos que el remitente puede enviar antes de que el remitente simplemente se detenga y espere. 

El mecanismo de ventana TCP le da al receptor el control de la tasa de envío de datos del emisor. Cada nuevo segmento enviado por el receptor al remitente otorga una nueva ventana, que puede ser más pequeño o más grande que la ventana anterior. Al subir y bajar la ventana, el receptor puede hacer que el emisor espere más o espere menos.

Por elección, cuando todo está bien, el receptor sigue aumentando la ventana concedida, duplicándola cada vez que el receptor acusa recibo de los datos. Eventualmente, la ventana crece hasta el punto que el remitente nunca tiene que dejar de enviar: el remitente sigue recibiendo acuses de recibo TCP antes de enviar todos los datos en la ventana anterior. Cada nuevo acuse de recibo (como figura en un segmento TCP y un encabezado TCP) otorga una nueva ventana al remitente.

También por elección, cuando un receptor TCP detecta la pérdida de un segmento TCP, reduce la ventana con el siguiente tamaño de ventana enumerado en el siguiente segmento TCP que el receptor envía de vuelta a el remitente. Por cada segmento TCP perdido, la ventana puede reducirse a la mitad, con múltiples pérdidas de segmento que causan que la ventana se reduzca a la mitad varias veces, ralentizando la tasa del remitente significativamente.

 En la siguiente figura, podemos ver como se produce la congestión y como se descartan los paquetes debido al aumento de la congestión. A mayor congestión, mayor descarte de segmentos TCP.

 

Calidad de Servicio QoS para el CCNA 09 

Ahora la herramienta de Congestion Avoidance, intenta evitar la congestión, principalmente mediante el uso de su propio mecanismos de ventanas TCP. Estas herramientas descartan algunos segmentos TCP antes que las colas se llenen, con la esperanza de que se desaceleren las conexiones TCP suficientemente, reduciendo la congestión y evitando un problema mucho peor: los efectos de muchos más paquetes que se eliminan debido a la caída de la cola. La estrategia es simple: desechar algunos ahora con la esperanza de que el dispositivo descarte muchos menos en el largo plazo.

 

 

Abrir chat
1
Hola 👋, en que puedo ayutarte!