Ping elevado em jogos online .

  • 7 October 2014
  • 852 respostas
  • 17037 visualizações


Mostrar a primeira mensagem

852 respostas

Se tens a hipotese de tornar uma defesa de algo + forte, fazendo hide do ip da mesma, porque não? 


Muita gente basta ter o teu skype, e faz-te ddos, e a mim, ja o dei a muita gente, e ja foi mostrado em stream e nunca levei ddos, por que será?


Aquele 2nd hop tem a ver com a conecção a card do CMTS como ja tinha dito, e o CMTS é o que comunica a nossa fibra/coaxial hibrido (nos so temos fibra do poste até casa, o resto é coaxial) e os servidores da meo. Porque razão iria a meo mostrar assim só pq lhe apetece algo interno?
Reputação 3
whatever , por mim tá tudo optimo .


siga para bingo .
Boa noite, depois de muitas queixas, vieram a minha casa mudaram o router, resolveu o problema de velocidade e dos breakes da tv e pensei que fosse finalmente resolver o ping elevado, mas a partir das 21H esqueçam, joguei League of Legends as 18H e tive 60 ping, chegou as 21 fiquei com 170/180 ping fixo....
Honestamente esta situação já está, a meu ver, mais que analisada e a única constante em todos os casos é a elevada latência no peering em Amsterdam. No dia de hoje já estive com latências acima dos 200ms para o ams1 as quais continuam desde as 20h30. A solução para mim está cada vez mais a parecer óbvia: mudar o serviço para a NOS que utiliza a Level3 como peerings e que tendo testado com amigos, não apresenta anomalias.


 


