Category Archives: Виртуальные сети

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.


      Про виртуальные сети (часть 21). Ограничиваем таблицу маршрутизации VRF (часть 2)

      Итак, продолжаем разговор. В предыдущей статье мы разобрались, зачем нужно ограничивать таблицу маршрутизации и рассмотрели один из вариантов, как это сделать. Узнали, что можно ограничить таблицу маршрутизации командой maximum routes, но повлиять на использование ресурсов маршрутизатора процессом маршрутизации (OSPF в нашем случае) не можем.

      В этой статье рассмотрим другой способ ограничения маршрутов с использованием возможностей протокола BGP. (Вообще этот протокол много чего умеет, и в процессе его изучения создается ощущение, что он разве что картошку почистить не сможет.)


        Про виртуальные сети (часть 20). Ограничиваем таблицу маршрутизации VRF (часть 1)

        Всем привет. Сегодня мы рассмотрим один из моментов, связанный с безопасностью виртуальных сетей, а именно как ограничить ресурсы маршрутизатора, предоставляемые клиенту. Ведь маршрутизатор один и его ресурсы не безграничны. А клиенту может понадобиться очень большая таблица маршрутизации. А может и попасться очень зловредный клиент (или просто неграмотный) и его сеть будет просто очень страшно флудить обновлениями маршрутов, фактически осуществляя DoS атаку.  Что же делать?


          Про виртуальные сети (часть 19). L2VPN + VRF

          Всем привет. Сегодня мы будем рассматривать такого зверя, как L2VPN. Что он из себя представляет? С точки зрения клиента – это просто Ethernet канал между двумя его маршрутизаторами, один широковещательный домен. А вот с точки зрения провайдера, все намного сложнее. Нужно поймать кадр Ethernet (ну или что там используется на канальном уровне), запаковать, передать через всю сеть, снова распаковать и отдать клиенту. Вот настройкой этой цепочки мы и займемся. Заодно проверим, что можно сделать, если взаимодействие провайдера с клиентом уже осуществляется и организовано с помощью VRF.


            Про виртуальные сети (часть 18). DMVPN на виртуальных маршрутизаторах

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

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

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


              Про виртуальные сети (часть 17).BGP в виртуальных сетях

              Сегодня мы обсудим Border Gateway Protocol (BGP). Как понятно из названия это протокол граничных (или пограничных, кому как нравится) маршрутизаторов, т.е. маршрутизаторов которые стоят на границах сетей и обеспечивают общение этих самых сетей между собой. Является основным протоколом маршрутизации в интернете. Ну и как следствие, является достаточно сложным в настройке, но зато и предоставляет много возможностей.

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

              Поехали.


                Про виртуальные сети (часть 16).Как привязать QoS к виртуальной сети

                В предыдущих статьях здесь и здесь я рассматривал работу различных сервисов через виртуальные сети. Было рассмотрена работа PBR  и IP SLA в этих сетях. Еще одним интересным аспектом работы, отличающим виртуальные сети от реальных является то, что нескольким виртуальным сетям приходится сосуществовать в одной реальной сети одновременно. С одной стороны мы экономим на оборудовании, с другой — всем приходится ютиться под одной крышей. И вот тут встает вопрос: кому сколько места положено, или, если выражаться уже технически, как распределить ресурсы каналов между имеющимися виртуальными сетями. Конечно, перефразируя известное стихотворение, все протоколы нужны, все данные важны. Но что-то нужно срочно, а что-то подождет. Обсуждение, что более важно или срочно, выходит за рамки данной статьи, а вот на том, как распределить пропускную способность сети, остановимся поподробнее.


                  Про виртуальные сети (часть 15). IP SLA в виртуальных сетях.

                  Если заглянуть на сайт cisco.com, то там можно найти документ, в котором есть следующее описание (прошу меня извинить за мой перевод, сделанный по японской технологии касавато):

                  IP SLA собирает информацию о производительности сети в реальном времени: время ответа, задержки, потери пакетов, измерение качества передачи голоса и пр. Пользователь имеет возможность надежно и предсказуемо производить измерения сетевой производительности продолжительное время, а также активно контролировать доступность сети. Cisco IOS IP SLA позволяет автоматизировать наблюдение за сетью, обеспечить гарантированный уровень обслуживания, активно контролировать сетевые операции и точно измерять сетевую производительность. Система активного мониторинга продолжительное время измеряет производительность сети по многочисленным маршрутам, непрерывно обеспечивая основную информацию о производительности.
                  Сетевой администратор может также использовать Cisco IOS IP SLA как инструмент для поиска неисправности. Он может получать статистику производительности от узла к узлу, между двумя маршрутизаторами Cisco или между маршрутизатором и сервером. Если сетевая производительности резко падает в процессе работы (перегрузка сети), сетевой администратор может точно определить узкое место и решить проблему. Cisco IOS IP SLA может также оценить уровень качества обслуживания для вновь внедряемого сервиса. Например, Cisco IOS IP SLA может определить, способна ли сеть обеспечить передачу голоса, смоделировав нагрузку и произведя измерение сетевой производительности для VoIP.


                    Про виртуальные сети (часть14). Cisco Policy-based routing (PBR) в виртуальной сети

                    Если заглянуть на официальный сайт Cisco, то можно найти отельный документ, в котором описывается технология маршрутизации на основе политик. И хотя конкретного определения там нет, можно выделить две основные возможности PBR, а именно:

                    - маршрутизация пакетов на основе источника (реализуется на базе списков доступа)

                    - маршрутизация пакетов на основе их размера.

                    Оба варианта позволяют выделить трафик конкретного приложения и направить по конкретному маршруту, а это в свою очередь позволяет реализовать такие вещи, как распределение нагрузки, качество обслуживания, а также (у Cisco вообще без этого никуда) экономия ресурсов (Cost Saving).


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