Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 99
Добротно так написали, хоть и не отношусь к админам, но читал взахлеб, прям блокбастер.
Довольно таки старая проблема.
Впервые я её обнаружил, когда на рынок вышли лазерные Canon.
Их программное обеспечение «желало лучшего» из-за чего по странному обстоятельству страдала сеть. Но это было лет 10 назад. Видно сразу что Panasonic наступил на те же грабли.
Впервые я её обнаружил, когда на рынок вышли лазерные Canon.
Их программное обеспечение «желало лучшего» из-за чего по странному обстоятельству страдала сеть. Но это было лет 10 назад. Видно сразу что Panasonic наступил на те же грабли.
Респект за такое расследование.
Почти как Конан-Дойла можно читать. :)
Почти как Конан-Дойла можно читать. :)
Очень увлекательное расследование, такая целеустремленность в поиске причин неполадок, очень хорошее качаство для сетевого администратора.
Панасоники конечно молодцы :), видимо перезагрузкой решали какие-то свои внутренние проблемы, но проблема врядли бы возникла при более правильном дизайне сети, 200-300 хостов в одной подсети — это перебор, ведь при таком большом широковещательном домене проблемы с производительностью сети практически неизбежны.
Панасоники конечно молодцы :), видимо перезагрузкой решали какие-то свои внутренние проблемы, но проблема врядли бы возникла при более правильном дизайне сети, 200-300 хостов в одной подсети — это перебор, ведь при таком большом широковещательном домене проблемы с производительностью сети практически неизбежны.
полностью с вами согласен, по поводу размеров подсети
и проблема эта известная.
еще хуже то, что этот широковещательный домен размазан по 30+ коммутаторам и двум зданиям!
но увы, есть причины(от админов независящие), по которым ситуация остается неизменной и решение этих проблем отложено на неопределенный срок.
а проблем с производительностью на практике нет.
и проблема эта известная.
еще хуже то, что этот широковещательный домен размазан по 30+ коммутаторам и двум зданиям!
но увы, есть причины(от админов независящие), по которым ситуация остается неизменной и решение этих проблем отложено на неопределенный срок.
а проблем с производительностью на практике нет.
Для чего это сделано понятно, я и сам не раз сталкивался с подобным даже на более серьезных устройствах, например, во Львове есть несколько АТС (не мини, а настоящих — узлы горосдской телефонной сети), которые тоже перезапускаются каждую ночь и процес этот у них занимает до десяти минут.
Но это их не оправдывает, а наоборот говорит о качестве системного ПО :)
А про провайдеров и сессии: мы значит крутую билинговую систему сделали, у клиентов наших клиентов иногда бывают сесии длительностью в пару месяцев :)
Но это их не оправдывает, а наоборот говорит о качестве системного ПО :)
А про провайдеров и сессии: мы значит крутую билинговую систему сделали, у клиентов наших клиентов иногда бывают сесии длительностью в пару месяцев :)
Можете обьяснить такой момент в работе одного провайдера?
Макс длинна сессии — 12ч. Примерно 15 декабря ВНЕЗАПНО сессия прекратила прерываться… на 3 недели. Так же в течении этих трёх недель не начислялась ежемесячная абонентская плата, назначенная на 20 число месяца. Никаких новостей на оф. сайте не было.
Макс длинна сессии — 12ч. Примерно 15 декабря ВНЕЗАПНО сессия прекратила прерываться… на 3 недели. Так же в течении этих трёх недель не начислялась ежемесячная абонентская плата, назначенная на 20 число месяца. Никаких новостей на оф. сайте не было.
Можно строить разные гипотезы, опираясь на существующий опыт, например, в нашей практике есть случаи когда разрыв сессии необходим для изменения атрибутов соединения, или бывали случаи когда на праздники связанные со сменой года нужно было отменить выполнение процедур связанных с отключением по состоянию счета.
Но 15 декабря, это рановато для начала сервисных процедур, а три недели это как-раз после праздников, больше всего похоже на то, что 15-го что-то сломалось, а заметили аж когда от праздиков отошли :)
Но 15 декабря, это рановато для начала сервисных процедур, а три недели это как-раз после праздников, больше всего похоже на то, что 15-го что-то сломалось, а заметили аж когда от праздиков отошли :)
snmp — Stability Not My Problem. Ну или как-то так, да.
ещё несколько сюжетов да харизматичных персонажей и получится хороший сериал «Сетевой Хаус» ;-)
Читается как детектив :-)
Люблю я такие расследования, жаль личное участие в них бывает очень утомительным :-)
Люблю я такие расследования, жаль личное участие в них бывает очень утомительным :-)
Читал статью сразу после просмотра серии «доктора Хауса». Похоже — невероятно :) Завязка, интрига, потенциально смертельно опасный баг, неверное предположение циски о петле, сложные анализы и торжество рациональной аналитики в финале.
Выводы:
1) Все устройства врут.
2) Все устройства ошибаются.
А всего-то надо было принимать витамины и вести здоровй образ жизни — при установке МФУ'шек пробить в них правильное системное время. :)
Выводы:
1) Все устройства врут.
2) Все устройства ошибаются.
А всего-то надо было принимать витамины и вести здоровй образ жизни — при установке МФУ'шек пробить в них правильное системное время. :)
А чисто теоретически, возможно ли такое ПО, которое как раз будет рассылать такие пакеты, которые исходили от МФУ при перезагрузке? Ведь это серьезная брешь в системе безопасности, т.к. вирус знающий такую уязвимость сможет положить всю корпоративную сеть.
стоит учесть стечение обстоятельств.
1) это ПО должно быть на множестве клиентов в данной подсети(допустим распространить вирусом)
2) в данной подсети должно быть множество устройств, работающих с SNMP в комьюнити public
3) TC(Topology Change) — вызываны слабым железом. с одной стороны в сети может и не быть таких железок. с другой стороны вся сеть может быть построена только на них, и тогда…
4) есть один интересный момент, в дампе четко видно TTL=1, что не позволяет пакету покидать данную подсеть… а если IP.TTL = '255', то большому кораблю большое плавание! Но тут уже все зависит от настроек маршрутизации…
наверное определяющим является второй пункт.
1) это ПО должно быть на множестве клиентов в данной подсети(допустим распространить вирусом)
2) в данной подсети должно быть множество устройств, работающих с SNMP в комьюнити public
3) TC(Topology Change) — вызываны слабым железом. с одной стороны в сети может и не быть таких железок. с другой стороны вся сеть может быть построена только на них, и тогда…
4) есть один интересный момент, в дампе четко видно TTL=1, что не позволяет пакету покидать данную подсеть… а если IP.TTL = '255', то большому кораблю большое плавание! Но тут уже все зависит от настроек маршрутизации…
наверное определяющим является второй пункт.
Вы описали ситуацию с логической точки зрения. С другой стороны, имхо, вполне можно эксплуатировать подобные схемы, даже без устройств. Тот же ARP флуд. Ну или действительно намеренно пытаться инициировать (а то и подделывать) TC.
P.S: По поводу пункта 4 сомнительно. Даже если бы TTL не был 1 то пропускать бродкасты наружу это уже сомнительно имхо. Вы знаете ситуации когда они пропускаются? Или это из за VLANов?
P.S: По поводу пункта 4 сомнительно. Даже если бы TTL не был 1 то пропускать бродкасты наружу это уже сомнительно имхо. Вы знаете ситуации когда они пропускаются? Или это из за VLANов?
Да конешно, для аткаи на корпоративную сеть лучше использовать специальное ПО, позволяющее сформировать любой пакет, а не таскать с собой МФУ внушительных размеров. =)
Я рассмотрел ситуацию чисто гипотетически, указав, что все зависит от настроек маршрутизации, но в принципе такое возможно.
VLAN в данном контексте стоит рассматривать лишь как единый широковещательный домен второго уровня, ну или проще говоря одну физическую сеть. Правда виртуальную. Они тут не при чем, т.к. маршрутизация — это уже третий уровень, а VLAN-ы исключительно второй.
Я рассмотрел ситуацию чисто гипотетически, указав, что все зависит от настроек маршрутизации, но в принципе такое возможно.
VLAN в данном контексте стоит рассматривать лишь как единый широковещательный домен второго уровня, ну или проще говоря одну физическую сеть. Правда виртуальную. Они тут не при чем, т.к. маршрутизация — это уже третий уровень, а VLAN-ы исключительно второй.
Оно не только позможно, но и существует, даже вполне благонадежные диагностические утилиты позволяют сгенерировать пакет с нужными характеристиками или flood (много-много таких пакетов). Бороться с этим можно устанавливая специальные фильтры против таких атак, кроме того можна использовать чисто административные методы.
arp-ами можно столько всего наделать в корпоративной сетке… ужос
Рукоплещу анализу.
Угу-угу, было бы еще веселее, если бы в конторе стояло штук 10 таких МФУ-шек, которые синхронизировали время по NTP, но часовой пояс стоял некорректный (например, +11). Тогда DDoS был бы покруче =)
Тогда бы невилировалась мораль статьи, о том что нужно искать обьяснение таким «мистическим» явлениям, а не спихивать на — «неисповедимы пути электронов в вычислительной машине». Описаный вами расклад привел бы к тому что на поиски его причины бросили бывсе силы, получился бы «экшн» но без морали, да и ругани в сторону Панасоника было бы.
а не набор ли ошибок в администрировании тут
огромная подсеть на тупых свичах(или не настроенный вилан)
открытые порты на пользовательских машинах
не настроенные циски
огромная подсеть на тупых свичах(или не настроенный вилан)
открытые порты на пользовательских машинах
не настроенные циски
>>огромная подсеть на тупых свичах
Cisco 2950 и 3560 — не самые тупые свичи.
>>или не настроенный вилан
Почитайте еще раз статью
>>открытые порты на пользовательских машинах
И чо?
>>не настроенные циски
Что конкретно нужно добавить в конфиг?
Cisco 2950 и 3560 — не самые тупые свичи.
>>или не настроенный вилан
Почитайте еще раз статью
>>открытые порты на пользовательских машинах
И чо?
>>не настроенные циски
Что конкретно нужно добавить в конфиг?
ошибка одна — системное время на МФУ, а настройка МФУ не имеет отношения к сетевому администрированию.
назвать cisco2950 — тупым свичом… у меня язык не поворачивается. да, не корпоративный уровень, но никак не тупая.(vlan тут не при чом)
открытые порты — а зачем закрывать порты в сети, которая находиться за множеством фаерволов? и опять таки это не имеет отношение к сетевому администрированию
не настроено что?!
назвать cisco2950 — тупым свичом… у меня язык не поворачивается. да, не корпоративный уровень, но никак не тупая.(vlan тут не при чом)
открытые порты — а зачем закрывать порты в сети, которая находиться за множеством фаерволов? и опять таки это не имеет отношение к сетевому администрированию
не настроено что?!
Вопрос о том что относится к сетевому администрированию, а что нет, довольно сложный. МФУ в данном случае, всетаки, сетевой узел. Другое дело, что конфигурирование МФУ не вашего уровня задача, за такое разгильдяйство можно надавать щелбанов технику который устройство устанавливал :)
Это сетевое устройство может получать от dhcp ntp-сервер и синхронизироваться?
Это сетевое устройство настроено в ручную?
По опыту могу сказать, что технику ничего не сказали о сети, не о сервере времени… скорей всего васян там рулил сетями и был очень занят, когда устанавливалась эта штука, посему он сказал наскоряк чё вбить в настройки, чтобы пакеты полетели и кинул трубку. Это так в защиту техников.
Тупые свичи? Открытые порты? О чем вы?
Или вы сторонник закрывать все и вся и блокировать одноклассников? ;)
Проблемы уровня системного (сетевого) администрирования тут нет.
Или вы сторонник закрывать все и вся и блокировать одноклассников? ;)
Проблемы уровня системного (сетевого) администрирования тут нет.
А открытые портыэто очеь страшно… сродни открытым дверям? :-)
А не было бы решением проблемы завести МФУ-шки через программный принт-сервер, а не выполнять печать напрямую?
Т.е. стоит Windows Server 2003, к котрому «локально» подключен по IP-порту, а сам этот принтер расшарен пользователям.
Имхо, так намного функциональнее, биллинг ко всему этому можно прикрутить, авторизация само собой, приоритезация, ну и так далее.
Т.е. стоит Windows Server 2003, к котрому «локально» подключен по IP-порту, а сам этот принтер расшарен пользователям.
Имхо, так намного функциональнее, биллинг ко всему этому можно прикрутить, авторизация само собой, приоритезация, ну и так далее.
Учитывая мой скромный опыт общения со службой принт-сервера на базе Win2003, мне не ясно, как это может решить проблему?
Ну только если выводить МФУ в другую подсеть в другом vlan-е…
А это можно сделать и без принт-сервера, т.к. клиентское ПО можно настроить по IP.
Мы рассматривали множество вариантов решения. И выводить МФУ в отдельный vlan, и в отдельную подсеть с маршрутизацией, и вырезать порты на на клиентах…
Но как это не странно самым оптимальным решением является все же именно настройка корректного времени.
Был поставлен эксперимент. В 18-00 все сотрудники уходят, выключая свои машины. Перезагрузка МФУ в 19-00 не дает никакого эффекта! Просто некому ответить на эти пакеты, а если кто и задержался на работе, то что там какие-то 200-300 пакетов?
Вот так! Все гениальное просто.
Ну только если выводить МФУ в другую подсеть в другом vlan-е…
А это можно сделать и без принт-сервера, т.к. клиентское ПО можно настроить по IP.
Мы рассматривали множество вариантов решения. И выводить МФУ в отдельный vlan, и в отдельную подсеть с маршрутизацией, и вырезать порты на на клиентах…
Но как это не странно самым оптимальным решением является все же именно настройка корректного времени.
Был поставлен эксперимент. В 18-00 все сотрудники уходят, выключая свои машины. Перезагрузка МФУ в 19-00 не дает никакого эффекта! Просто некому ответить на эти пакеты, а если кто и задержался на работе, то что там какие-то 200-300 пакетов?
Вот так! Все гениальное просто.
Вполне возможно, а для усиления эффекта, вынести принтеры в отдельную VLAN.
Но это все в случае просто принтера, а речь идет о МФУ, его и как сканер захотят пользовать, а тут может оказаться не все так просто (решаемо, но мороки больше).
Но это все в случае просто принтера, а речь идет о МФУ, его и как сканер захотят пользовать, а тут может оказаться не все так просто (решаемо, но мороки больше).
Аффтару за раследование зачет! =)
Решить проблему можно вынесением МФУ в отдельный VLAN с единственным гейтом во вне (пользовательскую сеть). В таком случае ввиду TTL=1 такого шторма не получится никак, т.к. дальше выделенного VLAN-а пакеты не уйдут.
Решить проблему можно вынесением МФУ в отдельный VLAN с единственным гейтом во вне (пользовательскую сеть). В таком случае ввиду TTL=1 такого шторма не получится никак, т.к. дальше выделенного VLAN-а пакеты не уйдут.
Вот они, админские будни :)
отличное чтиво.
и отличная работа проделана.
тоже люблю выяснять детали разных казусов.
и отличная работа проделана.
тоже люблю выяснять детали разных казусов.
Вопрос к автору
Где такому учат или где вы учились?
Где такому учат или где вы учились?
Немного смущает терминология «коммутатор зафиксировал петлю в сети», a la Cosmopolitan. Начнем с того, что петли никакой нет и фиксировать ее никто не мог. В реальность технология Loop Guard придумана для того, чтобы в ситуации если коммутатор перестал получать BPDU на non-designated порт, вместо того, чтобы переводить его в состояние Forwarding, блокирует его на случай однонаправленой потери линка, предотвращая таким образом образование кольца на L2.
Так что утверждение «когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm» не соответствует действительности в Вашем случае — такая функциональность возможна, но если бы она сработала, сообщение об ошибке было бы другое.
Мне в этой истории непонятны два вопроса:
1. Куда делось BPDU, отсутствие которого спровоцировало Loop Guard ошибку? 6000 мелких пакетов настолько забили транк?
2. Насколько я понимаю, аксесс-коммутаторы соединены одним транком с центральным устройством. Зачем при таком сценарии включать на единственном рут-порте Loop Guard, который по умолчанию выключен на всех портах (во всяком случае на всех железках, которые я видел)? Или все-таки были избыточные соединения?
Так что утверждение «когда они огребают такое количество широковещательного трафика, они воспринимают это как broadcast-storm» не соответствует действительности в Вашем случае — такая функциональность возможна, но если бы она сработала, сообщение об ошибке было бы другое.
Мне в этой истории непонятны два вопроса:
1. Куда делось BPDU, отсутствие которого спровоцировало Loop Guard ошибку? 6000 мелких пакетов настолько забили транк?
2. Насколько я понимаю, аксесс-коммутаторы соединены одним транком с центральным устройством. Зачем при таком сценарии включать на единственном рут-порте Loop Guard, который по умолчанию выключен на всех портах (во всяком случае на всех железках, которые я видел)? Или все-таки были избыточные соединения?
2. portfast по-умолчанию как раз-то выключен. Те именно по-умолчанию будет дедектися петля.
Я ничего не писал про PortFast, речь шла про Loop Guard.
PortFast, опять-таки не «детектит петли», а безусловно переводит порт в Forwarding, миную Listening и Learning, всё.
PortFast, опять-таки не «детектит петли», а безусловно переводит порт в Forwarding, миную Listening и Learning, всё.
Долго думал, что вам ответить.
Во-первых, позволю себе заметить, что в статье после 5-го пункта есть абзац содержащий такие фразы:
"… не точен и скуп на факты."
"… вообще говоря все не совсем так, хотя очень близко."
«краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.»
Во-вторых, во общем, я с вами согласен, но есть некоторые особенности, которые я не осветил, а вы не учли.
Я предлагаю написать небольшую отдельную статью в блоге Cisco, с описанием особенностей работы коммутаторов серии cisco2950. Там я подробно изложу свою точку зрения, с соответствующими аргументами. И если у вас останутся вопросы, то мы сможем обсудить их в комментариях к той статье, так как это уже вопросы более специфические.
Во-первых, позволю себе заметить, что в статье после 5-го пункта есть абзац содержащий такие фразы:
"… не точен и скуп на факты."
"… вообще говоря все не совсем так, хотя очень близко."
«краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.»
Во-вторых, во общем, я с вами согласен, но есть некоторые особенности, которые я не осветил, а вы не учли.
Я предлагаю написать небольшую отдельную статью в блоге Cisco, с описанием особенностей работы коммутаторов серии cisco2950. Там я подробно изложу свою точку зрения, с соответствующими аргументами. И если у вас останутся вопросы, то мы сможем обсудить их в комментариях к той статье, так как это уже вопросы более специфические.
мдя. и после этого юзвери смеют говорить, что админы сидять и «ничерта не делают».
вот они, бойцы невидимого фронта.
вот они, бойцы невидимого фронта.
Проблемы бы не было, если бы циска и панасоник не экономили на программистах. Тупое введение паузы произвольного периода (0… пара секунд) между:
1. Наступлением 00:00 и перезагрузкой
2. Получением пакета на порт 3892 и отправкой ответа
3. Получением TC-пакета и началом инициализации таблицы MAC-адресов (которую тоже хорошо бы чуть-чуть растянуть во времени)
позволило бы избавиться от кучи головняка.
1. Наступлением 00:00 и перезагрузкой
2. Получением пакета на порт 3892 и отправкой ответа
3. Получением TC-пакета и началом инициализации таблицы MAC-адресов (которую тоже хорошо бы чуть-чуть растянуть во времени)
позволило бы избавиться от кучи головняка.
1. момент времени, когда происходит перезагрузка не влияет на дальнейшее развитие событий, хоть это 00:00:00, хоть 00:00:02.
2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
3. Чем меньше интервал времени между реальным изменением топологии сети, и сбросом MAC-таблиц, тем меньше вероятность дропа(потери) пакетов. Одно лечим, другое калечим. К тому же этот интервал можно вручную настроить в IOS(операционная система, применяемая на оборудовании cisco) разным на разных устройствах. Но все же в идеале нужно стремиться к минимальному значению, и одинаковому поведению(стандартизация) всех узлов сети. Иначе, когда, как вы предлагаете такие временные интервалы будут определяться случайным образом, диагностировать проблемы в сети станет в разы сложнее!
2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
3. Чем меньше интервал времени между реальным изменением топологии сети, и сбросом MAC-таблиц, тем меньше вероятность дропа(потери) пакетов. Одно лечим, другое калечим. К тому же этот интервал можно вручную настроить в IOS(операционная система, применяемая на оборудовании cisco) разным на разных устройствах. Но все же в идеале нужно стремиться к минимальному значению, и одинаковому поведению(стандартизация) всех узлов сети. Иначе, когда, как вы предлагаете такие временные интервалы будут определяться случайным образом, диагностировать проблемы в сети станет в разы сложнее!
> 2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
Они тупые индусы, если не могли такое предположить. Они сами спланировали ситуацию, в которой
а) широковещательный пакет влечет за собой ответы от всех присутствующих клиентов в данном сегменте сети (1 пакет запрос, 10-100-1000 ответов на него мгновенно — это нормально? У любого вменяемого человека в голове сразу же загорелась бы неонка лампочка, что такое делать нельзя.)
> 3.
Х.З. Понятно, что хочется за минимальное время всё сделать, но такой вариант решения — далеко не оптимальный. Зачем рассылать сразу всем клиентам ARP-запросы? Можно рассылать их по мере появления пакетов для них (т.е. для неизвестных пока MAC-адресов).
Они тупые индусы, если не могли такое предположить. Они сами спланировали ситуацию, в которой
а) широковещательный пакет влечет за собой ответы от всех присутствующих клиентов в данном сегменте сети (1 пакет запрос, 10-100-1000 ответов на него мгновенно — это нормально? У любого вменяемого человека в голове сразу же загорелась бы неонка лампочка, что такое делать нельзя.)
> 3.
Х.З. Понятно, что хочется за минимальное время всё сделать, но такой вариант решения — далеко не оптимальный. Зачем рассылать сразу всем клиентам ARP-запросы? Можно рассылать их по мере появления пакетов для них (т.е. для неизвестных пока MAC-адресов).
ПО на компах, некий PCCMFLPD.EXE. Не очень понимаю зачем оно вообще нужно. Без него не печатает? Или это для сканера?
Я бы сказал соответствующим людям что бы снесли это вредоносное ПО.
Я бы сказал соответствующим людям что бы снесли это вредоносное ПО.
вот если бы не написали бы в начале статьи про panasonic и мфу в углу комнаты, было бы вобще супер :)
С удовольствием принимаю вашу критику!
Было два варианта:
1. Не писать сразу про МФУ в углу комнаты, и тогда читатель подсознательно искал бы в статье ответ на вопрос КТО? Кто же виноват в этом?
2. Начав статью с недвусмысленного намека на виновника, я переключил интерес читателя на поиски ответа на вопрос ПОЧЕМУ? А именно это и было главной идей статьи. Не найти виновника, а понять почему так происходит.
А за дельную критику в литературном(а не техническом) ракурсе — спасибо.
Было два варианта:
1. Не писать сразу про МФУ в углу комнаты, и тогда читатель подсознательно искал бы в статье ответ на вопрос КТО? Кто же виноват в этом?
2. Начав статью с недвусмысленного намека на виновника, я переключил интерес читателя на поиски ответа на вопрос ПОЧЕМУ? А именно это и было главной идей статьи. Не найти виновника, а понять почему так происходит.
А за дельную критику в литературном(а не техническом) ракурсе — спасибо.
читал на одном дыхании :]
Эркюль Пуаро network edition! Настоящий детектив! Очень интересно.
Следствие ведут знатоки (с).
Автору множественный респект, давно с таким интересом не читал.
Автору множественный респект, давно с таким интересом не читал.
Вах, очень увлекательно, спасибо.
Рекомендую приложить сслыку на пост в свое резюме
NetWare — зона ответственности серверистов, а я все же сетевик. Как следствие дать подробного и развернутого ответа не могу.
Но на сколько я понимаю NetWare — это лишь пережиток прошлого, и сейчас его роль сведена лишь до каталогов директорий(организация доступа к ресурсам) и файл-серверов. Но повторюсь, я могу ошибаться.
Но на сколько я понимаю NetWare — это лишь пережиток прошлого, и сейчас его роль сведена лишь до каталогов директорий(организация доступа к ресурсам) и файл-серверов. Но повторюсь, я могу ошибаться.
А что за родное ПО Panasonic? для чего оно используется?
Имеется ввиду драйвер принтера или что-то другое?
Имеется ввиду драйвер принтера или что-то другое?
Драйвер принтера + дополнительное ПО.
Оно необходимо для реализации функции сетевого сканера в первую очередь. Заметьте МФУ имеет сетевой порт Ethernet, т.е. это полноценный сетевой сканер. А также для мониторинга принтеров. Это ПО кстати обнаруживает все принт-сервера в сети, и очень хорошо подходит для их мониторинга(оно цепляет все наши HP-шники, а это около сотни!). В главном окне выводиться весь список принтеров и их текущее состояние — например «Готов», или «кончился картридж», «нет бумаги» и т.д. Вообще-то очень удобно. Само ПО проблем не вызывает, и нареканий к нему нет… ну пока оно не услышит зов МФУ =)
Оно необходимо для реализации функции сетевого сканера в первую очередь. Заметьте МФУ имеет сетевой порт Ethernet, т.е. это полноценный сетевой сканер. А также для мониторинга принтеров. Это ПО кстати обнаруживает все принт-сервера в сети, и очень хорошо подходит для их мониторинга(оно цепляет все наши HP-шники, а это около сотни!). В главном окне выводиться весь список принтеров и их текущее состояние — например «Готов», или «кончился картридж», «нет бумаги» и т.д. Вообще-то очень удобно. Само ПО проблем не вызывает, и нареканий к нему нет… ну пока оно не услышит зов МФУ =)
Мда, коварное ПО)
но я скорее всего оставил бы его только там, где оно действительно нужно. А просто печатать и тем более снимать копии можно и без дополнительного ПО.
По моему опыту — сканером в МФУ пользуются чрезвычайно редко. А так как к МФУ для сканирования все равно далеко ходить нужно, то людям проще дойти до полноценного сканера.
но я скорее всего оставил бы его только там, где оно действительно нужно. А просто печатать и тем более снимать копии можно и без дополнительного ПО.
По моему опыту — сканером в МФУ пользуются чрезвычайно редко. А так как к МФУ для сканирования все равно далеко ходить нужно, то людям проще дойти до полноценного сканера.
> сканером в МФУ пользуются чрезвычайно редко
В это сложно поверить, но я видел своими собственными глазами!
Скорость сканирования у это МФУ чисто визуально близка к странице в секунду.
В него заряжают стопку договоров, и он их сканит с бешенной скоростью.
Дык вот, что бы перезагрузить МФУ, мы каждый раз были вынуждены дожидаться окончания процесса сканирования. Сложилось впечатление, что МФУ-шка сканирует документы 8 часов в день, каждый день. Это по странице в секунду!
В это сложно поверить, но я видел своими собственными глазами!
Скорость сканирования у это МФУ чисто визуально близка к странице в секунду.
В него заряжают стопку договоров, и он их сканит с бешенной скоростью.
Дык вот, что бы перезагрузить МФУ, мы каждый раз были вынуждены дожидаться окончания процесса сканирования. Сложилось впечатление, что МФУ-шка сканирует документы 8 часов в день, каждый день. Это по странице в секунду!
Так причина проблемы-то всё же в этом самом ПО, а не в МФУ? МФУ ведь только провоцируют проблему, как я понял, это мог бы сделать кто угодна. А Вы говорите, что нареканий к ПО нет, как же так? :)
Мне как ленивый админ с 9 стажем, который не любит читать худ. литературу, но вот твоя статья зацепила, читал, как детектив… давай еще.
Бренд Panasonic напоминает китайцев, которые «для облегчения общения с русскими» называют себя Васями и Петями. В оригинале же Matsushita — имя само за себя говорит.
хотя и не понимаю ничего в устройстве сетей, но, как уже было сказано выше, написано действительно очень увлекательно и интересно =)
Спасибо за статью! пришлась очень кстати, т.к. от клиента пришло письмо с проблемой с такими же симптомами )
Хочу статью со всеми тонкостями ) получилось как в хорошем практическом руководстве по TCP/IP!
Вот такие посты я приветствую на хабре, а не «у гугла в гмыле появилась новая фенечка»
Интересно и познавательно, спасибо! Тоже случаются иногда подобные эпические драмы =)
неплохо, ога. :) автор молодец, что докопался до причины, а не забил.
только пока все это читал, несколько раз в голову лезла мысль о неверно настроенных каталистах, о причинах «зачем же роутить каталистом» и т.п. правда каждый раз когда мысль формировалась и была готова быть сюда написана, глаза натыкались на фразы про неточности, скупость фактов и прочие отмазки.
а была действительно сладкая возможность помусолить за каталисты на хабре (да неужели дожили на хабре говорить за каталисты?! О_о)
и да, МФУ хорошее устройство не назовут :) никогда не понимал в чем прелесть купить гавнецо три в одном вместо покупки трех _нормальных_ устройств, а в случае с принтером, вообще отдельный принтсервер…
только пока все это читал, несколько раз в голову лезла мысль о неверно настроенных каталистах, о причинах «зачем же роутить каталистом» и т.п. правда каждый раз когда мысль формировалась и была готова быть сюда написана, глаза натыкались на фразы про неточности, скупость фактов и прочие отмазки.
а была действительно сладкая возможность помусолить за каталисты на хабре (да неужели дожили на хабре говорить за каталисты?! О_о)
и да, МФУ хорошее устройство не назовут :) никогда не понимал в чем прелесть купить гавнецо три в одном вместо покупки трех _нормальных_ устройств, а в случае с принтером, вообще отдельный принтсервер…
А никто и не говорил, что эти каталисты роутят.
Нет ну роутят конечно, и даже каталисты, ну дык ведь шеститонники(cisco catalyst 650x), а никак не 29х0 и 35х0.
В данной статье маршрутизация во вне не имеет никакого значения, так как все события разворачиваются исключительно в пределах одного широковещательного домена.
А на счет хабра и каталистов — там вон про микроконтроллеры топики пошли, так что как знать, как знать…
Нет ну роутят конечно, и даже каталисты, ну дык ведь шеститонники(cisco catalyst 650x), а никак не 29х0 и 35х0.
В данной статье маршрутизация во вне не имеет никакого значения, так как все события разворачиваются исключительно в пределах одного широковещательного домена.
А на счет хабра и каталистов — там вон про микроконтроллеры топики пошли, так что как знать, как знать…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Panasonic атакует