Занимательный troubleshooting

trouble

Приветствую всех читателей блога, в свете сегодняшних событий решил написать небольшую статью, а точнее даже просто поделиться кое-какими мыслями и выслушать ваши мнения и советы по этому поводу. Итак приступим…

Всем наверняка по роду деятельности приходилось заниматься диагностикой и устранением каких либо неполадок в работе небольших и средних до 100-200 единиц офисных сетей. Проблемы в большинстве случаев типовые, неправильная коммутация и петли, некачественный монтаж, дешевое оборудование и все вытекающие последствия зависания выход из строя коммутаторов и т.д. Время от времени чем то подобным и мне приходится заниматься.  Итак немного предыстории, помнится как то уже рассказывал, что обслуживаю небольшой филиал одной организации N 40 машин, головной офис в Москве таким же основной ит-отдел. Я там по сути занимаюсь всем тем, что они не могут сделать посредством удалённого доступа Radmin-ов и Тимвьюверов .  Теперь ближе к теме на днях звонит директор говорит мол не работает сеть, точнее Интернет в общем посмотри разберись. Ну не работает так не работает иду по стандартной схеме проверяю шлюз шлюз доступен подключаюсь матерюсь в очередной раз на тормозящую WinXP, Traffic Inspectorа Kaspersky и весь проприетарный софт вместе взятый.  К слову немного о том каким образом там устроена сеть и доступ в интернеты. Стойка, в стойке два коммутатора управляемый planet модель не помню… работает в default режиме и неуправляемый dlink des 1016 всё это стянуто и заведено на компьютер с WinXp на борту выполняющего роль файлового сервера, nat транслятора кэширующего прокси, шейпера (Traffic Inspector), Radmin авторизатора, сервера обновлений Kaspersky. В общем этакий комбайн 50 фукций в одном флаконе на дохленьком Intel Celeron D …не помню какого года и поколения. На сетевой карте навешано три айпи адреса (alias в нотации linux bsd ) и вся сеть таким образом сегментирована, что для меня является чем то странным и необъяснимым т.к всё воткнуто в одни и те же коммутаторы и находится в одном broadcast domain смысл от такого деления я так и не понял. Ну да ладно им там в Москве видимо виднее.  Итак продолжим, логинюсь на клиентский компьютер cmd.exe —> ping ya.ru … все ок. Чешу затылок, вроде работает на что жалуются… открываю браузер вбиваю ya.ru —-> облом, опа приехали. Первая мысль что то с конфигурацией Traffic Inspector, попробовал со шлюза всё норм ping, браузер. Поковырялся в настройках TrfIns, столько окон вкладок терминов, я быстро запутался в логике его работы, сделал вывод, что у меня примитивное текстовое мышление, и ни с чем сложнее iptables pf, ipfw  работать мне нельзя. В общем к тому времени Москва уже проснулась и я отписав свои соображения по поводу проблемы спокойно передал эту заявку на их решение. Через пол часа они мне позвонили и посмеявшись сказали что произошел какой то сбой на шлюзе весь журнал, засыпан логами ошибок. В общем решили проблему вроде как воcпользовавшись службой восстановления Windows. Ну решили да решили я порадовался что у них всё так просто решилось и забыл.

Сегодня в пять часов вечера звонит руководитель Московского Ит-отдела и говорит Дима надо приехать на шлюзе образ системы перезалить, к слову после установки со всех ключевых систем был снят образ Акронисом на случай полного краха. Оказывается они вчера весь день там что то ковыряли с rules-ами Traffic Inspector в купе с Kaspersky  т.к сеть всё равно периодически отказывается работать, таким же образом как и вчера т.е все компьютеры доступны шлюза, потерь пакетов нет, со всех доступны ресурсы по крайней мере через icmp проверки, но ни одна страница в браузере не прогружается. Приезжаю пере заливаю образ WinXp шлюза проблема не исчезает. Москвичи опять ковыряют Traffic Inspector я сижу жду… в итоге выносят предположение что проблема с встроенной сетевой картой на мат плате просят заменить сняв с другого компьютера. В моем мозгу происходит некое переосмысление, никак не могу увязать всё в логическую цепочку TCP, HTTP ICMP вспоминаю уровни стека TCP/IP ….в общем WTF что за бред?????? Ведь icmp нет потерь пакетов абсолютно!!! и Radmin tcp/udp та же ситуация. В общем понимаю что теряю логику абсолютно, появляется дикое желание воткнуть wireshark на шлюзе снять дамп трафика с интерфейсов. Проскальзывают еще кое-какие мысли, захожу в серверную выдёргиваю пачкорд с сетевой карты шлюза и меняю порт на коммутаторе.
И вдруг всё каким то чудесным образом ЗАРАБОТАЛО. Ну ладно, ну допустим порт на коммутаторе… Решил проверить вернул на место, итак работает…. У меня опять логический коллапс. Пол часа хожу проверяю со всех компьютеров проталкиваю icmp пакеты на полный mtu интерфейсов ни одной потери. Устал думать, поехал домой…

У кого какие мысли?

Смотрите так же:

Занимательный troubleshooting: 4 комментария

  1. Жалею что дамп трафика не снял до того как всё восстановилось. т.к я для себя логического объяснения пока не нашел. Коммутация пакетов это все таки у нас уровень L2 А и ICMP, TCP/UDP это все таки уже L3. Единственная взаимосвязь которая мне приходит в голову это размер пакета. Неисправности я проверял только стандартным 32 байтным пакетом. Возможно коммутация пакетов большей размерности как раз таки и вызывала проблемы отчего мы и получали на L7 уровне такие эффекты. В общем плохо делать выводы когда анамнёза нормального не собрано. )

    1. А что еще остается? Как объяснить повторение глюка после восстановления из образа, как не аппаратными проблемами.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.