edofullo Sicuramente servirebbe un test ma non sono TIM, o in generale le grandi aziende, che lavorano a colpi di proclami. teozonzo ci farà qualche test.
QRDG Non solo le hanno messe, sono un loro brevetto. Comunque i profili simmetrici non mi sembrano esserci più ma c'erano quando in zona non c'era nemmeno l'ADSL 2 mega. Ora probabilmente usano la loro fibra per P2P o GPON "dedicate" alle tante strutture alberghiere di Paestum e del Cilento.
mb334 Sicuramente servirebbe un test ma non sono TIM, o in generale le grandi aziende, che lavorano a colpi di proclami
Anche i piccoli a volte non son da meno, io non credo finchè non vedo 
IPv6 fatto alla IPv4 serve a poco, non basta prendere una /64 dinamica dal pool.
Se @teozonzo ha voglia può cominciare mettendo uno screen di https://ipv6-test.com, se vuoi censura il terzo gruppo dell'indirizzo IPv6 se compare. Gli altri non sono sensibili.
Se non compare c'è da verificare se è attivato nel router
QRDG Su AON o GPON+ simmetrico secondo me dare profili asimmetrici è stupido ed è semplicamente una limitazione inutile che ci si porta dietro dall'ADSL.
davidebissoli97 non ho detto poco traffico in assoluto, ho detto verso certi paesi
Non è che ti stessi contraddicendo, stavo commentando riallacciandomi alla questione wholesale introdotta da @mb334 : posto che personalmente mi pare lungo / difficile stimare (con quei mezzi pubblicamente a disposizione dei non esperti) se e quanto da Convergenze facciano traffico verso India, Cina o altre mete esotiche, sul loro AS hanno relativamente tanto traffico per un operatore regionale (a confronto, vedi per es. le stime per Unidata su peeringdb), ma annunciano pochi prefissi (per dire, appena il doppio di Interfibra, per citare un piccolo operatore noto di recente qui per mezzucci e sotterfugi) per un operatore che operi in wholesale (vedi i ca. 2000-2500 prefissi di una SeFlow o di una FT, sempre dati peeringdb, che hanno un ordine di grandezza doppio per quanto riguarda le stime dei livelli di traffico).
Quanto al numero dei peer, a sentimento (quindi sarei lieto di essere corretto con dei dati) immagino che possano esser figli di qualche accordo / contratto di remote peering, che almeno fino a poco tempo fa erano tanto di moda in Italia (e che in genere sapevo che si pagano: per cui una volta che ce l'hai, probabilmente è meglio sgravare gli altri transiti di qualunque traffico tu possa avere lungo le direttrici coperte, anche se l'utilità e la gestione dei RP mi sembra di ricordare che fossero piuttosto dibattute, almeno in ambiente ITNOG).
mark129 per un operatore che operi in wholesale
Non è detto che un wholesaler debba per forza avere miliardi di risorse IP, può fare WLS solo per la parte di accesso fisica, e consegnare il traffico via NNI alla rete del provider "cliente" (stile OpenStream per capirsi).
Quel che intendi tu è se fanno fare solo rivendita di servizi propri per conto terzi alla EasyIP o OpenInternet.
[cancellato] Non è detto che un wholesaler debba per forza avere miliardi di risorse IP, può fare WLS solo per la parte di accesso fisica, e consegnare il traffico via NNI alla rete del provider "cliente" (stile OpenStream per capirsi).
Non sono sicuro di averti capito.
Innanzitutto se il traffico lo si consegna alla rete del provider "cliente" direttamente i vari tool tipo peeringdb o bgpview non dovrebbero averne contezza, oppure no?
In ogni caso non stavo dicendo che debba avere milioni di IP: per fare un es., se attraverso te passa il traffico dei tuoi provider clienti, i blocchi dei tuoi clienti dovrebbero essere annunciati dal tuo AS, cosa che nel breve check che ho fatto non ho visto (c'è qualcosina di Retelit, qualcosa di altri e - interessante - tutta la /10 di AMPRNET, ma niente di significativo sul totale).
[cancellato] Quel che intendi tu è se fanno fare solo rivendita di servizi propri per conto terzi alla EasyIP o OpenInternet.
No, come detto sopra il numero limitato di prefissi annunciati sembrava in contrasto con la rivendita di transito. In ogni caso, in EasyIP (penso OF sia lo stesso) gli IP ci sono, e sono quelli di TIM, annunciati su uno degli AS di TIM (il 3269?); ora rispetto a TIM (che ha i netblock nascosti pure sotto i tappeti), Convergenze ha sì ca. 1/10 dei prefissi ma solo ca. 1/200 degli indirizzi totali (circa 95k).
Ora qualunque traffico da qualche host deve originarsi: ho citato Unidata nel post precedente, perché con un numero equivalente di indirizzi (ca 84k) fa un traffico da 2 a 10 volte inferiore (secondo le stime dei soliti noti).
In ogni caso, come pure detto a @davidebissoli97, di certo non stavo "battezzando" il traffico di Convergenze, solo notando alcune caratteristiche "peculiari" (non prettamente da wholesaler o transit provider, non da generatore di contenuti, non da ISP consumer, etc): o meglio, peculiari per chi li osserva la prima volta (come me).
Anche perché i dati che si trovano pubblicamente (peeringdb/bgpview) sono piuttosto "aleatori" a quel che mi risulta, per cui tutto il lambiccarsi potrebbe benissimo essere del tutto vano.
mark129 se il traffico lo si consegna alla rete del provider "cliente" direttamente i vari tool tipo peeringdb o bgpview non dovrebbero averne contezza, oppure no?
Corretto; il provider wholesaler in questo caso rende disponibile il solo "circuito" L2 di consegna tra i BRAS e la CPE utente. "Tira il tubo", per semplificare.
mark129 se attraverso te passa il traffico dei tuoi provider clienti, i blocchi dei tuoi clienti dovrebbero essere annunciati dal tuo AS
No, anzi. Facendo così tu sei un transito del provider cliente, sei a monte verso la big-internet, non a valle verso il cliente finale.
mark129 in EasyIP (penso OF sia lo stesso) gli IP ci sono
Certo, perché di fatto sono vere e proprie linee TIM, a tutti gli effetti. Cambia solo chi emette fattura verso il cliente. Ma sono due prodotti all'ingrosso molto diversi, il primo è una semplice connettività di circuito, il secondo è un servizio attivo e completo.
@teozonzo a occhio lavori per Convergenze (o altrimenti spiegami l'indirizzo email 
), quindi in tal caso di inviterei a rendero esplicito. Non è vietato e anzi incentivato, ma bisogna essere chiari.
teozonzo iao, io ho FTTH con loro su rete OF e li conosco di persona.
Ti confermo che funziona tutto a dovere, sono stati fatti dei lavori di manutenzione di recente a Milano per cui la consegna del traffico verrà a giorni separata tra clienti nord e sud.
Se hanno aperto un punto di raccolta a Milano è senza dubbio positivo, fin'ora raccoglievano sempre a Salerno.
Il problema però è un'altro.
Dai traceroute che mi inviarono nel 2019, mentre il peering con i transiti (Level3, GTT, Cogent) si trovavano a Milano, tutti gli altri collegamenti diretti, come anche al DECIX o AMSIX, partivano da Roma (ed erano usati per una cospicua parte del routing estero).
In quei casi l'utente che esce a Milano dovrà riscendere a Roma per agganciare il DECIX? Oppure sono stati aperti dei collegamenti diretti con DECIX o AMSIX anche a Milano?
Inoltre, se questi dati sono aggiornati, non sono un pò pochini ad oggi 2GB al DECIX e AMSIX, con connessioni di 1Gb ad utente? https://www.peeringdb.com/net/3838
MiloZ utti gli altri collegamenti diretti, come anche al DECIX o AMSIX, partivano da Roma (ed erano usati per una cospicua parte del routing estero).
Sai chi fornisse loro il servizio di remote peering?
MiloZ se questi dati sono aggiornati
Eh, "SE"... personalmente comincio ad avere dubbi sull'affidabilità di quei dati per Convergenze.
vanzo Ecco i traceroute verso i server che mi chiedevi
Traccia instradamento verso dns.google [8.8.8.8]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 <1 ms <1 ms <1 ms cr1-br2-capac.convergenze.it [185.104.124.5]
4 13 ms 13 ms 13 ms mix-rs1.convergenze.it [94.101.60.173]
5 13 ms 13 ms 13 ms google.mix-it.net [217.29.66.96]
6 15 ms 13 ms 15 ms 74.125.245.225
7 17 ms 16 ms 17 ms 142.250.212.243
8 16 ms 13 ms 14 ms dns.google [8.8.8.8]
Traccia instradamento verso one.one.one.one [1.1.1.1]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 1 ms 1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 5 ms 5 ms 6 ms rm-cap1.convergenze.it [195.60.190.28]
5 6 ms 5 ms 6 ms cloudflare-nap.namex.it [193.201.28.33]
6 5 ms 5 ms 5 ms one.one.one.one [1.1.1.1]
Traccia instradamento verso i3d.net [31.204.146.148]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 <1 ms <1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 5 ms 4 ms 4 ms rm-cap1.convergenze.it [195.60.190.28]
5 23 ms 23 ms 23 ms ipv4.de-cix.fra.de.as49544.i3d.net [80.81.194.107]
6 38 ms 36 ms 39 ms nlrtm1-rt001i.i3d.net [109.200.218.76]
7 34 ms 34 ms 40 ms nlrtm1-rt004i.i3d.net [109.200.218.165]
8 30 ms 30 ms 31 ms www.i3d.net [31.204.146.148]
Traccia instradamento verso 149.154.167.91 su un massimo di 30 punti di passaggio
1 1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 1 ms <1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 18 ms 16 ms 16 ms mix-rs1.convergenze.it [94.101.60.173]
5 29 ms 29 ms 28 ms as57463.0.181.netix.net [193.218.0.181]
6 * * * Richiesta scaduta.
7 * * * Richiesta scaduta.
8 * * * Richiesta scaduta.
9 * * * Richiesta scaduta.
10 41 ms 41 ms 41 ms 149.154.167.91
Traccia instradamento verso gofile.io [51.91.136.229]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 <1 ms <1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 15 ms 14 ms 13 ms mix-rs1.convergenze.it [94.101.60.173]
5 17 ms 27 ms 17 ms ovh.mix-it.net [217.29.66.67]
6 * * * Richiesta scaduta.
7 * * * Richiesta scaduta.
8 * * * Richiesta scaduta.
9 38 ms 37 ms 39 ms par-gsw-sbb1-nc5.fr.eu [54.36.50.228]
10 36 ms 35 ms 36 ms be102.gra-g1-nc5.fr.eu [91.121.215.176]
11 * * * Richiesta scaduta.
12 * * * Richiesta scaduta.
13 * * * Richiesta scaduta.
14 * * * Richiesta scaduta.
15 * * * Richiesta scaduta.
16 * * * Richiesta scaduta.
17 * * * Richiesta scaduta.
18 36 ms 35 ms 35 ms 51.91.136.229
Traccia instradamento verso speedtest.your-server.de [88.198.248.254]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 <1 ms <1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 6 ms 5 ms 4 ms rm-cap1.convergenze.it [195.60.190.28]
5 24 ms 39 ms 26 ms decix2-gw.hetzner.com [80.81.193.164]
6 28 ms 27 ms 27 ms core12.nbg1.hetzner.com [213.239.245.246]
7 27 ms 27 ms 27 ms juniper3.dc1.nbg1.hetzner.com [213.239.247.229]
8 27 ms 28 ms 27 ms nbg.icmp.hetzner.com [88.198.248.254]
Traccia instradamento verso tmo-136-31.customers.d1-online.com [80.187.136.31]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 4 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 2 ms <1 ms <1 ms cr1-br2-capac.convergenze.it [185.104.124.5]
4 16 ms 16 ms 16 ms mix-rs2.convergenze.it [94.101.60.174]
5 20 ms 21 ms 27 ms xe-11-3-0.bar1.Milan1.Level3.net [213.242.65.89]
6 * 29 ms 32 ms ae-1-3107.edge6.Dusseldorf1.Level3.net [4.69.161.194]
7 32 ms 32 ms 34 ms DTAG-level3-Dusseldorf1.Level3.net [4.68.71.114]
8 35 ms 35 ms 35 ms f-ef81-i.F.DE.NET.DTAG.DE [217.5.67.210]
9 35 ms 35 ms 35 ms 80.156.5.36
10 * * * Richiesta scaduta.
11 32 ms 32 ms 33 ms tmo-136-31.customers.d1-online.com [80.187.136.31]
Traccia instradamento verso ecmwf.int [136.156.180.54]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 3 ms <1 ms <1 ms cr1-br1-capac.convergenze.it [185.104.124.1]
4 5 ms 5 ms 4 ms rm-cap1.convergenze.it [195.60.190.28]
5 40 ms 38 ms 54 ms linx-gw1.ja.net [195.66.224.15]
6 43 ms 40 ms 57 ms ae23.londtt-sbr1.ja.net [146.97.35.169]
7 38 ms 39 ms 40 ms ae28.londtw-sbr2.ja.net [146.97.33.62]
8 40 ms 38 ms 38 ms ae30.londpg-sbr2.ja.net [146.97.33.5]
9 39 ms 40 ms 41 ms ae19.readdy-rbr1.ja.net [146.97.37.194]
10 40 ms 39 ms 40 ms ae3.readss-rbr1.ja.net [193.63.108.90]
11 43 ms 41 ms 41 ms ecmwf.ja.net [193.63.109.158]
12 41 ms 42 ms 42 ms 136.156.31.17
13 42 ms 44 ms 41 ms ecmwf.int [136.156.180.54]
Traccia instradamento verso aixit.com [82.149.224.66]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms core1-sede2-laser.convergenze.it [93.88.110.21]
3 <1 ms <1 ms <1 ms cr1-br2-capac.convergenze.it [185.104.124.5]
4 5 ms 7 ms 5 ms rm-cap1.convergenze.it [195.60.190.28]
5 24 ms 24 ms 32 ms 10GE-7-1.DECIX1.FRA.IAG.EU [80.81.194.46]
6 28 ms 24 ms 24 ms decix.cr1.of.aixit.net [83.141.0.253]
7 25 ms 24 ms 24 ms ae0-3003.er1.fra1.ax.de.aixit.net [83.141.5.106]
8 29 ms 25 ms 24 ms www.aixit.com [82.149.224.66]matteocontrini L'indirizzo nella forma che hai visto è una webmail attivabile liberamente da tutti i clienti . Come ho scritto anche nel primo messaggio li conosco di persona. Non sono loro dipendente ma un loro consulente esterno (oltre che cliente).
teozonzo L'indirizzo nella forma che hai visto è una webmail attivabile liberamente da tutti i clienti
Ok, ci avevo pensato ma vedendo che è lo stesso dominio usato dai dipendenti mi pareva strano, e mi pare un po' una follia sinceramente, ma tant'è grazie per la precisazione.
teozonzo Sai qualcosa per quanto riguarda IPv6?
Cosa ti restituisce questa pagina: https://ipv6-test.com
edofullo Non avevo IPv6 precedentemente attivo nel router e sto provando a fare qualche test.
Su quel sito web di test compare qualcosa sulla parte IPv6 solo attivandola con protocollo di tunneling.
Uscendo con IPv4 nativa o IPv6 nativa vedo che negozia indirizzo, navigo, ma sul link che mi hai dato non vede nulla.
Ti allego quindi la screenshot con IPv6 su protocollo di tunneling.
teozonzo 6to4 vade retro meglio di no... ormai è deprecato da anni.
teozonzo Uscendo con IPv4 nativa o IPv6 nativa vedo che negozia indirizzo, navigo, ma sul link che mi hai dato non vede nulla
Prova a mandare qualche screenshot dei log se riesci (e se hai voglia) che ci diamo un occhiata.
Per quanto riguarda l'IPv6 devi censurare il terzo gruppo di cifre, il resto è legato all'operatore o random.
teozonzo
Quando compare un ISP nuovo c'è sempre la mia domanda di rito:
Che ti rispondono
https://redirector.googlevideo.com/report_mapping
(di questo interessa solo la prima riga, non le debug info)https://api.fast.com/netflix/speedtest/v2?https=true&token=YXNkZmFzZGxmbnNkYWZoYXNkZmhrYWxm&urlCount=3
(questo sarebbe carino averlo tutto)
?In entrambi i casi ti consiglio di cancellare il primo indirizzo IP che vedi per privacy perché è il tuo, il resto non sono dati sensibili ti dicono solo rispettivamente dove vai a pescare il primo Youtube/Google video ecc., il secondo netflix
edofullo Selezionando IPv6 nativa dal router poi nel log vedo
Il prefisso IPv6 è stato ottenuto correttamente. Nuovo prefisso: 2a01:xxxx:yyyy:4::/64
La connessione Internet IPv6 è stata stabilita correttamente. Indirizzo IP: 2a01:xxxx: ...
e viene visualizzato l'indirizzo completo IPv6
Come DNS ho aggiunto a mano quelli di CloudFlare (2606:4700:4700::1111 e 2606:4700:4700::1001).
Però la schermata che restituisce il test non trova nulla di IPv6. Non saprei cos'altro controllare.
@itreb Sul primo compare indirizzo IPv4 => convergenze-nap1 (indirizzo dell'intero blocco IPv4)
Sul secondo
{"client":{"ip":"mio IPv4","asn":"39120","location":{"city":"Capaccio","country":"IT"}},"targets":[
{"name":"https://ipv4-c001-qsr001-convergenze-isp.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=nErpZn4ZFv_IOh_3-IyNzc61COUmCn6SW76Bfw","url":"https://ipv4-c001-qsr001-convergenze-isp.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=nErpZn4ZFv_IOh_3-IyNzc61COUmCn6SW76Bfw","location":{"city":"Capaccio Paestum","country":"IT"}},
{"name":"https://ipv4-c030-rom001-ix.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=JjCzJGt2gYjQbNoar578zZ9_IZPOasFBBVR8xw","url":"https://ipv4-c030-rom001-ix.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=JjCzJGt2gYjQbNoar578zZ9_IZPOasFBBVR8xw","location":{"city":"Rome","country":"IT"}},
{"name":"https://ipv4-c006-rom001-ix.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=CQFGvH0rhabHztegEyMOzowy7c-k9Zy7GMlCqA","url":"https://ipv4-c006-rom001-ix.1.oca.nflxvideo.net/speedtest?c=it&n=39120&v=43&e=1622127959&t=CQFGvH0rhabHztegEyMOzowy7c-k9Zy7GMlCqA","location":{"city":"Rome","country":"IT"}}]}
Consigli su cos'altro controllare? Grazie
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile
