Компания
33,64
рейтинг
16 мая 2014 в 10:24

Разное → Как отравить кошку? Детективная история со счастливым концом

Устраивайся поудобнее, мой читатель. Сегодня я расскажу тебе увлекательную историю.

Все началось недавно. Свежеустановленный (меньше месяца) роутер Cisco вдруг на всех обиделся и ушел в себя. Настолько ушел, что на внешние раздражители реагировать перестал совершенно, трафик через себя пропускать посчитал делом неблагодарным и недостойным, и вообще закуклился по самое не могу.

Первая мысль после перезагрузки роутера: какой-то шутник решил запустить очередную убер-программу. Ну, или чей-нибудь ноут сошел с ума – тоже бывает. Однако пристальное изучение трафика (netflow, прослушка tcpdump-ом на предмет хитрого бродкаста) ничего не дало. Более того, шторм-контроль на клиентских портах не срабатывал.

А тем временем, роутер, проработавший после ребута едва ли пять минут, снова завис. Прошу заметить, в самый разгар рабочего дня. «К счастью», телефония шла через этот же роутер, и только это спасло нас от воплей огорченных коллег:).


Хм… — сказали суровые сибирские мужики.

Выключаем всех клиентов, включаем по одному – вроде, тихо. Начинаем допрос с пристрастием: кто, что, куда… в ответ тишина. Не были, не знаем. Починяли примус. Читали почту, работали.

И можно было бы списать на случайность, если бы такая проблема не повторилась еще несколько раз в других филиалах, где недавно меняли роутеры, в разное время, с разной нагрузкой…

Естественно, как только стало понятно, что проблема не единичная, был открыт тикет в Cisco TAC, началась стандартная история со сменой версий IOS, предложением поменять маршрутизатор, проверкой настроек и тыды и тыпы.

Параллельно с общением с TAC собрали стенд и попытались воспроизвести ситуацию «в лабораторных условиях». После анализа тонны логов прокси выяснили, что зависание происходит при открытии почтового ящика на outlook.com.

Черт возьми, Холмс, но как?!

На стенде проблема воспроизведена на 100%. При входе в учетную запись outlook.com роутер умирает, не издав ни звука. Крашдампов роутер после себя не оставляет, даже если попросить, запущенный watchdog ситуацию не спасает – роутер зависает наглухо и спасает его только холодный рестарт по питанию. Начинаем по одной выключать активированные настройки и выясняем, что если отключить инспекцию трафика, все приходит в норму. Меняем несколько версий IOS – поведение идентичное, даже с «рекомендованной для этой модели специалистами TAC». Начинаем копать глубже – оказывается, виноват nbar (Network Based Application Recognition) – модуль, позволяющий распознавать тип трафика (voice, video, data… etc) для правильной его окраски и применения различных политик QoS.

Инженер TAC, который вел наш тикет, от таких новостей был несколько в шоке, но снял всю нужную информацию и передал программистам. Ответ их был шикарен:

«it is rather a general behavior of ISR routers in case of loops at the interrupt level.
If the interrupt service routine in the router is suspended or stalled it might cause the router to hang
and the console to become unresponsive, requiring a manual reload to restore service.
The router can be configured with the command 'scheduler isr-watchdog' (as shown in example below )
in order to activate a mechanism for detecting such cases.
It will also trigger a router reload if such an event is identified.»


Т.е. все в порядке, так и должно быть. Гордые кошки умирают молча.

Также инженер TAC ответил, что в buglist мы этой проблемы не найдем, т.к. она internal, и вообще не фиг лишний раз будоражить общественность, а лучше просто молча обновить protocol pack (набор сигнатур и правил для этого самого nbar). Оно, конечно, может, и правильно, но, с другой стороны, отсутствие этой проблемы в known bugs превращает поиск решения, по сути, в гадание на кофейной гуще и отключение всех функций роутера поочередно (а учитывая стоимость железки, то подходящей лабы под рукой вполне может и не оказаться).
После обновления protocol pack все пришло в норму, и вот уже месяц (тьфу-тьфу-тьфу) никаких проблем с маршрутизаторами нет.

