cisco soho 77 segnale portante sparito

[aranciammx]

Sono circa tre giorni che il router in oggetto non rileva più il segnale della portante.
E' successo tutto in un attimo: da che stavo tranquillamente navigando a quando invece è successo tutto ciò.
Mi connetto tramite libero adsl 4mb, ed ho già aperto una segnalazione guasto sulla mia linea, aggiungo che sono di Catanzaro (nel caso potesse esservi utile).

vi posto la configurazione con la quale ho sempre lavorato benissimo, la potete controllare e dirmi se è corretta o meno?

version 12.1
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Router
!
logging rate-limit console 10 except errors
enable secret 5 ****
!
username **** password 7 ****
ip subnet-zero
no ip finger
ip name-server 193.70.152.15
ip name-server 193.70.152.25
ip dhcp excluded-address 192.168.0.254
ip dhcp excluded-address 192.168.0.1
ip dhcp excluded-address 192.168.0.2
ip dhcp excluded-address 192.168.0.3
ip dhcp excluded-address 192.168.0.4
!
ip dhcp pool CLIENT
import all
network 192.168.0.0 255.255.255.0
default-router 192.168.0.254
dns-server 193.70.152.15 193.70.152.25
!
no ip dhcp-client network-discovery
vpdn enable
no vpdn logging
!
vpdn-group 1
request-dialin
protocol pppoe
!
!
!
!
interface Ethernet0
ip address 192.168.0.254 255.255.255.0
ip adjust-mss 1452
ip nat inside
ip tcp adjust-mss 1452
no ip mroute-cache
!
interface ATM0
no ip address
no ip mroute-cache
no atm ilmi-keepalive
pvc 8/35
protocol pppoe
pppoe-client dial-pool-number 1
!
dsl operating-mode auto
hold-queue 224 in
!
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
ppp authentication pap chap callin
ppp chap hostname ****
ppp chap password ****
ppp pap sent-username **** password 7 ****

ppp ipcp dns request
ppp ipcp wins request
!
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip http server
!
ip nat inside source list 102 interface Dialer1 overload
ip nat inside source static tcp 192.168.0.1 1976 interface Dialer1 1976
ip nat inside source static udp 192.168.0.1 1976 interface Dialer1 1976
ip nat inside source static tcp 192.168.0.3 1977 interface Dialer1 1977
ip nat inside source static udp 192.168.0.3 1977 interface Dialer1 1977
ip nat inside source static tcp 192.168.0.4 1978 interface Dialer1 1978
ip nat inside source static udp 192.168.0.4 1978 interface Dialer1 1978
ip nat inside source static tcp 192.168.0.1 3388 interface Dialer1 3388
ip nat inside source static udp 192.168.0.1 3388 interface Dialer1 3388
ip nat inside source static tcp 192.168.0.3 3389 interface Dialer1 3389
ip nat inside source static udp 192.168.0.3 3389 interface Dialer1 3389
ip nat inside source static tcp 192.168.0.4 3390 interface Dialer1 3390
ip nat inside source static udp 192.168.0.4 3390 interface Dialer1 3390
ip nat inside source static tcp 192.168.0.1 35148 interface Dialer1 35148
ip nat inside source static udp 192.168.0.1 45573 interface Dialer1 45573
ip nat inside source static tcp 192.168.0.3 35149 interface Dialer1 35149
ip nat inside source static udp 192.168.0.3 45574 interface Dialer1 45574
ip nat inside source static tcp 192.168.0.4 35150 interface Dialer1 35150
ip nat inside source static udp 192.168.0.4 45575 interface Dialer1 45575
access-list 102 permit ip 192.168.0.0 0.0.0.255 any
dialer-list 1 protocol ip permit
!
line con 0
exec-timeout 120 0
transport input none
stopbits 1
line vty 0 4
exec-timeout 0 0
login local
length 0
!
scheduler max-task-time 5000
end

[meccanico_mutua]

Se ti può consolare anche a me con libero capita di perdere la portante, non dipende sicuramente dalla configurazione anche perchè se prima ti andava...