O peering da PT, em Amsterdam, é de 30GE (podem ver aqui https://ams-ix.net/connected_parties).


 


Reports aqui no fórum ou ao "apoio ao cliente" da MEO a lado nenhum irão levar, nem contactos com o provedor. Aqui https://www.peeringdb.com/view.php?asn=8657&peerParticipantsPublics_mOrder=Sorter_name&peerParticipantsPublics_mDir=ASC estão contactos directos com a CPRM. Força, contactem-nos por aí! E-mails e contactos telefónicos estão lá disponibilizados.


 


Um pequeno à parte e apenas de forma humoristica: nem à uma hora atrás veio à minha residência um comercial da MEO, ora eu deveria era tê-lo feito aguardar e mostrar o porquê de estar a ponderar seriamente a mudança de ISP, que até está atualmente com pacotes mais em conta com a oferta.
Mais uma noite... isto já cansa
Reputação 2
pessoal, metam na cabeça que a ida de um tecnico a casa nada resolve acerca dos pings, porque isso afecta todos os users meo, nao tem nada a ver com o equipamento... É mudar de ISP e tá feito.
A rastrear a rota para mx1.eu.lol.riotgames.com [95.172.65.1]
até um máximo de 30 saltos:


1 1 ms 1 ms <1 ms dsldevice.lan [192.168.1.254]
2 * * * O pedido excedeu o tempo.
3 29 ms 20 ms 19 ms bl3-73-161.dsl.telepac.pt [213.13.73.161]
4 31 ms 18 ms 19 ms bt-cr1-hu-4-0-0.cprm.net [195.8.10.217]
5 * 110 ms 82 ms lon3-cr1-be2.cprm.net [195.8.0.242]
6 89 ms 79 ms 101 ms ge-0.linx.london03.uk.bb.gin.ntt.net [195.66.224
.138]
7 71 ms 88 ms 70 ms ae-3.r21.frnkge03.de.bb.gin.ntt.net [129.250.3.1
38]
8 67 ms 72 ms 68 ms ae-3.r02.frnkge04.de.bb.gin.ntt.net [129.250.4.5
4]
9 68 ms 68 ms 66 ms 212.119.15.6
10 68 ms 68 ms 76 ms border1.po2-8g-bbnet2.fra002.pnap.net [95.172.67
.65]
11 77 ms 70 ms 66 ms mx1.eu.lol.riotgames.com [95.172.65.1]


Rastreio concluído.


 


 


ja esta a fazer progressos
Reputação 3
talve entrando com o login da MEO no cprm e alterando a configuração dos peerings resulte . (ou talve não)


configuração de peerings pelo operador ?!!


 


Dá.me a entender que o problema são as rotas configuradas .


Por regra , as rotas poderão ser alternadas consoante a carga que um peering tenha .


Exemplo : portugal -> alemanha


por norma é tomado o caminho mais curto e menos sobrecarregado , podendo a rota ir a outros peerings de outros países até chegar ao destino .


O que se constata na MEO é que a rota é sempre a mesma não importando a carga que um peering tenha .


Por isso se tiverem 1000 clientes ou 10 clientes em frança ates de irem para a alemanha , o peering não faz o switch de rota , e talvez por isso os delays aumentem consoante as horas de ponta .
Reputação 1
Boas,


Pois para mim hoje ainda está pior, No CS Source estou com 180ms.


Tomem lá um print da ZON/NOS, que fiz há 10 minutos em casa dos meus pais.


SERVIDOR EM LYON (FRANÇA).


http://www.speedtest.net/result/3852209980.png


 


Acho que tenho de ir para lá viver outra vez.
Reputação 1
Olha... apagaram os post's que fiz no Facebook.


Pelos vistos não gostam...
guilherme_r escreveu:

A rastrear a rota para mx1.eu.lol.riotgames.com [95.172.65.1]
até um máximo de 30 saltos:


1 1 ms 1 ms <1 ms dsldevice.lan [192.168.1.254]
2 * * * O pedido excedeu o tempo.
3 29 ms 20 ms 19 ms bl3-73-161.dsl.telepac.pt [213.13.73.161]
4 31 ms 18 ms 19 ms bt-cr1-hu-4-0-0.cprm.net [195.8.10.217]
5 * 110 ms 82 ms lon3-cr1-be2.cprm.net [195.8.0.242]
6 89 ms 79 ms 101 ms ge-0.linx.london03.uk.bb.gin.ntt.net [195.66.224
.138]
7 71 ms 88 ms 70 ms ae-3.r21.frnkge03.de.bb.gin.ntt.net [129.250.3.1
38]
8 67 ms 72 ms 68 ms ae-3.r02.frnkge04.de.bb.gin.ntt.net [129.250.4.5
4]
9 68 ms 68 ms 66 ms 212.119.15.6
10 68 ms 68 ms 76 ms border1.po2-8g-bbnet2.fra002.pnap.net [95.172.67
.65]
11 77 ms 70 ms 66 ms mx1.eu.lol.riotgames.com [95.172.65.1]


Rastreio concluído.


 


 


ja esta a fazer progressos



 


Se queres testar a latência / route para os servidores de jogo da RIOT não é esse o endereço que deverás usar.


 


De momento, e pelo que vi na RIPE e para onde o client se liga, tens estas ranges:


83.71.194.0-31


185.40.64-67.*


162.249.76.0/22


162.249.72.0/22


 


Isto é as gamas que têm sido usadas para EUW, os servidores em Frankfurt não estão, aparentemente, a ser usados. Tenho também as gamas desses.


 


code:
root@server:~$ nmap -sP 83.71.194.0-31
Starting Nmap 6.46 ( [url=http://nmap.org]http://nmap.org[/url] ) at 2014-10-21 22:32 WEST
Nmap scan report for 83.71.194.10
Host is up (0.10s latency).
Nmap done: 32 IP addresses (1 host up) scanned in 7.26 seconds

root@server:~$ nmap -sP 185.40.64-67.*
Starting Nmap 6.46 ( [url=http://nmap.org]http://nmap.org[/url] ) at 2014-10-21 22:33 WEST
Nmap scan report for 185.40.64.66
Host is up (0.18s latency).
Nmap scan report for 185.40.64.67
Host is up (0.10s latency).
Nmap scan report for 185.40.64.86
Host is up (0.22s latency).
Nmap scan report for 185.40.64.87
Host is up (0.18s latency).
Nmap scan report for 185.40.64.163
Host is up (0.18s latency).
Nmap done: 1024 IP addresses (5 hosts up) scanned in 31.30 seconds

root@server:~$ nmap -sP 162.249.76.0/22
Starting Nmap 6.46 ( [url=http://nmap.org]http://nmap.org[/url] ) at 2014-10-21 22:40 WEST
Nmap done: 1024 IP addresses (0 hosts up) scanned in 50.03 seconds

root@server:~$ nmap -sP 162.249.72.0/22
Starting Nmap 6.46 ( [url=http://nmap.org]http://nmap.org[/url] ) at 2014-10-21 22:47 WEST
Nmap done: 1024 IP addresses (0 hosts up) scanned in 410.77 seconds

 


De momento para o ams1:


code:
ping 195.8.1.38
PING 195.8.1.38 (195.8.1.38) 56(84) bytes of data.
64 bytes from 195.8.1.38: icmp_seq=1 ttl=248 time=226 ms
64 bytes from 195.8.1.38: icmp_seq=2 ttl=248 time=208 ms
64 bytes from 195.8.1.38: icmp_seq=3 ttl=248 time=218 ms
64 bytes from 195.8.1.38: icmp_seq=4 ttl=248 time=220 ms
64 bytes from 195.8.1.38: icmp_seq=5 ttl=248 time=218 ms
64 bytes from 195.8.1.38: icmp_seq=6 ttl=248 time=220 ms
64 bytes from 195.8.1.38: icmp_seq=7 ttl=248 time=216 ms
64 bytes from 195.8.1.38: icmp_seq=8 ttl=248 time=222 ms
^C
--- 195.8.1.38 ping statistics ---
9 packets transmitted, 8 received, 11% packet loss, time 8010ms
rtt min/avg/max/mdev = 208.965/219.039/226.415/4.762 ms

 
Há cerca de dois/três anos andava com problemas num jogo online em que constantemente tinhamos acima de 200ms quando o normal seria cerca de 60ms.


Nessa altura falei com alguns responsáveis do jogo que me aconselharam a escrever para a CPRM. Resultado, eles estavam a routear o sinal para a Alemanha através de Washington (uma viagem grátis de ida e volta aos USA). Eles reconfiguraram o routeamento e explicaram-me que o caminho escolhido é, por norma, o mais curto e por mais curto entende-se o que passa por menos "saltos" e não o que percorre menos quilómetros ou o que tem o ping mais baixo. 


Provavelmente a solução estará mesmo em reclamar directamente para a CPRM novamente porque estou a ver que apenas lá podem fazer alguma coisa.
Reputação 3
Resultado, eles estavam a routear o sinal para a Alemanha através de Washington .



 


Eu lembro-me disso .


Isso éra assim porque a rota fica mais barata se passar pelos estados unidos .


 
Reputação 1
Boas,


Após ter conversado com 3 equipas técnicas, venho aqui fazer o resumo.


1ª Equipa Técnica (da linha de Apoio Técnico) o resultado foi como todos sabem igual a zero.


2ª Equipa Técnica (Técnicos de Assistencia Técnica de Rua) o senhor que veio a minha casa fez-me o favor, após ter pedido muito, para ele expor a situação ao director do departamento técnico encarregue da Internet e após a chamada (efectuada à minha frente) ele disse "pronto já está comunicado mas, segundo o que o director disse, se fosse eu, não tinha grandes esperanças que alguma coisa seja resolvida.


3ª Equipa Técnica (Da Manutenção dos Servidores PT/TELEPAC) Após análise em simultâneo comigo, eu a fornecer IP's e traceroutes, a senhora que me atendeu, no final disse que realmente existia um problema, que já tinha toda a informação que necessitava para preencher o relatório e que tinha acabado de enviar o relatório para a equipa de Engenharia que trata das interligações dos BackBones (CPRM).


Portanto se a equipa de Engenharia da CPRM já tem conhecimento, será uma questão de aguardar 48/72 horas. Ficaram de me ligar. Ainda não recebi chamada. (Isto foi ontem)


Caso isto não seja resolvido nos próximos dias, pois bem, tenho a dizer-vos para esquecerem a PT/MEO, pois eles nunca mais vão resolver o problema. (Se é que para eles isto será problema)


E só consegui chegar tão longe porque sou cliente empresarial.


 


Tenho mais dois serviços da NOS e esses estão cinco estrelas, como coloquei num post mais atrás.


O problema reside nos servidores de Interligação aos backbones de Fibra.


Os servidores que a PT usa são próprios, chamados CPRM, mas que pertencem à PT/MEO, ou seja, só não resolvem o problema se não quiserem.


A ZON/NOS contratou as interligações aos BackBones a uma empresa externa estrangeira chamada COGENT, que tem servidores de Interligação de backcones em todo o MUNDO, incluindo cá na "espinha dorsal " de fibra que temos em Portugal. Daí a ZON/NOS estar a funcionar 5 estrelas.


 


Cumprimentos a todos.
Reputação 6
Crachá +10
PLourenço escreveu:

O problema reside nos servidores de Interligação aos backbones de Fibra.


 



Sempre suspeitei. Se a MEO está a empatar os routings usando nós de interligação baratos, ou outro tipo de soluções que degradam a qualidade do serviço, no geral, não é justo para a maioria dos clientes. Náo podemos ser só exigentes para o lado que nos convem! Algo necessita ser feito urgentemente, por alguem encarregue pela gestão e requesição desses mesmos nós, o que pode muito bem, tambem siginificar que alguem terá de, precocemente, ignorar ordens superiores, mas fico-me por aqui...


 


Acreditem ou não, tambem sou gamer, só deixei de ter tempo, mas sei que pode ser frustrante jogar com latencia maior que os nossos companheiros de jogo e, estou um pouco solidario convosco.


 


Boa jogada, @@@PLourenço !


 


Parabens pelo post exemplar.
Boas,


 


Em anexo envio o traceroute efectuado por mim ao longo de quase um dia inteiro, a começar na meia noite de ontem, para os servidores europeus da Riot.


Como se pode ver, por volta das 20.30 existe um aumento brutal do ping para acima dos 150 ms, descendo as 22h mas voltando a subir pouco depois. Lá para as 23h já tende a estabilizar.


 


Isto foi só hoje, não quer dizer que seja 100% igual todos os dias. Não usei net quase nenhuma o dia todo só para não me atirarem desculpas ridículas como router longe, downloads, p2p, seja o que mais for.


 


Sendo uma situação que já dura alguns dias, não percebo como não existe nenhuma cláusula que obrigue a operadora a reparar isto em X dias, caso contrário o cliente tem direito à rescisão do contrato sem penalização. Basicamente estou à vontade da Meo por dois anos por uma **** de ADSL - como se custasse assim tanto fazer instalação disto.


 


http://i.imgur.com/2L0AMS0.png
Reputação 1
zuadao escreveu:
 

 

tipepe escreveu:

maxnuker :

o 2nd hop do traceroute tem a ver com a placa existente no CMTS, 

Do site official da Cisco:

The CMTS is a Cisco Universal Broadband Router (uBR) with features that enable it to communicate with a Hybrid Fiber Coaxial (HFC) Cable network via a Cisco MCxx cable modem card .


 

Se tu o dizes então devo ficar mais descançado  , lol .

Explica se puderes o porquê de estár anónimo .

É que em outros operadores isto não apareçe .

Será que a MEO é especial ?!!

 

 

porque o router esta defenido para bloquear pedidos ICMP

 

é feito assim normalmente para prevenir ataques com denial of service.

 

agora esta caladinho va...

Boas noites,

 

vocês os dois (maxnuker e zuadao) estão a gozar com todas a pessoas que passam por este tópico não é?

 

É que nenhum dos dois acertou numa única palavra daquilo que escreveu, apesar de as terem escrito com um tom de sabedoria incrível!!!!!

 

Em vez de mandarem estar calado quem não devem, calem-se os dois, caso pretendam continuar a dar informação errada e de qualidade duvidosa. Só demonstra a vossa ignorância no que toca ao assunto e equipamentos envolvidos no processo de acesso às redes que usam.

 

maxnuker:

 

CMTS é usado apenas em redes de cabo coaxial ou HFC (precisamente como diz a tua transcição da CISCO, se calhar devias usar outro tradutor porque esse tá estragado). CMTS é um Cable Modem Termination System e é usado pela NOS em ligações HFC (Hybrid Fiber Coaxial). São equipamentos localizados no head-end do operador que servem para terminar as ligações dos modems/routers de cabo usados (já ouviram falar em células de cabo e agredadores de ligações de cabo????), daí a sabedoria comum de que as ligações de cabo coaxial são partilhadas ao contrário das de fibra (vulgo FTTH, mas já lá vamos). O CMTS agrega e termina um número finito de equipamentos de cliente (CPE's, ou Client Premises Equipment) e liga a partir daí esses mesmos equipamentos à sua rede interna e backbones internacionais e nacionais (já perceberam o porquê da ligação partilhada em cabo???).

Nenhum deste tipo de equipamentos é usado em ligações FTTH (fibra até ao cliente), são única e exclusivamente dedicados a redes HFC.

 

zuadao:

 

não mandes calar alguém quando estás a dizer um asneira ainda maior do que aquele que mandas calar.

 

Para tua informação os routers da PT (sejam eles quais forem) vêm configurados de base para aceitar pedidos de ICMP numa série de portas e modos e códigos. O ping é um dos felizes contemplados nessa aceitação, bem como vários outros modos e códigos que a própria MEO (PT) necessita para poder diagnosticar remotamente todos os routers. 

 

Continuando a tua explicação, o facto de um determinado equipamento estar configurado para não aceitar pedidos de controlo ICMP não implica de maneira alguma a sua anonimidade na rede. Todo e qualquer equipamento que utilize protocolos NAT, TCP ou UDP acusa a sua existência. O facto de um pedido ICMP ser bloqueado apenas implica uma resposta negativa por parte do equipamento que se reflecte num número de erro ou código de erro seguido de um explicação para o mesmo (aconselho-te a ler bem o documento da wikipedia que alguém postou acima para te educares nestas lides), acusando sempre o seu IP público ou privado na rede a que pertence.

 

Agora para quem realmente quer saber o porquê do HOP 2 no traceroutes de ligações MEO Fibra (as ligações xDSL reportam sempre o HOP2):

 

O 2º HOP num traceroute com origem numa ligação MEO Fibra corresponde SEMPRE ao ONT (Optical Network Terminator). O ONT é considerado um terminal "Burro", que não incorpora nenhum tipo de protocolo de rede e não sabe fazer mais nada senão converter a luz recebida da fibra em impulsos eléctricos seja para o cabo coaxial (TV analógica) seja para o cabo de rede que vai ligar ao router. Este terminal, como disse, não incorpora nem entende NENHUM protocolo de rede e não tem nenhum tipo de IP associado (daí ninguém conseguir aceder directamente ao ONT por rede). Assim sendo seria de esperar que não responda a nenhum tipo de pedido de ICMP. Isto dito a anonimidade do HOP2 fica explicada, é anónimo porque é transparente na rede, PONTO FINAL PARÁGRAFO!

 

A segunda parte desta explicação serve só para entenderem porque é que ligações cabo ou HFC (NOS, Cabovisão, etc.) são consideradas partilhadas e as de FTTH (fibra MEO,Vodafone, etc) não são. Explicando:

 

No caso de linhas HFC a terminação de rede só é feita no head-end do operador por um CMTS onde são agregados vários CPE's (centenas?) que partilham a mesma largura de banda fornecida pelo CMTS. A autenticação é feita através do MAC Address do CPE no CMTS para que este último permita o acesso à rede do CPE.

 

No caso do FTTH a terminação da rede é feita directamente em casa do cliente. Não existe agregação de equipamentos de cliente e cada cliente tem um link de acesso directo e exclusivo à rede do operador. A autenticação do do cliente é feita através do protocolo PPPOE (PPP Over Ethernet) com username e password nos servidores BBRAS (Broadband Remote Access Server) onde dependendo do username e password vão ser atribuídas todas as configurações ao router do cliente. Todas as configurações de velocidade de UP e DOWN são também atribuídas pelo mesmo BBRAS. O mesmo é dizer que do ONT para a frente o cliente tem acesso à rede da PT através de uma linha dedicada e não partilhada, sendo que necessita autenticar-se no BBRAS para que as configurações da sua conta cliente sejam activadas e o seu equipamento possa aceder a "algo mais" (vulgo Internet) do que apenas a rede interna da PT.

 

maxnuke e zuadao, agora que já se educaram neste assunto, não chamem os outros de burros nem os mandem calar quando vocês próprios não sabem o que estão a dizer, ou pelo menos eduquem-se correctamente antes de o fazer e dizer asneiras trás de asneiras.

 

CURIOSIDADE: sabem porque é que todos os clientes Fibra 30, 100 e 200 têm sempre 20mbps de upload mesmo que o contrato não o diga? Porque a PT não consegue (ou não sabe ou não quer) configurar os seus BBRAS para atribuir menos upload do que 20mbps sem causar problemas no resto da rede.

 

Antes que me venham dizer que falo muito sem saber, posso por à disposição de quem quiser os meus certificados CISCO CCNA e Microsoft MSCE. Sou administrador e designer de redes de profissão.

 

Trocando a nota..... sou daqueles que trabalha em casa e sou cliente MEO Fibra do pacote TOTAL 400 na zona da Maia, sim, pago 180€ mensais à MEO/PT e também tenho problemas de latência alta em determinadas horas do dia, todas elas identificadas, assim como a origem do problema. Posso-vos dizer que normamelmente começa por volta das 21 (5 minutos mais cedo ou 5 minutos mais tarde) e termina por volta da 1 da manhã (quase sempre em ponto). Apesar de não jogar online por pura falta de tempo, utilizo várias aplicações e protocolos em tempo real que OBRIGATORIAMENTE precisam de respostas em PING abaixo dos 100ms, sendo que em alguns dias se torna pura e simplesmente impossível desenvolver qualquer tipo de trabalho em ligações MEO/PT.

 

O problema apesar de estar concentrado na CPRM (Companhia Portuguesa Rádio Marconi, que é detida a 100% pela PT/MEO) vai um pouco mais longe e está também na própria MEO e na forma como é feito o routing dependendo esse mesmo routing da pool de DHCP que estão a usar no momento. Mas essa explicação fica para o próximo post que este já vai demasiado longo.

 

Cumprimentos
A internet ontem e hoje esteve constante a 53 ms de ping e 0 ms de jitter para a alemanha, mas tenho as minhas duvidas que seja um ping um pouco alto para o meu pacote (total 100). Criei um topico a explicar e um dos colaboradores pediu me identificacao de cliente para averiguar da situacao, isto a cerca de 2 dias ate agora nada.
Reputação 1
@@@Houls "Agora para quem realmente quer saber o porquê do HOP 2 no traceroutes de ligações MEO Fibra (as ligações xDSL reportam sempre o HOP2)"


 


Tenho ADSL e o segundo hop dá sempre timeout.
Reputação 3
Uma questão que vem no abito do post do PLourenço e do NeoPT isso tambem pode afectar os utilizadores de ADSL?


Tal como referi anteriormente, hoje tive um tecnico ca em casa durante quase 2 horas, no seguimento da minha exposição do caso a provedoria da PT, onde a minha ligação a net ca em casa foi completamente refeita, puseram fios novos, separaram o telefone da ADSL de forma a não perder largura de abnda, e ainda me deram um router novo completamente configurado, no final o técnico recebido recentemente uma informação que tem existido problemas de congestionamento na central e que eles tem recebido ultimamente muitas queixas com a mesma situação, disse ainda que neste a uns meses para ca a PT está a fazer a migração parte das suas ligações da sua central das Picoas para a Covilhã e que isso poderá uma das origens dos problemas mas o este assunto já foi detectado e esta a ser resolvido, poderá isto estar relacionado com a situação? No final o técnico disse que caso o problema continua, para aguardar 1 ou 2 dias, sendo que é o prazo mais ou menos que o técnico me deu para a situação ficar resolvida, e voltar a contactar a procuradoria, pois muito provavelmente o problema já não será responsabilidade dos serviço técnicos da PT, mas sim de outro departamento sendo que eles encaminham o caso para o departamento responsável, sendo que o caso esta a ser acompanhado pela procuradoria


E caso então esse seija o problema, o que é que nos, podemos fazer? Vale a pena fazer uma exposição por escrito a CPRM?


 


PS. apesar da vinda do tecnico os pins altos continuaram até as 23:30
Reputação 1
NeoPT escreveu:

PLourenço escreveu:

O problema reside nos servidores de Interligação aos backbones de Fibra.


 



Sempre suspeitei. Se a MEO está a empatar os routings usando nós de interligação baratos, ou outro tipo de soluções que degradam a qualidade do serviço, no geral, não é justo para a maioria dos clientes. Náo podemos ser só exigentes para o lado que nos convem! Algo necessita ser feito urgentemente, por alguem encarregue pela gestão e requesição desses mesmos nós, o que pode muito bem, tambem siginificar que alguem terá de, precocemente, ignorar ordens superiores, mas fico-me por aqui...


 


Acreditem ou não, tambem sou gamer, só deixei de ter tempo, mas sei que pode ser frustrante jogar com latencia maior que os nossos companheiros de jogo e, estou um pouco solidario convosco.


 


Boa jogada, @PLourenço !


 


Parabens pelo post exemplar.



Boas,


 


posso confirmar o que foi dito pelo PLourenço, sendo que a explicação técnica não se fica por aí nem é o mais correcta possível.


 


O problema reside de facto nas ligações aos backbones, mas ao nível dos routers instalados em três zonas da Europa e não nos servidores. Todas as ligações de saída internacional vão dar a 3 sítios específicos na Europa - Londres no LINX, Amsterdão no AMS-IX e a Frankfurt no F-IX - depois de passarem no GigaPIX nacional.


 


O problema pode ter duas ou três explicações possíveis, que são de fácil resolução caso a PT o queira fazer. 


 


1- Os routers instalados nos 3 exchanges internacionais onde a PT está presente estão a ficar completamente atolados e no limite das capacidades face ao número crescente de clientes, e em horas de maior utilização (normalmente das 21 horas até à 1 hora do dia seguinte) "arreiam" chegando ao limite de tráfego que podem aceitar e entrando em overload fazendo com que todas as tarefas de routing sejam afectadas por delays (pings altos). Solução fácil.... actualizem os equipamentos que detêm nestas instalações e os problemas desaparecem. Ainda há pouco mais de um ano a OVH teve esse mesmo problema na sua rede nos routers que tinha no LINX em Londres com picos a certas horas do dia a levar os routers a cerca de 92% das suas capacidades... actualizou os equipamentos, comprou mais dois links de 10gbps entre Roubaix e Londres e deixou de permitir certos comportamentos dentro da sua rede, resultado..... voltou a ter a melhor conectividade europeia ao LINX.


 


2 - A PT decidiu que fazer traffic shapping e bandwidth throttling aos seus clientes era uma boa ideia para poupar tráfego e recursos de rede, nas horas de pico de utilização, e reconfigura automaticamente os seus router no exchanges para atrasar as ligações na sua rede. Solução fácil para o operador que tem a sua dimensão...... deixa de fazer TS e Throttling tóxico e compra mais um ou dois links para cada um dos exchanges onde tem presença.... A Virgin Media em UK assim o fez e em menos de mês e meio viu os seus clientes novamente satisfeitos e a recomendar a operadora (apesar de que o maior dos problemas da Virgin eram erros de roteamento para redes específicas na Europa e em particular no AMS-IX).


 


3 - Existe um "problema" (as aspas são propositadas) de roteamento e má gestão do mesmo em toda a rede de fibra da PT. Dependendo da pool de DHCP que cada cliente está a usar em determinado momento o roteamento do tráfego está a ser feito de forma diferente e através de diferentes exchanges europeus para chegar exactamente ao mesmo sítio, numa tentiva de poupança de alguns "trocos" no tráfego contratado a providers internacionais. Posso dar como exemplo a minha experiência:


Trabalho com vários datacenters na Europa (RapidSwitch em Londres, BlueSquare em Londres e Reading, Portlane na Suécia, OVH em Roubaix (RBX1 e RBX2), Softlayer em Amsterdão, Leaseweb em Amsterdão, etc.) e dependendo da pool de DHCP que a minha ligação estiver a usar todo o meu tráfego é roteado por exchanges diferentes. Caso eu esteja a usar um IP da pool 2.8X.**bleep**.**bleep** sou roteado para Amsterdão directamento através de peering pelo AMS-IX, mas se estiver a usar um IP da pool 188.82.**bleep**.**bleep** sou roteado primeiro para Frankfurt pelo F-IX que por sua vez me manda para o AMS-IX, para chegar exactamente ao mesmo sítio anterior. Escusado será dizer que as diferenças em respostas de ping saltam de 47ms directo no AMS-IX para 125ms quando passa primeiro no F-IX.


 


Solução fácil...... contratem quem saiba o que está a fazer e não tentem poupar trocos no que toca a trânsito de IP!!!!!


 


Depois disto tudo devo referir que nos últimos dias, em maior ou menor escala, todos os pontos de exchange da PT/CPRM têm sofrido bastante com este problema, sendo que o mais afectado nos últimos dois dias tem sido o router de de Londres no LINX. Hoje, por incrível que pareça, a ligação ao AMS-IX manteve-se mais ou menos aceitável apesar de algumas variações que causaram jitters temporários nos pings de mais de 50ms.


 


Não ponho de parte a hipótese de que os servidores de agregação de fibra da PT também possam estar com problemas, pois para meu espanto, na segunda-feira dia 20, até a ligação à NFSI.pt em Lisboa no datacenter da Telvent estava com pings a rondar os 200ms a partir da fibra da PT, sendo que o provider de transito da NFSI é a Cogent. Esta situação levou-me a crer que existe um problema muito maior dentro da infra-estrutura da PT, seja ele derivado da recente migração que está a ser feita do Picoas para a Covilhã, da preparação da infra-estrutura de fibra para receber a Vodafone ou pior ainda que seja "azelhice" de quem esta empresa contrata.


 


Devo também esclarecer que todos os equipamentos identificados por ".cprm.net" que vocês vêm nos traceroutes, são router instalados em pontos de troca (exchanges) e não estão em território nacional.


 


Caso queiram, posso postar alguma da informação que fui recolhendo estes dias, com pings e traceroutes efectuados da rede PT para os pontos que referi acima, bem como em sentido contrário (da Europa para a PT).


 


Cumprimentos
"Tenho ADSL e o segundo hop dá sempre timeout."


 


epá pois é... e agora??


 


talvez o administrador e designer de redes de profissão nos eduque novamente
Reputação 1
oem escreveu:

@Houls "Agora para quem realmente quer saber o porquê do HOP 2 no traceroutes de ligações MEO Fibra (as ligações xDSL reportam sempre o HOP2)"


 


Tenho ADSL e o segundo hop dá sempre timeout.



Timeout não é o mesmo que anonimidade. Ele identifica-te o IP (aí vai depender do software que usas para fazer o traceroute) apesar de não responder (Timeout é um dos códigos contemplados no protocolo ICMP, anonimidade não).


 


O ONT pura e simplesmente não é identificado . Como disse em cima dependendo do software que uses para fazer o trace, a diferença está entre receberes um TIMEOUT e não receberes absolutamente nada.


 


EDIT: deixe-me corrigir um possível erro chamando a atenção para que o HOP2 em XDSL poderá em alguns casos ser identificado como sendo o DSLAM da central que por default não responde a pedidos ICMP.


 


Já agora aproveito o edit para dizer que não sou funcionário nem tenciono ser funcionário da PT.


 


Cumprimentos
Houls, nao me acredito na 1ª nem na 2ª


 


isto aconteceu de um momento para o outro, portanto lotação não me parece que seja.


 


ja havia aqui no forum posts a condenar o traffic shapping e bandwidth throttling, pelo que tambem por ai nao deva ser problema.


 


so fica a sobrar a 3ª opção
Houls escreveu:

oem escreveu:

@Houls "Agora para quem realmente quer saber o porquê do HOP 2 no traceroutes de ligações MEO Fibra (as ligações xDSL reportam sempre o HOP2)"


 


Tenho ADSL e o segundo hop dá sempre timeout.



Timeout não é o mesmo que anonimidade. Ele identifica-te o IP (aí vai depender do software que usas para fazer o traceroute) apesar de não responder (Timeout é um dos códigos contemplados no protocolo ICMP, anonimidade não).


 


O ONT pura e simplesmente não é identificado .


 


Cumprimentos



e o que aconteceu então ao ont?

Responder