История сертификации сетевого эксперта Juniper JNCIE-ENT

[Rel1cto]

Поздравляю с ачивкой. :)
А нужны ли были для лабы роутеры J-серии? Я думал, SRX их во всём может заменить.

[RootDm]

Спасибо! Все верно, SRX пришел на замену J-серии. Собирал домашнюю лабу из того, что было и удавалось найти, поэтому они оказались в списке. Маршрутизаторы J2320 с модулями uPIM также использовал в качестве коммутаторов, тут появилась некоторая универсальность.

[zipo]

Я в качестве дополнения еще проходил симуляции экзаменов, что бы оценить уровень своей подготовки и готовность к сдаче экзамена. Симуляции тестов проходил тут: exambraindumps.com/

[RootDm]

Кстати, в Fast Track на juniper.net есть online-симуляция экзаменов JNCIA и JNCIS, и в случае успешного прохождения теста дается ваучер — 50% скидка на экзамен в тестовом центре VUE.

[JDima]

Поздравляю!

и консолью SecureCRT

Аккуратные вкладки SecureCRT по сравнению с мешаниной окон Putty на CCIE… Зависть…

[RootDm]

Спасибо!
Поддерживаю, т.к. на экзамене приходится управлять одновременно где-то 9 устройствами, в SecureCRT можно удобно переключать вкладки с помощью клавиатурного сокращения Alt+номер, также как и в терминале Linux / Mac OS.

[pavelodintsov]

Поздравляю с крутым достижение по укрощению крутого сетевого оборудования :) Сколько же стоил тестовый стенд? SRX-240 дивайс не из дешевых даже б/у.

[RootDm]

Спасибо! Покупал б/у SRX100 — около 5 и 6 т.р каждый, SRX210 — около 10 т.р. каждый. Все остальное, включая SRX240, временно заимствовал у коллег. Благо, мир не без добрых людей, огромное им спасибо!

[Insspb]

Поздравляю с сертификацией. на самом деле интересен профессиональный путь и осознание необходимости такой сертификации. Можете рассказать? Какие планы на будущее в плане работы? или всё это делалось для себя?

[RootDm]

Спасибо! Осознание необходимости профессиональной сертификации было связано с желанием перейти из системной интеграции к вендору. Так получилось, что желание осуществилось раньше, чем был сдан JNCIE-ENT. Поэтому в моем случае это скорее делалось для себя и своей уверенности в основной работе, да и останавливаться на полпути бессмысленно.
Как показывает практика, работодателей на собеседованиях больше интересуют реальные знания и образ мышления, а сертификат является отличным пропуском при первичной фильтрации кандидатов.

[Insspb]

Какие дальнейшие планы по сертификации? Ну и, если не секрет, повышение зарплаты окупает затраты?

[RootDm]

Есть только ориентировочные планы — скорее всего, это будет развитие по направлению SP. На мой взгляд, это будет логичным продолжением ENT, приведет к расширению кругозора и универсальным знаниям сетевого инженера.
Затраты окупаются, работодатель поддерживает такую активность.

[TPertenava]

Поздравляю и спасибо за хорошую статью. А какие материалы Вы использовали при подготовке к экзаменам более низких ступеней?
ПС. Исправьте плз имя Леонида Миренкова (не смог в лс с телефона написать)

[RootDm]

Спасибо! Материалы для JNCIA и JNCIS — из раздела Fast Track juniper.net, к JNCIP готовился с помощью книг издательства O'Reilly по маршрутизации, коммутации, SRX:
www.juniper.net/ru/ru/training/jnbooks/oreilly-juniper-library/
И отличных книг серии «Day One»:
www.juniper.net/ru/ru/training/jnbooks/day-one/

Конечно же, официальная документация на Junos также была основным источником. Кстати, на экзамене JNCIE-ENT была доступна вся необходимая документация, но времени ее изучать просто нет, поэтому я стремился довести до автоматизма практически все.

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

PS. Прошу прощения за опечатку, имя исправил.

[lostinfuture]

Случайно не на Вконтактовских маршрутизаторах лабу сдавали? То то они померли… :-)

[RootDm]

Сетевые инженеры ищут любые способы самоподготовки, некоторые собирают домашние лабы, а некоторые тренируются на боевых сетях.

[JDima]

У третьих есть лабы на работах, ибо изменения на боевых сетях в идеале тоже стоило бы обкатывать, особенно когда речь идет о новом железе/софте…

[rdntw]

там же коммутаторы глючили. И скорее всего это было Nexus 7k, а не Juniper

[lostinfuture]

telecombloger.ru/12313/034_dcvk2

[rdntw]

это новый ЦОД. а он писал что глючил старый ЦОД партнеров… Селектела вроде.

[elmanr]

Поздравляю! Firefly vSRX — отличная вещь, жалко что коммутация пока не поддерживается.
Интересно почему IS-IS не было на экзамене. В JNCIS-ЕNT он вроде есть.

[RootDm]

Спасибо!
Firefly Perimeter (vSRX) изначально задумывался как элемент виртуальной инфраструктуры, чтобы обеспечивать маршрутизацию и фильтрацию на границе сети. К сожалению, использовать его в качестве коммутатора не планируется, да и на самом деле бессмысленно в боевых проектах.

Про IGP есть некий стереотип, что в корпоративных сетях в основном применяется OSPF, в операторских сетях — ISIS, поэтому JNCIE-ENT используется OSFP (кстати, еще и RIP), JNCIE-SP — ISIS.

[Night_Snake]

Странный какой-то стереотип. OSPF прекрасно ложится на операторскую сеть. А вот как раз энтерпрайз любит придумывать всякую экзотику типа того же EIGRP

[alex_www]

Это не стереотип — тому масса причин. ISIS изначально поддеживате несколько address family, в то время как OSPF требовал двух отдельных версий OSPFv2 для ipv4 и OSFPv3 для ipv6. Поддержака ipv4 в OSPFv3 повяилась только в 2009 году и только в IOS-XR, IOS 15.x и Junos 9.x что сильно ограничивает варианты развертывания. Traffic engineering опять же в ISIS есть всегда и всегда включен. Вот тут еще можете почитать еще одно мнение по этому поводу routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/

[Night_Snake]

ну я конечно мало где был и мало что видел, но
OSPF у операторов видел много, а ISIS, наоборот, мало (если только это не пришедшие из седой старины решения)

[Chelioz]

Наш заказчик, не самый древний оператор, имеет IGP на ISIS. В лабах по провайдерским темам стараюсь только ISIS крутить, так как OSPF мне и так со всех сторон суют(в т.ч. циска), а знать и помнить приходится и то, и то.

EIGRP тоже не экзотика. Два хорошо всем известных (и не маленьких) гос-предприятия, находящиеся у нас на поддержке, совсем не брезгуют этим протоколом. Упрекнуть их в этом не могу, ибо проблем eigrp не вызывает там.

[Night_Snake]

Я не говорю, что EIGRP это плохо и им нужно брезговать. Учитывая распространенность цисок это, наверное, даже не экзотика, а ментсрим для энтерпрайза…
Но все равно, пропиетарщина это не айс =)

[alex_www]

В 21 веке EIGRP не актуален — он же не link state, посему не пригоден для traffic engineering. Даже если не нужен трафик инжиниринг сегодня, он может понадобится потом. К тому же плюсы EIGRP перед тем же OSPF даже 5 лет назад были уже не актуальны даже 5 лет назад.

[JDima]

В 21 веке EIGRP не актуален — он же не link state, посему не пригоден для traffic engineering

Ну положим traffic engineering может быть и концепцией управления трафиком…

Вот сегодня была задача, передаю в обрезанном виде, оставив только суть. Есть две железки, между ними ходит трафик по двум каналам связи. С метриками когда-то пришлось поиграться, чтобы нагрузка на каналы была похожей (без variance конечно). У железок есть по лупбеку. В результате тех манипуляций с метриками трафик между этими лупбеками в одну сторону ходит через один канал, в другую — через другой. Но вот потребовалось сделать наоборот — чтобы прямое и обратное направления махнулись местами. Задевать остальной трафик не надо, только лупбеки. Инкапсуляции недопустимы в связи с особенностями изначальной задачи (с ними смысл теряется). Сможете решить задачу исключительно средствами IGP, исходя из того, что задача эта разовая, на пару минут проверить, потом вернуть обратно и скорее всего никогда больше так не делать(? Для EIGRP это один стандартный ACL в одну строчку и одна команда с этим ACL. Ах да, железки, разумеется, в одной области…

Или еще пример. Есть две площадки, они обмениваются трафиком по двум линкам. Надо, вводя команды только на одной железке одной из площадок, увести весь прямой и обратный трафик с одного из линков — но чтобы при аварии на втором он сразу перетек обратно. Потерь быть не должно, в крайнем случае допустимо терять несколько десятков миллисекунд.
Дополнительная задача: выполнить такую манипуляцию не для всего трафика, а только для трафика между определенными префиксами.

(ну да, это я раз за разом пиарю одну конкретную фичу, но что поделать? В том и прелесть EIGRP, что каждый хоп может нести в сеть полную отсебятину, и остальные будут ему верить)

Что до MPLS TE… В определенных случаях он хорош. В других он не просто бесполезен, а еще и вреден, сильно усложняя сопровождение. Я вот честно понятия не имею, куда его можно прикнуть в собственной сети. Ну нет в нем надобности, совсем нет.

Да и в любом случае, explicit path прекрасно делается поверх EIGRP, пусть и с определенными оговорками.

[alex_www]

Да могу решить задачи выше в пару команд с учловием что у меня ISIS (а так и есть). Более того TE на случаи описаные выше ложится идеально, зафорсить какой хотим трафик ходить как хотим. При этом не переконфигурируюя роутеры по пути, а только ingress и egress.

[JDima]

Да могу решить задачи выше в пару команд с учловием что у меня ISIS

Ммм… Ради интереса — а как? Что-то ничего в голову не приходит…

TE на случаи описаные выше ложится идеально

В первом примере TE исключен, во втором — а как? Напомню, пакет идет с routerA на routerB, routerB должен как-то сказать routerA «через меня ходить нежелательно». Хотя можно повесить дополнительные цвета на все остальные интерфейсы… Но некрасиво это, если их много. Да и в некоторых случаях TE просто сломает сервис, так что надо без него (см. Appnav например).

а только ingress и egress.

А вот нельзя во втором примере трогать egress. Только следующий хоп за интересующим линком.

[rdntw]

расскажите решение задачек, пожалуйста. изменение метрики при помощи route-map?

[JDima]

Нет, проще. Offset-list.

[Chelioz]

Ну, уже не столь EIGRP проприетарно, новости уже давно проскакивали habrahabr.ru/post/172081/. Хотя относительно сертификации, вряд ли кто-нибудь окромя циски уделит достойное внимание этому бедному протоколу.
Другое дело, OSPF, который все любят, особенно за MPLS/TE. Давайте пихать это комбо во все офисы и лечить им заказчиков.

Прошу прощения за флуд не по теме, но тут уж либо принимаем экзаменационные топики, либо остаёмся без бумажек.

[sahe]

Предыдущие версии сертификационных экзаменов помимо теоретических вопросов содержали лабораторную работу
Так было в ENT треке, да? И вопросы, и лаба? Дело в том, что предыдущая версия JNCIP-M (который нынче называется JNCIP-SP) не содержала никаких вопросов, а представляла из себя полноценную 8-часовую лабу. Говорю как сдавший её три года назад в Амстере.

[RootDm]

Спасибо! Для задач SP функционала vSRX вполне хватает, для ENT нужен L2.
Что касается olive, то там, например, не получится сделать mpls l2vpn, vpls, что достаточно актуально.

[sahe]

Я готовился к JNCIP-M в qemu целиком и полностью. На тот момент была парочка глюков, но жить они не мешали. Собственно, работало всё, что нужно было на том экзамене, разве что ATM не было. Но он, слава богу, ограничился на экзамене двумя зазубренными командами. Причём я прошёл полный путь джедая — пользовался не готовыми сборками образов системы, а сам накатывал жунос на голую фряху, то ещё развлечение было.

[Sk1f3r]

Поздравляю вас с успешной сертификацией!

Если не против, оставлю здесь ссылки на статьи с моим мнением о экзаменах JNCIA-Junos, JNCIS-ENT, JNCIP-ENT.

[astim]

День добрый. Отличная статья, хотелось бы побольше информации о «подводных камнях» которые могут встретиться на лабе. Скажи, пожалуйста, достаточно ли iNetZero WB для подготовки или же требуется какой-то дополнительный источник? Было бы неплохо пообщаться на данную тему через скайп или другой мессанджер. Заранее спасибо.