По информации Reuters, иностранное государство смогло как минимум один раз воспользоваться бэкдором в продукции Juniper Networks Inc, который был предусмотрен по соглашению с американским Агентством по нацбезопасности. О том, что оборудование было взломано, сообщалось еще в 2015 году.

Эксперты компании ESET выяснили, что многие компании, продающие бывшие в употреблении роутеры, коммутаторы и интернет-шлюзы производства Cisco, Fortinet и Juniper, не заботятся об информационной безопасности и не удаляют хранящиеся на сетевых устройствах критичные и конфиденциальные данные.

Многие задаются вопросом как устроена сеть провайдера или как им самим строить сеть, в данной статье я покажу как спроектирована и работает сеть у меня, на логическом уровне. Хотя не считаю свою структуру за идеальную, можно было сделать и лучше, но это мое имхо :) ибо истина “спроси у 2-х провайдеров как строить сеть – получишь 3 разных варианта “

Теперь подробнее о том как это работает

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

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



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

Итак, сегодня, точнее вчера уже, побывал на первом дне конференции CloudConf 2010 и вот делюсь впечатлениями. Они не однозначные. Хотя только то, что узнал много нового и есть над чем подумать – уже хорошо. Время позднее, хочется спать так что много писать не буду… Сделаю просто: во-первых, я в течении конфы отчаянно твиттил. Это упрощает воспоминание, и может помочь хабравцам понять, что я переживал и над чем раздумывал. Во-вторых, я все записал в диктофон своего старого мобильника. Так что у тех кто на конференции не был есть уникальная возможность получить предварительную информацию, еще до выхода «официальных результатов конференции». Безусловно, дня через три все необходимое у организаторов (SoftLine) будет представлена в видео-формате, снабжено презентационными материалами… но это будет отредактированная и вышелушенная информация. Потому и представляю вам свои твиты и mp3-записи наложенные на программу конференции. Твиты содержат ссылки на мобильные фоты с мест событий, так что это получится почти «эффект присутствия»… Считайте, что вам попалось место в зале, с которого «плохо видно»…

Juniper Research выпустил аналитическую записку под поэтичным названием «Голос в мобильных сетях – шепот перемен» (Mobile Voice — Whispers of Change), в которой дает краткий обзор своего более обширного доклада, посвященного стратегиям развития VoIP сервисов в мобильных сетях.

По оценке Juniper Research число пользователей мобильного VoIP превысит 100 млн. человек уже в этом году.

Рост их числа будет скорее всего выше на развитых рынках (благодаря инфраструктуре), хотя итоговые объемы трафика могут оказаться выше на развивающихся рынках (благодаря звонкам рабочих-мигрантов).

Их распределение по регионам Juniper представляет следующим образом:


Автор отчета Энтони Кокс (Anthony Cox) говорит, что Juniper ожидает пополнения в рядах операторов, которые строят особые отношения с VoIP сервисами, как это уже сделали 3UK и Verizon Wireless со Skype. Альянсы с мобильными VoIP сервисами и могут стать лучшим выходом для операторов, пытающихся понять, что делать с распространением мобильного VoIP.

БольшАя доля мобильного VoIP трафика пойдет через Wi-Fi сети, вообще в обход сотовых сетей операторов: такой трафик может означать потерю доходов сотовых операторов на уровне $5 млрд к 2015 г.

Исследователи Juniper предупреждают операторов, что в ближайшем будущем роль голосового трафика существенно изменится из-за структурных, технологических и конкурентных причин. В то время как проникновение голосовой связи достигло точки насыщения рынка, VoIP наоборот только набирает обороты, в связи с тем, что скорости передачи данных и возможности мобильных устройств позволяют теперь успешно передавать голос через IP. Помимо этого, Wi-Fi с одной стороны «разгружает» сети операторов, а с другой – дает новым игрокам возможности выйти на «голосовой» рынок. И наконец, увеличивается давление на операторов со стороны регулирующих органов, требующих введения/сохранения принципа “сетевой нейтральности” (net neutrality). И несмотря на все эти перемены, голос остается основным продуктом в сетях операторов.

Вступление

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

Многие из моих знакомых не до конца понимаю механизм работы rib-groups внутри Juniper's JunOS. В данной статье я попробую наиболее просто объяснить, что же это такое — rib-groups, и зачем они нужны.
Подробности под катом.

В это статье рассмотрена установка 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 JunOS на PC.

