Configurar Traffic Shaping Cisco IOS: Comando Shape Average

¿Qué es el Traffic Shaping en Cisco? El traffic shaping en Cisco consiste en regular la tasa de salida del tráfico de acuerdo con determinados criterios mediante el uso de buffers y mecanismos de token bucket, suavizando ráfagas y ajustando la velocidad media al CIR configurado.

Una situación típica es tener un enlace de proveedor y varios suscriptores en la red, donde es necesario dividir la capacidad de acuerdo con la cuota asignada a cada uno. Es un método sencillo pero muy eficaz para garantizar que ningún usuario monopolice el ancho de banda disponible.

En este artículo te explico cómo configurar traffic shaping en Cisco IOS y aplico una política mediante class-based traffic shaping usando MQC (Modular QoS CLI), donde la clasificación se realiza a través de ACL asociadas a class-map, y las políticas se aplican por clase de tráfico sobre la interfaz de salida.

La configuración la he implementado sobre un Cisco ISR 4331 con IOS XE 17.18.2 — versión de referencia actual en producción a la fecha de publicación. Los comandos MQC son compatibles con versiones anteriores y posteriores de IOS XE sin modificaciones de sintaxis.

Topología del escenario real

El escenario utiliza tres nodos conectados a un router R1:

• Segmento oeste — servidor: 10.0.0.2/24, puerta de enlace: 10.0.0.1/24 (interfaz GigabitEthernet0/0/0 del router)
• Segmento este — interfaz del router: 192.168.0.1/24 (interfaz GigabitEthernet0/0/1), con dos nodos:
  • Nodo de administración: 192.168.0.10/24
  • Nodo de usuario: 192.168.0.2/24

El switch SW1 divide el flujo hacia los dos nodos del segmento este. La política de shaping se aplicará sobre la interfaz GigabitEthernet0/0/1, que conecta el router hacia ese segmento.

Paso 1 — Configuración de interfaces

He asignado las direcciones IP a ambas interfaces del router y las he activado:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int GigabitEthernet0/0/0
R1(config-if)#ip addr 10.0.0.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#
*Mar 1 00:08:50.355: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed state to up
*Mar 1 00:08:51.355: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/0, changed state to up
R1(config-if)#exit
R1(config)#int GigabitEthernet0/0/1
R1(config-if)#ip addr 192.168.0.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#
*Mar 1 00:10:01.975: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/1, changed state to up
*Mar 1 00:10:02.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/1, changed state to up
R1(config-if)#exit

En este punto, todos los nodos deben responder a ping. Es mi punto de partida antes de aplicar cualquier política de QoS.

Paso 2 — Clasificación del tráfico

He utilizado ACL extendidas para clasificar tráfico basándose en direcciones IP de origen y destino. En este escenario, las ACL identifican tráfico desde la red 10.0.0.0/24 hacia hosts específicos del segmento este, lo que permite aplicar QoS por dirección IP en el router Cisco definiendo políticas diferenciadas por flujo en la dirección de salida.

R1(config)#access-list 102 permit ip 10.0.0.0 0.0.0.255 192.168.0.10 0.0.0.0
R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 192.168.0.2 0.0.0.0
R1(config)#class-map LitlAdmin
R1(config-cmap)#match access-group 102
R1(config-cmap)#exit
R1(config)#class-map LitlUser
R1(config-cmap)#match access-group 101
R1(config-cmap)#exit
R1(config)#

He creado dos clases:

• LitlAdmin — vinculada a la ACL 102, identifica tráfico hacia el nodo de administración (192.168.0.10)
• LitlUser — vinculada a la ACL 101, identifica tráfico hacia el nodo de usuario (192.168.0.2)

Paso 3 — Política de shaping

Configuro la policy-map MyPolicy con los límites de ancho de banda para cada clase. El comando shape average expresa el CIR en bits por segundo.

Veamos un ejemplo de shape average en Cisco IOS:

R1(config)#policy-map MyPolicy
R1(config-pmap)#class LitlAdmin
R1(config-pmap-c)#shape average 512000
R1(config-pmap-c)#exit
R1(config-pmap)#class LitlUser
R1(config-pmap-c)#shape average 256000
R1(config-pmap-c)#exit

La política establece:

• Clase LitlAdmin → límite de 512 Kbps
• Clase LitlUser → límite de 256 Kbps

Dado que las clases están asociadas a las ACL, el router regula la tasa media de salida (CIR) del tráfico que coincide con cada clase mediante shaping, utilizando buffers para absorber ráfagas y mantener la velocidad promedio configurada.

La diferencia entre shaping y policing en Cisco es relevante aquí: el shaping retarda los paquetes que superan el CIR encolándolos, mientras que policing los descarta o remarca.

Para este escenario he optado por shaping para reducir la probabilidad de descarte frente a policing, a costa de introducir buffering y latencia adicional cuando el tráfico excede el CIR. Este comportamiento de shaping que utiliza buffers para absorber ráfagas justifica su elección con suscriptores. Para un análisis detallado del comportamiento saw-tooth del shaping frente al drop inmediato del policing, ver las diferencias entre traffic policing y traffic shaping en Cisco.

Paso 4 — Aplicación de la política en la interfaz

He aplicado la política en la dirección de salida de GigabitEthernet0/0/1, que es la interfaz orientada hacia los clientes:

R1(config)#int GigabitEthernet0/0/1
R1(config-if)#service-policy output MyPolicy

El tráfico que sale hacia el segmento este queda ahora sujeto a los límites definidos en MyPolicy.

Verificación con iperf

Para confirmar que el shaping está funcionando correctamente, utilizo la utilidad iperf.

Primero mido la velocidad sin restricciones del router para establecer la línea base — en el escenario original he obtenido aproximadamente 60 Mbit/s entre los nodos.

Luego genero el tráfico sujeto a las políticas. En el nodo de usuario ejecuto iperf en modo servidor:

# iperf -s

Y desde el servidor del segmento oeste lanzo el cliente apuntando a la IP del nodo de usuario:

# iperf -c 192.168.0.2

La dirección de la medición es importante: estoy midiendo el flujo que va hacia la máquina del cliente en la interfaz de salida GigabitEthernet0/0/1, que es exactamente donde está aplicada la política. Los resultados deben mostrar el ancho de banda recortado a 256 Kbps para el nodo de usuario.

Verificación en Cisco IOS

Para confirmar que los paquetes están haciendo match en las ACL y que la política de QoS se está aplicando correctamente ejecuto:

R1# show access-list

Este comando muestra el contador de matches por cada entrada de la ACL. Si los contadores no incrementan mientras hay tráfico activo, la ACL no está clasificando correctamente y ese es mi primer punto de auditoría.

R1# show policy-map interface GigabitEthernet0/0/1

Resumen del flujo para traffic shaping con MQC en Cisco

El proceso completo sigue la estructura estándar de MQC en Cisco IOS:

1. ACL — identifica el tráfico por dirección IP de origen/destino
2. class-map — asocia las ACL a clases de tráfico nombradas
3. policy-map — define la acción para cada clase (en este caso, shape average)
4. service-policy — aplica la política a una interfaz en una dirección (input u output)

Este ejemplo de class-map, policy-map y service-policy demuestra cómo este patrón se aplica en cualquier escenario de QoS con MQC, independientemente de si la acción es shaping, policing, marking o queuing — los mecanismos fundamentales de QoS que comprenden classification, marking, queuing, congestion management, policing y shaping. La referencia completa del framework MQC está disponible en la guía oficial de configuración MQC en Cisco IOS.