Voz : H.323

VoIP over Frame Relay con los PVC de múltiples puntos y el priorización

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento discute el modelado de tráfico y el priorización para una voz sobre IP (VoIP) sobre la red Frame Relay con el topologia Hub y Spoke. La configuración del concentrador es tal que hay dos circuitos virtuales permanentes (PVC), uno para cada conexión remota, y ambos datos y Voz se envían sobre los mismos PVC. Es importante observar que el priorización y la fragmentación discutidos en este documento se aplica no sólo a este escenario pero también a un escenario donde usted puede tener un PVC con la Voz y los datos y otro con solamente los datos. Los PVC de datos necesitan tráfico-ser formados apenas como la Voz y los PVC de datos. Esto es debido al hecho de que cuando un solo tubo físico se comparte, en este caso en el concentrador, el retraso de serialización afecta a todos los datos.

En la topología abajo, Nueva York representa al router central del concentrador. El Raleigh y el San José representan a los routeres remotos conectados con el concentrador a través de una red Frame Relay. Hay dos PVC que conectan con router New York. En este caso, Nueva York debe nunca enviar más de 64 kbps al Raleigh y además, él deben nunca enviar más de 192 kbps al San José porque éste excede la Velocidad de información comprometida (CIR) configurada en los mapclass del Frame Relay.

En la topología mostrada en este documento, el Routers con las Configuraciones de VoIP está conectado directamente con una nube de Frame Relay. En algunas topologías, sin embargo, el Routers activado mediante la voz puede existir dondequiera en la red, a excepción del Cisco AS5300. Para más información sobre esto, refiera a la nota proporcionada. El Routers de la Voz puede ser conectado con la conectividad LAN con el otro Routers que está conectado con WAN. Esto es importante observar porque si su Routers de la Voz no está conectado directamente con un servicio de Frame Relay, configuran a todos los comandos configuration de la conectividad WAN en eso Routers que esté conectado con WAN, y no en el Routers de la Voz.

Nota:  No diseñan a los Cisco AS5300 Router con las interfaces en serie de alta velocidad a la conexión de datos de soportear datos a WAN. Usted necesita utilizar su Cisco AS5300 como routeres LAN intermedios con la funcionalidad principal para procesar las llamadas de voz. Usted necesita a los routeres dedicados actuar como conexiones directas a WAN.

prerrequisitos

Requisitos

Antes de que usted intente esta configuración, asegúrese de que usted resuelva estos requisitos previos:

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Tres Cisco 3640 Router con el Enterprise Plus del Software Release 12.3(5) del ½ del ¿Â de Cisco IOSïÂ

  • Cuatro teléfonos analógicos conectados con los puertos de la Estación de intercambio remota (FXS) en el spokes

  • Un PBX conectado con a controlador T1 en el router de eje de conexión

El spokes puede también ser un Cisco 2600 o una plataforma 1750. El concentrador puede ser un Cisco 2600 o una plataforma 3600 en el caso de voz digital, pero puede también ser una plataforma del Cisco 1750 si solamente la voz analógica existe en el concentrador. Todo el modelado de tráfico y configuraciones se aplican a otras Plataformas también.

Nota: Aunque este documento no se restringe al software específico, algunos de los comandos usados aquí no están disponibles con todas las versiones del Cisco IOS Software. Por ejemplo, una imagen IP soporta al comando frame-relay fragment con el IP Plus pero no.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Configurar el modelado de tráfico y el priorización para un VoIP over Frame Relay

Cuando usted ejecuta el VoIP over Frame Relay, es importante que el tráfico enviado sobre la trama permanece en un nivel que sea inferior o igual el CIR del Frame Relay. El router no envía el tráfico que excede el CIR cuando está configurado con el Control de tráfico de Frame Relay (FRTS) como se muestra. Si usted configura al router para ejecutarse en una velocidad mayor que el CIR, usted puede experimentar los problemas de calidad de voz, y la Calidad de voz no se garantiza cuando usted ejecuta los PVC sobre el CIR garantizado.

Nota: Es posible configurar el modelado adaptable para permitir a un router para estrangular abajo de la velocidad de transmisión a un valor especificado si los paquetes de Frame Relay se reciben con el conjunto de bits del Notificación explícita de la congestión hacia atrás (BECN). Le aconsejan que sin embargo, esas relaciones del tráfico no son exceder el CIR del servicio de Frame Relay cuando se transmiten los paquetes de voz. Éste es asegurar la calidad adecuada y la salida cuando los paquetes de la voz en tiempo real se envían a través de la red. La configuración donde se excede el CIR se recomienda solamente para los PVC de datos que no llevan el tráfico de voz.

Nota: También, antes de que usted pueda configurar a su router para utilizar el VoIP, es el mejor si usted entiende las características del Calidad de Servicio (QoS) en Cisco IOS Software. Para aprender más sobre las características de QoS, refiera a los Datos en espera, modelado de tráfico, y filtración y fragmentación para la Voz.

Nota: Use la herramienta Command Lookup Tool (clientes registrados solamente) para encontrar más información sobre los comandos usados en este documento.

Diagrama de la red

Este documento utiliza la configuración de la red mostrada en el diagrama aquí:

/image/gif/paws/12162/voip_fr_mp_1.gif

Configuraciones

En este documento, se utilizan estas configuraciones:

Router de eje de conexión de Nueva York
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname newyork
!
logging buffered 50000 debugging
enable secret < password > [Choose a strong password with 
at least one capital letter, one number, and one special character.]
!
controller T1 2/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-4 type e&m-wink-start
!
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay traffic-shaping

!--- This CLI command enables traffic shaping for both PVCs.

!
interface Serial2/0.1 point-to-point
description Connection to Raleigh PVC
ip address 172.16.120.2 255.255.255.0
  frame-relay interface-dlci 100
  class class-raleigh
!
interface Serial2/0.2 point-to-point
description Connection to San Jose PVC
ip address 172.16.130.2 255.255.255.0
frame-relay interface-dlci 200
  class class-sanjose
!
ip classless
!
map-class frame-relay class-raleigh
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80

!--- Recommended fragment size for 10ms delay when carrying voice
!--- traffic based on the configured CIR 64000.
!--- based on the configured CIR 64000

 frame-relay ip rtp priority 16384 16383 48

!--- Two calls with g729, no CRTP, at 24 kbps/each.

 !
map-class frame-relay class-sanjose
 frame-relay cir 192000
 frame-relay bc 1920
 frame-relay be 0
 frame-relay mincir 192000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 240

!--- This is the recommended fragment size for 10ms delay when carrying voice traffic
!--- based on the configured CIR 192000.

frame-relay ip rtp priority 16384 16383 48 

!--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach.

!
!
voice-port 2/0:1
!
dial-peer cor custom
!
dial-peer voice 100 pots

!--- Calls to the Public Switched Telephone Network (PSTN).

 destination-pattern 212.......
prefix 212
port 2/0:1
!
dial-peer voice 200 pots

!--- Calls to the corporate network-four digit extension forwarded.

destination-pattern 567....
 port 2/0:1
!
dial-peer voice 110 voip

!--- Calls to Raleigh.

destination-pattern 919392....
session target ipv4:172.16.120.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
dial-peer voice 210 voip    
!--- Calls to San Jose.

destination-pattern 408527....
session target ipv4:172.16.130.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end  

Presentaron al comando ip qos dscp en IOS version12.2(2)T de substituir el comando ip precedence (dial-peer).

El comando frame-relay ip rtp priority reserva una cola de prioridad estricta para un conjunto de los flujos de paquetes del Real-Time Protocol (RTP) que pertenezca a un rango de los puertos destino del User Datagram Protocol (UDP).

Nota: Porque el comando frame-relay ip rtp priority da la prioridad absoluta sobre el otro tráfico, utilice este comando con el cuidado. En caso de congestión, si el tráfico excede el configuré el ancho de banda, después se cae todo el tráfico en exceso.

Raleigh del Cisco 3640
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname raleigh3640a
!

logging buffered 50000 debugging
enable secret < password > [Choose a strong password with at 
least one capital letter, one number, and one special character.]
!
no ip subnet-zero
!
!
!
!
voice-port 1/0/0
!
voice-port 1/0/1
dial-peer voice 1 pots
 destination-pattern 9193924100
port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 2126789001
  ip qos dscp cs5 media
 dtmf-relay h245-alphanumeric
 session target ipv4: 172.16.120.2 
!

interface Loopback0
 ip address 172.16.125.1 255.255.255.255
 no ip directed-broadcast
!

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.1 point-to-point
description Connection to New York
 ip address 172.16.120.1 255.255.255.0

 frame-relay interface-dlci 100
  class fr_class_voip  
!
!
ip classless
no ip http server
!
!
map-class frame-relay fr_class_voip
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment  80


!--- The recommended fragment size for 10ms delay when carrying voice traffic.


!--- based on the configured CIR 64000.


  frame-relay ip rtp priority 16384 16383 48
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Verificación

Esta sección proporciona la información que usted puede utilizar para confirmar sus trabajos de la configuración.

