Буквально на прошлой неделе, во время европейского вояжа с заездом на CEBIT, летучая бригада «Оверсан-Меркурий» посетила с дружеским визитом офис голландской компании Juniper Networks, расположенный рядом со славным городом Амстердам. Juniper Networks производит магистральное сетевое оборудование и в данный момент переживает бурный рост. Это один из немногих производителей Старого Света, способных составить конкуренцию мощной Cisco и демпингующим китайцам. О продукции Juniper мы скоро расскажем отдельно, а в этом посте пойдет речь об офисе компании, а, точнее, о Customer Briefing Center. Это отдельная структура с двумя дата-центрами, предназначенная для визитов партнеров и покупателей Juniper. Здесь легко обсудить любые вопросы, и, что главное, увидеть оборудование в работе, в «живом» дата-центре.

Один из них служит только для демонстраций, в то время как во втором дата-центре созданы точные или близкие к таковым копии систем, реально установленных у крупных заказчиков масштаба British Telecom. Это позволяет, с одной стороны, демонстрировать по-настоящему мощные решения всем заинтересованным лицам, а с другой — моментально моделировать проблемные ситуации, предоставляя техническую поддержку практически в реальном времени. Такая роскошь, очевидно, доступна только самым серьезным заказчикам, но сам подход производит весьма благоприятное впечатление.



Во время визита было сделано немало фото, и самые любопытные из них мы предлагаем вашему вниманию.

В это статье рассмотрена установка Juniper JunOS версии 10.4 для маршрутизаторов M/T серии на виртуальный стенд VMware и последующая конвертация в QEMU Image для применения в среде GNS3.

Про версии

Мы устанавливаем свежую версию JunOS, но хочется отметить, что установка более ранних версий производится аналогичным образом, поэтому Вы не задумываясь можете взять любой JunOS OS install media, также нет никаких технических оговорок относительно domestic версий, содержащих крито модули.

Общая идея

JunOS базируется на FreeBSD и аппаратно отчасти на x86 архитектуре, о чем я уже упоминал в своей предыдущей статье.
План таков:
создание виртуальной машины -> установка FreeBSD -> установка JunOS на FreeBSD, предварительно произведя обман проверки PIC -> завершение установки JunOS –> конвертация для QEMU.

Под катом много снимков экрана.

В связи с ожидающим нас в скором времени событии: дне, точнее ночи, «не перехода на зимнее время», хочется рассказать про обновление базы временных зон на оборудовании компании Juniper Networks, Inc. исполняющем операционную систему Junos.

Сама процедура великолепно описана в документации представленной на сайте компании, в документе: "Setting a Custom Time Zone on Routers Running JUNOS Software". Я лишь расскажу о ней на родном языке и уточню отдельные детали.

Учитывая, что в операционной системе Junos используется довольно стандартный демон ssh, я осмелился предположить, что организация ssh туннелей в нём реализована. И хотя в документации о таком применении коммутаторов, маршрутизаторов или межсетевых экранов не удалось найти упоминания — это работает. Мало того, ssh туннели разрешены по умолчанию.

Приведу пример, позволяющий продемонстрировать, где это может пригодиться.

В этой короткой статье я опишу процесс настройки функций для переключения маршрутов между двумя провайдерами в случае, если физический линк присутствует и даже есть наличие локальной сети провайдера, но нет самого интернета.
Рассмотрим пример с 2 провайдерами:

• ISP1
  interface IP 1.1.1.100
  gateway IP 1.1.1.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0
• ISP2
  interface IP 2.2.2.200
  gateway IP 2.2.2.1
  netmask 255.255.255.0
  interface name ge-0/0/2.0

Конфигурирование будет состоять из двух этапов:

1. Настройка rpm — который проверяет доступность выбранных хостов
2. Настройка ip-monitoring — который непосредственно выполняет переключения рутинга

Этап 1

Как правило выбираются хосты изначально постоянно доступные для icmp-ping в моем примере. Для примера, а не для подражания возьмем для мониторинга IP крупных провайдеров: 213.180.193.3, 209.85.148.104. Я беру 2 IP для мониторинга так как по одному возможны ложные срабатывания. В реальной обстановке можно мониторить и сеть провайдера и хопы после его граничных маршрутизаторов.
Заходим в режим редактирования конфигурации из командной строки.

Приветствую,

Juniper опубликовал PR839412, который описывает уязвимость, существующую во всех версиях JunOS начиная с 7.6R1. Cпециально сформированный TCP-пакет направленный на RE (Routing Engine) маршрутизатора может привести к краху ядра. Деталей о том каким именно должен быть TCP-пакет — не предоставляется. На данный момент известных публичных эксплоитов нет.

Здесь уже есть несоклько статей про настройку маршрутизаторов Juniper SRX (например, раз, два, три и т.д.). В этой я постараюсь консолидировать полезную информацию, дополнив ее некоторыми приятными мелочами.

Всех заинтересовавшихся прошу под кат.

Сегодня я хотел бы рассказать как можно обновить версию JunOS на вашем Juniper SRX. Я буду экспериментировать с SRX240B.

Пост будет полезен начинающим администраторам, матерые гуру не найдут тут ничего интересного.

Заинтересовало? Прошу под кат.

Всем привет!

Эта статья — о скрытых командах операционной системы Junos. Тем, кто работал с оборудованием Juniper под управлением ОС Junos (сюда относятся серии MX, SRX, EX, QFX, T, J, и многие другие) наверняка известно, что кроме «официальных» (документированных) команд в системе имеются и недокументированные. Их особенность в том, что они не видны в интерфейсе командной строки по контекстной подсказке (это когда вводишь вопросительный знак) и для них не работает автозаполнение, то есть команду нужно знать и ввести полностью (все буквы). Видимо, самая известная (и самая бесполезная) из таких команд — show version and haiku, выдающая «японское» трехстишие о жизни сетевых инженеров.

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

В этой статье я расскажу о том, как можно получить список всех скрытых команд Junos операционного режима, в пределах какой-то начальной ветки. Метод основан на довольно простом наблюдении, но гуглением мне не удалось найти свидетельств того, что вопрос раньше ставился в такой форме. Пример скрипта на Python прилагается.

Технология VPLS уже давно зарекомендовала себя как способ объединения географически разнесенных объектов в единую L2-сеть. Такое решение хорошо масштабируется по сравнению с классической L2-сетью и позволяет избавиться от проблем L2-петель в ядре сети. Однако, часто возникает необходимость организации резервных каналов от абонента к VPLS-облаку. В такой ситуации есть опасность образования петель на участке PE-CE. Для решения этой проблемы существует несколько подходов. Вот некоторые из них:

• BGP-Based VPLS Multihoming
• Связка VPLS и STP
• MC-LAG

В данной статье я бы хотел рассмотреть первые два подхода.

Сейчас очень популярна тема сетевой автоматизации. Одним из инструментов такой автоматизации в мире Juniper является библиотека PyEZ, разрабатываемая командой Джереми Шульмана (Jeremy Schulman). PyEZ — это микро-фреймворк для удаленного управления и автоматизации устройств Juniper, написанный на языке Python. Основным преимуществом PyEZ является его простота и нацеленность на аудиторию сетевых инженеров, а не программистов.

Некоторые возможности PyEZ:

• Сбор «фактов», таких как серийный номер, версия ОС и т.д.
• Извлечение оперативной (аналог команд show) информации
• Извлечение конфигурации
• Изменение конфигурации

В этой статье я бы хотел остановиться на возможности извлечения оперативной информации на примере коммутатора EX4200.

В УЦ МУК (Киев) прошли воркшопы “JunOS как второй язык” 30 и 31 июля 2015, где слушатели на практике учились работать с основной ОС решений Juniper Networks.

Данные семинары были направлены на знакомство с операционной системой JunOS сетевых инженеров, которые ранее имели опыт работы только с Cisco подобными CLI (Cisco, Brocade, Huawei, ZTE и т.д.). На воркшопах, как теоретически, так и практически, были рассмотрены особенности и логика работы операционной системы, которая установлена на всех линейках оборудования Juniper.

Это был не простой семинар – в виде теоретической начитки, а был реальный воркшоп, на котором слушатели пытались что-то делать своими руками, настраивать шлюзы SRX.

Под катом репортаж, видеозапись воркшопа и шпаргалки, которые раздавали слушателям —

Чем больше знакомишься с оборудованием Juniper, тем больше влюбляешься в это оборудование и операционную систему JunOS. Сегодня речь пойдет о Static, Aggregate и Generate маршрутах. По этой теме есть статьи на английском (не встречал на русском даже переводов), поэтому решил написать свою статью. Надеюсь, помогу какому-нибудь начинающему инженеру.

Итак, начну. Все три перечисленых выше видов маршрутов по своей сути являются статическими маршрутами и прописывают в конфигурации junos в иерархии edit routing-options.

Итак, static route. Любой сетевой инженер знает что это такое. Нам надо попасть в какую то сеть, но нет возможности (или желания) использовать протоколы динамической маршрутизации, выход — статика.

Сегодня речь пойдет о «межоператорском» взаимодействии — BGP Inter-AS. Эти опции используют при необходимости прокинуть L3vpn между PE маршрутизаторами, находящимися в разных автономных системах. Стоит уточнить, что данные опции используются по большей части внутри компаний при поглощении/слиянии сетей, для взаимодействия между филиалами одной компании если они имеют свои автономные системы и свои mpls домены.
В статье рассмотрим следующие темы:
— BGP Inter-AS Option A
— BGP Inter-AS Option B
— BGP Inter-AS Option C
— Особенности настройки данных опций на JunOS
В данной статье будет много выводов из CLI Cisco и Juniper. Если вы не знаете основ mpls, разницы между bgp labeled-unicast и vpnv4 unicast, то читать данную статью вам нет смысла. Если же эти понятия вам знакомы, то прошу под кат.

Сегодня речь пойдет о команде vrf-table-label. Вначале вспомним о способах генерации vrf меток. Метки могут быть сгенерированны тремя способами — per-vrf, per-prefix и per-next-hop.

per-prefix — одна метка — один клиентский префикс, то есть если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х100=10 000 меток, что очень расточительно по сегодняшним меркам. Данный метод распределения меток vrf по дефолту используется в маршрутизаторах Cisco.

per-next-hop — одна метка на все префиксы клиента, которые имеют один и тот же next-hop. Если клиентский маршрутизатор подключен к PE маршрутизатору одним линком, то все префиксы будут иметь один и тот же next-hop, а значит одну и ту же метку. Данный механизм распределения меток vrf по дефолту в JunOS.

per-vrf — одна метка на весь vrf. С точки зрения распределения меток этот режим очень экономичен: если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х1=100 меток. При таком распределении меток vrf маршрутизатор должен делать помимо mpls lookup еще и ip lookup.

В жизни каждого системного администратора наступают моменты, когда возникает необходимость автоматизировать выполнение каких-то операций или, например, приходится часть своих полномочий делегировать подчиненным. Причем, желательно это сделать безопасно, а возможность накосячить свести к минимуму. Хорошо, если речь идет про сервер под управлением *NIX-системы — имеется превеликое множество предназначенных для этого инструментов. Но так везет не всегда…

Современные маршрутизаторы обрабатывают по несколько миллионов пакетов в секунду, работают с несколькими FV таблицами маршрутизации, позволяют реализовать огромное количество сервисов. Различные вендоры используют разный подход к построению оборудования. В данной статье не будет огромного количества выводов. Сегодня поговорим об архитектуре оборудования Juniper.

Все, кто хоть раз сталкивался с необходимостью внести изменения в конфигурацию оборудования Cisco под управлением IOS XR, знают, что в отличии от обычного IOS, IOS-XR требует производить коммит для применения конфигурации. Но как закоммитить конфиг, думаю, что знают все, кто хоть раз в жизни щупал IOS XR. А вот как откатить конфиг назад? На JunOS все легко и понятно, чего не скажешь об IOS XR. До определенного времени и я этого не знал, но в одну из ночей у меня было всего 5 минут, чтобы этому научиться, откатить конфиг и не получить аварию. В сети ничего, кроме мануала самой Циски на английском я не нашел, поэтому решил написать небольшой ликбез по данной теме, авось кому то пригодится.

Итак, поехали…

Где то год назад или раньше я писал статью, посвященную routing-instance в JunOS, где описал основные виды routing инстансов, за исключением virtual switch и evpn. О последней вы можете прочитать в статье о EVPN, а вот virtual-switch пока что остался без внимания. Многие недооценивают возможности данной routing instance — а ведь функционал приличен. В данной небольшой статье мы рассмотрим — что такое virtual-switch, с чем его едят и нужен ли он вам.