Migrato su DPPU: ancora porte chiuse! VERGOGNA

[Marc Serafino]

Confermo che Fastweb e' un'azienda di BARBONI che dice di vendere Internet
e invece anche ora che assegna un IP pubblico dinamico (come tutti gli
altri provider) continua a non concedere vero accesso ad Internet in quanto
le porte sono TUTTE chiuse in ingresso (tranne la 80 ovviamente). Ricordo
infatti che la corretta definizione di connessione ad Internet identifica
un nodo perfettamente raggiungibile da qualsiasi altro nodo della rete. E
con Fastweb, quei barboni di Fastweb, nonostante tutto non e' ancora cosi'.

Lo posso dire con certezza perche' esattamente OGGI mi hanno migrato sui
nuovi pool DPPU, probabilmente nel pomeriggio. In questo momento ci sono
due apparati connessi all'Hag e predisposti per andare su Internet,
entrambi gli apparati dispongono di un proprio IP pubblico dinamico
93.x.x.x (un pc e' connesso direttamente e il router della mia rete locale)
e entrambi gli IP pubblici dinamici univoci hanno TUTTE LE PORTE IN
INGRESSO BEN TAPPATE!!! VERGOGNA FASTWEB.

Posso aggiungere che gli IP della MAN non sono cambiati, sono quelli che ho
da anni, e che la mappatura di MACS per quanto mi riguarda almeno e'
sbagliata: il mio IP pubblico viene infatti da lui associato ad una
differente MAN rispetto a quella alla quale sono collegato io.

Ho provato a vedere se e' cambiato qualcosa anche per l'attivazione dell'IP
pubblico dinamico, ma con porte aperte (a questo punto e' solo questa la
differenza): non e' cambiato nulla, l'attivazione assegna un nuovo IP
questa volta si tratta di un 62.x.x.x proprio come prima della migrazione e
questa volta le porte sono ovviamente aperte (ma SI PAGA ANCHE!!! SI
PAGA?????????? CON GLI ALTRI PROVIDER L'IP PUBBLICO DINAMICO SENZA PORTE
CHIUSE E' PARTE DELL'ABBONAMENTO, INTERNET PREVEDE UN IP PUBBLICO CON LE
PORTE APERTE, come detto!)

FASTWEB SIETE PROPRIO DEI BARBONI PERCHE' ORA L'IP PUBBLICO LO POTETE DARE
COME FANNO TUTTI, NON C'E' PIU' LA SCUSA DEL NAT!!!

Ma nonostante tutto non lo date... E specie nei confronti di chi ha una
delle vostre pessime DSL e' una vera mancanza di riguardo considerando
anche quanto fate pagare l'abbonamento a regime!!!

[titta]

Post by Marc Serafino
Confermo che Fastweb e' un'azienda di BARBONI che dice di vendere Internet
e invece anche ora che assegna un IP pubblico dinamico (come tutti gli
altri provider) continua a non concedere vero accesso ad Internet in quanto
le porte sono TUTTE chiuse in ingresso (tranne la 80 ovviamente). Ricordo
infatti che la corretta definizione di connessione ad Internet identifica
un nodo perfettamente raggiungibile da qualsiasi altro nodo della rete. E
con Fastweb, quei barboni di Fastweb, nonostante tutto non e' ancora cosi'.
Lo posso dire con certezza perche' esattamente OGGI mi hanno migrato sui
nuovi pool DPPU, probabilmente nel pomeriggio. In questo momento ci sono
due apparati connessi all'Hag e predisposti per andare su Internet,
entrambi gli apparati dispongono di un proprio IP pubblico dinamico
93.x.x.x (un pc e' connesso direttamente e il router della mia rete locale)
e entrambi gli IP pubblici dinamici univoci hanno TUTTE LE PORTE IN
INGRESSO BEN TAPPATE!!! VERGOGNA FASTWEB.
Posso aggiungere che gli IP della MAN non sono cambiati, sono quelli che ho
da anni, e che la mappatura di MACS per quanto mi riguarda almeno e'
sbagliata: il mio IP pubblico viene infatti da lui associato ad una
differente MAN rispetto a quella alla quale sono collegato io.
Ho provato a vedere se e' cambiato qualcosa anche per l'attivazione dell'IP
pubblico dinamico, ma con porte aperte (a questo punto e' solo questa la
differenza): non e' cambiato nulla, l'attivazione assegna un nuovo IP
questa volta si tratta di un 62.x.x.x proprio come prima della migrazione e
questa volta le porte sono ovviamente aperte (ma SI PAGA ANCHE!!! SI
PAGA?????????? CON GLI ALTRI PROVIDER L'IP PUBBLICO DINAMICO SENZA PORTE
CHIUSE E' PARTE DELL'ABBONAMENTO, INTERNET PREVEDE UN IP PUBBLICO CON LE
PORTE APERTE, come detto!)
FASTWEB SIETE PROPRIO DEI BARBONI PERCHE' ORA L'IP PUBBLICO LO POTETE DARE
COME FANNO TUTTI, NON C'E' PIU' LA SCUSA DEL NAT!!!
Ma nonostante tutto non lo date... E specie nei confronti di chi ha una
delle vostre pessime DSL e' una vera mancanza di riguardo considerando
anche quanto fate pagare l'abbonamento a regime!!!

Sono ancora in tanti quelli che non hanno capito che lavori per Fastweb,
soprattutto tra gli abbonati

[Macs]

Ciao

Post by Marc Serafino
entrambi gli apparati dispongono di un proprio IP pubblico dinamico
93.x.x.x

In pieno contrasto con i (seppur pochi) feedback multipli (cioe' inviati
da IP MAN della medesima utenza) finora ricevuti, che indicano NAT M-1
NO Overload per gli IP del singolo pool.

Non mi stupisco comunque piu' di tanto, vista la diversa provenienza
(come MAN/POP) dei dati = vi sarebbero infatti 2 possibili spiegazioni :
==
1. Errore/problema lato gestore NAT = possono accadere (ved. questioni
di riconoscimento della sessione e/o di bilanciamento) soprattutto in
una fase di avvio transitorio come quella attuale.

2. Test temporanei sul campo di configurazioni diverse, anche come
tipologia NAT, allo scopo p.es. di confrontare la risposta reale in
termini di carico sul POP tra NAT Many-to-One No Overload e NAT
Many-to-Many NO Overload.

Sinceramente non mi aspetterei a regime uno scenario NAT M-M NO Overload
in virtu' di alcune questioni tecniche ed anche della storia & del
modello di business FW, ma e' ovviamente ancora presto per delineare un
quadro preciso = dovremo attendere almeno che la migrazione si estenda a
piu' POP e soprattutto a MAN ancora non coinvolte.

Post by Marc Serafino
la mappatura di MACS per quanto mi riguarda almeno e' sbagliata: il
mio IP pubblico viene infatti da lui associato ad una differente MAN
rispetto a quella alla quale sono collegato io.

L'unica reale mappatura MAN/NAT verificata e' quella relativa ai pool
IPPU/NAT-R, che e' aggiornata al 12 Febbraio 2009 in base ai moduli
di sondaggio inviati da altri utenti negli ultimi anni. Sono appunto le
verifiche su tali moduli, che hanno portato alle seguenti pagine :
==
- http://plany.fasthosting.it/natpool.html
- http://plany.fasthosting.it/dbmap.asp?table=Mappatura


Non esiste invece (ancora) un'analoga mappatura per i pool DPPU proprio
per l'esiguo tempo trascorso dall'avvio della migrazione = i pochi
moduli ricevuti sulle nuove associazioni hanno finora confermato quelle
generiche DPPU->MAN/POP ricavate in base allo schema netname (cioe' il
medesimo della gestione dei pool IPPD e di quelli Small-Business), ma
cio' non e' sufficiente per avviare l'analisi di mappatura.

Tradotto in soldoni, visto che hai segnalato un'incongruenza su DPPU,
sarebbe utile se mandassi un modulo di feedback della mappatura o
perlomeno indicassi i riferimenti (nome netname o intervallo IP) del
pool che 'non torna' con http://plany.fasthosting.it/dppupool.html .

Ovviamente tale indicazione e' valida anche per altri, che dovessero
riscontrare situazioni analoghe di incongruenza nella tabella DPPU.

Post by Marc Serafino
Ho provato a vedere se e' cambiato qualcosa anche per l'attivazione
dell'IP pubblico dinamico, ma con porte aperte (a questo punto e' solo
questa la differenza): non e' cambiato nulla, l'attivazione assegna un
nuovo IP questa volta si tratta di un 62.x.x.x proprio come prima
della migrazione e questa volta le porte sono ovviamente aperte

Infatti, nonostante i recenti blackout del servizio, per il momento IPPD
non risulta coinvolto dalla migrazione DPPU.

[Conte Frobenius]

Post by Macs
Sinceramente non mi aspetterei a regime uno scenario NAT M-M NO Overload
in virtu' di alcune questioni tecniche ed anche della storia & del
modello di business FW, ma e' ovviamente ancora presto per delineare un
quadro preciso = dovremo attendere almeno che la migrazione si estenda a
piu' POP e soprattutto a MAN ancora non coinvolte.

Vedremo che succede. Sarà comunque difficile per Fastweb sostenere una
posizione commerciale di chiusura del traffico in ingresso una volta
completata la configurezione del NAT in modaltà 1:1.

[Cane Rabbioso]

Post by Macs
In pieno contrasto con i (seppur pochi) feedback multipli (cioe'
inviati da IP MAN della medesima utenza) finora ricevuti, che
indicano NAT M-1 NO Overload per gli IP del singolo pool.

[cut]

troppo complicato

[Macs]

Ciao

Post by Cane Rabbioso
troppo complicato

Prova a vederla in quest'altro modo :
==
A. NAT M-1 Overload = IP pubblici di uscita su Internet condivisi tra
piu' utenze MAN FW Residenziali/SOHO

B. NAT M-1 NO Overload = 1 IP pubblico univoco di uscita su Internet per
tutti gli IP riservati MAN di ogni utenza Residenziale/SOHO.

C. NAT M-M NO Overload = ad ogni IP riservato MAN viene associato in
sola uscita su Internet un IP pubblico univoco. Differisce dal NAT
1:1 Bidirezionale proprio perche' non vi sono regole di traduzione,
che inoltrino sull'IP MAN le connessioni autonome in ingresso da
Internet.


Lo scenario A e' quello che ha contraddistinto l'architettura base
delle connessioni Residenziali/SOHO sin dall'avvio dell'offerta FW. Lo
scopo primario della migrazione IPPU->DPPU e' quello di consentire
l'univocita' su Internet delle utenze Residenziali/SOHO FW, per cui a
regime (migrazione completata) tale scenario non dovra' esserci piu'.

Lo scenario B e' quello rilevato in associazione alla migrazione in
corso IPPU->DPPU, osservando i feedback privati/pubblici degli utenti
che hanno gia' avuto la variazione.

Lo scenario C e' quello riscontrato/segnalato ieri da Marc Serafino.


Sia B che C garantiscono l'univocita' dell'utenza su Internet, ma poi
differiscono in termini di gestione tecnica. Lo scenario C e' infatti
nettamente piu' "oneroso" in termini di gestione & disponibilita' degli
indirizzi IP pubblici utenza, per cui richiederebbe una serie di misure
ulteriori anche combinate, e.g.:
==
- Adeguamento del dimensionamento dei pool IP pubblici DPPU
- Ridefinizione delle policy di gestione delle sessioni NAT
- Variazione tecnica & contrattuale sul numero degli IP MAN utenza

Considerando tali aspetti ed il modello di business finora seguito da
FW (ved. anche IPPD come 'monetizzazione' della raggiungibilita' da
Internet), sarebbe piu' prevedibile a regime lo scenario B.

In ogni caso e' ancora presto per trarre un quadro preciso, proprio
perche' la migrazione e' lenta/graduale & in corso da neanche una
settimana = occorre attendere per capire meglio lo sviluppo seguito da
FW, alla luce anche di possibili variazioni (non escludibili a priori)
sul sistema IPPD.

[trip65]

Attualmente io riscontro (Milano fibra) lo scenario nat 1.1 , ovvero
continuo a mantenere gli ip 1.53.x.x con associazione all'ip pubblico
93.x.x.x che prevedo sia quello che verrà usato in virtu' anche dei servizi
iptv e telefonici e per mantenere la possibilità di assegnare 5 ip ai
clienti fibra.
Difatti continuo a rimanere connesso con i vecchi parametri (per ora).
Il nat 1:1 è unidirezionale , quindi iraggiungibilità dall'esterno.
Ippd è difatti ancora attivabile alle vecchie modalità ed è l'unico modo per
avere la bi-direzionalità.
Fastweb continua a sostenere che non è un problema di soldi e di
investimenti , ma di tempi tecnici . Attualmente , con la vecchia struttura
nat , non era in grado neanche di identificare l'utente poichè in virtu' di
un provvedimento del garante non puo' conservare i dati relativi relativi
all'ip di terminazione rendendo di fatto impossibile agli organi preposti
fare indagini.
Se l'autority gli permettesse di conservare gli ip di terminazione , avrebbe
già tutta la tecnolgia per identificare l'utente (mirava a questa soluzione)
anche con l'attuale struttura nat.
Con il nuovo sistema invece adempirebbe agli obblighi di legge e riuscirebbe
cmq a vendere ancora ippd .. Mi aspetto quindi che non apra il nat visto che
lo scopo di tutta questa operazione è garantire l'identificazione univoca
dell'utente.

[Marc Serafino]

Post by trip65
Con il nuovo sistema invece adempirebbe agli obblighi di legge e riuscirebbe
cmq a vendere ancora ippd .. Mi aspetto quindi che non apra il nat visto che
lo scopo di tutta questa operazione è garantire l'identificazione univoca
dell'utente.

Sei nella mia stessa situazione, e cntrariamente a quanto sostiene MACS
oggi ho sentito un sacco di altre persone che gia' sono come noi qui a
Milano e altri a Torino e Roma attestati sui nuovi IP pubblici e tutti con
l'opzione C indicata da MACS in seguito alle mie esperienze.

Io penso che come dice frobenus che per Fastweb diventerebbe insostenibile
motivare il fatto di non aprire le porte in ingresso in una situazione di
NAT 1:1 quando la cosa non comporta loro costi o problemi. Se non ci
arrivano da soli, possibile vista la grettezza del loro management, ci
pensera' qualche authority spero a costringerli.

[Macs]

Ciao

Post by Marc Serafino
oggi ho sentito un sacco di altre persone che gia' sono come noi qui a
Milano e altri a Torino e Roma attestati sui nuovi IP pubblici e tutti
con l'opzione C indicata da MACS in seguito alle mie esperienze.

MAN e POP differenti = scenari diversi in corso, e non si tratta di una
mia opinione/convinzione personale, bensi' dell'osservazione (anche) dei
moduli di feedback mappatura, che sono pervenuti in questi giorni.

Questo e' p.es. un estratto dei moduli pervenuti a partire da lunedi
(ultimo ottetto IP MAN mascherato) ordinati cronologicamente a partire
dal piu' recente (in modo anche da evidenziare il passaggio IPPU->DPPU
per una subnet /24 fibra sulla MAN di Genova) :
==
************************************************************************
27.236.103.* - . - 93.46.193.238 - POP-2701-DPPU-04 -> check OK
23.217.90.* - . - 85.18.66.23 - 2303-IPPU-34-F5 rank 8 -> check OK
1.238.87.* - . - 62.101.93.181 - 0101-IPPU-35-F6 rank 6 -> check OK
39.3.245.* - . - 85.18.14.28 - 2303-IPPU-32-F4 rank 13 -> check OK
28.232.16.* - . - 62.101.93.167 - 0101-IPPU-34-F6 rank 8 -> check OK
5.254.119.* - 2 - 93.32.215.81 - POP-0502-DPPU-02 -> check OK
5.8.116.* - . - 93.37.19.226 - POP-0504-DPPU-03 -> check OK
39.8.42.* - 2 - 93.44.96.27 - POP-3902-DPPU-08 -> check OK
39.237.137.* - . - 85.18.219.231 - 2303-IPPU-35-F5 rank 8 -> check OK
23.229.17.* - . - 89.97.21.216 - 2303-IPPU-31-F8 rank 9 -> check OK
1.241.231.* - . - 93.32.113.107 - POP-0114-DPPU-01 -> check OK
5.8.116.* - . - 81.208.106.67 - 0101-IPPU-32-F5 rank 4 -> check OK
28.239.74.* - . - 213.156.48.103 - 0101-IPPU-35-F4 rank 8 -> check OK
39.234.90.* - . - 83.103.90.52 - 2303-IPPU-34-F8 rank 5 -> check OK
1.243.134.* - . - 93.32.172.227 - POP-0114-DPPU-04 -> check OK
5.255.222.* - . - 93.32.210.223 - POP-0502-DPPU-02 -> check OK
23.232.140.* - . - 83.103.90.48 - 2303-IPPU-34-F8 rank 1 -> check OK
2.244.121.* - . - 89.96.14.255 - 0101-IPPU-31-F6 rank 16 -> check OK
23.227.11.* - . - 93.40.140.50 - POP-2304-DPPU-03 -> check OK
22.243.17.* - . - 85.18.227.209 - 2303-IPPU-31-F6 -> check OK
23.252.152.* - . - 93.40.132.184 - POP-2304-DPPU-03 -> check OK
23.236.30.* - . - 89.97.35.64 - 2303-IPPU-34-F6 rank 1 -> check OK
31.239.66.* - . - 83.103.39.114 - 2303-IPPU-35-F8 rank 3 -> check OK
29.230.33.* - . - 81.208.106.72 - 0101-IPPU-32-F5 rank 9 -> check OK
29.238.22.* - . - 213.156.52.137 - 0101-IPPU-34-F8 rank 10 -> check OK
27.237.7.* - . - 85.18.136.72 - 2303-IPPU-31-F5 rank 9 -> check OK
28.226.115.* - . - 213.140.6.127 - 0101-IPPU-33-F5 rank 16 -> check OK
27.239.52.* - . - 213.140.21.232 - 2303-IPPU-33-F4 rank 9 -> check OK
************************************************************************