La herramienta Output Interpreter (sólo para clientes registrados) permite utilizar algunos comandos “show” y ver un análisis del resultado de estos comandos.

  • show frame-relay fragment — Visualiza la información sobre la fragmentación de Frame Relay que ocurre en el router Cisco.

  • muestre la cola de la tráfico-dimensión de una variable — Información de las visualizaciones sobre los elementos hechos cola en el nivel del identificador de conexión de link de datos del virtual circuit (VC) (DLCI). Se utiliza este comando de verificar el funcionamiento de la prioridad IP RTP sobre el Frame Relay. Cuando se congestiona el link, los flujos de la voz se identifican con un peso igual a cero. Esto indica que el flujo de la voz está utilizando el priority queue. Refiera a la salida de muestra proporcionada.

  • [dlci-] pvc del show frame-relay — Visualiza la información tal como parámetros de modelado del tráfico, valores de fragmentación, y paquetes perdidos. Refiera a la salida de muestra proporcionada aquí y también refiera al Guía exhaustiva al Configurando y Troubleshooting Frame Relay para más información.

newyork#show frame-relay fragment

interface   dlci   frag-type   frag-size   in-frag   out-frag   dropped-frag
 
Serial1/0.1 100    end-to-end    80          16        20           0 

Serial1/0.2 200    end-to-end    240         12        10           0 

newyork#show traffic-shape  serial 2/0.1
Interface Se2/0.1

     Access    Target   Byte   Sustain   Excess   Interval    Increment    Adapt
VC   List      Rate     Limit  bits/int  bits/int (ms)        (bytes)      Active

100            64000    80     640       0         10          80          -
  
newyork#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0.1 dlci 100
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
     Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 16 kilobits/sec

Traffic queued in shaping queue on Serial2/0.2 dlci 200
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
    Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 144 kilobits/sec

newyork#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1

input pkts 1078          output pkts 1078         in bytes 157792
out bytes 172284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 28        out bcast bytes 8498
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:27:48, last time pvc status changed 00:27:48
Queueing strategy: weighted fair
Current fair queue configuration:
	Discard     Dynamic      Reserved
	threshold   queue count  queue count
		64          16           0
Output queue size 0/max total 600/drops 0
fragment type end-to-end        fragment size 80
cir 64000     bc   640       be 0         limit 80     interval 10
mincir 64000     byte increment 80    BECN response no  IF_CONG no
frags 2707      bytes 172284    frags delayed 2707      bytes delayed 172284
shaping inactive
traffic shaping drops 0
ip rtp priority parameters 16384 32767 48000

Troubleshooting

En esta sección encontrará información que puede utilizar para solucionar problemas de configuración.

Procedimiento de Troubleshooting

Aquí está la información de Troubleshooting y las instrucciones relevantes a esta configuración:

  1. Resuelva problemas el Frame Relay y al QoS implementados para la Voz y asegure su operación correcta.

  2. Proceda al Troubleshooting de fallas de la llamada de voz cuanto sea necesario.

    Nota: Para una información de Troubleshooting más detallada, refiera al VoIP over Frame Relay con QoS (fragmentación, modelado de tráfico, prioridad de RTP LLQ/IP).

Comandos para resolución de problemas

La herramienta Output Interpreter Tool (clientes registrados solamente) (OIT) soporta ciertos comandos show. Utilice la OIT para ver un análisis del resultado del comando show.

Nota: Consulte Información Importante sobre Comandos de Debug antes de usar un comando debug.

  • prioridad del debug — Visualiza los eventos del Asignación de colas de prioridad (PQ) y muestra si un descenso ocurre en esta cola. Para obtener más información, consulte ppSolución de problemas de caídas de salidas con cola prioritaria.

  • debug frame-relay fragment — Visualizaciones evento o mensajes de error relacionados con la fragmentación de Frame Relay. Este comando se habilita solamente en el nivel PVC en la interfaz seleccionada.

    newyork#debug priority 
    Priority output queueing debugging is on
    newyork#ping 172.16.120.1
    Type escape sequence to abort. 
    Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: 
    !!!!! 
    Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
    newyork# 
    *Mar  1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2)
    *Mar  1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) 
    *Mar  1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2)
    *Mar  1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) 
    *Mar  1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) 
    *Mar  1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) 
    
    newyork#debug frame-relay fragment interface serial 2/0 100
    This may severely impact network performance.
    You are advised to enable no logging console debug. Continue?[confirm]
    Frame Relay fragment/packet debugging is on
    Displaying fragments/packets on interface Serial2/0 dlci 100 only
    
    *Mar  1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, 
    B bit set, frag_hdr 03 B1 9C 3D
    *Mar  1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, 
    E bit set, frag_hdr 03 B1 5C 3E
    *Mar  1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, 
    exp_seq-num 17,B bit set,
    	 frag_hdr 03 B1 80 11
    *Mar  1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, 
    exp_seq-num 18,E bit set,
    	 frag_hdr 03 B1 40 12

Información Relacionada


Document ID: 12162