Alta latência devido à não presença de um provedor de trânsito no meu país

Question

Meu ISP, um operador estatal, compra largura de banda de diferentes provedores de trânsito. Sempre que compra trânsitos, anuncia apenas um prefixo específico (na maioria dos casos, até então não utilizado) através do novo trânsito AS. Por exemplo, se ficar sem largura de banda, ele compra largura de banda de um novo tráfego e anuncia um novo prefixo, enquanto o mesmo prefixo não é anunciado (ou anunciado com métricas mais baixas, de modo que as rotas são raramente usadas) pelos antigos trânsitos que continue a fornecer largura de banda a ele. Eu sou um cliente de negócios, então eu tenho um link de fibra para o ISP e uma pequena sub-rede me é dada.

A sub-rede que me é fornecida faz parte de um prefixo que é anunciado pelo AS de um trânsito que, ao que parece, não tem presença no meu país. Então, quando eu faço um rastreamento dos pacotes, quando eles saem do AS do meu ISP, eles demoram cerca de 275ms para chegar ao roteador principal dos provedores de trânsito, que está localizado nos EUA (metade do mundo de distância). Também para tráfego upstream, meu ISP usa um provedor de transporte público (nível 1) que tem uma presença em meu país. Mas o caminho de retorno é sempre através do trânsito que está nos EUA.

Portanto, a latência média é de 400 ms. Todos os usuários de outros ISPs do meu país descobrem minha sub-rede via EUA. Até mesmo o tráfego dos países vizinhos, da Europa (que é muito mais próximo) segue o caminho via EUA. Sites usando CDNs também resolvem ips nos EUA.

Eu informei o ISP NOC sobre o assunto e pedi que ele fornecesse uma sub-rede ip pertencente a um prefixo anunciado por um trânsito local (de preferência um provedor de transporte de nível 1) e estou aguardando uma resposta. Minha pergunta: é um problema sério que devo seguir para resolvê-lo? Quando comparo a latência em outros provedores em meu país, na maioria dos casos, isso é menos da metade da latência de meus provedores. Por que meu ISP não anuncia todos os seus prefixos para todos os seus provedores de trânsito, de modo que os pacotes possam levar rotas eficientes e mais próximas para alcançar prefixos originados dentro de sua rede?

    

Answer 1

Is it a serious issue that I must follow up to get it resolved?

Sim, essencialmente, seu provedor está oferecendo conectividade ruim. Todos os clientes esperam que seu tráfego seja roteado dentro de seu próprio continente primeiro. Então, se você está na Índia e os clientes típicos indianos / europeus precisam atravessar o oceano duas vezes para atingir seus servidores, esse é um grande problema.

When I compared the latency on other providers in my country, it is, in most cases, less than half of my ISPs latency. Why my ISP doesn't announce all its prefixes to all of its transit providers, so that the packets can take efficient and nearest routes to reach prefixes that originate within its network?

Isso geralmente se resume a (escolha um ou mais):

• Eles não conseguiram verificar se o seu upstream anuncia seus prefixos para outros NAPs em seu continente; talvez eles tenham um engenheiro júnior lidando com suas políticas de BGP que não tenham ideia do que ele precisa verificar depois de fazer alterações na política de roteamento
• Eles estão tentando equilibrar a carga do tráfego para minimizar os custos (porque pagam por Mbps em trânsito)
• O upstream (neste caso, C & W) decidiu alterar suas próprias políticas de roteamento de saída e o VSNL não sabia

EDITAR:

Na verdade, o seu provedor parece estar anunciando a supernet para pelo menos dois upstreams diferentes: AS 1273 e AS 4755 (VSNL)

route-views>sh ip bgp 117.240.120.0
BGP routing table entry for 117.240.112.0/20, version 1257325932
Paths: (35 available, best #26, table Default-IP-Routing-Table)
  Not advertised to any peer
  3277 3216 1273 9829  <------------------------------------------- C&W
    194.85.102.33 from 194.85.102.33 (194.85.4.4)
      Origin IGP, localpref 100, valid, external
      Community: 1273:11840 3216:3000 3216:3001 3277:3216
  6539 1273 9829
    66.59.190.221 from 66.59.190.221 (66.59.190.221)
      Origin IGP, localpref 100, valid, external
  4436 1273 9829
    69.31.111.244 from 69.31.111.244 (69.31.111.244)
      Origin IGP, metric 186, localpref 100, valid, external
      Community: 1273:11840 4436:31611
  101 101 11164 22822 1273 9829
    209.124.176.223 from 209.124.176.223 (209.124.176.223)
      Origin IGP, localpref 100, valid, external
      Community: 101:20100 101:20120 101:22100 11164:1170 11164:7790
      Extended Community: RT:101:22100
  3549 1299 1273 9829
    208.51.134.254 from 208.51.134.254 (67.17.81.150)
      Origin IGP, metric 1, localpref 100, valid, external
  2828 6453 4755 9829  <------------------------------------------- VSNL
    65.106.7.139 from 65.106.7.139 (66.239.189.139)
      Origin IGP, metric 3, localpref 100, valid, external
  16150 1299 1273 9829
    217.75.96.60 from 217.75.96.60 (217.75.96.60)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 1299:20000 16150:63392 16150:65326
  2914 1273 9829
    129.250.0.11 from 129.250.0.11 (129.250.0.12)
      Origin IGP, metric 37, localpref 100, valid, external
      Community: 2914:420 2914:1005 2914:2000 2914:3000 65504:1273
  1239 1273 9829
    144.228.241.130 from 144.228.241.130 (144.228.241.130)
      Origin IGP, localpref 100, valid, external
  3333 1273 9829
    193.0.0.56 from 193.0.0.56 (193.0.0.56)
      Origin IGP, localpref 100, valid, external

route-views>

O rastreamento de um dos meus servidores nos EUA (Texas) me leva pelo Pacífico e pelo AS 4755 (VSNL ) :

[mpenning@Bucksnort ~]$ sudo lft -A 117.240.120.67

Tracing _________________________________________________________________________

TTL  LFT trace to 117.240.120.67:80/tcp
 1   [ASxxxxx] REDACTED 0.4ms
 2   [ASxxxxx] REDACTED 0.4ms
**   [neglected] no reply packets received from TTL 3
 4   [AS174] te0-1-0-7.ccr22.dfw01.atlas.cogentco.com (154.54.0.121) 0.7ms
**   [neglected] no reply packets received from TTLs 5 through 6
 7   [AS174] teleglobe.dfw03.atlas.cogentco.com (154.54.13.134) 0.9ms
 8   [AS6453] if-2-2.tcore2.DT8-Dallas.as6453.net (66.110.56.6) 261.0ms
 9   [AS6453] if-3-2.tcore1.LVW-LosAngeles.as6453.net (66.110.57.62) 262.0ms
10   [AS6453] if-2-2.tcore2.LVW-LosAngeles.as6453.net (66.110.59.2) 263.6ms
11   [ASN?] if-7-2.tcore2.SVW-Singapore.as6453.net (180.87.15.25) 267.2ms
12   [ASN?] if-5-2.tcore2.CXR-Chennai.as6453.net (180.87.15.70) 270.7ms
13   [ASN?] 180.87.37.46 272.8ms
**   [neglected] no reply packets received from TTL 14
15   [AS4755] 59.163.206.158.static.chennai.vsnl.net.in (59.163.206.158) 295.7ms
16   [AS9829] 218.248.237.161 296.7ms
**   [80/tcp failed]  Try alternate options or use -V to see packets.

[mpenning@Bucksnort ~]$