Le voci contrassegnate con - 2 - corrispondono a moduli inviati a pochi
minuti di distanza dalla medesima utenza, che riportano il medesimo IP
pubblico di uscita su DPPU associato pero' a 2 IP MAN distinti del
proprio pool = questo indica NAT M-1 NO Overload.

Come vedi, i moduli non sono ancora sufficienti per delineare con
precisione le modalita' definitive di variazione tipologia NAT (M-1 NO
Overload, M-M NO Overload o - 'magari' a regime - NAT 1:1 Bidirezionale)
ne' fornire stime sul grado di avanzamento della migrazione.

Le informazioni sono ancora poche, comprese quelle sugli effetti della
migrazione nella navigazione delle utenze a consumo = vedasi questione
dell'accesso senza autenticazione manuale a risorse esterne su Internet
(in green park a causa di appositi accordi o meno).


Per il resto, i check OK corrispondono alla conformita' dei dati con
le tabelle generali di associazione IPPU e DPPU :
==
-
http://plany.fasthosting.it/dbmap.asp?sort=IDasc&pagesize=all&strKeyWords=&mode=&table=IPPU

-
http://plany.fasthosting.it/dbmap.asp?sort=IDasc&pagesize=all&strKeyWords=&mode=&table=DPPU

Non mi risultano finora incongruenze sugli schemi generali ma, visto che
ne avevi segnalata una nel tuo precedente messaggio in merito al pool
DPPU di riferimento dei tuoi IP di uscita, sarebbe utile che indicassi
i relativi riferimenti (netname o intervallo IP) onde fare le verifiche
del caso.

