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

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 requer o entendimento do seguinte:

• Ambiente FRF.8 típico e modos transparente e de tradução FRF.8 - Consulte Compreendendo os Modos Transparente e de Tradução com FRF.8.

• Familiaridade com os comandos de configuração LS1010 e Catalyst 8500 e como o Adaptador de Porta de Frame Relay E1 Canalizado ou o Adaptador de Porta de Frame Relay DS3 Canalizado executa o entrelaçamento entre um ponto final de Frame Relay e um ponto final de ATM.

• Retardo de serialização e tremulação. Consulte Links VoIP sobre PPP com Qualidade de Serviço (Prioridade LLQ / IP RTP, LFI, cRTP) e VoIP sobre Frame Relay com Qualidade de Serviço (Fragmentação, Modelagem de Tráfego, Prioridade IP RTP).

Componentes Utilizados

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

Conventions

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 atraso de serialização e a variação de atraso em enlaces de baixa velocidade que transportam tráfego em tempo real e não em tempo real. O atraso de serialização é o atraso fixo necessário para registrar um quadro de voz ou de dados na interface de rede e está diretamente relacionado à velocidade de clock no tronco. Um flag extra é necessário para separar os quadros para velocidades de relógio baixas e tamanhos de quadros pequenos.

O LFI usa os recursos de fragmentação integrados do MLPPP para evitar atrasos e jitter (variações no atraso) causados por pacotes grandes de tamanho variável que são enfileirados entre pacotes de voz relativamente pequenos. Com o LFI, os pacotes maiores que um tamanho de fragmento configurado são encapsulados em um cabeçalho MLPPP. O RFC 1990 define o cabeçalho MLPPP, bem como o seguinte:

• (B)O bit de fragmento inicial é um campo de um bit definido como 1 no primeiro fragmento derivado de um pacote PPP e definido como 0 para todos os outros fragmentos do mesmo pacote PPP.

• O bit de fragmento final é um campo de um bit definido como 1 no último fragmento e definido como 0 para todos os outros fragmentos.

• O campo de sequência é um número de 24 bits ou 12 bits que é incrementado para cada fragmento transmitido. Por padrão, o campo de sequência tem 24 bits de comprimento, mas pode ser negociado para ter apenas 12 bits com a opção de configuração de LCP descrita abaixo.

Além da fragmentação, os pacotes sensíveis a retardo devem ser programados com prioridade adequada entre fragmentos de um pacote grande. Com a fragmentação, o Enfileiramento Moderado Ponderado (WFQ - Weighted Fair Queueing) se torna "consciente" de que um pacote faz parte de um fragmento ou está desfragmentado. O WFQ atribui um número de sequência a cada pacote que chega e agenda os pacotes com base nesse número.

A fragmentação da camada 2 fornece uma solução superior a todas as outras abordagens na solução do "problema do pacote grande". A tabela a seguir lista as vantagens e desvantagens de outras soluções em potencial.

Possível solução	Vantagens	Desvantagens
Anule a transmissão do pacote grande e recoloque-o em fila atrás do tráfego sensível a atrasos.	Apenas adia a transmissão de pacotes. Quando o pacote é retransmitido, o mesmo problema pode ocorrer. Se os pacotes forem continuamente recolocados em fila e até mesmo descartados, pode ocorrer privação de largura de banda.	Algumas interfaces físicas não suportam transmissão anulada ou introduzem uma penalidade de desempenho para fazer isso (como redefinir toda a fila de transmissão).
Fragmente o pacote grande usando as técnicas de fragmentação da camada de rede.	O IP e o CLNP suportam a fragmentação em qualquer roteador, com a remontagem ocorrendo no host de destino. Pode evitar a necessidade de fragmentar o pacote grande com a descoberta de MTU. Usa um mecanismo global para superar o que é essencialmente um problema local (de um salto) - todos os saltos de downstream devem lidar com um número maior de pacotes a serem comutados, mesmo que todos os links subsequentes sejam rápidos. Anula a opção de compactação de cabeçalho TCP/IP.	Muitos aplicativos não aceitam a fragmentação e definem o bit "Do Not Fragment" no cabeçalho IP. Esses pacotes serão descartados se forem fragmentados. Os aplicativos que não são capazes de aceitar pacotes fragmentados ficarão inoperantes nesse ambiente.
Fragmente o pacote usando técnicas da camada de enlace.	Suportado com qualquer pacote da camada de rede ou pacote com bridge.	Fornece fragmentação por link em vez de exigir que pacotes fragmentados sejam transportados de ponta a ponta. Somente os roteadores conectados ao link lento precisam acomodar o manuseio e a remontagem de pacotes adicionais.

O tamanho de fragmento ideal para o multilink Point-to-Point Protocol over ATM (MLPPPoATM) deve permitir que os fragmentos caibam em um múltiplo exato de células ATM. Consulte Fragmentação e intercalação de link para Frame Relay e Circuito virtual ATM para obter orientação sobre a seleção de valores de fragmentação.

Cabeçalhos MLPPPoA e MLPPPoFR

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

• Um ponto final do Frame Relay

• Um ponto final ATM

• Um dispositivo de entrelaçamento (IWF)

Cada endpoint encapsula pacotes de dados e voz em um cabeçalho de encapsulamento da camada 2, que comunica o protocolo encapsulado e transportado no quadro ou na célula. O Frame Relay e o ATM suportam cabeçalhos de encapsulamento NLPID (Network Layer Protocol ID). O documento ISO/International Eletrotechnical Commission (IEC) TR 9577 define valores NLPID bem conhecidos para um número selecionado de protocolos. Um valor 0xCF é atribuído ao PPP.

O RFC 1973 define o PPP no Frame Relay e o cabeçalho MLPPPoFR, enquanto o RFC 2364 define o PPP sobre AAL5 e o cabeçalho MLPPPoA. Ambos os cabeçalhos usam um valor NLPID de 0xCF para identificar o PPP como o protocolo encapsulado.

Cada um desses cabeçalhos está ilustrado na Figura 1 abaixo.

Figura 1. cabeçalho PPP sobre AAL5, cabeçalho MLPPPoA com encapsulamento NLPID e cabeçalho MLPPPoA com multiplexação VC

Observação: o cabeçalho MLPPPoFR também inclui um campo de flag de um byte de 0x7e, que não é mostrado na Figura 1. Após os cabeçalhos, o byte número 5 inicia os campos do protocolo PPP ou MLPPP.

Tabela 1 - FRF.8 transparente vs. FRF.8 translacional.

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

Figura 3. Como o pacote MLPPPoATM é fragmentado usando Multiplexação VC.

O significado dos valores de byte são mostrados abaixo:

• 0xFEFE - identifica os pontos de acesso a serviços (SAPs) de destino e origem no cabeçalho do Controle Lógico de Enlace (LLC - Logical Link Control). Um valor 0xFEFE indica que o que vem a seguir é um cabeçalho NLPID de forma curta, que é usado com protocolos com um valor NLPID definido.

• 0x03 - Campo de controle usado com muitos encapsulamentos, incluindo Controle de Enlace de Dados de Alto Nível (HDLC). Também indica que o conteúdo do pacote consiste em informações não numeradas.

• 0xCF - Valor NLPID conhecido para PPP.

FRF.8 Transparente versus modos de tradução

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

• Transparente - o dispositivo IWF encaminha os cabeçalhos de encapsulamento inalterados. Ele não executa nenhum mapeamento de cabeçalho de protocolo, fragmentação ou remontagem.

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

O modo configurado no dispositivo IWF, que pode ser um switch de campus Cisco ATM ou um 7200 Series Router com um adaptador de porta PA-A3 ATM, altera o número de bytes de cabeçalho de camada 2 nos segmentos ATM e Frame Relay do link de interfuncionamento. Vamos analisar essa sobrecarga mais detalhadamente.

As duas tabelas a seguir mostram os bytes de sobrecarga para pacotes de dados e pacotes de voz sobre IP (VoIP).

