DM 2104

DATACOM
Manual CESoP DmSwitch 2104 – EDD
Documento Público Manual CESoP DmSwitch 2104 – EDD Página 1 de 50

Sumário
1 Introdução ao Serviço de Emulação de Circuitos sobre Pacotes (CESoP)...................................................4
1.1 TDM....................................................................................................................................................... 4
1.2 Bundle.................................................................................................................................................... 4
1.3 Pseudo-Wire.......................................................................................................................................... 4
2 Comandos Básicos do EDD.......................................................................................................................... 4
2.1 Login no Equipamento........................................................................................................................... 4
2.2 Configuração da Interface de Gerência................................................................................................. 5
2.3 Atualização de Firmware........................................................................................................................ 5
2.4 Aplicando a Configuração de Fábrica.................................................................................................... 5
2.5 Salvando a Configuração Atual na Memória.......................................................................................... 5
2.6 Visualizando a Configuração Atual........................................................................................................ 5
2.7 Alterando o HostName........................................................................................................................... 5
3 Topologia exemplo......................................................................................................................................... 6
4 Diferenças do Modelo SERIES I para os Modelos SERIES II e III................................................................6
4.1 Recursos................................................................................................................................................ 6
4.2 Comandos de configuração................................................................................................................... 6
4.3 Testes.................................................................................................................................................... 7
5 Diferenças de Comandos entre Firmwares.................................................................................................... 8
6 Configuração do SETUP................................................................................................................................ 8
6.1 Configuração da Gerência através da VLAN......................................................................................... 9
6.2 Configuração da Interface TDM............................................................................................................. 9
6.2.1 Configuração do Line Type.......................................................................................................... 10
6.2.2 Configuração de Impedância da TDM.........................................................................................10
6.2.3 Configuração de Sync Source..................................................................................................... 10
6.3 Configuração da Interface PW............................................................................................................. 11
6.3.1 Configuração do Endereço IP do PW..........................................................................................11
6.3.2 Configuração do Idle Byte............................................................................................................ 12
6.4 Configuração da Interface Bundle....................................................................................................... 12
6.4.1 Configuração do Número de Timeslots........................................................................................ 14
6.4.2 Mapeamento da Interface TDM................................................................................................... 14
6.4.3 Configuração do Packet Delay.................................................................................................... 14
6.4.4 Configuração do Jitter Buffer....................................................................................................... 15
6.4.5 Adição das portas ETH na VLAN do Bundle................................................................................16
6.4.6 Configuração do Endereço IP do Bundle.....................................................................................16
6.4.7 Configuração dos Dados de Destino do Bundle..........................................................................16
6.4.8 Configurando o Limite de Perda de Pacotes...............................................................................17
6.4.9 Atribuindo um Nome à Interface Bundle......................................................................................17
6.4.10 Configurando o DSCP............................................................................................................... 17
6.4.11 Configuração de preenchimento de pacotes perdidos...............................................................17
6.4.12 Configuração de R-Bit-Send-RAI............................................................................................... 17
6.4.13 Configurando a fonte de Relógio............................................................................................... 17
6.4.14 Habilitação do Bundle................................................................................................................ 19
7 Verificação Status das Interfaces................................................................................................................. 19
7.1 Status da Interface TDM...................................................................................................................... 19
7.1.1 TDM Status: Link Status.............................................................................................................. 20
7.1.2 TDM Status: Remote Alarm......................................................................................................... 20
7.1.3 TDM Status: CAS Status............................................................................................................. 21
7.1.4 TDM Status: CRC Status............................................................................................................. 21
7.2 Status da Interface Bundle................................................................................................................... 21
7.2.1 Bundle Status: Local Bundle........................................................................................................ 22
7.2.2 Bundle Status: Remote Bundle.................................................................................................... 22
7.2.3 Bundle Status: TDM Local........................................................................................................... 22
7.2.4 Bundle Status: TDM Remoto....................................................................................................... 22
7.2.5 TDM Status: Packet Size............................................................................................................. 22
7.2.6 TDM Status: Next-Hop................................................................................................................. 22
8 Habilitação Testes TDM............................................................................................................................... 23
8.1 Teste de BERT TDM/ETH.................................................................................................................... 23
8.1.1 Habilitando o Teste de BERT TDM/ETH......................................................................................23
8.1.2 Inserindo um Erro no Teste de BERT.......................................................................................... 23
8.2 Teste LDL na interface Bundle............................................................................................................. 23
8.2.1 Habilitando o Teste de LDL.......................................................................................................... 23
8.3 Verificando o Status dos Testes........................................................................................................... 24
9 Análise dos Contadores do Bundle.............................................................................................................. 24
9.1.1 Contador Bundle: Overflow.......................................................................................................... 24
9.1.2 Contador Bundle: Underflow........................................................................................................ 25
9.1.3 Contador Bundle: Lost Packets................................................................................................... 25
9.1.4 Contador Bundle: Out of Order Packets......................................................................................25
9.1.5 Contador Bundle: Sequence Number Violations..........................................................................25
9.1.6 Contador Bundle: Wrong Size Packets........................................................................................ 25
10 Análise dos Contadores da PW................................................................................................................. 26
11 Teoria de Operação da PW........................................................................................................................ 27
12 Monitor do Jitter-Buffer History.................................................................................................................. 30
12.1 Configuração do intervalo de leitura do jitter-buffer...........................................................................30
12.2 Visualização do log do Jitter-Buffer History........................................................................................ 30
13 Troubleshooting......................................................................................................................................... 31
13.1 Incremento de Wrong Size Packet em ambos os lados.....................................................................31
13.2 Jitter Buffer cai/sobe regularmente até causar Underflow/Overflow..................................................32
13.2.1 Procedimento padrão................................................................................................................ 32
13.2.2 Equipamentos ligados ponto-a-ponto, com apenas um Bundle.................................................32
13.2.3 Equipamentos ponto-a-ponto com mais de um Bundle e relógio regenerado de TDM..............33
13.2.4 Equipamentos com Bundles em topologia de estrela com relógio regenerado de TDM............34
13.3 Underflow/Overflow acontece subitamente........................................................................................ 34
13.4 Slips no tráfego dos equipamentos.................................................................................................... 35
14 Comportamento de Alarmes e Traps......................................................................................................... 35
14.1 TDM Unframed.................................................................................................................................. 35
14.1.1 Perda de Sinal (LOS)................................................................................................................. 35
14.1.2 Falha do Bundle Local (Perda de Conexão Ethernet)...............................................................36
14.1.3 Falha do Bundle Local (Perda Excessiva de Pacotes)..............................................................37
14.1.4 TDM e Bundle OK (Sem Evento de Alarme)..............................................................................37
14.2 TDM framed....................................................................................................................................... 38
14.2.1 Sinalização do Alarme Remoto (RALM).....................................................................................38
14.2.2 Perda de Sinal ou Alinhamento do Quadro (LOS ou LOF)........................................................39
14.2.3 Falha do Bundle Local (Perda de Conexão Ethernet)...............................................................39
14.2.4 Falha do Bundle Local (Perda Excessiva de Pacotes)..............................................................40
14.2.5 Sinalização de AIS..................................................................................................................... 41
14.2.6 Alarme de Packet Size............................................................................................................... 41
14.2.7 Alarmes de CAS e CRC............................................................................................................. 42
15 Coerências................................................................................................................................................. 42
16 Apêndice A: Configuração exemplo resumida........................................................................................... 44
16.1 Configuração do EDD_RX................................................................................................................. 45
16.2 Configuração do EDD_ADAP............................................................................................................ 46
17 Controle de Revisões................................................................................................................................. 48

1 Introdução ao Serviço de Emulação de Circuitos sobre
Pacotes (CESoP)
O Serviço de Emulação de Circuitos sobre Pacotes (do inglês Circuit Emulation Service over
Packets, ou CESoP), é uma tecnologia que permite a transmissão de serviços que utilizam Multiplexação
por Divisão de Tempo (Time Division Multiplexing, TDM) através de redes assíncronas, como as redes de
comutação de pacotes.
Com a evolução das redes de núcleo para redes de comutação de pacotes, como Metro Ethernet e
MPLS, o uso de CESoP é cada vez mais comum para manter a compatibilidade com a ampla base de
equipamentos já instalados que utilizam TDM. Um enlace com CESoP é constituído por três elementos:
TDM, Bundle e PW, que são apresentados a seguir.
1.1 TDM
TDM, que em português significa Multiplexação por Divisão de Tempo, utiliza-se do conceito de
alocação de espaços de tempo, chamados timeslots, para os sinais previamente amostrados. O TDM-PCM
ou Modulação por Código de Pulso é o método utilizado para representar digitalmente os sinais analógicos
amostrados. O sistema T1 é um TDM de 24 canais de voz usando PCM de 7 bits. O sistema E1 é um TDM
de 30 canais de voz e 2 canais para sincronismo e sinalização. Assim sendo, um quadro TDM de modo E1
contém 32 timeslots de 8 bits cada. A informação de sincronismo na TDM de modo E1 está presente no
primeiro timeslot do quadro (TS 0).
Na sinalização de linha por canal associado (CAS) são empregadas dois timeslots: o primeiro
timeslot (TS 0) para a informação de sincronismo do quadro, e o décimo sexto timeslot (TS 16) para a
sinalização. A perda de sincronismo de quadro é identificada após a recepção de palavras de sincronismo
incorretas. Isto desencadeia o processo de ressincronização e ativa o alarme de perda de sincronismo.
Na interface TDM do equipamento, configura-se o PCM que corresponda ao tipo de quadro

(com/sem sincronismo) e número de timeslots, além da sinalização CAS caso necessário.
1.2 Bundle
O bundle se refere à rede Ethernet, onde tem por finalidade a transmissão dos dados sobre a rede
IP/Ethernet. O bundle representa um mapeamento de uma interface TDM que será transmitido entre dois
equipamentos conectados por Pseudo-Wire.
1.3 Pseudo-Wire
O Pseudo-Wire (PW) permite que serviços legados, como TDM, sejam transportados por uma
conexão virtual ponto a ponto através de um mesmo circuito em redes IP/Ethernet até seu destino. A ideia
básica é a utilização de uma terceira camada na rede, sobre a qual uma operadora necessita transportar
serviços legados, incluindo ainda a camada 2 de serviços da rede.

2 Comandos Básicos do EDD
2.1 Login no Equipamento

O usuário e senha padrão é “admin” para ambos.
2.2 Configuração da Interface de Gerência

Para configurar o IP de gerência via interface MGMT ETH, deve executar os seguintes comandos:
# configure
(config)# interface mgmt-eth
(config-if-mgmt)# ip address 176.16.X.X/16
2.3 Atualização de Firmware

Na raiz do terminal (fora do modo de configuração) deve se usar o comando copy para atualizar a
imagem de FW de um servidor TFTP para o EDD.
# copy tftp [SERVER_IP] [IM_NAME] firmware
2.4 Aplicando a Configuração de Fábrica

Na raiz do terminal (fora do modo de configuração) deve se copiar a configuração default para a
configuração atual com o seguinte comando na raiz do terminal:
# copy default-config running-config
2.5 Salvando a Configuração Atual na Memória

Na interface CLI da linha Metro, as configurações são aplicadas no momento de execução do
comando, porém não são salvas na memória.
Para salvar a configuração na memória, inicialmente deve-se indicar qual será a posição utilizada
para armazenar configuração, para isto utiliza-se o seguinte comando na raiz do terminal:
# select startup-config 1
Para salvar a configuração aplicada na memória do equipamento, utiliza-se o seguinte comando:

# copy running-config startup-config
2.6 Visualizando a Configuração Atual

Para visualizar a configuração atual do switch, deve-se utilizar o comando:
# show running-config
2.7 Alterando o HostName

O rótulo apresentado no menu CLI é configurável e por padrão é utilizado “DmSwitch2104”. É
conveniente alterar este campo para facilitar a identificação do equipamento quando estiver sendo utilizada
a gerência remota do mesmo.

