Комментарии 16
Привет Анатолий от Краковского TAC'а. &)
А вот за музыку спасибо :)
1. Спасибо, что в субботу.
2. Это, пожалуй, самые продуктивные 2 часа 22 минут за эту неделю.
3. Долгожданные гости!
4. Ссылка на тот самый пост про спор? :)
5. Хочется, совета литературы/книг по архитектуре коммутаторов/маршрутизаторов (Cisco Press CEF, etc.), особенно от Анатолия. Помимо BRKARC.
6. Огромное спасибо команде LinkMeUp.
7. 2:09 это дочка или музыка?
2. Это, пожалуй, самые продуктивные 2 часа 22 минут за эту неделю.
3. Долгожданные гости!
4. Ссылка на тот самый пост про спор? :)
5. Хочется, совета литературы/книг по архитектуре коммутаторов/маршрутизаторов (Cisco Press CEF, etc.), особенно от Анатолия. Помимо BRKARC.
6. Огромное спасибо команде LinkMeUp.
7. 2:09 это дочка или музыка?
2 часа 22 минуты 21 секунды) Немного не угадал при сведении.
Не услышал ничего на 2:09, но это может быть и ребёнок, хотя, вычищал как мог дорогу).
Ссылка на новость есть среди новостей: habrahabr.ru/company/beeline/blog/207162/
ответить редактировать
Не услышал ничего на 2:09, но это может быть и ребёнок, хотя, вычищал как мог дорогу).
Ссылка на новость есть среди новостей: habrahabr.ru/company/beeline/blog/207162/
ответить редактировать
5. Лучшая (из доступной кому-то помимо инженеров TAC и девелоперов) информация по архитектуре железок дается как раз на Cisco Live — актуальная, обычно достоверная и в понятной форме. Там есть много такого, чего в документации вообще нет. Смотреть надо и видео, и скачиваемые слайды (там бывают дебри, опущенные в самом выступлении), выбор большой по всем основным платформам. Изредка бывают хорошие вебинары и вне Live, этот например, за авторством Анатолия.
Доходит до смешного. У меня сейчас открыт один кейс, по одной довольно экзотической и исключительно отвратительно документированной технологии. Бельгинский боец TAC, в целом знающий и адекватный, изначально вообще не знал, как подойти к вопросу траблшутинга. Технология должна включаться одной кнопкой в GUI и сразу начать работать, а она, гадина эдакая, стабильно дропает определенные пакеты в определенных условиях, причем только у меня, но не в исключительно дотошно возведенной лабе. В общем, тот инженер траблшутит это дело с помощью слайдов к грядущему BRKCRS-3147, делиться ими не хочет, и никакой другой нормальной информации по теме в природе не существует.
На мой взгляд, с точки зрения понимания устройства железок самая правильная тема — QoS на них, а именно — то, каким образом каждая конкретная железка гарантирует доставку пакета без потерь в условиях переподписки на исходящем интерфейсе, на бекплейне и так далее. Если вы знаете данную сторону работы железки, то вы понимаете, как устроена и как работает железка.
Доходит до смешного. У меня сейчас открыт один кейс, по одной довольно экзотической и исключительно отвратительно документированной технологии. Бельгинский боец TAC, в целом знающий и адекватный, изначально вообще не знал, как подойти к вопросу траблшутинга. Технология должна включаться одной кнопкой в GUI и сразу начать работать, а она, гадина эдакая, стабильно дропает определенные пакеты в определенных условиях, причем только у меня, но не в исключительно дотошно возведенной лабе. В общем, тот инженер траблшутит это дело с помощью слайдов к грядущему BRKCRS-3147, делиться ими не хочет, и никакой другой нормальной информации по теме в природе не существует.
На мой взгляд, с точки зрения понимания устройства железок самая правильная тема — QoS на них, а именно — то, каким образом каждая конкретная железка гарантирует доставку пакета без потерь в условиях переподписки на исходящем интерфейсе, на бекплейне и так далее. Если вы знаете данную сторону работы железки, то вы понимаете, как устроена и как работает железка.
//коммент не к месту удалён//
[удалено — что-то я тоже промазал с ответом]
Спасибо за проделанную работу! Я ожидал, что после рассказа об эволюции линейки 6500, Анатолий скажет пару слов о линейке 6800.
Также, было интересно послушать ответы на вопросы о невозможности прочтения описания некоторых багов, и об отличиях Sup2T, спасибо Дмитрию, что задал эти вопросы.
Также, было интересно послушать ответы на вопросы о невозможности прочтения описания некоторых багов, и об отличиях Sup2T, спасибо Дмитрию, что задал эти вопросы.
Небыло цели охватить все платформы и все их разнообразие. Основная задача была заинтересовать, показать основы, дать источники откуда эту информацию можно подчерпнуть. Надеюсь это удалось.
По поводу дефектов, которые нельзя просмотреть. Большенство из них внутреннние, т.е. были обнаружены между релизами и не имеют ни какой ценности для конечных пользователей. Бывают и другие случаи. Например открыт дефект, а оказалось что на момент пролемы оборудование вышло из строя и к програмным дефектам ни какого отношения не имеет. В общем обычные рабочие моменты и в итоге принимается решение давать доступ к деталям или нет.
По поводу дефектов, которые нельзя просмотреть. Большенство из них внутреннние, т.е. были обнаружены между релизами и не имеют ни какой ценности для конечных пользователей. Бывают и другие случаи. Например открыт дефект, а оказалось что на момент пролемы оборудование вышло из строя и к програмным дефектам ни какого отношения не имеет. В общем обычные рабочие моменты и в итоге принимается решение давать доступ к деталям или нет.
Спасибо, приятно было узнать как работает изнутри контора, с которой работаешь в таких объемах (это я про Cisco TAC). Два часа прошли незаметно.
у меня одного запись «Архитектура ASR 9000 (на русском)» по ссылке не показывает?
ps: все заработало)
ps: все заработало)
Спасибо Марату за приглашение! Теперь смогу отвечать на вопросы лично.
// Анатолий.
// Анатолий.
Кстати если кто будет на идущем в Милане Cisco Live! — я буду там ТАС инженером в Design Clinic от NMS. Подходите, обсудим. &)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LinkMeUp. Выпуск 11. Cisco TAC, CEF, FIB