Voz : Protocolos de gateway

Desenhando e Implantando Multilink PPP no Frame Relay e ATM

3 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (16 Agosto 2007) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes Usados
     Convenções
Desenho
     Sobrecarga de Link de Dados
     Requisitos de Largura de Banda de VoIP
     Otimizar o Tamanho de Fragmentação
     Considerações sobre Vigilância e Modelagem de Tráfego
Dicas e Advertências
Caso Prático
     Introdução
     Visão Geral de Rede
     Configurações
Discussões relacionadas da comunidade de suporte da Cisco
Informações Relacionadas

Introdução

O Multilink PPP para ATM e Multilink PPP para Frame Relay (MLPoATM e MPLoFR) foi introduzido no Cisco IOS® Software Release 12.1(5)T. Esse recurso é destinado a clientes com interconexão de Frame Relay/ATM (FR/ATM IW) que implantam Voice over IP (VoIP) em links de WAN de velocidade média a baixa. Antes desse recurso, não havia esquema comum de fragmentação da Camada 2 que fosse suportado pelo Cisco IOS em clientes ATM e Frame Relay. Os clientes com FR/ATM IW eram forçados a fazer fragmentação da Camada 3.

Pré-requisitos

Requisitos

Este documento é direcionado às pessoas envolvidas com o desenho e a implantação de redes VoIP que envolvem redes MLPoATM e Frame Relay. Os leitores deste documento devem ter conhecimento destes tópicos:

  • Frame Relay

  • ATM

  • PPP

  • MLP

  • Interconexão de Frame Relay/ATM

  • Configuração de Quality of Service (QoS) de Voz

Este documento não tem a intenção de fornecer treinamento de tecnologia sobre esses assuntos. Uma lista de materiais de referência é incluída no final deste documento. A Cisco recomenda que esses documentos sejam analisados e compreendidos antes da leitura deste documento.

Componentes Usados

As informações neste documento são baseadas nestas versões de hardware e software:

  • Cisco IOS Software Release 12.1(5)T ou posterior para MLP em FR/ATM IW

  • Cisco IOS Software Release 12.2(2)T ou posterior para Compressed Real Time Transport Protocol (cRTP) em ATM

  • Cisco IOS Software Release 12.0(7)T para Low Latency Queueing (LLQ) em Frame Relay e ATM na interface fìsica

  • Cisco IOS Software Release 12.1(2)T para LLQ no Frame Relay e no ATM por permanent virtual circuit (PVC)

O caso prático incluído neste documento é baseado em uma rede de produção que usa estas versões de software e hardware:

  • O roteador Cisco 3660 principal em execução no Cisco IOS Software Release 12.2(5.8)T. O requisito de cRTP em ATM dita a utilização do Cisco IOS Software Release 12.2T. Esse problema conhecido foi resolvido no software Cisco IOS Software Release 12.2(8)T1:

    • Identificação de erro da Cisco CSCdw44216 (clientes registrados somente) - o cRTP provoca alta utilização de CPU quando o link class-based weighted fair queueing (CBWFQ)/LLQ atinge o congestionamento.

  • O roteador de filial Cisco 2620 está em processo de atualização do Cisco IOS Software Release 12.2(3) para 2.2(6a). Os Cisco 2620 também atuam como gateways H.323 filiais. A atualização é desencadeada por um problema relacionado a gateway. Quanto aos recursos de WAN w QoS, o Cisco IOS Software Release 12.2(3) não apresenta quaisquer problemas significativos.

Convenções

Para obter mais informações sobre convenções de documentos, consulte Convenções de Dicas Técnicas da Cisco.

Desenho

Esta seção discute vários conceitos relacionados ao desenho e à implantação da Multink PPP em Frame Relay e ATM.

Sobrecarga de Link de Dados

Quando desenha redes ATM e Frame Relay com MLP, você precisa compreender a sobrecarga de link de dados. A sobrecarga tem influência sobre o total de largura de banda que cada chamada de VoIP consome. Ela também desempenha um papel na determinação do tamanho de fragmento do MLP ideal. A otimização do tamanho do segmento para se adequar a um número inteiro das células de ATM é fundamental, especialmente em PVCs de baixa velocidade em que um valor significativo de largura de banda é perdido em preenchimento de célula. A sobrecarga de link de dados no MLP em PVCs de Frame Relay e ATM depende destes fatores:

  • O modo de operação do dispositivo FRF.8 IW (transparente ou translacional).

  • O sentido do tráfego (ATM para Frame Relay ou Frame Relay para ATM).

  • O trecho PVC. A sobrecarga é diferente nos segmentos de ATM e de Frame Relay do PVC.

  • O tipo de tráfego. Os pacotes de dados possuem um cabeçalho MLP e os pacotes VoIP, não.

