Cisco *

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

Этой статьёй я хочу начать цикл, посвященный IPv6. Я являюсь инструктором академии Cisco, поэтому, если вы в совершенстве знаете материал нового CCNA Routing & Switching, то скорее всего, не найдёте в цикле ничего нового. Речь пойдёт о структуре и особенностях протокола IPv6, а также, применении его на маршрутизаторах Cisco (маршрутизация RIP, OSPF, EIGRP, списки контроля доступа, и др. – как пойдёт). В первой статье мы поговорим о структуре IPv6 пакета, записи адресов, префиксе. Вторая статья цикла доступна здесь. Информация подойдёт для новичков, имеющих, тем не менее, некоторые знания по IPv4 и модели OSI.
Цикл статей основан на материалах моего блога, которые, в свою очередь, основаны на опыте преподавания, работы с оборудованием и вольном переводе и обдумывании официального курса CCNA Routing & Switching.
Итак, начнём. Не буду останавливаться на стандартных рассуждениях о том, что IPv4 адресов мало, о том, что NAT и прокси – это костыли, о том, что костыли пока работают, и никто не хочет переходить на IPv6, вместо этого – сразу к сути.

Идея сделать умный дом приходила мне ещё тогда, когда я учился в школе. Так получилось, что в отличии от сверстников, которые гоняли мяч во дворе или играли в компьютерные игры я, сэкономив деньги, которые мне давали родители на школьный обед радостный ехал на Василеостровскую.


Демонстрация работы «Умного дома».

Как показал томный взгляд, построение сети для видеосвязи задача нетривиальная: тут и решения разные, и уровни взаимодействия, и интернет везде разный, и опасных мест выше крыши. Самое странное – нет русскоязычных гайдов по планированию, дизайну и более тонкой настройке. Есть серединка, т.н. «базовая настройка», которой искушенный сетевой администратор доволен не будет. В зависимости от ситуации и требований могут появиться абсолютно неожиданные решения. Даже для одной организации с набором требований найти подходящее решение сходу будет проблематично, а чтобы быть универсальным и охватить полный спектр услуг, предоставляемых оборудованием Cisco TelePresence, нужен будет не один агрегат. Если купить все цисковские железки и все друг в друга воткнуть – может это и получится «Универсально».

Под катом много текста.

Приветствую, хабр!

В силу профессиональных интересов, я довольно часто натыкаюсь на статьи о том, как готовиться и сдавать те или иные сертификационные экзамены небезызвестного вендора Cisco. Но вот беда! Не все направления сертификации одинаково популярны. Про всеми любимый Routing and Switching (R&S) пишут всегда и везде, чуть реже обсуждают Voice и Security, а некоторые треки и вовсе остаются без внимания. На днях я закончил сдавать трек CCNP Service Provider. Достижение небольшое, то ли дело коллеги, сдающие CCIE. Цель, как ни крути, благородная, даже если работаешь с разными вендорами.
Уровень «Professional» можно достичь гораздо быстрее, о нём и поговорим.

Начну пожалуй с краткого введения в Cisco CCIE экзамен.
История CCIE началась в 1993 году. Изначально экзамен состоял из двухдневной лабораторной работы, позднее его сократили до одного дня. Согласно Википедии меньше 3% Cisco специалистов удается стать счастливым обладателем CCIE сертификата.

Сам экзамен состоит из двух частей: письменной и лабораторной. На лабу дается 8 часов.
Существует несколько треков: «Маршрутизация и коммутация» (Routing and Switching); «Безопасность» (Security); «Провайдер услуг» (Service Provider); «Передача голоса» (Voice) и т.д.

Статей по внедрению аутентификации компьютеров на различных RADIUS серверах написано много и на разных языках, в том числе и сценарии, когда компьютер подключен к сети через встроенный коммутатор в телефоне, однако в этих статьях упоминаются умные IP телефоны, поддерживающих CDP или LLDP и умеющие работать с Voice Vlan.
К сожалению, мне пришлось работать с тем, что есть, а именно IP телефон Panasonic KX-NT321, работающий по проприетарному протоколу, не умеет ни LLDP, ни тем более CDP и даже загрузки конфигурации по TFTP. Но можно с самого телефона настроить тегирование на каждом из порту коммутатора.

Данная статья посвящена созданию собственного виртуального стенда для подготовки к лабораторной работе CCIE RS.

Как известно подготовка к экзамену CCIE является своеобразным подвигом в сетевом мире. Для успешной сдачи кандидат должен вложить уйму ресурсов: времени и денег. Помимо оплаты за сам экзамен необходимо, оплатить учебные материалы, оплатить поездку и.т.д. Одной из статей затрат является организация учебного стенда для подготовки. Рассматривая популярную топологию INE из одноименного воркбука, видно, что понадобится 9 роутеров и 4 свитча. Перечислю классические способы реализации в порядке убывания стоимости:

1. Покупка полного стенда домой из старого железа на ebay.
2. Аренда стойки.
3. Смесь виртуальных роутеров из GNS3 и реальных коммутаторов.
4. IOU.

Про плюсы и минусы каждого из методов уже писали на хабре. Остановимся на самом дешевом (что выгодно, если ваш работодатель не оплачивает вам обучение).
Прежде чем поставить задачу и начать её выполнение стоит упомянуть, что использование IOU не законно, если ты не сотрудник Cisco. Даже для обучения.

Задача статьи: организовать учебный стенд используя топологию INE и веб интерфейс для IOU.

Позвольте поделиться небольшим опытом в контексте SAN.

Дано:

В одной неизвестной организации есть серверная, в которой была внедрена и успешно функционирует SAN сеть. В сети две фабрики, в каждой фабрике было по коммутатору HP AM869A 8/40. Как оказалось, эти коммутаторы представляют собой сорока портовые SAN коммутаторы Brocade 5100, под управлением Fabric OS. К этим фабрикам подключено несколько десятков серверов и пару Систем хранения данных. Без подробностей выглядит всё это следующим образом… страшненько:

В учебных материалах к CCNP Route утверждается, что если существует несколько внешних маршрутов OSPF одного типа, будет выбран маршрут с лучшей метрикой, в случае же совпадения метрик, выбирается маршрут, объявленный ближайшим ASBR. При этом складывается впечатление, что трафик во внешние сети всегда должен проходить через ASBR. На практике данное описание является неполным и опускается один аспект, который может привести к субоптимальному роутингу.

Я думаю, про tacacs+ его настройку, политики, ACL и прочее сказано, а уж тем более написано более чем достаточно. Но, что меня всегда напрягало в tacas+ — постоянно чего-то не хватает. Некая недоработанность что ли…

Введение, или зачем нужна еще одна статья о WCCP?

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



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

Но всегда ли внедрение WCCP проходит гладко? И если нет, как бороться с возникающими проблемами?

Например, практически во всех статьях упоминается, что сервер кэширования должен находиться в том же сегменте, что и пользователи, но причины этого не уточняются. А как быть, если политика безопасности требует, чтобы все серверы находились в демилитаризованной зоне и были защищены межсетевым экраном (МЭ)?

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

Если читателям интересно, какие проблемы встречаются при реализации подобных схем, и как можно обойти ограничения — добро пожаловать.

Пролог

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

Итак, постоновка задачи:

Необходимо организовать сеть, максимально удобную для конечного пользователя, при этом также удобную (с точки зрения минимальной нагрузки на техподдержку) и безопасную (с точки зрения мошенничества) для оператора. К тому же сеть должна быть недорогой. Кто-то возразит, что Cisco и «недорого» — несовместимые понятия, однако для решения нашей задачи годятся и End of Life старички, которые можно приобрести по очень демократичным ценам.

Для обеспечения удобства пользователя были отброшены следующие варианты:

• статическое назначение ip-адресов — неудобно для пользователя, адрес нужно где-то записывать, потерявшие адрес пользователи названивают в техподдержку
• dhcp с привязкой по mac-адресу — неудобно для пользователя, при смене устройства нужно перерегистрировать его у провайдера или менять на нем mac.
• всевозможные виды туннелей, в основном pptp — требует настройки у клиента, забытые логины и пароли

Из всех рассмотренных вариантов для пользователя наиболее удобен вариант с DHCP, но для провайдера есть ряд сложностей:
Привязка по mac неудобна, так как придется перерегистрировать новые mac-адреса. Аутентификация пользователя в биллинге только по ip-адресу тоже на первый взгляд кажется ненадежной, хитрый пользователь может поставить себе вручную ip-адрес соседа и внести смуту. Однако решение есть и строится оно на технологиях из заголовка статьи — option 82 и dynamic arp inspection

Кому интересно решение — прошу под кат

В работе ( инженера | системного администратора | просто хорошего парня) иногда начинает казаться что время тратится неэффективно, задачи которые решаются, решаются неоптимальным образом, вот тогда может понадобиться Расписко

В прошлом посте я писал о WiFi донгле Airconsole, которые позволяет через WiFi подключаться к консольному порту сетевого оборудования (cisco, juniper, HP и т.д.). Используя приложение Get-console for iOS вы можете администрировать оборудование с iPad и iPhone, а используя донгл Airconsole — выполнять настройку и другие операции с OC семейства Windows, Apple OS X, Linux.

В данном обзоре я подробнее остановлюсь на приложении Get-console и одной очень важной функции приложения — Давать доступ к консоли открытого на iPad подключения другому человеку средствами Get-console Private Server.

Достаточно давно я пользуюсь iOS приложением для администрирования сетевого оборудования Get-console производства новозеландской CloudStore. Данное приложение, субъективно, лучшее для такого рода деятельности, имея в распоряжении iPad или iPhone (последнее спорно из-за размера экрана). Прикупил себе и кабель для подключения планшета к консольному порту.

Так продолжалось какое-то время, пока не пришла пора обновить Пад. Выбор пал на iPad 4, и, о горе, встал острый вопрос — а что же делать с Lightning портом, ведь консольный кабель имеет только 30-пиновый разъем. Выход на время был найден — переходник с 30-pin на Lightning.
Так я пользовался до июля сего года.

Компания разработчик и производитель кабелей разродились версией Lightning своего консольного провода, также представило устройство под названием — Airconsole.

Airconsole — это WiFi-донгл для подключения по WiFi к консольному порту сетевого оборудования (Cisco, Juniper, HP и т.д.).

Предисловие

Про IronPort c170 я написал на хабре год назад. И это была моя первая статья, которая подарила мне инвайт. К сожалению, с того времени, на хабре не появилось ни одной (!) статьи про эту железку, что, я считаю, непозволительно для такого ресурса, как хабр.
Для начала, я, конечно, напомню про свою первую статью: habrahabr.ru/post/148317
Она обзорная и не делающая никаких выводов. Но за год я немного разобрался с железкой, научился некоторым хитростям и встретился с ошибкой прошивки… и вообще теперь я готов рассказать про нее нечто больше, чем ничего :)

Для начала я бы хотел опять показать, какое количество спама в мире ходит.

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

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

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

Всем доброго времени суток! Разбираясь с NetFlow, таким простым, удобным и часто используемым протоколом, я осознал, что он не такой уж и простой, и подводных камней при его эксплуатации хватает.
Под катом я собрал все, что для начала необходимо знать о NetFlow и его настройках на Cisco, отдал дань eucariot, пишущему отличные статьи о сетях, и… Картинки, немного веселых картинок.