FiberTelecom (Klik Network)

GiovanniS Succederà questo alla rete:

1° segmento - CASA-ROE-ARMADIO-OLT (centrale) resta quello di TIM attuale
2° segmento - CENTRALE-POP CONSEGNA ROMA (Fastweb)
3° segmento - POP-INTERNET e trasporto (Fiber Telecom)

Non è una risposta la mia, ma una domanda: se questi sono i listini KLIK

• https://www.klik.network/servizi-telefonia-adsl-fibra/ftth-giga-professionale-casa.asp
• https://www.klik.network/servizi-telefonia-adsl-fibra/ftth-giga-professionale-aziende.asp

da dove salta fuori la raccolta Fastweb su accesso Fibercop con trasporto FT?

mark129 da dove salta fuori la raccolta Fastweb su accesso Fibercop con trasporto FT?

Ed in tutto ciò come si può eseguire una operazione di

fine tuning del caso al fine di ottenere latenze ridotte all'osso verso i server di gioco conosciuti

All'interno di una matrioska klik/ft/fw/tim?

simonebortolin una matrioska klik/ft/fw/tim?

klik è un mero reseller, non ha alcuna parte attiva nella catena se non nella fatturazione a fine mese. E un livello in più del gioco del "telefono senza fili" quando c'è una segnalazione di problemi.

GiovanniS mi attiveranno una linea Fastweb con trasporto Fiber Telecom.

Contrario, FT su trasporto Fastweb in VULA TIM.

E anche il trasporto FW ha impatti sulla latenza, se nella loro rete ti fanno fare "il giro dell'oca" prima di consegnarti al BRAS FiberTelecom è tutto tempo che perdi ma non vedi.

GiovanniS conviene scendere per poi risalire?

Dipende da come sono disposte geograficamente le reti Fastweb e/o TIM, a seconda di dove avviene l'handoff tra le due reti, se in VULA locale in sede OLT o in consegna NGA remota -- in questo secondo caso fan fede i rilegamenti della rete OPB di TI, e da Pesaro con massima probabilità percorrerà la dorsale adriatica fino a Rimini, e da qui al nodo di core a Roma.

[cancellato] Dipende da come sono disposte geograficamente le reti Fastweb e/o TIM, a seconda di dove avviene l'handoff tra le due reti, se in VULA locale in sede OLT o in consegna NGA remota

Sempre e solo VULA, perche' lo scopo e' anche quello di usare il trasporto Fastweb che costa molto meno del Long Distance Telecom...

Purtroppo pero' temo che anche su rete FW si finisca per forza a Roma da Pesaro...

gandalf2016 rete aggiornata

Oh, ecco, cosi' ha molto piu' senso Finalmente... Speriamo che anche Fastweb si "svegli" presto cosi'...

gandalf2016 Sono 12 ms a Milano e 20 ms ad Amsterdam.

Io veramente dalla traccia del primo post vedo ben 16-22 ms fino a Milano e 33 fino ad Amsterdam... In teoria ne dovrebbe pingare 9-12 fino a Milano in base alla distanza geografica e a come sono collegate le citta'...

gandalf2016 Non so io non son per niente sicuro sia la rete la causa di tutti questi problemi, son curioso di vedere cosa succede cambiando.

Effettivamente questo dubbio viene anche a me. Considerando poi che Fastweb lo portera' fino a Roma (come gli e' gia' stato detto anche da Klik...), anche se la latenza dovesse "stabilizzarsi", cmq ci sarebbe sempre un'aggiunta "statica" non indifferente...

gandalf2016 Penso sia nel margine di errore di ICMP TTL time exceeded per quei router.
Ho preso il minimo su questo hop che è 12 ms.
Quindi in 12 ms la rete lo porta a Milano che è poi coerente con i +20 ms ad Amsterdam.

