Cisco *

В этой статье я хотел бы поделиться опытом использования Vendor-Specific Attributes (далее VSA) в Cisco Secure ACS 5.5 (далее просто ACS) на примере настройки RADIUS-авторизации на APC Smart-UPS и Supermicro IPMI. ACS в свою очередь будет авторизовать пользователей в LDAP. В конце статьи в качестве бонуса покажу как снимать дамп пакетов на ACS для траблшутинга с помощью Wireshark.
Предупреждение: для простоты понимания излагаемого материала статья содержит множество скриншотов.

Как и любой современный человек, я периодически задаю себе вопросы об уровне своего развития. Причем развития во всех его проявлениях. Уже изъезженно невероятное количество тем в этой области, но все же хотелось бы внести свои пять копеек.

Есть ли проблема?

После всех известных по умолчанию методов, о которых пишут и многие используют (например, «Как постоянно совершенствовать свои навыки»), встал вопрос о более активных методах обучения, и в тоже время более консервативных. Предложений на рынке IT-образования хоть отбавляй, да, и к сожалению, на «рынке». По отзывам в сети правильный вывод о качестве сделать нереально, особенно для меня, работающей в области максимально близкой IT, но с образованием отличным от необходимого. Поэтому не мудурствуя лукаво, были опробованы одни из самых доступных доступных: книги, во всех их проявлениях и со множеством плюшек-в виде подарочных дисков, как бы это смешо не звучало сейчас; записи курсов, вебинары, форумы, походы на обычные занятия в центры обучения.

В треке Service Provider у Cisco появилась новое направление — Service Provider Mobility. Предлагаются два направления — CDMA to LTE и UMTS to LTE. Для сдачи эказмена нет никаких требований, кроме как знаний самих технологий. В разделе литературы для данных экзаменов можно найти лишь PDF документ с описание курса для данной направленности. В разделе ресурсов Cisco даёт ссылки на сайт 3GPP, мануалы по настройке ASR5x00 и несколько книг разных авторов на тему мобильных сетей. Т.е. на данный момент отсутствуют специализированные книги от Cisco для подготовки к эказмену, как например для трека CCNA/CCNP/CCIE, и неизвестно, будут ли такие вообще.

Всем привет!

Совсем недавно вышла публичная бета популярного симулятора сетевого оборудования GNS3 1.0. Интересен он в первую очередь тем, что стал поддерживать switching (раньше поддерживал лишь routing) с помощью Cisco IOU. Так как я пользуюсь им, начиная с альфа-версии, то решил написать небольшой гайд, как подружить GNS3 и IOU.

Дисклеймер. Cisco IOU могут использовать только сотрудники компании Cisco.

Ниже представлена инструкция и для Windows, и для Linux.

В середине июля стало известно, что американских производителей телекоммуникационного оборудования Cisco Systems и Juniper Networks появились сложности с поставками в российские силовые структуры из-за санкций США. Так, Juniper остановила поставки оборудования в силовые структуры, например МВД и Минобороны. И если от Juniper ничего пока не слышно, то Cisco собирается локализовать производство в России.

Всем привет!
Не так давно Cisco обновили трек CCNA, CCIE R&S, а также CCNP Security. Поэтому можно было ожидать, что вскоре изменят и CCNP R&S.
И вот, 28 июля переработали экзамены для этой сертификации.
Теперь необходимыми экзаменами для получения статуса CCNP R&S являются:

• 300-101 ROUTE (на замену 642-902)
• 300-115 SWITCH (на замену 642-813)
• 300-135 TSHOOT (на замену 642-832)

Данные экзамены можно сдать, начиная с 29.07.2014, а последний день сдачи старых экзаменов — 29.01.2015.
Так что всем, кто сейчас на пути к CCNP, стоит поспешить!

Статья получилась довольно объёмная, рассмотренные темы — форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

Форматы Ehternet фреймов.

1) Ethernet II

Рис. 1

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).


Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Эти два протокола долго жили в разных нишах применения, но наступило время, когда они стали конкурировать друг с другом. Мы однозначно видим, что Ethernet набирает скорость в прямом смысле слова и начинает лезть туда, где FC всегда считался единственным игроком на поле. Появились альтернативы FC, работающие на Ethernet, как в блочном доступе: IP-SAN, FCoE так и других типах, это файловый (SMB, NFS), RDMA и объектный.
Эта статья не призвана к сравнению протоколов, а скорее как краткое хронологическое описание эволюции сетей ЦОД.