Tabela 2 - Sobrecarga do link de dados em 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 - Sobrecarga do link de dados em 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+User Datagram Protocol (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

Ao revisar as tabelas acima, observe o seguinte:

• Os pacotes menores que o tamanho de fragmentação especificado são encapsulados somente em um cabeçalho PPP e não em um cabeçalho MLPPP. Da mesma forma, os pacotes maiores 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 a menos de sobrecarga.

• Somente o primeiro fragmento MLP (Multilink PPP) inclui um campo de ID do protocolo PPP. Assim, o primeiro fragmento carrega dois bytes extras de sobrecarga.

• No modo transparente, os cabeçalhos de encapsulamento são passados inalterados através do dispositivo IWF. Assim, a sobrecarga varia em cada direção e em cada segmento. Especificamente, um cabeçalho MLPPPoA começa com um cabeçalho NLPID curto de 0xFEFE. No modo transparente, esse cabeçalho é passado inalterado pelo dispositivo IWF do segmento ATM para o segmento Frame Relay. No entanto, no sentido Frame Relay para ATM, tal cabeçalho não existe no modo transparente em nenhum dos segmentos.

• No modo de conversão, o dispositivo IWF altera os cabeçalhos de encapsulamento. Assim, o overhead é o mesmo em cada segmento em qualquer direção. Especificamente, na direção ATM para Frame Relay, o ponto final ATM encapsula o pacote em um cabeçalho MLPPPoA. O dispositivo IWF remove o cabeçalho NLPID antes de passar o quadro restante para o segmento Frame Relay. No sentido Frame Relay para ATM, o dispositivo IWF manipula novamente o quadro e precede um cabeçalho NLPID antes de passar o quadro segmentado para o ponto final ATM.

• Ao projetar links FRF com MLP, certifique-se de levar em conta o número correto de bytes de sobrecarga de link de dados. Essa sobrecarga influencia 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. Otimizar o tamanho do fragmento para ajustar um número inteiro de células ATM é essencial, particularmente em PVCs de baixa velocidade, onde uma quantidade significativa de largura de banda pode ser desperdiçada ao preencher a última célula para um múltiplo par de 48 bytes.

Para fins de clareza, vamos passar pelas etapas do processo de encapsulamento de pacotes quando um pacote vai no sentido Frame Relay para ATM com modo transparente:

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

2. O dispositivo IWF remove o cabeçalho Frame Relay de dois bytes com o Identificador de Conexão de Enlace de Dados (DLCI). Em seguida, ele encaminha o pacote restante para a interface ATM do IWF, que segmenta o pacote em células e o encaminha pelo segmento ATM.

3. O ponto final ATM examina o cabeçalho do pacote recebido. Se os dois primeiros bytes do pacote recebido forem 0x03CF, o ponto final ATM considerará o pacote um pacote MLPPPoA válido.

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

Examine o processo de encapsulamento de pacotes quando um pacote for no ATM para a direção do Frame Relay com o modo transparente:

1. O ponto final ATM encapsula o pacote em um cabeçalho MLPPPoA. Em seguida, segmenta os pacotes em células e os encaminha para fora do segmento ATM.

2. O IWF recebe o pacote, o encaminha para sua interface do Frame Relay e antecede um cabeçalho do Frame Relay de dois bytes.

3. O ponto final do Frame Relay examina o cabeçalho do pacote recebido. Se os primeiros quatro bytes após o cabeçalho de Frame Relay de dois bytes forem 0xfefe03cf, o IWF tratará o pacote como um pacote MLPPPoFR válido.

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

As ilustrações a seguir mostram o formato dos pacotes MLPPPoA e MLPPPoFR.

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

Figura 7. carga adicional de MLPPPoFR. Somente o primeiro fragmento transporta 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 os requisitos de largura de banda por chamada para VoIP, dependendo do codec e do uso do protocolo RTP compactado. Os cálculos na Tabela 4 supõem um cenário melhor para a compactação de cabeçalho RTP (cRTP), ou seja, nenhum checksum UDP ou erros de transmissão. Os cabeçalhos são compactados consistentemente de 40 bytes para dois bytes.

Tabela 4 - Requisitos de largura de banda por 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 - Amostras de 20 ms - Sem cRTP	27.6	42.4	42.4	28.4	27.6	42.4	42.4	27.6	26.8
G729 - Amostras de 20 ms - cRTP	12.4	21.2	21.2	13.2	12.4	21.2	21.2	12.4	11.6
G729 - Exemplos de 30 ms - Sem cRTP	20.9	28.0	28.0	21.4	20.9	28.0	28.0	20.9	20.3
G729 - Amostras de 30 ms - cRTP	10.8	14.0	14.0	11.4	10.8	14.0	14.0	10.8	10.3
G711 - Exemplos de 20 ms - Sem 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 - Exemplos de 30 ms - cRTP	66.3	84.0	84.0	66.8	66.3	84.0	84.0	66.3	65.7

Como a sobrecarga varia em cada trecho do PVC, recomendamos que você elabore um projeto para o pior cenário possível. Por exemplo, considere o caso de uma chamada G.279 com amostragem de 20 ms e cRTP em um PVC transparente. No trecho do Frame Relay, o requisito de largura de banda é de 12,4 kbps em uma direção e 13,2 kbps na outra. Portanto, recomendamos o provisionamento com base em 3,2 kbps por chamada.

Para fins de comparação, a tabela também mostra o requisito de largura de banda de VoIP em um PVC de Frame Relay de ponta a ponta configurado com fragmentação FRF.12. Como observado na tabela, o PPP consome entre 0,5 kbps e 0,8 kbps de largura de banda adicional por chamada para suportar os bytes adicionais do cabeçalho de encapsulamento. Assim, recomendamos o uso de FRF.12 com VCs de Frame Relay de ponta a ponta.

O RTP comprimido (cRTP) sobre ATM requer o software Cisco IOS® versão 12.2(2)T. Quando o cRTP está habilitado com MLPoFR e MLPoATM, a compactação de cabeçalho TCP/IP é habilitada automaticamente e não pode ser desabilitada. Essa restrição resulta do RFC 2509, que não permite a negociação PPP da compactação de cabeçalho RTP sem também negociar a compactação de cabeçalho TCP.

Tradução e suporte transparente para dispositivos Cisco

Originalmente, a LFI exigia que os dispositivos IWF usassem o modo transparente. Mais recentemente, o Frame Relay Forum apresentou o FRF.8.1 para suportar o modo de conversão. A Cisco introduziu suporte para FRF.8.1 e modo de conversão nas seguintes versões do 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) nos roteadores Cisco IOS com interfaces ATM, 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 for esse o caso, o provedor deverá configurar seus PVCs para o modo transparente.