A tabela aqui mostra a sobrecarga de link de dados para um pacote de dados. Ela detalha o número de bytes nos vários cabeçalhos de Frame Relay, ATM, LLC, PPP e MLP de todas as permutações do modo de operação FRF.8, direção de tráfego e trecho PVC.

Modo de 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

Trecho de Frame Relay de PVC

Frame Relay

ATM

ATM

Frame Relay

Frame Relay

ATM

ATM

Frame Relay

                 

Indicador de Quadro (0x7e)

1

0

0

1

1

0

0

1

Cabeçalho de Frame Relay

2

0

0

2

2

0

0

2

LLC DSAP/SSAP1 (0xfefe)

0

0

2

2

0

2

2

0

Control de LLC (0x03)

1

1

1

1

1

1

1

1

NLPID2 (0xcf para PPP)

1

1

1

1

1

1

1

1

ID do Protocolo MLP (0x003d)

2

2

2

2

2

2

2

2

Número de seqüência de MLP

4

4

4

4

4

4

4

4

ID de protocolo PPP (somente primeiro 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

Frame Check Sequence (FCS)

2

0

0

2

2

0

0

2

Sobrecarga total (bytes)

15

18

20

17

15

20

20

15

1DSAP/SSAP - Ponto de Acesso do Serviço de Destino/Ponto de Acesso do Serviço de Origem.

2NLPID - Identificação do Protocolo da Camada de Rede.

O PVC de conversão é mais fácil de compreender, uma vez que a sobrecarga é a mesma nos dois sentidos. Isso ocorre porque o dispositivo FRF.8 converte entre os formatos MLPoATM e MLOOFR. Como resultado, o formato do quadro é MLPoFR nos dois sentidos do trecho do Frame Relay. O formato nos dois sentidos do trecho ATM é MLOoATM.

O PVC transparente está ligeiramente mais conturbado porque a sobrecarga é diferente nos dois sentidos. Essa complexidade ocorre porque o roteador do Frame Relay envia pacotes no formato MPLoFR. Esse formato é transportado pelo dispositivo IW no lado ATM. Da mesma forma, o roteador do ATM envia pacotes no formato MLPoATM. Esse formato é transportado pelo dispositivo IW no lado do Frame Relay. Portanto, o resultado são formatos de quadro diferentes nos dois sentidos de cada trecho.

Em comparação, a sobrecarga em um PVC de Frame Relay de ponta a ponta que usa FRF.12 tem 11 bytes. Portanto, em um link de Frame Relay de ponta a ponta, o FRF.12 é uma escolha mais eficiente de fragmentação de link e intercalação (LFI) que o MLP. Em circuitos virtuais ATM de ponta a ponta, o MLP é a única opção, já que não existe fragmentação baseada em padrões disponível. No entanto, VCs de ATM ponta a ponta são de velocidade média a alta. Portanto, o LFI não é necessário. A exceção a esta regra são os VCs de ATM de baixa velocidade em linha de assinante digital (DSL).

A ID do PPP está presente somente no primeiro fragmento de MLP. Sendo assim, a sobrecarga no primeiro fragmento é sempre dois bytes a mais que nos fragmentos subseqüentes.

A tabela aqui mostra a sobrecarga de link de dados para um pacote VoIP. Ela detalha o número de bytes nos vários cabeçalhos de Frame Relay, ATM, LLC e PPP para todas as permutações do modo de operação FRF.8, do sentido de tráfego e da derivação de PVC. A principal diferença entre um pacote de dados e um pacote VoIP é que os pacotes VoIP são enviados como pacotes PPP e não como pacotes MLP. Todos os demais aspectos são idênticos ao cenário de dados.

Modo de FRF.8

Transparente

Tradução

Frame Relay para Frame Relay

Sentido de tráfego

Frame Relay para ATM

ATM para Frame Relay

Frame Relay para ATM

ATM para Frame Relay

 

Trecho de Frame Relay de PVC

Frame Relay

ATM

ATM

Frame Relay

Frame Relay

ATM

ATM

Frame Relay

 
                   

Indicador de Quadro (0x7e)

1

0

0

1

1

0

0

1

1

Cabeçalho de Frame Relay

2

0

0

2

2

0

0

2

2

LLC DSAP/SSAP (0xfefe)

0

0

2

2

0

2

2

0

0

Control de 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

Sobrecarga total (bytes)

9

12

14

11

9

14

14

9

7

A sobrecarga do link de dados para um pacote VoIP em um PVC de Frame Relay de ponta a ponta é mostrada em comparação na coluna mais a direita.

Requisitos de Largura de Banda de VoIP

Quando você aprovisiona a largura de banda para o VoIP, a sobrecarga do link de dados deve ser incluída nos cálculos da largura de banda. A tabela a seguir mostra os requisitos de largura de banda por chamada para as várias versões de VoIP. Ela é baseada nas características do PVC. Os cálculos da tabela supõem um cenário ideal para cRTP (por exemplo, nenhum checksum de UDP e nenhum erro de transmissão). OS cabeçalhos são consistentemente compactados de 40 bytes para 2 bytes.

Modo de 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

 

Trecho de Frame Relay de PVC

Frame Relay

ATM

ATM

Frame Relay

Frame Relay

ATM

ATM

Frame Relay

 
                   

G.729 – Exemplos de 20 ms - Sem cRTP

27.6

42.4

42.4

28.4

27.6

42.4

42.4

27.6

26.8

G.729 – Exemplos de 20 ms - cRTP

12.4

21.2

21.2

13.2

12.4

21.2

21.2

12.4

11.6

G.729 – Exemplos de 30 ms - Sem cRTP

20.9

28.0

28.0

21.4

20.9

28.0

28.0

20.9

20.3

G.729 – Exemplos de 30 ms - cRTP

10.8

14.0

14.0

11.4

10.8

14.0

14.0

10.8

10.3

G.711 – Exemplos de 20 ms - Sem cRTP

83.6

106.0

106.0

84.4

83.6

106.0

106.0

83.6

82.8

G.711 – Exemplos de 20 ms - cRTP

68.4

84.8

84.8

69.2

68.4

84.8

84.8

68.4

67.6

G.711 – Exemplos de 30 ms - Sem cRTP

76.3

97.9

97.9

76.8

76.3

97.9

97.9

76.3

75.8

G.711 – 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 trechos diferentes do PVC, é necessário criar um desenho para a pior das hipóteses. Por exemplo, considere o G.729 com exemplo de 20 milissegundos (mseg) e cRTP em um PVC transparente. Os requisitos de largura de banda para este cenário no segmento de Frame Relay é de 12,4 Kbps em uma direção e de 13,2 Kbps na outra. Necessidades de aprovisionamento a serem realizadas supondo 13.2 Kbps por chamada.

O requisito de largura de banda de VoIP em um PVC de Frame Relay de ponta a ponta também é mostrado em comparação na coluna mais à direita da tabela acima. A sobrecarga de PPP comparada ao encapsulamento nativo de Frame Relay resulta em um consumo extra de largura de banda entre 0.5 Kbps e 0.8 Kbps por chamada. Portanto, o encapsulamento do Frame Relay com FRF.12 faz mais sentido que um MLP em um VC de Frame Relay de ponta a ponta.

Observação: O cRTP para ATM requer o Cisco IOS Software Release 12.2(2)T ou posterior.

Otimizar o Tamanho de Fragmentação

A razão para usar MLP em um PVC de Frame Relay/ATM é permitir que pacotes de dados maiores sejam fragmentados em chunks menores. O roteador então expede pacotes VoIP intercalando-os entre os fragmentos de dados. No Cisco IOS, o tamanho da fragmentação não é configurado diretamente. Em vez disso, o atraso desejado é configurado com a ajuda do comando ppp multilink fragment-delay . O Cisco IOS então calcula o tamanho do fragmento correspondente usando esta fórmula:

fragment size = delay x bandwidth/8

Quando você faz MLP no ATM, o tamanho do fragmento precisa ser otimizado para que se ajuste em um número inteiro de células. Se essa otimização não for feita, a largura de banda necessária pode quase dobrar devido ao preenchimento. Por exemplo, se cada fragmento tiver 49 bytes, duas células de ATM serão necessárias para carregar cada fragmento. Portanto, 106 bytes são usados para transportar um payload de apenas 49 bytes.

O Cisco IOS automaticamente otimiza o tamanho do fragmento para usar seu número inteiro de células de ATM quando faz MLPoATM e MLPoFR. O Cisco IOS automaticamente arredonda o tamanho do fragmento calculado para o próximo número inteiro de células de ATM. Não são adicionados comandos de CLI. O Cisco IOS realiza essa otimização nas extremidades do Frame Relay e do ATM de um PVC de MLPoFR/ATM. É possível que um PVC do MLP seja Frame Relay de ponta a ponta. Nesse caso, não é necessário otimizá-lo para ATM. Entretanto, o Cisco IOS otimiza esse cenário para ATM, pois não tem como saber se a extremidade remota é ATM ou Frame Relay.

Observação: Devido ao arredondamento, o atraso resultante pode ser ligeiramente mais alto que o configurado. Esse erro de arredondamento é mais significativo em PVCs de velocidade baixa.

A otimização também pode ser configurada manualmente. Como o tamanho do fragmento não pode ser especificado diretamente no Cisco IOS, calcule o tamanho de fragmento ideal e converta-o em um atraso. Quando você fizer esse cálculo, ajuste a sobrecarga do link de dados, pois o código do MLP supõe que todos os links são High-Level Data Link Control (HDLC) e tenham 2 bytes de sobrecarga de link. Além da sobrecarga de link de dados HDLC, o código MLP inclui em seus cálculos os 8 bytes que compõem o ID MLP, o número de Seqüência MLP e o ID PPP conforme descrito na primeira tabela acima.

Use este procedimento para calcular o atraso a ser configurado no Cisco IOS.

  1. Calcule o tamanho do fragmento teórico com base no atraso desejado e na largura de banda do PVC:

    fragment = bandwidth * delay / 8
  2. Certifique-se de que o fragmento é um múltiplo de 48 bytes, de modo que ele se encaixe em um número inteiro de células ATM. A fórmula para calcular o tamanho do fragmento alinhado à célula é:

    fragment_aligned = (int(fragment/48)+1)*48
  3. Ajuste a sobrecarga do link de dados que não foi considerada pelo MLP.

    Como visto anteriormente, essa sobrecarga difere com base em características do PVC. Considere o lado do ATM do PVC como o lado do qual você otimizará. A tabela aqui mostra o número de bytes da sobrecarga do link de dados no lado do ATM.

    Modo de 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

    Trecho de Frame Relay de PVC

    ATM

    ATM

    ATM

    ATM

             

    LLC DSAP/SSAP (0xfefe)

    0

    2

    2

    2

    Control de LLC (0x03)

    1

    1

    1

    1

    NLPID (0xcf for PPP)

    1

    1

    1

    1

    AAL5

    8

    8

    8

    8

             

    Sem sobrecarga de MLP (bytes)

    10

    12

    12

    12

    Para chegar ao tamanho do fragmento no qual o MLP baseia seus cálculos, subtraia a sobrecarga do link de dados do tamanho do fragmento alinhado da célula desejada. Adicione 2 bytes para compensar o encapsulamento de HDCL que o MLP sempre presume. A fórmula resultante para calcular o tamanho do fragmento que o código do MLP visa é:

    fragment_mlp = fragment_aligned - datalink_overhead + 2
  4. Converta o tamanho do fragmento resultante no atraso correspondente com esta fórmula:

    delay = fragment_mlp/bandwidth x 8bits/byte
  5. Na maioria dos casos, o atraso calculado não é um número inteiro de milissegundos. Como o Cisco IOS aceita apenas um valor inteiro, você deve arredondar para baixo. Portanto, o valor do atraso configurado no Cisco IOS com a ajuda do comando ppp multilink fragment-delay é:

    fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)
  6. Para compensar o erro de arredondamento acima, altere a largura de banda utilizada pelo MLP para converter de atraso para fragmento. A largura de banda forjada, que você configura com o Cisco IOS com a ajuda do comando bandwidth é:

    bandwidth = fragment_mlp/fragment_delay * 8