* по некоторым событиям нет точных дат. Корректировки и дополнения по датам прошу присылать с удостоверяющими их ссылками. Таймлайн.

Привет! В этой статье я расскажу про интересные особенности протокола маршрутизации EIGRP.
Основы EIGRP отлично описаны в одной из статей цикла СДСМ: 6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация.
В первой половине статьи кратко описаны некоторые факты об этом протоколе, а во второй — несколько интересных примеров с топологией и командами.

Факты про EIGRP

• В феврале 2013 года Cisco решила открыть EIGRP. Стоит отметить, что был открыт не исходный код, а лишь информация, необходимая для реализации протокола. В итоге появился драфт RFC. Последнее обновление 10.04.2014. В этом документе не была раскрыта ключевая особенность — Stub, без которой пользоваться протоколом практически бесполезно. Интересна реакция других вендоров: на сегодняшний день никто, кроме Cisco, не внедрил поддержку этого протокола в своём оборудовании.
• EIGRP для расчёта метрики использует 5 K-values, которые являются лишь модификаторами (коэффициентами), и 4 значения метрики. Надёжность (reliability) и загрузка линка (load) являются динамическими параметрами, поэтому эти значения пересчитываются только при изменении в сети. K5 — это дополнительный коэффициент надёжности, и никакого отношения к MTU он не имеет! Напомню общую формулу расчёта метрики:
  
  
  
  А если K5 = 0, то формула имеет такой вид:
  
  
  
  
  
  
  
  где min_bandwidth — это пропускная способность наихудшего линка в kbps,
  а total_delay — это сумма задержек всех линков в мкс (микросекундах).
  
  Для изменения метрики обычно меняют delay, так как bandwidth влияет на QoS, кроме этого, изменение bandwidth не всегда меняет метрику (если наихудший линк не изменился).
  Минимальное значение MTU действительно подсчитывается, но не принимает никакой роли в определении лучшего пути. В своей топологии в GNS3 я тестировал несколько десятков раз с помощью команд redistribute connected metric и maximum-paths 1. Несмотря на различное значение MTU, лучший путь выбирается тот, который был изучен ранее. Также интересно, что в драфте RFC упоминается дополнительный коэффициент K6 и 2 дополнительных значения метрики: джиттер (jitter) и энергия (energy).
• Feasibility Condition не всегда легко понять в первый раз. Но логика очень простая: если ты говоришь мне, что у тебя метрика больше, чем метрика моего лучшего пути, значит есть шанс, что твой путь проходит через меня, что в свою очередь означает петлю. Из-за этого часто очевидные для инженера «пути-без-петли» могут не рассматриваются протоколом как feasible successors. Помните, EIGRP не видит всей сети — а лишь то, что говорят соседи.
• EIGRP — Distance Vector протокол, никакой гибридности в нём нет.
• С помощью show ip eigrp neighbors detail можно посмотреть, является ли сосед тупиковым (stub) роутером.
• Помните, с помощью команды show ip eigrp topology видны лишь successors и feasible successors. Чтобы посмотреть все возможные пути, необходимо добавить ключевое слово «all-links»: show ip eigrp topology all-links.
• В IOS 15 наконец-то отключена по умолчанию автоматическая суммаризация, ура! Прощай команда no auto-summary!
• Значения таймеров (hello и hold) могут быть неодинаковыми. Кстати, значение таймера hold передаётся соседу и означает: «если в течение X секунд ты от меня не получишь hello, значит я больше недоступен».
• EIGRP использует свой транспортный протокол (IP protocol number: 88) — RTP (Reliable Transport Protocol). Не стоит путать его с другим известным протоколом Real-time Transport Protocol (тоже RTP), который используется для передачи потоков реального времени, например VoIP (в связке с SIP). EIGRP также использует мультикаст адрес: 224.0.0.10. Не забывайте во входящем ACL разрешать EIGRP трафик, например с помощью записи: permit eigrp any any.
• Из-за различных значений административной дистанции (AD) для внутренних (90) и внешних (170) маршрутов, EIGRP позволяет избежать некоторых проблем при редистрибьюции (redistribution).
• Помните, что 2 роутера могут быть соседями, и при этом у них может не быть adjacency. С помощью команды show ip eigrp neighbors показываются лишь соседи. В выводе этой команды стоит обратить внимание на поле Q Cnt: если там не ноль, то вполне возможно, что у вас есть проблема в сети (например, неустановленное adjacency).
• EIGRP кроме суммарного маршрута может отправить и конкретный специфический маршрут. Эта особенность называется EIGRP Leak Map. Это полезно, если мы хотим сделать traffic engineering. Идея очень похожая на bgp unsuppress-map. Для этого необходимо применить команду: ip summary-address eigrp as-number summary-address summary-mask leak-map leak-map-route-map.
• Как верно добавил alk0v, в отличие от OSPF, EIGRP поддерживает балансировку нагрузки при разной метрике (unequal cost load balancing). Для этого необходимо использовать команду variance. Стоит помнить две вещи: это работает только для successors/feasible successors и, по умолчанию, CEF выполняет балансировку per-destination. Последнее значит, что 2 пакета, у которых соответствующие IP адреса отправителя и получателя одинаковые, всегда будут выходить из одного и того же интерфейса, что заметно усложняет проверку. Если вы всё же хотите это проверить, то можно переключить CEF в режим per-packet (в режиме конфигурации интерфейса используйте команду ip load-sharing per-packet) или вообще его отключить (команда no ip cef в глобальном конфигурационном режиме, не рекомендуется).