Вот такая пятничная история. Так что если ты используешь nbar и твоем хозяйстве есть вышеупомянутые роутеры (ISR G2, если что), то крайне советую обновить protocol pack, пока твои пользователи не решили как-нибудь открыть какой-нибудь «интересный» сайт.
Автор: @Night_Snake
Петер-Сервис
рейтинг 33,64

Комментарии (93)

  • +14
    Всегда преклонялся перед умением распутывать такие вещи. Бешено плюсую
  • +16
    Боюсь показаться человеком «не в теме», но скажите пожалста, при чем же тут кошка?
    • +11
      Оборудование Cisco исторически зовут кошками. Обычно это применяется к коммутаторам (серия Catalyst), но, имхо, применимо и к роутерам.
      • +2
        Благодарю )
    • +14
      «Киска» ведь. А еще«сиська».
      • 0
        Да как-то не прижилось. А вот «кошка» или «кот» — то да
      • +3
        Вот кстати в меру своей испорченности, «сиську» то я давно в названии углядел, а вот кися никак в голову не приходила. Уж простите )
        • 0
          Кстати официальная транскрипция вроде как «Киско системз»
          • 0
            Не «Сиско»?
            • +5
              Википедия говорит «сиско», когда к нам приходил их продаван говорил «Киско». могу ошибаться =)
              • +3
                ООО «Сиско Системс», так что не ошибаетесь. San Francisco — Cisco взято именно от сюда. Транскрипция что-то типа [sisko], но могу незначительно ошибаться.
                • 0
                  Благодарю :)
        • 0
          они там, к слову, не только в названии, но и в лого :)
  • 0
    Я правильно понял, что решением проблемы — включить некую внутреннюю службу, которая сама перезагружает роутер, когда он наглухо зависнет при попытке анализа пакета?
    • +3
      Решение проблемы при включенном nbar — это обновление protocol pack.
      А как сопутствующий костыль — это настройка watchdog
      • 0
        Так ведь watchdog по факту тоже не помог. Получается, что решение до следующего (надеюсь, нескорого) затыка в правилах
        • 0
          В каких-то случаях watchdog помогает… но не в нашем :)
  • 0
    А модель какая?
    Версия IOS?
    • +1
      В полуофициальной беседе с TAC удалось выяснить, что заффекчена вся ISR G2 линейка. Версия IOS при этом особой роли не играет.
  • 0
    История, конечно, любопытная, но если бы я писал по посту на каждый открытый мной и вызывающий крэш баг…

    Разумеется, полное окукливание без перезагрузки — совсем плохо. У меня сейчас такая «проблема» имеется — если на 2911-й роутер вылить 100cps совершенно обычных SIP звонков, то с ним происходят поистине волшебные метаморфозы, не поддающиеся описанию…
    • +2
      Ну я с таким сталкиваюсь первый раз. Если это станет обыденностью, то может больше писать и не буду :)
      • 0
        Ну и кстати в лабе TAC проблема, как обычно, не воспроизвелась? :)

        Ну и core dump, если настроить на флеш тоже не записался? На моих падениях крэшдамп создается с нулевым размером, а вот core dump — нормально.
        • +1
          В том и дело, что программеры про это знали. Но решили не патчить IOS, а пропатчить базу сигнатур. Плюс мы на стенде ее воспроизвели и еще и TAC на стенд пустили
          Насчет coredump/crashdump, честно, уже не помню.
          • +1
            Девелоперы — всегда больная тема. Но обычно подобное поведение (включая скрытие бага) значит, что хотя у вас проблема и воспроизвелась — для этого потребовались какие-то специфические условия, которых у подавляющего большинства других пользователей нет. NBAR под «специфические условия» не подпадает. Сайт outlook.com — тоже. Значит, было что-то еще.

            Меня тоже раздражает, когда напарываешься на баг — а он скрыт.
            • 0
              Ну больше ничего они не сказали, сказали только как вылечить. А ковыряться еще глубже… в общем, не фонтан =)
  • +1
    Респект за то, что распутали!!!
    Тут бубен нужен такой что огого!!!
    • +2
      Распутал не я один, а с коллегой :) Но было весело, да
      • 0
        Из подобного вспоминается случай, когда при включении в управляемый D-Link (не помню какой конкретно) камеры Trendnet D-Link вешался так же наглухо. Помогал только рестарт на холодную. ТП D-Link как бы не помогли, обновление прошивки и танцы с бубнами тоже…
  • 0
    А зачем QOS наружу? Любой провайтер его режет policy-map-ом тут же. Или не режет?
    • 0
      Тут IPVPN-каналы арендованные, так что QoS сохраняется
      • 0
        IPVPN — другое дело, там SLA, каждый килобит за деньги и вообще TE.
        В публичном internet-е халявы нету, какой-нибудь из магистральных операторов обязательно срезает.
    • +1
      QoS наружу нужен даже если провайдер игнорирует TOS. Ибо с входящим трафиком проблемы, но вот с исходящим можно делать что угодно, не доводя дело до провайдерского полисера. Ну а на вопрос «зачем маркировать в пределах одного роутера» ответ «роутеры разные бывают, и интерфейсы разные бывают, иногда без маркировки пакета на одном интерфейсе и последующей приоритезации на основании маркировки на другом никуда».
    • 0
      Бывают случаи когда нужно сохранить и маркирование от CE и иметь возможность воздействовать на трафик своими (операторскими) полисерами. Чаще всего при туннелировании трафика, предоставлении L2/L3 vpn для корпоративных заказчиков между их сайтами. Обычно такая модель называется short pipe.
      • 0
        Оригинальный автор упомянул outlook.com в публичном сегменте, что удивило.
        • 0
          Филиал -> HQ -> прокси -> outlook.com

          что не так?
          • 0
            что не так?

            Дак отсутствие слова IPVPN в посте. От этого неясно, зачем полиси и зачем NBAR. Может там

            Юзер -> прокси -> DMZ -> фронтальная цыска -> outlook.com

            P.S.
            Автор уже ответил.
  • +1
    Мне больше всего интересно то как вы выяснили что беда именно с outlook.com?
    • +1
      Коллега пропарсил тонны сквидовских логов
      • 0
        Сурово. Вообще конечно красавцы, проделали огромную работу.
  • +4
    Меня умиляет этот ответ разработчиков:

    it is rather a general behavior of ISR routers in case of loops at the interrupt level.
    If the interrupt service routine in the router is suspended or stalled it might cause the router to hang


    Но подпрограммы обработки прерываний (ISR) не должны зависать и зацикливаться! Если они это делают — значит в них имеется баг. Ну или в системе происходит порча памяти, зависание с удержанием критических блокировок и т.д., что тоже следствие багов.

    А тут какой-то странный демагогический ответ, обосновывающий, что, дескать, все нормально.
    • 0
      ISR — Integrated Services Routers
      • 0
        Это и то, и другое. И роутер, и петля на уровне прерываний.
      • +2
        ISR — Interrupt Service Routine :)
    • 0
      Вообще побороть вечный цикл в обработчике прерываний действительно может быть не так-то просто без серьезной переделки архитектуры ядра и возможно даже железа. Выглядеть такой баг будет действительно как глухое зависание всей системы (так как обычно на многих фазах обработчика прерываний все другие прерывания запрещены).

      Часто действительно проще по-быстрому пропатчить «прикладной» софт, чтобы он не вызывал вечный цикл.
      • 0
        А почему не предусмотреть отдельного вотчдог-чипа?
        • 0
          И что он должен делать?
          Ребут?
          Ну будет вместо просто зависания циклический ребут.
          • 0
            а почему циклический? после ребута система оживает, до следующего «волшебного пакетика» =) за это время можно успеть отключить порт, например
  • –7
    Все проблемы начинаются с неуместного тут слова «кошка» :)
    Мужик решил напрячь маршрутизатор несвойственными ему задачами (инспекция прикладного уровня всё-таки далека от понятия «маршрутизатор»), а потом удивляется, что что-то не работает. Вот когда начнёт называть вещи своими именами, глядишь, некоторые проблемы уйдут ;)
    • +2
      А с каких пор у нас QoS и инспекция трафика не могут делаться маршрутизатором? Это сейчас умеют и ISR, и Juniper SRX.
      • –3
        «могут» и «должны» — это разные понятия.
        Именно как маршрутизаторы ISR G2 стабильны, и если есть какие-то проблемы, стоит начинать с отделения мух от котлет.
        • +4
          Простите, но если железка за десять штук баксов умеет только routing/nat и не умеет qos/inspect/ipsec (нужное подчеркнуть), то такую железку надо выкинуть нахер
          • 0
            но если железка за десять штук баксов умеет только routing/nat и не умеет qos/inspect/ipsec (нужное подчеркнуть), то такую железку надо выкинуть нахер

            Ого.

            У меня есть железки за сотни тысяч долларов, прилично умеющие routing (с ограничениями по числу маршрутов и по некоторому специфическому функционалу), кое-как умеющие NAT и QoS (первое лучше вообще никогда не включать, второе очень ограниченное по сравнению с ISR) и вообще не умеющие вникать в L7 и шифровать трафик. Вы предлагаете мне выкинуть их нахер? А что вместо них поставить? Сто ISR маршрутизаторов, которые только совместными силами переварят нужный объем трафика? :)
            • +2
              У меня есть железки за сотни тысяч долларов, прилично умеющие routing

              Не смешивайте операторское железо и энтерпрайзное :) У операторов одна железка обычно пользуется для одной функции (routing, switching, etc). ISR же заявлен как решение все-в-одном именно для энтерпрайза.
              • 0
                Я — ентерпрайз. Я предпочитаю использовать одну железку для одной функции (в первую очередь — чертовы баги, и мне не нравится, когда баг в SIP кладет DMVPN хаб или тому подобное).

                То, что вы озвучили, это не ентерпрайз, а SOHO. Или мелкий ентерпрайз-бранч, где всё скучно и на уровне того самого SOHO.
                • +1
                  Я предпочитаю использовать одну железку для одной функции

                  У меня в центре есть отдельный фаервол, есть роутеры, есть бордеры. SIP-шлюзы тоже отдельно, да. И из-за багов в том числе.
                  Но ставить в филиал на 100 человек три железки (для SIP/Routing/NAT)? Зачем? Когда с этим вполне справляется один ISR? Много от него не требуется — простейший фаервол на уровне acl, qos, routing, sip. Скажете много? Я так не думаю.
                  • –1
                    А это уже мелкий ентерпрайз-бранч, и, как я уже говорил, мелкие бранчи скучны.
                    • 0
                      Они работают, и это главное. Значит, у меня есть время поковыряться с чем-нибудь интересным.
    • +1
      Мужик решил напрячь маршрутизатор несвойственными ему задачами

      Чо? ISR — давно уже мегакомбайн, умеющий всё вплоть до отправки твитов в твиттер. И функционал, связанный с AVC, активно продвигается циской. Так что не надо тут этого… Баг есть баг, они есть и в процессе OSPF, и в SIP, и где угодно.
    • +3
      Если функция имеется в железке, описана вендором и на нее нет ограничений в документации вендора, значит она железу СВОЙСТВЕННА и никак иначе (Или пусть пишет в даташите вместо сотен страниц болтологии о том что в новой версии все быстрее и лучше пометки, что функция добавлена маркетологами и вообще бета, не включать). И пока вендор называет себя энтерпрайзом, пусть будет так добр поддерживать указанный им в документации функционал на достойном рабочем уровне. Вспоминаю как я неделю просношался с Juniper MX серии, которому функция брас не свойственна, но ДОКУПАЕТСЯ за много денег и после покупки, работает так, как луче бы не работала и не продавалась, то радиус пакеты задваивает, то PPPoE строится на физических линках, но срыгивает с агрегаций, то версия прошивки не работает вообще в брасе корежа пакеты (найди из 10 версий, предложенных вендором такую, чтоб работали все нужные тебе функции и молись чтоб ничего не понадобилось в дальнейшем). Простите, но на какой переплачивать за именитого вендора, если он не может обработать заявленный функционал(именно заявленный а не NAT на 7тонниках и прочий изврат), если бы хотел поработать бетатестером, ставил бы длинки и прочее SOHO, а тут циска вроде как вполне взрослая контора и туда же: «Это не баг, это фича».
  • +3
    Побольше бы таких статей (необязательно топик-стартера) с поиском и пинаний саппорта. Жаль, что коротенькая, но чрезвычайно интересная. Добавил в ИЗБР
    • 0
      спасибо на добром слове :)
      • 0
        ошибся
  • 0
    Спасибо за статью. Судя по ответу компании в ней просто некому такого уровня баги исправлять. Для такой компании — это потеря репутации.
    • 0
      Возможно им действительно было проще и дешевле тихо исправить protocol pack, чем править баг в IOS
      • 0
        Эти баги в каждой версии софта патчатся сотнями.

        У меня есть пара железок, работающих на специально под меня оперативно собранном циской образе. В нем три багфикса. Все три бага вызывали падения.
      • 0
        Подпераем баг костылем? Я не админ — но когда-то решил себе купить вайфай-ретранслятор, посмотрел цены на Циску — перекрестился. Странно что при практически золотом оборудовании такое отношение к фирмвару.
        • +1
          По помоему опыту от цены оборудования это не зависит. Код чем дальше, тем хуже. причем у всех
          • +1
            зато слать твиты умеет.
            • 0
              Скоро прогноз погоды показывать начнет, а толку?)
    • –4
      Меня всегда радуют люди, делающие такие заявления… Не зная ни внутреннюю кухню, ни людей, ни их компетенцию.
      CSCO компания учавствующая в расчете Nasdaq, а чего добились Вы?
      • +3
        Внутренняя кухня и компетенция людей как раз лучше всего видна по багам и манере отвечать на вопросы.
        А добились мы внутренней гармонии а так же умения вычислять такие баги и их делателей, Nasdaq нам по барабану.
        • –1
          Имеюший внутренню гармонию такого бы не написал.
          Можете хоть как-то аргументировать свои утверждения? Или показть хоть один столь же массовый продукт без ошибок? Или что конкретно плохого было в ответе разработчиков?
          • +2
            Аргумент простой: это очень серьезный баг, глубоко в недрах и с фатальными последствиями, однако разработчики о нем похоже давно знали и тем не менее вовсе не рвутся фиксить, предпочитая костыли. Я вовсе не сужу обо всей Cisco, однако квалификация конкретно этой команды по-моему достаточно очевидна. Кроме того, наличие такой команды неизбежно бросает тень на всю компанию.
            Я стараюсь не обращать внимания на массовость продукта и былые заслуги (которых у Cisco много), а сужу по конкретной ситуации. Баги есть у всех, относятся к ним по разному. Сам я никоим образом не нетворкер, однако такие симптомы должны настораживать.
            • 0
              Я специально посмотрел кейс и переписку с разработчиками. С чего Вы решили что проблему знают давно? То что проблему знают не означает, что ни чего не делается. Назначен аудит кода и есть вполне реальный план по устранению. Почему инженер это не упомянул при общении мне лично не понятно. Возможно и поста бы не было.

              Мне кажется тут какое-то гиганское недопонимание. Хотя конечно же проблемы есть и их не мало, но невозможно исправить все мгновенно.

              • 0
                Если проблема известна, почему ее нет в known bugs? Зато есть костыль, да
                • 0
                  В паблик попадают дефекты, обнаруженные пользоватлями. Если дефект обнаружен разработчиками, то его не оформляют для конечных пользователей, т.к. чаще всего он выявляется на промежуточных версиях.

                  Все задокументированно и есть в публичном доступе. CSCun69013 Или Вы про другое?
                  • 0
                    Ну вот собственно после нашего обращения и завели known bug. А до этого был ответ от разрабов, что про багу они знают, но пока не фиксили и вообще не публиковали. Мне вот это непонятно. Если баг есть на релизных ветках, и о нем известно, почему его нет в known bugs?
                    • 0
                      Потому что Вы единственный кто столкнулся в продакшене…
                      • +2
                        Однажды сотрудник TAC в рамках одного кейса предложил мне сделать debug platform packet-trace на железке, к которой были аномалии с data plane в определенной ситуации. Я посмотрел баги — вроде ничего. Спросил парня «не сдохнет?» — «меня разработчик уверил, что это совершенно безопасно». Роутер сдох сразу после включения. Это был известный баг, скрытый. Если бы баг не был скрытым, продуктивный роутер не ушел бы в ребут посреди дня, ненадолго, но теряя трафик.

                        Когда же они поймут, что то, что нашли девелоперы, рано или поздно найдут и кастомеры?
                        • 0
                          По мне так все неправы. Без окна обслуживания ни каких работ на критичном оборудовании.
                          То что ты описал есть в свободном доступе. CSCuj82468
                          • 0

                            Но по-моему, его действительно открывали на какое-то время, но не уверен. Факт тот, что на момент, когда моя железка упала, гугл не знал об этом баге (его и в release notes не было). Я проверял после получения его номера.
      • +3
        Репутация-то не пострадает, она и так весьма средненькая среди тех, кто много работает с разнообразным цискиным софтом (боговорят циску только краем уха слышавшие или работающие с от силы парой устройств и задействующие минимальный набор издавна существующих и вылизанных фич). Проблема с качеством софта — наисерьезнейшая, уж тебе ли это не знать? Вон писали обещания, может, что-то улучшат, а может, и нет. А жалобы-то идут давно. Были лозунги «15-й иос решит все проблемы, вместо нескольких десяток веток будет от силы пять, легкая портабельность протестированного кода, рай». Ну и что? Мои ASR1k, работающие на дебаг-образе с тремя фиксами по трем открытым с моей подачи багам, говорят, что как была жопа, так и осталась. Да, знаю, что в IOS толком отсутствует защита памяти и один процесс запросто может похерить другой, потому малейший сбой чреват падением. Но мне-то от этого не легче.

        Greg Ferro в блоге правильно писал. Cisco TAC прекрасен. Эскалация с TAC на разработчиков менее прекрасна, но, по словам моих ASR1k, процесс работает, баги правятся. Но «TAC has to be good because there are so many problems with the products».

        Я все-таки хоть и чуть-чуть, но знаю внутреннюю кухню и людей. Даже слишком хорошо знаю для клиента. Такого на самом деле быть не должно. Фактически, любой новый крупный проект — и я поименно знаком минимум с половиной сотрудников поддержки, работающих по этому направлению, плюс десяток багов завожу и еще о десятке узнаю (из них половина скрыта, да). Грустно.
        Или показть хоть один столь же массовый продукт без ошибок?

        У меня в кармане телефон с Android (Nexus 5, 4.4.2). Эта версия считается забагованной. Сравним с release notes абсолютно любой ветки абсолютно любого софта циски? Периодичность обновлений схожая. Я, кстати, этих глюков не вижу.
        Передо мной компьютер с Windows 7. Раз в месяц (изредка — внепланово) выходят обновления. Практически все — обновления безопасности. Это обычно когда злобный дядя может, поигравшись с ИМХО самым сложным в мире с сетевой точки зрения протоколом SMB (или RPC), что-то похакать. Но, как и почти всё мое сетевое железо, мой компьютер недоступен из интернета и я не запускаю зловредный код (незловредного где-то триста единиц проинсталлировано). И он не глючит. От слова «совсем». Эта семерка прошла долгий путь от самой первой беты 7000 без переустановок (категорически не рекомендовано), она дважды полностью меняла платформу, один раз была смена видеокарты с зеленой на пару красных, иногда падали глючные видеодрайвера (перезапускались). Хотя нет, вру, глюки были, один раз они решились заменой сильно сыпавшегося винта с приличным повреждением ФС так, что запуск стал невозможен (повторюсь — система не переустанавливалась после этого, содержимое было клонировано на новый накопитель с последующей точечной починкой), другой раз память барахлила.
        что конкретно плохого было в ответе разработчиков?

        Фактически, проблема пользователя решена, так что ничего плохого. Но это говорит о том, что кое-что там просто боятся трогать, чтобы окончательно не развалилось.
        • +1
          Репутация-то не пострадает, она и так весьма средненькая среди тех, кто много работает с разнообразным цискиным софтом

          BMW плохая машина, но лучше-то нет. Мое мнение конечно же предвзято (это я про Cisco), т.к. один из любимых брендов. Но я точно знаю, что не все так плохо. Хоть и медленно, но становиться лучше. Мне тоже очень жаль, что Cisco это не tech church в этом смысле, но я понимаю, что такое бизнес и как он работает. К истории про Петю и Васю можно относиться по разному, но в итоге все понимают, кто прав.

          Проблема с качеством софта — наисерьезнейшая, уж тебе ли это не знать? Вон писали обещания, может, что-то улучшат, а может, и нет. А жалобы-то идут давно. Были лозунги «15-й иос решит все проблемы, вместо нескольких десяток веток будет от силы пять, легкая портабельность протестированного кода, рай».

          Постепенно все к этому и идет. Медленно, но изменения есть. PI (platform independed) код практически везде в 15.х одинаков.

          Ferro читал. Что-то правда, что-то очень далеко от неё. Да и аналогия с маком так себе. За последние полтора года открыл 15 баг репортов в apple, на один из них получил ответ через три месяца. Можешь сравнить это с работой TAC. 3 раза рассыпалась файловая система, 1 раз по вине ssd и т.д.

          Я все-таки хоть и чуть-чуть, но знаю внутреннюю кухню и людей. Даже слишком хорошо знаю для клиента. Такого на самом деле быть не должно. Фактически, любой новый крупный проект — и я поименно знаком минимум с половиной сотрудников поддержки, работающих по этому направлению

          Вопрос поднимался по поводу компетенции. Что все безоговорочно имеют низкую компетенцию, раз мгновенно не исправили. Можешь что-то сказать по этому поводу? Ну а раз не должно быть, то можем и исправить :)

          Или показть хоть один столь же массовый продукт без ошибок?


          У меня в кармане телефон с Android (Nexus 5, 4.4.2). Эта версия считается забагованной. Сравним с release notes абсолютно любой ветки абсолютно любого софта циски? Периодичность обновлений схожая. Я, кстати, этих глюков не вижу.

          То что, ты не сталкивался не показатель. Сам мне на это указал несколькими поставми выше. Просто ты не туда смотришь. code.google.com/p/android/issues/list вот с этим уже вполне можно сравнивать… И гугл я тебе скажу не блещет. Лет 5 уже висит нерешенной бага с пропаданием сообщений gtalk.

          Передо мной компьютер с Windows 7.

          Тоже далеко не идеал, как-нибудь в очередной раз расскажу. Но пожалуй соглашусь, продукт и правда хороший.
          Только вот сравнения в обоих случаях совсем некоректны. Разница просто колосальная между продуктами. И еще одно, может конечно моя информация устарела и сейчас что-то изменилось, но еще 3 года назад в мире небыло ни одного _полного_аналога_ ISR! Почти уверен, что нет до сих пор. Да, комбинацией нескольких устройств заменить его можно, но одним нет.
          Я точно знаю, что в любой продукт можно ткнуть пальцем и показать на такое, от чего волосы будут шевелиться, но в общем счете это ни чего не меняет.

          что конкретно плохого было в ответе разработчиков?

          Фактически, проблема пользователя решена, так что ничего плохого. Но это говорит о том, что кое-что там просто боятся трогать, чтобы окончательно не развалилось.

          Нет, не боятся. Но наскоком и правда не решить. Всегда есть приоритеты в решении таких задач.
          • +1
            т.к. один из любимых брендов.

            Да вот та же фигня :) Колюсь, плачу, но кушать продолжаю.
            Можешь сравнить это с работой TAC.

            Я о том и говорю — к TAC вопросов никаких, лучшего саппорта нет. Но в идеале, с этим саппортом клиент должен контактировать редко. И у клиента не должно быть в среднем по 5 одновременно открытых кейсов.
            вот с этим уже вполне можно сравнивать

            Половина — фичареквестов.
            Открываем любой release notes, делаем ctrl+f «crash». Мое любимое развлечение.
            Разница просто колосальная между продуктами.

            Есть одно колоссальное различие. Windows выполняет сторонний код. IOS — нет. Плагины IOS-XE не в счет.
            ни одного _полного_аналога_ ISR!

            Да, ISR хорош с точки зрения фич. ASR1k имеет первоклассное железо и очень близок к ISR по функционалу. Но блин, оба глючат. ASR1k чаще.
            Да, комбинацией нескольких устройств заменить его можно, но одним нет.

            Да в целом его можно заменить одним устройством. Это устройство будет работать на линуксе, и на нем будет куча софта. По большинству направлений есть опенсорсные альтернативы. Но да, при наличии малейшего выбора я за ISR.
            Всегда есть приоритеты в решении таких задач.

            BU вообще временами очень странные ребята. Встречался я с одним из них пару месяцев назад, ни по одному из моих вопросов до сих пор нет обещанных комментариев, зато вот послушал рекламу будущего функционала, из-за которого нужного мне функционала не будет еще очень долго (все ресурсы брошены туда).
            • 0
              Есть одно колоссальное различие. Windows выполняет сторонний код. IOS — нет. Плагины IOS-XE не в счет.
              Это не отличие. IOS — RTOS. Windows — нет. Вот это отличие, так отличие. Ну и по мне так, винде проще. Многое изначально реализованно в железе интелом.

              Про машину с линуксом не подумал. Сейчас уже наверное и dmvpn можно, а вот на счет auto qos не уверен. Да и сложности с поддержкой в целом, ведь это не решение от одного вендора.
              • 0
                Это не отличие.

                То, что на одной платформе априори не может быть запущен написанный кем-то другим код (ну да, tclsh, но это мелочь), а на другой куча хлама аж в ring0 прописывается, если хочет (и система обычно переживает это и продолжает нормально работать) — не отличие, а мелочь, да :)
                Собственно, 99% «глюков винды» вызваны именно либо кривым чужеродным кодом, залезшим чуть ли не в ядро (где от него особо не защитишься), либо аппаратными проблемами.
                а вот на счет auto qos не уверен

                Эм… Речь про макросы на каталистах? Или per-tunnel qos? С тем, кстати, свои заморочки. Эта штука теряет всякий смысл, если разрешать динамические spoke-to-spoke туннели, одну из главных фич DMVPN, за которую его и любят.
              • 0
                Кстати.
                IOS — RTOS

                А IOS-XE, который линукс с процессом IOSd внутри, тоже RTOS?
                • 0
                  Да. Там же ядро c rt патчами.
  • 0
    не отличие, а мелочь, да :)
    Нет, ну правда. Подходы совсем разные. Если уж винда, то и сравнивать с NX-OS например. Как наиболее близкое. С IOS-XR опять же не сравнишь. Повторюсь венде сильно проще было с интелом. MIPS и PowerPC даже не снился в те времена аналог защищенного режима.
    А пуская кого-то в такую систему, нужно начинать и за ним слежить и гарантировать чего-то. Если уж реально нужно, то надо пользоваться сервисными модулями. И пускай на них что хочешь.
  • 0
    Я вот не совсем понимаю, а почему watchdog не перезагружает девайс в таком случае? Как такое может быть?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное