ВИРТУАЛИЗАЦИЯ МАГИСТРАЛИ ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ
ЮЖНОГО ФЕДЕРАЛЬНОГО УНИВЕРСИТЕТА Березовский А.Н., Букатов А.А., Шаройко О.В. ЮГИНФО Южного Федерального университета
and@sfedu.ru, baa@sfedu.ru, os@sfedu.ru
Актуальность задачи виртуализации магистрали телекоммуникационной сети (ТС) Южного федерального университета (ЮФУ) и обусловлена потребностями постоянного расширения спектра прикладных задач и сетевых служб, основанных на использовании ТС ЮФУ и зачастую требующих изоляции применяемых для решения этих задач сетевых структур друг от друга и от остальных участков ТС. К такого рода задачам и службам относятся, в частности, задачи автоматизации управления деятельностью ЮФУ, служба IP-телефонии, служба проведения видеоконференций, единая служба электронных проходных. С другой стороны, хорошо известно, что повысить эффективность построения ТС можно за счет консолидации, т.е. за счет выполнения как можно более широкого множества задач в рамках одной физической сети передачи данных. Такая консолидация повышает эффективность ТС как за счет уменьшения суммарной стоимости применяемого оборудования, так и за счет повышения эффективности управления оборудованием, уменьшения количества обслуживающего персонала и уменьшения времени простоя. Таким образом, с одной стороны необходима консолидация сетевых структур, использующихся для решения различных задач, а с другой – изоляция (возможно, на логическом уровне) этих структур друг от друга. Добиться требуемого эффекта можно с помощью виртуализации единой магистрали ТС, которая может выполняться на различных уровнях стека сетевых протоколов.
В настоящее время сетевым инженерам доступен некоторый набор стандартизованных средств и методов, предназначенных для виртуализации различных аспектов работы ТС. При выборе метода следует руководствоваться несколькими основными принципами: выбранный метод должен обеспечивать полную изоляцию сетевых структур друг от друга, должен быть эффективным и минимально снижать производительность сетевого оборудования и телекоммуникационных каналов, а также должен быть удобным при настройке и администрировании.
Вполне естественно ожидать, что на различных участках ТС целесообразно применять различные методы виртуализации. Рассмотрим участок ТС от конечных устройств, таких как ПК, до маршрутизаторов или коммутаторов 3-го уровня (данный участок сети обычно называется сетью доступа). Можно говорить, что для виртуализации сетей доступа стандартом де-факто является применение технологии виртуальных локальных сетей (VLAN) и протокола IEEE 802.1q. Данные средства позволяют накладывать на одну физическую сеть доступа множество изолированных друг от друга VLAN. Данное решение удовлетворяет всем перечисленным выше требованиям. Что же касается виртуализации на магистральном участке НОТС, то решить эту задачу только указанными выше способами вообще невозможно, так как на магистрали сети применяются устройства, работающие не на втором, а на третьем и более высоких уровнях стека сетевых протоколов и выполняющие специальные процессы построения таблиц маршрутизации на этих уровнях. Таким образом, для виртуализации магистрали, как минимум, необходимы средства виртуализации этих устройств. В ряде сетевых устройств такие средства реализованы, например, в маршрутизаторах и коммутаторах Сisco используется технология VRF Lite, позволяющая создавать виртуальные маршрутизаторы. Технически технологии VRF Lite в сочетании с протоколом IEEE 802.1Q достаточно для создания виртуальных сетей на магистральном участке НОТС, однако, добавление каждой новой виртуальной сети при этом требует значительных усилий, связанных с настройкой всех маршрутизаторов магистрали.
В ТС ЮФУ применен другой подход, позволяющий строить виртуальные сети на магистральном участке и требующий настройки только пограничных устройств, т.е. тех устройств, к которым непосредственно подключены виртуальные сети доступа. Подход основан на технологии BGP/MPLS VPN [1]. В технологии MPLS к каждому IP пакету приписывается одна или несколько меток, образующих стек. Маршрутизаторы, работающие с помеченными пакетами, принимают решение о маршрутизации пакета на основе поиска в таблице меток записи, соответствующей самой верхней метке пакета. Таким образом, можно говорить, что технология MPLS позволяет заменить протокол IEEE 802.1q на магистрали сети и обеспечить виртуальную среду передачи данных. Причем при добавлении новой виртуальной сети нет необходимости настраивать каждое устройство магистрали ТС.
Маршрутизаторы и коммутаторы магистральных участков сети обмениваются специальной информацией, позволяющей автоматически строить таблицы маршрутов. Однако в различных виртуальных сетях таблицы маршрутизации могут содержать различные маршруты для одинаковых адресов, ведь виртуализация предполагает полную изоляцию виртуальных сетей друг от друга. Для обмена маршрутной информацией используется технология BGP/MPLS VPN, тесно взаимодействующая с технологией виртуальных маршрутизаторов (VRF Lite). При этом в пограничных маршрутизаторах поддерживается не одна, а несколько таблиц маршрутизации. Обмен информацией между несколькими таблицами маршрутизации основан на применении многопротокольных расширений BGP [2].
Таким образом, технология BGP/MPLS VPN позволяет виртуализировать магистральный участок ТС, что было подтверждено опытной эксплуатацией описанных методов, проведенной в ЮГИНФО ЮФУ и готовящимся полномасштабным внедрением этих методов в ТС ЮФУ. Отметим, что используемая в предлагаемых методах технология BGP/MPLS VPN поддерживается оборудованием производства Сisco systems, применяемом в магистральной части ТС ЮФУ: маршрутизаторах серий 7206, 3640, 3660 и 3745 и коммутаторах серий 2924, 2950-24 и 3550-24. Подчеркнем, что важным требованием, предъявляемым к другим моделям используемых коммутаторов является возможность предавать пакеты диной не менее 1530 байт, поскольку это необходимо для обеспечения возможности передачи расширенных заголовков пакетов, применяемых в технологии BGP/MPLS VPN.
Литература
1. Rosen E., Rekhter Y., BGP/MPLS VPNs, RFC 2547, March 1999.
2. Bates T., Chandra, R., Katz D., Rekhter Y., Multiprotocol Extensions for BGP4, RFC 2283, February 1998.
|