A tabela a seguir mostra os valores ideais de ppp multilink fragment-delay e bandwidth para as velocidades de PVC mais comuns. Pressupõe-se um atraso de destino de 10 mseg. Para simplificar a tabela, os cálculos não diferenciam PVC transparente de PVC de conversão nem o sentido do tráfego. A diferença máxima na sobrecarga de link de dados é de apenas 2 bytes. Portanto, a penalidade para criar um desenho com base no pior caso de 12 bytes é pequena. A tabela também mostra o atraso “real” encontrado devido ao fato de você aumentar o tamanho do fragmento, de forma que os fragmentos se ajustem em todas as células.

Velocidade do PVC

Tamanho do Fragmento

ppp multi-link fragment-delay

Largura de banda

Real Delay

(Kbps)

(células)

(mseg)

(Kbps)

(mseg)

56

2

12

57

13.7

64

2

10

68

12.0

128

4

11

132

12.0

192

6

11

202

12.0

256

7

10

260

10.5

320

9

10

337

10.8

384

11

10

414

11.0

448

12

10

452

10.3

512

14

10

529

10.5

576

16

10

606

10.7

640

17

10

644

10.2

704

19

10

721

10.4

768

21

10

798

10.5

Considerações sobre Vigilância e Modelagem de Tráfego

