Category Archives: Статьи

Мультикаст

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

Итак, протокол IGMP (Internet Group Management Protocol) используется для регистрации узлов на маршрутизаторах, которые передают multicast трафик в сети. Что такое multicast – это когда один и тот же трафик получается одновременно большим количеством пользователей (например, трансляция котиков через IP TV). На самом деле multicast и связанные с ним протоколы часто овеяны мифами. В реальности же все гораздо проще и прозаичнее, и все мифы – это от редкости использования и настройки данных протоколов.


    Cisco Fabric Extender и способы их подключения.

    Добрый день!

    Сегодня хотелось бы поговорить о модульности cisco nexus.
    Как вы знаете или может слышали, cisco nexus серий 5000, 7000, 9000 не просто коммутаторы с фиксированным количеством портов, а коммутаторы, к которым можно подключать модули, так называемые расширения cisco FEX (Cisco Fabric Extender). Модули – это коммутаторы cisco nexus серии 2200, которые подключаются и полностью управляются основными устройствами из серий 5000,7000,9000. То есть располагая extenders в разных стойках и подключая их к основному устройству мы получаем огромный единый логический коммутатор.

    Хотел бы акцентировать ваше внимание на двух важных заметках:
    1) Сами по себе FEX не маршрутизируют и не пересылают пакеты в рамках FEX, все это происходит только через управляющее устройство.
    2) К FEX устройствам не получится подключить, по умолчанию на портах активирован BPDU Guard, который нельзя отключить.

    N5N(config-if)# spanning-tree port type normal
    ERROR: Command not supported on fex port

    Кстати, в новых линейках оборудования для корпоративных сетей cisco catalyst 6800 также есть возможность модульного подключения extender’ов, которые, как мне показалось, обычные коммутаторы 2960 цвета хаки с немного урезанным IOS.

    По умолчанию на всех extenders серии 2200 есть 4 порта 10г для подключения к основным устройствам. Есть два способа подключения nexus 2200:


      Продолжение. Немного об оборудовании ядра.

      Добрый день!

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

      Одними из основных критериев при выборе сетевого оборудования было наличие поддержки от вендора , наличие функций резервирования, отказоустойчивости и community . Не маловажным фактором также был финансовый вопрос. Исходя из своего опыта работы в провайдере доводилось работать с оборудованием разных вендров, только с Juniper не удалось поработать. Изначально рассматривали всех производителей оборудования, запрашивали прайсы у поставщиков, обсуждали с ними всевозможные схемы и преимущества того или иного оборудования. В итоге пообщавшись с коллегами, проанализировав цены, взвесив все плюсы и минусы тех или иных моделей, в качестве L3 коммутаторов было выбрано оборудование Cisco Nexus 5500. По умолчанию серия 5500 относиться к уровню access, нежели redistribution и L3 функции как таковые не поддерживает. Так как площадки у нас не большие, на каждой не более 10 стоек, было решено просто докупить L3 карты для nexus и установить их в качестве так называемого ядра нашей площадки. На момент закупки были уже анонсированы коммутаторы 5600 серии с L3 возможностями по умолчанию, но в продажу на тот момент они не поступили, остановились на Cisco Nexus 5500. Что касается выбора, возможно ключевую роль сыграло не только наличие качественно и быстрой тех поддержки со стороны вендора, по сравнению с другими производителями, но и тот фактор, что линейка nexus производиться довольно давно и уже успела себя хорошо зарекомендовать в дата центрах по всему миру.

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


        Знакомство с IP v6

        В этой  зпметке мы расскажем о том что же интересного есть в IPv6 и так ли уж он страшен и непонятен как иногда кажется.

        Например, один из интернет-провайдеров Беларуси столкнулся с нехваткой IPv4. Точнее с этой проблемой столкнулись абоненты данного провайдера, так как попасть на сайт google.com стало периодически не возможно. Поэтому мы решили в данном письме поговорить про IPv6.

        Ты, безусловно, знаешь такой замечательный протокол, как ARP (Address Resolution Protocol). Нужен он для того, чтобы любой узел в сети мог получить информацию о MAC-адресе узла назначения по его IP-адресу. Фактически, этот протокол лежит в основе работы любой LAN сети, и результат его работы мы видим в  ARP-таблице узла (компьютера, маршрутизатора и т.д.):


          Заметки о двух площадках

          Рад приветствовать вас дорогие читатели нашего проекта network-lab. В сегодняшней и следующих статьях я хотел бы рассмотреть проект, который связан как с дизайном сети, так и настройкой оборудования cisco

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


            RFC-1925 12 сетевых истин

            Сетевая рабочая группа Р. Callon редактор
            Запрос Комментарии: 1925 IOOF
            Категория: Информационный 1 апреля 1996

            Двенадцать сетевых Истин

            Статус этого документа

            Этот документ предоставляет информацию для Интернет-сообщества. В этом документе не определяется стандарт Интернет какого-либо рода. Распространение этого документа не ограничено.

            Предисловие

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

            Благодарности

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

            1. Введение

            Это Запрос на комментарии (RFC) предоставляет информацию о фундаментальных истинах, лежащие в основе всех сетей. Эти истины относятся к сетям в целом и не ограничиваются TCP / IP, Интернет, или любой другой технологией сети.


              Ethernet Virtual Circuits

              Всем привет. В этой статье поговорим еще об одном инструменте виртуальных сетей. Речь пойдет о такой технологии как Ethernet Virtual Circuits (EVC).

              Как вам уже должно быть известно, сети второго уровня очень удобно  делить на  виртуальные подсети — VLAN’ы. Как правило, для этого используется стандарт IEEE 802.1q. Он позволяет организовать до 4096 VLAN’ов в одном широковещательном сегменте. Число немаленькое и даже для больших организаций его обычно достаточно. Но сети бывают всякие разные, и встречаются такие, в которых этого количества уже не хватает. Очевидное решение – разделение такой сети на два и более сегмента, которые объединяются между собой устройствами третьего уровня, маршрутизаторами. Как показано на рисунке.

              evc1

              В такой сети в каждом отдельном сегменте мы можем назначать любые ID VLAN’ов, даже если они повторяются в разных сегментах.


                Полезные фишки VTP v3

                vlan_operation1

                Ты наверняка знаешь про такой замечательный протокол от компании Cisco, как VTP (VLAN Trunking Protocol). Протокол он хороший, да и цель благую преследует: упростить настройку VLAN в коммутируемой части сети  и синхронизировать базу данных VLAN. Но используется, или как мы хотим верить, использовался он крайне редко. Основная его проблема заключается в том, что существовала очень реальная возможность при добавлении нового коммутатора в домен затереть всю базу данных VLAN, если не провести ряд мероприятий. В эти мероприятия включался обязательный перевод нового коммутатора в режим vtp transparent, чтобы понизить revision number до нуля. В случае, если у нового коммутатора VTP revision number был выше, чем у других коммутаторов в сети, то все коммутаторы (включая VTP Server) посылали VTP advertisement request новому коммутатору, в котором запрашивали его базу данных VLAN, получали ее и затирали свою начальную (потому что свой revision number меньше). Сколько мы знаем таких историй, когда добавление новых коммутаторов заканчивалось даунтаймами. А если бы люди про это знали, например послушав наши курсы CCNA или Technology School , то таких проблем бы не было J
                Но пост про другое. Описанная нами ситуация применима к протоколу VTP версии 1 и 2.


                  Нюансы EIGRP

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

                   

                  Нюанс 1

                  Например, тебе хорошо знаком этот протокол, если ты учился хотя бы на CCNA Routing and Switching. До недавнего времени этот протокол был закрытым, что называется, Cisco proprietary. А недавно Cisco открыла его большую часть в виде informational RFC. Любой человек может теперь познакомиться с его внутренним устройством. Именно этому протоколу будет посвещено это письмо.

                  Самым главной задачей любого протокола маршрутизации является построения маршрутов до сетей назначения. Причем эти маршруты должны быть кратчайшими и не содержащими петель. Внутри каждого протокола для этого используются свои алгоритмы и показатели для расчета (то есть метрика). Например у протокола динамической маршрутизации RIP в качестве метрики используется значение «хопов» до сети назначения. То есть количество маршрутизаторов, которые необходимо пакету преодолеть. чтобы попасть куда надо. EIGRP — гораздо более умный протокол, поэтому и метрика здесь гораздо более умная. Давай разберем ее.


                    Внедрение AAA для доступа и учёта

                    Сегодня поговорим о настройке «правильного» доступа на наши железки.

                    Задача была следующей:

                    Есть две группы, одни с полным доступом, вторые с очень ограниченным (доступ не на все железки и не ко всем командам) надо сделать возможность заходить по доменным учеткам. Железки роутеры Cisco 881 и свичи Catalyst 2960, сервер контроля доступа Cisco ACS 5.4, протокол TACACS+ (Radius не поддерживает в полной мере все приятные фишки, хоть и попроще).

                    В начале немного теории о том, что такое AAA и с чем его едят:


                      Hide me
                      Получать регулярно свежие материалы, лабораторные и вебинары
                      Email Имя
                      Show me