>[оверквотинг удален]
>> На данном этапе локализации проблемы, принципиальный вопрос следующий:
> ping 80.82.46.199
> Обмен пакетами с 80.82.46.199 по с 32 байтами данных:
> Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
> Ответ от 80.82.46.199: число байт=32 время=28мс TTL=55
> Хотя трасса до него все равно не доходит
>> Пока они будут чинить вашу жалобу, можете оттранслировать(NAT) проблемные src в ваши
> у нас не используется NAT, клиентам выдается белый IP.
> Что-то я теперь совсем теряюсь в догадках. В логах коммутатора доступа ничего
> подозрительного не обнаружено. Какие еще есть мысли по этому поводу?Крайне маловероятен глюк обычного коммутатора, который бы спецфично влиял на ip.
Трасировка не важно, может доходить, может нет, зависит от udp/icmp и фильтрации где-то того или иного.
Поверхностно выглядит так, что администратор хоста 80.82.46.209 зафильтровал у себя пакеты от одного из ваших ip-блоков.
(возможно когда-то этот блок нагадил ему спамом или флудом). Это типичная распространенная практика.
Пишите ему жалобу, типа "просьба проверить, с вашего хоста 80.82.46.209, не возвращаются пакеты на ip-блок такой-то."
В идеале вам надо конечно уметь смотреть дамп с аплинков, и щупать нужные ресурсные порты на интересующем хосте.(пинги-трасировки дают только первое приближение проблемы).
NAT в данном случае, нужен только как временный костыль, чтобы получить доступ к крайне необходимому ресурсу с проблемных IP-адресов клиентов.(тут уж смотрите, стоит ли овчинка выделки)
Вариант для распечатки
on 20-Фев-15, 13:29 