Em um ambiente IW de Frame Relay/ATM, é dada especial consideração á vigilância e à modelagem do tráfego. Os problemas de sentido entre o Frame Relay e o ATM são diferentes dos problemas de sentido entre o ATM e o Frame Relay. Assim, cada um é discutido separadamente.

O principal problema no sentido do Frame Relay para o ATM é a expansão potencial no consumo de largura de banda quando passa do quadro para a célula. Por exemplo, um quadro de 49 bytes no lado do Frame Relay consome duas células ou 106 bytes no lado do ATM. Portanto, não se pode supor que a taxa de sustentabilidade da célula (SCR) seja igual à taxa de informações comprometidas (CIR). O pior cenário ocorre quando cada quadro do Frame Relay contém 1 byte de payload. Cada um desses bytes consome uma célula inteira de 53 bytes no lado do ATM. Como exemplo deste conceito, este cenário extremo e irreal dita uma SCR que é 53 vezes a CIR. Outros dois exemplos realistas são:

  • Um pacote VoIP do G.729 tem 60 bytes, ou 69 bytes, incluindo a sobrecarga do MLP e do Frame Relay. No trecho do ATM, ele consome duas células ou 106 bytes. Portanto, se todo o tráfego transportado for de VoIP, um mapeamento apropriado seria SCR = 106/69 = 1,5 x CIR.

  • Um pacote da Telnet que transporta um único keystroke contém 40 bytes de cabeçalho TCP/IP e 1 byte de dados. No lado do Frame Relay, isso totaliza 56 bytes, incluindo a sobrecarga. Porém, no lado do ATM, este pacote se expande para duas células. Neste caso, SCR = 106/56 = 1,9 x CIR.

