Telefonía IP

Un teléfono IP es como cualquier otro dispositivo en la red, necesita corriente para funciona que puede obtener de dos tipos de fuentes:

  1. un adaptador externo (AC)
  2. Power over Ethernet (DC) que se obtiene del cable de red.

El adaptador externo provee de 48V DC al teléfono y como cualquier adaptador se conecta a un enchufe. Tiene el problema que si la corriente se va el teléfono deja de estar operativo. También se puede usar este adaptador como fuente redundante.

Una solución es Power over Ethernet (PoE) que consiste en obtener la corriente del mismo cable que viene del switch por donde pasan voz, datos y corriente. Se obtienen los mismos 48V DC. Lógicamente deberemos tener el switch con fuentes redundantes para evitar perder el teléfono.

Un switch puede ofrecer corriente a un dispositivo solo si este está diseñado para recibirla. Los modelos 3750, 4500 y 6500 soportan PoE. Hay 2 métodos para proveer de PoE:

  • Cisco Inline Power (ILP) es un método propietario de Cisco desarrollado antes del estándar 802.3af.
  • IEEE 802.3af es un método estándar multiproveedor.

El switch siempre mantiene la corriente apagada cuando el puerto está down, pero siempre está intentando detectar si el dispositivo conectado soporta o requiere corriente.Si detecta un dispositivo que lo requiera entonces empezará a dar corriente para que el dispositivo se inicialice y esté operativo. Solo en ese momento se establece enlace (link).

Un Catalyst probará ambos métodos para detectar dispositivos. IEEE 802.3af suministra un pequeño voltaje a través de los pares de transmisión y recepción para medir la resistencia y ver si el dispositivo conectado altera el voltaje suministrado.  Si se mide una resistencia de 25K ohm entonces un dispositivo PoE está conectado.

El switch también puede aplicar varios voltajes predefinidos para comprobar con lo cual se puede determinar a que clase de las 5 que especifica IEEE 802.3af que son:

Clase Potencia máxima Nota
0 15,4W Clase por defecto
1 4,0W Clase opcional
2 7,0W Clase opcional
3 15,4W Clase opcional
4 hasta 50W Clase opcional (802.3at)

Corriente puede darse de 2 formas:

Cisco ILP: se provee 48V DC de corriente por los pares 2 y 3 (RJ-45 patilla 1,2 y 3,6)

IEEE 802.3af: se provee de igual forma o por los pares 1 y 4 (RJ-45 patillas 4,5 y 7,8).

Por defecto un puerto PoE siempre intenta detectar (configurado en modo auto) pero se puede configurar para que nunca lo haga, el comando de configuración es:

Switch(config)# interface type mod/num
Switch(config-if)# power inline {auto [max mili-watts] | static [max milli-watts] | never}

La potencia por defecto son 15,4W pero se puede especifica en max milli-watts (4000 a 15400).

Podemos configurar el puerto en modo static si el dispositivo conectado no puede interactuar con ninguno de los métodos de detección de dispositivos, indicando la potencia (por defecto 15.4W).

Si queremos desactivar PoE en el puerto con usar never nunca se suministrará corriente.

Para verificar el estado de un puerto PoE con el comando:

Switch# show power inline [type mod/num]

En esta salida nos indica un dato muy importante y es la potencia máxima que el switch puede ofrecer en global, además de la que ya se está usando y la que queda libre.

Cisco recomienda estos pasas para configurar voice VLAN:

  • Se debe configurar una voice VLAN en un puerto de acceso
  • La característica Port Fast se activa automáticamente con se configura voice VLAN. Pero CUIDADO no se desactiva automáticamente cuando se desactiva voice VLAN.
  • Si se activa Port Security se debe configurar el máximo número de MACs a 2 más las que queramos configurar ya que un teléfono IP requiere hasta 2 MACs.
  • Si cualquier tipo de Port Security se activa en la VLAN de acceso, se activa automáticamente  Dynamic Port Security en la VLAN de voz.
  • NO se puede configurar Port Security en base a VLANs.
  • NO se puede configurar direcciones de MAC Sticky o seguridad estática en una VLAN de voz.

Para configurar un puerto e indicar el modo de VLAN de voz que se usará:

Switch(config-if)# switchport voice vlan {vlan-id | dot1p | untagged | none}
Parámetro VLAN Nativa (Untagged) Vlan de Voz QoS de Voz (Bits CoS)
vlan-id PC Data Vlan vlan-id 802.1p
dot1p PC Data Vlan 0 802.1p
untagged PC Data/voice --- ---
none (default) PC Data/voice --- ---

Por defecto el modo es none en el cual no se usa trunk.

Podemos verificar el modo del puerto (access o trunk) y la VLAN de voz usando el comando:

show interface type mod/num switchport

Como salida de ejemplo (solo indico las líneas a fijarse):

...
Operational Mode: static access
...
Access Mode VLAN: 10 (VLAN0010)
...
Voice VLAN: 110 (VoIP)
...

Cuando el trunk de un teléfono IP está activo no se muestra en el modo trunk de ningún comando show, así que para verificarlo podemos mirar el STP que ejecuta dos instancias una para datos y otra para voz usando el comando:

show spanning-tree interface type mod/num

Para que la voz no se pierda por saturación debemos configurar Calidad de Servicio (QoS) y así proveer que siempre las llamadas de voz funcionen.

Dependiendo de la aplicación una perdida o retardo puede asumirse (por ejemplo una web) pero en una vídeo conferencia o llamada de voz puede ser algo que no se puede asumir o tolerar.