Il problema è che c'è troppo congestione e questo crea dei "casuali" down di portante

[Correx]

E' strano che perda la portante... Vedo che nella config postata usi ppp over ethernet, puo tarsi che ti sia stato cambiato, in centrale, in ppp over atm. Nel caso bisogna apportare delle modifiche alla tua config o farlo cambiare da loro ovviamente...
Potresti postare uno show int a0 e uno sh dsl int a0 ?

[pegasolabs]

Comunque se parlate del router sarebbe meglio farlo nel thread ufficiale:
http://www.hwupgrade.it/forum/showthread.php?t=1126850

[aranciammx]

Grazie a tutti per gli aiuti, ho risolto !!!
Veramente io non ho dovuto fare niente perchè era un problema sulla centrale telecom (anche se ho speso 3 giorni provando varie configurazioni diverse, scoprendo poi che quella originale era funzionante)

[meccanico_mutua]

Originariamente inviato da aranciammx

Grazie a tutti per gli aiuti, ho risolto !!!
Veramente io non ho dovuto fare niente perchè era un problema sulla centrale telecom (anche se ho speso 3 giorni provando varie configurazioni diverse, scoprendo poi che quella originale era funzionante)

Come volevasi dimostrare tu eri a posto

In ogni caso scaricano sempre il problema su telecom, ma il problema è che c'è poca banda e basta. Le dslam in centrale sono sovraccariche di utenze e poi escono con un banale 100Mbps multiplexando centinaia di utenze, per limitare la congestione poi tagliano la banda minima, smanettano dove non devono ed ecco ritrovarsi con una linea non funzionante.

[stemanca]

Originariamente inviato da meccanico_mutua

Come volevasi dimostrare tu eri a posto

In ogni caso scaricano sempre il problema su telecom, ma il problema è che c'è poca banda e basta. Le dslam in centrale sono sovraccariche di utenze e poi escono con un banale 100Mbps multiplexando centinaia di utenze, per limitare la congestione poi tagliano la banda minima, smanettano dove non devono ed ecco ritrovarsi con una linea non funzionante.

Data la natura del problema e la sua soluzione, è assai probabile che in questo caso il DSLAM non c'entrasse nulla e fosse proprio un problema in centrale telecom

[meccanico_mutua]

Originariamente inviato da stemanca

Data la natura del problema e la sua soluzione, è assai probabile che in questo caso il DSLAM non c'entrasse nulla e fosse proprio un problema in centrale telecom

Le DSLAM dove pensi che siano? In un MUX e quest'ultimo dov'è? In centrale

Se il MUX è di proprietà Telecom è un problema Telecom escluso il local-loop che è in affitto ad infostrada. Se invece l'utente ha fatto l'unbundling allora il MUX è di proprietà WIND (infostrada) e sono tutti mazzi loro visto che in caso sfruttano solo alcune dorsali telecom.

Cmq non posso sapere dove fosse il problema, non ci ho lavorato sopra io, era una ipotesi come tante, ma di cross-connection sui MUX quando lavoravo in Telecom ne ho RIfatte a centinaia... ci sarà un motivo

[stemanca]

Originariamente inviato da meccanico_mutua

Le DSLAM dove pensi che siano? In un MUX e quest'ultimo dov'è? In centrale

Se il MUX è di proprietà Telecom è un problema Telecom escluso il local-loop che è in affitto ad infostrada. Se invece l'utente ha fatto l'unbundling allora il MUX è di proprietà WIND (infostrada) e sono tutti mazzi loro visto che in caso sfruttano solo alcune dorsali telecom.

Cmq non posso sapere dove fosse il problema, non ci ho lavorato sopra io, era una ipotesi come tante, ma di cross-connection sui MUX quando lavoravo in Telecom ne ho RIfatte a centinaia... ci sarà un motivo

A meno che non sia in wholesale, il dslam con la centrale telecom non c'entra una mazza, nel senso che vi risiede solo fisicamente ma sta in una sala a parte (sala OLO) a competenza Libero