Post by Marc Serafino
Io penso che come dice frobenus che per Fastweb diventerebbe
insostenibile motivare il fatto di non aprire le porte in ingresso in
una situazione di NAT 1:1 quando la cosa non comporta loro costi o
problemi.

Un passaggio da IPPU Hidden/Dynamic NAT M-1 Overload ad un eventuale
DPPU NAT 1:1 bidirezionale a regime sarebbe ovviamente piu' che gradito
dagli utenti residenziali/SOHO FW.

Cio' richiederebbe tuttavia che prima fosse tecnicamente sostenibile a
regime uno scenario NAT M-M NO Overload... e questo non possiamo saperlo
ancora in base allo status attuale (ved. numero di POP migrati e policy
di dimensionamento/gestione delle risorse IP) = a differenza di FW non
disponiamo di tutte le informazioni sul processo.

Per ora possiamo solo limitarci ad osservare le variazioni, confrontando
eventualmente alcuni fattori di linea con la situazione IPPU precedente
(vedansi p.es. prestazioni della velocita' di navigazione su Internet in
DL/UL e latenza delle connessioni).

[Marc Serafino]

Post by Macs

Post by Marc Serafino
Io penso che come dice frobenus che per Fastweb diventerebbe
insostenibile motivare il fatto di non aprire le porte in ingresso in
una situazione di NAT 1:1 quando la cosa non comporta loro costi o
problemi.

Un passaggio da IPPU Hidden/Dynamic NAT M-1 Overload ad un eventuale
DPPU NAT 1:1 bidirezionale a regime sarebbe ovviamente piu' che gradito
dagli utenti residenziali/SOHO FW.

Io trovo che sarebbe DOVEROSO da parte di Fastweb.

Post by Macs
Cio' richiederebbe tuttavia che prima fosse tecnicamente sostenibile a
regime uno scenario NAT M-M NO Overload... e questo non possiamo saperlo
ancora in base allo status attuale (ved. numero di POP migrati e policy
di dimensionamento/gestione delle risorse IP) = a differenza di FW non
disponiamo di tutte le informazioni sul processo.

Se non e' sostenibile (e secondo me lo e' eccome) si attrezzano perche' lo
sia: prendono qualche IP in piu' che come vedi anche la scusa da loro
sempre utilizzata relativa alla carenza di indirizzi (assolutamente FALSA)
ora e' stata risolto in un battibaleno perche' temevano una sonora multa se
non si adeguavano alle disposizioni. Insomma questi sono sempre i soliti
furboni anzi meglio, barboni.

Post by Macs
Per ora possiamo solo limitarci ad osservare le variazioni, confrontando
eventualmente alcuni fattori di linea con la situazione IPPU precedente
(vedansi p.es. prestazioni della velocita' di navigazione su Internet in
DL/UL e latenza delle connessioni).

Sotto questo punto di vista piu' o meno e' cambiato poco: la vera
differenza la farebbe il NAT 1:1. Diversamente resta la solita, ignobile
porcata firmata Fastweb.

[trip65]

Post by Macs
Le voci contrassegnate con - 2 - corrispondono a moduli inviati a pochi
minuti di distanza dalla medesima utenza, che riportano il medesimo IP
pubblico di uscita su DPPU associato pero' a 2 IP MAN distinti del
proprio pool = questo indica NAT M-1 NO Overload.

