войти зарегистрироваться

Cisco whois

индекс
133,02

Особенности работы и настройки DHCP на маршрутизаторах Cisco

В статье я хочу рассмотреть использование DHCP-сервера на базе маршрутизатора Cisco в корпоративной сети…

Шаблон базовой настройки маршрутизатора Cisco

В последнее время приходится часто настраивать с нуля маршрутизаторы Cisco (в основном 800-1800 серии) для филиалов моей компании и дабы не набирать одни и теже команды третий десяток раз составил для себя небольшой шаблон настроек на разные случаи жизни. Сразу скажу что сертификаты от Cisco не получал, книжек по данным роутерам особо не читал, весь свой опыт приобрел методом научного тыка, курением мануалов на cisco.com и кое каким вдумчивым заимствованием кусков чужих конфигов…

Новые таможенные правила или как жить дальше? Семинар в cisco

11 марта 2010 в московском офисе cisco состоялся увлекательный семинар Миши Кадера про новые таможенные правила на территории таможенного союза России, Белоруссии и Казахстана. И про то, что cisco делает для того, чтобы ввоз нового оборудования наконец стал снова радовать и продавцов и покупателей.

Статья была опубликована 11.03 здесь, но по просьбе докладчика была направлена на доработку. Миша внес ряд нужнейших ссылок и комментариев, поправив меня в тех моментах, которые были изложены не точно. За что ему огромное спасибо!
Сейчас публикуется поправленный вариант.

Для начала экскурс в историю:
1. Таможенные правила ввоза на территорию РФ впервые были написаны аж в 1995 году и там было и про шифрование и про согласование с ФАПСИ (ныне ФСБ) и МинПромТоргом. Просто их никто не выполнял. Вот ссылка на указ для интересующихся
2. В 2006, для вступления в ВТО, был разработан новый, более гибкий документ, выводящий часть криптографии из-под лицензирования ввоза. Документ так и не был согласован
3. В конце 2009 году, приняв за основу документ 2006г, ФСБ быстренько согласовала новые правила ввоза на территорию единого таможенного союза. Так что с 01.01.2010 года мы просто получили то, что должно было работать давным-давно. Вот опять же ссылка на эти правила

По новым правилам часть шифровательных функций выводится из-под лицензирования (полный список можно найти в нормативных документах):
1.«Слабое» шифрование (симметричное шифрование с длиной ключа меньше либо равным 56 битам, асимметричное – 128 битам)
2.Шифрование каналов для управления (ssh, https для управления)
3.Шифрование беспроводными точками доступа (со встроенными антеннами) трафика, передаваемого на расстояние до 400 м.
4.Если шифрование является неотъемлемой частью программного продукта (операционной системы).

IPTV: вещание мультикаст трафика в VRF и глобальную таблицу

С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.

Небольшое введение


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

Постановка задачи


Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.

По мотивам Cisco Live 2009: Advanced Concepts of DMVPN

Продолжая серию статей о VPN, хочу поделиться подробностями о реализации технологии DMVPN, изложенными на Cisco Live 2009. Осторожно, много букв :)

ASA. Настройка перехватывающей аутентификации через AD и LDAP

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

А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD

На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).

ASA: заморочки трансляции сетевых адресов. Часть 2. Статические трансляции

Статические трансляции

Статические трансляции, в отличие от динамических, жестко связывают адреса (или адреса с портами). Именно эта их особенность позволяет инициировать сессии как изнутри, так и снаружи МСЭ. Но для того, чтобы раз и навсегда не путаться в написании статических трансляций, я научу вас их «читать» правильно. Итак, формат команды довольно прост:

static ({source_int},{dest_int}) {translated_address} {real_addess}

где
source_int – интерфейс на который приходит пакет
dest_int – интерфейс, с которого пакет пойдёт дальше
real_address – реальный адрес хоста
translated_address – странслированный адрес хоста

И читается трансляция так:
Когда пакет бежит с интерфейса source_int на интерфейс dest_int его адрес ИСТОЧНИКА подменяется с real_address на translated_address.
Когда же пакет бежит в обратном направлении, т.е. приходит на интерфейс dest_int и идет далее через интерфейс source_int его адрес НАЗНАЧЕНИЯ меняется с translated_address на real_address

Cisco Group Encrypted Transport Virtual Private Network (GET VPN)

Cisco GET VPN — новая технология от Cisco, призванная обеспечить безопасность туннелей через провайдерские соединения, обладающая рядом полезных особенностей. Ее описанию, особенностям и настройке и посвящена эта статья.

Двусторонний NAT (PAT) на Cisco IOS или NAT NVI

По просьбе коллеги (Fedia) я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.

ASA: заморочки трансляции сетевых адресов. Часть 1. Динамические трансляции

Трансляция сетевых адресов (Network Address Translation, NAT) — это подмена какого-либо адреса или порта в пакете. Она, как правило, требуется на границе между сетью компании и провайдером Интернет. Однако, это далеко не единственная задача. Рассмотрим несколько типичных задач и способы решения при помощи межсетевого экрана ASA.

Для начала определимся с терминами. Как вы уже знаете, на ASA при помощи сравнения уровней безопасности интерфейса-источника и интерфейса-назначения легко определяется направление «наружу» и «внутрь» межсетевого экрана (ситуацию с одинаковыми уровнями безопасности рассмотрим отдельно).
Обычно разделяют внутреннюю (inside) и внешнюю (outside) трансляции. Внутренняя трансляция подменяет адрес источника при выходе «наружу» межсетевого экрана, а внешняя трансляция подменяет адрес источника при проходе «внутрь» МЭ.