Hay tres cosas básicas que pueden ocurrir a los paquetes a lo largo de la red:

  • Delay: El envío de un paquete desde un dispositivo de red a otro tiene un retraso (delay) que puede ser causado por varios motivos (tiempo requerido para enviar los daros por el cable, la búsqueda en una tabla, tiempo en recorrer un espacio geográfico muy distante. El tiempo total de retraso desde que empieza hasta que termina se llama latencia. Para verlo más gráficamente es el tiempo desde que un usuario pulsa una tecla hasta que  aparece en el terminal.
  • Jitter: La cantidad de retraso entre paquetes de un mismo flujo pueden variar y por consiguiente no todos los paquetes llegan a un tiempo predecible, esta variación de retraso se llama Jitter. Por ejemplo el audio es muy susceptible al Jitter ya que si el audio no se reproduce a un ratio constante se oirá entrecortado.
  • Loss: En casos extremos los paquetes que entran en una zona de congestión o propensa a fallos son descartados sin entregarlos al destino. Una cantidad de paquetes perdidos es aceptable siempre que la aplicación use un protocolo fiable y orientado a conexión como TCP, pero hay aplicaciones no son tolerantes a paquetes descartados que significa perdida de información.

Podemos usar tres tipos básicos de calidad de servicio QoS:

En este tipo el dispositivo de red hace lo mejor posible para entregar el paquete a tiempo y por lo tanto es como si no hubiese Calidad de Servicio QOS.

Se reserva con antelación un ancho de banda para la aplicación.

DiffServ no requiere reserva de ancho de banda con antelación como en IntServ. QoS se gestiona dinámicamente aplicándolo en base a per-hop a un grupo de flujos similares. DiffServ también basa sus decisiones QoS en la información que contiene la cabecera de cada paquete.

Las tramas de Capa 2 en si mismas no tienen forma de indicar la prioridad o importancia de su contenido por lo que un switch solo puede transportar tramas de acuerdo con la "Entrega de Mejor Esfuerzo".

Sin embargo cuando las tramas se transportan por un Trunk entre switches éstas son encapsuladas añadiendo el TAG ID de la vlan y en esta encapsulación incluye un campo que indica la Clase de Servicio (CoS) de cada trama. Este campo puede ser usado en lso switches extremos para tomar decisiones de QoS. Una vez que la trama se desencapsula cuando sale del Trunk la información CoS se elimina y pierde.

Diferencias entre las 2 encapsulaciones de Trunk:

  • IEEE 802.1Q - Cada trama se marca con la Vlan Id usando 12 bits y un campo de usuario, que contiene 3 bits para indicar CoS que van de 0 (prioridad más baja) a 7 (más alta). Tramas de la Vlan Nativa al no estar marcadas reciben el CoS por defecto configurado en el switch que recibe la trama,
  • Inter-Switch Link (ISL) - Cada trama se marca con la Vlan Id usando 15 bits. tras el campo de Tpy hay un campo de usuario de 4 bits, los 3 más bajos se usan para el CoS. Al no ser estándar se copian los 3 bits de 802.1Q tal cual.

Clasificación de QoS de Capa 3 con DSCP

  • Class 0 - Por defecto, solo ofrece Entrega de Mejor Esfuerzo.
  • Class 1 a 4 - también llamadas niveles de servicio de envío asegurado (Assured Forwarding - AF), cuanto más alto mejor prioridad tiene el tráfico.
  • Class 5 - conocido como envío acelerado (Expedited Forwarding - EF), para paquetes de servicio muy especial (como tráfico de Voz).
  • Class 6 y 7 - llamados control de intrared y de red y controlan el tráfico de red. Generalmente usado para STP y protocolos de enrutado.

El perímetro formado por switches que no confían en QoS entrantes se llama Trust Boundary. AMPLIAR!!

  1. Activar QoS en el switch: 
    switch(config)# mls qos
  2. Definir el parámetro QoS que será de confianza: 
    switch(config)# interface type mod/num
switch(config-if)# mls qos trust {cos | ip-precedence | dscp}
    Generalmente para teléfonos IP de Cisco se debería elegir cos ya que el teléfono puede controlar los valores de cos en su TRUNK de 2 vlans con el switch.
  3. Hacer la confianza condicional: 
    switch(config-if)# mls qos trust device cisco-phone
  4. Indicar el teléfono IP como extender el perímetro de confianza: 
    switch(config-if)# switchport priority extend {cos value | trust}
    Por defecto, un switch instruye a un teléfono IP conectado a que considere el puerto del PC sin confianza (untrust). El teléfono sobre escribirá el valor de CoS a 0 (cero).

Podemos configurar un puerto de uplink para que sea de confianza así:

switch(config)# interface type mod/num
switch(config-if)# mls qos trust cos

Es una macro que proporciona lo siguientes tipos de configuración QoS:

  • Habilita QoS
  • Mapeado CoS-a-DSCP para marcado de QoS
  • Ajustes de colas de entrada y salida
  • Colas de prioridad estricta para tráfico de voz de salida
  • Establece el límite de confianza de un interface QoS.

Podemos usar estos comandos:

switch(config)# interface type mod/num
switch(config-if)# auto qos voip {cisco-phone | cisco-softphone | trust}

Importante: CEF debe estar activado ya que Auto-QoS usa Network Based Application Recognition (nBAR) para identificar varios tipos de tráfico y de aplicaciones (CEF es un requisito para nBAR). También es necesario que CDP está habilitado.

Para verificar usamos el comando:

switch)# show mls qos interface type mod/num

Si el puerto es de confianza, todo el tráfico enviado pro el teléfono IP se acepta con la información QoS intacta. Si el puerto es de no confianza, la información de QoS se sobre escribe.

Retro

Lugares

Redes

Sistemas

Varios