Para alterar o label, utiliza-se o seguinte comando no modo de configuração:
# configure
(config)# hostname EDD_20.124
3 Topologia exemplo
Para a realização dos exemplos neste documento será utilizada a topologia presente na figura 1.
Neste setup os dois switches são conectados através da porta LAN e para a gerência é utilizado um PC
rodando um cliente telnet.
Figura 1: Topologia usada nos exmplos
4 Diferenças do Modelo SERIES I para os Modelos SERIES II

e III
Abaixo são apresentadas as principais diferenças entre os modelos SERIES I e SERIES II/III, bem
como são destacadas algumas diferenças relacionadas a configuração CESoP.
4.1 Recursos
O EDD SERIES I possui suporte a configuração de uma interface TDM e bundle, na qual
disponibiliza uma unidade de E1 física no equipamento, além de uma unidade T1 caso possua suporte. Os
EDDs SERIES II e III possibilitam a configuração de mais interfaces TDMs e bundles, sendo que o mesmo
poderá ter suporte de até oito unidades de E1 físicas no equipamento, dependendo do modelo.
4.2 Comandos de configuração

Dentre as configurações CESoP disponíveis entre os modelos de equipamentos, alguns comandos
diferem, conforme demonstrado abaixo:
INTERFACE PW O EDD SERIES I não disponibiliza a “interface pw” devido as

configurações do pseudo-wire serem feitas através da
interface bundle.
Os EDDs SERIES II e III disponibilizam a “interface pw” sua

árvore de comandos, que reúne todos os comandos de
configuração do pseudo-wire. A partir do firmware 5.6, a
configuração “source-ip-address”, pode ser realizada na

interface bundle e a partir do firmware 5.10 a configuração
"vlan" também pode ser realizada diretamente na interface
bundle.
Os comandos pertencentes a esta interface são abordados

na sequência.
No EDD SERIES I esta configuração pode ser feita a partir

da própria interface bundle. No caso dos EDDs SERIES II e
SOURCE IP ADDRESS
III, este IP de origem deve ser configurado na interface PW,
devido ao modelo suportar a configuração de mais bundles.
A configuração da vlan para o tráfego CESoP também segue

o mesmo critério da anterior. No EDD SERIES I a
configuração é feita na própria interface bundle, enquanto
VLAN que nos EDDs SERIES II e III a vlan para tráfego CESoP
deve ser configurada na interface PW. A partir do firmware
5.6, nos EDDs SERIES II e III, a configuração da vlan pode
ser aplicada na interface pw ou na interface bundle.
O EDD SERIES I disponibiliza este comando para a

definição do tipo de dados a ser utilizado em substituição
aos pacotes perdidos. Os valores suportados pelo comando
LOST PACKET FILL
são: “send-idle-byte” e “repeat-last-data”. Este último vem
configurado por default. Os EDDs SERIES II e III não
disponibilizam esta configuração.
Comando presente no EDD SERIES I (em sync-source

advanced) que possibilita estipular o filtro máximo utilizado,
o qual tem um ajuste automático mas saturado a este valor.
Os valores válidos são de 1 a 9, porém recomenda-se
MAX ETH FILTER
valores entre 2 e 6. Este comando somente estará apto
quando a fonte de relógio de transmissão estiver configurado
para bundle, do contrário deverá retornar um alarme. OS
EDDs SERIES II e III não disponibilizam esta configuração.
Comando disponível somente no EDD SERIES II modelos

DM2104 2GX+E1 e DmSwitch 2104G2 - EDD E1 (SERIES
EXTERNAL II), na qual permite configurar a referência de relógio externo
a ser usada na interface TDM. O comando de configuração é
sync-source transmit-clock-source external.
A partir da versão 5.6 do EDD SERIES II, o comando de

sync-source passou a suportar hierarquias, ao mesmo
SYNC-SOURCE tempo em que as interfaces TDMs receberam a
possibilidade de configurar um sync-source adaptativo,
independente do relógio do sistema.
4.3 Testes
Existem diferenças na disposição e nomenclatura dos comandos de testes existentes entre ambos
os modelos de equipamentos. Tais diferenças são apresentadas abaixo:

Este teste retorna o fluxo de dados para a sua origem, nos
sentidos TDM e Ethernet. No EDD SERIES I, este comando está
LDL
acessível a partir da interface bundle, enquanto nos EDDs
SERIES II e III o comando está presente na interface TDM.
A única diferença nos comandos para testes de BERT está

relacionada com a nomenclatura dos mesmos. Os comandos
BERT <TDM/ETH>
tdm_bert_2^9 e eth_bert_2^9 do EDD SERIES I equivalem aos
comandos bert-tdm-side e bert-psn-side dos EDDs SERIES II e III.
Este teste está disponível no EDD SERIES 1. O RTD consiste em

um teste que retorna o delay do link. Basicamente o teste se
RTD baseia em medir o tempo que o pacote leva para retornar a
origem, assim é possível saber a condição que o link se encontra.
O teste de RTD pode ser habilitado no sentido TDM e Ethernet.
5 Diferenças de Comandos entre Firmwares

Devido a algumas melhorias aplicadas sobre alguns comandos do CESoP, será demonstrado uma
tabela contendo o firmware e os comandos modificados:
• EDD SERIES I:
FWs anteriores ao 4.4 FW 4.4 em diante

show tdm <n> show interfaces tdm <n>
show bundle <n> show interfaces bundle <n>
• EDDs SERIES II e III:

show tdm <n> show interfaces tdm <n>
show bundle <n> show interfaces bundle <n>
show pw 1 show interfaces pw 1
• EDDs SERIES II e III:

sync-source ack-out-of-limits sync-source hierarchy <n> ack-out-of-limits
sync-source transmit-clock-source sync-source hierarchy <n> transmit-clock-source

6 Configuração do SETUP
Nesta seção serão apresentadas todas as configurações e comandos disponíveis para montar um
setup CESoP. Para demonstrar o uso de cada configuração, será utilizada a topologia de exemplo
apresentada anteriormente, ressaltando que estas configurações poderão se diferenciar de acordo com a
topologia utilizada.
Serão demonstradas as configurações para o EDD_RX, para o EDD_ADAP as configurações

deverão ser realizadas da mesma forma, porém utilizando alguns valores diferentes. Observar que na
topologia de exemplo, o EDD_ADAP possui apenas o endereço IP e a fonte do relógio distintos.
Antes de iniciar a configuração é necessário verificar se o equipamento está com o último FW e com
a configuração default. Para aplicar a configuração default:
6.1 Configuração da Gerência através da VLAN

Esta configuração não está envolvida na funcionalidade da feature CESoP, porém a partir da
configuração de uma VLAN de gerência será possível acessar e realizar as configurações via telnet, além
de gerenciar os dois equipamentos ao mesmo tempo.
Será necessário configurar uma VLAN exclusiva para o tráfego dos dados de gerência, onde para
nosso exemplo deverão estar presentes as portas ETH1 e ETH3 na VLAN 10. Segue configuração abaixo:
# configure
(config)# interface vlan 10
(config-if-vlan-10)# set-member tagged ethernet 1
(config-if-vlan-10)# set-member untagged ethernet 3
(config-if-vlan-10)# interface ethernet 3
(config-if-eth-1/3)# switchport native vlan 10
Após configurada a VLAN 10 é possível configurar o IP de gerência para o endereço indicado.

(config-if-vlan-10)# ip address 10.1.1.100/16
Deve-se proceder com a configuração da gerência do EDD_ADAP da mesma forma. Para testar a
conectividade entre os equipamentos pode-se executar um ping. Neste momento já é possível acessar o
EDD via telnet pela porta 3 do EDD_RX.
6.2 Configuração da Interface TDM

A interface TDM disponibiliza todas as configurações pertinentes às unidades de E1 físicas do
equipamento. Estas configurações permitem determinar o método para a representação digital dos sinais
analógicos e definir a impedância da conexão utilizada na unidade física com os demais equipamentos.
Para visualizar as configurações atuais da interface TDM utilize o comando de show:

# show interfaces tdm 1
TDM 1/1 Interface:
Configuration:
Enable: Enable
Impedance: 75 ohms

Line Type: Unframed
Sync Source: System
Test:
LDL: Disable
Antes de iniciar a configuração da interface TDM é necessário desabilitá-la (caso ela esteja
habilitada), para isto utiliza-se o comando:
(config)# interface tdm 1
(config-if-tdm-1/1)# shutdown
6.2.1 Configuração do Line Type

O Line Type determina qual o método a ser utilizado para representar digitalmente os sinais
analógicos amostrados, chamado de Modulação por Código de Pulso (PCM). A configuração do line type
deve corresponder ao tipo de quadro (com/sem sincronismo) e o número de timeslots, além da sinalização
CAS caso necessário. Existem as seguintes possibilidades de configuração para a interface TDM no modo
E1:
UNFRAMED Modo unframed 2,048 Mbits (G.703).
PCM31 Modo framed 31 time slots (G.704).
PCM31-CRC Modo framed 31 time slots com CRC (G.704).
PCM30-CAS Modo framed 30 time slots e sinalização CAS (G.704).
PCM30-CAS-CRC Modo framed 30 time slots e sinalização CAS com CRC (G.704).
Para o nosso teste será necessário o modo PCM30-CAS-CRC:

EDD SERIES I:
(config-if-tdm-1/1)# line-type e1 pcm30-cas-crc
EDDs SERIES II e III:
(config-if-tdm-1/1)# line-type pcm30-cas-crc
6.2.2 Configuração de Impedância da TDM

Disponível a partir do firmware 5.2, esta configuração permite selecionar a impedância da interface
TDM nas seguintes opções: 75 ohms e 120 ohms. Esta configuração deverá ser realizada em conformidade
com a impedância da conexão dos demais dispositivos, como centrais telefônicos PABX, aparelhos
telefônicos e geradores de tráfego TDM. Quando não configurado, o EDD assume a impedância padrão de
75 ohms.
Abaixo um exemplo de configuração da impedância:

(config-if-tdm-1/1)# impedance 75

6.2.3 Configuração de Sync Source
Disponível a partir do firmware 5.6, esta configuração permite selecionar a fonte de relógio para ser
utilizada na interface. São disponibilizadas duas opções: system e adaptive.
SYSTEM Equivalente aos firmwares anteriores, onde a interface utiliza o

relógio do sistema para as operações de TX. Esta é a opção
padrão.
ADAPTIVE Utiliza um relógio adaptativo, regenerado do bundle especificado.

É independente do relógio do sistema.
Abaixo um exemplo de configuração do sync source:

(config-if-tdm-1/1)# sync-source system
Caso seja necessário pode-se alterar os outros parâmetros, porém é recomendado usar os valores
default. Desta forma podemos habilitar a interface TDM.
(config-if-tdm-1/1)# no shutdown
Neste momento, o sinal de presença do TDM já deve ser percebido pelo equipamento remoto
conectado na E1.
6.3 Configuração da Interface PW

A interface PW é única no equipamento, e disponibiliza configurações globais referente a atribuição
do endereço IP à interface PW e o mapeamento da vlan para o tráfego TDM na rede Ethernet, além da
prioridade do tráfego.
Para visualizar as configurações atuais do PW usa-se o comando de show:

# show interfaces pw 1
PW 1/1 Interface:
Configuration:
Idle Byte: 0xFF
Source IP Address: 0.0.0.0
VLAN: 1
Priority: 0
Inner Tag: Disabled
6.3.1 Configuração do Endereço IP do PW

O endereço IP do PW deve ser de uma rede diferente do IP de gerência do EDD. Além do IP é
necessário especificar qual a VLAN o PW pertencerá. Para configurar o Source IP e VLAN ID do PW utiliza-
se os seguintes comandos:
EDD SERIES I:
(config)# interface pw 1
(config-if-pw-1/1)# source-ip-address 20.1.1.100
(config-if-pw-1/1)# interface vlan 20

(config-if-vlan-20)# set-member tagged pw
EDDs SERIES II e III:
(config)# interface pw 1
(config-if-pw-1/1)# source-ip-address 20.1.1.100
(config-if-pw-1/1)# vlan 20 priority 7
A partir do firmware 5.6, é possível configurar a atribuição de double-tag na interface PW através do

