По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Это первая статья цикла. Продолжение: 2 часть Плоскость данных Начнем с того, что основная задача сети-перенос данных с одного подключенного хоста на другой. Это может показаться простым на первый взгляд, но на самом деле это чревато проблемами. Здесь может быть полезна иллюстрация; рисунок № 1 используется для иллюстрации сложности проблемы. Начиная с верхнего левого угла иллюстрации: Приложение генерирует некоторые данные. Эти данные должны быть отформатированы таким образом, чтобы принимающее приложение могло понять, что было передано, - данные должны быть упорядочены. Механизм, используемый для упорядочения данных, должен быть эффективным во многих отношениях, включая быстрое и простое кодирование, быстрое и простое декодирование, достаточно гибкий, чтобы можно было вносить изменения в кодирование, не нарушая слишком много вещей, и добавлять наименьшее количество накладных расходов, возможных во время передача данных. Сетевое программное обеспечение должно инкапсулировать данные и подготовить их к фактической передаче. Каким-то образом сетевое программное обеспечение должно знать адрес хоста назначения. Сеть, которая соединяет источник и пункт назначения, является общим ресурсом, и, следовательно, должна быть доступна некоторая форма мультиплексирования, чтобы источник мог направлять информацию в правильный пункт назначения. Как правило, это будет связано с определенной формой адресации. Данные должны быть перемещены из памяти в источнике и непосредственно в сеть - фактический провод (или оптический кабель, или беспроводное соединение), который будет передавать информацию между устройствами, подключенными к сети. Сетевые устройства должны иметь какой-то способ обнаружить конечный пункт назначения информации - вторую форму проблемы мультиплексирования - и определить, требуется ли какая-либо другая обработка информации, когда она находится в пути между источником и пунктом назначения. Информация, прошедшая через сетевое устройство, должна быть снова закодирована и перенесена из памяти в провод. В любой точке, где информация перемещается из памяти в какую-либо форму физического носителя, информация должна быть поставлена в очередь; часто бывает больше данных для передачи, чем может быть помещено на любой конкретный физический носитель в любой момент времени. Здесь в игру вступает качество услуг. Информация, передаваемая по сети, теперь должна быть скопирована с физического носителя и обратно в память. Он должен быть проверен на наличие ошибок - это контроль ошибок - и у приемника должен быть какой-то способ сообщить передатчику, что ему не хватает памяти для хранения входящей информации - это контроль потока. Особый интерес представляет сетевое устройство в середине диаграммы. Сетевое устройство-например, маршрутизатор, коммутатор или middle box—соединяет два физических носителя вместе для построения реальной сети. Возможно, самый простой вопрос для начала заключается в следующем: зачем вообще нужны эти устройства? Маршрутизаторы и коммутаторы — это, очевидно, сложные устройства со своей собственной внутренней архитектурой и зачем добавлять эту сложность в сеть? Есть две фундаментальные причины. Первоначальная причина создания этих устройств заключалась в соединении различных видов физических носителей вместе. Например, внутри здания может быть практично работать ARCnet или thicknet Ethernet (приведены примеры из времени, когда были впервые изобретены сетевые устройства). Расстояние, которое эти носители могли преодолеть, однако, очень мало-порядка сотни метров. Каким-то образом эти сети должны быть расширены между зданиями, между кампусами, между городами и, в конечном счете, между континентами, используя своего рода мультиплексированную (или обратную мультиплексированную) телефонную сеть, такую как T1 или DS3. Эти два различных типа носителей используют различные виды сигналов; должно быть какое-то устройство, которое переводит один вид сигналов в другой. Вторая причина заключается в следующем — это масштаб и это стало проблемой. Природа физического мира такова, что у вас есть два варианта, когда дело доходит до передачи данных по проводу: Провод может соединять напрямую два компьютера; в этом случае каждая пара компьютеров должна быть физически соединена с каждым другим компьютером, с которым она должна взаимодействовать. Провод может быть общим для многих компьютеров (провод может быть общим носителем информации). Чтобы решить проблему первым способом, нужно много проводов. Решение проблемы вторым способом кажется очевидным решением, но оно представляет другой набор проблем - в частности, как пропускная способность, доступная по проводам, распределяется между всеми устройствами? В какой-то момент, если на одном общем носителе достаточно устройств, любая схема, используемая для обеспечения совместного использования ресурсов, сама по себе будет потреблять столько же или больше пропускной способности, как любое отдельное устройство, подключенное к проводу. В какой-то момент даже 100-гигабайтное соединение, разделенное между достаточным количеством хостов, оставляет каждому отдельному хосту очень мало доступных ресурсов. Решением этой ситуации является сетевое устройство - маршрутизатор или коммутатор, который разделяет два общих носителя, передавая трафик между ними только по мере необходимости. При некотором логическом планировании устройства, которые должны чаще общаться друг с другом, можно размещать ближе друг к другу (с точки зрения топологии сети), сохраняя пропускную способность в других местах. Конечно, маршрутизация и коммутация вышли далеко за рамки этих скромных начинаний, но это основные проблемы, которые системные администраторы решают, внедряя сетевые устройства в сети. Есть и другие сложные проблемы, которые необходимо решить в этом пространстве, помимо простого переноса информации из источника в пункт назначения; Во многих случаях полезно иметь возможность виртуализировать сеть, что обычно означает создание туннеля между двумя устройствами в сети. Сети всегда создавались для одной цели: передачи информации от одной подключенной системы к другой. Дискуссия (или, возможно, спор) о наилучшем способе выполнения этой, казалось бы, простой задачи длилась долго. Эту дискуссию можно грубо разбить на несколько, часто пересекающихся, этапов, каждый из которых задавал свой вопрос: Должны ли сети быть с коммутацией каналов или с коммутацией пакетов? Должны ли сети с коммутацией пакетов использовать кадры фиксированного или переменного размера? Как лучше всего рассчитать набор кратчайших путей через сеть? Как сети с коммутацией пакетов должны взаимодействовать с качеством обслуживания (QoS)? Должна ли плоскость управления быть централизованной или децентрализованной? На некоторые из этих вопросов давным-давно был дан ответ. С другой стороны, некоторые из этих вопросов все еще актуальны, особенно последний. Коммутация каналов Первое большое обсуждение в мире компьютерных сетей было то, должны ли сети быть с коммутацией каналов или с коммутацией пакетов. Основное различие между этими двумя понятиями заключается в концепции схемы: нужно ли передатчику и приемнику «видеть» сеть как один провод или соединение, предварительно сконфигурированное (или настроенное) с определенным набором свойств прежде чем они начнут общаться? Или они «видят» сеть как общий ресурс, где информация просто генерируется и передается «по желанию»? Первый считается с коммутацией каналов, а второй считается с коммутацией пакетов. Коммутация каналов имеет тенденцию обеспечивать больший поток трафика и гарантии доставки, в то время как коммутация пакетов обеспечивает доставку данных при гораздо меньших затратах - первый из многих компромиссов, с которыми вы столкнетесь при проектировании сетей. Рисунок 2 будет использован для иллюстрации коммутации каналов с использованием мультиплексирования с временным разделением (TDM) в качестве примера. На рисунке 2 общая пропускная способность каналов между любыми двумя устройствами разделена на восемь равных частей; A отправляет данные E, используя временной интервал A1 и F, используя временной интервал A2; B отправляет данные в E с использованием временных интервалов B1 и F с использованием временных интервалов B2. Каждый фрагмент информации имеет фиксированную длину, поэтому каждый из них может быть помещен в один временной интервал в текущем потоке данных (следовательно, каждый блок данных представляет фиксированное количество времени или интервала в проводе). Предположим, что где-то есть контроллер, назначающий слот в каждом из сегментов, через которые будет проходить трафик: Для трафика [A, E]: На C: слот 1 от A переключен на слот 1 в направлении D На D: слот 1 от C переключен на слот 1 в направлении E Для трафика [A, F]: На C: слот 4 от A переключен на слот 4 в направлении D На D: слот 4 от C переключен на слот 3 в направлении F Для трафика [B, E]: На C: слот 4 от B переключен на слот 7 в направлении D На D: слот 7 от C переключен на слот 4 в направлении E Для трафика [B, F]: На C: слот 2 от B переключен на слот 2 в направлении D На D: слот 2 от C переключен на слот 1 в направлении F Ни одно из устройств обработки пакетов в сети не должно знать, какой бит данных идет куда; до тех пор, пока C берет все, что находится в слоте 1 в потоке данных A в каждом временном интервале, и копирует его в слот 1 в своем исходящем потоке в направлении D, А D копирует его из слота 1 входящего из C в слот 1 исходящего в E, трафик, передаваемый A, будет доставляться в E. Есть интересный момент, который следует отметить об этом виде обработки трафика—для пересылки трафика ни одно из устройств в сети на самом деле не должно знать, что является источником или назначением. Блоки данных, передаваемые по сети, не обязательно должны содержать адреса источника или назначения; куда они направляются и откуда поступают, все решения основываются на знании контроллерами открытых слотов в каждом канале. Набор слотов, назначенных для любой конкретной связи между устройствами, называется схемой, потому что это пропускная способность и сетевые ресурсы, выделенные для связи между одной парой устройств. Основные преимущества сетей с коммутацией каналов включают в себя: Для коммутации пакетов устройствам не нужно читать заголовок или выполнять какую-либо сложную обработку. Это было чрезвычайно важно в первые дни работы сети, когда аппаратное обеспечение имело гораздо меньшее количество транзисторов и переключателей, скорость линии была ниже, а время обработки пакета в устройстве составляло большую часть общей задержки пакета через сеть. Контроллер знает доступную полосу пропускания и трафик, направляемый к периферийным устройствам по всей сети. Это делает его несколько простым, учитывая, что на самом деле имеется достаточная пропускная способность, для организации трафика для создания наиболее оптимальных путей через сеть. Есть и недостатки, в том числе: Сложность контроллера значительно возрастает по мере того, как сеть и услуги, которые она предлагает, растут в масштабе. Нагрузка на контроллер может стать подавляющей, фактически вызывая перебои в работе сети. Пропускная способность на каждом канале используется не оптимально. На рис. 1-3 блоки времени (или ячейки), содержащие*, по существу являются потерянной полосой пропускания. Слоты назначаются определенной схеме заранее: слоты, используемые для трафика [A, E], не могут быть «заимствованы» для трафика [A, F], даже если A ничего не передает в сторону E. Время, необходимое для реагирования на изменения в топологии, может быть довольно длительным с точки зрения сети; локальное устройство должно обнаружить изменение, сообщить о нем контроллеру, и контроллер должен перенастроить каждое сетевое устройство вдоль пути каждого затронутого потока трафика. Системы TDM внесли ряд идей в развитие сетей, используемых сегодня. В частности, системы TDM сформировали большую часть ранних дискуссий о разбиении данных на пакеты для передачи по сети и заложили основу для гораздо более поздней работы в области QoS и управления потоком. Одна довольно важная идея, которую эти ранние системы TDM завещали большему сетевому миру, - это network planes. В частности, системы TDM делятся на три плоскости: Плоскость управления - это набор протоколов и процессов, которые формируют информацию, необходимую сетевым устройствам для пересылки трафика через сеть. В сетях с коммутацией каналов плоскость управления является полностью отдельной плоскостью; обычно существует отдельная сеть между контроллером и отдельными устройствами (хотя и не всегда, особенно в новых системах с коммутацией каналов). Плоскость данных (также известная как плоскость пересылки) - это путь информации через сеть. Это включает в себя декодирование сигнала, полученного в проводе, в кадры, обработку их и передачу их обратно в провод, закодированный в соответствии с физической транспортной системой. Плоскость управления ориентирована на управление сетевыми устройствами, включая мониторинг доступной памяти, мониторинг глубины очереди, а также мониторинг, когда устройство отбрасывает информацию, передаваемую по сети, и т. д. Часто бывает трудно различить уровни управления и плоскости управления в сети. Например, если устройство вручную сконфигурировано для пересылки трафика определенным образом, является ли это функцией плоскости управления (потому что устройство настраивается) или функцией плоскости управления (потому что это информация о том, как пересылать информацию)? Коммутация пакетов В начале-середине 1960-х годов коммутация пакетов находилась в состоянии «in the air». Много людей переосмысливали то, как сети были построены, и рассматривали альтернативы парадигме коммутации каналов. Paul Baran, работавший в RAND Corporation, предложил сеть с коммутацией пакетов в качестве решения для обеспечения живучести; примерно в то же время Donald Davies в Великобритании предложил такой же тип системы. Эти идеи попали в Lawrence Livermore Laboratory, что привело к созданию первой сети с коммутацией пакетов (названной Octopus), введенной в эксплуатацию в 1968 году. ARPANET, экспериментальная сеть с коммутацией пакетов, начала функционировать вскоре после этого, в 1970 году. Существенное различие между коммутацией каналов и коммутацией пакетов заключается в роли отдельных сетевых устройств в передаче трафика, как показано на рис.3. На рисунке 3, A создает два блока данных. Каждый из них включает в себя заголовок, описывающий, как минимум, пункт назначения (представлен H в каждом блоке данных). Этот полный пакет информации - исходный блок данных и заголовок - называется пакетом. Заголовок также может описывать, что находится внутри пакета, и может включать любые специальные инструкции по обработке, которые устройства пересылки должны принимать при обработке пакета - их иногда называют метаданными или «данными о данных в пакете». Есть два пакета, произведенных A: A1, предназначенный для E; и A2, предназначенный для F. B также отправляет два пакета: B1, предназначенный для F, и B2, предназначенный для E. Когда C получает эти пакеты, он считывает небольшую часть заголовка пакета, часто называемого полем, чтобы определить место назначения. Затем C обращается к локальной таблице, чтобы определить, по какому исходящему интерфейсу должен быть передан пакет. D делает то же самое, перенаправляя пакет из правильного интерфейса к месту назначения. Этот способ пересылки трафика называется переадресацией по частям, поскольку каждое устройство в сети принимает совершенно независимое решение о том, куда пересылать каждый отдельный пакет. Локальная таблица, к которой обращается каждое устройство, называется таблицей пересылки; обычно это не одна таблица, а множество таблиц, потенциально включающих в себя базу информации маршрутизации (RIB) и базу информации пересылки (FIB). В оригинальных системах с коммутацией каналов плоскость управления полностью отделена от пересылки пакетов по сети. С переходом от коммутации каналов к коммутации пакетов произошел соответствующий переход от решений централизованного контроллера к распределенному протоколу, работающему в самой сети. В последнем случае каждый узел способен принимать свои собственные решения о пересылке локально. Каждое устройство в сети запускает распределенный протокол, чтобы получить информацию, необходимую для построения этих локальных таблиц. Эта модель называется распределенной плоскостью управления; таким образом, идея плоскости управления была просто перенесена из одной модели в другую, хотя на самом деле они не означают одно и то же. Сети с коммутацией пакетов могут использовать централизованную плоскость управления, а сети с коммутацией каналов могут использовать распределенные плоскости управления. В то время, когда сети с коммутацией пакетов были впервые спроектированы и развернуты, однако они обычно использовали распределенные плоскости управления. Software-Defined Networks (SDN) вернули концепцию централизованных плоскостей управления в мир сетей с коммутацией пакетов. Первым преимуществом сети с коммутацией пакетов над сетью с коммутацией каналов является парадигма пересылки hop-by-hop. Поскольку каждое устройство может принимать полностью независимое решение о пересылке, пакеты могут динамически пересылаться в зависимости от изменений в топологии сети, что устраняет необходимость связываться с контроллером и ждать решения. Пока существует как минимум два пути между источником и пунктом назначения (сеть имеет два подключения), пакеты, переданные в сеть источником, в конечном итоге будут переданы в пункт назначения. Вторым преимуществом сети с коммутацией пакетов по сравнению с сетью с коммутацией каналов является то, как сеть с коммутацией пакетов использует пропускную способность. В сети с коммутацией каналов, если конкретная схема (действительно временной интервал в приведенном примере TDM) не используется, то слот просто тратится впустую. При переадресации hop-by-hop каждое устройство может наилучшим образом использовать пропускную способность, доступную на каждом исходящем канале, чтобы нести необходимую нагрузку трафика. Хотя это локально сложнее, это проще глобально, и это позволяет лучше использовать сетевые ресурсы. Основным недостатком сетей с коммутацией пакетов является дополнительная сложность, особенно в процессе пересылки. Каждое устройство должно быть в состоянии прочитать заголовок пакета, найти пункт назначения в таблице, а затем переслать информацию на основе результатов поиска в таблице. В раннем аппаратном обеспечении это были сложные, трудоемкие задачи; коммутация каналов была обычно быстрее, чем коммутация пакетов. Поскольку со временем аппаратное обеспечение усовершенствовалось, то скорость переключения пакета переменной длины, как правило, достаточно близка к скорости переключения пакета фиксированной длины, так что между пакетной коммутацией и коммутацией каналов небольшая разница. Управление потоками в сетях с коммутацией пакетов В сети с коммутацией каналов контроллер выделяет определенную полосу пропускания для каждого канала, назначая временные интервалы от источника до назначения. Что происходит, если передатчик хочет отправить больше трафика, чем выделенные временные интервалы будут поддерживать? Ответ — прост-это невозможно. В некотором смысле, таким образом, возможность управлять потоком пакетов через сеть встроена в сеть с коммутацией каналов; и нет способа отправить больше трафика, чем может передать сеть, потому что «пространство», которое имеет передатчик в своем распоряжении для отправки информации, предварительно выделяется. А как насчет сетей с коммутацией пакетов? Если все звенья сети, показанные на рис. 3, имеют одинаковую скорость соединения, что произойдет, если и А, и В захотят использовать всю пропускную способность соединения в направлении С? Как C решит, как отправить все это в D по каналу связи, который пропускает вдвое меньше трафика, необходимого для обработки? Здесь можно использовать методы управления транспортными потоками. Как правило, они реализованы в виде отдельного набора протоколов / правил, «движущихся поверх» базовой сети, помогая «организовать» передачу пакетов путем создания виртуального канала между двумя взаимодействующими устройствами. Протокол управления передачей (TCP) обеспечивает управление потоком для сетей с коммутацией пакетов на основе Интернет-протокола (IP). Этот протокол был впервые указан в 1973 году Vint Cerf и Bob Kahn.
онтроллер выделяет определенную полосу пропускания для каждого канала, назначая временные интервалы от источника до назначения. Что происходит, если передатчик хочет отправить больше трафика, чем выделенные временные интервалы будут поддерживать? Ответ — прост-это невозможно. В некотором смысле, таким образом, возможность управлять потоком пакетов через сеть встроена в сеть с коммутацией каналов; и нет способа отправить больше трафика, чем может передать сеть, потому что «пространство», которое имеет передатчик в своем распоряжении для отправки информации, предварительно выделяется.
А как насчет сетей с коммутацией пакетов? Если все звенья сети, показанные на рис. 3, имеют одинаковую скорость соединения, что произойдет, если и А, и В захотят использовать всю пропускную способность соединения в направлении С? Как C решит, как отправить все это в D по каналу связи, который пропускает вдвое меньше трафика, необходимого для обработки? Здесь можно использовать методы управления транспортными потоками. Как правило, они реализованы в виде отдельного набора протоколов / правил, «движущихся поверх» базовой сети, помогая «организовать» передачу пакетов путем создания виртуального канала между двумя взаимодействующими устройствами.
Протокол управления передачей (TCP) обеспечивает управление потоком для сетей с коммутацией пакетов на основе Интернет-протокола (IP). Этот протокол был впервые указан в 1973 году Vint Cerf и Bob Kahn.
В этой серии лекций продолжается рассмотрение распределенных плоскостей управления, добавляя к изучению еще три протокола маршрутизации. Два из них являются протоколами состояния канала, а третий – единственный, широко распространенный протокол вектора пути, Border Gateway Protocol (BGP) v4.
В этих лекция мы уделим внимание тому, почему каждый из этих протоколов реализован именно так. Очень легко увлечься и запутаться в изучении мельчайших деталей работы протоколов, но нам гораздо важнее помнить о проблемах, для решения которых эти протоколы были разработаны, и о диапазоне возможных решений. Каждый изучаемый вами протокол будет представлять собой комбинацию умеренно ограниченного набора доступных решений: существует очень мало доступных новых решений. Существуют различные комбинации решений, реализованных иногда уникальными способами для решения конкретных наборов проблем.
Изучая эти принципы работы протокола, вы должны попытаться выбрать общие решения, которые они реализуют. Затем отразить эти решения обратно в набор проблем, которые должна решить любая распределенная плоскость управления, чтобы устранить проблемы в реальных сетях.
Краткая история OSPF и IS-IS
Протокол Intermediate System to Intermediate System (IS-IS или IS to IS) был разработан в 1978 году.
Open Shortest Path First (OSPF) изначально задумывался как альтернатива IS-IS, предназначенная специально для взаимодействия с сетями IPv4. В 1989 году первая спецификация OSPF была опубликована Internet Engineering Task Force, а OSPFv2, значительно улучшенная спецификация, была опубликована в 1998 году как RFC2328. OSPF, безусловно, был более широко используемым протоколом, причем ранние реализации IS-IS практически не применялись в реальном мире. Были некоторые аргументы за и против, и многие функции были «позаимствованы» из одного протокола в другой (в обоих направлениях).
В 1993 году компания Novell, в то время крупный игрок в мире сетевых технологий, использовала протокол IS-IS как основу для замены собственного протокола маршрутизации Netware. Протокол транспортного уровеня Novell, Internet Packet Exchange (IPX), в то время работал на большом количестве устройств, и возможность использования одного протокола для маршрутизации нескольких транспортных протоколов была решающим преимуществом на сетевом рынке (EIGRP, также может маршрутизировать IPX). Этот протокол замены был основан на IS-IS. Чтобы реализовать новый протокол Novell, многие производители просто переписали свои реализации IS-IS, значительно улучшив их в процессе. Это переписывание сделало IS-IS привлекательным для крупных провайдеров Интернет-услуг, поэтому, когда они отказались от протокола RIP, они часто переходили на IS-IS вместо OSPF.
Intermediate System to Intermediate System Protocol
В протоколе Intermediate System to Intermediate System (IS-IS) маршрутизатор называется Intermediate System (Промежуточной системой (IS), а хост- End System (Конечной системой (ES). Оригинальный дизайн набора состоял в том, чтобы каждое устройство, а не интерфейс, имело один адрес. Службы и интерфейсы на устройстве будут иметь точку доступа к сетевым службам (Network Service Access Point - NSAP), используемую для направления трафика к определенной службе или интерфейсу. Таким образом, с точки зрения IP, IS-IS изначально был разработан в рамках парадигмы маршрутизации хоста. Промежуточные и конечные системы связываются непосредственно с помощью протокола End System to Intermediate System (ES-IS), позволяющего IS-IS обнаруживать службы, доступные в любой подключенной конечной системе, а также сопоставлять адреса нижних интерфейсов с адресами устройств более высокого уровня.
Еще один интересный аспект дизайна IS-IS - он работает на канальном уровне. Разработчикам протокола не имело большого смысла запускать плоскость управления для обеспечения доступности транспортной системы через саму транспортную систему. Маршрутизаторы не будут пересылать пакеты IS-IS, поскольку они параллельны IP в стеке протоколов и передаются по локальным адресам связи. Когда была разработана IS-IS, скорость большинства каналов была очень низкой, поэтому дополнительная инкапсуляция также считалась расточительной. Каналы связи также довольно часто выходили из строя, теряя и искажая пакеты. Следовательно, протокол был разработан, чтобы противостоять ошибкам при передаче и потере пакетов.
Адресация OSI
Поскольку IS-IS был разработан для другого набора транспортных протоколов, он не использует адреса Internet Protocol (IP) для идентификации устройств. Вместо этого он использует адрес взаимодействия открытых систем (Open Systems Interconnect - OSI) для идентификации как промежуточных, так и конечных систем. Схема адресации OSI несколько сложна, включая идентификаторы для органа, распределяющего адресное пространство, идентификатор домена, состоящий из двух частей, идентификатор области, системный идентификатор и селектор услуг (N-селектор). Многие из этих частей адреса OSI имеют переменную длину, что еще больше затрудняет понимание системы. Однако в мире IP используются только три части этого адресного пространства.
Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) и область, где все обрабатывается как одно поле.
Системный идентификатор по-прежнему рассматривается как системный идентификатор.
N Selector, или NSAP, обычно игнорируется (хотя есть идентификатор интерфейса, который похож на NSAP, используемый в некоторых конкретных ситуациях).
Таким образом, промежуточные системные адреса обычно принимают форму, показанную на рисунке 1.
На рисунке 1:
Точка разделения между системным идентификатором и остальной частью адреса находится в шестом октете или если отсчитать двенадцать шестнадцатеричных цифр с правой стороны. Все, что находится слева от шестого октета, считается частью адреса области.
Если N-селектор включен, это один октет или две шестнадцатеричные цифры справа от идентификатора системы. Например, если для адреса A был включен N-селектор, это могло бы быть 49.0011.2222.0000.0000.000A.00.
Если в адрес включен N-селектор, вам нужно пропустить N-селектор при подсчете более шести октетов, чтобы найти начало адреса области.
A и B находятся в одном домене flooding рассылки, потому что у них одни и те же цифры от седьмого октета до крайнего левого октета в адресе.
C и D находятся в одном flooding domain.
A и D представляют разные системы, хотя их системный идентификатор одинаков. Однако такая адресация может сбивать с толку и поэтому не используется в реальных развертываниях IS-IS (по крайней мере, вдумчивыми системными администраторами).
Вы посчитать эту схему адресации более сложной, чем IP, даже если вы регулярно работаете с IS-IS в качестве протокола маршрутизации. Однако есть большое преимущество в использовании схемы адресации, отличной от той, которая используется на транспортном уровне в сети. Гораздо проще различать типы устройств в сети и гораздо проще отделить узлы от адресатов, если продумать алгоритм Дейкстры по кратчайшему пути (SPF).
Маршаллинг данных в IS-IS
IS-IS использует довольно интересный механизм для маршалинга данных для передачи между промежуточными системами. Каждая IS генерирует три вида пакетов:
Hello-пакеты
Пакеты с порядковыми номерами (PSNP и CSNP)
Одиночный пакет состояния канала (Link State Packet - LSP)
Единый LSP содержит всю информацию о самой IS, любых доступных промежуточных системах и любых доступных адресатах, подключенных к IS. Этот единственный LSP форматируется в Type Length Vectors (TLV), которые содержат различные биты информации. Некоторые из наиболее распространенных TLV включают следующее:
Типы 2 и 22: достижимость к другой промежуточной системе
Типы 128, 135 и 235: достижимость до пункта назначения IPv4
Типы 236 и 237: достижимость к адресату IPv6
Существует несколько типов, потому что, IS-IS изначально поддерживал 6-битные метрики (большинство процессоров на момент появления протокола могли хранить только 8 бит за раз, и два бита были «украдены» из размера поля, чтобы нести информацию о том, был ли маршрут внутренним или внешним, а также другую информацию). Со временем, по мере увеличения скорости связи, были введены различные другие метрические длины, включая 24 - и 32-битные метрики, для поддержки широких метрик.
Одиночный LSP, несущий всю информацию о доступности IS, IPv4 и IPv6, а также, возможно, теги MPLS и другую информацию, не поместится в один пакет MTU. Для фактической отправки информации по сети IS-IS разбивает LSP на фрагменты. Каждый фрагмент рассматривается как отдельный объект в процессе лавинной рассылки. Если изменяется один фрагмент, лавинной рассылкой по сети распространяется только измененный фрагмент, а не весь LSP. Благодаря этой схеме IS-IS очень эффективен при лавинной рассылке информации о новой топологии и достижимости без использования полосы пропускания, превышающей минимальную требуемую.
Обнаружение соседей и топологии
Хотя IS-IS изначально был разработан, чтобы узнать о доступности сети через протокол ES-IS, когда IS-IS используется для маршрутизации IP, он «действует так же, как протоколы IP», и узнает о достижимых местах назначения через локальную конфигурацию каждого из них. устройства и путем перераспределения из других протоколов маршрутизации. Следовательно, IS-IS - это проактивный протокол, который изучает и объявляет достижимость без ожидания пакетов, которые будут переданы и переадресованы через сеть.
Формирование соседей в IS-IS довольно просто. Рисунок 2 иллюстрирует этот процесс.
На рисунке 2:
IS A передает приветствие в сторону B. Это приветствие содержит список соседей, от которых получен сигнал, который будет пустым. Настройку времени удержания (hold time) B следует использовать для A, и добавляется к максимальному блоку передачи (MTU) локального интерфейса для канала связи. Пакеты приветствия дополняются только до завершения процесса формирования смежности. Не каждый пакет приветствия дополняется MTU канала.
IS B передает приветствие к A. Это приветствие содержит список соседей, от которых получен ответ, который будет включать A. Настройку времени удержания A следует использовать для B. Добавляется к MTU локального интерфейса.
Поскольку A находится в списке «слышимых соседей» B, A рассмотрит B и перейдет к следующему этапу формирования соседей.
Как только A включил B в список «услышанных соседей» хотя бы в одно приветствие, B рассмотрит A и перейдет к следующему этапу формирования соседа.
B отправит полный список всех записей, которые он имеет в своей таблице локальной топологии (B описывает LSP, которые он имеет в своей локальной базе данных). Этот список отправляется в Complete Sequence Number Packet (CSNP).
A проверит свою локальную таблицу топологии, сравнив ее с полным списком, отправленным B. Любые записи в таблице топологии (LSP), которых он не имеет, он будет запрашивать у B с использованием Partial Sequence Number Packet (PSNP).
Когда B получает PSNP, он устанавливает флаг Send Route Message (SRM) для любой записи в его локальной таблице топологии (LSP), запрошенной A.
Позже процесс лавинной рассылки будет проходить по таблице локальной топологии в поисках записей с установленным флагом SRM. Он заполнит эти записи, синхронизируя базы данных в A и B.
Примечание. Описанный здесь процесс включает изменения, внесенные в RFC5303, который определяет трехстороннее рукопожатие, и дополнение приветствия, которое было добавлено в большинство реализаций примерно в 2005 году.
Установка флага SRM отмечает информацию для лавинной рассылки, но как на самом деле происходит лавинная рассылка?
Надежная лавинная рассылка.
Для правильной работы алгоритма SPF Дейкстры (или любого другого алгоритма SPF) каждая IS в flooding domain должна совместно использовать синхронизированную базу данных. Любая несогласованность в базе данных между двумя промежуточными системами открывает возможность зацикливания маршрутизации. Как IS-IS гарантирует, что подключенные промежуточные системы имеют синхронизированные базы данных? В этой лекции описывается процесс создания point-to-point каналов. Далее будут описаны модификации, внесенные в процесс flooding domain по каналам с множественным доступом (например, Ethernet).
IS-IS полагается на ряд полей в заголовке LSP, чтобы гарантировать, что две промежуточные системы имеют синхронизированные базы данных. Рисунок 3 иллюстрирует эти поля.
На рисунке 3:
Длина пакета (packet length) содержит общую длину пакета в октетах. Например, если это поле содержит значение 15 , длина пакета составляет 15 октетов. Поле длины пакета составляет 2 октета, поэтому оно может описывать пакет длиной до 65 536 октетов - больше, чем даже самые большие MTU канала.
Поле оставшегося времени жизни (remaining lifetime) также составляет два октета и содержит количество секунд, в течение которых этот LSP действителен. Это вынуждает периодически обновлять информацию, передаваемую в LSP, что является важным соображением для старых технологий передачи, где биты могут быть инвертированы, пакеты могут быть усечены или информация, передаваемая по каналу связи, может быть повреждена. Преимущество таймера, который ведет обратный отсчет, а не на увеличение, состоит в том, что каждая IS в сети может определять, как долго ее информация должна оставаться действительной независимо от каждой другой IS. Недостаток в том, что нет четкого способа отключить описанный функционал. Однако 65 536 секунд - это большое время - 1092 минуты, или около 18 часов. Повторная загрузка каждого фрагмента LSP в сети примерно каждые 18 часов создает очень небольшую нагрузку на работу сети.
LSP ID описывает сам LSP. Фактически, это поле описывает фрагмент, поскольку оно содержит идентификатор исходной системы, идентификатор псевдоузла (функцию этого идентификатора рассмотрим позже) и номер LSP, или, скорее, номер фрагмента LSP. Информация, содержащаяся в одном фрагменте LSP, рассматривается как «один блок» во всей сети. Отдельный фрагмент LSP никогда не «рефрагментируется» какой-либо другой IS. Это поле обычно составляет 8 октетов.
Порядковый номер (Sequence Number) описывает версию этого LSP. Порядковый номер гарантирует, что каждая IS в сети имеет одинаковую информацию в своей локальной копии таблицы топологии. Это также гарантирует, что злоумышленник (или «кривая» реализация) не сможет воспроизвести старую информацию для замены новой.
Контрольная сумма (Checksum) гарантирует, что информация, передаваемая во фрагменте LSP, не была изменена во время передачи.
Лавинная рассылка описана на рисунке 4.
На рисунке 4:
А подключен к 2001: db8: 3e8: 100 :: / 64. A создает новый фрагмент, описывающий этот новый достижимый пункт назначения.
A устанавливает флаг SRM на этом фрагменте в сторону B.
Процесс лавинной рассылки в какой-то момент (обычно это вопрос миллисекунд) проверит таблицу топологии и перезальет все записи с установленным флагом SRM.
Как только новая запись будет помещена в свою таблицу топологии, B создаст CSNP, описывающий всю свою базу данных, и отправит его в A.
Получив этот CSNP, A удаляет свой флаг SRM в направлении B.
B проверяет контрольную сумму и сравнивает полученный фрагмент с существующими записями в своей таблице топологии. Поскольку нет другой записи, соответствующей этой системе и идентификатору фрагмента, он поместит новый фрагмент в свою таблицу локальной топологии. Учитывая, что это новый фрагмент, B инициирует процесс лавинной рассылки по направлению к C.
А как насчет удаления информации? Есть три способа удалить информацию из системы IS-IS flooding:
Исходящая IS может создать новый фрагмент без соответствующей информации и с более высоким порядковым номером.
Если весь фрагмент больше не содержит какой-либо действительной информации, исходящая IS может заполнить фрагмент с оставшимся временем жизни (lifetime) равным 0 секунд. Это приводит к тому, что каждая IS в домене лавинной рассылки повторно загружает фрагмент zero age и удаляет его из рассмотрения для будущих вычислений SPF.
Если таймер lifetime во фрагменте истекает в любой IS, фрагмент заполняется лавинной рассылкой с zero age оставшегося времени жизни. Каждая IS, получающая этот фрагмент с zero age, проверяет, что это самая последняя копия фрагмента (на основе порядкового номера), устанавливает оставшееся время жизни для своей локальной копии фрагмента на ноль секунд и повторно загружает фрагмент. Это называется удалением фрагмента из сети.
Когда IS отправляет CNSP в ответ на полученный фрагмент, она фактически проверяет всю базу данных, а не только один полученный фрагмент. Каждый раз, когда фрагмент лавинно рассылается по сети, вся база данных проверяется между каждой парой промежуточных систем.
Подведение итогов об IS-IS
IS-IS можно описать как:
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в flooding domain (протокол состояния канала).
Расчет loop-free -путей с использованием алгоритма SPF Дейкстры.
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол).
Проверка двусторонней связи при формировании соседей путем переноса списка «замеченных соседей» в своих пакетах приветствия.
Удаление информации из домена лавинной рассылки с помощью комбинации порядковых номеров и полей оставшегося времени жизни (lifetime) в каждом фрагменте.
Проверка MTU каждой линии связи путем заполнения первоначально обмененных пакетов приветствия.
Проверка правильности информации в синхронизированной базе данных с помощью контрольных сумм, периодического перезапуска и описаний базы данных, которыми обмениваются промежуточные системы.
IS-IS - это широко распространенный протокол маршрутизации, который доказал свою работоспособность в широком диапазоне сетевых топологий и эксплуатационных требований.
Всем привет! В этой статье мы расскажем о том, что такое Device Pool в Cisco Unified Communications Manager (CUCM) и как его настроить.
Device Pool можно представить как набор конфигураций и шаблонов, который применяется к группе устройств. Их можно создавать сколько угодно и использовать для разных локаций или функций абонентов (например, отдельные Device Pool’ы для центрально офиса и филиалов в другом городе). Но прежде чем создавать Device Pool необходимо настроить несколько разделов, которые будут использоваться в Device Pool’е
Cisco Unified CM Group
Эта группа определяет, на каких серверах и в каком порядке должна происходить регистрация телефона. Первый в списке сервер является основным, остальные являются дополнительными и телефоны регистрируются на них, если у них не получилось зарегистрироваться на основном. Для добавления Cisco Unified CM группы нужно перейти во вкладку System → Cisco Unified CM Group и нажать Add New. В появившемся меню в поле Name указываем название группы, а ниже в поле Selected Cisco Unified Communications Managers добавляем наши серверы в желаемом порядке (доступные серверы находятся в поле Available Cisco Unified Communications Managers). Изменить приоритет можно кнопкой со стрелкой.
Region
Разделение на регионы нужно для определения пропускной способности аудио и видео звонков внутри и между регионами. Аудио кодек определяет тип сжатия и максимум использования полосы пропускания, которая используется при звонке. Для создания региона нужно перейти во вкладку System → Region и нажимаем на кнопку Add New Region. Далее указываем имя региона и попадаем на страницу настроек. В поле Regions выбираем, с каким регионом мы хотим настроить связь (если хотим применить настройки внутри региона то выбиваем в этом поле его самого), из выпадающего списка Audio Codec выбираем желаемый кодек, в поле Video Call Bandwidth указываем пропускную способность для видеозвонков и далее выбираем Link-Loss Type на случай потерь. После чего нажимаем Save и настройки пропускной способности между регионами переносятся в верхнюю часть в поле Region Relationships.
Date/Time Group
Использование Date/Time групп нужно для определения временных зон аппаратов, подключенных к CUCM. При установке CUCM автоматически создается группа CMLocal, дата и время которой синхронизированы с ОС системы, на которой установлен CUCM. Для создания новой группы переходим во вкладку System → Date/Time Group и нажимаем Add New Date/Time Group. В новом окне указываем ее название в поле Group Name, в поле Time Zone выбираем временную зону, разделитель выбираем в поле Separator, форматы даты и времени выбираем в полях Date Format и Time Format.
Создание Device Pool
Переходим во вкладку System → Device Pool и нажимаем Add New. Тут четыре поля обязательны к заполнению. Первое это название Device Pool’а, а остальные ты мы настроили ранее - это Cisco Unified Communications Manager Group, Region и Date/Time Format. Остальные поля можно заполнить, выбрав пункт по умолчанию. После заполнения всех полей нажимаем Save и сохраняем наш Device Pool. Теперь его можно применить в настройках уже созданного телефона, либо выбирать его при создании нового.