O Apêndice A da norma do Fórum do ATM "BISDN Inter Carrier Interface (B-ICI) Specification Version 2.0" descreve dois métodos de mapeamento entre SCR e CIR. Embora os dois forneçam uma forma científica de derivar SCR do CIR, nenhum é mais preciso que os dados a que se aplicam. Um dos números necessários pelas fórmulas é o tamanho típico do quadro, um número difícil de determinar em uma rede real. Além disso, um número pode mudar potencialmente conforme novos aplicativos são lançados em uma rede de ATM/Frame Relay existente. A melhor recomendação para solucionar este problema é trabalhar rigorosamente com sua operadora, já que a política de vigilância será de importância decisiva. Com a assistência da operadora, esta abordagem à prova de falhas é possível:

  • Sentido Frame Relay para ATM - No sentido Frame Relay para ATM, a operadora precisa vigiar a entrada de tráfego somente no ponto de ingresso no Frame Relay. Por exemplo, no switch do Frame Relay conectado ao Frame Relay acoplado ao dispositivo customer premises equipment (CPE), a operadora vigia o tráfego de acordo com a CIR contratada. Essa política de vigilância é ilustrada na figura a seguir. Quando o tráfego for permitido no ponto de ingresso da rede, não deve ocorrer mais vigilância. A conseqüência dessa política de vigilância é que os dados recebidos no lado do Frame Relay podem se expandir e consumir a largura de banda necessária para permitir taxa de célula, sobrecarga de AAL e preenchimento, a fim de transportá-los no trecho ATM da rede. Na maioria dos casos, a largura de banda de ATM necessária é menor que duas vezes a largura do Frame Relay usada.

    ingress_policing.gif

  • Sentido do ATM para o Frame Relay - No sentido ATM para Frame Relay, ocorre o oposto. A utilização de largura de banda é reduzida quando vai do ATM para o quadro como uma taxa de célula, na sobrecarga de AAL e quando o preenchimento é removido. Entretanto, como a taxa de transmissão potencial do lado do ATM é bem maior que o do link do Frame Relay, a configuração correta da modelagem do tráfego no roteador do ATM é fundamental para a integridade de voz. Se a modelagem for muito folgada, o roteador do ATM alimentará dados a uma taxa mais rápida que a velocidade física do link do Frame Relay na outra extremidade. Como resultado, os pacotes começam a ser enfileirados no switch FRF.8. Em algum momento, os pacotes começarão a ser descartados e, como as redes de ATM/Frame Relay não diferenciam voz e dados, os pacotes VoIP também serão descartados.

    Ao mesmo tempo, se a modelagem estiver muito restritiva, a taxa de transmissão sofrerá. Devido à taxa de célula ATM, a sobrecarga de AAL e o preenchimento são removidos pelo dispositivo FRF.8. Não há consumo de largura de banda no link do Frame Relay. Portanto, você pode fazer uma assinatura ligeiramente excessiva do lado do ATM do PVC. A quantidade de preenchimento e a sobrecarga de AAL varia de acordo com o tamanho médio dos quadros e da agressividade da fragmentação. Como não é possível qualificar precisamente essa sobrecarga, é melhor não tentar otimizá-la. Por outro lado, a taxa de célula é totalmente determinista. Ela tem 5 bytes par cada 48 bytes de payload. Você pode otimizar a taxa de célula configurando o destino da modelagem no roteador do ATM como 53/48 x SCR. A vigilância no lado da operadora deve ser configurada para esse ligeiro excesso de assinatura.

Dicas e Advertências

  • O MLPoATM/Frame Relay atualmente só é testado e suportado com uma política de serviço vinculada a modelo virtual ou a interfaces do discador. A omissão da política de serviço pode fazer com que o recurso não funcione. Um exemplo está documentado na ID de erro da Cisco CSCdu19313 (clientes registrados somente) .

  • O MLPoATM/Frame Relay copia duas interfaces de acesso virtual para cada PVC. Uma delas representa o link PPP. A outra representa o link MLP. O comando show ppp multilink é usado para identificar cada uma delas. Atualmente, só há suporte para um link por pacote.

  • Cada PVC é associado a quatro interfaces diferentes, a saber: a interface física, a subinterface e duas interfaces de acesso virtual. Somente a interface de acesso virtual do MLP tem Fancy Queueing habilitado. As outras três devem ter enfileiramento first in, first out (FIFO).

  • Quando você aplica um comando service-policy a um modelo virtual, o Cisco IOS exibe essa mensagem normal de aviso:

    cr7200(config)#interface virtual-template 1
    cr7200(config-if)#service-policy output Gromit
                      Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
    Note CBWFQ supported on MLP bundle interface only.
                   

    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 primeira mensagem confirma que não a política de serviço teve efeito na interface de acesso virtual pacote do MLP. Esse fato é verificado com a ajuda dos comandos show interfaces virtual-access , show queue e show policy-map interface , que analisam o mecanismo de enfileiramento.

  • A autenticação de PPP não é estritamente necessária, pois um PVC é como uma linha alugada. Entretanto, a autenticação de PPP é útil quando o comando show ppp multilink é usado para determinar o nome do roteador da outra extremidade do PVC.

  • A modelagem do tráfego do Frame Relay deve estar habilitada para PVCs de MLPoFR, no roteador do Frame Relay.

  • O Cisco IOS Software Release 12.2 inicialmente suportava um máximo de 25 modelos virtuais por roteador. Essa limitação pode causar impacto na escala de um roteador de distribuição do ATM, se cada PVC precisar ter um endereço IP exclusivo. A solução para as versões afetadas é usar IP sem número ou interfaces de discagem, em vez de modelos virtuais. No Cisco IOS Software Release 12.2(8)T, o suporte é aumentado para 200 modelos virtuais.

  • Alguns provedores de serviço ainda não suportam a conversão de PPP em seus dispositivos FRF.8. Sempre que essa limitação ocorrer, os provedores devem configurar seus PVCs no modo transparente.

  • A maioria dos exemplos na documentação da Cisco IOS mostra configurações que incluem um Frame Relay ou subinterface ATM. Essas subinterfaces não têm objetivo. O modelo virtual deve ser anexado à interface física; O resultado é uma configuração mais compacta e gerenciável. Isso é especialmente importante se houver um número grande de PVCs.

  • Use o comando show ppp multilink como prova para determinar se há quadros/células descartados no lado da operadora. A única perda de segmento aceitável é a causada por erros de verificação de redundância cíclica (CRC).

  • Embora o MLPoATM/Frame Relay tenha sido introduzido no Cisco IOS Software Release 12.1(5)T, os bugs dessa versão e das versões posteriores exigem que o usuário tome cuidado ao selecionar a versão do Cisco IOS Software. A Cisco recomenda a utilização da versão de manutenção mais recente do mainstream do Cisco IOS. Entretanto, outros requisitos do recurso VoIP podem ditar o uso de Cisco IOS Software Release diferentes, como a 12.2(2)XT, se a Survivable Remote Site Telephony (SRST) for necessária. Esta tabela lista alguns problemas conhecidos. Ao selecionar o Cisco IOS, avalie as IDs de todos os bugs da Cisco.

