Dynamic QoS, part1.

Objetivo: proponer variantes para dinamizar la QoS.

Cuando se configuran los perfiles de QoS primeramente se hace un estudio de la aplicaciones que se quieren priorizar y de las características del enlace donde será aplicada la QoS . Las aplicaciones a priorizar y sus necesidades de ancho de banda y prioridad (en relación con el tipo de cola asociada) pueden cambiar con el tiempo, lo cual conlleva a una reconfiguración de la QoS. También pueden existir cambios períodicos o necesidades puntuales de priorización. Por ejemplo:
– Una semana del mes donde la empresa trabaja con cierta aplicación de manera intensiva y por lo tanto se hace necesario una priorizazión mayor en relación con esa aplicación.
– El tráfico de cierto usuario se vuelve prioritario dentro de un entidad por una actividad importante a cumplimentar y por lo tanto surge la necesidad de asignar más “recursos de ancho de banda al usuario específico”.
En los casos anteriores, si la necesidad de “mayor porción de ancho de banda del enlace” viene de una entidad que tiene enlaces redundantes es posible hacer redistribución del tráfico entre los distintos enlaces mediante el uso de PBR de acuerdo al ancho de banda de cada uno.

En este lab veremos una topología con un solo enlace entre una entidad x que se conecta al edificio corporativo de una empresa:

Configuración base:

!
hostname WanDR
!
// Configuración de los class-maps correspondientes a la aplicación 1 y 2 para las políticas de marcado, clasificación y priorización.
class-map match-all APP2-out
match ip dscp af31
class-map match-all APP1-out
match ip dscp af41
class-map match-all APP1
match access-group name aplicacion1
class-map match-all APP2
match access-group name aplicacion2
!
// Política de marcado.
policy-map MARK-IN
class APP1
set ip dscp af41
class APP2
set ip dscp af31
class class-default
set ip dscp default
// Política de identificación y priorización. 60% del canal para la APP1 ,30% para la APP2 y 10% para el resto del tráfico.
policy-map WAN_EDGE
class APP1-out
priority percent 60
class APP2-out
bandwidth percent 30
class class-default
bandwidth percent 10
// Shaping para limitar el tráfico a un 95% del ancho de banda de la interface Tu0 que es de 1024 kB.
policy-map SP-1024
class class-default
shape average 972800 9728 0
service-policy WAN_EDGE
!
interface Loopback0
ip address 144.1.20.1 255.255.255.255
!
interface Tunnel0
bandwidth 1024
ip address 144.1.1.1 255.255.255.252
tunnel source 10.1.1.2
tunnel destination 10.1.1.6
// Aplicación de la QoS de salida.
service-policy output SP-1024
!
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.252
duplex half
!
interface FastEthernet1/0
ip address 144.1.200.254 255.255.255.0
duplex auto
speed auto
// Aplicación de la QoS de entrada.
service-policy input MARK-IN
!
router eigrp 1
network 144.1.0.0
!
ip route 10.1.1.4 255.255.255.252 10.1.1.1
!
end

!
hostname Entidad1
!
interface Loopback0
ip address 144.1.20.2 255.255.255.255
!
interface Tunnel0
ip address 144.1.1.2 255.255.255.252
tunnel source 10.1.1.6
tunnel destination 10.1.1.2
!
interface FastEthernet0/0
ip address 10.1.1.6 255.255.255.252
duplex half
!
interface FastEthernet1/0
ip address 144.1.100.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 144.1.0.0
!
ip route 10.1.1.0 255.255.255.252 10.1.1.5
!
end

Nota: Los servidores de la APP1 y APP2 se encuentran en el nodo WanDR. Dependiendo del tipo de aplicación y del modo de trabajo, la carga de tráfico generada por el trabajo con las aplicaciones puede comportarse de manera diferente en el upload (Entidad1 -> WanDR) y en el download (WanDR -> Entidad1). En este laboratorio asumimos que la mayor carga de tráfico se produce en el sentido de download y por lo tanto la QoS está aplicada a la salida de la interfaz Tu0 que conecta WanDR con Entidad1.

Comprobación:

WanDR#sh policy-map interface tunnel 0
Tunnel0

Service-policy output: SP-1024

Class-map: class-default (match-any)
318 packets, 26712 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 318/31164
shape (average) cir 972800, bc 9728, be 0
target shape rate 972800

Service-policy : WAN_EDGE

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: APP1-out (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp af41 (34)
Priority: 60% (583 kbps), burst bytes 14550, b/w exceed drops: 0

Class-map: APP2-out (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp af31 (26)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 30% (291 kbps)

Class-map: class-default (match-any)
318 packets, 26712 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 318/31164
bandwidth 10% (97 kbps)

1ra Variante: Utilización de clasificación temporal con access-lists y time-ranges (Idea de Humberto Suros).
Requerimiento: Se necesita que durante los viernes de cada semana, la APP2 tenga una mayor prioridad (mayor % de ancho de banda del enlace) que la APP1.

Para cumplimentar el requerimiento se puede añadir y/o modificar la configuración en el router WanDR:

// Modificación de las ACLs en el router WanDR. Adición de los time-ranges.
!
// El tráfico que machee con la ACL aplicacion1 será marcado con af41 y tendrán un 60 % de prioridad en la salida. El tráfico desde la APP1 (ip address 144.1.200.1) estará activo en esta acl de acuerdo al time-range Prio60. El tráfico desde la APP2 (ip address 144.1.200.2) estará activo en esta acl de acuerdo al time-range Prio30.
ip access-list extended aplicacion1
permit ip host 144.1.200.1 any time-range Prio60
permit ip host 144.1.200.2 any time-range Prio30
// Está ACL tiene los time-ranges asignados de manera opuesta.
ip access-list extended aplicacion2
permit ip host 144.1.200.2 any time-range Prio60
permit ip host 144.1.200.1 any time-range Prio30
!
time-range Prio30
periodic Friday 0:00 to 23:59
!
time-range Prio60
periodic Monday Tuesday Wednesday Thursday Saturday Sunday 0:00 to 23:59
!

Comprobación:

WanDR#sh time-range
time-range entry: Prio30 (inactive)
periodic Friday 0:00 to 23:59
used in: IP ACL entry
used in: IP ACL entry
used in: IP ACL entry
used in: IP ACL entry
time-range entry: Prio60 (active)
periodic Monday Tuesday Wednesday Thursday Saturday Sunday 0:00 to 23:59
used in: IP ACL entry
used in: IP ACL entry
used in: IP ACL entry
used in: IP ACL entry

WanDR#sh access-lists
Extended IP access list aplicacion1
10 permit ip host 144.1.200.1 any time-range Prio60 (active)
20 permit ip host 144.1.200.2 any time-range Prio30 (inactive)
Extended IP access list aplicacion2
10 permit ip host 144.1.200.2 any time-range Prio60 (active)
20 permit ip host 144.1.200.1 any time-range Prio30 (inactive)

Nota: Para que esto funcione bien el reloj del router tiene que funcionar bien.

2da Variante: Utilización de scripts EEM y del scheduler KRON de Cisco.
Requerimiento: Se necesita que durante los viernes de cada semana, la APP2 tenga una mayor prioridad (mayor % de ancho de banda del enlace) que la APP1.

Para cumplimentar el requerimiento se puede añadir y/o modificar la configuración en el router WanDR:

// Añadida. Lo mismo podría añadir un WAN_EDGE1, un SP-1024_1, o simplemente no añadirlos y llenar el script EEM de comandos.
!
policy-map WAN_EDGE1
class APP2-out
priority percent 60
class APP1-out
bandwidth percent 30
class class-default
bandwidth percent 10
!
// Configuración del scheduler kron para la ejecución del EEM2 que dará prioridad a la APP2.
kron policy-list PRI60toAPP2
cli event manager run PRI60toAPP2
!
// Configuración del scheduler kron para la ejecución del EEM2 que devolverá la prioridad a la APP1.
kron policy-list PRI60toAPP1
cli event manager run PRI60toAPP1
!
kron occurrence PRI60toAPP2 at 0:00 Fri recurring
policy-list PRI60toAPP2
!
kron occurrence PRI60toAPP1 at 0:00 Sat recurring
policy-list PRI60toAPP1
!
// Script para el cambio de prioridad a la APP2
event manager applet PRI60toAPP2
event none
action 001 cli command “enable”
action 002 cli command “conf t”
action 003 cli command “policy-map SP-1024”
action 004 cli command “class class-default”
action 005 cli command “shape average 972800 9728 0”
action 006 cli command “no service-policy WAN_EDGE”
action 007 cli command “service-policy WAN_EDGE1”
action 008 cli command “end”
// Script para el cambio de prioridad de vuelta a la APP1
event manager applet PRI60toAPP1
event none
action 001 cli command “enable”
action 002 cli command “conf t”
action 003 cli command “policy-map SP-1024”
action 004 cli command “class class-default”
action 005 cli command “shape average 972800 9728 0”
action 006 cli command “no service-policy WAN_EDGE1”
action 007 cli command “service-policy WAN_EDGE”
action 008 cli command “end”
!

Comprobación:

WanDR#sh kron schedule
Kron Occurrence Schedule
PRI60toAPP2 inactive, will run again in 1 days 07:50:07 at 0 :00 on Fri
PRI60toAPP1 inactive, will run again in 2 days 07:50:07 at 0 :00 on Sat

WanDR#sh policy-map SP-1024
Policy Map SP-1024
Class class-default
Average Rate Traffic Shaping
cir 972800 (bps) bc 9728 (bits) be 0 (bits)
service-policy WAN_EDGE

WanDR#event manager run PRI60toAPP2
*Jun 7 16:12:44.131: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:PRI60toAPP2)

WanDR#sh policy-map SP-1024
Policy Map SP-1024
Class class-default
Average Rate Traffic Shaping
cir 972800 (bps) bc 9728 (bits) be 0 (bits)
service-policy WAN_EDGE1

Notas:
– Para que esto funcione bien el reloj del router tiene que estar actualizado y sincronizado.
– Se puede hacer lo mismo con scripts Tcl. Se puede crear un script Tcl en la flash del router que contenga los comandos a ejecutar (los mismos que estan en el script EEM de arriba). Se utilizaría el mismo kron para ejecutar el script Tcl.
– Se puede configurar un script en Python, con una librería específica para la conexión ssh con el router en los momentos de cambio (Viernes y Sábado) y que ejecute los mismo comandos. En este caso hay que reservar credenciales con privilegios de nivel 15 para la conexión ssh entre la PC con el script en Python y el router.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s