[b][u]Serial Up e protocol Down, alguém pode me audar?[/u][/

Galera boa noite, sou novo no assunto e no fórum e queria alguma ajuda, mais para a frente pretendo tirar a certificação e comecei a trabalhar com roteadores há uma semana.

Percebi que no meu serviço existem muitos casos de serial up e protocol Down, sempre peço para o cara de tx olhar cabeamento e ficar trocando as conexões de cabeamento, porém sempre demora a resolver(nunca resolvo) e acabam passando para outro cara.

Queria saber se alguém tem um troubleshooting desse caso para me ajudar.

Muito obrigado e boa noite.

Protocolo fica Down quando vc configura protocolos diferentes no router local e remoto por ex: ppp no router local e hdlc no remoto. Ou tambem quando a interface do router esta como DCE e o clock rate nao esta configurado.

Muito Obrigado Alexandr, mas poderia me explicar mais fisicamente, olha aqui abbaixo, peguei 2 routerscom o caso citado acima, poderia dizer aonde vejo e como mudo, por favor?

SAO PAULO #sh int s2/0
Serial2/0 is up, line protocol is down
Hardware is M4T
Description: RIBEIRÃO S1/1
Internet address is 10.18.1.189/30
MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
LMI enq sent 3035, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input never, output 00:00:08, output hang never
Last clearing of "show interface" counters 08:25:58
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1536 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4555 packets output, 59721 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up




RIBEIRAO#sh int s1/1
Serial1/1 is up, line protocol is down
Hardware is M4T
Description: SAO PAULO S2/0
Internet address is 10.18.1.190/30
MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, crc 16, loopback not set
Keepalive set (10 sec)
Restart-Delay is 0 secs
LMI enq sent 320345, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 309793/0, interface broadcasts 295636
Last input 4w6d, output 00:00:01, output hang never
Last clearing of "show interface" counters 5w2d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1536 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1 packets input, 1505 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
662753 packets output, 303969926 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
7 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up

Essa linha mostra o tipo de protocolo (no seu caso FRAME RELAY)

Encapsulation FRAME-RELAY, crc 16, loopback not set

Como vc esta utilizando frame-relay é necessario saber com a operadora o tipo de LMI configurado na rede deles. No seu caso ta configurado como LMI CISCO ( LMI DLCI 1023 LMI type is CISCO frame relay DTE)

Mas no seu caso vc falou que o problema e intermitente ne?!? provavelmente nao seja probelma de configuracao entao...

As vezes o problema pode estar na operadora tbm.....quando os links estiverem UP sempre verifique se existe erros na interface.....é o mesmo comando que vc deu so que verique essas linhas...

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
662753 packets output, 303969926 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out

poderia ser diversas coisas...

Primeiramente, mesmo que line esteja up, ainda pode ser um problema físico.

Pensando de forma lógica, o troubleshooting deve sempre começar nas camadas inferiores, principalmente em se tratando de circuito, onde a maioria dos problemas, de fato é relacionado a camada 1.

Nós temos um ponto a ponto, lgo, se o PVC fica down, ambos os lados ficam down.



A extrutura é mais ou menos essa:


CE---ECSU---SM------LTELCO-----NUVEM-------LTELCO-----SM-------CE

CE = customer edge, isto é, seu roteador
ECSU = external CSU. Caso seu roteador não tenha o csu interno, existe um csu externo pra prover clock.
SM = smartjack ou demarc ou pop, etc... é o ponto em que demarca o início do lado da telco é um ponto de teste também.
LTELCO é a local telco, isto é a operadora (telefonica, embratel, at&t, etc).

O que o provedor faz quando vocêw abre um chamado, primeiramente, vai fazer um teste de loop da nuvem em direção ao CSU. Caso falhar, ele faz um teste no smartjack. Se o teste do smartjack estiver OK, telco dirá que o problema é no seu lado (entre o smartjack e o CSU - podendo seu o cabeamento ou config no router, por exemplo). Se falhar o loop do smartjack, o problem está isolado na telco.

Isso nem sempre é verdade, pois um teste no smartjack (loop), não testa a interface de entrada e saida do lado do customer. Para validar totalmente, só loopando o smartjack fisicamente, com um loopback plug colocado na interface do smartjack.

Tentarei nào ser estenso, pois é um assunto vasto...

Eu recomendo os seguintes passos:

Primeiro, de cara, abra um chamado com a operadora. Deixe ela investigar o PVC e fazer os testes de loop dela (lembrando que, muitas vezes, eles testam apenas loop em camada 1. Se não detectarem problema em camada 1, muitas vezes eles dizem que o link está bom. Tenha certeza de que eles também chequem a camada 2 (o PVC).

Se você utiliza um CSU interno, para checar problemas de camada 1, use o comando service-module

exemplo: show service-module se1/0

Se for um T1, E1, utilizr show controllers T1 1/0 ou E1 1/0 onde o 1/0 é equivalente a sua interface.

Se você utiliza um CSU externo, utilize o comando show controllers se1/0

dependendo do output, você terá intervalos de 15 em 15 minutos, os quais conterá diversos contadores.


Basicamente:

hardware: VWIC
Show controllers T1 0/0


Router# show controllers t1
T1 4/1 is up.
  No alarms detected.
  Framing is ESF, Line Code is AMI, Clock Source is line
  Data in current interval (0 seconds elapsed): 
     0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 
     0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 
     0 Severely Err Secs, 0 Unavail Secs 
  Total Data (last 79 15 minute intervals): 
     0 Line Code Violations, 0 Path Code Violations, 0 Slip Secs, 0 Fr Loss Secs, 
     0 Line Err Secs, 0 Degraded Mins, 0 Errored Secs, 0 Bursty Err Secs, 
     0 Severely Err Secs, 0 Unavail Secs 


No caso acima, estou exibindo apenas o primeiro intervalo, mas no router, você poderá ver os ultimos 96 intervalos de 15 minutos casa, isto é um resumo detalhado das ultimas 24 horas.
Acredito que seu caso não seja desse comando, pois você não está com uma T1/E1. Mas fica ai!


hardware: WIC
Show service-module s0/0



Tipos de erros:

LOS - Loss of Signall
Significa que o line perdeu sinal. Como se não existisse pulso elétrico, isto é, completamente down. Neste caso, você teria o link down/down. Isso acontece quando a interface não recebe voltageml por um período de 100 bits.

LOF - loss of frame
Recebe voltagem, mas indica que não foi detectado um frame mais de 2 segundos.

OOF - out of frame
Recebe voltagem, mas indica que não foi detectado um frame num período inferior a 2 segundos.


Temos também os conceitos de Red alarm, Blue alarm e Yellow alarm

Red alarm ocorre quando o problema é no próprio device, que pode ser ocasionado por LOS ou LOF.

Yellow alarm é quando o device diretamente conectado ao aparelho com problema percebeu um problema e envia o yellow alarm de volta para o equipamento com problema. Também, se o equipamento com problema conseguir, ele envia o yellow para o equipamento conectado a ele para indicar o problema.

Blue alarm é quando o device envia uma notificação de problemas no sentido oposto ao problema

exemplo:

CE-----CSUEXTERNO-----SM---TELCO

Se tivermos um problema no CSU vindo da telco (Rx do CSU, isto é, trafego vindo da telco em direção ao CSU), o CSU terá um RED alarm no Rx. Enviará um Yellow alarm pelo Tx em sentido a telco e também enviará o blue alarm em sentido ao CE. O Blue alarm é conhecido também como AIS (Cisco mostra o log como AIS).


Como disse, é muito estenso hehehe...


Vamos para a prática.

Se camada 1 não funciona, camadas acimas não funcionarão bem. Comece o troubleshooting pela camada 1.

- Cheque por logs. Veja se existem indicações de problemas pelo log (sh log)
- Cheque controllers para ver se tem erros de camada 1 (processo descrito acima)
- Cheque erros na interface (sh int). Muitas vezes, erros são detectados em camada 1, mas não notado em camada 2, quando forem intermintentes.
- Cheque o frame-relay (sh frame-relay pvc / sh frame-relay lmi / sh frame-relay int)

Trabalhe com a telco... exija, de forma clara, o que ela vê. Quais foram os testes que eles fizeram.

Se você validou seu lado, incluindo cabeamento e a telco insistir que o problema não é dela, peça para eles refazerem o PVC. Eles não gostam muito disso hehehe...

Por fim, se a telco disse que o problema não é dela, faça um teste de loop por você mesmo e veja se detecta erros.
Você pode logar no equipamento e loopar sua própria WIC, com encapsulamento HDLC, vc pode pingar com vários patterns sua propria interface, testando line code, framing, etc.
Tem várias maneiras de loopar.

De qualquer maneira, a telco só vai poder falar que não é problema dela (de camada 1), se realmente ela for no site e loopar fisicamente o smartjack.


O site da cisco tem muita documentação e pode ajudar com os outputs... www.cisco.com e coloque no campo de busca o que quiser, se estiver em duvida sobre algum comando, etc.. lá explica passo a passo cada comando, cada campo.


Vai colocando ai o progesso que vamos ajudando no que der...
Escrevi muito e nada muito específico!!!