Asynchronous Transfer Mode (ATM) : Gerenciamento de tráfego ATM

Configurando fragmentação e intercalando o enlace (LFI) com Switches de ATM do campus

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento contém uma visão geral técnica da Fragmentação e Intercalação de Links (LFI) sobre um frame relay para conexão ATM Interworking (IWF) (conforme definido no Fórum de Frame Relay ou acordo FRF.8) e também uma configuração de exemplo de uso do LS1010 ou Catalyst 8500 como o dispositivo IWF na nuvem WAN. O LFI usa as características de fragmentação incorporadas do encapsulamento do protocolo multilink ponto a ponto (MLPPP) em ATM e Frame Relay para proporcionar uma solução de fragmentação e intercalação de ponta a ponta para links de baixa velocidade com larguras de banda de até 768 kbps.

Pré-requisitos

Requisitos

Este documento exige uma compreensão do seguinte:

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

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

Por que MLPPP sobre ATM e frame relay?

A fragmentação é uma técnica chave para controlar o retardo de serialização e a variação de retardo nos enlaces de velocidade baixa que levam o tempo real e o tráfego do tempo não real. O retardo de serialização é o retardo fixo exigido cronometrar um frame de voz ou de dados na interface de rede, e relaciona-se diretamente ao Clock Rate no tronco. Uma bandeira extra é precisada de separar os quadros para baixas velocidades de relógio e tamanhos do frame pequenos.

O LFI usa os recursos de fragmentação incorporados do MLPPP impedir o retardo e tremulação (variações no atraso) causado pelos grandes pacotes variável-feitos sob medida que estão sendo enfileirados entre relativamente pacotes de voz pequenas. Com LFI, os pacotes maiores do que um tamanho do fragmento configurado são encapsulados em um cabeçalho MLPPP. O RFC 1990leavingcisco.com define o cabeçalho MLPPP assim como o seguinte:

  • (B) o bit eginning do fragmento é um grupo de um campo de bit a 1 no primeiro fragmento derivado de um pacote PPP e grupo a 0 para todos fragmentos restantes do mesmo pacote PPP.

  • (E) o bit nding do fragmento é um grupo de um campo de bit a 1 no último fragmento e grupo a 0 para todos fragmentos restantes.

  • O campo de sequência é um número 24-bit ou 12-bit que seja incrementado para cada fragmento transmitido. À revelia, o campo de sequência é 24 bit por muito tempo, mas pode ser negociado para ser somente 12 bit com a opção de configuração LCP descrita abaixo.

Além do que a fragmentação, os pacotes sensíveis a retardo devem ser programados com prioridade adequada entre fragmentos de um pacote grande. Com fragmentação, o enfileiramento considerável tornado mais pesado (WFQ) torna-se “ciente” de se um pacote é parte de um fragmento ou é não-fragmentado. O WFQ atribui um número de sequência a cada pacote chegando e programa então os pacotes baseados neste número.

A fragmentação da camada 2 fornece uma solução superior a todas aproximações restantes em resolver do “o problema grande-pacote.” A tabela a seguir alista as vantagens e desvantagem de outras soluções potencial.

Solução potencial Vantagens Desvantagens
Aborte a transmissão do pacote grande e remeta-a atrás do tráfego sensível a retardo.
  • Adia somente a transmissão de pacote de informação.
  • Quando o pacote é retransmitido, o mesmo problema pode ocorrer. Se os pacotes são remetidos continuamente e deixados cair mesmo, a necessidade de largura de banda pode resultar.
  • Algumas interfaces física não apoiam a transmissão abortada nem introduzem uma penalidade de desempenho para fazer assim (como a restauração do transmitir fila inteiro).
Fragmente o pacote grande usando técnicas de fragmentação da camada de rede.
  • IP e fragmentação de suporte CLNP em algum roteador, com a remontagem que ocorre no host de destino.
  • Pode evitar a necessidade de fragmentar o pacote grande com descoberta de MTU.
  • Usa um mecanismo global para superar o que é essencialmente um problema local (do um-salto) - todos os saltos a jusante devem tratar um número maior de pacotes para comutar, mesmo se todos os link subsequente são rápidos.
  • Anula a opção da compressão do cabeçalho TCP/IP.
  • Muitos aplicativos não aceitam a fragmentação e para ajustar-se “não fragmente” mordido no cabeçalho IP. Estes pacotes serão deixados cair se fragmentados. Os aplicativos que não são capazes de aceitar pacotes fragmentados serão tornados inoperáveis neste ambiente.
Fragmente o pacote usando técnicas da camada de link.
  • Apoiado com algum pacote de camada de rede ou pacote interligado.
  • Fornece a fragmentação do por-link um pouco do que exigindo pacotes fragmentados ser fim-a-fim transportado. Somente o Roteadores anexado ao enlace lento precisa de acomodar a manipulação e a remontagem de pacotes adicionais.

O tamanho do fragmento ideal para o protocolo multilink point-to-point sobre ATM (MLPPPoATM) deve permitir que os fragmentos caibam em um múltiplo exato das células ATM. Veja configurar a fragmentação do link e intercalá-la para o Frame Relay e os circuitos virtuais ATM para a orientação em selecionar valores de fragmentação.

Cabeçalhos MLPPPoA e MLPPPoFR

Uma configuração típica do FRF.8 consiste no seguinte:

  • Um ponto final do Frame Relay

  • Um ponto final ATM

  • Um dispositivo (IWF) de colaboração

Cada valor-limite encapsula o pacote de voz e dados em um cabeçalho de encapsulamento da camada 2, que comunique o protocolo encapsulado e transportado no quadro ou na pilha. O Frame Relay e o ATM apoiam cabeçalhos de encapsulamento do Network Layer Protocol ID (NLPID). O documento eletrotécnico da comissão ISO/International (IEC) TR 9577 define valores nlpid bem conhecido para um número seleto de protocolos. Um valor de 0xCF é atribuído ao PPP.

O RFC 1973leavingcisco.com define o PPP no Frame Relay e no cabeçalho de MLPPPoFR, quando o RFC 2364leavingcisco.com definir o PPP over AAL5 e o cabeçalho de MLPPPoA. Ambos os encabeçamentos usam um valor NLPID de 0xCF para identificar o PPP como o protocolo encapsulado.

Cada um destes encabeçamentos é ilustrado em figura 1 abaixo.

/image/gif/paws/24041/mlpppoatm_encaps.gif

Figura 1. encabeçamento do PPP over AAL5, cabeçalho de MLPPPoA com encapsulamento de NLPID, e cabeçalho de MLPPPoA com multiplexação VC

Nota: O cabeçalho de MLPPPoFR igualmente inclui um campo de flag do byte de 0x7e, que não é mostrado em figura 1. Após os encabeçamentos, o número 5 do byte começa campos do protocolo PPP ou MLPPP.

Tabela 1 - FRF.8 transparente contra o FRF.8 Translational.

mlpppoatm_headers.gif

mlpppoatm_nlpid_frag_ex.gif

Figura 2. Como o pacote de MLPPPoATM é fragmentado usando o NLPID.

mlpppoatm_vcmux_frag_ex.gif

Figura 3. Como o pacote de MLPPPoATM é fragmentado usando a multiplexação VC.

/image/gif/paws/24041/mlpofr_atm_header.gif

O significado dos valores de byte é mostrado abaixo:

  • 0xFEFE - Identifica o destino e os pontos de acesso de serviço de origem (seivas) no encabeçamento do Logical Link Control (LLC). Um valor de 0xFEFE indica que o que segue em seguida é um cabeçalho nlpid curto, que seja usado com os protocolos que têm um valor nlpid definido.

  • 0x03 - Campo de controle usado com muitos encapsulamentos, incluindo o High-Level Data Link Control (HDLC). Igualmente indica que os índices do pacote consistem na informação não numerada.

  • 0xCF - Valor nlpid bem conhecido para o PPP.

FRF.8 Transparente versus modos de tradução

O acordo FRF.8 define dois modos operacionais para o dispositivo IWF:

  • Transparente - Dispositivo IWF para a frente os cabeçalhos de encapsulamento inalterados. Não executa nenhuma mapeamento de cabeçalho de protocolo, fragmentação ou remontagem.

  • Tradução - O dispositivo IWF executa o mapeamento de cabeçalho de protocolo entre os dois cabeçalhos de encapsulamento para esclarecer diferenças pequenas entre os tipos de encapsulamento.

O modo configurado no dispositivo IWF, que pode ser um Cisco ATM campus switch ou um 7200 Series Router com um adaptador da porta ATM PA-A3, mudam o número de bytes do cabeçalho de camada 2 no ATM e os segmentos do Frame Relay da colaboração ligam. Deixe-nos olhar com maiores detalhes estas despesas gerais.

As seguintes duas tabelas mostram os bytes de carga adicionais para pacotes de dados e exprimem-nos sobre pacotes IP (VoIP).

Tabela 2 - Link de dados aéreo nos bytes para um pacote de dados sobre um link FRF.8.

Modo FRF.8 Transparente Tradução
Direção de tráfego Frame relay para ATM ATM para frame relay Frame relay para ATM ATM para frame relay
Frame Relay ou trecho ATM de PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                 
Frame Flag (0x7e) 1 0 0 1 1 0 1 0
Cabeçalho do Frame Relay 2 0 0 2 2 0 0 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0
Controle LLC (0x03) 1 1 1 1 1 1 1 1
NLPID (0xcf for PPP) 1 1 1 1 1 1 1 1
ID de protocolo MLP (0x003d) 2 2 2 2 2 2 2 2
Número da seqüência MLP 4 4 4 4 4 4 4 4
ID de protocolo PPP (somente 1º fragmento) 2 2 2 2 2 2 2 2
Payload (Camada 3+) 0 0 0 0 0 0 0 0
Camada de Adaptação ATM (AAL)5 0 8 8 0 0 8 8 0
Seqüência de verificação de estrutura (FCS) 2 0 0 2 2 0 0 2
                 
Carga adicional total (bytes) 15 18 20 17 15 20 20 15

Tabela 3 - Link de dados aéreo nos bytes para um pacote voip sobre um link FRF.8.

Modo FRF.8 Transparente Tradução Frame Relay para Frame Relay
Direção de tráfego Frame relay para ATM ATM para frame relay Frame relay para ATM ATM para frame relay  
Frame Relay ou trecho ATM de PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                   
Frame Flag (0x7e) 1 0 0 1 1 0 0 1 1
Cabeçalho do Frame Relay 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Controle LLC (0x03) 1 1 1 1 1 1 1 1 1
NLPID (0xcf for PPP) 1 1 1 1 1 1 1 1 1
ID de PPP 2 2 2 2 2 2 2 2 0
Payload (IP+protocolo de datagrama de usuário (UDP)+RTP+voz) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
                   
Carga adicional total (bytes) 9 12 14 11 9 14 14 9 7

Em rever as tabelas acima, note o seguinte:

  • Os pacotes menores do que o tamanho de fragmentação especificado são encapsulados somente em um cabeçalho PPP e não em um cabeçalho MLPPP. Similarmente, os pacotes maiores do que o tamanho de fragmentação especificado são encapsulados em um cabeçalho PPP e em um cabeçalho MLPPP. Assim, os pacotes voip têm até oito bytes menos das despesas gerais.

  • Somente o primeiro fragmento do Multilink PPP (MLP) inclui um campo do protocolo PPP ID. Assim, o primeiro fragmento leva dois byes extra das despesas gerais.

  • No modo transparente, os cabeçalhos de encapsulamento são passados inalterados através do dispositivo IWF. Assim, as despesas gerais variam em cada sentido e em cada segmento. Especificamente, um cabeçalho de MLPPPoA começa com um cabeçalho nlpid curto de 0xFEFE. No modo transparente, este encabeçamento é passado inalterado pelo dispositivo IWF do segmento ATM ao segmento do Frame Relay. Contudo, no Frame Relay à direção de ATM, nenhum tal encabeçamento existe no modo transparente em um ou outro segmento.

  • No modo de tradução, o dispositivo IWF muda os cabeçalhos de encapsulamento. Assim, as despesas gerais são as mesmas em cada segmento em um ou outro sentido. Especificamente, no sentido do ATM para Frame Relay, o ponto final ATM encapsula o pacote em um cabeçalho de MLPPPoA. O dispositivo IWF remove o cabeçalho de NLPID antes de passar o quadro restante ao segmento do Frame Relay. No Frame Relay à direção de ATM, o dispositivo IWF outra vez manipula o quadro e prepends um cabeçalho de NLPID antes de passar o quadro segmentado ao ponto final ATM.

  • Quando projetar o FRF ligar com o MLP, seja certo esclarecer o número correto de bytes de carga adicionais do link de dados. Tais despesas gerais influenciam a quantidade de largura de banda consumida por cada chamada VoIP. Ela também desempenha um papel na determinação do tamanho de fragmento do MLP ideal. Aperfeiçoar o tamanho do fragmento para caber um número inteiro de células ATM é crítico, particularmente na velocidade lenta PVC onde uma quantidade significativa de largura de banda pode ser desperdiçada em acolchoar a última pilha a um mesmo múltiplo de 48 bytes.

Para maior clareza as finalidades, deixam-nos andar com as etapas do processo de encapsulamento de pacote quando um pacote vai no Frame Relay à direção de ATM com modo transparente:

  1. O ponto final do Frame Relay encapsula o pacote em um cabeçalho de MLPPPoFR.

  2. O dispositivo IWF remove o cabeçalho de Frame Relay de dois Bytes com o identificador da conexão de link de dados (DLCI). Ele então para a frente o pacote restante à interface ATM do IWF, que o segmenta o pacote em pilhas e para a frente através do segmento ATM.

  3. O ponto final ATM examina o encabeçamento do pacote recebido. Se os primeiros dois bytes do pacote recebido são 0x03CF, o ponto final ATM considera o pacote ser um pacote MLPPPoa válido.

  4. As funções MLPPP no ponto final ATM executam o processamento adicional.

Olhe o processo de encapsulamento de pacote quando um pacote vai no ATM à direção do Frame Relay com modo transparente:

  1. O ponto final ATM encapsula o pacote em um cabeçalho de MLPPPoA. Segmenta então os pacotes em pilhas e para a frente nelas para fora o segmento ATM.

  2. O IWF recebe o pacote, para a frente ele a sua interface do Frame Relay, e prepends um cabeçalho de Frame Relay de dois Bytes.

  3. O ponto final do Frame Relay examina o encabeçamento do pacote recebido. Se os primeiros quatro bytes depois que o cabeçalho de Frame Relay de dois Bytes é 0xfefe03cf, o IWF tratam o pacote como um pacote legal de MLPPPoFR.

  4. As funções MLPPP no ponto final do Frame Relay executam o processamento adicional.

As seguintes ilustrações mostram o formato de MLPPPoA e de pacotes MLPPPoFR.

/image/gif/paws/24041/mlpppoa-overhead.gif

Figura 6. carga adicional de MLPPPoA. Somente o primeiro fragmento leva um cabeçalho PPP.

mlpppofr-overhead.gif

