6

(Это может быть лучше ответил на сервере, но технически это не касается сервера, поэтому предложения приветствуются ...)

Мы просто переехали в офис на работу. Мы находимся в Кембридже, штат Массачусетс, и у нас есть кабельный модем Comcast бизнес-класса. Раз в несколько дней, в течение большей части дня, у нас возникают проблемы с посещением некоторых, но не всех веб-сайтов, например Slashdot. Так случилось, что я живу в трех милях от офиса, и у меня дома есть кабельный модем Comcast бизнес-класса. С работы я могу зайти на свой сервер дома, и хотя я прохожу через одни и те же маршрутизаторы - и все те же общие POP - у меня нет этих проблем из дома.

15 лет назад я знал, как решить эту проблему, позвонить в НОК и выяснить это. В настоящее время, с балансировщиком нагрузки и виртуальными IP-адресами, я в тупике. Я попытался связаться с Саввисом с приведенными ниже следами, и они сказали: «Это не мы». Я отправил их в Slashdot, и, конечно же, никакого ответа - но это не просто проблема Savvis и не проблема Slashdot в любом случае.

Мы также иногда видели потерю пакетов на 10-30% при пинге Google 8.8.8.8; Я не знаю, возникает ли проблема в то же самое время, и у меня нет никаких неисправных трассировок для этого в настоящее время, но успешный трассировочный маршрут оставляет 111eighthave.ny.ibone.comcast.net и идет прямо в Google, не нажимая Savvis.

Сбой traceroute из офиса:

~% 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 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

1 ответ1

2
  1. Просто отметим: icmp-тесты (traceroute | ping) не всегда точны и корректны - у вас может быть успешное TCP-соединение с конечной точкой, но отфильтрованы ICMP-ответы от некоторых прыжков (включая пункт назначения), и вы не можете обнаружить (легко) - тайм-аут или подавленный эхо-ответ
  2. То же физическое местоположение источника для вас не означает одинаковые сети (я не вижу офисный IP, но полагаю, что он должен быть в 68.87.3? сеть где-то, но home-net - 73.164.80.) и те же AS (автономные системы), которые являются основой маршрутизации (если я напишу это в простейшей форме и опущу NOC-детали)
  3. Для устранения неполадок вы можете проверить подключение icmp-tcp (как вы делали раньше, но для 2 типов предпочтительнее), знать (лучше) AS целевого объекта, AS хорошего источника и AS плохого источника и разместить заявку на поддержку @ что-л. рядом с "Обнаружена проблема с подключением к AS X из AS Y вашей области ответственности, в то время как ваша AS Z не отображает проблему такого же типа". В случае одного и того же AS для хорошего и плохого источника достаточно только сетей.
  4. "Это не мы" - это не ответ NOC !!! Вы можете прочитать SLA, чтобы иметь юридические инструменты, или просто потребовать (если можете) "эскалации проблемы" для руководства или соседей по маршруту

НТН

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .