Como faço para solucionar problemas de roteamento à distância na Internet?

Question

(Isso pode ser melhor respondido no serverfault, mas não é tecnicamente sobre um servidor, então sugestões bem-vindas ...)

Acabamos de mudar de escritório no trabalho. Estamos em Cambridge, MA, e temos um modem a cabo da classe Comcast. Uma vez a cada poucos dias, durante a maior parte do dia, temos dificuldade em acessar alguns sites, mas não todos, por exemplo, o Slashdot. Por acaso, moro a cinco quilômetros do escritório e também tenho um modem a cabo da classe Comcast em casa. Do trabalho, posso ssh em meu servidor em casa, e embora eu passe por alguns dos mesmos roteadores - e todos os dos mesmos POPs gerais - eu não tenho esses problemas em casa.

15 anos atrás, eu sabia como solucionar isso e chamar NOCs e descobrir. Hoje em dia, com balanceadores de carga e IPs virtuais, fico perplexo. Eu tentei entrar em contato com Savvis com os traceroutes abaixo, e eles disseram "não somos nós". Enviei-os para o Slashdot e, claro, sem resposta - mas não é apenas um problema do Savvis e não apenas um problema do Slashdot.

Também vimos ocasionalmente 10-30% de perda de pacotes ao executar ping no 8.8.8.8 do Google; Eu não sei se o problema ocorre ao mesmo tempo, e eu não tenho nenhum rastreamento falho para isso no momento, mas um traceroute bem-sucedido deixa 111eighthave.ny.ibone.comcast.net e vai direto para o Google sem bater no Savvis.

Falha no rastreamento do escritório:

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 hops max, 52 byte packets
 1  * * *
 2  te-7-1-ur01.cambridge.ma.boston.comcast.net (68.87.36.241)  10.628 ms  7.029 ms  14.147 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  10.648 ms  13.714 ms  13.754 ms
 4  pos-2-1-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.95.29)  20.171 ms  18.774 ms  17.866 ms
 5  pos-1-6-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.87.110)  20.177 ms  18.549 ms  18.130 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  20.854 ms  19.490 ms  16.720 ms
 7  cr1-tengig-0-8-3-0.newyork.savvis.net (204.70.198.13)  15.856 ms  20.863 ms  16.717 ms
 8  cr2-tengig-0-0-2-0.chicago.savvis.net (204.70.196.242)  59.632 ms  47.147 ms  52.665 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  40.771 ms  55.918 ms  39.418 ms
10  das4-v3044.ch3.savvis.net (64.37.207.206)  45.907 ms  45.159 ms  46.643 ms
11  64.27.160.198 (64.27.160.198)  42.509 ms  39.425 ms  67.412 ms
12  * * *
13  * * *
14  * * *
15  * * *

Traceroute bem sucedido em casa:

~% traceroute slashdot.org
traceroute to slashdot.org (216.34.181.45), 64 hops max, 52 byte packets
 1  73.164.80.1 (73.164.80.1)  10.194 ms  13.718 ms  9.876 ms
 2  te-7-4-ur01.cambridge.ma.boston.comcast.net (68.85.160.17)  9.680 ms  6.937 ms  9.150 ms
 3  be-51-ar01.needham.ma.boston.comcast.net (68.85.162.157)  8.392 ms  7.986 ms  8.621 ms
 4  pos-2-2-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.93.185)  16.350 ms  18.983 ms  19.961 ms
 5  pos-1-4-0-0-pe01.111eighthave.ny.ibone.comcast.net (68.86.86.194)  17.208 ms  16.946 ms  20.909 ms
 6  er2-tengig3-3.newyork.savvis.net (208.173.138.13)  16.934 ms  18.493 ms  23.790 ms
 7  cr2-tengig-0-15-4-0.newyork.savvis.net (204.70.198.17)  26.530 ms  16.009 ms  14.924 ms
 8  cr2-pos-0-7-3-0.chicago.savvis.net (204.70.192.109)  40.031 ms  39.496 ms  39.807 ms
 9  hr2-tengigabitethernet-12-1.elkgrovech3.savvis.net (204.70.195.122)  41.065 ms  45.294 ms  41.091 ms
10  das3-v3039.ch3.savvis.net (64.37.207.186)  47.867 ms  40.606 ms  40.157 ms
11  64.27.160.194 (64.27.160.194)  50.774 ms  56.097 ms  51.147 ms
12  slashdot.org (216.34.181.45)  39.788 ms  41.741 ms  39.871 ms

    

Answer 1

1. Apenas para observar: icmp-tests (traceroute | ping) não é sempre preciso e correto - você pode ter uma conexão TCP bem-sucedida com endpoint, mas filtrou respostas ICMP de alguns saltos (incluindo destino) e você não tem capacidade de detectar (fácil) - é o tempo limite ou resposta de eco suprimida
2. O mesmo local de origem físico para você não significa as mesmas redes (não consigo ver o IP do escritório, mas suponho que ele esteja na rede 68.87.3? em algum lugar, mas em rede doméstica é 73.164.80.) e mesmo AS (Sistemas Autônomos), que são a base do roteamento (se eu escrevê-lo da forma mais simples e soltar os detalhes do NOC)
3. A fim de solucionar problemas, você pode verificar a conectividade icmp-tcp (como você fez antes, mas para 2 tipos é mais preferível), saber (é melhor) AS de destino, AS de boa fonte e AS de origem incorreta para apoiar @ smth. near "Detectou o problema de conectividade para o AS X de ASY da sua área de responsabilidade, enquanto o seu AS Z não mostra o mesmo tipo de problema". No caso do mesmo AS para boas e más fontes, apenas as redes são suficientes.
4. "Não somos nós" não é resposta ao NOC !!! Você pode ler o SLA para ter ferramentas jurídicas ou apenas exigir (se puder) a "escalada do problema" para a administração ou para os vizinhos ao longo da rota

HTH