- Plany/MACS -<|> *FAQ GCN http://faq.news.nic.it/ ____<|

Nel mio caso , confermo che ad ogni device collegato alla cpe viene
associato un ippu diverso in nat 1:1 sugli ip della man Milano . Prima
sostenevano di non avere ip , adesso si "sciala" ? :)

[Marc Serafino]

Post by Macs

Post by Macs
Le voci contrassegnate con - 2 - corrispondono a moduli inviati a pochi
minuti di distanza dalla medesima utenza, che riportano il medesimo IP
pubblico di uscita su DPPU associato pero' a 2 IP MAN distinti del
proprio pool = questo indica NAT M-1 NO Overload.

- Plany/MACS -<|> *FAQ GCN http://faq.news.nic.it/ ____<|
Nel mio caso , confermo che ad ogni device collegato alla cpe viene
associato un ippu diverso in nat 1:1 sugli ip della man Milano . Prima
sostenevano di non avere ip , adesso si "sciala" ? :)

Vero anche io sono arrivato ad avere un IP pubblico per ogni apparato fino
ad un massimo di cinque. Attenzione pero': credo che anche nel tuo caso il
NAT 1:1 abbia le porte rigorsamente chiuse in ingresso.

[trip65]

Post by Marc Serafino
Vero anche io sono arrivato ad avere un IP pubblico per ogni apparato fino
ad un massimo di cinque. Attenzione pero': credo che anche nel tuo caso il
NAT 1:1 abbia le porte rigorsamente chiuse in ingresso.

Chiusissime , non rispondono manco agli ICMP provenienti dal'esterno , una
blindatura completa .
Ci sono comunque lavori in corso , ieri pomeriggio il mio telefono voip
eutelia attestato su fibra fastweb non funzionava correttamente , poi si è
sistemato.
Come se ci fossero problemi di port-mapping, ci mancherebbe che smettesse di
funzionare li mando a ranare con 3 mesi di anticipo :)

[MarcoGE]

ieri pomeriggio il mio telefono voip eutelia attestato su fibra fastweb non
funzionava correttamente

Ecco, io ho un problema: misteriosamente, dalle modifiche fastweb, il
mio PAP2 configurato Eutelia funziona correttemente *solo* se setto
entrambe le linee sulla medesima porta 5062... Com'è possibile?

Me ne sono accorto per caso: prima erano una sulla 5060 e una sulla
5061; quella sulla 5061 funzionava correttamente, ma la prima sebbene
apparentementa a posto non riceveva nè effettuava chiamate :-O

[Trip65]

Post by MarcoGE

ieri pomeriggio il mio telefono voip eutelia attestato su fibra
fastweb non funzionava correttamente

Ecco, io ho un problema: misteriosamente, dalle modifiche fastweb, il
mio PAP2 configurato Eutelia funziona correttemente *solo* se setto
entrambe le linee sulla medesima porta 5062... Com'è possibile?
Me ne sono accorto per caso: prima erano una sulla 5060 e una sulla
5061; quella sulla 5061 funzionava correttamente, ma la prima sebbene
apparentementa a posto non riceveva nè effettuava chiamate :-O

I problemi di euteliavoip da venerdi' scorso sono sulle chiamate in
uscita che sono mute ma riguardano eutelia, difatti pare non instradi su
rete fissa. Solo ora pare abbiano ripreso.
Il fenomeno c'è sia da rete fastweb che wind che qualsiasi isp che io
abbia provato . Speriamo siano cessati i disservizi c'era un po' di
gente alterata ..

[MarcoGE]

Il fenomeno c'è sia da rete fastweb che wind che qualsiasi isp che io abbia
provato . Speriamo siano cessati i disservizi c'era un po' di gente alterata
..

Tu hai un ata? usi le solite 5060/5061 ?

[trip65]

Post by MarcoGE

Post by Trip65
Il fenomeno c'è sia da rete fastweb che wind che qualsiasi isp che io
abbia provato . Speriamo siano cessati i disservizi c'era un po' di gente
alterata ..

Tu hai un ata? usi le solite 5060/5061 ?

No , ho un ip301 voip con un numero e un cellulare nokia della serie e con
wi-fi e account sip integrati.per l'altro account. Non uso tali porte vado
di server stun anche perchè mi ri-natto . Poi la stessa cfg la uso sia a
Milano con fastweb che qui con altro carrier e con lo stun mi evito di
ri-configurare i telefoni .
Oggi il servizio è regolare.

[Marc Serafino]

Post by trip65

Post by Marc Serafino
Vero anche io sono arrivato ad avere un IP pubblico per ogni apparato fino
ad un massimo di cinque. Attenzione pero': credo che anche nel tuo caso il
NAT 1:1 abbia le porte rigorsamente chiuse in ingresso.

Chiusissime , non rispondono manco agli ICMP provenienti dal'esterno , una
blindatura completa .
Ci sono comunque lavori in corso , ieri pomeriggio il mio telefono voip
eutelia attestato su fibra fastweb non funzionava correttamente , poi si è
sistemato.
Come se ci fossero problemi di port-mapping, ci mancherebbe che smettesse di
funzionare li mando a ranare con 3 mesi di anticipo :)

Trip mi aspetto da te la stessa coerenza che avrei io: NO FIBRA NO FASTWEB!
Mi raccomando!

[MarcoGE]

Nel mio caso , confermo che ad ogni device collegato alla cpe viene associato
un ippu diverso in nat 1:1 sugli ip della man Milano .

Vero, MAN di GE

[Marc Serafino]

Post by Macs
C. NAT M-M NO Overload = ad ogni IP riservato MAN viene associato in
sola uscita su Internet un IP pubblico univoco. Differisce dal NAT
1:1 Bidirezionale proprio perche' non vi sono regole di traduzione,
che inoltrino sull'IP MAN le connessioni autonome in ingresso da
Internet.
Lo scenario C e' quello riscontrato/segnalato ieri da Marc Serafino.

Eatto. Devo dire che l'IP pubblico dinamico e' effettivamente dinamico
poiche' per esempio ora su uno dei due apparati ho un IP pubblico diverso
(quello del dispositivo che ho spento, mentre quello che e' acceso da ieri
non ha cambiato l'IP pubblico dinamico).

Vediamo cosa faranno questi barboni :-((((

[Blak]

Post by Macs
Considerando tali aspetti ed il modello di business finora seguito da
FW (ved. anche IPPD come 'monetizzazione' della raggiungibilita' da
Internet),

Infatti, è uno dei motivi per cui non offriranno NAT 1:1.

[trip65]

Post by Blak

Post by Macs
Considerando tali aspetti ed il modello di business finora seguito da
FW (ved. anche IPPD come 'monetizzazione' della raggiungibilita' da
Internet),

Infatti, è uno dei motivi per cui non offriranno NAT 1:1.

La giustificazione prima era che non c'erano ip , poi motivi di sicurezza ,
poi questioni di architettura :adesso devono chiaramente dire che è per
motivi di lucro.
Non puo' essere difatti una feature a valore aggiunto datosi che è offerta
da tutti gratis , che diavolo si inventereanno ?
Che quando attivi IPPD a pagamento garantiscono prestazioni superiori agli
altri a banda garantita ??
I nodi vengono tutti al pettine prima o poi è inutile continuare con
fesserie "tecniche"

[Blak]

Post by trip65
La giustificazione prima era che non c'erano ip , poi motivi di sicurezza ,
poi questioni di architettura :adesso devono chiaramente dire che è per
motivi di lucro.
Non puo' essere difatti una feature a valore aggiunto datosi che è offerta
da tutti gratis , che diavolo si inventereanno ?
Che quando attivi IPPD a pagamento garantiscono prestazioni superiori agli
altri a banda garantita ??
I nodi vengono tutti al pettine prima o poi è inutile continuare con
fesserie "tecniche"

Un'associazione statica 1:1 tra IP di NAT e IP interno è effettivamente
irrealizzabile ora, Fastweb dovrebbe, credo certamente, richiedere una
nuova allocazione al RIPE. Tra l'altro è comprensibilmente inefficiente,
trascurando il problema della realizzazione.
Le alternative sono quelle già indicate da Macs, ovvero, seguendo la sua
nomenclatura, NAT M-1 No Overload che comporta necessariamente
l'irraggiungibilità dall'esterno oppure NAT M-M No Overload. Bisogna
sottolineare che la prima non è propriamente paragonabile all'offerta degli
altri ISP dove sei libero di configurare autonomamente il NAT. Con la
seconda la bidirezionalità è possibile, ma concessa? Staremo a vedere, ma
di sicuro questa migrazione non è frutto della spontanea volontà di Fastweb
di cambiare quindi dubito. Se a questo aggiungiamo ciò che dici è evidente
come la scelta sia politica e non di natura tecnica.

[Marc Serafino]

Post by Blak

Post by trip65
La giustificazione prima era che non c'erano ip , poi motivi di sicurezza ,
poi questioni di architettura :adesso devono chiaramente dire che è per
motivi di lucro.
Non puo' essere difatti una feature a valore aggiunto datosi che è offerta
da tutti gratis , che diavolo si inventereanno ?
Che quando attivi IPPD a pagamento garantiscono prestazioni superiori agli
altri a banda garantita ??
I nodi vengono tutti al pettine prima o poi è inutile continuare con
fesserie "tecniche"

Un'associazione statica 1:1 tra IP di NAT e IP interno è effettivamente
irrealizzabile ora, Fastweb dovrebbe, credo certamente, richiedere una
nuova allocazione al RIPE.

L'ha gia' richiesta. Attualmente Fastweb dispone di circa un milione di IP
pubblici che va ad assegnare dinamicamente.

Post by Blak
trascurando il problema della realizzazione.

Realizzato e' gia' stato realizzato. Basta solo aprire le porte dell'utente
sui router dei mini pop e dei palazzi. Tutto molto semplice ora.

Post by Blak
Staremo a vedere, ma
di sicuro questa migrazione non è frutto della spontanea volontà di Fastweb
di cambiare quindi dubito. Se a questo aggiungiamo ciò che dici è evidente
come la scelta sia politica e non di natura tecnica.

Come dicono anche frobenus e trip, questa volta sara' dura inventarsi
scuse.

[MarcoGE]

Post by Marc Serafino
Come dicono anche frobenus e trip, questa volta sara' dura inventarsi
scuse.

Sai cosa temo? Che come altre aziende in altri ambiti, non inventerà
proprio scuse. sarà così. Stop :-(

[Blak]

Post by Macs
Ciao

Ciao

Post by Macs

Post by Marc Serafino
entrambi gli apparati dispongono di un proprio IP pubblico dinamico
93.x.x.x

In pieno contrasto con i (seppur pochi) feedback multipli (cioe' inviati
da IP MAN della medesima utenza) finora ricevuti, che indicano NAT M-1
NO Overload per gli IP del singolo pool.

Anche io devo "smentire", ho due macchine accese con due diversi IP di NAT
(migrato qualche giorno fa, Genova).

Post by Macs
Non esiste invece (ancora) un'analoga mappatura per i pool DPPU proprio
per l'esiguo tempo trascorso dall'avvio della migrazione = i pochi
moduli ricevuti sulle nuove associazioni

provvedo subito :)

Post by Macs
Tradotto in soldoni, visto che hai segnalato un'incongruenza su DPPU,
sarebbe utile se mandassi un modulo di feedback della mappatura o
perlomeno indicassi i riferimenti (nome netname o intervallo IP) del
pool che 'non torna' con http://plany.fasthosting.it/dppupool.html .

Non ricordo gli IP dei giorni precedenti ma, come oggi, mi sembra fossero
tutti nel range 93.37.32.0/20 (ma non ci metterei la mano sul fuoco, terrò
d'occhio in questi giorni) con pool interno nella rete 5.255.56.0/21.

[Blak]

Post by Blak
Non ricordo gli IP dei giorni precedenti ma, come oggi, mi sembra fossero
tutti nel range 93.37.32.0/20 (ma non ci metterei la mano sul fuoco, terrò
d'occhio in questi giorni) con pool interno nella rete 5.255.56.0/21.

Mi autosmentisco, 3 macchine accese su 3 e:
- 93.37.48.114
- 93.37.38.218
- 93.37.40.251

Una cosa certa invece: sempre e solo indirizzi 93.37.*.*

[Macs]

Ciao

Post by Blak

Post by Blak
Non ricordo gli IP dei giorni precedenti ma, come oggi, mi sembra
fossero tutti nel range 93.37.32.0/20 (ma non ci metterei la mano sul
fuoco, terrò d'occhio in questi giorni) con pool interno nella rete
5.255.56.0/21.

- 93.37.48.114
- 93.37.38.218
- 93.37.40.251

Grazie in primis per i feedback ;) = tornano decisamente utili a questo
punto come ulteriore conferma dell'estensione dello scenario NAT M-M NO
Overload (ed infatti ho provveduto ad aggiornare in tal senso la pagina
sui pool DPPU).

Inoltre servono per porre le basi di una mappatura DPPU meno generica.
In base ai dati da te riportati risultano infatti :
==
- Pool DPPU = POP-0504-DPPU-05 93.37.48.0/20 (IP NAT M-M N-O PC1)
POP-0504-DPPU-04 93.37.32.0/20 (IP NAT M-M N-O PC2 e PC3)

- SGU TI = Genova - Nervi / IP MAN Range 5.255.56.0/21

Per quanto riguarda invece l'identificazione del POP di riferimento
attendero' di avere un numero maggiore di moduli d'associazione DPPU
dalla MAN di Genova = il POP-0504 potrebbe corrispondere al POP FW di
riferimento su Boccadasse, ma e' un dato che deve essere verificato.

[Blak]

Post by Macs
Ciao

Ciao

Post by Macs
Grazie in primis per i feedback ;)

Figurati... anzi, sono ancora in debito per l'aiuto con ekiga. ;-)

Post by Macs
- SGU TI = Genova - Nervi / IP MAN Range 5.255.56.0/21

Anni fa un conoscente che all'epoca lavorava per Fastweb mi diede qualche
informazione sul mio contratto e ti posso dire che sono attestato alla SGU
di via Manunzio, mentre il dslam (se non è cambiato) ha nome
ge-gavette-dslmnz.... anche se non trovo conferma nella mappa sul tuo sito.
Per quanto riguarda l'SGU Manunzio sono piuttosto sicuro mentre di gavette
non so nulla.

Post by Macs
Per quanto riguarda invece l'identificazione del POP di riferimento
attendero' di avere un numero maggiore di moduli d'associazione DPPU
dalla MAN di Genova = il POP-0504 potrebbe corrispondere al POP FW di
riferimento su Boccadasse, ma e' un dato che deve essere verificato.

Attualmente non ho novità da darti ma terrò d'occhio gli IP.

Piccola considerazione estemporanea.
Stavo pensando a quello che potrebbe essere il futuro di fastweb e credo ci
sia una cosa da tenere in considerazione, ossia il fatto che nel giro di
2-4 anni prima IANA e poi i RIR allocheranno le ultime reti disponibili. Il
che significa quanto meno dover rinumerare, ma come? Tornare alle classi
private mi sembra poco sensato e macchinoso; l'unica alternativa è fornire
IP pubblico, anche perché per questioni di retrocompatibilità dovrà fornire
connettivà IPv4 ancora per molti anni (e una soluzione definitiva sarebbe
auspicabile anche per loro credo). Per altro contestualmente dovranno
iniziare il deployment di connettività IPv6 e anche qui la soluzione basata
su tunnel, seppur adatta per dei test, non va poi troppo bene a lungo
termine (sviluppare fin da subito una buona architettura nuova e scalabile
è conveniente). In ogni caso oggi potrebbero iniziare a fornire un IP
pubblico, seppur dinamico e filtrato, per ogni IP privato, un domani
potrebbero continuare a farlo togliendo di mezzo le attuali classi ad uso
interno non ancora allocate dai RIR. Per altro ora di IP ne hanno e
potrebbero averne altri senza troppi problemi, almeno fino a quando ne
rimarranno ancora un po'. Allo stesso tempo con IPv6, indipendentemente dal
voler filtrare porte/traffico, non avrebbe alcun senso non fornire almeno
un IP per ogni macchina/device dei propri clienti. Insomma, probabilmente
qualcosa cambierà ancora nel giro dei prossimi mesi o anni, forse questo è
l'inizio?

[Marc Serafino]

Post by Blak
Stavo pensando a quello che potrebbe essere il futuro di fastweb e credo ci
sia una cosa da tenere in considerazione, ossia il fatto che nel giro di
2-4 anni prima IANA e poi i RIR allocheranno le ultime reti disponibili. Il
che significa quanto meno dover rinumerare, ma come? Tornare alle classi
private mi sembra poco sensato e macchinoso

E' quello che faranno. E non e' macchinoso per nulla: a loro la rete
interna serve per esempio per distribuire televisione.

Post by Blak
Insomma, probabilmente
qualcosa cambierà ancora nel giro dei prossimi mesi o anni, forse questo è
l'inizio?

Questa piu' che l'inizio e' stata una rivoluzione: costringere Fastweb a
comprare un milioni di indirizzi IP e distribuirli univocamente ai propri
clienti. E l'hanno fatto solo perche' costretti dalle autorita', la
politica aziendale e' a mio avviso troppo gretta per valutare altre
possibilita'.

[Conte Frobenius]

Post by Marc Serafino
costringere Fastweb a
comprare un milioni di indirizzi IP e distribuirli univocamente ai
propri clienti.

Gli IP non si comprano: sono gratuiti.

[Macs]

Ciao

ti posso dire che sono attestato alla SGU di via Manunzio, mentre il
dslam (se non è cambiato) ha nome ge-gavette-dslmnz.... anche se non
trovo conferma nella mappa sul tuo sito.

A me risultava invece il range successivo 5.255.64.0/21 (cioe' con IP da
5.255.64.0 a 5.255.71.255) associato alla SGU Manuzio, centrale che in
effetti e' interconnessa direttamente tramite la rete fibra FW al POP
Gavette.

Tuttavia, visto che tali info derivano dalle associazioni delle prime
linee ADSL attivate da FW, sarebbe ideale una controverifica, onde
correggere eventualmente i dati = lo schema di provisioning/assegnazione
degli IP sulle linee ADSL e' successivamente mutato sia per l'aggiunta
di nuove centrali SGU che per condizioni di aggiunta/ricambio utenze.

Ti chiederei quindi quando ti fosse possibile di controllare la SGU su :
==
https://intra.eutelia.it/cgi-bin/wbc_slbverificacoperturaservizialargabandawhs
[*]

[*]Qualora ti indicasse numerazione sconosciuta (come avviene con numeri
nativi FW ed alcuni TI portati), basterebbe inserire una numerazione
Telecom relativa al medesimo indirizzo (nota o reperita tramite le
Pagine Bianche http://www.paginebianche.it/execute.cgi?&ts=105 ).

Piccola considerazione estemporanea.
Stavo pensando a quello che potrebbe essere il futuro di fastweb

[...]

qualcosa cambierà ancora nel giro dei prossimi mesi o anni, forse
questo è l'inizio?

Sicuramente piu' cose - finche' FW continuera' ad operare - dovranno
cambiare nel lungo periodo per le questioni che hai indicato ed altre
(ved. evoluzione tecnica/commerciale del mercato xDSL), ma il passaggio
IPPU->DPPU resta comunque l'effetto di esigenze a breve termine.

La migrazione che porto' all'architettura IPPU fu conseguenza di scelte
aziendali precise in un dato periodo temporale, che erano motivate dal
modello di business FW.

Il renumbering della MAN di Torino e quest'ultima migrazione sono
invece esempi di interventi FW, che sono stati motivati da disposizioni
esterne = l'assegnazione ad AfriNIC del range 41/8 e le normative EU/ITA
sulla fornitura di servizi di comunicazione elettronica.

Sono infatti interventi disgiunti & di reazione/risposta, come e' anche
evidente dal ritardo nell'avvio di tali processi rispetto alla comparsa
delle variazioni esterne.


Indipendentemente dall'esito della migrazione in corso IPPU->DPPU (NAT
M-M NO Overload, NAT 1:1, ...), vediamo gia' che FW ha deciso comunque
di mantenere un'architettura NAT-ted in associazione agli IP MAN, cioe'
BOGON IP riservati dallo IANA.

Se infatti FW avesse gia' dovuto e/o voluto fornire IP pubblici dinamici
senza NAT per connettivita' diretta punto-punto ad Internet in
abbinamento ad IP privati RFC-1918 per servizi VoIP/Video su MAN (stile
quanto fatto da Telecom e Tiscali), non sarebbe mancato comunque il
tempo per definirne tecnicamente i meccanismi = considera in merito
anche il periodo temporale della richiesta al RIPE & dell'assegnazione
dei 2097152 IP associati al range 93.32/11 .


Tradotto in soldoni, da un lato c'e' il modello business telco (cioe' FW
punta sui *servizi* che puo erogare sulla rete in funzione praticamente
esclusiva del solo costo addebitabile agli utenti) e dall'altro ci sono
le variazioni esterne +/- previste.

FW sa bene che prima o poi dovra' intervenire nuovamente a livello di
indirizzamento diretto utenze Residenziali/SOHO (renumbering MAN, etc.),
ma lo fara' solo quando realmente vincolata a farlo.

Per altro contestualmente dovranno iniziare il deployment di
connettività IPv6 e anche qui la soluzione basata su tunnel, seppur
adatta per dei test, non va poi troppo bene a lungo termine

Per IPv6 vale il medesimo discorso fatto sopra sulle evoluzioni IPv4. Le
considerazioni in merito sono ancora quelle, che avevamo esaminato a
suo tempo proprio nel thread in cui avevi esposto la questione relativa
allo STUN server Ekiga su rete pubblica FW :
==
Newsgroups ..: it.tlc.gestori.fastweb
Subject .....: Fastweb filtra SIP?
Date ........: Tue, 14 Oct 2008
GoogleGroups : http://tinyurl.com/d57hxs
==
e dove avevamo anche confrontato le possibilita' di transizione IPv4/v6
tra tunnel-broker (test/sperimentazione stile quella TI) e traduzione
V4/V6 (implementazione globale in ambito produzione mediante SIIT +
NAT/NAPT V4/V6 + DNSALG).

[Blak]

Post by Macs
Ciao

Ciao

Post by Macs

ti posso dire che sono attestato alla SGU di via Manunzio, mentre il
dslam (se non è cambiato) ha nome ge-gavette-dslmnz.... anche se non
trovo conferma nella mappa sul tuo sito.

A me risultava invece il range successivo 5.255.64.0/21 (cioe' con IP da
5.255.64.0 a 5.255.71.255) associato alla SGU Manuzio, centrale che in
effetti e' interconnessa direttamente tramite la rete fibra FW al POP
Gavette.

Ma il mio a quale gruppo ti risulta essere associato? Premesso che abito in
San Fruttuoso, vedo San Fruttuoso 5.254.48.* e poi Manuzio con il range da
te citato. Il più vicino alla mia abitazione è (a meno di giri strani a me
non noti) è quello di via S. Fruttuoso (ma davvero c'è?), ma anche Manuzio
è sotto i due km, quindi papabile.

Post by Macs
==
https://intra.eutelia.it/cgi-bin/wbc_slbverificacoperturaservizialargabandawhs

Avevo già controllato tempo fa con un paio di numeri di alcuni vicini e
confermo anche ora che appare Manuzio.
Considera che, se non ricordo male, sono cliente FW da fine 2002.

Post by Macs

qualcosa cambierà ancora nel giro dei prossimi mesi o anni, forse
questo è l'inizio?

Sicuramente piu' cose - finche' FW continuera' ad operare - dovranno
cambiare nel lungo periodo per le questioni che hai indicato ed altre
(ved. evoluzione tecnica/commerciale del mercato xDSL), ma il passaggio
IPPU->DPPU resta comunque l'effetto di esigenze a breve termine.

Indubbiamente, però oggi potrebbe essere una soluzione contingente ma tra
un anno o due una ristrutturazione vera e propria. Ma bisognerebbe
conoscere qualcosa di più dall'interno.

Post by Macs
Il renumbering della MAN di Torino e quest'ultima migrazione sono
invece esempi di interventi FW, che sono stati motivati da disposizioni
esterne = l'assegnazione ad AfriNIC del range 41/8 e le normative EU/ITA
sulla fornitura di servizi di comunicazione elettronica.
Sono infatti interventi disgiunti & di reazione/risposta, come e' anche
evidente dal ritardo nell'avvio di tali processi rispetto alla comparsa
delle variazioni esterne.

Ho già commentato sarcasticamente questo aspetto ;-)
Però le rinumerazioni dovranno avvenire, prima o poi, mettere una pezza
ogni volta non è proprio il massimo soprattutto quando comunque avrai
sempre meno IP su cui spostarti. Filtrare senza un'architettura a NAT è
possibile, offrire bidirezionalità a pagamento anche, ed è compatibile con
il loro modello di business. Il dover smantellare l'attuale sistema è solo
questione di tempo ed è per altro una necessità tecnica insindacabile,
quindi dovranno semmai correggere le politiche aziendali.
Il nocciolo della questione è la tempistica, ma temo di dover concordare
con te che probabilmente non faranno nulla per accellerare il cambiamento,
anzi, aspetteranno anche più del necessario. Mi chedevo però se ci fosse
una piccola speranza che non sia così e che questo sia appunto l'inizio di
un cambiamento più radicale.

Post by Macs
Indipendentemente dall'esito della migrazione in corso IPPU->DPPU (NAT
M-M NO Overload, NAT 1:1, ...), vediamo gia' che FW ha deciso comunque
di mantenere un'architettura NAT-ted in associazione agli IP MAN, cioe'
BOGON IP riservati dallo IANA.

A proposito, oggi due macchine su POP-0504-DPPU-5 e una su POP-0504-DPPU-4.
Per ora sembro uscire solo con questi due pool, se dovesse cambiare
qualcosa ti riferisco.

Post by Macs
Se infatti FW avesse gia' dovuto e/o voluto fornire IP pubblici dinamici
senza NAT per connettivita' diretta punto-punto ad Internet in
abbinamento ad IP privati RFC-1918 per servizi VoIP/Video su MAN (stile
quanto fatto da Telecom e Tiscali), non sarebbe mancato comunque il
tempo per definirne tecnicamente i meccanismi = considera in merito
anche il periodo temporale della richiesta al RIPE & dell'assegnazione
dei 2097152 IP associati al range 93.32/11 .

Vero...

Post by Macs
Per IPv6 vale il medesimo discorso fatto sopra sulle evoluzioni IPv4. Le
considerazioni in merito sono ancora quelle, che avevamo esaminato a
suo tempo proprio nel thread in cui avevi esposto la questione relativa

Si ricordo :)
Grazie come sempre,
Ciao

[Macs]

Ciao

abito in San Fruttuoso, vedo San Fruttuoso 5.254.48.* e poi Manuzio
con il range da te citato. Il più vicino alla mia abitazione è (a meno
di giri strani a me non noti) è quello di via S. Fruttuoso (ma davvero
c'è?), ma anche Manuzio è sotto i due km, quindi papabile.

Nell'ultima versione della mappatura (aggiornamento 12-02-2009) ho
volutamente rimosso i riferimenti alle SGU, proprio per le variazioni da
parte di FW nelle policy di assegnazione/provisioning rispetto agli
schemi iniziali sulla carta.

Quando pertanto compare p.es. l'indicazione Genova - San Fruttuoso,
piuttosto che Genova - Sampierdarena, cio' non significa che esista una
SGU con tal nome = semplicemente tale e' un'informazione aggiuntiva, che
l'utente ha inserito prima di inviare il modulo di feedback.


Per quanto riguarda nello specifico San Fruttuoso, ho ricavato questa
pagina di copertura (che richiede la connessione ad Internet per le
utenze a consumo) su :
==
- http://plany.fasthosting.it/test/manuzio.htm
==
approfittando del prolungamento (purtroppo) necessario dei test privati
sull'Area Speed Estimator -> la geolocalizzazione degli indirizzi/civici
richiede ancora alcuni ritocchi (ed e' infatti una causa del ritardo nel
rilascio), ma sono visibili tutti gli armadi ripartitori collegati alla
centrale SGU Manuzio.

Non conosco bene Genova, ma - cartina alla mano - mi pare che la SGU in
questione copra l'intera area di San Fruttuoso. Vi sono sovrapposizioni
di servizio con SGU vicine, ma riguardano indirizzi/civici di confine
(p.es. alcuni civici di Corso Sardegna, che sono serviti invece dalla
SGU Manin).

Pertanto, a meno che il tuo indirizzo fosse su un 'bordo' dell'area SGU
Manuzio, dovresti ritrovarlo coperto nella pagina in questione.

[Blak]

Post by Macs
Ciao

Ciao

Post by Macs
Quando pertanto compare p.es. l'indicazione Genova - San Fruttuoso,
piuttosto che Genova - Sampierdarena, cio' non significa che esista una
SGU con tal nome = semplicemente tale e' un'informazione aggiuntiva, che
l'utente ha inserito prima di inviare il modulo di feedback.

Ok, pensavo fossero indicate solo le SGU.

Post by Macs
- http://plany.fasthosting.it/test/manuzio.htm

WOW!

Post by Macs
Pertanto, a meno che il tuo indirizzo fosse su un 'bordo' dell'area SGU
Manuzio, dovresti ritrovarlo coperto nella pagina in questione.

Si, c'è una indicazione relativa al mio numero civico, poco meno di 1300
metri e SGU Manuzio.

[Punto Moda]

Post by Marc Serafino
Confermo che Fastweb e' un'azienda di BARBONI che dice di vendere Internet
e invece anche ora che assegna un IP pubblico dinamico (come tutti gli
altri provider) continua a non concedere vero accesso ad Internet in quanto
le porte sono TUTTE chiuse in ingresso (tranne la 80 ovviamente). Ricordo
infatti che la corretta definizione di connessione ad Internet identifica
un nodo perfettamente raggiungibile da qualsiasi altro nodo della rete. E
con Fastweb, quei barboni di Fastweb, nonostante tutto non e' ancora cosi'.

Rimane sempre la domanda: ma perche non te ne vai, invece di sbraitare..??
Chi te lo fa fare di restare con fastweb..? Chi sei il buon samaritano che
vuole redimerli??

--
Saluti

Giorgio

[Marc Serafino]

Post by Punto Moda

Post by Marc Serafino
Confermo che Fastweb e' un'azienda di BARBONI che dice di vendere Internet
e invece anche ora che assegna un IP pubblico dinamico (come tutti gli
altri provider) continua a non concedere vero accesso ad Internet in quanto
le porte sono TUTTE chiuse in ingresso (tranne la 80 ovviamente). Ricordo
infatti che la corretta definizione di connessione ad Internet identifica
un nodo perfettamente raggiungibile da qualsiasi altro nodo della rete. E
con Fastweb, quei barboni di Fastweb, nonostante tutto non e' ancora cosi'.

Rimane sempre la domanda: ma perche non te ne vai, invece di sbraitare..?

Mi interessa conservare la mia utenza in fibra ottica. Appena potro'
migrarla presso un altro gestore lo faro' molto volentieri.

[titta]

Post by Marc Serafino

Post by Punto Moda

Post by Marc Serafino
Confermo che Fastweb e' un'azienda di BARBONI che dice di vendere Internet
e invece anche ora che assegna un IP pubblico dinamico (come tutti gli
altri provider) continua a non concedere vero accesso ad Internet in quanto
le porte sono TUTTE chiuse in ingresso (tranne la 80 ovviamente). Ricordo
infatti che la corretta definizione di connessione ad Internet identifica
un nodo perfettamente raggiungibile da qualsiasi altro nodo della rete. E
con Fastweb, quei barboni di Fastweb, nonostante tutto non e' ancora cosi'.

Rimane sempre la domanda: ma perche non te ne vai, invece di

sbraitare..?

Post by Marc Serafino
Mi interessa conservare la mia utenza in fibra ottica. Appena potro'
migrarla presso un altro gestore lo faro' molto volentieri.

Grande Fastweb! Anche nelle case di cura ha portato la fibra!

[Punto Moda]

Post by Marc Serafino
Mi interessa conservare la mia utenza in fibra ottica. Appena potro'
migrarla presso un altro gestore lo faro' molto volentieri.

Ogni provider ha i suoi pregi e difetti.. Non puoi voler solo i pregi e i
difetti se li cuccano gli altri..

--
Saluti

Giorgio

[Marc Serafino]

Post by Punto Moda

Post by Marc Serafino
Mi interessa conservare la mia utenza in fibra ottica. Appena potro'
migrarla presso un altro gestore lo faro' molto volentieri.

Ogni provider ha i suoi pregi e difetti.. Non puoi voler solo i pregi e i
difetti se li cuccano gli altri..

Nessuno ha solo difetti come Fastweb (a parte la fibra ottica).

[Punto Moda]

Post by Marc Serafino
Nessuno ha solo difetti come Fastweb (a parte la fibra ottica).

Difatti tu rimani proprio per quell'unico pregio..
E proprio vero che l'erba del vicino sembra sempre piu verde..

--
Saluti

Giorgio

[MarcoGE]

Post by Marc Serafino
Nessuno ha solo difetti come Fastweb (a parte

ti salta all'occhio la /lieve/ contraddizione, eh?

[Marc Serafino]

Post by MarcoGE

Post by Marc Serafino
Nessuno ha solo difetti come Fastweb (a parte

ti salta all'occhio la /lieve/ contraddizione, eh?

Direi proprio di no. Cosi' come per l'ultimo glio delle XDSL, anche
l'ultimo miglio delle fibre e l'intera rete in fibra realizzata anni fa da
Fastweb potrebbe essere affittata o migrata verso un altro gestore. E'
quello il momento che aspetto con ansia, poi nel caso Fastweb dovesse
invertire la sua tendenza di pessima telco sono pronto a rimanere anche con
loro. Nessun pregiudizio, nessuna preclusione. Soltanto: oggi come oggi non
avessi la fibra e alcuni servizi ad essa collegati sarei gia' scappato
dalle loro grinfie da lungo tempo. Piuttosto mi chiedo come facciano gli
utenti DSL a rimanere con Fastweb per pagare spesso di piu' e qualche volta
uguale rispetto ad un provider decisamente migliore come Telecom o Tiscali
(e molti altri). Misteri dell'animo umano o forse piu' semplicemente
potenza della pubblicita' e del marketing (a mio avviso spesso al limite
dell'ingannevole, vedi la faccendo di Internet che in realta' e' vista web
e potremmo andare avanti per ore).

[MarcoGE]

Post by Marc Serafino

Post by MarcoGE

Post by Marc Serafino
Nessuno ha solo difetti come Fastweb (a parte

ti salta all'occhio la /lieve/ contraddizione, eh?

Direi proprio di no.

...

Post by Marc Serafino
Nessun pregiudizio, nessuna preclusione.

LOL

Post by Marc Serafino
Piuttosto mi chiedo come facciano gli
utenti DSL a rimanere con Fastweb per pagare spesso di piu' e qualche volta
uguale rispetto ad un provider decisamente migliore come Telecom

Uh, ad un mio amico che ha Alice han fatto una lieve rimodulazione.


1Mb

Post by Marc Serafino
o Tiscali

Tiscali che, a meno di cambiare apparato e rinunciare quindi al numero
telefonico, non permette l'uso del voip

Post by Marc Serafino
(e molti altri).

Certo non Infostrada.
Ho una pessima esperienza personale avvallata da amici che ne sono
fuggiti o stanno epr farlo

Post by Marc Serafino
Misteri dell'animo umano o forse piu' semplicemente
potenza della pubblicita' e del marketing

Quello credo di no. Ognuno poi ha i suoi gusti, ma le pubblicità di FW
sono quantomeno fra le peggiori. Meno male che hanno, almeno, corretto
la gaffe del "disco frigido" LOL

[Massi]

Post by Marc Serafino
Confermo

milano est, da stamattina (probabilmente ieri sera) migrato al nuovo
93.spiccioli
non ho fatto prove dall'esterno

[Trip65]

Post by Massi

Post by Marc Serafino
Confermo

milano est, da stamattina (probabilmente ieri sera) migrato al nuovo
93.spiccioli
non ho fatto prove dall'esterno

tutto filtrato almeno fino a ieri
inoltre ci sono dei difetti vari che spero siano dovuti alla cfg ancora
sperimentale .
La cosa positiva è che le prestazioni sono ottime in termini di latenze
e velocità e sono spariti odiosi ban su ip (fibra mi - milano caldera )

[Marc Serafino]

Post by Trip65

Post by Massi
milano est, da stamattina (probabilmente ieri sera) migrato al nuovo
93.spiccioli
non ho fatto prove dall'esterno

tutto filtrato almeno fino a ieri
inoltre ci sono dei difetti vari che spero siano dovuti alla cfg ancora
sperimentale .
La cosa positiva è che le prestazioni sono ottime in termini di latenze
e velocità e sono spariti odiosi ban su ip (fibra mi - milano caldera )

Concordo, sembra quasi di utilizzare una normale connessione a Internet per
quanto riguarda le latenze sui siti, la disponibilita' di slot su
Rapidshare e altri host per il download/upload di file. Resta pero'
l'enorme problema relativo al fatto che questi barboni di ostinano a non
voler offrire Internet e a chiudere quindi tutte le porte in ingresso.

[MarcoGE]

Post by Marc Serafino
disponibilita' di slot su
Rapidshare e altri host per il download/upload di file

Mica scaricherai materiale coperto da copyrighjt, eh? :o)

[legend]

Post by MarcoGE

Post by Marc Serafino
disponibilita' di slot su
Rapidshare e altri host per il download/upload di file

Mica scaricherai materiale coperto da copyrighjt, eh? :o)

Sei pazzo !
Ci scarica sicuramente le distro linux...