comando:
(config-if-pw-1/1)#vlan <vid> priority <prio> inner-tag <vid>
priority <prio>
Alternativamente, também a partir do firmware 5.6, o endereço IP de origem podem ser configurado
diretamente no bundle e a partir do firmware 5.10 a configuração de VLAN também por ser realizada no
bundle. Isto significa que cada bundle pode enviar o tráfego para uma VLAN distinta, ou ainda, se
necessário, compartilhar uma mesma VLAN com outros bundles. Para realizar as configurações anteriores
diretamente no bundle utiliza-se os seguintes comandos:
(config)# interface bundle 1
(config-if-bundle-1/1)#source-ip-address 20.1.1.100
(config-if-bundle-1/1)#vlan 20 priority 7
Se as configurações “source-ip-address” e “vlan” não estiverem no bundle elas deverão estar na

interface pw.
6.3.2 Configuração do Idle Byte

É possível configurar o valor do idle byte, utilizado quando não há dados a serem transmitidos para
o sentido E1. É válido qualquer valor em hexadecimal de 0x00 à 0xFF, sendo que o padrão é 0xFF.
Exemplo:
(config-if-pw-1/1)#idle-byte 0xFF
6.4 Configuração da Interface Bundle

A interface bundle agrega todas as configurações pertinentes à rede IP/Ethernet. Estas
configurações permitem determinar o intervalo e a quantidade de dados a serem transmitidos pela interface
bundle, a configuração dos dados de destino, o mapeamento para uma interface TDM, o tamanho do buffer
(jitter-buffer) para o armazenamento dos pacotes provenientes do bundle remoto e o limite de perda de
pacotes e o mapeamento do serviço DSCP. A partir do firmware 5.6, os EDDs SERIES II e III suportam a
configuração “source-ip-address” no bundle e a partir do firmware 5.10 também suportam a configuração
“vlan” diretamente na interface bundle.
Para visualizar as configurações atuais do bundle usa-se o comando de show:

# show interfaces bundle 1
Bundle 1/1 Interface:
Configuration:
Enable: Disabled
Name: Not set
Initial timeslot: 0

Number of timeslots: 32
Packet delay: 1.000 ms
Jitter-buffer: 10.000 ms
Jitter Buffer History:
Enable: Enabled
Interval: 1200 sec
Packet loss Threshold: 1.00 %
TDM Channel: 1
Lost Packet Fill: Repeat Last Data
R bit send RAI: Enabled
IP:
Destination Bundle: 1
Destination IP Address: 0.0.0.0
IP Next Hop: 0.0.0.0
Source IP Address: 0.0.0.0
VLAN: 1
Priority 7
DSCP: 0
Tests:
Ethernet Bert test: Disabled
TDM Bert test: Disabled
Loop test: Disabled
Details:
Min. Jitter Buffer: 2.000 ms
Max. Jitter Buffer: 62.000 ms
Packet Size: 306 bytes
Payload Size: 256 bytes
Packet rate: 1000 Pkts/s
Throughput: 2480000 bits/s
Da mesma forma que a interface TDM, para configurar a interface bundle é necessário que ela
esteja desabilitada. Para desabilitar a interface bundle utiliza-se o comando shutdown:
# configure
(config-if-bundle-1/1)# shutdown
Nota: O tráfego enviado pela interface bundle sobre a rede ethernet é encapsulado em pacotes que

utilizam o protocolo de transporte UDP. O número da porta de origem e destino do pacote é formado pelo
cálculo “49152” + “número da interface bundle”. Por exemplo, se a interface bundle 1 for utilizada, os
pacotes UDP relativos a esta interface terão como porta de origem e destino o número 49153.
6.4.1 Configuração do Número de Timeslots

A configuração de timeslots (TS) determina quantos TS TDM serão transmitidos no bundle. No lado
Ethernet, essa configuração implica na quantidade de dados transmitidos: cada timeslot representa 64kbits
de dados por bundle. Por exemplo: uma configuração de TDM unframed com 32 timeslots no bundle resulta
em uma utilização de banda de 2048kbit/s; dois bundles com essa mesma configuração resultam em uma
utilização de banda de 4096kbit/s.
Para configurar a quantidade de TS do bundle deve-se indicar primeiro o TS inicial e em seguida a

quantidade de TS. Os timeslots disponíveis variam de acordo com a configuração de line-type da interface
TDM:
• unframed: de 0 à 32
• framed sem CAS: de 1 à 31
• framed com CAS: de 1 à 30
Para o nosso exemplo o comando fica:

(config-if-bundle-1/1)# timeslots 1 30
6.4.2 Mapeamento da Interface TDM

Disponível a partir do firmware 5.0, esta configuração mapeia a interface bundle com uma interface
TDM, possibilitando a configuração de grooming, que é o mapeamento de vários bundles para a mesma
interface TDM, mas ocupando timeslots distintos. No nosso exemplo a interface bundle será mapeada com
a interface TDM 1 através do comando:
(config-if-bundle-1/1)# tdm-channel 1
6.4.3 Configuração do Packet Delay

O packet-delay determina o intervalo de transmissão entre cada pacote do bundle na interface
Ethernet. Isso implica diretamente no tamanho do pacote a ser transmitido, pois o tamanho é calculado
observando-se a quantidade de banda necessária para atender a configuração de timeslots e dividindo-a
pela quantidade de pacotes transmitidos em 1 segundo, que por sua vez é determinada pelo packet-delay.
Portanto, quanto maior a configuração do packet-delay, maior o tamanho do pacote. O cálculo para o
tamanho do pacote é o descrito abaixo, onde pd é valor de packet-delay e ts é quantidade de timeslots
configurado no bundle; CAS é diferente de zero apenas se o line-type utilizado estiver com CAS ativado,
nesse caso seu valor é um inteiro referente à ts/2 arredondado para cima; HDR é o tamanho do cabeçalho,
fixo em 50 bytes; e, caso esteja sendo utilizado, QINQ é 4 bytes:
pd
tampacote=(( )×ts)+ CAS+ HDR+QINQ
0.125
Na tabela abaixo é demonstrado alguns valores comuns de packet-delay e timeslot com os
respectivos tamanhos de pacote e aproveitamento:
Packet-Delay Timeslots Tamanho do Pacote (bytes) Aproveitamento do payload (%)

0,5 32 178 71,91
1 32 306 83,66

Packet-Delay Timeslots Tamanho do Pacote (bytes) Aproveitamento do payload (%)
2 32 562 91,10
2 30 (c/ CAS) 545 90,82
Esses valores podem ser conferidos logo após configurar o timeslot e packet-delay no bundle com o
comando:
(config-if-bundle-1/1)# timeslot 0 32
(config-if-bundle-1/1)# packet-delay 1
(config-if-bundle-1/1)# show interfaces bundle 1
[…]
Details:
É importante destacar que a quantidade de pacotes enviados por segundo influencia diretamente a
qualidade do relógio regenerado no bundle remoto: quanto maior a taxa de envio de pacotes, melhor a
regeneração do relógio. Os valores possíveis para configuração ficam entre 0,5ms e 8ms, com incremento
mínimo de 0,125ms. Com modo CAS o packet-delay é obrigatoriamente 2 ms. Para o nosso exemplo o
comando deve ser:
(config-if-bundle-1/1)# packet-delay 2.000
6.4.4 Configuração do Jitter Buffer

O jitter-buffer é uma FIFO que armazena os pacotes recebidos na interface Ethernet provenientes
do bundle remoto. O seu objetivo é absorver variações de jitter, naturais da rede Ethernet, e reordenação de
pacotes recebidos fora de ordem. A configuração de jitter-buffer determina a quantidade desejada de
pacotes no buffer antes de iniciar a primeira transmissão dos pacotes contidos nele para a interface TDM.
Quanto maior o jitter-buffer, mais delay é inserido na rede, portanto configurações com jitter-buffer maiores
que 50ms não são recomendadas para tráfego de dados de voz.
Os valores mínimos e máximos variam de acordo com o tamanho do pacote. Para visualizar qual é
a faixa de tamanhos possíveis para a configuração de packet-delay e timeslots atual, utilize o comando de
show do bundle:
(config-if-bundle-1/1)# show interfaces bundle 1
[…]
Details:

O valor do jitter-buffer é representado em ms e define qual é a metade do tamanho total do buffer. A

lógica do CESoP tentará manter a ocupação do jitter-buffer no valor definido, mas poderá variar entre 0 e o
dobro do valor configurado. Quando a ocupação do buffer é extrapolada em algum dos limites superior
(dobro do valor configurado) ou inferior (zero), será incrementado um erro de overflow ou underflow,
respectivamente.
Para o nosso exemplo o comando fica:

(config-if-bundle-1/1)# jitter-buffer 10
Experiências práticas demonstram que links de rádio normalmente requerem

altas configurações de jitter-buffer, o que pode degradar consideravelmente a
! qualidade da transmissão.
6.4.5 Adição das portas ETH na VLAN do Bundle

É necessário adicionar a(s) porta(s) ETH do switch por onde irá trafegar o fluxo PWE3 na VLAN
onde está o PW. Na topologia de exemplo o tráfego irá passar apenas entre a porta 1 e a porta PW, assim o
comando deve ser:
(config-if-vlan-20)# set-member tagged ethernet 1
6.4.6 Configuração do Endereço IP do Bundle

O endereço IP do bundle deve ser diferente do IP de gerência do EDD. Além do IP é necessário
especificar qual a VLAN o bundle irá pertencer. Nos EDDs SERIES II e III o IP é configurado na interface
pw, conforme seção 6.3.1. No EDD SERIES I utiliza-se os seguintes comandos:
(config-if-bundle-1/1)# source-ip-address 20.1.1.100
(config-if-bundle-1/1)# vlan 20 priority 7
A partir do firmware 5.6, nos EDDs SERIES II e III, a configuração “source-ip-address” pode ser
realizada diretamente no bundle. A partir do firmware 5.10 a configurção “vlan” também pode ser aplicada
diretamente na interface bundle. Isto significa que a partir do firmware 5.10 cada bundle pode enviar o
tráfego para uma VLAN distinta, ou ainda, se necessário, compartilhar uma mesma VLAN com outros
bundles.
Nos EDDs SERIES II e III, quando a configuração “vlan” ou “source-ip-address” não estiverem no
bundle, elas deverão estar na interface pw as quais atuarão de forma global para todas as interfaces
bundle que não tiverem essas configurações.
6.4.7 Configuração dos Dados de Destino do Bundle

Existem três informações que determinam o destino do bundle:
• ip-next-hop: gateway para acessar bundles em outras redes (pode ser o o próprio ip de destino
quando não for necessário realizar saltos);

• destination-ip-adress: IP da PW do bundle de destino;
• destination-bundle: a qual bundle será associado no destino.
Para nosso exemplo, o comando de configuração fica:

(config-if-bundle-1/1)# ip-next-hop 20.1.1.101
(config-if-bundle-1/1)# destination-ip-address 20.1.1.101
(config-if-bundle-1/1)# destination-bundle 1
6.4.8 Configurando o Limite de Perda de Pacotes

O limite de perda de pacotes padrão é de 1% sobre o total esperado por segundo no bundle.
Quando a perda de pacotes for superior ao limite definido, o bundle entrá no estado de falha e um log é
gerado. O comando de configuração do limite de perda de pacotes para o exemplo é o que segue:
(config-if-bundle-1/1)# packet-loss-threshold 1
6.4.9 Atribuindo um Nome à Interface Bundle

Para atribuir um nome à interface bundle, usa-se o comando abaixo:
(config-if-bundle-1/1)# circuit-name NOME_BUNDLE
6.4.10 Configurando o DSCP

Permite mapear o DSCP ao pacote CESoP, com o seguinte comando:
(config-if-bundle-1/1)# dscp 0
6.4.11 Configuração de preenchimento de pacotes perdidos

O comando de lost-pkt-fill permite a configuração de como serão preenchidos os dados E1 quando
pacotes do bundle forem perdidos. Existem 3 opções para este comando:
AUTOMATIC É a mistura das duas outras opções, onde inicialmente é repetido

o último dado válido por alguns segundos até que passe a
transmitir o idle-byte.
IDLE-BYTE Preenche os dados com idle-byte, conforme configurado na

interface PW.
REPEAT-LAST-DATA Preenche os dados repetindo o último pacote com dados válidos