Hardware e Software

Essa configuração usa o seguinte hardware e software:

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

• Dispositivo IWF - LS1010 com módulo adaptador de porta T3 canalizado e Cisco IOS Software Release 12.1(8)EY.

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

Diagrama de topologia

Configurações

Esta seção mostra como configurar o recurso LFI em um link FRF.8 no modo transparente. Ele usa um modelo virtual nos dois endpoints do roteador, a partir do qual a interface de acesso virtual do pacote MLP é clonada. O LFI suporta interfaces de discador e modelos virtuais para especificar os parâmetros da camada de protocolo do MLPPP. O Cisco IOS Software Release 12.2(8)T aumenta para 200 o número de modelos virtuais exclusivos que podem ser configurados por roteador. As versões anteriores suportam apenas até 25 modelos virtuais por roteador. Essa limitação pode ser um problema de escalabilidade em um roteador de distribuição ATM se cada PVC for necessário para ter um endereço IP exclusivo. Como solução alternativa, use IP como não numerado ou substitua modelos virtuais por interfaces de discador em links numerados.

O Cisco IOS versão 12.1(5)T introduziu suporte para LFI em apenas um link membro por pacote MLPPP. Portanto, essa configuração usa apenas um único VC em cada endpoint. O suporte para vários VCs por pacote está planejado para uma próxima versão do Cisco IOS.

Ponto final do Frame Relay

O adaptador de porta T3 canalizado requer que você crie um channel-group e especifique os timeslots. Por padrão, não existem interfaces. 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 Use o comando show diag para determinar o adaptador de porta instalado. Neste exemplo, o PA T3 está no slot 3. As versões atuais do Cisco IOS agora exibem o número de peça substituível em campo (FRU) a ser pedido em caso de falha de 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 A execução do comando show controller t3 exibe alarmes e estatísticas da camada física. 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] Selecione um T1 no modo de configuração do controlador T3, crie um channel-group e atribua timeslots 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 Observação: se a interface remota conectada não estiver configurada de forma semelhante, a camada de enlace da nova interface canalizada será ativada, mas o protocolo de linha permanecerá inativo. A interface serial 3/0/1:1 identifica a nova interface canalizada. Configure a interface para o encapsulamento do Frame Relay e ative 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. Configure uma classe de mapa de Frame Relay para aplicar parâmetros de modelagem de tráfego ao VC de Frame Relay (que será criado 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 Crie uma política de serviço de QoS. Use os mesmos parâmetros que o lado ATM. Consulte abaixo para obter 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) Crie uma interface de modelo virtual e aplique parâmetros MLPPP. Aplique também a política de serviço 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 Crie uma subinterface e atribua o número do Identificador de Conexão de Enlace de Dados (DLCI) do Frame Relay. Em seguida, aplique o encapsulamento PPP, o molde virtual e a classe de mapa. 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 Use o comando show frame-relay pvc para confirmar seus parâmetros de molde virtual e classe de mapa 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 Use o comando show controller serial 3/0/1:1 para confirmar se o enlace do Frame Relay está em um status ativo e livre de alarmes da camada física. Cada interface canalizada recebe um número "VC". Na saída a seguir, channel-group 1 (3/0/1:1) recebe 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

Use o comando show hardware para confirmar se o seu LS1010 está equipado com um módulo adaptador de porta (PAM) de Frame Relay canalizado. 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 Use o comando show ip int brief para identificar a interface 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 Crie uma interface canalizada e selecione os mesmos timeslots 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 Configure o encapsulamento do Frame Relay na nova interface serial. Além disso, altere o tipo de Local Management Interface (LMI) de NNI para 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 Use o comando show interface serial para confirmar o encapsulamento do 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 Antes de configurar o PVC, certifique-se de que a interface ATM esteja 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 Além das duas interfaces físicas, o LS1010 usa uma interface lógica para vincular o lado ATM e o lado 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 No modo de configuração de interface serial, configure o PVC de interfuncionamento. 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 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

Certifique-se de estar usando um ATM PA ou PA-A3 avançado. Use o comando show interface atm para 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] Configure os parâmetros da camada ATM do PVC (Permanent Virtual Circuit Circuito Virtual Permanente). Nesta configuração, estamos usando uma subinterface ponto-a-ponto com uma taxa de célula sustentada (SCR) de 150 kbps. Esse valor foi selecionado para ser cerca de 15% mais alto que a CIR de 128 kbps do ponto final do Frame Relay. Os 15% adicionais ajudam a garantir que o VC forneça uma largura de banda equivalente ao tráfego real do usuário em ambos os lados da conexão, acomodando a sobrecarga extra do lado ATM. (Consulte também Configurando a modelagem de tráfego em PVCs de Frame Relay para ATM Service Interworking (FRF.8).) 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. Confirme se o VC aparece na tabela VC. Execute o comando show atm vc. Observe que o roteador atribui um tamanho de intermitência máximo (MBS) padrão de 94, já que não inserimos 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 Crie uma política de serviço de QoS. Na política mostrada abaixo, criamos quatro classes, incluindo a classe padrão de classe criada pelo roteador. Crie um mapa de classe para os pacotes de voz sobre 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. Crie um mapa de classe para os pacotes de sinalização de voz. Este exemplo usa o H.323 Fast Connect. (Consulte também a seção "Diretrizes de configuração de LLQ" de Links VoIP sobre PPP com Qualidade de Serviço (Prioridade de LLQ / IP RTP, LFI, 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 Crie um mapa de políticas nomeado e atribua ações de QoS a cada classe. Este exemplo atribui o enfileiramento de prioridade aos pacotes de usuário de VoIP com o comando priority e uma garantia de largura de banda mínima aos pacotes de sinalização de chamada com o comando bandwidth. Todo o tráfego restante vai para a classe padrão de classe, que separa o tráfego em fluxos de camada IP e fornece enfileiramento justo entre os fluxos. policy-map example class call-control bandwidth percent 10 class voice priority 110 class class-default fair-queue 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 Crie um modelo virtual e aplique a política de serviço de QoS a ele. 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. Aplique o molde virtual e o encapsulamento PPP multilink ao PVC ATM. 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 Confirme suas configurações no PVC ATM. 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 O roteador cria automaticamente uma interface de acesso virtual. Se você não tiver o MLPPP configurado no ponto final do Frame Relay, o status da interface de acesso virtual será 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 seguintes comandos no ponto final ATM para confirmar se o LFI está funcionando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

• show ppp multilink - O LFI usa duas interfaces de acesso virtual — uma para PPP e outra para o pacote MLP. Use o comando show ppp multilink para diferenciar 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 se a interface de acesso virtual está up/up e incrementando os contadores de 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 se a política de serviço de QoS está vinculada à interface do pacote 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
  

• debug ppp packet e debug atm packet - Use esses comandos se todas as interfaces estiverem up/up, mas você não for capaz de fazer ping de ponta a ponta. Além disso, você pode usar esses comandos para capturar manutenções de atividades do PPP, conforme 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 seguintes comandos no ponto final do Frame Relay para confirmar se o LFI está funcionando corretamente. Antes de emitir comandos debug, consulte Informações importantes sobre comandos debug.

• show ppp multilink - O LFI usa duas interfaces de acesso virtual — uma para PPP e outra para o pacote MLP. Use o comando show ppp multilink para diferenciar 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 
  

• show policy-map interface virtual-access - Confirme se a política de serviço de QoS está vinculada à interface do pacote 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 
  
  

• debug frame packet e debug ppp packet - Use esses comandos se todas as interfaces estiverem up/up, mas você não puder fazer ping 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 a partir da interface do discador ou do modelo virtual. Uma dessas interfaces representa o link PPP e a outra representa a interface de conjunto MLP. Use o comando show ppp multilink para determinar a interface específica usada para cada função. A partir desse momento, somente um VC por pacote é suportado e, portanto, somente uma interface de acesso virtual deve aparecer na lista de membros do pacote na saída show ppp multilink.

Além das duas interfaces de acesso virtual, cada PVC é associado a uma interface principal e a uma subinterface. Cada uma dessas interfaces fornece alguma forma de enfileiramento. No entanto, somente a interface de acesso virtual que representa a interface do pacote suporta o enfileiramento virtual por meio de uma política de serviço QoS aplicada. As outras três interfaces devem ter enfileiramento FIFO. Ao aplicar uma política de serviço a um modelo virtual, o roteador exibe a 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

Observação: o Enfileiramento Moderado Ponderado Baseado em Classe é suportado apenas na interface de conjunto MLPPP.

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 política de serviço é aplicada à interface de acesso virtual do pacote MLP. Para confirmar o mecanismo de enfileiramento na interface do pacote MLP, use os comandos show interface virtual-access, show queue virtual-access e show policy-map interface virtual-access.

O MLPPPoFR requer que o Frame Relay Traffic Shaping (FRTS) esteja habilitado na interface física. O FRTS ativa filas por VC. Em plataformas como as séries 7200, 3600 e 2600, o FRTS é configurado com os dois comandos a seguir:

• modelagem de tráfego frame-relay na interface principal

• map-class com qualquer comando shaping.

As versões atuais do Cisco IOS imprimem a seguinte mensagem de aviso se MLPPoFR for aplicado sem FRTS.

"MLPoFR not configured properly on Link x Bundle y"

Se essa mensagem de aviso for exibida, verifique se o FRTS foi configurado na interface física e se a política de serviço de QoS foi anexada ao modelo 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 enfileiramento de interface é alterado para FIFO duplo, como ilustrado abaixo. A fila de alta prioridade lida com pacotes de voz e pacotes de controle, como a Local Management Interface (LMI), e a fila de baixa prioridade lida com pacotes fragmentados, presumivelmente pacotes de dados ou de não 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: o nível de pacote MLPPP, que suporta enfileiramento virtual, e o nível PVC, que suporta apenas enfileiramento FIFO. A interface do pacote mantém sua própria fila. Todos os pacotes MLP passam primeiro pelo conjunto MLP e pelas camadas de acesso virtual antes da camada Frame Relay ou ATM. O LFI monitora o tamanho das filas de hardware dos links membros e desenfileira pacotes para as filas de hardware quando eles ficam abaixo de um limite, que originalmente era um valor de dois. Caso contrário, os pacotes serão enfileirados na fila do pacote MLP.

Troubleshooting e Problemas Conhecidos

A tabela a seguir lista os problemas conhecidos com links LFI sobre FRF e focaliza as etapas de Troubleshooting a serem seguidas para isolar os sintomas em um bug resolvido.

Sintoma	Passos de Troubleshooting	Erros Resolvidos
Throughput reduzido em trecho ATM ou trecho Frame Relay	Faça ping com pacotes de vários tamanhos de 100 bytes para o MTU Ethernet. Os pacotes grandes atingem tempos limite?	CSCdt59038 - Com pacotes de 1.500 bytes e fragmentação definida como 100 bytes, há 15 pacotes fragmentados. O atraso foi causado por vários níveis de enfileiramento. CSCdu18344 - Com o FRTS, os pacotes são desenfileirados mais lentamente do que o esperado. A função de desenfileiramento de pacote MLPPP verifica o tamanho da fila do modelador de tráfego. O FRTS estava muito lento na limpeza dessa fila.
Pacotes fora de ordem	Execute o comando show ppp multilink. Procure os valores incrementais dos contadores "fragmentos perdidos", "descartados" e "recebidos perdidos". 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 Ative debug ppp multi events e procure mensagens "Lost fragment" (Fragmento perdido) e "Out of sync with peer" (Fora de sincronia com o correspondente). *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 está congestionada, os fragmentos MLP são descartados ou recebidos fora de ordem na extremidade remota. Esse problema afeta apenas os módulos de rede ATM nas séries 2600 e 3600. Ele é o resultado de como o driver de interface estava comutando incorretamente pacotes no caminho rápido (como na comutação rápida ou no Cisco Express Forwarding). Especificamente, o segundo fragmento do pacote atual foi enviado após o primeiro fragmento do próximo pacote
Perda de conectividade fim-a-fim quando o 3600 Series executa o IWF no modo transparente	Altere o modo para translational e teste novamente.	CSCdw11409 - Garante que o CEF procure no local de bytes correto para iniciar o processamento dos cabeçalhos de encapsulamento de pacotes MLPPP

Informações Relacionadas

• Configurando a fragmentação e interfaceamento de link para Frame Relay e circuitos virtuais ATM
• Projetando e implantando o Multilink PPP por Frame Relay e ATM
• RFC2364, PPP sobre AAL5, julho de 1998
• RFC1973, PPP no Frame Relay, junho de 1996
• RFC1717, O PPP Multilink Protocol (MP), novembro de 1994
• Contrato de implementação de entrelaçamento de serviço PVC FRF.8 de Frame Relay / ATM
• Mais informações ATM
• Ferramentas e recursos - Cisco Systems
• Suporte Técnico e Documentação - Cisco Systems