miércoles, 15 de febrero de 2012

Mecanismos de Qos en salida en los Catalyst 3XXX (SRR Shape y Share)

El objetivo de este post, es intentar explicar el funcionamiento de la configuración de la QoS de salida en los Cisco Switchs 3XXXComo primera medida, analizaremos el funcionamiento de las colas y buffers de salida en un Catalyst 3560 y la configuración de SRR.  

A continuación, un ejemplo de configuración:

interface FastEthernet0/13
switchport mode access
load-interval 30
srr-queue bandwidth shape 50 0 0 0
srr-queue bandwidth share 33 33 33 1
srr-queue bandwidth limit 20

SRR en modo “shared” se utiliza cuando se quiere obtener la máxima eficiencia de un sistema de colas, porque los buffers de las colas no utilizadas pueden ser utilizados por las colas con exceso de tráfico. SRR en modo “shaped” se utiliza cuando se quiere garantizar el ancho de banda a una cola y establecer al mismo tiempo un límite de cuánto ancho de banda una cola puede utilizar.

Cuando el mecanismo de organización de salida SRR está configurado en modo “shared”, el ancho de banda asignado a cada cola se basa en pesos relativos. Por ejemplo, cuando se configura “srrqueue bandwidth share 30 20 25 25″ lo que realmente hacemos es configurar los pesos para las colas 1,2,3 y 4, en este caso 30+20+25+25 = 100 (el 100 podría representar el 100% del Bw).
Dichos pesos son relativos y son por lo tanto "30/100", "20/100", "25/100", "25/100", y se puede calcular el ancho de banda efectivo garantizado * * a una cola multiplicando este peso por el ancho de banda de la interface; por ejemplo, 30/100 * 100 Mbps = 30 Mbps para la interface de 100 Mbps y 30/100 * 10 Mbps = 3 Mbps para una interface de 10Mbps. Por supuesto, el peso sólo se tiene en cuenta cuando existe una sobresuscripción de la interface, es decir, cuando sufre una congestión.

Cuando se configura en el modo “shape”, en realidad se configura una restricción de ancho de banda (policing) cada cola se basa en el peso absoluto inverso. Por ejemplo, con el comando "srr-queue bandwidth shape 30 0 0 0" se restringe de manera efectiva a la primera cola a "1 / 30" de ancho de banda de la interfaz (es decir, aproximadamente 3,3 Mbps para una interface de 100 Mbps y aproximadamente 330Kbps para una interface de 10Mbps). Configurando SRR “shape” con un peso cero significa en la práctica, que no se aplica el “shape”. Cuando el “shaping” está habilitado, SRR no utiliza el peso “share” correspondiente a esta cola en el cálculo de ancho de banda relativo de colas configuradas como “share”.

Se pueden mezclar “shape” y share en la configuración de una misma interface. Por ejemplo, dos colas pueden ser configurados para “shape” y otras para share:

interface FastEthernet0/13
srr-queue bandwidth share 100 100 40 20
srr-queue bandwidth shape 50 50 0 0

Supongamos que el ancho de banda de la interface es 100Mpbs, entonces las colas de 1 y 2 tendrán 2 Mbps cada una, y las colas de 3 y 4 comparten el ancho de banda restante (100-2-2 = 96Mbps) en proporción "2:1". Se debe tener en cuenta que las colas de 1 y 2 garantizan y se limitan a 2 Mbps, al mismo tiempo.

El valor por defecto de la configuración para los pesos "shape” y "share" son los siguientes: “shape” "25 0 0 0" y share "25 25 25 25". Esto significa que la cola 1 es limitada hasta 4Mbps en interfaces de 100Mpbs por defecto (400kbps en una interface de 10Mbps) y el ancho de banda restante es compartida de forma igualitaria (“shared”) por las otras colas (2-4). Esto es así, en cuanto se habilita "mls qos" en el switch.

Cuando se habilita " priority-queue out " en una interface, se convierte a la cola 1 en una cola de alta prioridad, por lo que el mecanismo de SRR no tiene en cuenta el peso de esa cola en los cálculos. Se debe tener en cuenta que PQ ignorará la configuración del modo “shape”, y esto puede hacer que otras colas nunca tengan oportunidad de enviar paquetes, ya que primero, se enviaran los paquetes de la cola de alta prioridad y solo se pasara a las otras colas cuando esta se vacíe.

Si se quiere limitar el ancho de banda de salida de un puerto se puede utilizar el comando " srrqueue bandwidth limit xx " a nivel de interface. Este comando limita a la interface de salida en un porcentaje de xx% de la capacidad de la interface. Se debe tener en cuenta que el rango de porcentaje parte del 10% (con incrementos reales en múltiplos de 6), así que si se necesita una velocidad inferior a 10 Mbps, considere cambiar la velocidad del puerto a 10 Mbps.

¿Cómo afectara la configuración, a la programación del mecanismo SRR? Recordemos, que en SRR
share los pesos son relativos, y por lo tanto, que compartirán el ancho de banda entre las colas respectivas. Sin embargo, en el modo “shape” se basan en el peso absoluto de las colas descontándose del ancho de banda "disponible”. Consideremos el siguiente ejemplo:

interface FastEthernet0/13
switchport mode access
speed 10
srr-queue bandwidth shape 50 0 0 0
srr-queue bandwidth share 20 20 20 20
srr-queue bandwidth limit 20

El ancho de banda de la interface está limitado a 2Mbps (de 10Mbps). La cola 1 está configurada en modo “shape” limitándola a 1/50 de 10Mps, lo cual resulta en 200Kbps de ancho de banda.
El ancho de banda restante (2000-200 = 1800KBps) se divide en partes iguales entre las otras colas en proporción 20:20:20 = 1:1:1. Es decir, en caso de congestión y que todas las colas estén “llenas”, la cola 1 obtendrá 200Kbps, y las colas de 2-4 obtendrán 600Kbps cada una de ellas.

Preguntas Frecuentes (FAQ)

P: ¿Cómo puedo determinar a qué cola irán los paquetes? ¿Qué pasa si un paquete tiene un valor de CoS y DSCP fijado en el mismo tiempo?

R: Eso depende de la clasificación de entrada. Si se confía en el valor de CoS, entonces se utilizaran los valores referenciados en la figura 1 (asignaciones por defecto). Del mismo modo, si confía en el valor DSCP. Use el comando "show mls qos map " para ver las asignaciones actuales.

 
P: Que sucederá si he configurado “shape” y “share” en la misma cola?

R: La configuración de cola “shape” anulará el peso de “share”, lo sobreescribe. El valor del peso “shared” que está en conflicto con el valor de “shape” también estará excluido de los cálculos de SRR. Se debe tener en cuenta que en la cola en modo “shape” asegura cierto ancho de banda (el asignado), pero al mismo tiempo, también lo limita a él. En resumen, las colas “shape” garantizan y limitan el ancho de banda asignado a dicha cola. Las colas “share”, comparten el ancho de banda restante, según los pesos asignados a cada una de ellas.

P: ¿Qué pasa si priority-queue está habilitado en la interface? ¿Puedo limitar la tasa de envío de PQ con el uso del "shape"?

R: No, no se puede. Priority-queue utilizara todo el ancho de banda que necesite, por lo que se deberá tener cuidado a la hora de asignar que tipo de trafico utilizara la Priority-queue.

Preguntas? Comentarios?

Usa mi tweeter @guscorre4

Saludos

martes, 7 de febrero de 2012

Como funciona BGP AS-Override

Introducción

El mecanismo de prevención de loops (bucles) de BGP, es realizado a través de la revisión del número de AS, dentro del atributo AS_PATH.
Si el router receptor ve su número de AS en el atributo AS_PATH en el update BGP recibido, descarta el update. El router receptor asume que el update fue originado desde su propio AS y está volviendo al mismo AS de origen, en definitiva, se está produciendo un loop/bucle en cuanto a la información de routing.

Este mecanismo, puede ser un problema cuando por ejemplo un cliente tiene un único AS y esta “distribuido” entre distintos sites, y se usa otro AS de transito, entre ellos. En este tipo de escenarios, los updates desde un site son descartados por el otro site, al ver su propio numero de AS en el AS_PATH.

Para poder solucionar este problema BGP cuenta con un feature que es llamado “AS-Override” que básicamente lo que hace es sobrescribir el número de AS que se le envía a un vecino.  El comando para habilitar este feature es neighbor ip-address as-override  que solo está disponible en VPNv4 address-family.

Para poder observar mejor el funcionamiento de esta feature,  vamos a utilizar el siguiente escenario.

•    El router TAURUS_Site-A anuncia la red 10.3.3.3 con el AS100.
•    El router PE-1 propaga este anuncio como una ruta interna a PE2 con el AS100.
•    PE2 agrega a la ruta 10.3.3.3 el AS121 y reemplaza el 100 en el AS-Path con el 121 y propaga el prefijo.
•    El router TAURUS_Site-B acepta el update de la 10.3.3.3.


Diagrama Topologico
 
 
Escenario
En esta topología, el router PE-1 y el PE-2 conforman la red MPLS de Service Provider. Ambos routers están conectados por la interface Fast Ethernet 0/0 y están utilizando OSPF (Area 0) como protocolo de routing. MPLS está configurado en ambas interfaces Fast Ethernet 0/0. El tagging es realizado utilizando LDP y las etiquetas están siendo asignadas en el rango que va de la 100-199 en el router  PE1 y la de la 200-299 en el PE2.

Los routers TAURUS y CINDY son dos clientes que tienen multiples sites (Site-A y Site-B). El cliente TAURUS está usando AS 100 el cliente CINDY el AS 200.

Se  usan vrf's VPNv4 en los routers del SP (vrf TAURUS y vrf CINDY)

Las rutas son anunciadas desde cada site, hacia los PE utilizando EBGP. Una vez dentro de la vrf correspondiente, son transportadas hacia el próximo PE y de ahí, al site correspondiente.

Configuración de los PE
  
------------------------------------------------------ 
hostname PE-1
!
ip cef
!
ip vrf CINDY
rd 1:200
route-target export 1:200
route-target import 1:200
!
ip vrf TAURUS
rd 1:100
route-target export 1:100
route-target import 1:100
!
mpls label range 100 199
mpls label protocol ldp
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.12.12.1 255.255.255.0
mpls ip
!
interface Serial0/0
ip vrf forwarding TAURUS
ip address 192.13.13.1 255.255.255.252
!
interface Serial0/1
ip vrf forwarding CINDY
ip address 192.14.14.1 255.255.255.252
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.12.12.1 0.0.0.0 area 0
!
router bgp 121
no synchronization
bgp log-neighbor-changes
network 11.11.11.11 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 121
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 next-hop-self
no auto-summary
!
address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community both
exit-address-family
!
address-family ipv4 vrf TAURUS
  redistribute connected
  neighbor 192.13.13.2 remote-as 100
  neighbor 192.13.13.2 activate
  neighbor 192.13.13.2 as-override
  no synchronization
exit-address-family
!
address-family ipv4 vrf CINDY
  redistribute connected
  neighbor 192.14.14.2 remote-as 200
  neighbor 192.14.14.2 activate
  neighbor 192.14.14.2 as-override
  no synchronization
exit-address-family
!
mpls ldp router-id Loopback0
!
exit  
------------------------------------------------------

hostname PE-2
!
ip cef
!
ip vrf CINDY
rd 1:200
route-target export 1:200
route-target import 1:200
!
ip vrf TAURUS
rd 1:100
route-target export 1:100
route-target import 1:100
!
mpls label range 200 299
mpls label protocol ldp
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Loopback1
ip address 22.22.22.22 255.255.255.255
!
interface FastEthernet0/0
ip address 10.12.12.2 255.255.255.0
mpls ip
!
interface Serial0/0
ip vrf forwarding TAURUS
ip address 192.23.23.1 255.255.255.252
!
interface Serial0/1
ip vrf forwarding CINDY
ip address 192.26.26.1 255.255.255.252
!
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 10.12.12.2 0.0.0.0 area 0
!
router bgp 121
no synchronization
bgp log-neighbor-changes
network 22.22.22.22 mask 255.255.255.255
neighbor 1.1.1.1 remote-as 121
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
no auto-summary
!
address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community both
exit-address-family
!
address-family ipv4 vrf TAURUS
  redistribute connected
  neighbor 192.23.23.2 remote-as 100
  neighbor 192.23.23.2 activate
  neighbor 192.23.23.2 as-override
  no synchronization
exit-address-family
!
address-family ipv4 vrf CINDY
  redistribute connected
  neighbor 192.26.26.2 remote-as 200
  neighbor 192.26.26.2 activate
  neighbor 192.26.26.2 as-override
  no synchronization
exit-address-family
!
mpls ldp router-id Loopback0
!
exit


Configuración de los CE

------------------------------------------------------

hostname TAURUS-Site_A
!
ip cef
!
interface Loopback0
ip address 10.3.3.3 255.255.255.255
!
interface Serial0/0
ip address 192.13.13.2 255.255.255.252
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 10.3.3.3 mask 255.255.255.255
neighbor 192.13.13.1 remote-as 121
no auto-summary
!
exit
  
------------------------------------------------------
hostname CINDY-SITE_A
!
ip cef
!
interface Loopback0
ip address 10.4.4.4 255.255.255.255
!
interface Serial0/0
ip address 192.14.14.2 255.255.255.252
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.4.4.4 mask 255.255.255.255
neighbor 192.14.14.1 remote-as 121
no auto-summary
!
exit  
 
------------------------------------------------------

hostname TAURUS-Site_B
!
ip cef
!
interface Loopback0
ip address 10.5.5.5 255.255.255.255
!
interface Serial0/0
ip address 192.23.23.2 255.255.255.252
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 10.5.5.5 mask 255.255.255.255
neighbor 192.23.23.1 remote-as 121
no auto-summary
!
exit

------------------------------------------------------  

hostname CINDY-SITE_B
!
ip cef
!
interface Loopback0
ip address 10.6.6.6 255.255.255.255
!
interface Serial0/0
ip address 192.26.26.2 255.255.255.252
!
router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.6.6.6 mask 255.255.255.255
neighbor 192.26.26.1 remote-as 121
no auto-summary
!
exit

 
------------------------------------------------------
 
Verificación del funcionamiento

PE-1#show ip bgp vpnv4 all summary
 
< output truncated >
 
Neighbor       V    AS  MsgRcvd MsgSent           TblVer    InQ    OutQ   Up/Down   State/PfxRcd
2.2.2.2        4    121     115     116             15       0     0      01:09:16        4
192.13.13.2    4    100      70      74             15       0     0      00:46:42        1
192.14.14.2    4    200      41      44             15       0     0      00:36:14        1
 
PE-2#show ip bgp vpnv4 all summary
 
< output truncated >
 
Neighbor        V    AS MsgRcvd MsgSent           TblVer      InQ OutQ     Up/Down  State/PfxRcd
1.1.1.1         4   121     119     118               15       0    0      01:11:22        4
192.23.23.2     4   100      53      56               15       0    0      00:48:07        1
192.26.26.2     4   200      41      44               15       0    0      00:36:46        1
 
PE-1#sh ip route vrf  TAURUS bgp
     192.23.23.0/30 is subnetted, 1 subnets
B       192.23.23.0 [200/0] via 2.2.2.2, 00:25:32
     10.0.0.0/32 is subnetted, 2 subnets
B       10.3.3.3 [20/0] via 192.13.13.2, 00:35:30
B       10.5.5.5 [200/0] via 2.2.2.2, 00:33:03
 
PE-1#show ip route vrf CINDY bgp
     192.26.26.0/30 is subnetted, 1 subnets
B       192.26.26.0 [200/0] via 2.2.2.2, 00:27:05
     10.0.0.0/32 is subnetted, 2 subnets
B       10.6.6.6 [200/0] via 2.2.2.2, 00:32:36
B       10.4.4.4 [20/0] via 192.14.14.2, 00:34:51
 
PE-1#show ip bgp vpnv4 all
BGP table version is 15, local router ID is 11.11.11.11
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
    Network          Next Hop                    Metric LocPrf   Weight  Path
Route Distinguisher: 1:100 (default for vrf TAURUS)
*> 10.3.3.3/32      192.13.13.2                    0                 0 100 i
*>i10.5.5.5/32      2.2.2.2                        0     100         0 100 i
*> 192.13.13.0/30   0.0.0.0                        0              32768 ?
*>i192.23.23.0/30   2.2.2.2                        0     100         0  ?
Route Distinguisher: 1:200 (default for vrf CINDY)
*> 10.4.4.4/32      192.14.14.2                    0                 0 200 i
*>i10.6.6.6/32      2.2.2.2                        0     100         0 200 i
*> 192.14.14.0/30   0.0.0.0                        0              32768 ?
*>i192.26.26.0/30   2.2.2.2                        0     100         0  ?
 
 
TAURUS-Site_A#ping 10.5.5.5
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 456/696/972 ms


El prefijo 10.5.5.5 (desde el router TAURUS-Site_B) es recibida y alcanzada mediante ping desde el  router TAURUS-Site_A, sin problemas.


Referencias

Cisco IOS IP and IP Routing Command Reference
Configuring Basic MPLS VPN
Cisco IOS Multiprotocol Label Switching Configuration Guide
Cisco MPLS Support Page
Cisco BGP Support Page