Configuração da formatação de tráfego frame relay nos roteadores 7200 e nas plataformas inferiores

Introduction

Este documento fornece uma configuração de exemplo de modelagem de tráfego de Frame Relay.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

A modelagem de tráfego Frame Relay é suportada desde o Cisco IOS® Software Release 11.2.

Ele é suportado em roteadores Cisco 7200 e plataformas inferiores. A modelagem de tráfego distribuído é suportada nos roteadores Cisco 7500, nos roteadores 7600 e no módulo FlexWAN.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

As implementações comuns de modelagem do tráfego Frame Relay são:

1. Incompatibilidades entre circuitos de alta velocidade e baixa velocidade: Há duas possibilidades:

   • O local do hub tem uma linha T1 na nuvem, enquanto o local remoto tem uma velocidade mais baixa (56 Kbps). Nesse caso, você precisa limitar a taxa do local do hub para que ele não exceda a taxa de acesso do lado remoto.

   • A instalação do hub tem uma única linha T1 para a nuvem, enquanto as instalações remotas têm uma linha T1 completa para dentro da nuvem, conectando-se à mesma instalação do hub. Nesse caso, você precisa limitar as taxas das estações remotas para não sobrecarregarem o hub.

2. Excesso de assinatura: Por exemplo, se a taxa garantida em um PVC (Permanent Virtual Circuit, circuito virtual permanente) for de 64 Kbps e a taxa de acesso for de 128 Kbps em ambas as extremidades, é possível estourar acima da taxa garantida quando não há congestionamento e recuar para a taxa garantida quando há congestionamento.

3. Qualidade de serviço: Para implementar a fragmentação FRF.12 ou os recursos de enfileiramento de baixa latência para obter melhor qualidade de serviço, consulte VoIP sobre Frame Relay com Qualidade de Serviço.

Observação: a taxa de acesso é a velocidade da linha física da interface conectada ao Frame Relay. A taxa garantida é a taxa de informação comprometida (CIR) fornecida pela Telco para o PVC. A definição de CIR ou minCIR na taxa de acesso deve ser evitada, pois pode resultar em quedas de saída, fazendo com que o tráfego diminua. A razão para isso é que a taxa de forma não leva em conta os bytes de sobrecarga dos campos flag e Cyclic Redundancy Check (CRC). Então, a modelagem na taxa de linha é na verdade uma sobreassinatura e causará congestionamento na interface. A modelagem na taxa de acesso não é recomendada. Você deve sempre moldar o tráfego em 95% da taxa de acesso. De modo mais geral, a taxa em forma agregada não deve ser superior a 95% da taxa de acesso.

Configurar

Nesta seção, você encontrará informações para configurar os recursos descritos neste documento.

Observação: para encontrar informações adicionais sobre os comandos usados neste documento, use a ferramenta IOS Command Lookup

Diagrama de Rede

Este documento utiliza a seguinte configuração de rede:

No exemplo acima, temos os seguintes valores:

• HUB - taxa de acesso = 192 Kbps, taxa garantida = 32 Kbps

• REMOTO - taxa de acesso = 64 Kbps, taxa garantida = 32 Kbps

Aqui, estamos implementando a modelagem de tráfego nas duas extremidades para que a taxa de transmissão média seja 64 Kbps. Se necessário, o HUB pode fazer burst acima disto. Em caso de congestionamento, ele pode abaixar até o mínimo de 32 Kbps. A notificação de congestionamento da rede é feita por Notificação de retorno de congestionamento explícito (BECN). Por isso, a modelagem é configurada para adaptar-se ao BECN.

Observação: a modelagem de tráfego Frame Relay está habilitada na interface principal e se aplica a todos os DLCIs (Data Link Connection Identifiers Identificadores de Conexão de Enlace de Dados) nessa interface. Não podemos habilitar a modelagem de tráfego apenas para um DLCI ou subinterface específico na interface principal. Se determinado DLCI não tiver nenhuma classe de mapa anexada e a modelagem de tráfego estiver habilitada na interface principal, será atribuída ao DLCI uma classe de mapas padrão com CIR=56000.

Configurações

Este documento utiliza as seguintes configurações:

• Hub

• Remoto

interface Serial0/0 
 no ip address 
 encapsulation frame-relay 
 no fair-queue 
 frame-relay traffic-shaping 

!--- Apply traffic shaping to main interface (step 3).
 
interface Serial0/0.1 point-to-point 
 ip address 10.1.1.1 255.255.255.0 
 frame-relay interface-dlci 16  
 frame-relay class cisco 

!--- Apply map class to the DLCI / subinterface (step 2).
 
! 
! 

!--- Configure map class parameters (step 1).
 
map-class frame-relay cisco 
 frame-relay cir 64000  
 frame-relay mincir 32000 
 frame-relay adaptive-shaping becn 
 frame-relay bc 8000 
 frame-relay be 16000 
!

interface Serial0/0 
no ip address 
encapsulation frame-relay 
no fair-queue 
frame-relay traffic-shaping 
! 
interface Serial0/0.1 point-to-point 
ip address 10.1.1.2 255.255.255.0 
frame-relay interface-dlci 16                            
frame-relay class cisco 
! 
map-class frame-relay cisco 
frame-relay cir 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 
frame-relay bc 8000 
!

Este diagrama mostra o tráfego sendo enviado do roteador HUB:

Assumindo-se que o tráfego seja enviado com uma intermitência de 80.000 bits, ele é enviado para fora do PVC em intervalos de 8 Tc (125 ms cada). Podemos chegar a isso porque, no primeiro intervalo, o crédito disponível é Bc + Be = 8000 + 16000 = 24000 bits. Isso significa que a taxa é 24.000 bits / 125 ms = 192 Kbps.

Nos próximos sete intervalos, é somente Bc = 8000 bits. Portanto, a taxa é 8000 / 125 mseg = 64 Kbps.

Por exemplo, se recebermos uma intermitência de 88000 bits, não poderemos enviar todo esse tráfego em intervalos de 8 Tc. Os 8000 bits finais serão enviados no 9º intervalo de Tc. Assim, esse tráfego é atrasado pelo mecanismo de modelagem de tráfego.

Verificar

Esta seção fornece informações que você pode usar para confirmar se sua configuração está funcionando adequadamente.

comandos show

A Output Interpreter Tool (somente clientes registrados) oferece suporte a determinados comandos show, o que permite exibir uma análise da saída do comando show.

Use o comando show frame relay pvc <dlci> para visualizar os detalhes da configuração:

Hub#show frame relay pvc 16
     PVC Statistics for interface Serial0/0 (Frame Relay DTE)
     DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
       input pkts 8743          output pkts 5            in bytes 2548330
       out bytes 520            dropped pkts 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 0         out bcast bytes 0
       Shaping adapts to BECN
       pvc create time 6d01h, last time pvc status changed 6d01h
       
cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 
      mincir 56000 byte increment 1000 Adaptive Shaping BECN 
      pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 
      shaping inactive 
      traffic shaping drops 0
 
       Queueing strategy: fifo 
       Output queue 0/40, 0 drop, 0 dequeued

moldando inativo/ativo

Isso mostra, em tempo real, se o mecanismo de modelagem de tráfego foi ou não ativado. A modelagem de tráfego está ativa nos seguintes cenários:

1. BECNs são recebidos e DLCI foi configurado para modelar para BECNs.

2. O número de bytes de dados a transmitir de uma interface é maior que o crédito disponível (limite de bytes) em um determinado intervalo (Tc).

3. A fragmentação FRF.12 foi configurada e os pacotes estão esperando para serem fragmentados.

pkts atrasados / bytes atrasados

Mostra o número de pacotes e bytes que foram atrasados devido à ativação do mecanismo de modelagem de tráfego. Isso se aplica principalmente se o número de bytes a ser transmitido exceder o crédito disponível por intervalo ou se os pacotes precisarem ser fragmentados (FRF.12). Esses pacotes e bytes são armazenados na fila de modelagem (alocados por VC) e transmitidos em intervalos subsequentes quando houver crédito disponível suficiente.

Perdas de modelagem de tráfego

Isso mostra o número de reduções na fila de modelagem. Os bytes são, primeiro, atrasados pelo mecanismo de modelagem e armazenados nessa fila. Se a fila for preenchida, os pacotes serão cancelados. Por padrão, o tipo de fila é FCFS (First Come First Serve) ou FIFO, mas pode ser alterado para WFQ, PQ, CQ, CBWFQ ou LLQ. Consulte as informações relacionadas