recebido no bundle. Esta é a opção padrão.
(config-if-bundle-1/1)# lost-pkt-fill repeat-last-data

6.4.12 Configuração de R-Bit-Send-RAI
Ao ativar esta opção, a sinalização de Remote Alarm Indication (RAI) recebida na interface TDM
local associada ao bundle será transmitida pela interface Ethernet para o Bundle remoto. Esta
funcionalidade é habilitada pelo comando:
(config-if-bundle-1/1)#r-bit-send-rai
6.4.13 Configurando a fonte de Relógio

É essencial a configuração adequada do relógio para o funcionamento correto do bundle. Uma má
configuração irá gerar problemas que não serão vistos imediatamente, mas que possuem um
comportamento característico, conforme descrito no capítulo 13. Portanto, recomenda-se bastante atenção
nesta seção.
O EDD possui apenas uma fonte de relógio para o sistema, que, a partir do firmware 5.6, pode ser
hierarquizada entre fontes diferentes com até seis hierarquias. Também nesta versão, foi adicionada a
capacidade de trabalhar com fontes de relógio independentes por interface TDM.
O relógio do sistema determina a frequência com que os pacotes serão transmitidos e recebidos em
ambos os sentidos (TDM e Ethernet). Esse comportamento é diferente das versões anteriores, onde a
frequência dos pacotes recebidos na interface TDM sempre determinava a frequência de envio pela
interface Ethernet. Com isso, são introduzidos novos comportamentos em casos de erro que não eram
observados anteriormente. Estes novos comportamentos estão descritos no capítulo 13.
A partir da versão 5.6 foi adicionado o suporte a relógios independentes por bundle. Com esse
suporte é possível realizar o transporte de dados e voz pelo EDD de maneira transparente, utilizando no TX
TDM o mesmo relógio que é recebido no RX Ethernet. A transmissão no sentido RX TDM para TX Ethernet
ficará transparente quando utilizando relógios independentes, do contrário, será utilizando o relógio do
sistema conforme descrito no parágrafo anterior.
Como pode ser visto na figura 2, o EDD está sujeito a pelo menos quatro fontes de relógio
diferentes. O relógio ftdmL é a frequência recebida pela interface TDM e que pode ser utilizada pelo TX do
bundle caso seja configurado dessa maneira; o relógio ftdmR é a frequência recebida pelo RX do bundle local,
sendo referente ao relógio enviado pelo bundle remoto; o relógio flocal é a frequência do sistema, determinada
pela fonte de relógio configurada no EDD; por fim, fline é o relógio adaptativo recuperado do bundle. É este
último relógio que permite a utilização de fontes independentes, pois cada bundle possui seu próprio bloco
ACR.

Figura 2: Sistema de relógios no EDD
Ao configurar a fonte de relógio do sistema, está se configurando o flocal. A figura 3 ilustra essa
seleção. As configurações de fonte de relógio do sistema no EDD são:
• Interno: o próprio EDD é a fonte de relógio;
• Regenerado de uma interface TDM: o relógio recebido na interface TDM especificada é

utilizado como fonte para o EDD;
• Regenerado de um bundle (adaptive): o relógio recebido pelo bundle especificado é utilizado

como fonte para o EDD. O relógio poderá ser ajustado com aproximadamente ± 100 ppm de
diferença;
• Regenerado de uma fonte externa (EDDsII apenas): o relógio recebido por uma fonte externa,
conectada ao EDD, é utilizado como fonte.
Figura 3: Seleção de uma das opções de fonte de relógio (flocal)
Para o EDD_RX utiliza-se a opção TDM 1:

(config)# sync-source hierarchy 1 transmit-clock-source tdm 1
Para o EDD_ADAP a opção é bundle 1:

(config)# sync-source hierarchy 1 transmit-clock-source adaptive
bundle 1
Neste caso, a fonte de sincronismo configurada será uma referência global para as interfaces TDM.
Alternativamente, a partir do firmware 5.6, o clock de sincronismo do EDD_ADAP poderia ser

configurado diretamente na interface TDM para utilizar o bundle como fonte de sincronismo adaptativa:
(config)interface tdm 1
(config-if-tdm-1/1)#sync-source adaptive bundle 1
Neste caso, a fonte de sincronismo configurada será usada apenas pela interface TDM onde o
comando é aplicado. Na configuração padrão, as interfaces TDM utilizam as hierarquias de sincronismo
globais do sistema.
6.4.14 Habilitação do Bundle

Após realizar estas configurações deve-se habilitar o bundle com o comando no shutdown.
(config-if-bundle-1/1)# no shutdown
7 Verificação Status das Interfaces

O EDD disponibiliza os status das interfaces Bundle e TDM para depuração de problemas.
7.1 Status da Interface TDM

Para verificar o status da interface TDM utiliza-se o seguinte comando:
#show interfaces status tdm 1
TDM 1/1 - Status Information:
Link Status: Ok
Remote Alarm: Ok
CAS status: Ok
CRC status: Ok
7.1.1 TDM Status: Link Status

Este campo informa o status do link g704 e pode ter os seguintes valores:
OK O link não apresenta nenhuma falha.
LOS O link apresenta a falha LOS – Loss of Signal. Esta falha indica que não há
nenhum sinal chegando do dispositivo E1 adjacente, nenhuma máscara de
tensão de E1 válida, ou nenhuma alteração da tensão entre as amplitudes
positivas e negativas. Recomendação: Verifique a camada física
(conectores, cabos, etc) para a solução deste problema. Consultar as
seções 14.1.1 e 14.2.2 para maiores detalhes sobre o cenário e a condição

de alarme.
O link apresenta a falha LOF – Loss of Frame (não disponível no modo

unframed). A perda de quadros indica que o dispositivo E1 perdeu a
sincronia com o dispositivo adjacente.
Em maiores detalhes, esta falha corresponde a determinado período na qual
os erros de quadros persistiram sem a detecção do erro de AIS. O erro do
LOF
quadro é declarado quando três sinais de alinhamento de quadro
consecutivos foram recebidos com um erro.
Recomendação: Verifique todos os parâmetros de enquadramento
relacionados ao E1 e conexões físicas. Consultar a seção 14.2.2 para
maiores detalhes sobre o cenário e a condição de alarme.
O link apresenta a falha AIS – Alarm Indication Signal. O sinal de indicação

de alarme se refere a um sinal transmitido em substituição ao sinal normal
para indicar ao dispositivo E1 adjacente que há falha no fluxo de
AIS
transmissão. Recomendação: Verique as causas pelas quais o dispositivo
esteja enviando o sinal AIS. Consultar a seção 14.2.5 para maiores detalhes
sobre o cenário e a condição de alarme.
7.1.2 TDM Status: Remote Alarm

Este campo informa o status do alarme RALM do link g704 e pode apresentar os seguintes valores:
NO ALARM O link não apresenta alarme RALM – Remote Alarm.
O link apresenta alarme RALM – Remote Alarm. Um indicador de alarme

remoto é enviada por um dispositivo quando ele perder a sincronia com o
dispositivo E1 adjacente. Em outras palavras, o dispositivo envia o RALM
para o E1 adjacente quando entrar no estado LOF por exemplo.
ALARM
Recomendações: Verifique o motivo do dispositivo E1 estar no estado LOF
(fora de sincronia), verificando a integridade das conexões físicas e os
parâmetros de enquadramento relacionados. Consultar a seção 14.2.1 para
maiores detalhes sobre o cenário e a condição de alarme.
“-“ O status de alarme não se aplica para a configuração atual
7.1.3 TDM Status: CAS Status

Este campo apresenta o status do alinhamento da sinalização CAS do E1, pode assumir os
seguintes valores:
OK O link está com o alinhamento de CAS sem falhas.
LOM Loss of Multiframe. O link está com falha no alinhamento CAS. A perda de
multiquadros indica o período sem sincronização no modo de multiquadro.
Recomendações: Verifique a integridade da conexão física, método de
sinalização (habilitado) e parâmetros de enquadramento relacionados.

Consultar a seção 14.2.7 para maiores detalhes sobre o cenário e a
condição de alarme.
“-“ Não se aplica o alarme para a configuração atual.
7.1.4 TDM Status: CRC Status

Este campo apresenta o status do alinhamento do multiframe CRC do E1, pode assumir os
seguintes valores:
OK O link está com o alinhamento de CRC sem falhas.
O link está com falha no alinhamento CRC. A falha do alinhamento CRC

ocorre quando o cálculo do checksum realizada antes da transmissão não
coincide com o cálculo do checksum realizada pelo dispositivo E1 adjacente,
FAIL no momento da recepção. Recomendações: Verifique a integridade da
conexão física, método de CRC (habilitado) e parâmetros de enquadramento
relacionados. Consultar a seção 14.2.7 para maiores detalhes sobre o
cenário e a condição de alarme.
“-“ Não se aplica o alarme para a configuração atual.
7.2 Status da Interface Bundle

Para verificar o status da interface Bundle utiliza-se o seguinte comando:
#show interfaces status bundle 1
Bundle 1/1 - Status Information:
Bundle Name:
Local Bundle: Ok
Remote Bundle: Ok
TDM Local: Ok
TDM Remote: Ok
Packet size: Ok
Next-Hop: Ok
MAC: 00:00:00:00:00:0A
7.2.1 Bundle Status: Local Bundle

Este alarme indica que o bundle local está com perda de pacotes superior ao limite configurado. O
percentual default para o limite de perda de pacotes é de 1%. Recomendações: Verificar a integridade da
conexão física e parâmetros de configuração relacionados (packet-delay e jitter-buffer). Caso contrário, o
limite de perda de pacotes poderá ser alterado através do comando packet-loss-threshold na interface
bundle.

7.2.2 Bundle Status: Remote Bundle
Este item indica que o bundle remoto está alarmando perda de pacotes superior ao limite
configurado. Recomendações: Verificar a integridade da conexão física no equipamento remoto, e
parâmetros de configuração relacionados (packet-delay e jitter-buffer) do bundle remoto. Caso contrário, o
limite de perda de pacotes poderá ser alterado através do comando packet-loss-threshold na interface
bundle do equipamento remoto.
7.2.3 Bundle Status: TDM Local

Este alarme indica que o link TDM no qual o bundle está mapeado apresenta alguma falha.
Recomendação: Verifique todos os parâmetros de enquadramento relacionados ao E1 e conexões físicas.
7.2.4 Bundle Status: TDM Remoto

Este alarme indica que o link TDM no qual o bundle remoto está mapeado apresenta alguma falha.
Recomendação: Verifique todos os parâmetros de enquadramento relacionados ao E1 e conexões físicas
do equipmento remoto.
7.2.5 TDM Status: Packet Size

Este alarme indica que o bundle local está recebendo pacotes com tamanho diferente do
configurado. Normalmente esse alarme sinaliza uma divergência na configuração de timeslots e/ou packet-
delay entre o bundle local e o bundle remoto. Recomendações: Verifique a coerência da configuração dos
parâmetros relacionados (timeslot e packet-delay) entre o bundle local e o bundle remoto.
7.2.6 TDM Status: Next-Hop

Este alarme indica que não é possível acessar o endereço IP Next Hop configurado no bundle.
Recomendação: Verifique o parâmetro de configuração e alcance do endereço IP configurado.
8 Habilitação Testes TDM

Os EDDs disponibilizam os testes de BERT no sentido TDM como também no sentido ETH. O
EDD SERIES I disponibiliza o teste de LDL na interface bundle, enquanto os EDDs SERIES II e III
disponibilizam o mesmo na interface TDM.
8.1 Teste de BERT TDM/ETH

O teste de BERT consiste na transmissão de uma sequência de dados conhecida e a verificação da
recepção correta desta sequência pelo equipamento receptor.
Baseado nos testes de BERT será possível identificar erros no fluxo de dados entre dois pontos,
seja no sentido TDM ou no sentido ETH. Para a realização do teste, basta habilitá-lo na interface bundle do
equipamento, e acompanhar o status do teste através de um comando show que será demonstrado
adiante.
Alternativamente, poderá existir um caminho de retorno (loop) para o fluxo de dados TDM,
permitindo o uso de um gerador de BERT, como exemplo o DM704.
Não será possível habilitar dois testes simultâneos na mesma interface, sendo necessário
desabilitar o teste em execução para então habilitar quaisquer outros testes.

