Académique Documents
Professionnel Documents
Culture Documents
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.
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.
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
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.
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.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:
• EDD SERIES I:
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:
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
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.
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
PCM30-CAS-CRC Modo framed 30 time slots e sinalização CAS com CRC (G.704).
EDD SERIES I:
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.
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)# interface pw 1
(config-if-pw-1/1)# source-ip-address 20.1.1.100
(config-if-pw-1/1)# vlan 20 priority 7
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
Exemplo:
(config-if-pw-1/1)#idle-byte 0xFF
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)# interface bundle 1
(config-if-bundle-1/1)# shutdown
Nota: O tráfego enviado pela interface bundle sobre a rede ethernet é encapsulado em pacotes que
• unframed: de 0 à 32
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
Bundle 1/1 Interface:
[…]
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
É 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
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
Bundle 1/1 Interface:
[…]
Details:
Min. Jitter Buffer: 2.000 ms
Max. Jitter Buffer: 62.000 ms
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.
• 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);
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.
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:
• Regenerado de uma fonte externa (EDDsII apenas): o relógio recebido por uma fonte externa,
conectada ao EDD, é utilizado como fonte.
Neste caso, a fonte de sincronismo configurada será uma referência global para as interfaces TDM.
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.
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
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.
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.
EDD SERIES I
EDD SERIES I
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.
Internal PW stats:
Packets input : 0
Discard input : 0
Bundles reached packets : 0
Octets input : 0
Octets output : 0
Unicast input : 0
Packets Este contador indica o número TOTAL de pacotes de entrada recebidos pelo
Input equipamento.
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.
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.
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).
• 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;
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;
• As linhas Max e Min S/N allowed mostram a evolução da faixa de reordenamento conforme os
pacotes são recebidos;
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,
• 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.
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
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
Nota: A seção de Troubleshooting aplica-se plenamente apenas a versões de firmware anteriores a 5.6.
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
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).
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.
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.
Fonte de relógio
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:
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.
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:
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.
• 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;
As traps e logs enviados na condição de falha da figura 13, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 14, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 15, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 17, são apresentadas abaixo:
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);
As traps e logs enviados na condição de falha da figura 18, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 19, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 20, são apresentadas abaixo:
As traps e logs enviados na condição de falha da figura 21, são apresentadas abaixo:
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);
As traps e logs enviados na condição de falha da figura 22, são apresentadas abaixo:
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);
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.
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
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.
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.
... ...
! !
set-member tagged pw
! !
! !
! !
no shutdown no shutdown
! impedance 75 ohms
tdm-channel 1
no shutdown
interface pw 1/1
vlan 20 priority 7
...
... ...
! !
set-member tagged pw !
no shutdown !
no shutdown
... !
interface pw 1/1
source-ip-addr 20.1.1.101
vlan 20 priority 7
...