ID de bug da Cisco

Descrição

CSCdt09293 (clientes registrados somente)

LFI – Switching rápido no 7200 provoca chamadas de voz unidirecionais.

CSCdt25586 (clientes registrados somente)

Acesso a PPPoA não sincronizado ou circuito virtual comutado (SVC) não desativado na expiração da inatividade.

CSCdt29661 (clientes registrados somente)

MLP – O desligamento da interface do ATM durante o switching rápido interrompe o roteador.

CSCdt53065 (clientes registrados somente)

Melhoria de desempenho no código atm_lfi para o recurso LFI do ATM.

CSCdt59038 (clientes registrados somente)

MLPoATM: Falha do ping com grandes pacotes em PA-A3.

CSCdu18344 (clientes registrados somente)

Taxa de transmissão do PVC do MLPoATM/Frame Relay menor que a SCR/CIR.

CSCdu19297 (clientes registrados somente)

PVC do MLPoATM sem política de serviço gera erros.

CSCdu41056 (clientes registrados somente)

MLPoATM: Rotina vc-soutput do driver chamada duas vezes.

CSCdu44491 (clientes registrados somente)

Contadores do Acesso Virtual incorretos para MLPoFR.

CSCdu51306 (clientes registrados somente)

Keepalives quebradas no PPPoX.

CSCdu57004 (clientes registrados somente)

CEF não funcionará com MLP.

CSCdu84437 (clientes registrados somente)

Implementação de controle de fluxo entre MLP e tx-ring ajustou drivers.

CSCdv03443 (clientes registrados somente)

Fazer correção para u76585 no Cisco IOS® Software Release 12.2 – Os pacotes de MLP de entrada são comutados no processo.

CSCdv10629 (clientes registrados somente)

MLPoATM: Os pacotes de voz não são enfileirados no LLQ.

CSCdv20977 (clientes registrados somente)

Os pacotes de entrada de MLP estão sendo comutados no processo.

CSCdw44216 (clientes registrados somente)

O cRTP provoca alto uso de CPU quando o link CBWFQ/LLQ atinge o congestionamento.

Caso Prático

Introdução

Esta seção descreve uma das primeiras implantações de cliente do recurso MLPoATM/Frame Relay. O cliente é chamado pelo nome fictício de XYZ LTd. Em 2001, a XYZ Ltd. substituiu seus PBXs por uma solução de telefonia IP. Como parte desse projeto, uma nova rede de IP foi criada e uma interconexão de Frame Relay/ATM foi escolhido para a WAN. A operadora que fornece o serviço de WAN usa switches Newbridge para fornecer os serviços de ATM e Frame Relay.

Visão Geral de Rede

A rede XYZ LTd é uma rede de hub e falada que conecta 26 filiais com dois sites principais. Cada site principal é atendido por uma ATM E3 conectada a um router Cisco 3660. Dezoito das 26 filiais são de tamanho médio. Elas têm PVCs de Frame Relay duplos que se conectam aos 3600 nos sites principais por meio de IW de ATM/Frame Relay. As oito filiais restantes são muito pequenas. Elas se conectam à filial de tamanho médio mais próxima por um único PVC de Frame Relay. Todos os roteadores das filiais são Cisco 2620. Um PVC de ATM de ponta a ponta conecta os dois roteadores 3660 aos dois sites de hub. Esta figura ilustra a topologia.

network.gif

Esta tabela mostra as velocidades de acesso e a CIR do Frame Relay A CIR varia de 32 kbps a 256 kbps. A tabela também mostra o número máximo de chamadas simultâneas de VoIP transportadas por cada PVC.

Site

Site Remoto

Acesso (kbps)

CIR (kbps)

Número de Chamadas

Filial 1

Central 1

320

192

6

Filial 2

Filial 22

128

64

2.0

Filial 3

Central 1

576

256

8.0

Filial 4

Filial 16

64

32

2.0

Filial 5

Central 1

128

64

2.0

Filial 6

Filial 3

64

32

2.0

Filial 7

Central 1

512

256

8.0

Filial 8

Central 1

512

256

8.0

Filial 9

Filial 13

128

256

2.0

Filial 10

Central 1

256

128

4.0

Filial 11

Central 2

128

96

2.0

Filial 12

Central 1

128

64

2.0

Filial 13

Central 1

768

256

12.0

Filial 14

Central 1

192

96

4.0

Filial 15

Central 1

192

96

4.0

Filial 16

Central 1

448

192

8.0

Filial 17

Filial 13

128

64

2.0

Filial 18

Central 1

128

96

2.0

Filial 19

Filial 16

128

64

2.0

Filial 20

Central 1

64

32

2.0

Central 2

Central 1

34000

256

12.0

Filial 21

Filial 13

128

64

2.0

Filial 22

Central 1

384

192

6.0

Filial 23

Central 1

512

256

8.0

Filial 24

Central 1

192

96

2.0

Filial 25

Central 1

128

96

4.0

Filial 26

Filial 1

64

32

2.0

A modelagem de tráfego de Frame Relay é executada pelos roteadores de filial. A intermitência além de CIR é permitida. A modelagem de tráfego do Cisco IOS é configurada para definir a velocidade de acesso, com minicir igual a CIR. Se forem recebidas notificações de congestionamentos explícitos no sentido oposto ( Essa abordagem vai de encontro às recomendações da Cisco sobre realização de VoIP para Frame Relay. A voz já apresentava problemas quando o roteador respondeu as notificações de congestionamento. Entretanto, nesse caso, a operadora acredita que sua rede esteja suficientemente bem provisionada para nunca descartar quadros ou células e; dessa forma, BECNs nunca serão vistos.

A modelagem de tráfego ATM é definida para modelar na velocidade de acesso de quadro na extremidade remota, mais taxa de célula. Por exemplo, se a velocidade de acesso for 512 Kbps, a SCR é definida como 512x53/48 = 565 Kbps. Essa taxa de modelagem é usada para maximizar a taxa de transmissão. Esse procedimento é seguro, pois a taxa de célula é separada no ponto de IW. A vigilância no lado da operadora está configurada generosamente para que o menor excesso de assinatura seja permitido.

O cRTP é utilizado do outro lado da WAN. Quanto à CPU, o principal local é o roteador de distribuição Cisco 3660 no site principal 1. No acréscimo dos números à tabela acima, é determinado que, em tese, o número máximo de chamadas de VoIP que atravessam esse roteador é 102. Os números de desempenho desse gráfico indicam que a carga da CPU do Cisco 3660 para 100 sessões de cRTP (comutadas rapidamente) é de aproximadamente 50 por cento.

3660-performance.gif

Modelos virtuais são usados com links de WAN com numeração IP. Um modelo virtual é necessário por PVC, o que é impossível, uma vez que o número total de PVCs que terminam em cada Cisco 3660 é menor que 25.

Configurações

Este documento utiliza estas configurações:

Roteador ATM Central

                  
                     !--- Observação: Esta seção mostra as partes de um router Cisco 3660.
!--- configuração relevante para MLPoATM.
                  

class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


                     !--- Observação:  Não configure.
!--- Endereços IP diretamente em qualquer fonte de configuração,
!--- como um modelo virtual, sempre que houver possibilidade
!--- de as informações serem duplicadas em várias
!--- interfaces ativas. A exceção à regra é o
!--- raro caso em que o objetivo é definir várias rotas de IP paralelas
!--- e fazer com que o IP fala equilíbrio de carga entre elas.
!--- Se um endereço IP estiver presente na fonte de configuração,
!--- ele será copiado em todas as interfaces copiadas.
!--- O IP instala uma rota em cada uma das interfaces.
                  
               

Roteador de Frame Relay da Filial

                  
                     !--- Observação: Esta seção mostra as partes de uma filial do router Cisco 2600.
!--- configurações relevantes para MLPoFR.
                  

class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

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