Configurando o CBWFQ em PVCs de Frame Relay

Introduction

Este documento oferece configurações de exemplo para o CBWFQ (Enfileiramento Justo e Ponderado Baseado em Classes) de uma interface Frame Relay. O CBWFQ é habilitado com o comando de largura de banda, conforme configurado em um mapa de políticas com os comandos do QoS CLI modular (Qualidade de Serviços – Interface de Linha de Comando).

Antes de Começar

Conventions

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

Prerequisites

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

Componentes Utilizados

O CBWFQ é suportado a partir das seguintes versões do software Cisco IOS®, dependendo da plataforma:

• Cisco 7500 Series com VIP (Processadores de Interface Versáteis) (CBWFQ distribuído) - 12.1(5)T

• Cisco série 7200, séries 2600/3600 e outras plataformas não da série 7500 - 12.1(2)T

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Modelagem e enfileiramento

O enfileiramento é geralmente usado no contexto da modelagem, o que reduz a taxa de saída e, portanto, induz o congestionamento. Use CBWFQ com os seguintes mecanismos e comandos de modelagem, dependendo da plataforma.

Cisco 7200, 3600, 2600 Series

O Cisco IOS 12.1(2)T apresenta suporte para CBWFQ nas plataformas 7200, 2600/3600 e em outras plataformas de Processador de Switch não RSP (non-Route Switch Processor). (Para obter mais informações, consulte LLQ (Low Latency Queueing) sobre Frame Relay.) Nessas plataformas, o CBWFQ nas interfaces do Frame Relay está sempre no contexto de TS do Frame Relay. Use o comando frame-relay traffic-shaping para habilitar o TS do frame relay. Não é possível usar CBWFQ com GTS (Generic Traffic Shaping) e o comando de modelagem dessas plataformas. Uma configuração de exemplo é fornecida a seguir.

 policy-map mypolicy 
  class voice 
   priority 16 
  class priority-data 
   bandwidth 16 

!--- Create a policy-map and apply the bandwidth !--- command to a class. 

! 
 int s0/0 
  encapsulation frame-relay IETF 
  load-interval 30 
  frame-relay traffic-shaping 

!--- Enable Frame Relay TS. 

! 
 interface Serial0/0.1 point-to-point 
  frame-relay interface-dlci 100 
    class frclass 

!--- Apply the map-class to the Frame Relay PVC. 

! 
 map-class frame-relay frclass 
  service-policy output mypolicy 
  frame-relay cir 64000 
  frame-relay bc 640 

!--- Apply the service policy inside the map-class.

Observação: se você habilitar uma política de serviço diretamente em uma interface principal e não em um comando map-class, também não será possível aplicar o Frame Relay TS diretamente à interface. É importante observar que os mecanismos de enfileiramento se aplicam a uma única fila de interface grande em vez de a filas por circuito virtual (VC)

No Cisco 7200 Series, a partir do Cisco IOS Software versão 12.0(26)S e posterior, não é mais possível configurar uma política de serviço de saída em um comando frame-relay map-class. Em vez disso, a configuração do Cisco 7500 deve ser aplicada conforme explicado na seção a seguir. Um mapa hierárquico de políticas deve ser configurado com modelagem em uma política pai e enfileiramento em uma política filho. A política pai deve então ser anexada à interface principal ou à subinterface. Se você tentar configurar uma saída de política de serviço no comando map-class frame-relay, a seguinte mensagem de erro será exibida:

c7200(config)#map-class frame-relay
	 stef
c7200(config-map-class)#frame-relay cir
	 64000
c7200(config-map-class)#service-policy output
	 aan
Frame relay output service policy is not
	 supported

Cisco 7500 Series

A partir do Cisco IOS 12.1(5)T, as políticas de QoS devem ser executadas no modo distribuído no VIP; porque a QoS baseada em RSP não é mais suportada. Assim, você deve usar o comando shape e outros comandos da CLI de QoS modular para implementar DTS para interfaces de Frame Relay em VIPs na série Cisco 7500. DTS combina GTS e Frame Relay TS. Uma configuração de exemplo é fornecida em Configuring Distributed Traffic Shaping (Configurando modelagem de tráfego distribuído) e abaixo.

ip cef distributed 
 !  
 class-map 1  
   match < >  

!--- Define match-on criteria.

 class-map 2  
   match < >

!--- Define match-on criteria.

 !  
 policy-map CBWFQ  
   class 1  
     bandwidth < >  
     !-- Define value in kbps or percent.  
   class 2  
     priority < > 
 
!--- Define value in kbps or percent.

 !  
 Policy-map SHAPE  
    class class-default  
     shape average    
     service-policy CBWFQ  
 !  
 int s0/0/0  
   encapsulation frame-relay  
   ip route-cache distributed  
 !  
 int s0/0/0.1 point-to-point  
   ip address a.b.c.d  
   frame-relay interface-dlci xxx  
    class cisco  
 !  
 map-class frame-relay cisco  
   service-policy output SHAPE

Escolha de onde aplicar uma política de serviço

Ao configurar o CBWFQ, você usa os comandos do modular QoS CLI para criar um mapa de política de tráfego com várias classes de tráfego e um ou mais recursos de QoS. Nas versões atuais do Cisco IOS Software, as interfaces do Frame Relay suportam a aplicação de um mapa de política com o comando service-policy às interfaces, subinterfaces e VCs. Apenas as combinações corretas de políticas são suportadas agora. A tabela seguinte descreve especificamente onde é possível aplicar uma política de QoS com modelagem de tráfego.

Problemas conhecidos

Ao configurar CBWFQ em interfaces Frame Relay, observe as seguintes advertências:

• Após o recarregamento de um roteador, os contadores de correspondência de pacotes de uma política de serviço talvez não sejam incrementados quando a política for aplicada à interface principal. Para solucionar esse problema, certifique-se de que os flags de classificação de WFQ (Weighted Fair Queueing) sejam copiados da interface principal para as subinterfaces.

• Não há suporte para configuração do LLQ e do Frame Relay TS ao mesmo tempo no nível de interface física. O roteador remove a política de serviço da configuração em execução após o recarregamento de um roteador. A política de serviço deve ser anexada à classe de mapa quando o TS do Frame Relay estiver ativado na interface. A tentativa de configurar esta combinação resulta na mensagem de erro CBWFQ: Não é suportado nesta interface.

• Quando uma política de serviço com CBWFQ é aplicada diretamente a uma interface principal do Frame Relay (como, enfileiramento não por VC), a política pode ser removida após uma recarga do roteador se as instruções de largura de banda estiverem configuradas em uma subinterface e em uma interface principal. O roteador pode relatar mensagens de registro semelhantes às seguintes:

  CBWFQ: Not enough available bandwidth for all classes Available 44 (kbps) 
      Needed 1 00 (kbps)
      CBWFQ: Removing service policy on Serial1/0

  Esse problema é resolvido alterando o comportamento do CBWFQ para ignorar as notificações quando a largura de banda na subinterface é alterada, já que o CBWFQ pode ser configurado fora de uma classe de mapa do Frame Relay somente no nível da interface principal. Como solução alternativa, remova o comando bandwidth da subinterface. Se estiver usando largura de banda na subinterface para influenciar a métrica de roteamento, use um método alternativo como custo, como no protocolo OSPF ou retardo, como no protocolo EIGRP.

Notas de configuração

• Quando os comandos de largura de banda e prioridade calculam a quantidade total de largura de banda disponível em uma entidade, as seguintes orientações são invocadas quando a entidade é modelada como um PVC (circuito virtual permanente) do Frame Relay:

  • Se uma Minimum Acceptable Committed Information Rate (minCIR) não estiver configurada, o CIR é dividido em dois.

  • Se um minCIR estiver configurado, a definição do minCIR será usada no cálculo.

  • A largura de banda completa da taxa descrita acima pode ser atribuída a classes de largura de banda e de prioridades. Portanto, o comando max-reserved-bandwidth não é suportado em PVCs de Frame Relay, embora você deva garantir que a quantidade de largura de banda configurada seja grande o suficiente para acomodar também o overhead da Camada 2 (L2). Para obter mais informações, consulte What Bytes Are Counted by IP to ATM CoS Queueing?.

• Evite definir a CIR ou minCIR na taxa de acesso. Caso contrário, você pode ver filas de saída aumentando e gerando grandes retardos nas classes CBWFQ. A razão é que a taxa de forma não leva em consideração os campos de bytes de overhead do flag e Verificação de redundância cíclica (CRC), portanto a modelagem na taxa de linha está, na verdade, com excesso de assinaturas e provocará o congestionamento da interface. Realmente não há motivo para moldar a taxa de acesso. Você deve sempre definir a forma de tráfego a 95% da taxa de acesso ou, mais genericamente, a taxa modelada agregada deve estar sempre 95% abaixo da taxa de acesso.

• Quando o FRF.12 está configurado, o tamanho da fila de saída aumenta para acomodar o mesmo número de bytes que estão fragmentados agora. Em outras palavras, você vai de uma fila de pacotes para uma fila de fragmentos.

• O WFQ por VC está incluso no Software Cisco IOS versão 12.0(7)T.

• O CBWFQ com GTS está incluído no Cisco IOS Software versão 12.1(2)T.

Informações Relacionadas

• página de suporte de QoS
• Suporte Técnico - Cisco Systems