In tal caso, 9 volte su 10 il problema è sul cablaggio dello splitter in uscita dal raccordo rigido o nel collegamento con l'autocommutatore, la sala OLO (e il dslam) sono imputabili solo in casi più rari (non che sia impossibile, eh!)

In ogni caso condivido la tua perplessità sui dslam atm marconi della telecom

STE

[meccanico_mutua]

Originariamente inviato da stemanca

A meno che non sia in wholesale, il dslam con la centrale telecom non c'entra una mazza, nel senso che vi risiede solo fisicamente ma sta in una sala a parte (sala OLO) a competenza Libero

In tal caso, 9 volte su 10 il problema è sul cablaggio dello splitter in uscita dal raccordo rigido o nel collegamento con l'autocommutatore, la sala OLO (e il dslam) sono imputabili solo in casi più rari (non che sia impossibile, eh!)

In ogni caso condivido la tua perplessità sui dslam atm marconi della telecom

STE

Vabbè, star qui a disquisire su quale sala ospiti il MUX (dove al suo interno vengono alloggiate diverse DSLAM, alcune dedicate all'ADSL, altre all'SHDSL) non mi sembra di grande utilità

Ai tempi non era così rare problematiche sui mux e non solo sui marconi, ma anche sui siemens (poi risolte su release successive) e sugli alcatel (i migliori nei primi del millennio).

I marconi erano i più economici e anche i più rognosi, tra l'altro le utenze per singola DSLAM erano limitate a 32 e spesso non le si sfruttavano neppure tutte, poi con i siemens si è passati a 64 e già la situazione era più interessante, ora non so se siano stati fatti salti successivi, tuttavia il problema era più lato ATM su MGX e IGX (i cosiddetti nodi) che dovevano smaltire un mole di traffico mostruosa. Non a caso a tuttoggi gli operatori non offrono banda garantita se non i famosi 10k (escluso fastweb credo e pochi altri che però si fan pagare oro).
Vien da ridere sentire i vari alice 20Mega, fermo restando che in italia non siamo in grado di viaggiare a certe velocità sulla rete per ovvi motivi di bottleneck.

Ricordo quando si doveva settare valori di MCR e PCR sui nodi atm molto più bassi di quelli in realtà dichiarati proprio per problemi di congestione di traffico.

Ma tu dove hai lavorato o lavori?

[stemanca]

Originariamente inviato da meccanico_mutua

Vabbè, star qui a disquisire su quale sala ospiti il MUX (dove al suo interno vengono alloggiate diverse DSLAM, alcune dedicate all'ADSL, altre all'SHDSL) non mi sembra di grande utilità

Ai tempi non era così rare problematiche sui mux e non solo sui marconi, ma anche sui siemens (poi risolte su release successive) e sugli alcatel (i migliori nei primi del millennio).

I marconi erano i più economici e anche i più rognosi, tra l'altro le utenze per singola DSLAM erano limitate a 32 e spesso non le si sfruttavano neppure tutte, poi con i siemens si è passati a 64 e già la situazione era più interessante, ora non so se siano stati fatti salti successivi, tuttavia il problema era più lato ATM su MGX e IGX (i cosiddetti nodi) che dovevano smaltire un mole di traffico mostruosa. Non a caso a tuttoggi gli operatori non offrono banda garantita se non i famosi 10k (escluso fastweb credo e pochi altri che però si fan pagare oro).
Vien da ridere sentire i vari alice 20Mega, fermo restando che in italia non siamo in grado di viaggiare a certe velocità sulla rete per ovvi motivi di bottleneck.

Ricordo quando si doveva settare valori di MCR e PCR sui nodi atm molto più bassi di quelli in realtà dichiarati proprio per problemi di congestione di traffico.

Ma tu dove hai lavorato o lavori?

Prima ero nel bacbone di fastweb a bologna, ho smanettato assai sui siemens e sugli alcatel

Ora sto a tiscali, ho appena abbandonato il settore assurance ma guasti adsl ne ho gestiti in quantità

STE