Миф первый: “Policer Filters (interfaces don't measure realtime traffic rates)”, данное утверждение можно найти на одном из авторитетных неофициальных сайтов о Juniper Olive.

Суть легенды заключается в том, то Policer Filters работают неправильно, интерфейсы измеряют трафик в реальном времени некорректно.

Для теста воспользуемся достаточно производительной системой на базе процессора Intel Core i7, с 8 Gb RAM и операционной системой Windows 7 (x64).

Также была использована самая свежая версия GNS3 (с приложениями входящими в её состав, такими как модифицированный qemu), еще был задействован акселератор — kqemu.

В роле маршрутизатора выступал Juniper Virtual JunOS 10.4 M/T Series, клиенты – debian lenny. Для маршрутизатора выделено 512 Mb RAM и 128 – на каждый клиент соответственно. Суммарная нагрузка на CPU системы не превысила 0.27.
Инструменты для генерации и получения информации о трафике Iperf.

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

Juniper анонсировал новую платформу на новом же супер-пупер чипсете Express. Называется платформа PTX. Есть две модели: показанный на картинке PTX5000 и непоказанный PTX9000, который тоже в два прокрута колеса мышки на экране высотой, но еще и в два раза шире.



Не волнуйтесь, дорогие хабровчане, это не пресс-релиз от лица компании Juniper Networks, призыващий срочно покупать новый продукт. Они со своей рекламой справятся как-нибудь сами. Да и покупать пока нечего: анонсирована не значит продается. Не говоря уже о цене.

Заходим на www.cisco.com , смотрим колонку Latest news и наблюдаем следующую статью — When You Overpromise and Under Deliver, You've «Junipered». Делаем вот такие глаза — о_О. Переходим по сылке попадаем на сайт www.overpromisesunderdelivers.net. Улыбаемся, читаем, улыбаемся, понимаем что не шутка, делаем вот такие глаза — О_О.

Кто знаком с подоплёкой? Была ли какая-то предыстория? Новый директор по маркетингу или влияние магнитных бурь?

В связи с ожидающим нас в скором времени событии: дне, точнее ночи, «не перехода на зимнее время», хочется рассказать про обновление базы временных зон на оборудовании компании 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 SRX100.
До этого времени в основном общался с Cisco и серией роутеров, типа 2800, 800.
На сколько я понял, могу ошибаться, данное оборудование ближе к классу аппаратных файрволлов.
Под катом первичная настройка данной железяки и выход в интернет.

Этой статьей я планирую открыть серию мануалов по Juniper серии SRX. Если это кому-то будет полезно – буду очень рад. И не стесняйтесь задавать вопросы.

Отмечу, что все ниженаписанное, скорее всего, будет подходить и к любой другой модели маршрутизаторов от Juniper (вследствие их слогана «One Junos», то есть одна операционка на все железяки). Данная статья основана на официальном англоязычном мануале по настройке NAT, взятом отсюда: www.juniper.net/us/en/local/pdf/app-notes/3500151-en.pdf.

Итак, проброс портов. Или по-научному, destination NAT. Тут надо сделать одно небольшое замечание. Некоторые админы привыкли под словом NAT понимать source NAT, со всеми вытекающими. И даже не source NAT, а одну из его разновидностей — PAT. Но надо понимать отличия между разными видами ната. Здесь я не буду вдаваться в теорию, на википедии все достаточно понятно написано. Я хочу сделать лишь одно пояснение: NAT – это всего лишь подмена адресов, ничего больше. Если вы понимаете суть этой технологии по-другому, вы неправы. Ничего больше, чем замена одного адреса в заголовке IP-пакета другим, эта технология не делает. И ничего изначально страшного и ужасного в ней нет. Соответственно, если мы говорим о destination NAT, то речь идет о подмене адреса назначения. Рассмотрим пример:

     В этой статья я постараюсь максимально доходчиво рассказать о том, как настроить Juniper серии SRX «из коробки». Статья подобного рода уже есть: habrahabr.ru/post/144218, однако моя отличается большей полнотой и подробностью настройки.
     Почему именно Juniper SRX, а не какая-то конкретная модель типа SRX100 или SXR240? Да просто потому что настройки будут полностью идентичными, ввиду полной одинаковости платформы – Junos OS. Это очень удобно, когда вроде бы разные по цене и производительности девайсы настраиваются абсолютно одинаковым образом. В этом лишь одно из достоинств Junos OS.

     В данной статье я опишу, как с помощью родных средств Juniper SRX можно действительно легко и изящно разрулить некоторые раздражающие схемы маршрутизации. Речь пойдет об использовании виртуального маршрутизатора, а точнее, в терминах Джуниперов, routing-instance virtual-router.
     Кратко проблему можно сформулировать так: есть два или больше внешних Интернет-канала (ISP1 и ISP2) и есть веб-сервер внутри сети. На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам. Надо чтобы клиенты обоих провайдеров видели веб-страницу. Проблема в том, что, если, допустим, основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.