8.1.1 Habilitando o Teste de BERT TDM/ETH
Para habilitar o teste de BERT utiliza-se o seguinte comando (o exemplo é para o teste TDM, porém
aplica-se para o caso do ETH apenas mudando TDM para ETH):
EDD SERIES I
(config-if-bundle-1/1)# test tdm_bert_2^9
EDDs SERIES II e III
(config-if-bundle-1/1)# test bert-tdm-side
8.1.2 Inserindo um Erro no Teste de BERT

Para inserir um erro no teste de BERT que está rodando basta executar o seguinte comando:
(config-if-bundle-1/1)# test bert-error
8.2 Teste LDL na interface Bundle

O teste de LDL na interface bundle retorna o fluxo de dados para a sua origem, tanto no sentido
TDM, quando no sentido ETH.
8.2.1 Habilitando o Teste de LDL

Para habilitar o teste de LDL:
EDD SERIES I

(config-if-bundle-1/1)# test ldl
EDDs SERIES II e III

(config-if-tdm-1/1)# test ldl
8.3 Verificando o Status dos Testes

Para verificar o status dos testes do bundle utiliza-se o comando show:
#show interfaces test bundle 1
Information of Bundle Interface 1/1
Ethernet Bert test: Disabled
TDM Bert test: Enabled
Error time(sec): 0
Total time(sec): 15
LDL test: Disabled

A partir do retorno do comando é possível visualizar o teste habilitado, e para os testes de BERT
são exibidos o tempo transcorrido e número de segundos com erro.
9 Análise dos Contadores do Bundle

O EDD disponibiliza alguns contadores para depuração da interface bundle. Utiliza-se o comando
show para visualizar os contadores do bundle:
#show interfaces counters bundle 1
Bundle Interface Counters:
Buffer overflow: 0
Buffer underflow: 0
Lost packets: 0
Lost packets rate: 0 pkts/s
Out of order packets: 0
Sequence number violation: 0
Wrong size packets: 0
Jitter Buffer Occupation: 20.000 ms
9.1.1 Contador Bundle: Overflow

Este contador indica quantos eventos de overflow ocorreram no jitter-buffer da interface bundle
respectiva. Um overflow ocorre quando a ocupação do jitter-buffer chega ao dobro do que foi configurado
para o bundle. Ao ocorrer um overflow irá ocorrer também um underflow, causado pelo descarte de todos os
pacotes que estavam no buffer, a fim de esvaziá-lo para que volte ao estado ideal. Portanto, um incremento
de overflow é acompanhado de um incremento de underflow e lost packets. Após um overflow a transmissão
do jitter-buffer para a interface TDM é interrompida enquanto não houver pacotes bufferizados suficientes
para atingir o nível determinado pela configuração de jitter-buffer no bundle.
9.1.2 Contador Bundle: Underflow

Este contador indica quantos eventos de underflow ocorreram no jitter-buffer da interface bundle
respectiva. Um underflow ocorre quando a ocupação do jitter-buffer chega a zero. Na ocorrência do
underflow também poderá haver o descarte de pacotes devido a necessidade da readaptação ao novo
número de sequência. Portanto, um incremento de underflow é acompanhado de incrementos do lost
packets. Da mesma forma que o overflow, após um underflow a transmissão do jitter-buffer para a interface
TDM é interrompida até que ele seja preenchido novamente com o nível determinado pela configuração de
jitter-buffer no bundle.
9.1.3 Contador Bundle: Lost Packets

Este contador é incrementado sempre que, ao remover um pacote do jitter-buffer para transmissão
na interface E1, for detectado que o número de sequência é maior que o esperado, mas ainda dentro da
capacidade de reordenamento do jitter-buffer. Nesse caso serão contabilizados como perdidos os pacotes
resultantes da diferença entre o número de sequência recebido e o esperado. O contador também irá
incrementar em uma unidade quando o pacote a ser transmitido está marcado como inválido por conter um
erro de CRC ou por estar com um número de sequência menor do que o esperado ou fora do intervalo de
reordenação.

9.1.4 Contador Bundle: Out of Order Packets
O contador de Out of Order é incrementado sempre que chegar um pacote para ser inserido no
jitter-buffer com um número de sequência diferente do esperado, mas dentro de uma faixa em que é
possível reordená-lo dentro do jitter-buffer. Por exemplo, se o jitter-buffer está configurado de maneira a
comportar 10 pacotes e o número de sequência esperado é 15, serão tratados como Out of Order pacotes
que cheguem com um número de sequência diferente de 15, mas entre 20(+5) e 10(-5). Da mesma
maneira, se o jitter-buffer está configurado de maneira a comportar 20 pacotes e o número de sequência
esperado for o mesmo 15 do exemplo anterior, serão tratados como Out of Order pacotes que cheguem
com um número de sequência diferente de 15, mas entre 25(+10) e 5(-10).
Esse contador por si só não determina uma condição de erro, pois seu incremento significa que o
pacote foi tratado com sucesso. Porém ele indica que a rede está ocasionando pacotes fora de ordem e em
algum momento poderá ocorrer o Lost Packet como também o Sequence Number Violation.
O contador Lost Packet será incrementado caso o pacote atrasado não chegue até o momento de
sua leitura no jitter-buffer. Por exemplo, se o jitter-buffer está configurado para comportar 10 pacotes,
significa que o ponteiro de leitura do jitter-buffer estará 10 posições atrás, assim sendo o pacote atrasado
tem o tempo de 10 ms (10 pacotes) para chegar, ser reordenado e lido corretamente. Caso o pacote
atrasado não chegue neste período de tempo, ocorre então o incremento do Lost Packet. Além disso, se o
pacote atrasado chegar após este tempo, ocorre então o incremento do Sequence Number Violation.
9.1.5 Contador Bundle: Sequence Number Violations

Este contador indica quantos pacotes CESoP corretamente endereçados foram recebidos pela
interface bundle com um número de sequência que excede a capacidade de absorção do jitter-buffer. Ao
contrário do Out of Order, os pacotes com Sequence Number Violations não podem ser tratados e portanto
serão marcados para descarte, gerando também um Lost Packet.
9.1.6 Contador Bundle: Wrong Size Packets

Este contador indica quantos pacotes CESoP corretamente endereçados foram recebidos pela
interface bundle com um tamanho diferente do configurado para o bundle. Um pacote com tamanho errado
será marcado para descarte e portanto também irá gerar um Lost Packet.
10 Análise dos Contadores da PW

O EDD disponibiliza alguns contadores para depuração da interface PW. Utiliza-se o comando show
para visualizar os contadores da interface PW:
#show interfaces counters pw 1
PW 1/1
Internal PW stats:
Packets input : 0
Discard input : 0
Bundles reached packets : 0
Octets input : 0
Octets output : 0
Unicast input : 0

Unicast output : 0
Discard input : 0
Discard output : 0
Error input : 0
Error output : 0
Unknown protos input : 0
QLen : 0
Abaixo são detalhados os contadores e sua finalidade:
Packets Este contador indica o número TOTAL de pacotes de entrada recebidos pelo
Input equipamento.
Discard Este contador indica o número TOTAL de pacotes de entrada descartados

Input pelo equipamento.
Bundle Este contador indica o número TOTAL de pacotes encaminhados para o

Reached bundle do equipamento.
Packets
Octets Este contador indica o número de bytes recebidos com sucesso na interface
Input PW.
Octets Este contador indica o número de bytes transmitidos com sucesso pela
Output interface PW.
Unicast Este contador indica o número de pacotes entregues a camadas superiores

Input e que não estavam endereçados para multicast ou broadcast.
Este contador indica o número de pacotes solicitados por camadas

Unicast superiores, para serem transmitidos pela interface PW, que não foram
Output endereçados para multicast ou broadcast, incluindo pacotes descartados e
não enviados.
Este contador indica o número de pacotes de entrada que foram

descartados, para prevenir que os mesmos fossem entregues para
Discard
protocolos em camadas superiores. Pacotes descartados não
Input
necessariamente contém erros, podem ter sido eliminados para liberar
espaço no buffer.
Este contador indica o número de pacotes de saída que foram descartados,

Discard para prevenir que os mesmos fossem transmitidos através da interface PW.
Output Pacotes descartados não necessariamente contém erros, podem ter sido
eliminados para liberar espaço no buffer.
Este contador indica o número de pacotes de entrada que não puderam ser
Error Input
entregues a protocolos de camadas superiores por conter erros.
Error Este contador indica o número de pacotes de saída que não puderam ser
Output transmitidos através da interface PW por conter erros.

Unknown Este contador indica o número de pacotes de entrada que foram recebidos
Protos pela interface PW e descartados por apresentarem um protocolo
Input desconhecido ou não suportado pelo equipamento.
Este contador indica o número de pacotes de saída que se encontram na fila

QLen
esperando a transmissão pela interface PW.
11 Teoria de Operação da PW
A seguir é demonstrado um exemplo de ocupação do jitter-buffer, além de ilustrar as situações em
que ocorrem os erros de buffer overflow e underflow. A configuração utilizada no exemplo é de 1ms para
packet-delay e 10ms de jitter-buffer (JB_SIZE).
Em operação normal, o jitter-buffer poderá receber um pacote 10 ms adiantado ou atrasado sem

ocorrer a perda do pacote, uma vez que o ponteiro de leitura inicia JB_SIZE posições anteriores ao ponteiro
de escrita, conforme ilustrado na figura 4, estando 10 posições atrás.
Figura 4: Exemplo de ocupação do jitter-buffer
Abaixo é demonstrada a operação da leitura e escrita dos pacotes no jitter-buffer, destacando o

incremento dos contadores equivalentes:
• Supondo que o equipamento recebeu um pacote com o numero de sequência sendo 998, ao
receber a sequência 999 será incrementado o contador de pacotes ordenados em 1;
• Seguindo a operação, supondo que o pacote 1000 não chegue. Quando ocorrer a chegada do
1001, o contador de pacotes fora de ordem ("Out of order packets") é incrementado em 1. O
próximo pacote esperado passa a ser o 1002 e, ao chegar, o contador de pacotes em ordem é
incrementado;

Figura 5: Diagrama de pacote não recebido no tempo esperado
A partir deste momento, poderá ocorrer duas operações distintas mediante o recebimento de
pacotes fora de ordem:
1) Seguindo a operação, quando chegar o pacote 1011, o ponteiro de leitura vai estar apontando
para o sequence number 999 ou 1000, sendo 10 posições atrás da posição de escrita. O pacote
atrasado tem o tempo de 10 ms (10 pacotes) para chegar. Caso não tenha chegado até o
momento da leitura, o mesmo será substituído e o contador Lost packets incrementado. Caso o
sequence number 1000 chegue após o tempo de 10 milisegundos, o contador de Sequence
number violation é incrementado devido o pacote chegar fora de ordem e com a diferença além do
que o jitter-buffer suporta. Neste caso, aumentar o jitter-buffer poderá eliminar ou reduzir o
problema;
Abaixo a demonstração em diagrama:
Figura 6: Diagrama de pacote fora da faixa
• As linhas Max e Min S/N allowed mostram a evolução da faixa de reordenamento conforme os
pacotes são recebidos;
• O packet-delay é de 1 milisegundo, o tempo de 14,5 ms demonstra que o pacote não chegou

com o fluxo normal, e poderia chegar em qualquer tempo ente 14 e 15 milisegundos.
2) Agora supondo que o pacote 1000 chegue logo após o sequence number 1005, o ponteiro de
leitura vai estar na posição 995 ou 996. No momento em que chegar o sequence number 1000,

será incrementado o contador Out of order packets. Nesse caso, não deve ocorrer erro na
passagem de dados devido o pacote chegar no tempo suportado pelo jitter-buffer, mesmo estando
fora de ordem.
A figura 7 contém a demonstração em diagrama:
Figura 7: Diagrama de pacote fora de ordem
• O incremento do contador Out of order packets é realizado na ocorrência de saltos de sequence