Uhm, no a guardare meglio la traceroute secondo me ci sta ECMP (Equal Cost Multi-Path routing) da qualche parte che rompe le uova nel paniere... Essendo quella la traceroute UDP di Windows che quindi se ricordo bene usa porte di destinazione in sequenza, ecco qui che si evidenziano i diversi percorsi, con latenze differenti ben evidenti ma cmq configurati in ECMP...

  7    22 ms    22 ms    21 ms  ae48.milano11.mil.seabone.net [195.22.192.144]
  8    13 ms    12 ms    16 ms  ae21.milano51.mil.seabone.net [195.22.205.39]
  9    22 ms    21 ms    21 ms  riot.milano51.mil.seabone.net [195.22.205.93]
 10    27 ms    27 ms    27 ms  ae11.er01.fra02.riotdirect.net [104.160.151.234]
 11    25 ms    25 ms    25 ms  ae14.er01.ams02.riotdirect.net [104.160.159.156]
 12    33 ms    33 ms    33 ms  104.160.141.30

In effetti se fosse cosi', credo proprio che il cambio Operatore probabilmente risolverebbe questa latenza "ballerina". Anche se, come detto sopra, aggiungerebbe il "costo fisso" del giretto panoramico Pesaro-Roma-Milano...

gandalf2016 Non so, son tutti in festa per il nuovo DC di Roma e ci son collegati sempre più transiti a Roma

... ma almeno i wholesale li facessero passare diretti a Milano...

LATIITAY ECMP fa divisione tra i percorsi sul singolo pacchetto, non è LACP che ha gli algoritmi di hashing tra cui anche dati L3 e L4 per mantenere un "flusso" su una stessa porta.

Ciò detto, non dimenticate che la latenza vista negli hop intermedi dei trace è anche il tempo che impiega la risposta ICMP ad arrivare all'host, difatti nel tuo caso la latenza all'ultimo hop (che è quella che conta di tutta 'sta trafila) è stabile e costante a 33ms. Che in mezzo ci balli la tarantella frega niente a nessuno, onestamente...

[cancellato] ECMP fa divisione tra i percorsi sul singolo pacchetto, non è LACP che ha gli algoritmi di hashing tra cui anche dati L3 e L4 per mantenere un "flusso" su una stessa porta.

Ehm no, viene fatto hashing anche per ECMP, se no addio... Vedi anche CloudFlare ne sa qualcosa: https://blog.cloudflare.com/warp-technical-challenges/ (emphasis mine)

It could be theoretically possible to use ECMP to balance packets between servers randomly, but you would almost never want to do that. A message over the Internet is generally composed of multiple TCP packets. If each packet were sent to a different server it would be impossible to reconstruct the original message in any one place and act on it. Even beyond that, it would be terrible for performance: we rely on being able to maintain long-lived TCP and TLS sessions which require a persistent connection to a single server. To provide that persistence, our routers don’t balance traffic randomly, they use a combination of four values: the source address, the source port, the destination address, and the destination port. Traffic with the same combination of those four values will always make it to the same server. In the case of my example above, all of my messages destined to cloudflare.com will make it to a single server which can reconstruct the TCP packets into my request and return packets in a response.

(dove leggi "server" leggilo come "next-hop router", se vuoi approfondire perche' leggi l'articolo del blog.)

[cancellato] è stabile e costante a 33ms

Su 3 probe fatte in 3 secondi... Non e' certo misura di stabilita' e costanza nel tempo...

LATIITAY Non c'entra nulla, è un esempio di come passano da un IP anycast ad un server via routing invece che usare un load balancer.
Nel mondo ISP le cose sono leggermente diverse, e se hai due o più router adiacenti che danno accesso allo stesso percorso ma su fibre diverse per distribuire il carico di tenere coerenti i flow non te ne importa più di tanto.

gandalf2016 Il numero di HOP c’entra poco, dipende strettamente dalla progettazione di rete.
Molti usano MPLS con tunnelizzazione arrivando a farti Milano- New York in un hop, quando hai N router in mezzo.

In sostanza il numero di hop che vedi ha poco significato, purtroppo. A seconda di come è progettata la rete possono o meno apparire.

Concordo.
Ricordo ancora quando Fastweb 20 anni fa aveva una sfilza di router nella sua rete interna che non finiva più (ora mi pare siano generalmente un pò diminuiti), però poi nella pratica funzionava molto meglio di altri ISP che magari raggiungevano determinate destinazione con la metà degli hop.

gandalf2016 Con TIM l’instradamento poi varia anche di +-10ms a seconda dell’IP che prendi, essendo una rete con molti indirizzi che vengono annunciati in modi lievemente diversi anche per bilanciare il carico.

In parte credo dipenda anche da TI Sparkle non solo da TIM con ISP in sè, in quanto la stessa cosa accade anche con le FTTH OpenInternet, per cui a seconda dell'IP cambiano le latenza di 10-20ms (e spesso proprio sugli stessi server dove sto giochino succede con TIM).

GiovanniS IP: 3.64.164.153 - Ping su Sparkle da Pesaro: 13 ms - Francoforte (sembra si appoggino ad Amazon AWS)

Non mi sembra che sia pingabile, comunqe 52.119.155.155 lo fa in 18 ms dal friuli.

E neanche

GiovanniS 52.119.154.213

è pingabile, il max che sono riuscito a pingare è l'analogo del tuo 52.119.X.X su altra rotta.

GiovanniS no becco il 52.119.155.155 che risponde in 18 ms (in liena con i tempi classici dati che fino a milano qui in friuli si passa per Trieste)

GiovanniS E' più che altro curiosità, vorrei capire che giri fa Fiber Telecom a differenza di Sparkle e con che latenze

Dovrebbe avere peering a Milano al MIX per lo meno, da qui passi entro la rete AWS.

GiovanniS

Traccia instradamento verso ec2-3-64-164-153.eu-central-1.compute.amazonaws.com [3.64.164.153]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     7 ms     8 ms     7 ms  249-228-157-185.fibertelecom.it [185.157.228.249]
  3     8 ms     8 ms     8 ms  172.30.36.9
  4    10 ms     9 ms     8 ms  73-229-157-185.fibertelecom.it [185.157.229.73]
  5    10 ms    10 ms     9 ms  52.119.155.72
  6     9 ms     8 ms    10 ms  52.119.155.87
  7     *        *        *     Richiesta scaduta.
  8     *        *        *     Richiesta scaduta.
  9     *        *        *     Richiesta scaduta.
 10     *        *        *     Richiesta scaduta.
 11     *        *        *     Richiesta scaduta.
 12     *        *        *     Richiesta scaduta.
 13

Come hanno già scritto sopra, non si raggiunge il server finale.

GiovanniS ahime' temo che da Pesaro su rete FW che gira per Roma avrai 20-25 ms verso Milano, a cui poi aggiungere un'altra decina di ms per arrivare a Francoforte. Purtroppo finche' il Long Distance su rete Telecom non calera' a prezzi "umani", poco altro c'e' da fare se non farsi trasportare da Fastweb, se non si e' coperti da OpenFiber... :/

LATIITAY Purtroppo finche' il Long Distance su rete Telecom non calera' a prezzi "umani"

Prezzi umani == non si paga se fai meno di una media di 3Mbps a cliente?

simonebortolin grrr

GiovanniS eh, 10 ms peggio di quanto avevo detto io. :/

Puoi fare traceroute da entrambe le linee anche verso 8.8.8.8 che e' "quasi" sicuramente a Milano?

GiovanniS non mi spiego queste latenze insensate su rete FW, davvero eccessive

Potrebbe essere una NGA consegnata altrove, quindi ti manca il trasporto TIM in mezzo e vedi un salto di latenza tra hop 1 e 2.

GiovanniS C'è modo per capire se effettivamente è VULA o NGA questa FW di esempio?

Controlla sul sito di Dimensione la copertura di quell'indirizzo: loro raccolgono le FTTC su VULA FW, se non ti da copertura per FTTC, allora è NGA.