Newsgroup: it.comp.reti.cisco
Titolo: Problema frame-relay

Ciao a tutti,
premetto che non ho grosse esperienze sul campo frame-relay.
Ho da qualche giorno una linea che non funziona, volevo
chiedere lumi in merito ai passi necessari a fare un minimo
di debug sul problema, giusto per restringere il campo...
quello che ho fatto sino ad ora è stato:
Serial0/0 is up, line protocol is down
  Hardware is PowerQUICC Serial
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation FRAME-RELAY IETF, loopback not set
  Keepalive set (10 sec)
  LMI enq sent  9714, LMI stat recvd 6463, 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
  Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
  Last input 00:00:09, output 00:00:09, output hang never
  Last clearing of "show interface" counters 1d02h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     96634 packets input, 5578340 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     1541 input errors, 0 CRC, 1541 frame, 0 overrun, 0 ignored, 0 abort
     9982 packets output, 153645 bytes, 0 underruns
     0 output errors, 0 collisions, 3230 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
              Active     Inactive      Deleted       Static
  Local          0            1            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0
DLCI = 20, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE =
Serial0/0.1
  input pkts 90167         output pkts 287          in bytes 5442756
  out bytes 27610          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  pvc create time 1d02h, last time pvc status changed 1d02h
da quello che ne ho capito la linea fisicamente sta su ma non
il protocollo frame-relay....
a questo punto volevo capire se è un problema Telecomics
(fornitore della linea fisica) o del provider....
la mia supposizione è che telecom ha fatto il malanno e
ha pasticciato con il circuito logico (PVC) che prima
 funzionava....
qualche suggerimento ???



   Encapsulation FRAME-RELAY IETF, loopback not set Keepalive set (10 sec)
prova con:
int s0
enc fram
int s0.1
fram interface-dlci 20 ietf
prova anche senza ietf.
se ancora non va telefona ai butei telecom e fagli sistemare il tutto.
(anche se pacchetti in entrata ne hai).
un mayhem e le prime prove
-- 
 Everyone is gay, with someone else's ass 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613


Prova a fare un "sh frame-relay dlci" ed un "debug frame-relay lmi", cattura
l'output del primo e del secondo per un paio di minuti poi mandaci il tutto
insieme ad un bel "sh run".
Il mio sospetto č che non ci sia un pvc attivo su quella linea, dal momento
che quello che hai configurato te lo da inactive e non ne compaiono altri;
in teoria se avessi sbagliato dlci ti dovrebbe comparire un secondo pvc con
il dlci giusto e lo stato di "deleted" o qualcosa del genere.
Sai se la linea č una cdn, hdsl o shdsl?
Ciao,
        Tosh.

 (anche se pacchetti in entrata ne hai).
gią aperta una chiamata, sai percaso i tempi telecom
di intervento in queste circostanze ???
altra domanda, ma se prima funzionava, un buteo telecom
ha fatto casini con le conf ???

 il dlci giusto e lo stato di "deleted" o qualcosa del genere.
appunto...
poi il dlci non me l'avevano manco dato, l'ho ricavato io
con sh frame-relay PVC....
ciao

 1d07h: 00 75 01 01 00 03 02 9B AA
cz so di fretta ma questi prob mi interessano sempre.. phy up , proto up ,
DTE lmi down.. non riceve correttamente lmi: sommando l'output del debug
lmi con lo sho int mi verebbe da ascrivere questi lmi "assenti" a in quegli
input errors; fra l'altro input e frame err uguali.. io mi orienterei per
un prob fra la s0 ed il dce, ma molto di piu' per il dce...non direi un
prob di clocking non vedo crc ne aborts.. nemmeno di framing visto che dici
che funzionava.. controlla il cavo, magari provandone un'altro.
Controlla che non sia in palla il dce e fornisca il clock,  magari
resettalo...verifica che non ci sia un prob di areazione/temperatura tipo
fonti fi calore vicino ot simili (il rumore termico fa miracoli).. ad ogni
modo non sarebbe male dare un'occhiata a sh contr s0/0 ed eventualmente se
ti puzza un debug sulla serial.. ad ogni buon conto io preferisco lasciarlo
in autosensing l'lmi salvo controindicazioni di telecomics (ah gia'..
quando mai te lo dicono =))
Saluti.

 telecom ha fatto casini con le conf ???
i tempi ... quando le cose non funzionano sono ere. come il tempo che il
valpolicella superiore deve invecchiare.
se prima funzionava... beh e' telecom, ora non e' detto che funzioni.
troppi cavi, configurazioni, persone e protocolli (nel senso id iso).
se la tua cfg e' ok, non ti resta che stare seduto sulla riva del fiume.
un mayhem che il loro cadavere non passa mai


 !
Toglilo, cosě gli lascia rilevare l'lmi type in automatico.
Non vedo dai tuoi output gli lmi della centrale, per cui o č sbagliato l'lmi
type o c'č un problema in centrale o č andato in palla il dce.
Ciao,
        Tosh.