number. Para a demonstração acima, o contador será incrementado 2 vezes devido a ocorrência
de saltos de sequence number do 999 para o 1001, e do 1005 para o 1000;
• O próximo pacote esperado equivale a sequência do maior número recebido. Caso o sequence
number 1001 chegar após o 999, o próximo pacote esperado passa a ser o 1002, porém caso o
sequence number 1000 chegar após o 1005, o próximo pacote esperado permanece sendo o
sequence number 1006;
• As linhas Max e Min S/N allowed mostram a evolução da faixa de reordenamento conforme os
pacotes são recebidos;
• O packet-delay é de 1 milisegundo, o tempo de 7,5 ms demonstra que o pacote não chegou com
o fluxo normal, e poderia chegar em qualquer tempo ente 7 e 8 milisegundos.
Os contadores de overflow e underflow são casos à parte e devem causar em torno de 15 loss
packets na configuração de exemplo, sendo 5 para realinhar o sequence number esperado e 10 para
preencher o jitter-buffer antes de liberar a leitura.
12 Monitor do Jitter-Buffer History

A partir do firmware 5.2, foi adicionado um monitor que mantém em log as últimas informações
relacionadas a variação do jitter-buffer.
12.1 Configuração do intervalo de leitura do jitter-buffer

A feature Jitter-Buffer History disponibiliza a configuração do intervalo de leitura do jitter-buffer. O
intervalo configurável compreende entre 10 e 21.600 segundos, sendo permitido o intervalo máximo de 6
horas. Esta configuração é opcional. Não possuindo a configuração de intervalo, o monitor do jitter-buffer
history assume o intervalo default de 20 minutos (1.200 segundos) .
A configuração deve ser realizada na interface bundle, conforme demonstrado abaixo:

(config-if-bundle-1/1)#jitter-buffer-history interval 1200
12.2 Visualização do log do Jitter-Buffer History

Utiliza-se o comando show para visualizar o log gerado pelo monitor do jitter-buffer history. A partir
do resultado poderá ser observado a existência de variação do jitter-buffer, para um determinado período de
tempo.
#show interfaces counters bundle 1 jitter-buffer-history
Bundle 1/1 jitter-buffer history:
Name: Not set
JB (ms) |------------------------ |
014 | * |
|------------------------ |
012 | ++*+**** +******+*** |
|------------------------ |
010 | *+ |
|------------------------ |
| |
Date: 01/01/09 00:34:38 01/01/09 00:55:38
Os caracteres “*” e “+” que representam cada período de tempo em que ocorreu a leitura do jitter-
buffer. O caracter “*” demonstra que no respectivo período de tempo não houveram ocorrências de variação
do jitter-buffer, e o caracter “+” aponta a existência de variação do jitter-buffer durante o respectivo período
de tempo.
Também é possível visualizar o log completo, para isto basta acrescentar o argumento “ detail” ao
final do comando show, conforme abaixo:
#show interfaces counters bundle 1 jitter-buffer-history detail
Bundle 1/1 jitter-buffer history:
Name: Not set
Time Jitter-buffer Variation Overflow Underflow
-------------------------------------------------------------------
01/01/09 00:34:38 010 000 000 001
01/01/09 00:35:38 010 001 000 000
01/01/09 00:36:38 010 005 000 000
01/01/09 00:37:38 012 001 000 000
01/01/09 00:38:38 012 000 000 000
01/01/09 00:39:38 012 002 000 000
01/01/09 00:40:38 012 000 000 000
01/01/09 00:41:38 012 000 000 000
01/01/09 00:42:38 012 000 000 000

01/01/09 00:43:38 012 000 000 000
01/01/09 00:44:38 014 000 000 000
01/01/09 00:45:38 012 004 000 000
01/01/09 00:46:38 012 000 000 000
<...>
A partir deste resultado será possível obter maiores informações relacionados ao histórico de leitura
do jitter-buffer, que são: data e hora de leitura, ocupação do jitter-buffer, número de ocorrências de variação
do jitter-buffer durante o período, e o número de ocorrências de overflow e underflow.
13 Troubleshooting
Ao detectar-se problemas na operação do bundle, existem diversos indicadores que podem
direcionar a solução do problema. A primeira medida a fazer quando o bundle apresenta problemas é limpar
os contadores de ambos EDDs, local e remoto, com o comando:
# clear interface counters
E então monitorar o comportamento de cada campo. A seguir serão descritos comportamentos

comuns, possíveis causas e soluções.
Nota: A seção de Troubleshooting aplica-se plenamente apenas a versões de firmware anteriores a 5.6.
13.1 Incremento de Wrong Size Packet em ambos os lados

O incremento de Wrong Size Packet em ambos os EDDs, local e remoto, é uma situação comum
quando existe diferença de configuração de packet-delay e/ou timeslots entre os EDDs. Nestes casos, o
status do bundle também deve apontar Packet size: Mismatch.
Resolução: Certifique-se de que os valores de packet-delay e timeslots são os mesmos em ambos

EDDs.
13.2 Jitter Buffer cai/sobe regularmente até causar Underflow/Overflow

Uma variação regular do jitter-buffer em apenas um sentido até causar underflow ou underflow
repetitivamente é um grande indicativo de que há uma falta de sincronismo entre os relógios dos
equipamentos envolvidos. A resolução deste problema pode requerer uma série de etapas e envolver
diferentes cenários, que são descritos a seguir:
13.2.1 Procedimento padrão

Os itens abaixo são a primeira etapa para todos os cenários:
1) Certifique-se de que todos os cabos ligados à interfaces TDM dos EDDs que não estejam em
uso estão com loop físico. Cabos E1 sem conexões e em contato com superfícies metálicas
podem gerar ruídos que interferem no relógio do EDD. Caso essa ação não seja suficiente,
prossiga com o item 2.
2) Certifique-se de que todos os equipamentos envolvidos possuem apenas uma fonte de relógio,
que deve ser a mesma para todos. Apenas um equipamento pode ser o gerador do relógio e os
outros devem regenerar dele ou de quem já regenera dele. Se depois de verificar que a
regeneração do relógio está correta em todos os equipamentos e o problema continuar, prossiga
com os precedimentos específicos para cada cenário. Caso não tenha descrição específica para o

cenário do problema, entre em contato com o suporte técnico.
13.2.2 Equipamentos ligados ponto-a-ponto, com apenas um Bundle
EDD Bundle 1 EDD

TDM1 TDM1
Figura 8: Topologia ponto-a-ponto com um bundle
Neste cenário não é comum haver problemas de sincronismo de relógio quando a configuração dos
equipamentos está correta. Um problema de relógio só pode ser inserido caso os dados recebidos pelas
interfaces TDM não respeitem as definições de relógio. Para identificar se esse é o caso, siga os passos
abaixo:
1) Criar um segundo bundle, deixando as portas TDM deste novo bundle sem cabo conectado ou
em loop físico. Observar o jitter-buffer por no mínimo 10 minutos até que se estabilize. Caso se
estabilize (parou de ocorrer underflow/overflow), significa que pelo menos um dos EDDs está
recebendo pela interface TDM dados que não respeitam o relógio estabelecido. Desconecte todos
os cabos das interfaces TDM em ambos EDD e o problema deve cessar. Nesse caso, o
equipamento que não respeita o relógio é aquele que está conectado ao EDD oposto do qual
apresenta a variação no jitter-buffer (ver figura 2).
13.2.3 Equipamentos ponto-a-ponto com mais de um Bundle e relógio regenerado

de TDM
Bundle de propagação do relógio Fonte de relógio

Bundle 1
TDM1 TDM1
EDD_A Bundle 2 EDD_B
TDM2 TDM2
Bundle #
TDM# TDM#
Figura 9: Topologia ponto-a-ponto com mais de um bundle
Quando há um problema de relógio neste cenário, o bundle que é fonte de relógio no EDD remoto
(bundle 1 do EDD_B na figura 9) não apresenta problema, pois regenera baseado no que a TDM1 do
EDD_A envia. Dessa maneira, caso o equipamento conectado na TDM1 do EDD_B regenere corretamente
da TDM1, todo o circuito do bundle 1 funciona com apenas uma fonte de relógio. Já os outros bundles
podem apresentar problemas, pois pode haver uma variação de sincronismo entre os relógios dos outros
TDMs no EDD_A. Para verificar essa situação, siga os passos abaixo:
1) Certifique-se de que, no EDD_B, o bundle utilizado para regeneração do relógio é o mesmo que
está conectado à TDM fonte de relógio no EDD_A, conforme ilustra a figura 9.

Bundle Jitter-Buffer OK Jitter-Buffer NOK
Relógio A Relógio B
TDM1 TDM1
TDM2 TDM2
TDM3 TDM3
EDD_A EDD_B
Figura 10: Cenário ponto-a-ponto com mais de um relógio
2) Verifique se a variação do jitter-buffer ocorre apenas em bundles do EDD_B. No EDD_A
nenhum bundle deve apresentar overflow/underflow. Essa situação confirma a falta de sincronismo
em relação ao TDM1 nos TDMs utilizados nos bundles com problema no EDD_A. A figura 10
ilustra essa situação.
3) Nesses casos recomenda-se tornar o EDD_A no gerador de relógio para todos os outros
equipamentos. Se isso não for possível, recomenda-se separar os bundles com problema em
enlaces ponto-a-ponto isolados, conforme a figura 8.
13.2.4 Equipamentos com Bundles em topologia de estrela com relógio regenerado

de TDM
Fonte de relógio
Bundle 1 EDD_B TDM1

TDM1 Bundle 2
TDM2 EDD_A EDD_C TDM1
Bundle #
TDM#
EDD_D TDM1
TDM#
Figura 11: Topologia estrela
Quando há um problema de relógio neste cenário, o EDD remoto que está conectado ao bundle do
EDD_A que realiza o CESoP do TDM fonte de relógio não apresenta problemas (bundle 1 na figura 11).
Pois, de forma semelhante ao cenário anterior, todo o circuito do bundle 1 funciona com apenas uma fonte
de relógio. Já os outros bundles podem apresentar problemas, pois pode haver uma variação de
sincronismo entre os relógios dos outros TDMs no EDD_A. Para verificar essa situação, siga os passos
abaixo:

Bundle Jitter-Buffer OK Jitter-Buffer NOK
Relógio A Relógio B
TDM1 TDM1
EDD_B
TDM2 TDM2
EDD_C
TDM3 TDM3
EDD_A EDD_D
Figura 12: Topologia estrela com mais de um relógio
1) Verifique se a variação do jitter-buffer ocorre apenas em bundles do EDD_A. Nos EDDs remotos
ao EDD_A nenhum bundle deve apresentar overflow/underflow. Essa situação confirma a falta de
sincronismo em relação ao TDM1 nos TDMs utilizados nos bundles com problema no EDD_A. A
figura 12 ilustra essa situação.
2) Nesses casos recomenda-se tornar o EDD_A no gerador de relógio para todos os outros
equipamentos. Se isso não for possível, recomenda-se separar os bundles com problema em
enlaces ponto-a-ponto isolados, conforme a figura 8.
13.3 Underflow/Overflow acontece subitamente

Quando não existe variação perceptível do jitter-buffer e mesmo assim ocorrem underflow/overflow
sem intervalos bem definidos, é tipicamente um problema de jitter na rede. Esses problemas são mais
comuns em redes em que os EDDs estão conectados por canais wireless. Nesses casos também é possível
que haja incremento dos contadores de Packet Loss, Out of Order e Sequence Number Violation. Para
confirmar essa situação, siga os passos a seguir:
1) Crie um segundo bundle entre os equipamentos que apresentam problema utilizando uma porta
TDM disponível (deixar sem conexão) e configurar da mesma maneira que o bundle que apresenta
o problema. Após 10 minutos, limpe os contadores e observe que o bundle para teste deve
apresentar overflow/underflow de forma semelhante o bundle original.
2) Aumente o jitter-buffer do bundle teste em ambos EDDs para o maior valor possível e limpe os
contadores:
Timeslot Packet-Delay Jitter-Buffer

1-16 (TDM line-type pcm31) 8 496
3) Verifique que os eventos de underflow/overflow são significativamente menores que o do bundle

