Сервера, размещенные в сети администрируемой мной AS, часто подвергаются различным DDOS атакам. Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом. С каждым месяцем количество, сложность и мощность атак возрастает. Атаки в 300-400Мб/с выросли до 70-80Гб/с. В этой ситуации не все атаки могут быть отражены тюнингом серверов, а крупные атаки могут помешать работе и всей площадки в целом. Бороться с такими атаками необходимо силами всей команды хостинга. Сетевые администраторы также должны иметь средства борьбы с такими атаками на сетевом уровне. О таких средствах и пойдет речь под катом.

В этом посте я хотел собрать воедино всю информацию по системе сертификации RPKI, но тема оказалась достаточно обширной, кроме того наткнулся на несколько статей в русскоязычной части интернета в которых подробно описывается принцип работы RPKI (ссылки на эти статьи в конце поста). С примерами настройки и применения RPKI на живом железе все хуже. Поэтому решил сделать статью в стиле HOW-TO. Информация, представленная в статье, может помочь провайдерам автоматизировать процесс проверки получаемых префиксов от клиентов и исключить ошибки в фильтрах. Всех кому интересна защита динамической маршрутизации средствами RPKI и настройка RPKI кэш-сервера на Linux прошу под кат.

Данный пост я написал в порыве негодования и недоумения от того, как сетевое оборудование от мирового лидера в данном сегменте может сильно и неожиданно портить жизнь production-процессам и нам – сетевым админам.
Я работаю в государственной организации. Ядром нашей сетевой инфраструктуры является VSS-пара, собранная из двух коммутаторов Cisco Catalyst 6509E под управлением супервизоров VS-S720-10G-3C с версией IOS 12.2-33.SXI6 (s72033-adventerprisek9_wan-mz.122-33.SXI6.bin) на борту. Наша сетевая инфраструктура является полностью production и должна быть доступна практически 24*7*365. Какие-либо профилактические работы, предполагающие малейший останов предоставляемых сервисов, мы должны заранее согласовывать и выполнять в ночное время. Чаще всего это ночные квартальные профилактики. Об одной из таких профилактик я хочу рассказать. И я искренне не хочу, чтобы с вами повторилась моя история.

Не секрет, что CCIE является одной из наиболее влиятельных и значимых сертификаций в IT. Грядет очередное большое обновление, и мне захотелось осветить его основные изменения.

Кратко о технологии FCoE
FCoE (Fibre Channel over Ethernet), представляет собой ключевой протокол для поддержки унифицированной матрицы коммутации ЦОД, позволяющий консолидировать инфраструктуру ЦОД, повышать эффективность управления, а также наращивать гибкость и производительность инфраструктуры. Следуя курсу на использование Ethernet для унификации подключений в ЦОД, компания Cisco поддерживает протокол FCoE в своих ключевых продуктах, в том числе в коммутаторе для сетей дата-центров Nexus 5000 и в новой системе унифицированных вычислений UCS (Unified Computing System), которая объединяет вычислительные и сетевые ресурсы для поддержки виртуализации. Применение одной и той же физической среды для соединения серверов и сетей хранения данных SAN (Storage Area Network) упрощает серверную и сетевую инфраструктуру, а также инфраструктуру хранения данных.

Технология Fibre Channel over Ethernet (FCoE) представляет собой очередной этап эволюции консолидированных сетей хранения данных. Спецификация стандарта была предложена комитету T11 Национального института стандартизации США ANSI (American National Standards Institute) сообществом ведущих ИТ-компаний, в числе которых IBM, Intel, Brocade, Cisco, EMC, Emulex, Nuova, QLogic, Sun Microsystems.

В статье описывается включение FCoE на коммутаторе Cisco Nexus 5000

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

• Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
• Подключаемся к провайдеру по BGP
• Организуем резервирование и распределение нагрузки между несколькими линками
• Рассмотрим вариант резервирования без использования BGP – IP SLA

В последние годы многие компании применяют практику удаленного администрирования своего серверного парка. Такая необходимость возникает, если организация имеет несколько филиалов, или же полностью отдает техническое сопровождение инфраструктуры на откуп аутсорсинговым компаниям. В связи с этим высокую популярность приобрели системы удаленного управления серверами посредством Ethernet-сети на основе технологии IPMI (Intelligent Platform Management Interface).

Как-то незаметно на просторах IT прошла новость о покупке компанией Cisco копании Cloupia за 125 миллионов долларов США. Cisco увидела дополнение своего портфолио решений для Датацентров предоставляющих облачные услуги, софтом от Cloupia.Напомню также что Cloupia это первый оркестратор, валидированный обоими: Cisco и NetApp, для управления FlexPod архитектурой.Что такое FlexPod, можно ознакомится в соответствующей статье на хабре. Для пущей наглядности картинок будет много.

CUIC

CUIC — это оркестратор для инфраструктуры ЦОД, способный объединить под своим управлением как физическое оборудование в ЦОД, так и виртуализированные среды. С его помощью можно осуществлять оркестрацию из «одной точки» входа. Таким образом это средство способное предоставлять услуги как: IaaS и PaaS.
Примеры такого оборудования:

• Сетевые маршрутизаторы и коммутаторы: Cisco Nexus 7000, 5000, 1000v.
• Вычислительные системы: Cisco UCS Fabric Interconnect.
• Различные системы хранения данных, в том числе и NetApp.
• Виртуализация: VMware, Microsoft, Citrix.

Возможности CUIC

Возможность «управления из одного места» далеко не всё, что умеет этот оркестратор.

Поделюсь проблемой и ее внезапным решением, с которыми мы столкнулись на прошлой неделе, и доставившей нам множество неприятностей.
Итак, ситуация достаточно стандартная, центральный офис компании соединен каналами связи с удаленными подразделениями. Связь (Интернет и VPN) дают два оператора. Для того, чтобы минимизировать простои удаленных подразделений при падении одного канала на офисе, на каждое подразделение построены по 2 тоннеля DMVPN. Маршрутизация внутри сети динамическая, eigrp. Соотвественно в центральном офисе используется 2 маршрутизатора Cisco.
Количество удаленных подразделений — около 70, соотвественно каждый маршрутизатор строит такое же количество тоннелей. Средняя нагрузка на канал — 40-60% от полосы пропускания, гарантированной операторами.
Настройка DMVPN использовалась достаточно стандартная, описанная в букваре:

Какие только не приходилось читать статьи про композитную метрику EIGRP. Как очень полезные, так и откровенно глупые. Давайте еще раз разберем, что к чему. Я постараюсь не жевать то, что уже было 10 раз пережевано, а указать на интересные, на мой взгляд, особенности и хитрости подсчета этой самой композитной метрики, в короткой статье. Вспомним кошмарную формулу:

Установка NetScaler VPX Express

Предположим, Вы прочитали про широкий функционал и больше возможности, гибкость и универсальность Citrix NetScaler, но сразу расставаться и пачкой денег не готовы. Предлагаю рессмотреть как быстро и просто протестировать полную копию NetScaler на своей площадке и совершенно бесплатно.

Как?
Подробности внутри.

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

_{EIGRP Lab | EIGRP Lab — Answers}

Продолжим изучение лаб для экзамена ROUTE курса CCNP.

Я думал объединить ответы на задачки прошлой лабы с лабой по OSPF, но этот топик и без того получается настолько большим, что, боюсь, как бы его все дочитали до конца. Здесь будет очень много конфигов, скриншотов из Wireshark и дебрей технологии, но все это только для того, чтобы лучше проиллюстрировать внутреннюю логику EIGRP, без понимания которой этот экзамен сдать невозможно.

Будущие, бывшие и настоящие CCNP, добро пожаловать под кат!

_{EIGRP Lab | EIGRP Lab — Answers}

Привет! Сегодня я хочу поделиться с уважаемым сообществом лабами, которые помогли мне в подготовке к экзамену ROUTE из нового трека CCNP, а также мыслями и впечатлениями от экзамена. В связи с тем, что материала и лаб очень много, придется разбить это все на порции и выкладывать их по очереди. Сегодня предлагаю поговорить о CCNP 6 версии вообще, об экзамене ROUTE и посмотреть на лабы по EIGRP, которые я использовал для подготовки к экзамену.

Заинтересовавшимся – добро пожаловать под кат!

На прошлой неделе компания НР выпустила пресс-релиз, где в спокойной и выдержанной манере, будничным тоном сообщалась весьма значительная новость. На первый взгляд, не произошло ничего особенного: PR-служба компании отрапортовала о том, что HP оснастила шесть своих центров обработки данных собственным сетевым оборудованием. Но на самом деле это значит, что в критически важных узлах ЦОДов, которые обслуживают 300 тысяч сотрудников в 170 странах мира, HP смогла обойтись без оборудования Cisco.

Магистральные коммутаторы Cisco в последние годы служат неформальным эталоном в мире телекоммуникаций. Инфраструктуры целых отраслей «привязаны» к ним, а целые поколения администраторов построили свою карьеру на знании оборудования и протоколов только этого вендора. Изменить эту ситуацию уже давно пытаются Juniper и Extreme Networks. Компания HP в этой технологической гонке, казалось бы, не участвовала. Но сегодня подразделение HP Networking довело свои продукты до той степени развития, когда на них стало возможным возложить самые масштабные задачи.

«После обмена мнениями с заказчиками из разных стран мира мы пришли к выводу, что им нужен поставщик полноценного набора сетевых продуктов с открытой архитектурой, способной создать альтернативу нестандартным протоколам, к которым пользователи были привязаны на протяжении десятилетий», — сказал директор ИТ-службы HP Рэнди Мотт. И HP решила стать здесь примером.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

В сети любого большого content/eyeball провайдера возникает необходимость управления трафиком. И чем больше сеть, тем острее эта необходимость ощущается. В этой статье я попытаюсь описать основной принцип управления трафиком в сети компании, непосредственное отношение к которой я имею. Сразу оговорюсь, что в этой статье упоминается множество торговых марок, терминов и «жаргона». Здесь не будет ни примеров конфигурации роутеров, ни описания этих самых терминов.

Мы привыкли считать, что транспортная MPLS-сеть необходима, в основном, для applications, которых существует множество: L3VPN, L2VPN/VPLS, и т.д. О Traffic Enigineer'инге в сетях MPLS вспоминают или от «хорошей» жизни, или, скорее, теоретически.

Также принято считать, что backup capacity — это роскошь и, как правило, кариеры/транспортники биллят за backup-порт также, как за обычный. Назревает резонный вопрос: зачем покупать капасити, которые будет просто простаивать и, возможно, несколько раз в месяц на короткое время использоваться? Но, с другой стороны, говорить о том, что «backup'ы для трусов» тоже нельзя, backup'ная емкость должна быть. Как же быть? Об этом и пойдет речь в статье.

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

Проблемы бывают разные. Те, которые связаны с багами софта, железа или мозга клиента приходится локализовывать и передавать кому следует. Это не так интересно.

Гораздо интереснее заморочистые задачки.

Как то:
OSPF пиринг поднимается и падет через некоторое время.
Маршруты, полученные Route Reflector'ом по BGP не анонсируются клиентам.
Не работает Inter-AS Option C.

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

Добрый день, уважаемые читатели! К сожалению, на Хабре практически нет упоминаний об этих замечательных устройствах, очевидно ввиду их возраста, но имеются статьи по более молодому оборудованию Cisco ACE. Но, несмотря на некоторую непопулярность, Cisco CSS 11500 Series Content Services Switches всё же встречаются в корпоративных сетях и первое столкновение с неподготовленным администратором может вызвать у него легкое недоумение. Не обращайте внимания на кажущуюся сложность, эти железки удивительно просты в конфигурировании.

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