Figura 7. carga adicional de MLPPPoFR. Somente o primeiro fragmento leva um cabeçalho PPP.

Requisitos de largura de banda VoIP

Ao aprovisionar a largura de banda para o VoIP, o overhead do enlace de dados deve ser incluído nos cálculos da largura de banda. A tabela 4 mostra as exigências da largura de banda por chamada para VoIP segundo o codec e o uso do protocolo compressed real-time transport (RTP). Os cálculos na tabela 4 supõem uma encenação do melhor-caso para RTP Header Compression (cRTP), ou seja nenhuns checksum de UDP ou erros de transmissão. Os encabeçamentos são comprimidos então consistentemente 40 bytes a dois bytes.

Tabela 4 - Por requisitos de largura de banda da chamada VoIP (kbps).

Modo FRF.8 Transparente Tradução Frame Relay para Frame Relay
Direção de tráfego Frame relay para ATM ATM para frame relay Frame relay para ATM ATM para frame relay  
Frame Relay ou trecho ATM de PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                   
G729 - 20 Senhora amostras - nenhum cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G729 - 20 Senhora amostras - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G729 - 30 Senhora amostras - nenhum cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G729 - 30 Senhora amostras - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G711 - 20 Senhora amostras - nenhum cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
Exemplos de G711 - 20 ms – cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G711 - Exemplos de 30 ms - Sem cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G711 - amostras 30ms - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

Desde que as despesas gerais variam em cada pé do PVC, nós recomendamos projetar para um cenário de caso pior. Por exemplo, considere o exemplo de um atendimento G.279 com uma amostra 20 milissegundos e do cRTP através de um PVC transparente. No trecho do Frame Relay, o requisito de largura de banda é 12.4 kbps em um sentido e 13.2 kbps no outro. Assim, nós recomendamos o abastecimento baseado em 3.2 kbps pelo atendimento.

Para finalidades da comparação, a tabela igualmente mostra o requisito de largura de banda voip em um Frame Relay de ponta a ponta PVC configurado com fragmentação FRF.12. Como referido na tabela, o PPP consome entre 0.5 kbps e 0.8 kbps da largura de banda adicional pelo atendimento para apoiar os bytes adicionais do cabeçalho de encapsulamento. Assim, nós recomendamos usar o FRF.12 com Frame Relay de ponta a ponta VC.

O Compressed RTP (cRTP) sobre o ATM exige o Software Release 12.2(2)T de Cisco IOS�. Quando o cRTP é permitido com MLPoFR e MLPoATM, a compressão do cabeçalho TCP/IP automaticamente está permitida e não pode ser desabilitada. Esta limitação resulta do RFC 2509, que não permite a negociação de PPP do RTP Header Compression sem igualmente negociar o TCP Header Compression.

Tradução e suporte transparente para dispositivos Cisco

Originalmente, o LFI exigiu que os dispositivos IWF usam o modo transparente. Mais recentemente, o fórum do Frame Relay introduziu o FRF.8.1 para apoiar o modo de tradução. Cisco introduziu o apoio para o FRF.8.1 e o modo de tradução nas seguintes versões de Cisco IOS Software:

  • 12.0(18)W5(23) para o LS1010 e Catalyst 8500 Series com um 4CE1 FR-PAM (CSCdt39211)

  • 12.2(3)T e 12.2(2) no Roteadores do Cisco IOS com interfaces ATM, tais como o PA-A3 (CSCdt70724)

Alguns provedores de serviço ainda não suportam a conversão do PPP em seus dispositivos FRF.8. Sempre que este é o caso, o fornecedor deve configurar seus PVC para o modo transparente.

Hardware e Software

A visão geral do capítulo dos mecanismos de eficiência de link alista o hardware suportado para a característica LFI. Esta configuração usa o seguinte hardware e software:

  • Ponto final ATM - PA-A3-OC3 em um Cisco IOS Software Release 12.2(8)T running do 7200 Series Router. (Nota: O LFI é apoiado no PA-A3-OC3 e no PA-A3-T3 somente. Não é apoiado nos adaptadores de porta IMA e ATM OC-12.)

  • Dispositivo IWF - LS1010 com módulo adapter e Cisco IOS Software Release 12.1(8)EY da porta T3 canalizada.

  • Ponto final do Frame Relay - PA-MC-T3 em um Cisco IOS Software Release 12.2(8)T running do 7200 Series Router.

Diagrama de topologia

/image/gif/paws/24041/lfi-topology.gif

Configurações

Esta seção mostra como configurar a característica LFI sobre um link FRF.8 no modo transparente. Usa um molde virtual nos dois pontos finais de roteador, de que a interface de acesso virtual do conjunto MLP é clonada. O LFI apoia interfaces do discador e moldes virtuais para especificar os parâmetros da camada de protocolo do MLPPP. O Cisco IOS Software Release 12.2(8)T aumenta a 200 o número de moldes virtuais originais que podem ser configurados pelo roteador. As versões anterior apoiam somente até 25 moldes virtuais pelo roteador. Esta limitação pode ser uma questão de escalada em um roteador de distribuição ATM se cada PVC é exigido para ter um endereço IP exclusivo. Como uma ação alternativa, use o IP como unnumbered ou substitua moldes virtuais com as interfaces do discador nos links numerados.

O Cisco IOS Release 12.1(5)T introduziu o apoio para o LFI sobre somente um enlace membro pelo pacote MLPPP. Assim, esta configuração usa somente um único VC em cada valor-limite. O apoio para VC múltiplos pelo pacote é planeado para uma Próxima Versão do Cisco IOS.

Ponto final do Frame Relay
  1. O adaptador da porta T3 canalizada exige que você cria um canal-grupo e especifica os intervalos de tempo. À revelia, nenhuma relação existe.
    FRAMEside#show ip int brief 
    Interface        IP-Address      OK? Method Status   Protocol 
    FastEthernet0/0  172.16.142.231  YES NVRAM  up       up  
    Loopback1        191.1.1.1       YES NVRAM  up       up  
    
    
  2. Use o comando show diag determinar o adaptador de porta instalado. Neste exemplo, o T3 PA está em versões atual do entalhe 3. do Cisco IOS indica agora o part number substituível do campo (FRU) para pedir em caso de uma falha do hardware.
    FRAMEside#show diag 3 
    Slot 3: 
       CT3 single wide Port adapter, 1 port 
       Port adapter is analyzed  
       Port adapter insertion time 13:16:35 ago 
       EEPROM contents at hardware discovery: 
       Hardware revision 1.0           Board revision A0 
       Serial number     23414844      Part number    73-3037-01 
       FRU Part Number:  PA-MC-T3= (SW) 
    
       Test history      0x0           RMA number     00-00-00 
       EEPROM format version 1 
       EEPROM contents (hex): 
         0x20: 01 A0 01 00 01 65 48 3C 49 0B DD 01 00 00 00 00 
         0x30: 50 00 00 00 00 10 30 00 FF FF FF FF FF FF FF FF 
    
    
  3. Executar o comando show controller t3 indica alarmes de camada física e estatísticas.
    FRAMEside#show controller t3 3/0  
    T3 3/0 is up.  Hardware is CT3 single wide port adapter 
      CT3 H/W Version : 1.0.1, CT3 ROM Version : 1.1, CT3 F/W Version : 2.4.0 
      FREEDM version: 1, reset 0 resurrect 0 
      Applique type is Channelized T3 
      No alarms detected. 
      FEAC code received: No code is being received 
      Framing is M23, Line Code is B3ZS, Clock Source is Internal 
      Rx throttle total 0, equipment customer loopback 
      Data in current interval (75 seconds elapsed): 
         2 Line Code Violations, 1 P-bit Coding Violation 
         0 C-bit Coding Violation, 1 P-bit Err Secs 
         0 P-bit Severely Err Secs, 0 Severely Err Framing Secs 
         0 Unavailable Secs, 1 Line Errored Secs 
         0 C-bit Errored Secs, 0 C-bit Severely Errored Secs 
      [output omitted] 
    
    
  4. Selecione um T1 de dentro do modo de configuração de controle T3, crie um canal-grupo, e atribua intervalos de tempo ao grupo.
    FRAMEside(config)#controller t3 3/0 
    b13-8-7204(config-controller)#? 
    Controller configuration commands: 
      cablelength  cable length in feet (0-450) 
      clock        Specify the clock source for a T3 link 
      default      Set a command to its defaults 
      description  Controller specific description 
      equipment    Specify the equipment type for loopback mode 
      exit         Exit from controller configuration mode 
      framing      Specify the type of Framing on a T3 link 
      help         Description of the interactive help system 
      idle         Specify the idle pattern for all channels on a T3 interface 
      loopback     Put the entire T3 line into loopback 
      mdl          Maintenance Data Link Configuration 
      no           Negate a command or set its defaults 
      shutdown     Shut down a DS3 link (send DS3 Idle) 
      t1           Create a T1 channel 
    
    b13-8-7204(config-controller)#t1 ? 
      <1-28>  T1 Channel number <1-28> 
    
    b13-8-7204(config-controller)#t1 1 channel-group ? 
      <0-23>  Channel group number 
    
    b13-8-7204(config-controller)#t1 1 channel-group 1 ? 
      timeslots  List of timeslots in the channel group 
    
    b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots ? 
      <1-24>  List of timeslots which comprise the channel 
    
    b13-8-7204(config-controller)#t1 1 channel-group 1 timeslots 1-2 
    b13-8-7204(config-controller)# 
    13:22:28: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to down 
    13:22:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down 
    13:22:46: %LINK-3-UPDOWN: Interface Serial3/0/1:1, changed state to up 
    13:22:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to up 
    13:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/0/1:1, changed state to down 
    
    

    Nota: Se a interface remota anexada não é configurada similarmente, a camada de enlace da interface canalizada nova vem acima, mas o protocolo de linha fica para baixo.

  5. A série 3/0/1:1 da relação identifica a interface canalizada nova. Configurar a relação para o Encapsulamento frame relay e permita então o Frame Relay Traffic Shaping (FRTS) na interface principal.
    FRAMEside(config)#int serial 3/0/1:1 
    FRAMEside(config-if)#encapsulation frame-relay ietf 
    FRAMEside(config-if)#frame-relay traffic-shaping
    
    !--- FRTS must be enabled for MLPoFR.
    
    
  6. Configurar uma classe de mapa do Frame Relay para aplicar parâmetros de modelagem de tráfego ao VC do Frame Relay (que serão criados abaixo).
    FRAMEside(config)#map-class frame-relay mlp 
    FRAMEside(config-map-class)#frame-relay cir ? 
      <1-45000000>  Applied to both Incoming/Outgoing CIR, Bits per second 
      in            Incoming CIR 
      out           Outgoing CIR 
    
    FRAMEside(config-map-class)#frame-relay cir 128000 
    FRAMEside(config-map-class)#frame-relay mincir 128000 
    FRAMEside(config-map-class)#frame-relay bc ? 
      <300-16000000>  Applied to both Incoming/Outgoing Bc, Bits 
      in             Incoming Bc 
      out             Outgoing Bc 
      <cr> 
    FRAMEside(config-map-class)#frame-relay bc 1280
    
    !--- Configure a burst committed (Bc) value of 1/100th of the CIR or 1280 bps.
    
    FRAMEside(config-map-class)#frame-relay be 0
    
    !--- Configure an excess burst (Be) value of 0.
    
    FRAMeside(config-map-class)#no frame-relay adaptive-shaping
    
  7. Crie uma política de serviços de QoS. Use os mesmos parâmetros que o lado ATM. Veja abaixo para a referência.
    FRAMEside#show policy-map example 
      Policy Map example 
        Class voice 
          Weighted Fair Queueing 
                Strict Priority 
                Bandwidth 110 (kbps) Burst 2750 (Bytes) 
        Class class-default 
          Weighted Fair Queueing 
                Flow based Fair Queueing 
                Bandwidth 0 (kbps) Max Threshold 64 (packets)
  8. Crie uma relação virtual do molde e aplique parâmetros MLPPP. Igualmente aplique a serviço-política de QoS ao VC.
    FRAMEside(config)#interface Virtual-Template1 
    FRAMEside(config-if)#ip address 1.1.1.2 255.255.255.0 
    FRAMEside(config-if)#service-policy output example 
    FRAMEside(config-if)#ppp multilink 
    FRAMEside(config-if)#ppp multilink fragment-delay 10 
    FRAMEside(config-if)#ppp multilink interleave 
    FRAMEside(config-if)#end 
    
    
  9. Crie uma subinterface e atribua o número do identificador da conexão de Data-Link do Frame Relay (DLCI). Aplique então o encapsulamento PPP, o molde virtual, e a classe de mapas.
    FRAMEside(config)#int serial 3/0/1:1.1 point 
    FRAMEside(config-subif)#frame-relay interface-dlci ? 
      <16-1007>  Define a switched or locally terminated DLCI 
    
    FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp ? 
      Virtual-Template  Virtual Template interface 
    
    FRAMEside(config-subif)#frame-relay interface-dlci 20 ppp Virtual-Template 1 
    FRAMEside(config-fr-dlci)#class mlp 
    
    
  10. Use o comando show frame-relay pvc confirmar seus virtual-molde e parâmetros da classe de mapas no VC.
    FRAMEside#show frame-relay pvc 20  
    
    PVC Statistics for interface Serial3/0/1:1 (Frame Relay DTE) 
    
    DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial3/0/1:1.1 
    
      input pkts 0      output pkts 0         in bytes 0 
      out bytes 0       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  
      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
      pvc create time 00:03:24, last time pvc status changed 00:03:24 
    Bound to Virtual-Access1 (down, cloned from Virtual-Template1) 
      cir 128000    bc 1280      be 0         byte limit 160    interval 10  
      mincir 128000    byte increment 160   Adaptive Shaping none 
      pkts 0       bytes 0       pkts delayed 0   bytes delayed 0 
      shaping inactive  
      traffic shaping drops 0 
      Queueing strategy: fifo 
      Output queue 0/40, 0 drop, 0 dequeued 
    
  11. Use a série 3/0/1:1 do controlador da mostra para confirmar que o Link do Frame Relay está em um estado e em um espaço livre ascendentes dos alarmes de camada física. Cada interface canalizada é atribuída um número “VC”. Na seguinte saída, o canal-grupo 1 (3/0/1:1) é atribuído um número VC de 0.
    FRAMEside#show controller serial 3/0/1:1 
    CT3 SW Controller 3/0 
      ROM ver 0x10001, h/w ver 1.0.1, f/w ver 2.4.0, FREEDM rev 1
    
    !--- FREEDM is the HDLC controller on the channelized T3 port adapter. 
    It extracts data from the 24 timeslots of a T1, validates the CRC, and checks for 
    any other frame errors.
    
    T3 linestate is Up, T1 linestate 0x00000002, num_active_idb 1 
      Buffer pool size 640, particle size 512, cache size 640, cache end 128/127 
      Rx desctable 0xF1A5A20, shadow 0x628C6AFC, size 512, spin 128
    
    !--- When it initializes, the interface driver builds a control structure 
    known as the receive ring.  The receive ring consists of a list of 512 packet buffer 
    descriptors. As packets arrive, FREEDM DMAs the data into the buffer to which a 
    descriptor points.
    
    rx queue 0xF1B8000, cache 0xF1B8000, fq base 0xF1B8800 
        rdq base 0xF1B8000, host_rxrdqr 0xF1B8004, host_rxfqw 0xF1B8804 
      Tx desctable 0xF1A7A60, shadow 0x628B6AD0, size 4096, spin 256 
    
    !--- When it initializes, the interface driver also creates the transmit 
    queue or transmit ring. In the case of the channelized T3 PA, the driver creates a 
    queue of 4096 entries and sets all fields in the descriptors to NULL or empty.
    
    tx queue 0xF1C0000, cache 0xF1C0000 
        host_txrdqw 1802, fq base 0xF1C4000, host_txfqr 0xF1C5C20 
      dynamic txlimit threshold 4096 
      TPD cache 0x628C7A54, size 4096, cache end 4096/4094, underrun 0 
      RPD cache 0x628C7328, size 448, cache end 0 
      Freedm fifo 0x628AA7B0, head ptr 0x628AA7C8, tail ptr 0x628AB7A8, reset 0 
      PCI bus 6, PCI shared memory block 0xF1A454C, PLX mailbox addr 0x3D820040 
      FREEDM devbase 0x3D800000, PLX devbase 0x3D820000 
      Rx overruns 0, Tx underruns 0, tx rdq count 0 
    
    !--- The "tx rdq count" indicates the number of outstanding transmit packets in 
    FREEDM's "transmit ready" queue. This queue holds a packet before it reaches the 
    transmit ring.
    
    Tx bad vc 0 
      FREEDM err: cas 0, hdl 0, hdl_blk 0, ind_prov 0, tavail 0, tmac busy 0, rmac b 
    usy 0 
             rxrdq_wt 0x2, rxrdq_rd 0x1, rxsfq_wt 0x201, rxsfq_rd 0x206 
    
    VC 0 (1:1) is enabled, T1 1 is enabled/Up, rx throttle 0 
    Interface Serial3/0/1:1 is up (idb status 0x84208080) 
      xmitdelay 0, max pak size 1608, maxmtu 1500, max buf size 1524 
      started 8, throttled 0, unthrottled 0, in_throttle FALSE 
      VC config: map 0xC0000000, timeslots 2, subrate 0xFF, crc size 2, non-inverted data 
        freedm fifo num 3, start 0x628AA7B0, end 0x628AA7C0, configured = TRUE 
      Rx pkts 0, bytes 0, runt 0, giant 0, drops 0 
        crc 0, frame 0, overrun 0, abort 1, no buf 0 
      Tx pkts 194313, bytes 2549490, underrun 0, drops 0, tpd udr 0 
        tx enqueued 0, tx count 0/36/0, no buf 0 
        tx limited = FALSE 
    
    !--- The "tx count x/y/z" counter includes the following information:
    !--- "x" = Number of transmit ring entries in use.
    !--- "y" = Maximum number of packets allowed on the transmit queue.
    !--- "z" = Number of times that the transmit limit has been exceeded.
    
    

Configuração de LS1010
  1. Use o comando show hardware confirmar que seu LS1010 está equipado com um módulo separado do adaptador de porta do Frame Relay (PAM).
    LS1010#show hardware    
    LS1010 named LS1010, Date: 07:36:40 UTC Mon May 13    2002    
    Feature Card's FPGA Download Version: 11    
    Slot Ctrlr-Type    Part No.  Rev  Ser No  Mfg Date  RMA No.   Hw Vrs  Tst EEP    
    ---- ------------  ---------- -- -------- --------- -------- ------- --- ---    
    0/0  155MM PAM     73-1496-03 A0 02829507 May 07 96 00-00-00   3.1     0   2    
    1/0  1CT3 FR-PAM   73-2972-03 A0 12344261 May 17 99 00-00-00   3.0     0   2    
    2/0  ATM Swi/Proc  73-1402-03 B0 03824638 Sep 14 96 00-00-00   3.1     0   2    
    2/1  FeatureCard1  73-1405-03 B0 03824581 Sep 14 96 00-00-00   3.2     0   2
    
  2. Use o comando show ip int brief identificar a relação do controlador.
    LS1010#show ip int brief    
    Interface      IP-Address         OK? Method Status       Protocol    
    ATM0/0/0       unassigned         YES unset  up           up    
    ATM0/0/1       unassigned         YES unset  down         down     
    ATM0/0/2       unassigned         YES unset  down         down     
    ATM0/0/3       unassigned         YES unset  down         down     
    ATM-P1/0/0     unassigned         YES unset  up           up     
    T3 1/0/0       unassigned         YES unset  up           up
    
  3. Crie uma interface canalizada e selecione os mesmos intervalos de tempo que o adaptador de porta serial (PA).
    LS1010(config)#controller t3 1/0/0 
    LS1010(config-controller)#channel-group 1 t1 ? 
      <1-28>  T1 line number <1-28> 
    
    LS1010(config-controller)#channel-group 1 t1 1 timeslots ? 
      <1-24>  List of timeslots which comprise the channel 
    
    LS1010(config-controller)#channel-group 1 t1 1 timeslot 1-2 
    LS1010(config-controller)# 
    
    2w1d: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up 
    2w1d: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up 
    
    
  4. Configurar o Encapsulamento frame relay na interface serial nova. Além, mude o tipo de interface de gerenciamento local (LMI) do NNI ao DCE.
    LS1010(config)#int serial 1/0/0:1 
    LS1010(config-if)#encap frame ? 
      ietf  Use RFC1490 encapsulation 
    
    LS1010(config-if)#encap frame ietf 
    LS1010(config-if)#frame-relay intf-type dce 
    
  5. Use o comando show interface serial confirmar o Encapsulamento frame relay.
    LS1010#show int serial 1/0/0:1 
    Serial1/0/0:1 is up, line protocol is up  
      Hardware is FRPAM-SERIAL 
      MTU 4096 bytes, BW 128 Kbit, DLY 0 usec,  
         reliability 139/255, txload 1/255, rxload 1/255 
      Encapsulation FRAME-RELAY IETF, loopback not set 
      Keepalive set (10 sec) 
      LMI enq sent  32, LMI stat recvd 0, LMI upd recvd 0 
      LMI enq recvd 40, LMI stat sent  40, LMI upd sent  0, DCE LMI up 
      LMI DLCI 1023  LMI type is CISCO  frame relay DCE 
    
    !--- By default, the serial PAM and the serial PA use LMI type Cisco. The serial PAM 
    should show DCE LMI status of "up", and the serial PA should show DTE LMI status of 
    "up". 
    
    
    Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
      Last input 00:00:03, output 00:00:05, output hang never 
      Last clearing of "show interface" counters 00:06:40 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
      Queueing strategy: fifo 
      Output queue :0/40 (size/max) 
      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         44 packets input, 667 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         71 packets output, 923 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
       Timeslots(s) Used: 1-2 on T1 1  
       Frames Received with: 
        DE set: 0, FECN set :0, BECN set: 0 
       Frames Tagged : 
        DE: 0, FECN: 0 BECN: 0 
       Frames Discarded Due to Alignment Error: 0 
       Frames Discarded Due to Illegal Length: 0 
       Frames Received with unknown DLCI: 5 
       Frames with illegal Header : 0  
       Transmit Frames with FECN set :0,  BECN Set :0  
       Transmit Frames Tagged FECN : 0 BECN : 0  
       Transmit Frames Discarded due to No buffers : 0 
       Default Upc Action : tag-drop 
       Default Bc (in Bits) : 32768 
    
    LS1010#show frame lmi 
    
    LMI Statistics for interface Serial1/0/0:1 (Frame Relay DCE) LMI TYPE = CISCO< 
      Invalid Unnumbered info 0             Invalid Prot Disc 0 
      Invalid dummy Call Ref 0              Invalid Msg Type 0 
      Invalid Status Message 0              Invalid Lock Shift 0 
      Invalid Information ID 0              Invalid Report IE Len 0 
      Invalid Report Request 0              Invalid Keep IE Len 0 
      Num Status Enq. Rcvd 120              Num Status msgs Sent 120 
      Num Update Status Sent 0              Num St Enq. Timeouts 0 
    
  6. Antes que você configure o PVC, assegure-se de que a interface ATM seja Up/Up.
    LS1010#show int atm 0/0/0 
    ATM0/0/0 is up, line protocol is up  
      Hardware is oc3suni 
      MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 0 usec,  
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation ATM, loopback not set 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters never 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
      Queueing strategy: fifo 
      Output queue :0/40 (size/max) 
      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 1000 bits/sec, 2 packets/sec 
         253672 packets input, 13444616 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         2601118 packets output, 137859254 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
  7. Além do que as duas interfaces física, o LS1010 usa uma interface lógica para ligar o lado ATM e o lado do Frame Relay. A interface lógica é identificada como "atm-p1" na pseudo-interface ATM.
    LS1010#show int atm-p1/0/0 
    ATM-P1/0/0 is up, line protocol is up  
      Hardware is ATM-PSEUDO 
      MTU 4470 bytes, sub MTU 4470, BW 45000 Kbit, DLY 0 usec,  
         reliability 0/255, txload 1/255, rxload 1/255 
      Encapsulation ATM, loopback not set 
      Keepalive not supported  
      Encapsulation(s): 
      2000 maximum active VCs, 0 current VCCs 
      VC idle disconnect time: 300 seconds 
      Last input never, output never, output hang never 
      Last clearing of "show interface" counters never 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
      Queueing strategy: fifo 
      Output queue :0/40 (size/max) 
      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         0 packets input, 0 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         0 packets output, 0 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
    
  8. No modo da configuração de interface serial, configurar o PVC de colaboração.
    interface Serial1/0/0:1 
     no ip address 
     encapsulation frame-relay IETF 
     no arp frame-relay 
     frame-relay intf-type dce 
     frame-relay pvc 20 service transparent  interface  ATM0/0/0 1 100
    
  9. Confirme sua configuração com o comando show vc interface atm.
    LS1010#show vc int atm 0/0/0    
    Interface      Conn-Id  Type   X-Interface     X-Conn-Id   Encap  Status    
    ATM0/0/0       0/5      PVC     ATM0           0/39        QSAAL    UP    
    ATM0/0/0       0/16     PVC     ATM0           0/35        ILMI     UP    
    ATM0/0/0       1/100    PVC     Serial1/0/0:1  20                   UP    

Ponto final de ATM
  1. Assegure-se de que você esteja usando um ATM PA aprimorado ou um PA-A3. Use o comando show interface atm confirmar.
    ATMside#show int atm 1/0/0 
    ATM1/0/0 is up, line protocol is up  
      Hardware is cyBus ENHANCED ATM PA 
      MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec,  
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation ATM, loopback not set 
      Encapsulation(s): AAL5 
      4095 maximum active VCs, 0 current VCCs 
    [output omitted] 
    
  2. Configurar os parâmetros da camada ATM dos Circuitos Virtuais Permanentes (PVC). Nesta configuração, nós estamos usando uma subinterface ponto a ponto com uma taxa de célula sustentada (SCR) de 150 kbps. Este valor foi selecionado para ser aproximadamente 15% mais alto do que o CIR do ponto final do Frame Relay dos kbps 128. As ajudas adicionais de 15% para assegurar-se de que o VC entregue uma largura de banda equivalente ao tráfego de usuário real em ambos os lados da conexão ao acomodar as despesas gerais extra do lado ATM. (Veja igualmente configurar o modelagem de tráfego no Frame Relay ao ATM Service Interworking (FRF.8) os PVC.)
    ATMside(config)#int atm 1/0/0.1 point 
    ATMside(config-subif)#pvc 1/100 
    ATMside(config-if-atm-vc)#vbr-nrt 300 150 ? 
      <1-65535>  Maximum Burst Size(MBS) in Cells 
      <cr> 
    
    ATMside(config-if-atm-vc)#vbr-nrt 300 150 
    ATMside(config-if-atm-vc)#end 
    ATMside(config-if-atm-vc)#tx-ring-limit 4 
    
    !--- Tune down the transmit ring to push most queueing to the layer-3 queues, where 
    our service policy will apply.
    
    
  3. Confirme que seu VC aparece na tabela VC. Execute o comando show atm vc. Note que o roteador atribui um máximo padrão do tamanho de intermitência (MBS) de 94 desde que nós não incorporamos um valor explícito.
    ATMside#show atm vc 
               VCD /                             Peak Avg/Min Burst 
    Interface Name VPI  VCI Type Encaps SC  kbps kbps Cells Sts 
    1/0/0.1    1    1   100 PVC  SNAP   VBR 300  150  94    UP 
  4. Crie uma política de serviços de QoS. Na política mostrada abaixo, nós criamos quatro classes, incluindo a classe de padrão classe roteador-criada.
    1. Crie um mapa de classe para a Voz sobre pacotes IP (VoIP).
      ATMside(config)#class-map voice  
      ATMside(config-cmap)#match ip rtp ? 
        <2000-65535>  Lower bound of UDP destination port 
      
      ATMside(config-cmap)#match ip rtp 16384 ?  
        <0-16383>  Range of UDP ports 
      
      ATMside(config-cmap)#match ip rtp 16384 16383 
      
      
      !--- Cisco IOS H.323 devices use this UDP port range to transmit VoIP packets.
      
      
    2. Crie um mapa de classe para os pacotes da sinalização de voz. Este exemplo usa H.323 conecta rapidamente. (Veja igualmente da “a seção das diretrizes configuração LLQ” de VoIP sobre links de PPP com Qualidade de Serviço (prioridade RTP LLQ/IP, LFI, o cRTP.)
      class-map voice-signaling 
        match access-group 103 
      ! 
      access-list 103 permit tcp any eq 1720 any  
      access-list 103 permit tcp any any eq 1720
      
    3. Crie um mapa de política nomeado e atribua ações QoS a cada classe. Este exemplo atribui filas de prioridade aos pacotes do usuário voip com o comando priority e uma garantia de largura de banda mínima aos pacotes da sinalização de chamada com o comando bandwidth. Todo tráfego restante vai à classe de padrão classe, que separa o tráfego em fluxos da camada de IP e fornece o enfileiramento considerável entre os fluxos.
      policy-map example 
        class call-control 
          bandwidth percent 10 
        class voice 
           priority 110 
        class class-default 
          fair-queue 
      
      
    4. Confirme sua configuração.
      ATMside#show policy-map example 
        Policy Map example 
          Class call-control 
            bandwidth percent 10 
          Class voice 
            priority 110 
          Class class-default 
            fair-queue 
      
  5. Crie um molde virtual e aplique-lhe a política de serviços de QoS.
    interface Virtual-Template1 
      bandwidth 150 
      ip address 1.1.1.1 255.255.255.0 
      service-policy output example 
      ppp multilink 
      ppp multilink fragment-delay 10 
      ppp multilink interleave 
    
    
    !--- You select a fragment size indirectly by specifying the maximum tolerable 
    serialization delay. The recommended maximum per-hop serialization delay for voice 
    environments is 10 milliseconds (ms). LFI also requires ppp multilink interleave. 
    
    
    
  6. Aplique o encapsulamento do molde virtual e do Multilink PPP ao ATM PVC.
    ATMside(config)#int atm 1/0/0.1 
    ATMside(config-subif)#pvc 1/100 
    ATMside(config-if-atm-vc)#protocol ppp ? 
      Virtual-Template  Virtual Template interface 
      dialer            pvc is part of dialer profile 
    
    ATMside(config-if-atm-vc)#protocol ppp Virtual-Template 1 
    
  7. Confirme seus ajustes no ATM PVC.
    ATMside#show run int atm 1/0/0.1 
    Building configuration... 
    
    Current configuration : 127 bytes 
    ! 
    interface ATM1/0/0.1 point-to-point 
     pvc 1/100  
      vbr-nrt 300 150 
      tx-ring-limit 4 
      protocol ppp Virtual-Template1 
     ! 
    end 
    
  8. O roteador cria uma interface de acesso virtual automaticamente. Se você não tem o MLPPP configurado no ponto final do Frame Relay, o estado da interface de acesso virtual é up/down.
    ATMside#show int virtual-access 1 
    Virtual-Access1 is up, line protocol is down  
      Hardware is Virtual Access interface 
      Internet address is 1.1.1.1/24 
      MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec,  
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation PPP, loopback not set 
      DTR is pulsed for 5 seconds on reset 
      LCP Listen, multilink Closed 
      Closed: LEXCP, BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP 
      Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 
      Cloned from virtual-template: 1
    

comandos show e debug

Ponto final de ATM

Use os comandos seguintes no ponto final ATM confirmar que o LFI está trabalhando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

  • multilink de PPP da mostra - O LFI usa duas interfaces de acesso virtual -- um para o PPP e um para o conjunto MLP. Use o multilink de PPP da mostra para diferenciar-se entre os dois.

    ATMside#show ppp multilink 
    Virtual-Access2, bundle name is FRAMEside 
    
    !--- The bundle interface is assigned to VA 2.
    
      Bundle up for 01:11:55 
      Bundle is Distributed 
      0 lost fragments, 0 reordered, 0 unassigned 
      0 discarded, 0 lost received, 1/255 load 
      0x1E received sequence, 0xA sent sequence 
      Member links: 1 (max not set, min not set) 
        Virtual-Access1, since 01:11:55, last rcvd seq 00001D  187 weight 
    
    !--- The PPP interface is assigned to VA 1.
    
    
  • show interface virtual-access 1 - Confirme que a interface de acesso virtual é Up/Up e incremento dos contadores dos pacotes de entrada e saída.

    ATMside#show int virtual-access 1 
    Virtual-Access1 is up, line protocol is up 
      Hardware is Virtual Access interface 
      Internet address is 1.1.1.1/24 
      MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, 
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation PPP, loopback not set 
      DTR is pulsed for 5 seconds on reset 
      LCP Open, multilink Open 
      Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 
      Cloned from virtual-template: 1 
      Last input 01:11:30, output never, output hang never 
      Last clearing of "show interface" counters 2w1d 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 
      Queueing strategy: fifo 
      Output queue :0/40 (size/max) 
      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         878 packets input, 13094 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         255073 packets output, 6624300 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
    
  • show policy-map int virtual-access 2 - Confirme que a política de serviços de QoS está limitada ao bundle interface MLPPP.

    ATMside#show policy-map int virtual-access 2 
     Virtual-Access2 
    
      Service-policy output: example 
    
        queue stats for all priority classes: 
          queue size 0, queue limit 27 
          packets output 0, packet drops 0 
          tail/random drops 0, no buffer drops 0, other drops 0 
    
        Class-map: call-control (match-all) 
          0 packets, 0 bytes 
          5 minute offered rate 0 bps, drop rate 0 bps 
          Match: access-group 103 
          queue size 0, queue limit 3 
          packets output 0, packet drops 0 
          tail/random drops 0, no buffer drops 0, other drops 0 
          Bandwidth: 10%, kbps 15 
    
        Class-map: voice (match-all) 
          0 packets, 0 bytes 
          5 minute offered rate 0 bps, drop rate 0 bps 
          Match: ip rtp 16384 16383 
          Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 
    
        Class-map: class-default (match-any) 
          0 packets, 0 bytes 
          5 minute offered rate 0 bps, drop rate 0 bps 
          Match: any 
          queue size 0, queue limit 5 
          packets output 0, packet drops 0 
          tail/random drops 0, no buffer drops 0, other drops 0 
          Fair-queue: per-flow queue limit 2
    
  • debugar o pacote ppp e debugar o pacote atm - use estes comandos se todas as relações são Up/Up, mas você não pode sibilar o End to End. Além, você pode usar estes comandos capturar manutenções de atividade de PPP, como ilustrado abaixo.

    2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 
    2w1d: ATM1/0/0.1(O): 
    VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
    2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 
    2w1d: 
    2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 
    
    !--- This side received an Echo Request and responded with an outbound Echo Reply.
    
    2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 
    2w1d: ATM1/0/0.1(O): 
    VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03  Length:0x16 
    2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 
    2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 
    2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up
    
    !--- This side transmitted an Echo Request and received an inbound Echo Reply.
    
    

Ponto final do Frame Relay

Use os comandos seguintes no ponto final do Frame Relay confirmar que o LFI está trabalhando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

  • multilink de PPP da mostra - O LFI usa duas interfaces de acesso virtual -- um para o PPP e um para o conjunto MLP. Use o multilink de PPP da mostra para diferenciar-se entre os dois.

    FRAMEside#show ppp multilink 
    
    Virtual-Access2, bundle name is ATMside 
      Bundle up for 01:15:16 
      0 lost fragments, 0 reordered, 0 unassigned 
      0 discarded, 0 lost received, 1/255 load 
      0x19 received sequence, 0x4B sent sequence 
      Member links: 1 (max not set, min not set) 
        Virtual-Access1, since 01:15:16, last rcvd seq 000018  59464 weight 
    
  • mostre o acesso virtual da relação do mapa de política - Confirme que a política de serviços de QoS está limitada ao bundle interface MLPPP.

    FRAMEside#show policy-map int virtual-access 2 
     Virtual-Access2 
      Service-policy output: example 
    
        Class-map: voice (match-all) 
          0 packets, 0 bytes 
          5 minute offered rate 0 bps, drop rate 0 bps 
          Match: ip rtp 16384 16383 
          Weighted Fair Queueing 
            Strict Priority 
            Output Queue: Conversation 264 
            Bandwidth 110 (kbps) Burst 2750 (Bytes) 
            (pkts matched/bytes matched) 0/0 
            (total drops/bytes drops) 0/0 
    
        Class-map: class-default (match-any) 
          27 packets, 2578 bytes 
          5 minute offered rate 0 bps, drop rate 0 bps 
          Match: any 
          Weighted Fair Queueing 
            Flow Based Fair Queueing 
            Maximum Number of Hashed Queues 256 
            (total queued/total drops/no-buffer drops) 0/0/0 
    
    
  • debugar o pacote de frame e debugar o pacote ppp - Use estes comandos se todas as relações são Up/Up, mas você não pode sibilar fim-a-fim.

    FRAMEside#debug frame packet 
    Frame Relay packet debugging is on 
    FRAMEside# 
    FRAMEside#ping 1.1.1.1 
    Type escape sequence to abort. 
    Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: 
    !!!!! 
    Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms 
    FRAMEside# 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 
    2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
    
    

Enfileiramento e LFI

MLPPPoA e MLPPPoFR clonam duas interfaces de acesso virtual da interface do discador ou do molde virtual. Uma tal relação representa o link de PPP, e a outro representa a relação do conjunto MLP. Use o comando show ppp multilink determinar a relação específica usada para cada função. Até à data desta escrita, somente um VC pelo pacote é apoiado, e assim somente uma interface de acesso virtual deve aparecer na lista do membro de conjunto na saída do multilink de PPP da mostra.

Além do que as duas interfaces de acesso virtual, cada PVC é associado com uma interface principal e uma subinterface. Cada um destas relações fornece algum formulário do enfileiramento. Contudo, somente a interface de acesso virtual que representa o bundle interface apoia o enfileiramento extravagante através de uma política de serviços aplicada de QoS. Outras três relações devem ter o enfileiramento de FIFO. Ao aplicar uma serviço-política a um virtual-molde, o roteador indica o seguinte mensagem:

cr7200(config)#interface virtual-template 1
cr7200(config)#service-policy output Gromit
Class Base Weighted Fair Queueing not supported on interface Virtual-Access1

Nota: Class Based Weighted Fair Queueing apoiado no bundle interface MLPPP somente.

Essas mensagens são normais. A primeira mensagem informa que não há suporte para uma política de serviço na interface de acesso virtual do PPP. A segunda mensagem confirma que a serviço-política está aplicada à interface de acesso virtual do conjunto MLP. Para confirmar o mecanismo de filas na relação do conjunto MLP, use os comandos show interface virtual-access, show queue virtual-access, e show policy-map interface virtual-access.

MLPPPoFR exige que o Frame Relay Traffic Shaping (FRTS) esteja permitido na interface física. O FRTS ativa filas por voz. Em Plataformas tais como os 7200, os 3600, e o 2600 Series, o FRTS é configurado com os seguintes dois comandos:

  • modelagem de tráfego do Frame Relay na interface principal

  • classe de mapas com alguns comandos shaping.

As versões atual do Cisco IOS imprimem o seguinte mensagem de advertência se MLPPoFR é aplicado sem FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Se você vê este mensagem de advertência, assegure-se de que o FRTS esteja configurado na interface física e que a política de serviços de QoS esteve anexada ao molde virtual. Para verificar a configuração, use os comandos show running-config serial interface e show running-config virtual-template. Quando MLPPPoFR é configurado, o mecanismo de filas da relação muda para dual FIFO, como ilustrado abaixo. A fila de alta prioridade segura pacotes de voz e os pacotes de controle, tais como a interface de gerenciamento local (LMI), e a fila de baixa prioridade seguram pacotes fragmentados, presumivelmente dados ou pacotes que não é de voz.

Router#show int serial 6/0:0 
    Serial6/0:0 is up, line protocol is down 
      Hardware is Multichannel T1 
      MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, 
         reliability 255/255, txload 1/255, rxload 1/255 
      Encapsulation FRAME-RELAY, crc 16, Data non-inverted 
      Keepalive set (10 sec) 
      LMI enq sent  236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down 
      LMI enq recvd 353, LMI stat sent  0, LMI upd sent  0 
      LMI DLCI 1023  LMI type is CISCO  frame relay DTE 
      Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
      Last input 00:00:02, output 00:00:02, output hang never 
      Last clearing of "show interface" counters 00:39:22 
      Queueing strategy: dual fifo 
      Output queue: high size/max/dropped 0/256/0
      !--- high-priority queue

      Output queue 0/128, 0 drops; input queue 0/75, 0 drops
      !--- low-priority queue

      5 minute input rate 0 bits/sec, 0 packets/sec 
      5 minute output rate 0 bits/sec, 0 packets/sec 
         353 packets input, 4628 bytes, 0 no buffer 
         Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
         0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         353 packets output, 4628 bytes, 0 underruns 
         0 output errors, 0 collisions, 0 interface resets 
         0 output buffer failures, 0 output buffers swapped out 
         0 carrier transitions 
      no alarm present 
      Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags

O LFI usa duas camadas de enfileiramento -- Nível do pacote MLPPP, que apoia o enfileiramento extravagante, e nível PVC, que apoia somente o enfileiramento de FIFO. O bundle interface mantém sua própria fila. Todos os pacotes de MLP atravessam as camadas do conjunto MLP e do acesso virtual primeiramente antes do Frame Relay ou da camada ATM. O LFI monitora o tamanho das filas de hardware dos enlaces membros e dequeues pacotes às filas de hardware quando caem abaixo de um ponto inicial, que seja originalmente um valor de dois. Se não, os pacotes são enfileirados na fila do conjunto MLP.

Troubleshooting e Problemas Conhecidos

Os problemas conhecidos das lista da tabela a seguir com links do LFI over FRF e focos nos passos de Troubleshooting a tomar para isolar seus sintomas a um erro resolved.

Sintoma Passos de Troubleshooting Erros resolved
Throughput reduzido no trecho de ATM ou no trecho do Frame Relay
  • Sibile com os pacotes vário-feitos sob medida de 100 bytes aos Ethernet MTU.
  • Fazem os grandes pacotes passam por intervalo?
CSCdt59038 - Com os pacotes 1500-byte e a fragmentação ajustados a 100 bytes, há 15 pacotes fragmentados. O atraso foi causado por níveis múltiplos do enfileiramento. CSCdu18344 - Com FRTS, os pacotes dequeued esperados mais lentamente do que. O pacote MLPPP dequeue verificações de função o tamanho da fila da fila do formador de tráfego. O FRTS era demasiado lento em cancelar esta fila.
Pacotes estragados
  • Execute o comando show ppp multilink. Look for que incrementa valores para “perdeu fragmentos”, “rejeitado”, e “perdeu” contadores recebidos.
    Virtual-Access4, bundle name is xyz 
    Bundle up for 03:56:11 
    2524 lost fragments, 3786 reordered, 
    0 unassigned 
    1262 discarded, 1262 lost received, 
    1/255 load 
    0x42EA1 received sequence, 0xCF7 
    sent sequence 
    Member links: 1 (max not set, min 
    not set)     
    Virtual-Access1, since 
    03:59:02, last rcvd seq 042EA0 400 
    weight 
    
  • Enable debuga multi eventos ppp e procura-os “perdeu o fragmento” e os mensagens fora de sincronismo com peer.
    *Mar 17 09:14:08.216: Vi4 MLP: Lost 
    fragment 3FED9 in 'dhartr21' (all 
    links have rcvd higher seq#) 
    *Mar 17 09:14:08.232: Vi4 MLP: 
    Received lost fragment seq 3FED9, 
    expecting 3FEDC in 'dhartr21' 
    *Mar 17 09:14:08.232: Vi4 MLP: Out 
    of sync with peer, resyncing to last 
    rcvd seq# (03FED9) 
    *Mar 17 09:14:08.236: Vi4 MLP: 
    Unusual jump in seq number, from 
    03FEDC to 03FEDA 
    
CSCdv89201 - Quando a interface ATM física é congestionada, os fragmentos MLP estão deixados cair ou fora de serviço recebido na extremidade remota. Este problema afeta somente os módulos de rede ATM no 2600 e 3600 Series. Resulta de como o direcionador da relação era incorretamente pacotes de switching no caminho rápido (como com o interruptor rápido ou o Cisco Express Forwarding). Especificamente, o segundo fragmento do pacote atual foi enviado após o primeiro fragmento do próximo pacote
Perda de conectividade de ponta a ponta quando o 3600 Series executar o IWF no modo transparente
  • Mude o modo a translational e ao teste outra vez.
CSCdw11409 - Assegura-se de que olhares CEF no local do byte correto para começar a processar os cabeçalhos de encapsulamento dos pacotes MLPPP

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: 24041