original. Essa configuração prova que existe variações de jitter muito grande na rede.
4) Para chegar ao valor ideal, vá reduzindo o tamanho do jitter-buffer e packet-delay até que os
problemas de underflow/overflow voltem a acontecer. Lembre-se de que quanto maior o jitter-
buffer e packet-delay, menor será a qualidade dos dados de voz recebidos pelos usuários. Após
encontrar o ponto mínimo em que não ocorrem eventos de underflow/overflow, recomenda-se que
seja adicionado uma margem de erro de pelo menos 1,5x sobre o valor mínimo encontrado, pois o
jitter pode variar ao longo do tempo.

13.4 Slips no tráfego dos equipamentos
Este problema pode ser motivado por alguns fatores, conforme descritos abaixo:
• Portas Ethernet dos equipamentos não operando na mesma velocidade e modo duplex;
• Porta Ethernet configurado para operar em modo half duplex. Pode causar extrema variação do
packet-delay devido as colisões;
• Jitter-buffer não configurado corretamente, ocorrendo underflow/overflow do buffer

periódicamente;
• Problema de jitter na rede ou perda de quadros.
Segue abaixo algumas ações corretivas para a resolução deste problema:
1) Verifique a conexão física das E1's nos equipamentos;
2) Verifique se o jitter-buffer está configurado corretamente, de forma a transmitir os pacotes em

intervalos convenientes. Consulte a seção “Configuração do Jitter-Buffer” para maiores detalhes;
3) Verifique se as portas Ethernet possuem a mesma configuração (Negociação, velocidade e

modo duplex);
14 Comportamento de Alarmes e Traps

Nesta seção são demonstradas as situações em que ocorrem os eventos de alarmes e,
consequentemente, o envio das traps e mensagens de log. Durante o contexto será tomado como base a
topologia de exemplo para a demonstração da condição de falha em que cada alarme é gerado.
14.1 TDM Unframed

No modo unframed não existe envio de Remote Alarm pelos equipamentos. Na sequência são
apresentados os eventos de alarmes e cenários característicos do modo unframed.
14.1.1 Perda de Sinal (LOS)

Se o EDD_RX não esteja recebendo os pacotes em decorrência da perda de conexão RX com o
equipamento adjacente, é gerado na interface TDM do EDD_RX o alarme de perda de sinal (LOS), e no
status do bundle é sinalizado a falha do TDM Local. No EDD_ADAP, o status do bundle sinaliza a falha do
TDM Remote e a interface TDM passa a enviar o sinal de AIS ao equipamento adjacente.
Figura 13: TDM Unframed - Perda de Conexão RX
As traps e logs enviados na condição de falha da figura 13, são apresentadas abaixo:

EDD_RX: Alarme de Perda de Sinal (LOS) no TDM Local:
Link Status: – Log: "Link status on TDM 1/1 change to LOS”;

LOS
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40036 (G704_link_status) com
o valor 1 (Fail).
EDD_ADAP: Alarme de Falha no TDM Remoto:
TDM – Log: “Remote TDM status on Bundle 1/1 change to Fail;

Remote: Fail
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40041 (bundle_tdm_remote)
com o valor 1 (Fail).
14.1.2 Falha do Bundle Local (Perda de Conexão Ethernet)

No caso da perda de conexão Ethernet entre o EDD_RX e o EDD_ADAP, é gerado o alarme de
falha local no bundle. A interface TDM de ambos os EDDs passam a enviar os últimos dados do frame TDM
válido repetidamente, causando erro de dados nos equipamentos adjacentes.
Figura 14: TDM Unframed - Perda de Conexão Ethernet
EDD_RX e EDD_ADAP: Alarme de Falha do Bundle Local:
Local – Log: “Local Bundle status on Bundle 1/1 change to Fail.”

Bundle: Fail
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40042 (bundle_local_status)
com o valor 1 (Fail)
14.1.3 Falha do Bundle Local (Perda Excessiva de Pacotes)

Caso houver a ocorrência de perda de pacotes acima da taxa configurada em packet-loss-threshold
no sentido EDD_RX a EDD_ADAP, é gerado no EDD_ADAP o alarme de falha local do bundle. O EDD_RX
recebe o alarme do bundle remoto sendo o status Fail. O tráfego Ethernet no sentido EDD_ADAP ao
EDD_RX continua normal.

Figura 15: TDM Unframed - Perda Excessiva de Pacotes
EDD_RX: Alarme de Falha do Bundle Local:
Local – Log: “Local Bundle status on Bundle 1/1 change to Fail.”;

Bundle: Fail
EDD_ADAP: Alarme de Falha do Bundle Remoto:
Remote – Log: “Remote Bundle status on Bundle 1/1 change to Fail”;

Bundle: Fail
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40043 (bundle_remote_status)
14.1.4 TDM e Bundle OK (Sem Evento de Alarme)

Supondo que o EDD_RX não esteja transmitindo os pacotes ao equipamento adjacente devido a
perda da conexão TX, nenhum alarme será gerado na interface TDM de ambos os EDDs.
Figura 16: TDM Unframed - Perda de Conexão TX
Neste caso não ocorre o envio de nenhuma trap ou mensagem de log.
14.2 TDM framed

No modo framed existe o envio do Remote Alarm (RALM) pelos equipamentos. Na sequência são
apresentados os eventos de alarmes e cenários característicos do modo framed.
14.2.1 Sinalização do Alarme Remoto (RALM)

Supondo que o EDD_RX não esteja transmitindo os pacotes ao equipamento adjacente devido a
perda da conexão TX, este último envia a sinalização de alarme remoto (RALM) para a interface TDM do
EDD_RX. No status do bundle, o TDM Local do EDD_RX e o TDM Remote do EDD_ADAP são sinalizados

com RDI. A sinalização do alarme remoto recebida na interface TDM do EDD_RX, não é replicada no
sentido TX da interface TDM do EDD_ADAP.
Figura 17: TDM Framed - Perda de Conexão TX
EDD_RX: Sinalização do Alarme Remoto (RALM):
Remote Alarm: – Log: “Remote Alarm status on TDM 1/1 change to RALM”;
RALM
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40037 (G704_remote_status)
com o valor 5 (RALM);
BUNDLE EDD_RX:
TDM Local: – Log: “Local TDM status on Bundle 1/1 change to RDI”.
RDI
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40040 (bundle_tdm_local)
com o valor 3 (RDI);
EDD_ADAP: Indicação de Falha do TDM Remoto:
TDM Remote: – Log: “Remote TDM status on Bundle /1 change to RDI.”

RDI
com o valor 3 (RDI).
14.2.2 Perda de Sinal ou Alinhamento do Quadro (LOS ou LOF)

Caso a perda de conexão seja no RX do EDD, é gerado na interface TDM o alarme de perda de
sinal (LOS) ou a perda de alinhamento do quadro (LOF), além de ocorrer a sinalização de falha no TDM
Local do bundle. No EDD_ADAP é sinalizada a falha no TDM Remote do bundle e a interface TDM passa a
enviar o sinal de AIS para o equipamento adjacente.

Figura 18: TDM Framed - Perda de Conexão RX
EDD_RX: Perda de Sinal (LOS) ou Perda de Alinhamento do Quadro

(LOF):
– Log: “Link status on TDM 1/1 change to LOS.”;

Link Status: valor 1 (LOS) ou 3 (LOF);
LOS/LOF
BUNDLE EDD_RX:
– Log: “Local TDM status on Bundle 1/1 change to Fail.”
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40040 (bundle_tdm_local) com

o valor 1 (Fail).
EDD_ADAP: Alarme de Falha no TDM Remoto:
TDM – Log: “Remote TDM status on Bundle 1/1 change to Fail.”

Remote: Fail
com o valor 1 (Fail);
14.2.3 Falha do Bundle Local (Perda de Conexão Ethernet)

Na perda de conexão Ethernet é gerado o alarme de falha local no bundle dos EDDs. A interface
TDM dos equipamentos passam a enviar os últimos dados do frame TDM válido repetidamente, causando
apenas erro de dados nos equipamentos adjacentes.
Figura 19: TDM Framed - Perda de Conexão Ethernet

EDD_RX e EDD_ADAP: Alarme de Falha do Bundle Local:
Local – Log: “Local Bundle status on Bundle 1/1 change to Fail.”

Bundle: Fail
14.2.4 Falha do Bundle Local (Perda Excessiva de Pacotes)

No caso de perda de pacotes acima da taxa configurada em packet-loss- threshold no sentido
EDD_RX ao EDD_ADAP, é gerado no equipamentos EDD_ADAP o alarme de falha local do bundle. O
EDD_RX recebe o alarme do bundle remoto sendo o status Fail. O tráfego Ethernet no sentido EDD_ADAP
ao EDD_RX continua normal.
Figura 20: TDM Framed - Perda Excessiva de Pacotes
EDD_RX: Alarme de Falha do Bundle Local:
Local – Log: “Local Bundle status on Bundle 1/1 change to Fail.”;

Bundle: Fail
EDD_ADAP: Alarme de Falha do Bundle Remoto:
Remote – Log: “Remote Bundle status on Bundle 1/1 change to Fail”;

Bundle: Fail
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40043 (bundle_remote_status)
14.2.5 Sinalização de AIS

Ao receber a sinalização de AIS na interface TDM, o EDD_RX acusa AIS no Link Status e o bundle
sinaliza a falha no TDM Local. No EDD_ADAP é sinalizada a falha no TDM Remote do bundle.

Figura 21: Recepção de AIS
EDD_RX: Sinalização de AIS:
Link Status: – Log: “Link status on TDM 1/1 change to AIS.”

AIS
o valor 2 (AIS).
BUNDLE EDD_RX:
TDM Local: – Log: Local TDM status on Bundle 1/1 change to Fail.”
Fail
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40040 (bundle_tdm_local) com
o valor 1 (Fail);
EDD_ADAP: Alarme de Falha do TDM Remoto:
TDM – Log: “Remote TDM status on Bundle 1/1 change to Fail.”

Remote: Fail
14.2.6 Alarme de Packet Size

Quando existem problemas de configuração entre dois bundles, como número de timeslots
diferentes, configuração de interfaces TDM relativas a estes bundles com linetypes diferentes, os pacotes
Ethernet trocados entre eles serão gerados com tamanho diferente do esperado. Neste caso é alarmado
Mismatch no Packet Size do bundle. Os contadores dos bundles são incrementados a cada pacote com
tamanho errado que chega.
Figura 22: Recepção de Alarme Packet Size

EDD_RX e EDD_ADAP: Alarme de tamanho dos pacotes incompatíveis:
Packet size: – Log: “Packet size status on Bundle 1/1 change to Mismatch.”;
Mismatch
– Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40044 (bundle_pkt_mismatch)
com o valor 3 (Mismatch);
14.2.7 Alarmes de CAS e CRC

Disponível para os linetypes PCM31-CRC , PCM30-CAS e PCM30- CAS-CRC , a sinalização de
status de CRC e CAS acontece somente quando o Link Status da interface TDM estiver Ok, caso contrário,
o mesmo estando em LOS, LOF ou AIS, esta sinalização passa a ser considerada don't care "-". Os alarmes
de CAS e CRC da interface TDM não implicam em nenhum alarme da interface bundle, por se tratarem de
erros nos dados TDM.
As traps e os logs são apresentadas abaixo:
– Log: “CAS status on TDM 1/1 change to LOM.”;

CAS status:
LOM – Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40038 (G704_cas_status) com
o valor 4 (LOM).
– Log: “CRC status on TDM 1/1 change to Fail.”;

CRC status:
Fail – Trap OID .1.3.6.1.4.1.3709.3.5.201.2.1.0.40039 (G704_CRC_status)
com o valor 6 (CRC Fail).
15 Coerências
Em determinadas configurações que necessitam de consistência, seja em termos dos parâmetros
informados ou de configurações conflitantes, será realizado a checagem de coerência. Se durante a
checagem for identificado qualquer inconsistência, será retornado uma mensagem indicando o problema
detectado, e a configuração não é aplicada.
As mensagens de coerências são apresentadas abaixo:
Esta mensagem será retornada caso os parâmetros contenham

The value argumentos fora do range de valores permitidos. Casualmente a
configured is Out mensagem poderá estar acompanhada do argumento que foi
of Limits detectado o problema. Recomendações: Verificar o range de
valores suportado para o argumento.
Esta mensagem será retornada caso o número de tag's a serem

Max Number of
adicionadas no header do pacote ultrapassar o limite máximo de 2
VLAN tags in
vlan's. Recomendações: Verificar a consistência de configuração
header is 2
das vlans do PW e QinQ.
Packet delay must Esta mensagem será retornada caso o packet delay não seja
be multiple of 125 múltiplo de 125 unidades de segundo. Recomendações: Configurar

us o packet delay com um valor múltiplo de 125 us.
Esta mensagem será retornada caso a TDM associada ao bundle

Packet delay must
esteja configurada com alinhamento CAS, e o packet delay seja
be 2 ms when CAS
diferente de 2 milisegundos. Recomendações: Ajustar os
is enabled
parâmetros de configuração do alinhamento CAS e/ou packet delay.
Interface is Esta mensagem será retornada caso modificar um parâmetro de

enabled, disable it uma interface TDM ou Bundle ativa. Recomendações: Desabilitar a
before changing interface antes de realizar a configuração do parâmetro.
this parameter
TDM must be Esta mensagem será retornada ao ativar uma interface Bundle cuja
enabled to be used interface TDM associada se encontra inativa. Recomendações:
in bundle interface Ativar a interface TDM ou associar ao Bundle uma interface ativa.
Found one Esta mensagem será retornada ao configurar o timeslot do Bundle

overlapping of que sobrepõem o parâmetro de outra interface Bundle.
Bundle timeslots Recomendações: Ajustar os parâmetros de timeslot do Bundle.
Esta mensagem será retornada ao inserir o erro de BERT em uma

To execute this
interface Bundle desligada. Recomendações: Inserir o erro de
test, Bundle must
BERT após a interface Bundle estar habilitada com ao menos um
be enabled
teste de BERT configurado (bert-psn-side ou bert-tdm-side).
Esta mensagem será retornada ao inserir o erro sem ativar ao

Enable some bert
menos um teste de BERT (bert-psn-side ou bert-tdm-side).
test before insert a
Recomendações: Ativar o teste de BERT desejado (bert-psn-side ou
bert error
bert-tdm-side), e inserir o erro de BERT.
Esta mensagem será retornado quando habilitar um teste na

One test is already
interface Bundle que já possui um teste em execução.
running, disable
Recomendações: Desativar o teste em execução, e ativar o teste
first
desejado.
One loop test is Esta mensagem será retornada quando habilitar o teste de loop que
already running in se encontra ativo em outra interface Bundle. Recomendações:
another bundle, Desativar o teste de loop em execução, e ativar o teste de loop na
disable first interface Bundle desejada.
Esta mensagem será retornada ao configurar uma ocupação

diferente de 32 timeslots em uma interface Bundle, que possui
TDM is configured
associada uma interface TDM no modo unframed. Somente é
as Unframed, you
permitido a configuração de 32 timeslots no modo unframed.
have to use 32
Recomendações: Ajustar os parâmetros do intervalo de tempo entre
timeslots
a interface Bundle (timeslot) e a interface TDM associada (line
type).
CAS is enabled, Esta mensagem será retornada ao configurar uma ocupação

number of time superior a 30 timeslots na interface Bundle, que possui associada
slots cannot be uma interface TDM com alinhamento CAS. Os timeslots 0 e 16 são
bigger than 30 reservados para o sincronismo do quadro e a sinalização
respectivamente, restando o máximo de 30 timeslots configuráveis.
Recomendações: Ajustar o parâmetro da interface Bundle para uma

ocupação de até 30 timeslots.
Esta mensagem será retornada ao configurar o timeslot inicial

CAS is enabled,
sendo 0 ou 16 em uma interface Bundle, que possui associada uma
time slot 0 and 16
interface TDM com alinhamento CAS. Os timeslots 0 e 16 são
cannot be the first
reservados para o sincronismo do quadro e a sinalização
time slot in the
respectivamente. Recomendações: Ajustar o timeslot inicial na
Bundle
interface Bundle para um número diferente de 0 e 16.
Esta mensagem será retornada ao configurar o timeslot inicial

TDM is framed, sendo 0 em uma interface Bundle, que possui associada uma
timeslot 0 cannot interface TDM no modo framed. Neste modo, o timeslot 0 é utilizado
be used para o sincronismo dos quadros. Recomendações: Configurar o
timeslot inicial na interface Bundle para um número de 0.
Esta mensagem será retornada ao configurar uma ocupação

superior a 31 timeslots na interface Bundle, que possui associada
TDM final timeslot
uma interface TDM no modo framed. Neste modo, o timeslot 0 é
must be smaller
utilizado para o sincronismo dos quadros, restando o máximo de 31
than 32
timeslots configuráveis. Recomendações: Configurar a ocupação de
no máximo 31 timeslots na interface Bundle.
Esta mensagem será retornada ao configurar os parâmetros

Packet delay and
packet-delay e timeslot com valores excessivos, superando o
number of
tamanho máximo de 1.518 bytes nos pacotes ethernet
timeslots results in
(considerando os headers e payload). Recomendações: Ajustar os
a invalid packet
parâmetros packet-delay e/ou timeslot para uma margem de
size configuration
tamanho de pacotes ethernet suportada.
Esta mensagem será retornada ao configurar o jitter-buffer na qual

Twice size of jitter o dobro do seu tamanho não seja múltiplo do packet delay. O
buffer must be an tamanho do jitter-buffer (FIFO) deve ser um múltiplo inteiro do
integer multiple of packet-delay. Recomendações: Configurar o tamanho do jitter-
packet delay buffer, levando em conta que o dobro do seu tamanho seja múltiplo
do packet-delay.
16 Apêndice A: Configuração exemplo resumida

Ao final do setup aplicado em ambos os equipamentos, o resultado das configurações deve ser
semelhante ao demonstrado abaixo. São apresentadas somente as configurações relevantes ao setup
descrito neste documento, podendo o switch também possuir outras configurações que não pertencem ao
setup.
16.1 Configuração do EDD_RX

Para visualizar a configuração do EDD_RX, deve-se executar o comando:
#show running-config
EDD SERIES I EDDs SERIES II e III
... ...

interface vlan 10 interface vlan 10
ip address 10.1.1.100/16 ip address 10.1.1.100/16
set-member tagged ethernet 1/1 set-member tagged ethernet 1/1
set-member untagged ethernet 1/3 set-member untagged ethernet 1/3
! !
set-member tagged pw
! !
interface ethernet 1/3 interface ethernet 1/3
switchport native vlan 10 switchport native vlan 10
! !
sync-source transmit-clock-source sync-source hierarchy 1 transmit-

tdm 1/1 clock-source tdm 1/1
! !
interface tdm 1/1 interface tdm 1/1
line-type e1 pcm30-cas-crc line-type pcm30-cas-crc
no shutdown no shutdown
! impedance 75 ohms
interface bundle 1/1 !
timeslots 1 30 interface bundle 1/1
packet-delay 2.000 timeslots 1 30
vlan 20 priority 7 packet-delay 2.000
source-ip-address 20.1.1.100 destination-ip-address 20.1.1.101
destination-ip-address 20.1.1.101 ip-next-hop 20.1.1.101
ip-next-hop 20.1.1.101 dscp 0
no shutdown packet-loss-threshold 1.00
tdm-channel 1
... circuit-name NOME_BUNDLE
no shutdown
interface pw 1/1

source-ip-addr 20.1.1.100
vlan 20 priority 7
...
16.2 Configuração do EDD_ADAP

Para visualizar a configuração do EDD_ADAP, deve-se executar o comando:
#show running-config
EDD SERIES I EDDs SERIES II e III
... ...
ip address 10.1.1.101/16 ip address 10.1.1.101/16
! !
set-member tagged pw !
! sync-source hierarchy 1 transmit-

clock-source bundle 1/1
sync-source transmit-clock-source
bundle 1/1 !
! interface tdm 1/1
interface tdm 1/1 line-type pcm30-cas-crc
line-type e1 pcm30-cas-crc no shutdown
no shutdown !
! interface bundle 1/1
interface bundle 1/1 timeslots 1 30
timeslots 1 30 packet-delay 2.000
packet-delay 2.000 destination-ip-address 20.1.1.100
vlan 20 priority 7 ip-next-hop 20.1.1.100
source-ip-address 20.1.1.101 dscp 0
destination-ip-address 20.1.1.100 packet-loss-threshold 1.00

ip-next-hop 20.1.1.100 tdm-channel 1
no shutdown circuit-name NOME_BUNBLE
no shutdown
... !
interface pw 1/1
source-ip-addr 20.1.1.101
vlan 20 priority 7
...
Observação: Configurações destacadas em itálico foram adicionadas para demonstrar o resultado

da topologia apresentada neste documento, uma vez que as mesmas não aparecerão na running-config por
serem a configuração default.

DM 2104

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DM 2104

Caricato da

Copyright:

Formati disponibili

DATACOM

Manual CESoP DmSwitch 2104 – EDD

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 1 de 50

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 3 de 50

Na interface TDM do equipamento, configura-se o PCM que corresponda ao tipo de quadro

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 4 de 50

2.1 Login no Equipamento

2.2 Configuração da Interface de Gerência

2.3 Atualização de Firmware

2.4 Aplicando a Configuração de Fábrica

2.5 Salvando a Configuração Atual na Memória

Para salvar a configuração aplicada na memória do equipamento, utiliza-se o seguinte comando:

2.6 Visualizando a Configuração Atual

2.7 Alterando o HostName

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 5 de 50

Figura 1: Topologia usada nos exmplos

4 Diferenças do Modelo SERIES I para os Modelos SERIES II

4.2 Comandos de configuração

INTERFACE PW O EDD SERIES I não disponibiliza a “interface pw” devido as

Os EDDs SERIES II e III disponibilizam a “interface pw” sua

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 6 de 50

Os comandos pertencentes a esta interface são abordados

No EDD SERIES I esta configuração pode ser feita a partir

A configuração da vlan para o tráfego CESoP também segue

O EDD SERIES I disponibiliza este comando para a

Comando presente no EDD SERIES I (em sync-source

Comando disponível somente no EDD SERIES II modelos

A partir da versão 5.6 do EDD SERIES II, o comando de

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 7 de 50

A única diferença nos comandos para testes de BERT está

Este teste está disponível no EDD SERIES 1. O RTD consiste em

5 Diferenças de Comandos entre Firmwares

FWs anteriores ao 4.4 FW 4.4 em diante

show bundle <n> show interfaces bundle <n>

• EDDs SERIES II e III:

FWs anteriores ao 5.0 FW 5.0 em diante

show bundle <n> show interfaces bundle <n>

show pw 1 show interfaces pw 1

• EDDs SERIES II e III:

FWs anteriores ao 5.6 FW 5.6 em diante

sync-source transmit-clock-source sync-source hierarchy <n> transmit-clock-source

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 8 de 50

Serão demonstradas as configurações para o EDD_RX, para o EDD_ADAP as configurações

6.1 Configuração da Gerência através da VLAN

Após configurada a VLAN 10 é possível configurar o IP de gerência para o endereço indicado.

6.2 Configuração da Interface TDM

Para visualizar as configurações atuais da interface TDM utilize o comando de show:

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 9 de 50

6.2.1 Configuração do Line Type

UNFRAMED Modo unframed 2,048 Mbits (G.703).

PCM31 Modo framed 31 time slots (G.704).

PCM31-CRC Modo framed 31 time slots com CRC (G.704).

PCM30-CAS Modo framed 30 time slots e sinalização CAS (G.704).

Para o nosso teste será necessário o modo PCM30-CAS-CRC:

(config-if-tdm-1/1)# line-type e1 pcm30-cas-crc

EDDs SERIES II e III:

(config-if-tdm-1/1)# line-type pcm30-cas-crc

6.2.2 Configuração de Impedância da TDM

Abaixo um exemplo de configuração da impedância:

Documento Público Manual CESoP DmSwitch 2104 – EDD Página 10 de 50

SYSTEM Equivalente aos firmwares anteriores, onde a interface utiliza o

ADAPTIVE Utiliza um relógio adaptativo, regenerado do bundle especificado.

Abaixo um exemplo de configuração do sync source: