WAN : Frame Relay

Configurando o Frame Relay Traffic Shaping em 7200 roteadores e plataformas mais baixas

16 Janeiro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (13 Novembro 2015) | Feedback


Índice


Introdução

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

Pré-requisitos

Requisitos

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

Componentes Utilizados

O Frame-Relay Traffic Shaping foi apoiado desde o Software Release 11.2 de Cisco IOS�.

É apoiado em Cisco 7200 Router e em plataformas mais baixa. O Distributed Traffic Shaping é apoiado em Cisco 7500 Router, em 7600 Router, e em módulo FlexWAN.

Convenções

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. Alta velocidade às más combinações de baixa velocidade do circuito: Há duas possibilidades:

    • A instalação de hub tem uma linha T1 na nuvem, quando o local remoto tiver uma velocidade mais baixa (56 kbps). Neste caso, você precisa o taxa-limite a instalação de hub de modo que 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. Sobreassinatura: Por exemplo, se a taxa garantida em uns Circuitos Virtuais Permanentes (PVC) é 64 kbps e a taxa de acesso é os kbps 128 no ambas as extremidades, é possível estourar acima da taxa garantida quando não há nenhumas congestão e queda de volta à taxa garantida quando há uma congestão.

  3. Qualidade de Serviço: Para executar a fragmentação FRF.12 ou os recursos de enfileiramento de latência baixa para conseguir o melhor qualidade do serviço, veja o VOIP sobre o Frame Relay com Qualidade de Serviço.

Nota: A taxa de acesso é a velocidade de linha física da relação que conecta ao Frame Relay. A taxa garantida é a taxa de informação comprometida (CIR) que o telco deu para o PVC. Ajustar o CIR ou o mincir na taxa de acesso deve ser evitado, porque pode conduzir às quedas de emissor, fazendo com que o tráfego estrangule. A razão para esta é que a taxa da forma não leva em consideração os bytes de carga adicionais da bandeira e dos campos da verificação de redundância cíclica (CRC). Assim, dar forma na linha taxa oversubscribing realmente, e causará o congestionamento de interface. Dar forma na taxa de acesso não é recomendado. Você deve sempre dar forma ao tráfego em 95 por cento da taxa de acesso. Mais geralmente, a taxa dada forma agregada deve ser não mais de 95 por cento da taxa de acesso.

Configurar

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

Nota: Para localizar informações adicionais sobre os comandos utilizados neste documento, utilize a ferramenta IOS Command Lookup.

Diagrama de Rede

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

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151.gif

No exemplo acima, nós temos os seguintes valores:

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

  • Taxa de acesso remoto = 64Kbps, taxa garantida = 32Kbps

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.

Nota: O Frame-Relay Traffic Shaping é permitido na interface principal, e aplica-se a todos os identificadores da conexão de link de dados (DLCI) sob essa relação. 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

Hub
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 
!

Remoto
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 que está sendo enviado fora do roteador de hub:

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151a.gif

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 sete intervalos seguintes é somente Bc = 8000 bit. Portanto, a taxa é 8000 / 125 mseg = 64 Kbps.

Por exemplo, se nós recebemos uma explosão de 88000 bit, nós não podemos enviar todo este tráfego em 8 intervalos Tc. Os 8000 bits finais serão enviados no 9º intervalo de Tc. Assim, este 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

dar forma inativo/active

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. Os BECN são recebidos, e o DLCI foi configurado para dar forma aos BECN.

  2. O número de bytes de dados a transmitir fora de uma relação é mais do que o crédito disponível (limite de byte) em um dado intervalo (Tc).

  3. A fragmentação FRF.12 foi configurada, e os pacotes estão esperando para ser 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). Estes pacotes e bytes são armazenados na fila moldada (atribuída pelo VC) e transmitidos então nos intervalos subsequente quando há bastante crédito disponível.

gotas do 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. À revelia, o tipo de fila é FCFS (First Come First Serve) ou FIFO, mas pode ser mudado ao WFQ, ao PQ, ao CQ, ao CBWFQ, ou ao LLQ. Veja a seção da “informação relacionada” para documentos em configurar mecanismos fancy queuing em PVC do Frame Relay.

Parâmetros configuráveis

frame relay cir

A taxa média desejada para envio de tráfego em um determinado PVC em bps. Geralmente, essa taxa é mais alta do que a taxa garantida, mas inferior à taxa de acesso (AR). Equivale a uma taxa garantida apenas se:

  1. O provedor de serviços não permite enviar acima da taxa garantida.

  2. A taxa "de linha física" da interface é a mesma da taxa garantida.

  3. Há pacotes de voz (voz sobre IP [VOIP] ou voz sobre Frame Relay [VOFR]) nesta PVC, portanto, não é possível aceitar pacotes descartados para fins de qualidade ou serviço.

