ussr1990: Мб мы с вами на разных языках говорим но мне кажется вы меня не до конца поняли или я вас.
Насчёт фаеров спорить не буду ибо некомпетентен,сделал только предположение.
Видимо я путаю фаер с чем то более примитивным, но вот например ovh.com из под виндовс стандартными средствами не пингуется из программы(приложения к главной программе) на ура,хотя она как бы не пингует,её основная функция трэйс а пинг также как из cmd побочное явление.
Нащёт ICMP я как раз таки вроде бы понимаю вас,видел даже в этой проге да и не только такое когда например из 12 узлов скажем 8 узел не виден но он есть.В cmd-tracert будут звёздочки естественно в этом случае.
В общем вот что вы мне пытаетесть расссказать на скрине: Не про это шла речь,речь была в том что идут таймауты на работающем и видимом узле(вот что я пытаюсь сказать),таймауты эти были не всегда а возникали с определённой переодичностью..
Про функционал этой программы я вкурсе, считаю что прилагаемая к ней утилита очень удобна.
Есть ли какие то способы точно определить проблему если мой метод настолько примитивен и не в "тему"(просто очень интрестно),как бы вы поступили?
С Удовольствием бы поделился своим методом с вами, но боюсь это будет немного не честно, у меня более 6 лет опыта работы на должностях из серии "Unix Системный Администратор"/"Менеджер отдела Системных Админов".
По этому мой метод проверки разведет еще больший оффтоп в теме, разговор действительно отошел от основного русла, мочите хостера!!!!!! :D :D :D
"Определить проблему" может только инженер узла о котором мы говорим, клиент может только предполагать и делать какие-то собственные заключения из анализа происходящего.....
Я кстати уже предложил более интересный и "правильный" вариант проверки "работоспособности сайта", меня лично не интересует что там случилось, кабель порезали или винт сгорел или или или, меня интересует доступность моего ресурса.
Концепция проверки: конектимся на 80 , делаем GET запрос своего сайта, данные (код ответа сервера, время ответа) анализируем , выполняем результат в зависимости от анализа...
На сегодня я знаю как минимум 10 средств из серии (cacti, nagios, zabbix), последний даже есть в виде бинарей для win32, которые имеют шаблоны мониторинга FTP / HTTP / и других сервисов... Ну я вообще молчу что можно написать php / perl скриптик в 10 строк который будет делать тоже самое и повесить его в cron :))
В результате проверки мы получаем ответ в любом виде, хоть в процентах в месяц, сколько был недоступен веб сервер..... когда... какие периоды, можно даже графики строить.... если вы говорите о наблюдениях в течении более часа... полагаться на ICMP вообще нет смысла, процент потерь между "миром" выхватите в любом случае ...... Но главное , что мы будем точно знать, что мы мониторили тем же методом (запросом) как и браузер в случае клиента который посещает ваш сайт, а вы опираетесь на не совсем относящиеся к конкретному сайту tracert и ping ... в результате на срезе в 1 сутки например понимаем, что мы не пингали 50% времени сайт, потому что сработала система какая-то и залочила ICMP... потому что регулярность под ее фильтры попала....... Но это же не означает что перестал работать сайт :))))
Явно что то на стороне хостера,видно что маршрут то и дело переключается а порой таймауты адские и причём они могут таки пропасть всё на томже узле где были, тобишь это не настройки маршрутизаторов такие...
Я не утверждаю, что проверяемый хост 200% стабилен, вы не подумайте, я лишь как технический специалист поправил вас в том, что анализ доступности хостера путем PING это все равно что кидать камешки в реку и ждать пока она из берегов выйдет :)))) Результат не может быть достоверным по ряду причин, во первых доставку echo запросов и ответов ни кто не гарантирует, во вторых не исключено что на маршруте в 11 хопов кто-то не режет ICMP просто потому-что....
Программа которая щупает сквозь файрволы :))) ? Любопытно аж до не могу :)) Как же этой ей удается? :) Поделитесь технологией ?:)
traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP. Traceroute основана на протоколе ICMP.
Так что от ICMP мы далеко не уехали , если я пожелаю вы не увидите ни одного хоста в трейсроуте внутри моей сети, а так же сам мой пограничный маршрутизатор, в tracert У вас будут звездочки, но это не коем образом не мешает мне отдавать с того же сервера (подсети) сайты в полном объеме. Мало того, в моем ведении еще получается вариант ответа который вы увидите :))) Может быть timeout может быть unreachable, А может быть и prohibited...
Так что не советую вам в будущем штурмовать провайдера услуг опираясь на ICMP ping .... ;) Я понимаю вы бы посмотрели таблицу маршрутизации BGP мировую и зафиксировали изменения маршрутов для этой автономной системы, в таком случае можно было бы утверждать что меняя маршруты хостер меняет физику включения, а именно какие-то проблемы с основным каналом или с одним из каналов...
P.S: Если я не ошибаюсь то основная задача указанного вами софта это поиск игровых серверов, а функции ping / tracert там для удобства клиента... Это сути описанного не меняет, но выглядит странновато ;)
Добавлено:
Изучив более детально ваш скриншот я заметил , что изменение маршрута таки фиксируется, черным блоком на графике, но видимо новый маршрут не отображается, до чего же я люблю "mtr" показывается даже направление асимметричного трафика, а тут как-то не понятно, например могу предположить, что программа не стала показывать "Другой маршрут".... после того как пропал линк с первым.... не ясно что вложили её разработчики (или может быть даже переводчики) в смысл "Другой маршрут"...
Если вас интересует работа сайтов с конкретного ИП я бы рекомендовал мониторить на прикладном уровне OSI, т.е сделать мониторинг 80 го порта к примеру... потому, что исходя из логики в случае с хостингом клиенту все равно, через какой канал и как он запущен (я не говорю про клиентов чей трафик зависит от паритетных каналов городских или регональных), клиента интересует что бы его сайт отображался... по этому говоря техническим языком нам надо что бы на 80м порту указанного ИП отвечал наш сайт при условиях его запроса, вот и скажите мне, зачем при этом мониторить возможность прохождения ICMP пакетов сквозь всю цепочку, если нас предельно точно интересует 80/TCP ?!
ussr1990: Всмысле? Я написал что мониторил этот ip в течении 20 минут, примерно 98% из этого времени были таймауты.
Возможно я чего то не понимаю (так как не спец в этой области ,но базовые навыки имею),если это так поясните.
Поясняю, совсем не обязательно IP адрес на котором расположен сайт должен пинговаться, так же пограничные маршрутизаторы провайдеров в большинстве случаев не отвечают на ICMP запросы, а в редких случаях могут быть настроены на определенное кол-во таких запросов от одного адресата, таким образом чем дольше вы долбите ... тем хуже вам видно ;) Но это касается ICMP протокола.
В общем к чему это я , показатель пингов.... это в общем-то не показатель .... В совокупности с другими данными... да... может быть.... но вы приводите только маршрут который на "последнем хопе" показывает потери ICMP запросов, а что у вас в этот момент с TCP происходит в ту же сторону? Где показатели? Да с ICMP явно проблемы, но к работе сайтов это в принципе отношения не имеет. Могу для вас модулировать такую ситуацию, что бы вы убедились... на графике будет точно такая-же "красная лента"... а сайт вы будете открывать с максимальной скоростью канала доступного между нами....
Пишите хостеру гневное письмо,можете сами сделать трэйс и передать хостеру если не отреагируют сваливайте от них,бывает иногда поднимается канал но не надолго покрайней мере за 20 минут которые я его мониторю...
Antonsad: Romka_Kharkov ок, я попрошу сделать эти шаги. дело в том что на американском хосте стояли эти сайты, они норм их видели, 2 недели назад перенес, и до сих пор Индия не может достучаться....
Все может быть, я же говорю дело скорее всего в недоступности ДНС (как я вижу), но вполне может быть и что-то другое.... я ж почему и спросил, по ИП достучаться из Индии можно ? минуя ДНС... Я еще не исключал варианта, что не работает на компьютере ваших клиентов что-то ;)
Antonsad: Добрый день.
Вроде бы угадал с темой...
Сайты не работают в Индии, пишет не найден сервер, хотя в других странах все отлично. все сайты которые расположены на этом акке не работают там. Хостер говорит что нет никакой блокировки по IP .
В чем может быть проблема?
Исходя из описанного я бы порекомендовал вам связаться с вашими клиентами в индии , и попросить их сделать:
A) traceroute yourdomain.com (or IP)
B) ping yourdomain.com (or IP)
C) tracert & ping to domain DNS ns1/ns2.yourdomain.com (или как там у вас).
D) прямые запросы через ДНС сервера которые указаны у регистратора.
Моя пятая точка подсказывает, что если пишется "сервер не найден" не работает ДНС для начала.... а ДНС может не работать по причинам:
A) В индии у клиентов вообще нафик запрещен DNS и все плохо.
B) Индийские ИП зарезаны на стороне провайдера который предоставляет DNS.
До момента "не работает что-то у хостера" еще рановато, надо проверить ДНС для начала.... Хотя и ДНС могут быть у того же хостера.....
В общем думаю что проблемма именно в ДНС а точнее в доступности ваших ДНС со стороны Индии.
А по IP адресу Индия может смотреть сайт ? ну или хотябы hosting page которая показывается (в случае shared IP) ?
как будет осуществляться переход клиентов?
Все соберут свои узелки... И поедут ;)
Мб мы с вами на разных языках говорим но мне кажется вы меня не до конца поняли или я вас.
Насчёт фаеров спорить не буду ибо некомпетентен,сделал только предположение.
Видимо я путаю фаер с чем то более примитивным, но вот например ovh.com из под виндовс стандартными средствами не пингуется из программы(приложения к главной программе) на ура,хотя она как бы не пингует,её основная функция трэйс а пинг также как из cmd побочное явление.
Нащёт ICMP я как раз таки вроде бы понимаю вас,видел даже в этой проге да и не только такое когда например из 12 узлов скажем 8 узел не виден но он есть.В cmd-tracert будут звёздочки естественно в этом случае.
В общем вот что вы мне пытаетесть расссказать на скрине:
Не про это шла речь,речь была в том что идут таймауты на работающем и видимом узле(вот что я пытаюсь сказать),таймауты эти были не всегда а возникали с определённой переодичностью..
Про функционал этой программы я вкурсе, считаю что прилагаемая к ней утилита очень удобна.
Есть ли какие то способы точно определить проблему если мой метод настолько примитивен и не в "тему"(просто очень интрестно),как бы вы поступили?
С Удовольствием бы поделился своим методом с вами, но боюсь это будет немного не честно, у меня более 6 лет опыта работы на должностях из серии "Unix Системный Администратор"/"Менеджер отдела Системных Админов".
По этому мой метод проверки разведет еще больший оффтоп в теме, разговор действительно отошел от основного русла, мочите хостера!!!!!! :D :D :D
"Определить проблему" может только инженер узла о котором мы говорим, клиент может только предполагать и делать какие-то собственные заключения из анализа происходящего.....
Я кстати уже предложил более интересный и "правильный" вариант проверки "работоспособности сайта", меня лично не интересует что там случилось, кабель порезали или винт сгорел или или или, меня интересует доступность моего ресурса.
Концепция проверки: конектимся на 80 , делаем GET запрос своего сайта, данные (код ответа сервера, время ответа) анализируем , выполняем результат в зависимости от анализа...
На сегодня я знаю как минимум 10 средств из серии (cacti, nagios, zabbix), последний даже есть в виде бинарей для win32, которые имеют шаблоны мониторинга FTP / HTTP / и других сервисов... Ну я вообще молчу что можно написать php / perl скриптик в 10 строк который будет делать тоже самое и повесить его в cron :))
В результате проверки мы получаем ответ в любом виде, хоть в процентах в месяц, сколько был недоступен веб сервер..... когда... какие периоды, можно даже графики строить.... если вы говорите о наблюдениях в течении более часа... полагаться на ICMP вообще нет смысла, процент потерь между "миром" выхватите в любом случае ...... Но главное , что мы будем точно знать, что мы мониторили тем же методом (запросом) как и браузер в случае клиента который посещает ваш сайт, а вы опираетесь на не совсем относящиеся к конкретному сайту tracert и ping ... в результате на срезе в 1 сутки например понимаем, что мы не пингали 50% времени сайт, потому что сработала система какая-то и залочила ICMP... потому что регулярность под ее фильтры попала....... Но это же не означает что перестал работать сайт :))))
Romka_Kharkov добавил 29.04.2010 в 23:51
ТС,
А что такое?
5 загрузочных балансеров
Явно что то на стороне хостера,видно что маршрут то и дело переключается а порой таймауты адские и причём они могут таки пропасть всё на томже узле где были, тобишь это не настройки маршрутизаторов такие...
Я не утверждаю, что проверяемый хост 200% стабилен, вы не подумайте, я лишь как технический специалист поправил вас в том, что анализ доступности хостера путем PING это все равно что кидать камешки в реку и ждать пока она из берегов выйдет :)))) Результат не может быть достоверным по ряду причин, во первых доставку echo запросов и ответов ни кто не гарантирует, во вторых не исключено что на маршруте в 11 хопов кто-то не режет ICMP просто потому-что....
Программа которая щупает сквозь файрволы :))) ? Любопытно аж до не могу :)) Как же этой ей удается? :) Поделитесь технологией ?:)
Что же касается "tracert" / "traceroute", так вот собственно http://ru.wikipedia.org/wiki/Traceroute
traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP. Traceroute основана на протоколе ICMP.
Так что от ICMP мы далеко не уехали , если я пожелаю вы не увидите ни одного хоста в трейсроуте внутри моей сети, а так же сам мой пограничный маршрутизатор, в tracert У вас будут звездочки, но это не коем образом не мешает мне отдавать с того же сервера (подсети) сайты в полном объеме. Мало того, в моем ведении еще получается вариант ответа который вы увидите :))) Может быть timeout может быть unreachable, А может быть и prohibited...
Так что не советую вам в будущем штурмовать провайдера услуг опираясь на ICMP ping .... ;) Я понимаю вы бы посмотрели таблицу маршрутизации BGP мировую и зафиксировали изменения маршрутов для этой автономной системы, в таком случае можно было бы утверждать что меняя маршруты хостер меняет физику включения, а именно какие-то проблемы с основным каналом или с одним из каналов...
P.S: Если я не ошибаюсь то основная задача указанного вами софта это поиск игровых серверов, а функции ping / tracert там для удобства клиента... Это сути описанного не меняет, но выглядит странновато ;)
Добавлено:
Изучив более детально ваш скриншот я заметил , что изменение маршрута таки фиксируется, черным блоком на графике, но видимо новый маршрут не отображается, до чего же я люблю "mtr" показывается даже направление асимметричного трафика, а тут как-то не понятно, например могу предположить, что программа не стала показывать "Другой маршрут".... после того как пропал линк с первым.... не ясно что вложили её разработчики (или может быть даже переводчики) в смысл "Другой маршрут"...
Если вас интересует работа сайтов с конкретного ИП я бы рекомендовал мониторить на прикладном уровне OSI, т.е сделать мониторинг 80 го порта к примеру... потому, что исходя из логики в случае с хостингом клиенту все равно, через какой канал и как он запущен (я не говорю про клиентов чей трафик зависит от паритетных каналов городских или регональных), клиента интересует что бы его сайт отображался... по этому говоря техническим языком нам надо что бы на 80м порту указанного ИП отвечал наш сайт при условиях его запроса, вот и скажите мне, зачем при этом мониторить возможность прохождения ICMP пакетов сквозь всю цепочку, если нас предельно точно интересует 80/TCP ?!
Всмысле? Я написал что мониторил этот ip в течении 20 минут, примерно 98% из этого времени были таймауты.
Возможно я чего то не понимаю (так как не спец в этой области ,но базовые навыки имею),если это так поясните.
Поясняю, совсем не обязательно IP адрес на котором расположен сайт должен пинговаться, так же пограничные маршрутизаторы провайдеров в большинстве случаев не отвечают на ICMP запросы, а в редких случаях могут быть настроены на определенное кол-во таких запросов от одного адресата, таким образом чем дольше вы долбите ... тем хуже вам видно ;) Но это касается ICMP протокола.
В общем к чему это я , показатель пингов.... это в общем-то не показатель .... В совокупности с другими данными... да... может быть.... но вы приводите только маршрут который на "последнем хопе" показывает потери ICMP запросов, а что у вас в этот момент с TCP происходит в ту же сторону? Где показатели? Да с ICMP явно проблемы, но к работе сайтов это в принципе отношения не имеет. Могу для вас модулировать такую ситуацию, что бы вы убедились... на графике будет точно такая-же "красная лента"... а сайт вы будете открывать с максимальной скоростью канала доступного между нами....
Сопутствующие доки:
http://ru.wikipedia.org/wiki/ICMP
так ШО, продали или нет?:)
Читал, читал, так ничего и не понял, халявный хостинг + еще доплачивают?
Где конец очереди... ?
Пишите хостеру гневное письмо,можете сами сделать трэйс и передать хостеру если не отреагируют сваливайте от них,бывает иногда поднимается канал но не надолго покрайней мере за 20 минут которые я его мониторю...
А что ICMP всегда и везде должно быть allowed ?:)
Romka_Kharkov ок, я попрошу сделать эти шаги. дело в том что на американском хосте стояли эти сайты, они норм их видели, 2 недели назад перенес, и до сих пор Индия не может достучаться....
Все может быть, я же говорю дело скорее всего в недоступности ДНС (как я вижу), но вполне может быть и что-то другое.... я ж почему и спросил, по ИП достучаться из Индии можно ? минуя ДНС... Я еще не исключал варианта, что не работает на компьютере ваших клиентов что-то ;)
Добрый день.
Вроде бы угадал с темой...
Сайты не работают в Индии, пишет не найден сервер, хотя в других странах все отлично. все сайты которые расположены на этом акке не работают там. Хостер говорит что нет никакой блокировки по IP .
В чем может быть проблема?
Исходя из описанного я бы порекомендовал вам связаться с вашими клиентами в индии , и попросить их сделать:
A) traceroute yourdomain.com (or IP)
B) ping yourdomain.com (or IP)
C) tracert & ping to domain DNS ns1/ns2.yourdomain.com (или как там у вас).
D) прямые запросы через ДНС сервера которые указаны у регистратора.
Моя пятая точка подсказывает, что если пишется "сервер не найден" не работает ДНС для начала.... а ДНС может не работать по причинам:
A) В индии у клиентов вообще нафик запрещен DNS и все плохо.
B) Индийские ИП зарезаны на стороне провайдера который предоставляет DNS.
До момента "не работает что-то у хостера" еще рановато, надо проверить ДНС для начала.... Хотя и ДНС могут быть у того же хостера.....
В общем думаю что проблемма именно в ДНС а точнее в доступности ваших ДНС со стороны Индии.
А по IP адресу Индия может смотреть сайт ? ну или хотябы hosting page которая показывается (в случае shared IP) ?