Ну что, пора заняться практикой?

Публикую продолжение вот этой статьи.

Статические маршруты

Таблица маршрутизации протокола IPv6 по умолчанию содержит не только непосредственно подключённые сетки, но также и локальные адреса. Кроме того, в ней присутствует маршрут на групповые адреса.

R1#show ipv6 routing
IPv6 Routing Table - Default - 3 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       HA - Home Agent, MR - Mobile Router, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external
C   2001:DB8::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:DB8::1/128 [0/0]
     via GigabitEthernet0/0, receive
L   FF00::/8 [0/0]
     via Null0, receive

Привычным способом задаются статические маршруты в IPv6. Единственное, что хотелось бы отметить, что при использовании link-local адресов кроме самого адреса следующего перехода необходимо указать и интерфейс.

Введение

Протокол IPv6 является наследником повсеместно используемого сегодня протокола IP четвёртой версии, IPv4, и естественно, наследует большую часть логики работы этого протокола. Так, например, заголовки пакетов в IPv4 и IPv6 очень похожи, используется та же логика пересылки пакетов – маршрутизация на основе адреса получателя, контроль времени нахождения пакета в сети с помощью TTL и так далее. Однако, есть и существенные отличия: кроме изменения длины самого IP-адреса произошёл отказ от использования широковещания в любой форме, включая направленное (Broadcast, Directed broadcast). Вместо него теперь используются групповые рассылки (multicast). Также исчез ARP-протокол, функции которого возложены на ICMP, что заставит отделы информационной безопасности внимательнее относиться к данному протоколу, так как простое его запрещение уже стало невозможным. Мы не станем описывать все изменения, произошедшие с протоколом, так как читатель сможет с лёгкостью найти их на большинстве IT-ресурсов. Вместо этого покажем практические примеры настройки устройств на базе Cisco IOS для работы с IPv6.
Многие начинающие сетевые специалисты задаются вопросом: «Нужно ли сейчас начинать изучать IPv6?» На наш взгляд, сегодня уже нельзя подходить к IPv6 как к отдельной главе или технологии, вместо этого все изучаемые техники и методики следует отрабатывать сразу на обоих версиях протокола IP. Так, например, при изучении работы протокола динамической маршрутизации EIGRP стоит проводить настройку тестовых сетей в лаборатории как для IPv4, так и для IPv6 одновременно. Перейдём от слов к делу!

Введение

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

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

Первое, с чего пришлось начать, это с изучения данной статьи — http://habrahabr.ru/post/127613/ (автору gag_fenix большущий респект). Это единственная нормальная и полная статья о том, как можно получить и учитывать трафик на сетевом оборудование Cisco ASA с использованием nfdump. В этой статье отлично описана только реализация о том, как можно настроить оборудование на передачу пакетов NetFlow на хост, а также каким образом можно использовать полученные данные для последующего анализа. Сам же анализ трафика и его учет не рассматривается в статье.

Перед тем, как читать дальше, настоятельно рекомендую хорошо изучить вышеуказанную статью, так как некоторые особенности настройки будут опускаться. В статье рассмотрим такие вопросы о том, как вести учет по NetFlow (используя MySQL на коллекторе), как посчитать VPN трафик, какой тип пакетов учитывать, как избежать «удвоения» и «дублирования» трафика, и как использовать мое приложение.

Буквально только что была аннонсирована новая серия коммутаторов от одного из крупнейших вендоров — Cisco Systems.

В дополнение к линейкам Nexus и Catalyst будет выпущена новая линейка Cisco Fatalyst, и, соответственно, пересмотрен подход к построению локальных сетей. На смену концепции Borderless Networks приходит новая концепция Hopeless Networks, основная опора в ней — именно на L2, L3 и lvl80 свитчи Fatalyst.

В сети присутствует множество различных гайдов на эту тему, но поднять сервис на Linux и связать его с Active Directory в течении 30-60 минут не удалось. Предлагаю свой путь решения задачи, с подробными комментариями.

Приступим к установке сервиса. В качестве ОСи используется CentOS.

Подтвердилось существование проблемы, о которой многие догадывались.

Cisco объявили, что неназванный производитель памяти в течение пяти лет (с 2005 по 2010) поставлял им брак. Характер брака: оборудование с этой памятью может годами копить аптайм, не вызывая никаких нареканий к своей работе, но стоит перезагрузить его (по питанию или даже простым reload) — память перестает корректно работать, само устройство либо не загружается, либо загружается и периодически падает. Связано это с деградацией чипов памяти. По заявлению вендора, основные проблемы начинаются после двух лет эксплуатации.

Прежде чем в Cisco полетят тухлые помидоры, спешу предупредить: память стандартная, многие вендоры ее закупали, потому затронуто может быть великое множество единиц оборудования. Есть подтверждение об аналогичных проблемах у Juniper. Но только Cisco сознались, несмотря на неизбежный репутационный ущерб. Их финансовые потери из-за этой катастрофы составляют около 655 миллионов долларов.

1. Введение в списки префиксов

Для управления обменом маршрутной информацией, ее приемом, отправкой или перераспределением, в Cisco IOS можно использовать различные методы фильтрации маршрутных обновлений, такие как списки распределения (distribute-list) и списки префиксов (prefix-list).
Использование списков распределения обладает определенными недостатками, такими как:

• ACL (Access-List, списки управления доступом), используемые в спискахраспределения, изначально разрабатывались для фильтрации пакетов, а не для фильтрации маршрутов
• Невозможность определения совпадения маски маршрута при использовании стандартных ACL
• Использование расширенных ACL может оказаться громоздким для конфигурирования
• Работа ACL достаточно медленна, так как они последовательно применяется к каждой записи в маршрутном обновлении

Списки префиксов разрабатывались как альтернатива использованию ACL, их можно использовать во множестве команд предназначенных для фильтрации маршрутов.

Google и Cisco сформировали новое соглашение для защиты от потенциальных патентных троллей.

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

По словам The Wall Street Journal, некоторые владельцы запатентованных продуктов стараются избегать судебных баталий путём подписания соглашения с патентно-претендующими фирмами.

Такие действия обоснованы тем, что фирма может получить выручку с патента, а затем поделиться ею с патентообладателями. В маловероятном случае продажи этих патентов троллям, их все равно нельзя будет применить ни против Google, ни против Cisco.

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

1. Введение в ODR – On-Demand Routing

Прежде чем изучать технологию ODR, давайте вспомним два основных метода наполнения таблиц маршрутизации информацией:

• Статическая маршрутизация – маршруты добавляются вручную администратором.
• Динамическая маршрутизация – администратор настраивает протоколы динамической маршрутизации.

Но в каждом из этих случаев есть недостатки:

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

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

• Объем передаваемых данных минимален, по сравнению с протоколами протоколов динамической маршрутизации.
• Требуется минимальная конфигурация на одном маршрутизаторе.