O valor do CIR é 56000 bps é à revelia.

frame relay mincir

A taxa garantida real obtida a partir do provedor de serviços em bps. Esse valor deve ser a taxa mínima a ser descartada em caso de congestionamento (o descarte abaixo dessa taxa impedirá que você obtenha a largura de banda pela qual está pagando). Em certos casos (listados acima) os valores mincir e cir devem ser iguais. O valor de mincir é metade do valor de CIR em bps, por padrão.

Frame Relay bc

A quantidade de dados a ser enviada a cada intervalo Tc em bits. Idealmente para dados PVCs Bc = CIR/8, de maneira que Tc = 125mseg. O Cisco IOS volta a calcular o parâmetro de FRTS quando é Bc maior de 10,000 bytes. Se nós estamos fazendo a Voz no PVC, a seguir Bc = o CIR/100 é preferível, de modo que o intervalo Tc = 10msec (como pacotes de voz não pode tolerar um atraso mais longo). O valor de Bc é mostrado à revelia como o CIR nos bit na saída do comando show traffic-shape. Contudo, internamente, um valor diferente é atribuído para assegurar o desempenho ótimo. Este valor é mostrado do “na coluna dos bytes incremento” na saída da tráfego-forma da mostra. Um valor do bc=CIR iguala a um Tc de 1 segundo. Segundo como o tráfego chega no shaper, o roteador teria que parar a transmissão para perto 1 segundo se a explosão foi esgotada imediatamente no início do intervalo. Assim, o shaper atribui um valor interno diferente que ainda permita configurado Bc sobre o Tc original, simplesmente nós o faremos em um número de explosões pequenas em vez de uma grande explosão.

o Frame Relay seja

A quantidade de excesso de dados permitida para envio durante o primeiro intervalo de Tc em bits, após o aumento do crédito. Configure Be only se o valor CIR de Frame Relay for menor que AR. Para os PVC que levam pacotes de voz, ser deve ser ajustado a zero para assegurar a Qualidade de voz melhor possível. O roteador emite bursts (Be) apenas quando há tokens no bucket de token. O Token Bucket não aumenta tokens a menos que a quantidade de tráfego que está sendo mandada for menos do que o CIR. O roteador pode somente estourar para o primeiro Tc, depois do qual o Token Bucket está vazio. Por padrão, o valor de Be by é de zero bits.

frame relay adaptive-shaping becn

Implica que o PVC adapta a taxa de transmissão em resposta aos BECNs recebidos. O comportamento é como abaixo:

  • Se o PVC recebe algum BECN durante o intervalo de horas atual (não importa se este é um ou 1000) que a taxa transmitir está diminuída por 25 por cento ou ao mincir e para se o valor configurado do mincir é mais de 75% do valor cir.

  • Ela continua caindo a cada BECN (limite uma queda por intervalo de tempo) até que a taxa de tráfego chegue a mincir (taxa garantida), onde pára.

  • Uma vez reduzida a taxa de tráfego, deve haver 16 intervalos de tempo sem o recebimento de BECNs antes de iniciar o aumento do tráfego novamente. A quantidade que aumenta por é o limite de byte que aparece na saída do show frame pvc x dividida por 16. Este aumento ocorre somente se o modelagem de tráfego é ativo. Assim, toma muito mais por muito tempo para receber de volta ao CIR do que fez para deixar cair ao mincir.

Parâmetros não configuráveis

intervalo (Tc)

O intervalo durante que você envia Bc os bit a fim manter a taxa média do CIR nos segundos.

Tc = Bc/CIR in seconds

O intervalo de Tc é entre 10 ms e 125 ms. O roteador internamente calcula este valor baseado no CIR e Bc nos valores no map class. Se o Bc/CIR é igual ou maior que 125 ms, ele utiliza um valor Tc interno. Se Bc/CIR for menor que 125 ms, ele utiliza o Tc calculado a partir daquela equação.

acréscimo de bytes

O número real de bytes comprometidos enviado pelo Tc. Podemos fazer o cálculo utilizando a fórmula a seguir:

Cir * Tc / 8

limite de bytes

O número de bytes real enviado no primeiro Tc. Podemos fazer o cálculo utilizando a fórmula a seguir:

byte increment + Be/8 (measured in bytes)

Troubleshooting

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 6151