Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Проектирование маршрутизации в двух трехуровневых сетях с использованием протокола BGP

Содержание:

1.Введение

Мы рассмотрелли протоколы динамической маршрутизации, используемые в основном для работы в сетях среднего либо малого размера. И хотя, при описании таких протоколов как OSPF и EIGRP использовалось понятие Автономная система (AS), под такими AS понимались отдельные физические сети в каждой из которых мог работать свой внутренний протокол маршрутизации, или же деление на AS производилось по иным соображениям – например для облегчения контроля трафика и т.п. Однако, в любом из приведенных случаев, администрирование взаимодействующих AS подразумевает централизованное управление и выработку единой политики относительно конфигурации Автономных систем. При использовании термина AS в более масштабном смысле, при описании глобальных взаимодействий Internet, под Автономной системой подразумевают область, управляемую отдельно от других, т.е. права на администрирование данной области принадлежат одному субъекту. Таким образом, взаимодействие между AS не может управляться централизованно, т.к. каждая Автономная система имеет своего хозяина – в этом случае возможность совместной работы различных AS между собой реализуется достижением договоренностей между владельцами автономных систем о деталях такого взаимодействия, стоимости услуг и т.д. Для того, что бы лучше понять специфику управления взаимодействием между глобальными AS, и динамической маршрутизацией меньших масштабов, рассмотрим историю развития Internet, с точки зрения межсетевых взаимодействий и определим основные термины, используемые при описании маршрутизации в Internet.

2.История развития

Как известно, сеть Internet началась как эксперимент в конце 60-х годов 20-го века, проводившийся агентством по передовым исследованиям (Advanced Research Projects Agency — ARPA, позднее переименованное в DARPA), которое находилось в ведении Министерства обороны США (Department of Defense). Агентство DARPA проводило комплексные исследования работы компьютеров, объединенных в сеть, с предоставлением грантов на конкурсной основе нескольким университетам и частным компаниям, вовлекая их таким образом висследовательский процесс. В декабре 1969 года была сдана в эксплуатацию экспериментальная сеть, объединявшая четыре узла со скоростью передачи данных 56 Кбит/с. Новая технология, примененная при построении этой сети, доказала свою жизнеспособность и легла в основу создания еще двух военных вычислительных сетей: MILNET — на территории США и MINET — в Европе. Впоследствии к сети ARPANET были подключены тысячи хостов и отдельных сетей (главным образом университетских и государственных), что привело к созданию так называемой "ARPA Internet" — прародительницы современной сети Internet.

Конгломерат исследовательских, образовательных и государственных сетей, объединенных ядром сети ARPANET, положил начало сети, которая сегодня известна под названием Internet. Однако в сети ARPANET существовал набор правил для пользователей, обязательный для всех (так называемая Acceptable Usage Policy — AUP). Согласно этому своду правил, запрещалось использование сети ARPANET в коммерческих целях. К тому же, у пользователей ARPANET стали возникать проблемы при расширении сетей, наиболее очевидными из которых являлись перегрузки на линиях связи. Поэтому Национальный

научный фонд (National Science Foundation —NSF) приступил к созданию сети NSFNET2. Эксплуатация сети ARPANET была полностью прекращена в 1989 году.

Уже к 1985 году сеть ARPANET разрослась до огромных размеров, и администраторы столкнулись с проблемой перегруженности сети. Чтобы исправить ситуацию, NSF инициировал развертывание сети NSFNET. В 1990 году, объединив свои усилия в области обслуживания национальной вычислительной сети, компании Merit3 , IBM и MCI создали организацию по развитию сети и услуг под названием Advanced Network and Services (ANS). Группа инженеров компании Merit разработала базу данных, в которой хранилась информация о маршрутизации, консультировала и осуществляла управление маршрутами в сети NSFNET, a ANS отвечала за работу магистральных маршрутизаторов и управляла сетевым операционным центром (Network Operation Center—NOC).

К 1991 году трафик сети возрос настолько, что понадобилось срочно расширять пропускную способность магистральных каналов опорной сети до каналов ТЗ (45 Мбит/с). В начале 90-х годов сеть NSFNET по-прежнему использовалась в исследовательских и образовательных целях. Все магистральные каналы передачи данных были зарезервированы правительственными агентствами для стратегических целей.

Чтобы как-то упорядочить рост сети, NSF назначил компанию Sprint менеджером международных соединений (International Connection Manager — ICM), в функции которой входило обеспечение соединений между компьютерными сетями США, Европы и Азии. В апреле 1995 было объявлено о прекращении существования сети NSFNET.

Деятельность NSFNET должна была прекращаться постепенно, в несколько этапов, с сохранением существующих соединений между различными государственными институтами и агентствами. Инфраструктура сети Internet сегодня — уход от концентрированного ядра сети (как это было в NSFNET) к более распределенной архитектуре, которая управляется в основном коммерческими провайдерами. Все они соединяются друг с другом через точки обмена трафиком либо напрямую. Современная опорная сеть Internet представляет собой объединение провайдеров Internet, у которых в нескольких регионах имеются узлы, называемые точками присутствия (Points Of Presence — POP). Это — объединение точек доступа и совокупность каналов, соединяющих их между собой. Все подключения клиентов к провайдерам Internet осуществляются именно через серверы доступа или другие средства хостинга, расположенные на POP провайдера. Иногда клиенты сами могут быть одновременно провайдерами Internet (тогда их называют субпровайдерами).

Первое ходатайство от NSF поступило в 1987 году и привело к модернизации опорной сети (магистральные каналы передачи данных к концу 1993 г. были заменены на каналы с большей пропускной способностью — Т3). В 1992 году NSF собирался подать ходатайство об объединении и усилении роли коммерческих сервис-провайдеров, что создало бы условия для построения универсальной модели сети. В то же время в NSF решили отказаться от обслуживания ядра сети и направили все усилия на разработку новых концепций и продвижение новых технологий. Последнее ходатайство от NSF (NSF 93-52) было издано в мае 1993 года. В последнее ходатайство вошли четыре отдельных проекта, в которых предполагалось:

- Создать разветвленную сеть точек доступа к сети (NAP), посредством которых провайдеры могли бы осуществлять обмен трафиком.

- Реализовать проект арбитража маршрутизации в сети (Routing Arbiter project — RA), что облегчило бы согласование правил работы в сети и управление адресами между несколькими провайдерами, подключенными к NAP.

- Найти и утвердить единого провайдера для службы обеспечения высокоскоростной магистральной сети (very high-speed Backbone Network Service — vBNS), который бы обеспечивал подключения в интересах государственных и образовательных учреждений.

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

Фондом NSF были выделены четыре основных NAP:

• Sprint NAP в Пенсаукен (штат Нью-Джерси);

• PacoBell NAP в Сан-Франциско (штат Калифорния);

• Ameritech Advanced Data Services (AADS) NAP в Чикаго (штат Иллинойс);

• MFS Datanet (MAE-East) NAP в Вашингтоне (Федеральный округ Колумбия).

Опорная сеть NSFNET 13 сентября 1994 года была подключена к точке доступа Sprint NAP. В середине октября 1994 года она была подключена к NAP PacoBell, а в начале января 1995 года к NAP Ameritech. И, наконец, 25 марта 1995 года, по предложению MFS (ныне MCI Worldcom), сеть NSFNET была подключена к узлу MAE-East FDDI.

3.Рост количества провайдеров

С ростом количества провайдеров, подключенных к NAP, повышалась и масштабируемость сети, так как каждый провайдер должен был обеспечить межсетевые соединения с другими провайдерами для обмена маршрутной информацией и информацией о правилах работы в сети. Проект RA был призван уменьшить требования к организации соединений между провайдерами. Планировалось отойти от схемы соединений типа "каждый с каждым". Вместо этого провайдеры должны были обеспечить лишь соединения с определенной центральной системой, которая называлась сервером маршрутов (Route Server). Сервер маршрутов был призван обслуживать базу данных, в которой содержалась необходимая для провайдеров информация о маршрутах и правилах их применения. На рисунке представлена схема физических соединений и логического взаимодействия между провайдерами и сервером маршрутов:

На проект RA возлагались следующие задачи.

- Укрепление стабильности и повышение управляемости маршрутами в сеть Internet. Сервер маршрутов выполняет эти задачи путем уменьшения количеств; узлов ВGР, требуемых для соблюдения правил маршрутизации, перед передачей маршрутной информации следующему узлу. Таким образом, путем сокращения объемов информации о маршрутах уменьшается нагрузка на маршрутизаторы.

- Формирование и обслуживание баз данных топологий сети путем обмена маршрутной информацией и ее обновления посредством подключенных к сети автономных систем (Automomous System — AS) с помощью одного из стандартных протоколов внешнего шлюза Exterior Gateway Protocol (EGP), например таких, как протокол граничного шлюза Border Gateway Protocol (BGP) и IDRP (поддержка IP и CLNP).

- Подача предложений и определение процедур по взаимодействию технического персонала при решении технических проблем, начиная от менеджеров NAP, дежурных операторов провайдеров vBNS, до администраторов региональных и других сетей включительно. Обеспечение единого качества обслуживания (Quality of Service— QoS) во всей сети и устойчивости всех существующих соединений. Разработка новых технологий в обеспечении маршрутизации, т.е. введение таких критериев, как тип сервиса (type of service) и маршрутизация по старшинству, многоадресная передача, выделение полосы пропускания по запросу и формирование службы распределения полосы пропускания совместно со всем сетевым сообществом Internet.

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

- Внедрение распределенного управления в сети Internet. Проект RA осуществлялся объединенными усилиями компании Merit Network, Inc., Института информационных технологий при Южнокалифорнийском университете (University of Southern California Information Sciences Institute — USC ISI), компании Cisco Systems (как субподрядчика ISI) и Университета штата Мичиган (University of Michigan ROC) (с компанией Merit в качестве субподрядчика).

Проект RA подразделялся на четыре дочерних субпроекта.

- Сервер маршрутов (Route Server — RS) — В качестве RS может выступать рабочая станция Sun, установленная на каждой NAP. - Система управления сетью (Network Management System) — Специальное программное обеспечение, с помощью которого осуществляется мониторинг производительности RS. На каждом RS запускаются специальные программы-агенты — распределенные указатели, с помощью которых ведется сбор статистики о производительности RS. В центре по мониторингу маршрутов компании Merit (Merit Routing Operations Center) находится центральная станция управления сетью (central network management station — CNMS), которая опрашивает всех агентов и обрабатывает собранную информацию.

- База данных арбитража маршрутизации (Routing Arbiter Database — RADB) — Эта база данных является одной из нескольких баз данных маршрутов, известных как регистр маршрутов сети Internet (Internet Routing Registry — IRR). - Группа инженеров по маршрутизации (Routing Engineering Team) — Эта группа работает совместно с провайдерами при разрешении технических проблем, возникающих в NAP. В обязанности специалистов группы входит предоставление консультаций по стратегиям маршрутизации, разработке планов адресации и другим вопросам, касающимся маршрутизации.

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

Американский реестр адресов сети Internet. В конце 1997 года IANA передала права на администрирование IP-адресов от компании Network Solutions, Inc. Американскому реестру ARIN. Официально реестр ARIN начал свою деятельность 22 октября 1997 года. В настоящее время ARIN отвечает за распределение IP-адресов в следующих географических регионах:

• Северная Америка.

• Южная Америка.

• Страны Карибского бассейна.

• Центральная и Южная Африка.

ARIN так же управляет распределением и регистрацией IP-адресов, номеров автономных систем (AS), корневым доменом IN-ADDR.ARPA и экспериментальным доменом IP6.INT. Кроме того, эта организация обеспечивает регистрацию в реестре маршрутизации, т.е. операторы сети могут регистрироваться, получать и обновлять конфигурационную информацию для маршрутизаторов, пользоваться услугами службы WHOIS для просмотра информации по заданным критериям. ARIN является некоммерческой организацией. Основные источники финансовых поступлений — регистрационные взносы за назначение и обслуживание блоков IP-адресов, поступающие от членов ARIN.

Кроме ценовой политики, магистральных каналов и способов межсетевых соединений, следует также обсудить с провайдером вопрос о точке демаркации (demarcation point — DP). Точка демаркации — это точка, в которой происходит разделение сети на зоны ответственности провайдера и клиента (или клиентов). Частично это определение верно и для провайдера, предоставляющего услуги выделенного подключения. Важно определить и правильно понимать различия между зоной ответственности провайдера и клиента. Точки демаркации определяются вплоть до конкретных кабелей и разъемов для того, чтобы избежать конфликтных ситуаций при возникновении каких-либо проблем с оборудованием или в работе сети. На рисунке представлена типовая точка демаркации между сетью провайдера и сетью клиента:

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

1. Если оборудование принадлежит клиенту.

Оборудование, принадлежащее клиенту (Customer Premises Equipment — CPE), обычно включает в себя маршрутизатор, устройство сопряжения с цифровым каналом CSU/DSU, систему кабелей и иногда аналоговый модем для мониторинга и управления вышеуказанным оборудованием вне основной полосы (out-of-bandwidth — ООВ). Обычно провайдер предлагает клиенту выбор в приобретении СРЕ и канала для доступа к своему узлу. Так, вы можете оплатить только канал доступа или же выплачивать ежемесячно набор услуг, в который входит аренда и обслуживание всего оборудования и канала доступа, но при этом все эти задачи выполняются персоналом провайдера. Практически всегда удается достичь с провайдером хорошего соотношения цена/качество для предоставляемых услуг.

Обычно ISP несет ответственность за обслуживание оборудования или за качество предоставляемых с его помощью услуг. Как правило, провайдеры заранее формируют различные пакеты услуг, в которые входит и обслуживание СРЕ. Если же клиент не желает приобрести стандартный пакет услуг, то ему придется выбрать оборудование, заранее одобренное провайдером. После этого покупатель будет самостоятельно нести ответственность за обслуживание и решение технических проблем, возникающих при эксплуатации этого оборудования.

В данном случае, провайдер обеспечивает доступ к CSU/DSU, а клиент предоставляет маршрутизатор.

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

Далее представлена схема, когда клиент предоставляет и СРЕ, и соединительную линию. В этом случае ответственность провайдера заканчивается на коммутационном шкафу, расположенном на одной из POP провайдера, где осуществляется коммутация технической площадки провайдера с центральным офисом.

2. Расположение маршрутизаторов.

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

Стимулирующими факторами для расположения клиентом своего оборудования на узле провайдера является более быстрый доступ и упрощение мониторинга оборудования со стороны провайдера или предоставление клиенту возможности более гибкого управления нагрузкой на полосу пропускания.

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

После рассмотрения возможных схем подключения к маршрутизаторам провайдера, рассмотрим протокол BGP, как основной (стандартный) протокол, используемый в подобных случаях, при внедрении динамической маршрутизации.

Протокол граничного шлюза Border Gateway Protocol (BGP) претерпел несколько изменений с момента выхода его первой версии BGP-1 в 1989 году. Повсеместное внедрение BGP-4 началось в 1993 rоду. Это первая из версий BGP, в которой появились возможности агрегации адресов, что позволило реализовать бесклассовую междоменную маршрутизацию (classless interdomain routing—CIDR), и обеспечить поддержку суперсетей.

Протокол BGP не предъявляет никаких требований к топологии сети. Принцип его действия предполагает, что маршрутизация внутри автономной системы выполняется с помощью внутренних протоколов маршрутизации, или, как их еще называют, интра-протоколов (например, Interior Gateway Protocol — IGP). Далее по тексту термин "внутренний" (intra) обозначает все, что относится к действиям внутри субъекта, а термин "внешний " (inter) означает события или действия, которые имеют место между субъектами. Протоколом ВGР на основе информации, полученной от различных маршрутизаторов, выстраивается граф автономных систем со всеми связями между узлами. Такой граф так же называют деревом. Если рассматривать сеть Internet "глазами" протокола BGP, то это будет граф, состоящий из автономных систем (AS), где каждой AS соответствует уникальный номер.

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

Протокол BGP является протоколом вектора маршрута и используется для обмена маршрутной информацией между автономными системами. Термин вектор маршрута (path vector) происходит из самого принципа действия BGP: маршрутная информация содержит последовательности номеров AS, через которые прошел пакет с заданным префиксом сети. Маршрутная информация, связанная с префиксом, используется для профилактики образования петель в маршрутах.

В качестве транспортного протокола в BGP используется протокол TCP (порт 179). Таким образом, надежность доставки (включая повторную передачу) возлагается на протокол TCP и не требует отдельной реализации в самом BGP, что естественно упрощает механизмы надежности в BGP. Маршрутизаторы, которые работают с протоколом BGP, часто называют спикерами BGP (BGP speakers). Два спикера BGP, образующих TCP-соединение друг с другом для обмена маршрутной информацией, называют соседними (neighbors) или взаимодействующими (peers).

Взаимодействующие маршрутизаторы сначала обмениваются открытыми сообщениями для того, чтобы определить параметры соединения. Эти сообщения используются для согласования параметров, таких как номер версии BGP и др. в случае негативного исхода переговоров между взаимодействующими маршрутизаторами, что может быть результатом несовместимости их конфигураций, вмешательства оператора или вызвано другими причинами, генерируется и посылается сообщение об ошибке NOTIFICATION. Получив это сообщение, вторая сторона должна прекратить попытки установить соединение или разорвать его, если оно было установлено ранее. Преимущество такого механизма заключается в том, что обе стороны уведомляются о невозможности установки соединения и не тратят свои мощности на обслуживание этого соединения или попытки повторно установить связь. Процедура закрытия также гарантирует, что обе стороны до закрытия сеанса TCP, получат все сообщения об ошибках, в частности сообщение NOTIFICATION.

В начале сеанса ВGР между несколькими спикерами ведется обмен всеми маршрутами, которые могут далее использоваться в работе по протоколу ВGР. После того как соединение установлено и проведен начальный обмен маршрутами, по сети рассылается лишь информация о новых маршрутах — так называемые инкремент-ные обновления (incremental updates). Применение инкрементных обновлений, по сравнению с периодическим обновлением маршрутов, которое использовалось в других протоколах, таких как EGP, позволило многократно увеличить производительность центральных процессоров на маршрутизаторах и разгрузить полосу пропускания. Согласно протоколу ВGР, пара маршрутизаторов уведомляется о маршрутах и изменениях в них с помощью сообщения UPDATE. Сообщение UPDATE, помимо другой полезной информации, содержит список записей типа <длина, префикс> (<Iength, prefix>), указывающих на список узлов, на которые можно доставить трафик через спикер ВGР. В сообщение UPDATE также включены атрибуты маршрута. К ним относятся: степень предпочтения определенного маршрута и список AS, через которые пролегает маршрут.

В случае если маршрут становится недействительным, т.е. по нему невозможно достичь пункта назначения, спикер ВGР информирует об этом своих соседей и удаляет недействительный маршрут. Удаляемые маршруты также включаются в сообщение UPDATE. Таким образом, эти маршруты уже нельзя использовать. Если же информация о маршруте изменилась или для того же префикса выбран новый маршрут, то процедура удаления не выполняется; в этом случае достаточно лишь объявить о замене маршрута.

При таком алгоритме, если нет никаких изменений в структуре маршрутов, то маршрутизаторы обмениваются только пакетами KEEPALIVE. Сообщения KEEPALIVE периодически посылаются между соседними маршрутизаторами ВGР, чтобы убедиться, что соединение находится в нормальном состоянии. Пакеты KEEPALIVE (длиной 19 байт каждый) не создают практически никакой нагрузки на процессор маршрутизатора и полосу пропускания, так как им требуется очень незначительная полоса пропускания (один 152-битовый пакет каждые 60 секунд, т.е. около 2,5 байт/с).

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

4.Заголовка пакета BGP

Далее, рассмотрим формат заголовка пакета BGP

Формат заголовка сообщения в BGP представляет собой поле маркера длиной 16 байт, за которым следует поле длины (2 байта) и поле типа (1 байт). В зависимости от типа пакета в сообщении протокола BGP за заголовком может следовать или не следовать блок данных. Так, например, сообщения KEEPALIVE состоят только из заголовка и никаких данных не передают. Поле маркера длиной 16 байт используется для аутентификации входящих сообщений BGP либо для детектирования потери синхронизации между двумя взаимодействующими по BGP маршрутизаторами. Поле маркера бывает двух форматов:

• Если послано сообщение типа OPEN или в нем отсутствует информация об аутентификации, то в поле маркера все позиции выставляются в 1.

• В другом случае значение поля маркера вычисляется в соответствии с используемым механизмом аутентификации.

Поле длины размером 2 байта используется для отображения полной длины сообщения ВGР, включая заголовок. Наименьшая длина сообщения ВGР составляет 19 байт (16+2+1), а наибольшая — 4096 байт.

Поле типа размером 1 байт определяет тип сообщения. Возможны следующие значения:

• OPEN (Открытие соединения)

• UPDATE (Обновление маршрутной информации)

• NOTIFICATION (Уведомление об ошибке)

• KEEPALIVE (Проверка состояния соединения)

Одно из основных положений протокола ВGР состоит в том, что взаимодействующие узлы устанавливают между собой сеансы ВGР. Если этот этап по каким-либо причинам не был выполнен, то обмен маршрутной информацией или ее обновление не проводится. Переговоры с соседними узлами основаны на успешном установлении соединения по протоколу TCP, успешной обработке сообщения OPEN и периодическом обмене сообщениями UPDATE и KEEPALIVE.

5.BGP-соседи

Процесс переговоров между BGP-соседями до полной установки соединения

происходит в несколько этапов

1. Ожидание (Idle). Это первое состояние, в котором находятся системы перед установлением соединения. В протоколе ВGР ожидается наступление события "Пуск" (Start), инициированного оператором или самой BGP-системой. Администратор вызывает наступление события "Пуск" путем установления BGP- сеанса маршрутизатором или посредством сброса существующего BGP-сеанса. После наступления события "Пуск" BGP-система инициализирует свои ресурсы, сбрасывает таймер повторных попыток установки соединения (ConnectRetry timer), устанавливает транспортное соединение по протоколу TCP и находится в режиме ожидания соединения с удаленной стороной. Затем BGP-система переходит в состояние ведения связи. В случае появления каких-либо ошибок BGP-система возвращается в состояние ожидания.

2. Связь (Connect). В этом состоянии BGP-система ожидает полного установления соединения транспортным протоколом. Если TCP-соединение установлено успешно, то система переходит в состояние пересылки сообщения OPEN (OpenSent) (т.е. на этом этапе удаленной системе посылается сообщение об открытии соединения OPEN). Если истекает время, заданное таймером повторных попыток ConnectRetry timer, то система остается в состоянии "Связь", таймер сбрасывается, и повторно начинается установка соединения транспортным протоколом. При наступлении каких-либо других событий, инициированных оператором или самой системой, BGP-система возвращается в состояние ожидания.

3. Система активна (Active). На этом этапе BGP-система пытается достичь удаленной системы путем открытия соединения транспортного протокола. Если установлено транспортное соединение, то система переходит в состояние пересылки сообщения OPEN (OpenSent), при котором генерируется и посылается сообщение OPEN. Если истекает интервал времени, заданный таймеромповторных попыток, то система перезапускает таймер и возвращается в состояние "Связь". При этом BGP-система продолжает ожидать появления входящего соединения от удаленного узла. При наступлении еще каких-либо событий система может вернуться и в состояние ожидания. Таким событием может быть событие "Останов" (Stop), инициированное самой системой или оператором. Если система находится в состоянии, колеблющимся между состояниями "Связь" и "Система активна", — это признак того, что при установке транспортного TCP-соединения что-то происходит неправильно. Причинами такого состояния может быть большое количество повторных передач пакетов по протоколу TCP или невозможность соседнего узла распознать IP-адрес удаленной стороны.

4. Состояние пересылки сообщения OPEN (OpenSent). В этом состоянии BGP-система ожидает получения сообщения OPEN от удаленной стороны. Полученное сообщение проверяется на целостность. Если в нем содержатся ошибки, такие как искаженный номер версии протокола или недопустимый номер AS, система отправляет удаленной стороне сообщение об ошибке NOTIFICATION и возвращается в состояние ожидания. Если ошибок не обнаружено, BGP-система начинает посылать сообщения KEEPALIVE и сбрасывает свой таймер проверки состояния канала (KEEPALIVE timer) в 0. С этого момента оговаривается также время удержания и устанавливается наименьшее его значение из связанных систем. Если согласованное время удержания равно 0, то таймер удержания (Holdtimer) и таймер проверки состояния (KEEPALIVE timer) не перезапускаются. В состоянии пересылки сообщения OPEN BGP-система путем сравнения собственного номера AS с номером AS удаленной системы выясняет, принадлежит ли маршрутизатор, с которым установлена связь, к той же автономной системе (внутренний Internal BGP) или это различные AS (внешний External BGP). При разрыве TCP-соединения система возвращается в состояние "Система активна". При возникновении других событий, таких как истечение времени, заданного таймером удержания, BGP-система посылает сообщение NOTIFICATION, в котором содержится код ошибки, и возвращается в состояние ожидания. Кроме того, в ответ на событие "Останов", инициированное системой или оператором, BGP-система также переходит в состояние ожидания.

5. Подтверждение получения сообщения OPEN (OpenConfirm). В этом состоянии BGP-система ожидает поступления сообщения KEEPALIVE. Приняв такое сообщение, система переходит в следующее состояние "Связь установлена"(Established) и переговоры с соседним узлом завершаются. Приняв сообщение KEEPALIVE, система перезапускает свой таймер удержания (при условии, что оговоренное значение времени ожидания не равно 0). Если же система получает сообщение NOTIFICATION, то она возвращается в состояние ожидания. Система периодически посылает другой стороне сообщения KEEPALIVE с частотой, установленной таймером проверки состояния канала. В случае любого разрыва транспортного соединения или в ответ на событие "Останов", инициированное самой системой или оператором, система также возвращается в состояние ожидания. При наступлении какого-либо другого события система посылает сообщение NOTIFICATION, содержащее код ошибки модели конечных состояний FSM, и возвращается в состояние ожидания.

6. Связь установлена (Established). Это последнее состояние, в котором находятся соседние узлы при ведении переговоров. В этом состоянии BGP-система начинает обмен пакетами UPDATE со своими соседями. Предположим, что таймер удержания не равен 0. Тогда он будет перезапускаться каждый раз при приеме сообщения UPDATE или KEEPALIVE. Если же система получает сообщение NOTIFICATION (в случае возникновения какой-либо ошибки), то она возвращается в состояние ожидания. Сообщения UPDATE также проверяются на наличие ошибок, таких как недостающие атрибуты, дублированные атрибуты и другие. При обнаружении ошибки взаимодействующей стороне высылается сообщение NOTIFICATION, и система переводится в состояние ожидания. В состояние ожидания система возвращается также по истечении времени, заданного таймером удержания, при получении уведомления о разрыве транспортного соединения или при наступлении события "Останов", принятого от другого узла или наступившего в результате какого-либо другого события.

Ниже приведены описания форматов служебных сообщений протокола BGP.

Формат сообщения OPEN.

Версия (Version) — целое число длиной 1 байт, которое отражает номер версии протокола ВGР, такой как BGP-3 или BGP-4. В течение фазы переговоров с соседями стороны, участвующие в BGP-сеансе, должны согласовать номер версии протокола ВGР. Вначале стороны пытаются "договориться" о наивысшей версии, которую они могут поддерживать. На этом этапе стороны могут сбрасывать сеанс ВGР и проводить повторные переговоры до тех пор, пока не согласуют, по какой версии ВGР будет проводиться сеанс. Для ускорения процесса переговоров компания Cisco Systems ввела специальный параметр, в котором определяется версия протокола. Как правило, номер версии устанавливается статически, когда версии ВGР сторон уже известны, хотя большинство реализаций по умолчанию начинают переговоры с BGP-4.

Автономная система (My autonomous system) — поле размером 2 байта, где указывается номер AS спикера ВGР. Таймер удержания (Hold timer). В поле "Таймер удержания", имеющее в длину 2байта, включаются целые числа, указывающие максимальный интервал времени между приемом сообщений KEEPALIVE и UPDATE. По сути таймер удержания представляет собой счетчик, величина которого увеличиваются от 0 до значения времени удержания. Прием сообщений типа KEEPALIVE или UPDATE сбрасывает таймер в 0. Если время удержания для заданного соседнего узла превышено, делается вывод о недоступности такого узла. Маршрутизатор, поддерживающий работу по ВGР, в фазе переговоров со своим соседом подбирает для него время удержания. Выбор времени удержания между соседними маршрутизаторами производится на основе наименьшего времени удержания. Таймер удержания может быть равным 0, но тогда ни он, ни таймер состояния соединения (KEEPALIVE timer) никогда не будут сбрасываться. Другими словами, оба таймера всегда будут иметь значение 0, следовательно, соединение будет считаться активным. Если таймер не установлен в 0, то по умолчанию минимальное значение времени ожидания для таймера удержания 3 секунды.

Обратите внимание - переговоры с целью определения номера версии (сводящиеся в действительности к повторному установлению сеанса, пока узлы не согласуют номер версии протокола) и для определения начального значения таймера удержания (использование минимального значения одного из двух спикеров ВGР) отличаются коренным образом. В обоих случаях каждому маршрутизатору посылается только сообщение OPEN. Однако при несовпадении значений (в случае таймера удержания) сеанс не прерывается.

Идентификатор BGP (BGP Identifier) представляет собой четырехбайтовое целое число, которое отображает значение идентификатора ВGР узла отправителя. В маршрутизаторах компании Cisco это значение обычно соответствует идентификатору маршрутизатора (Router ID — RID), который вычисляется из наивысшего IP-адреса на маршрутизаторе или из наивысшего адреса обратной петли в начале сеанса ВGР. Адрес обратной петли представляет собой IP-адрес программного виртуального интерфейса, который считается всегда активным, независимо от состояния физического интерфейса на маршрутизаторе.

Длина поля необязательных параметров (Optional Parameter Length — Opt ParmLen). Это однобайтовый целочисленный параметр, который отражает полную длину в байтах поля "Необязательные параметры". Если длина равна 0, то необязательные параметры отсутствуют.

Необязательные параметры (Optional Parameters). Это поле переменной длины, в котором отображается список необязательных параметров, используемых протоколом ВGР при ведении переговоров между соседними узлами. В этом поле могут отображаться параметры <Параметр типа, параметр длины, параметр значения> (<Parameter Type, Parameter Length, Parameter Value>) длиной по одному байту и переменной длины, соответственно. Примером необязательных параметров может служить параметр информации об аутентификации (тип 1), который применяется для аутентификации сторон в сеансе ВGР.

Формат сообщения NOTIFICATION.

Сообщение NOTIFICATION состоит из кода ошибки (1 байт), дополнительного кода ошибки (1 байт) и поля данных переменной длины.

Код ошибки (Error code) определяет тип уведомления об ошибке, а дополнительный код ошибки (Error subcode) предоставляет более детальную информацию о природе ошибки. В поле данных (Data field) содержатся сведения об ошибке, такой как неправильный заголовок, запрещенный номер AS и т.д.

Формат сообщения KEEPALIVE.

Стороны, участвующие в сеансе связи, периодически обмениваются сообщениями типа KEEPALIVE для того, чтобы определить наличие канала связи и возможность достижения по нему удаленного узла. Как уже отмечалось, время удержания определяет максимальный интервал времени между успешным приемом двух сообщений типа KEEPALIVE или UPDATE. Сообщения типа KEEPALIVE посылаются обычно с частотой, меньшей времени, установленного таймером удержания, на основании чего делается вывод о нормальном течении сеанса. Рекомендуемый интервал времени для посылки сообщений KEEPALIVE — 1/3 от значения таймера удержания. Если же таймер удержания установлен в 0, то обмен сообщениями KEEPALIVE не ведется. Как отмечалось ранее, сообщение типа KEEPALIVE представляет собой 19-байтовый заголовок протокола BGP, без каких- либо значений в поле данных. Сообщения этого типа могут подавляться в течение передачи сообщения UPDATE.

Формат сообщения UPDATE.

Основу протокола BGP составляет концепция обновлений маршрутной информации. Обновления маршрутов несут в себе всю необходимую информацию, которая используется в протоколе BGP для построения сети без петель маршрутизации. В сообщение UPDATE, как правило, входят три основных блока:

- информация сетевого уровня о доступности сети (Network Layer ReachabilityInformation —NLRI);

- атрибуты маршрута;

- недостижимые маршруты.

Блок NLRI отображает форму записи IP-префикса маршрута к объявляемой сети. Список атрибутов маршрута позволяет протоколу BGP обнаруживать петли в маршрутизации и придает ему дополнительную гибкость при определении локальных и глобальных правил маршрутизации.

Атрибуты маршрута в ВGР — это набор параметров, используемых для описания маршрутной информации, такой как информация о пути следования, степень предпочтения маршрута, значение переменной NEXT_HOP для маршрута и информация о возможной агрегации.

6.Атрибуты BGP.

Рассмотрим наиболее часто используемые атрибуты BGP.

Атрибут ORIGIN. ORIGIN (тип 1) – обязательный атрибут, указывающий источник информации о маршруте:

0 – IGP (информация о достижимости сети получена от протокола внутренней маршрутизации или введена администратором),

1 – EGP (информация о достижимости сети импортирована из устаревшего протокола EGP),

2 – INCOMPLETE (информация получена другим образом, например, RIP->OSPF->BGP или BGP->OSPF->BGP).

Атрибут ORIGIN вставляется маршрутизатором, который генерирует информацию о маршруте, и при последующем анонсировании маршрута другими маршрутизаторами не изменяется. Атрибут фактически определяет надежность источника информации о маршруте (наиболее надежный ORIGIN=0).

Атрибут AS_PATH. AS_PATH (тип 2) – обязательный атрибут, содержащий список автономных систем, через которые должна пройти дейтаграмма на пути в указанную в маршруте сеть. AS_PATH представляет собой чередование сегментов двух типов: AS_SEQUENCE – упорядоченный список АС, и AS_SET – множество АС (последнее может возникнуть при агрегировании нескольких маршрутов со схожими, но не одинаковыми AS_PATH в один общий маршрут). Каждый BGP-узел при анонсировании маршрута (за исключением IBGP-соединений, т.е.при использовании BGP для передачи маршрутов внутри AS) добавляет в AS_PATH номер своей АС. Возможно (в зависимости от политики) дополнительно добавляются номера других АС.

Атрибут NEXT_HOP. NEXT_HOP (тип 3) – обязательный атрибут, указывающий адрес следующего BGP-маршрутизатора на пути в заявленную; может совпадать или не совпадать с адресом BGP-узла, анонсирующего маршрут. Указанный в NEXT_HOP маршрутизатор должен быть достижим для получателя данного маршрута. При передаче маршрута по IBGP NEXT_HOP не меняется.

Атрибут MULTI_EXIT_DISC. MULTI_EXIT_DISC (тип 4) – необязательный атрибут, представляющий собой приоритет использования объявляющего маршрутизатора для достижения через него анонсируемой сети, то есть фактически это метрика маршрута с точки зрения анонсирующего маршрут BGP-узла. Имеет смысл не само значение, а разница значений, когда несколько маршрутизаторов одной АС объявляют о достижимости через себя одной и той же сети, предоставляя, таким образом, получателям несколько вариантов маршрутов в одну сеть. При прочих равных условиях дейтаграммы в объявляемую сеть будут посылаться через маршрутизатор, заявивший меньшее значение MULTI_EXIT_DISC. Атрибут сохраняется при последующих объявлениях маршрута по IBGP, но не по EBGP.

Атрибут LOCAL_PREF. LOCAL_PREF (тип 5) – необязательный атрибут, устанавливающий для данной АС приоритет данного маршрута среди всех маршрутов к заявленной сети, известных внутри АС. Атрибут вычисляется каждым пограничным маршрутизатором для каждого присланного ему по EBGP маршрута и потом распространяется вместе с этим маршрутом по IBGP в пределах данной АС. Способ вычисления значения атрибута определяется политикой приема маршрутов (по умолчанию берется во внимание только длина AS_PATH). LOCAL_PREF используется для согласованного между маршрутизаторами одной АС выбора маршрута из нескольких вариантов.

Атрибуты агрегирования. ATOMIC_AGGREGATE (тип 6) и AGGREGATOR (тип 7) – необязательные атрибуты, связанные с операциями агрегирования (объединения) нескольких маршрутов в один. Для более детального ознакомления с ними отсылаем читателей к документу RFC-1771.

Атрибут Weight (вес) – данный атрибут не входит в RFC 1771, и введен компанией Cisco для использования в своем оборудовании. Этот атрибут является локальным по отношению к маршрутизатору, он не распространяется на соседние маршрутизаторы. Если маршрутизатор обнаруживает несколько маршрутов к приемнику, то выбирается маршрут с наибольшим весом.

Все эти параметры используются при фильтрации и выборе маршрутов на базе протокола ВGР. Каждое сообщение типа UPDATE включает в себя последовательность атрибутов маршрута переменной длины. Атрибут маршрута имеет три составляющие и записывается в форме <тип атрибута, длина атрибута, значение атрибутах Тип атрибута — это двухбайтовое поле, состоящее из однобайтового флага атрибута и однобайтового кода типа атрибута. На схеме представлен общий вид поля типа атрибутов маршрута:

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

- Первый бит в поле флагов атрибута (бит 0) указывает на то, является ли атрибут общеизвестным (0) или необязательным (1).

- Второй бит (бит 1) указывает, является ли необязательный атрибут нетранзитивным (0) или транзитивным (1). Общеизвестные атрибуты всегда транзитив-ны, так что второй бит всегда установлен в 1.

- Третий бит (бит 2) показывает, является ли информация, содержащаяся в необязательном транзитивном атрибуте, полной (0) или частичной (1).

- В четвертом бите (бит 3) определяется длина атрибута —1 байт (0) или 2 байта (1).

- Младшие биты (с 4 по 7) в поле атрибута флага в настоящее время не используются и всегда установлены в 0.

Обязательные общеизвестные (Well-known mandatory).

Атрибуты, которые обязательно должны присутствовать в пакете UPDATE протокола ВОР. Если отсутствует общеизвестный атрибут, то автоматически генерируется сообщение об ошибке NOTIFICATION и сеанс прекращается. Это указывает на то, что во всех реализациях BGP может использоваться стандартный набор атрибутов. В качестве примера общеизвестного обязательного атрибута можно привести атрибут AS_PATH.

Общеизвестные, предоставленные на собственное усмотрение (Well-known

discretionary).

Эти атрибуты опознаются всеми реализациями BGP, но при этом могут

и не посылаться в сообщении UPDATE протокола BGP. Атрибутом этой категории является атрибут LOCAL_PREF. Кроме общеизвестных атрибутов, маршрут может обладать одним и более необязательными атрибутами. Эти атрибуты необязательно будут поддерживаться всеми реализациями протокола BGP. Необязательные атрибуты могут быть транзитивными и нетранзитивными.

Необязательные транзитивные (Optional transitive).

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

Необязательные нетранзитивные (Optional nontransitive).

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

Байт кода типа атрибута содержит код атрибута. В настоящее время определены следующие атрибуты:

Номер

атрибута

Имя атрибута

Код категории/типа

Соответствующий

RFC/проект

документа

1

ORIGIN

Общеизвестный обязательный

код типа 1

RFC 1771

2

AS_PATH

Общеизвестный обязательный

код типа 2

RFC 1771

3

NEXT_HOP

Общеизвестный обязательный

код типа 3

RFC 1771

4

MULTI_EXIT_DISC

Необязательный нетранзитивный, код типа 4

RFC 1771

5

I_OCAL_PREF

Общеизвестный предоставленный

на собственное усмотрение, код типа 5

RFC 1771

6

ATOMIC_AGGREGATE

Общеизвестный используемый

по усмотрение, кодтипа 6

RFC 1771

7

AGGREGATOR

Необязательный транзитивный, код типа 7

RFC 1771

8

COMMUNITY

Необязательный транзитивный

код типа 8

RFC1997

9

ORIGINATORJD

Необязательный

нетранзитивный, код типа 9

PFC1966

10

Список кластеров

(Cluster List)

Необязательный

нетранзитивный, код типа 10

RFC1966

11

DPA (Destination Point

Атрибут точки назначения для

BGP

Не используется

12

Atribute) Объявитель маршрутов (Advertiser)

Сервер маршрутов BGP/IDRP

документ RFC1863

13

FaD_PATHO-USTTЈRJD

Сервер маршрутов BGP/IDRP

RFC1863

14

NLRI, допускающий работу в

мультипротокольном

режиме (Multiprotocol Reachable NLRI)

Необязательный нетранзитивный, код типа 14

RFC2283

15

NLRI, запрещающий

работу в

мультипротокольном

режиме (Multiprotocol Unreachable NLRI)

Необязательный

нетранзитивный, код типа 15

RFC 2283

16

Дополнительные

сообщества (Extended Communities)

"в стадии

разработки" draft-ramachandra-bgp-ext-communities-

00.txt

256

Зарезервировано

Протокол ВGР с мультипротокольными расширениями (Multiprotocol ВОР — MBGP) иногда также называют BGP-4+ и ошибочно причисляют его к групповому протоколу ВGР (Multicast ВGР). На самом деле протокол ВGР с мультипротокольными расширениями описан в RFC 2283, и его работа организуется на основе возможностей по ведению переговоров, принятых в протоколе BGP. Протокол MBGP обеспечивает обратную совместимость с протоколом BGP-4, что позволяет ему переносить в себе информацию для протоколов сетевого уровня (кроме IPv4), таких как IPv6 и IPX. Кратко рассмотрим основные типы новых атрибутов, а также сферах применения этого протокола.

В порядке поддержки мультипротокольных расширений в протокол BGP-4 было введено два дополнительных атрибута: NLRI, допускающий работу в мультипротокольном режиме (Multiprotocol Reachable NLRI — MP_REACH_NLRI), и NLRI, запрещающий работу в мультипротокольном режиме (Multiprotocol Unreachable NLRI— MP_UNRICH_NLRI). NLRI, допускающий работу в мультипротокольном режиме (MP_REACH_NLRI), является необязательным нетранзитивным атрибутом, который может использоваться для следующих целей:

- Объявление действующих маршрутов соседнему узлу.

- Разрешение маршрутизатору объявлять адреса сетевого уровня следующемуближайшему маршрутизатору, который будет использоваться в качестве промежуточного узла, чтобы достичь пункта назначения, указанного в поле NLRI атрибута МР_ NLRI.

- Разрешение заданному маршрутизатору выдавать отчет о некоторых или обовсех точках подключения подсетей (Subnetwork Points of Attachment — SNPA),которые имеются на локальной системе.

NLRI, запрещающий работу в мультипротокольном режиме (Multiprotocol Unreachable NLRI — MP_UNRICH_NLRI), также представляет собой необязательный нетранзитивный атрибут, который может использоваться для удаления одного или нескольких недействующих маршрутов.

Эти новые атрибуты были введены в действие протоколом MBGP для обеспечения возможности связывания определенного протокола сетевого уровня с информацией о соседнем узле и с NLRI. Адресная информация, описанная в RFC 1700, используется для идентификации протоколов сетевого уровня. Междоменная групповая маршрутизация — наиболее общий случай применения мультипротокольных расширений протокола BGP. Вероятно, в этом и кроется причина того, что иногда ошибочно под MBGP подразумевают Multicast (т.е. групповой) BGP, а не Multiprotocol (мультипротокольный) BGP. При использовании MBGP для работы с группами адресов протокол BGP одновременно передает информацию о двух наборах маршрутов — об уникальных маршрутах и о маршрутах, используемых в групповой маршрутизации. Маршруты для групповой маршрутизации используются затем групповым независимым протоколом (Protocol-Independent Multicast — PIM) для процедур пересылки обратных маршрутов (Reverse Path Forwarding — RPF), с помощью которых осуществлялось построение деревьев распределения данных. До появления MBGP в групповой междоменной маршрутизации использовались обычные системы с однозначными маршрутами, что требовало взаимного соответствия топологий сети для одно- и многоадресной маршрутизации. С появлением протокола MBGP работа с многоадресной междоменной маршрутизацией стала более гибкой, что предоставило новые возможности для управления сетевыми ресурсами.

7.Примеры практического применения протокола BGP

Рассмотрим примеры практического применения протокола BGP для реализации простейших схем взаимодействия маршрутизаторов внутри AS и между несколькими AS. Из приведенного выше материала следует, что BGP является универсальным инструментом управления маршрутной информацией, т.е. область применения данного протокола не ограничивается только за пределами либо только внутри AS. Таким образом существует как бы два варианта использваония данного протокола: eBGP и iBGP.

Если AS содержит несколько BGP маршрутизаторов, то она может использоваться в качестве транзитной системы для других AS.

AS200 является транзитной системой для AS100 и AS300.

В данном случае передача информации между AS100 и AS300 по BGP напрямую невозможна, в соответствии с топологией связей. Для выполнения задачи используется транзитная система - AS200, т.е. передача BGP трафика между граничными маршрутизаторами внутри AS200. Это стало возможным благодаря одновременному использованию внутреннего BGP (iBGP) – для передачи BGP трафика внутри AS, и внешнего BGP (eBGP) – для передачи трафика между маршрутизаторами, лежащими в разных AS. Т.о. если BGP выполняется между маршрутизаторами одной AS – это iBGP. Если же BGP выполняется между маршрутизаторами разных AS - это eBGP.

Для запуска BGP необходимо два маршрутизатора. В предлагаемых примерах это маршрутизатор А , маршрутизатор В и т.д. (RTA, RTB, RTC etc). Конфигурация BGP начинается с указания номера AS к которой принадлежит маршрутизатор.

router bgp autonomous-system

RTA#

router bgp 100

RTB#

router bgp 200

В приведенном выше примере RTA использует BGP и принадлежит к AS100, RTB так же использует BGP и принадлежит AS200.

Следующим шагом конфигурации является объявление соседей, для указания соседних маршрутизаторов, использующих BGP.

Формирование BGP Neighbors.

Два BGP маршрутизатора становятся соседями после установки TCP соединения между собой. После установления TCP соединения маршрутизаторы обмениваются сообщениями содержащими такую информацию как номер AS, версия используемого протокола BGP, BGP ID маршрутизатора и значение временного интервала для обмена сообщениями keepalive. После того как указанные сообщения переданы, подтверждены и согласованы - соединение между соседями считается установленным (established). Любое другое состояние TCP соединения, отличное от «established» указывает, что два маршрутизатора не являются соседями и не могут обмениваться BGP трафиком.

Для установки соединения используется следующая команда

neighbor ip-address remote-as number

number – это номер AS маршрутизатора с которым необходимо установить соединение BGP.

ip-address – это IP адрес в той же сети подключенного напрямую маршрутизатора для eBGP, или любой другой IP адрес маршрутизатора для iBGP независимо от топологии подключения.

Важно, что бы адрес, указываемый в команде neighbour, был достижим. Для подтверждения достижимости используется команда ping с указанием интерфейса источника, который должен использоваться отправки эхо-запроса на IP адрес соседнего BGP маршрутизатора.

В случае изменения конфигурации протокола BGP на маршрутизаторе, обязательна перезагрузка соединения, для применения изменений. Для это используют следующую команду:

clear ip bgp address (где address это адрес соседа )

clear ip bgp * (очищает соединения со всеми соседями)

По умолчанию, сессия BGP начинается с использования версии протокола – BGP 4, процесс переговоров происходит в убывающем порядке, и в случае необходимости версия может быть понижена.

Для запрещения переговоров и жесткого определения номера версии BGP, используемого на маршрутизаторе для взаимодействия с соседом используют следующую команду:

neighbor {ip address|peer-group-name}version value

value – номер версии

Пример использования команды neighbour

RTA#

router bgp 100

neighbor 129.213.1.1 remote-as 200

RTB#

router bgp 200

neighbor 129.213.1.2 remote-as 100

neighbor 175.220.1.2 remote-as 200

RTC#

router bgp 200

neighbor 175.220.212.1 remote-as 200

В приведенном выше примере между маршрутизаторами RTA и RTB используется eBGP. Между RTC и RTB используется iBGP. Разница, между eBGP и iBGP, заключается в объявлении номера AS совпадающего или не совпадающего с номером AS, в которой находится маршрутизатор. Также, при использовании eBGP, маршрутизаторы-соседи подключены напрямую, а в случае использования iBGP топология подключения не принципиальна. Т.е. маршрутизаторы, использующие iBGP, могут не быть подключены напрямую друг к другу, так же как и маршрутизаторы использующие протоколы внутренней маршрутизации – основное требование – возможность взаимодействия на сетевом уровне.

Пример вывода информации при использовании команды show ip bgp neighbors на маршрутизаторе RTA

# show ip bgp neighbors

BGP neighbor is 129.213.1.1, remote AS 200, external link

BGP version 4, remote router ID 175.220.12.1

BGP state = Established, table version = 3, up for 0:10:59

Last read 0:00:29, hold time is 180, keepalive interval is 60 seconds

Minimum time between advertisement runs is 30 seconds

Received 2828 messages, 0 notifications, 0 in queue

Sent 2826 messages, 0 notifications, 0 in queue

Connections established 11; dropped 10

Обратите внимание на состояние связи маршрутизаторов BGP state = Established, любое другое значение указывает на отсутствие взаимодействия между соседями.

Номер версии протокола BGP – 4.

Идентификатор удаленного маршрутизатора (remote router ID) – 175.220.12.1. В этом параметре выводится максимальный по значению IP адрес физического интерфейса соседнего маршрутизатора или максимальный адрес его loopback интерфейса, если таковой присутствует.

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

BGP и loopback интерфейс.

Использование loopback интерфейса для настройки взаимодействия с соседями, в основном, применяется в iBGP и намного реже для eBGP. Обычно, loopback интерфейс используется для взаимодействия с соседним маршрутизатором, независимо от состояния физических интерфейсов, при условии, что хотя бы один физический интерфейс работает и используется маршрутизатором для подключения в сеть. В случае с eBGP – маршрутизаторы, чаще всего, подключены напрямую поэтому конфигурация с loopback интерфейсом не применяется.

Если в команде neighbor вы используете IP адрес loopback интерфейса, то необходимо дополнительно указывать источник обновления для настраиваемого соседнего маршрутизатора.

Маршрутизатор должен указать протоколу BGP, что для установки TCP соединения с соседним маршрутизатором вначале loopback интерфейс. Это выполняется следующей командой:

neighbor ip-address update-source interface

Пример использования loopback интерфейса

RTA#

router bgp 100

neighbor 190.225.11.1 remote-as 100

neighbor 190.225.11.1 update-source loopback 1

RTB#

router bgp 100

neighbor 150.212.1.1 remote-as 100

В приведенном выше примере RTA и RTB используют iBGP внутри AS100. В конфигурации neighbor маршрутизатора RTB используется адрес loopback интерфейса RTA (150.212.1.1) - в этом случае на маршрутизаторе RTA обязательно конфигурируется loopback интерфейс как источник для дальнейшего TCP взаимодействия. Это осуществляется добавлением параметра update-source (neighbor 190.225.11.1 update-source loopback 1), тогда маршрутизатор RTA использует loopback интерфейс при взаимодействии с соседним маршрутизатором по адресу 190.225.11.1.

Обратите внимание, RTA обращается к IP адресу физического интерфейса RTB (190.225.11.1). Поэтому RTB не нуждается в дополнительной конфигурации.

Примеры сценариев конфигурации:

iBGP + Loopback Address

R1-AGS

R6-2500

Current configuration:

!-- Output suppressed.

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 300

neighbor 2.2.2.2 remote-as 300

neighbor 2.2.2.2 update-source Loopback0

!-- This command specifies that the TCP

!-- connection with the specified external

!-- peer should be established using the

!-- address on the loopback interface.

!

ip route 2.2.2.2 255.255.255.255 10.10.10.2

!--- This static route ensures that the

!--- remote peer address used for peering

!--- is reachable.

!-- Output suppressed.

end

Current configuration:

!-- Output suppressed.

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 300

neighbor 1.1.1.1 remote-as 300

neighbor 1.1.1.1 update-source Loopback0

!-- This command specifies that the TCP

!-- connection with the specified external

!-- peer should be established using the

!-- address on the loopback interface.

!

ip route 1.1.1.1 255.255.255.255 10.10.10.1

!-- Output suppressed.

end

eBGP + Loopback Address

R1-AGS

R6-2500

Current configuration:

!-- Output suppressed.

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 300

neighbor 2.2.2.2 remote-as 400

neighbor 2.2.2.2 ebgp-multihop 2

!--- This command changes the ttl value in

!--- order to allow the packet to reach the

!--- external BGP peer which is not directly

!--- connected or is using an interface other

!--- than the directly connected interface.

neighbor 2.2.2.2 update-source Loopback0

!--- This command specifies that the TCP

!--- connection with the external BGP

!--- peer should be established using the

!--- address on the loopback interface.

!

ip route 2.2.2.2 255.255.255.255 10.10.10.2

!--- This static route ensures that the

!--- remote peer address used for peering

!--- is reachable.

!-- Output suppressed.

end

Current configuration:

!-- Output suppressed.

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 1.1.1.1 remote-as 300

neighbor 1.1.1.1 ebgp-multihop 2

neighbor 1.1.1.1 update-source Loopback0

!

ip route 1.1.1.1 255.255.255.255 10.10.10.1

!-- Output suppressed.

end

8.eBGP Multihop.

Возможны ситуации, при которых маршрутизаторы Cisco использующие eBGP подключаются не на прямую, а через маршрутизаторы сторонних производителей. В этом случае, при конфигурации eBGP применяется технология eBGP Multihop, позволяющая осуществлять взаимодействия между инетрфейсами маршрутизаторов не подключенных напрямую друг к другу. Технология Multihop используется только для eBGP и не используется для iBGP.

Пример использования Multihop.

RTA#

router bgp 100

neighbor 180.225.11.1 remote-as 300

neighbor 180.225.11.1 ebgp-multihop

RTB#

router bgp 300

neighbor 129.213.1.2 remote-as 100

Если интерфейс маршрутизатор RTA не имеет прямого подключения к RTB, то в конфигурацию eBGP добавляется параметр ebgp-multihop. Т.к., интерфейс RTB имеет прямое подключение, то дополнительная конфигурация параметра ebgp-multihop не выполняется.

Следующий пример показывает, как распределить трафик при помощи BGP, с использованием двух параллельных линий связи - eBGP Multihop (Load Balancing)

RTA#

int loopback 0

ip address 150.10.1.1 255.255.255.0

router bgp 100

neighbor 160.10.1.1 remote-as 200

neighbor 160.10.1.1 ebgp-multihop

neighbor 160.10.1.1 update-source loopback 0

network 150.10.0.0

ip route 160.10.0.0 255.255.0.0 1.1.1.2

ip route 160.10.0.0 255.255.0.0 2.2.2.2

RTB#

int loopback 0

ip address 160.10.1.1 255.255.255.0

router bgp 200

neighbor 150.10.1.1 remote-as 100

neighbor 150.10.1.1 update-source loopback 0

neighbor 150.10.1.1 ebgp-multihop

network 160.10.0.0

ip route 150.10.0.0 255.255.0.0 1.1.1.1

ip route 150.10.0.0 255.255.0.0 2.2.2.1

В приведенном выше примере используется два loopback интерфейса, параметры update-source и ebgp-multihop. Указанная конфигурация позволяет распределить нагрузку между двумя eBGP интерфейсами через две параллельные линии связи. Обычно, BGP использует одну линию и распределение нагрузки не происходит.

Для перехода в режим распределения нагрузки необходимо на каждом маршрутизаторе выполнить следующие действия:

  1. Добавить loopback интерфейс.
  2. При настройке neighbour указать в качестве параметра IP адрес loopback интерфейса соседнего eBGP маршрутизатора.
  3. При настройке neighbour указать update-source loopback.
  4. При настройке neighbour указать ebgp-multihop
  5. Создать два статических маршрута в таблице маршрутизации для достижения loopback адаптера соседнего eBGP маршрутизатора через каждый из интерфейсов, подключенных параллельно линий. Стоимость параллельных маршрутов должна быть одинакова. Так же указанные записи могут создаваться IGP протоколами.

В результате, маршрутизатор RTA использует два маршрута для достижения соседнего маршрутизатора RTB 160.10.1.1: один - через 1.1.1.2, другой – через 2.2.2.2. Аналогично – для взаимодействия RTB – RTA.

Route Maps (Маршрутные карты).

В BGP маршрутная карта применяется как метод управления маршрутной информацией. Суть метода заключается в определении условий передачи маршрутной информации между различными протоколами маршрутизации и контроля полученных данных на этапе передачи маршрутной информации протоколу BGP. Для определения маршрутной карты используется следующая команда:

route-map map-tag [[permit | deny] | [sequence-number]]

map-tag - имя, идентифицирующее маршрутную карту, назначается произвольно

permit / deny - определяет состояние карты, соответственно разрешена . запрещена

sequence-number - номер правила маршрутной карты.

В протоколе BGP сначала применяются правила с наименьшим sequence-number и далее по возрастающей. Если какое-либо условие выполняется, то производятся действия, определенные для этого условия и просмотр условий прекращается.

Пример определения двух правил маршрутной карты MYMAP. Первое правило номер 10, второе – номер 20.

route-map MYMAP permit 10 (далее указывается первый набор условий и инструкций)

route-map MYMAP permit 20 (далее указывается второй набор условий и инструкций)

После применения карты MYMAP для входящих и исходящих маршрутов вначале проверяются условия из правила 10 и в случае соответствия выполняются инструкции правила 10. Если условия не выполняются, происходит переключение на правило 20 и т.д.

Команды match и set.

Каждая маршрутная карта состоит из набора команд match и set. Match – определяет набор условий, а set – указывает действия, осуществляемые в случае выполнения условий.

Например, определим маршрутную карту, которая проверяет исходящие обновления и если среди них встречается IP адрес 1.1.1.1 то метрика обновлений будет равна 5 :

route-map MYMAP permit 10

match ip address 1.1.1.1

set metric 5

В данном случае, если заданные условия выполняются – возникает событие permit (разрешить). Протокол BGP устанавливает метрику для данной информации равной 5 и пересылает обновление соседнему маршрутизатору, после чего просмотр маршрутной карты заканчивается.

Следующий пример. Определим маршрутную карту, которая проверяет исходящие обновления и если среди них встречается IP адрес 1.1.1.1 то обновлении не передаются:

route-map MYMAP deny 10

match ip address 1.1.1.1

В данном случае, если заданные условия выполняются – возникает событие deny (запретить). Маршрутизатор не пересылает обновление – на этом просмотр маршрутной карты заканчивается.

Из приведенных выше примеров следует, что в случае применения директивы permit анализ происходит по следующей схеме:

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

В случае применения директивы deny, если информация удовлетворила условию, то она отбрасывается.

Если условия описанные правилом 10 не зависимо от директивы (permit / deny) не выполняются, происходит переключение на правило имеющее следующий больший порядковый номер (например, правило 20) и так далее, пока не закончатся все правила входящие в маршрутную карту. Если, достигнут конец списка правил, и не в одном из случаев не произошло выполнение условия то обновление не будет принято и не будет передано.

В операционной системе CiscoIOS с номером версии меньше 11.2 невозможно фильтровать входящие обновления при помощи команды match <IP адрес> - только исходящие. В версии CiscoIOS 11.2 и далее это ограничение устранено, и фильтрации подвергаются как входящие так и исходящие обновления.

Команда match использует следующие операторы

match as-path

match community

match clns

match interface

match ip address

match ip next-hop

match ip route-source

match metric

match route-type

match tag

Команда set использует следующие операторы

set as-path

set clns

set automatic-tag

set community

set interface

set default interface

set ip default next-hop

set level

set local-preference

set metric

set metric-type

set next-hop

set origin

set tag

set weight

Примеры составления маршрутных карт.

Пример 1.

Пусть между RTA и RTB используется протокол RIP, между RTA и RTC используется протокол BGP. Маршрутизатор RTA получает обновления по BGP и передает их протоколу RIP. Если RTA хочет передавать на RTB маршрут 170.10.0.0 с метрикой 2, а все остальные маршруты с метрикой 5, то используется следующая конфигурация:

RTA#

router rip

network 3.0.0.0

network 2.0.0.0

network 150.10.0.0

passive-interface Serial0

redistribute bgp 100 route-map SETMETRIC

router bgp 100

neighbor 2.2.2.3 remote-as 300

network 150.10.0.0

route-map SETMETRIC permit 10

match ip-address 1

set metric 2

route-map SETMETRIC permit 20

set metric 5

access-list 1 permit 170.10.0.0 0.0.255.255

В приведенном выше примере, если маршрутизатор идентифицирует в принятом обновлении значение 170.10.0.0, то выполняется правило 10: обновление передается с метрикой 2 и просмотр маршрутной карты завершается. Иначе выполняется правило 20: обновление передается с метрикой 5 и просмотр маршрутной карты так же завершается.

Пример 2.

Допустим, в приведенной выше схеме необходимо запретить передавать маршрут 170.10.0.0 в AS100. Т.к. маршрутная карта не используется для входящих обновлений, используем условия для исходящих обновлений. Тогда, конфигурация имеет вид:

RTC#

router bgp 300

network 170.10.0.0

neighbor 2.2.2.2 remote-as 100

neighbor 2.2.2.2 route-map STOPUPDATES out

route-map STOPUPDATES permit 10

match ip address 1

access-list 1 deny 170.10.0.0 0.0.255.255

access-list 1 permit 0.0.0.0 255.255.255.255

Далее рассмотрим способы объявления сетевых маршрутов и дополнительной информации по объявляемым маршрутам.

Команда network. Формат команды network:

network network-number [mask network-mask]

network-number - номер объявляемой сети

network-mask - маска объявляемой сети

Команда используется для сообщения протоколу BGP информации о том, какую сеть и маску сети нужно объявлять соседним маршрутизаторам. Такая операция называется анонсирование (объявление) сети.

Команда network выполняется, только, если объявляемая сеть известна маршрутизатору. Т.е. объявляемая сеть может быть известна по следующим причинам:

-является подключенной сетью;

-запись об объявляемой сети присутствует в таблице маршрутизации в виде статического маршрута;

-запись об объявляемой сети появилась в таблице маршрутизации динамически;

Пример командs network:

RTA#

router bgp 1

network 192.213.0.0 mask 255.255.0.0

ip route 192.213.0.0 255.255.0.0 null 0

В приведенном выше примере маршрутизатор RTA объявляет суперсеть класса С 192.213.0.0. Для того, что бы объявление применилось, в таблицу маршрутизации добавляется соответствующая запись.

Команда network представляет первый способ объявления своей сети через BGP, второй способ заключается в объявлении внутреннего маршрута на основе информации протоколов внутридоменной маршрутизации, например IGRP, EIGRP, OSPF или RIP. Подобная передача маршрутной информации должна производится крайне осторожно, т.к. возможна ситуация, при которой через BGP во внешнюю сеть будут объявлены маршруты, которые изначально были получены по средствам того же BGP, что приведет к увеличению трафика и быстрому росту версий таблиц маршрутизации. Для предотвращения подобных ситуаций использую фильтры, позволяющие передавать только те номера маршрутов, которые удовлетворяют политике взаимодействия с соседними AS.

Например:

RTA объявляет маршрут 129.13.1.0, а RTC объявляет маршрут 175.220.0.0. Рассмотрим конфигурацию RTC. При использовании команды network конфигурация имеет вид:

RTC#

router eigrp 10

network 175.220.0.0

redistribute bgp 200

default-metric 1000 100 250 100 1500

router bgp 200

neighbor 1.1.1.1 remote-as 300

network 175.220.0.0 mask 255.255.0.0

При использовании информации протоколов внутридоменной маршрутизации, например EIGRP, конфигурация имеет вид

RTC#

router eigrp 10

network 175.220.0.0

redistribute bgp 200

default-metric 1000 100 250 100 1500

router bgp 200

neighbor 1.1.1.1 remote-as 300

redistribute eigrp 10

В данном случае, протокол EIGRP имеет информацию о маршруте в сеть 129.213.1.0, как результат предыдущего взаимодействия с протоколом BGP.Таким образом, возможна ситуация, при которой протокол EIGRP сообщит BGP указанный маршрут (129.213.1.0) для объявления маршрутизатору RTB – подобное явления считается недопустимым, т.к. AS200 не является источником маршрута 129.213.1.0. Для предотвращения описанной ситуации, в конфигурацию маршрутизатора RTC вносится дополнение в виде фильтра, конфигурация имеет вид:

RTC#

router eigrp 10

network 175.220.0.0

redistribute bgp 200

default-metric 1000 100 250 100 1500

router bgp 200

neighbor 1.1.1.1 remote-as 300

neighbor 1.1.1.1 distribute-list 1 out

redistribute eigrp 10

access-list 1 permit 175.220.0.0 0.0.255.255

Команда access-list контролирует маршруты, объявляемые из AS200. В данном случае разрешается объявление только 175.220.0.0 /16. Однако не всегда возможно так просто передать информацию внутренних протоколов для объявления через BGP, в случае протокола OSPF необходимо дополнительно конфигурировать маршруты как internal Или external при настройке протокола OSPF, и только потом приступать к конфигурации взаимодействия BGP-OSPF.

Так же, существуют конфигурации в которых, протокол BGP использует информацию статических таблиц маршрутизации. Например:

RTC#

router eigrp 10

network 175.220.0.0

redistribute bgp 200

default-metric 1000 100 250 100 1500

router bgp 200

neighbor 1.1.1.1 remote-as 300

redistribute static

...

ip route 175.220.0.0 255.255.255.0 null0

....

Интерфейс null0, указывает на передачу пакета «по ситуации». В данном случае, если маршрутизатор получает пакет, и при этом в таблице маршрутизации существует маршрут в большей мере (более полно) отвечающий адресу получателя, указанному в пакете, тогда пакет обрабатывается в соответствии с этой маршрутной записью. Обычно такой метод используется, при объявлении суперсетей.

Далее рассмотрим пример явного указания объявляемых внутренних маршрутов для использования в BGP.

RTA#

router bgp 100

neighbor 150.10.20.2 remote-as 300

network 150.10.0.0

RTB#

router bgp 200

neighbor 160.10.20.2 remote-as 300

network 160.10.0.0

RTC#

router bgp 300

neighbor 150.10.20.1 remote-as 100

neighbor 160.10.20.1 remote-as 200

network 170.10.00

В данной конфигурации протокол BGP будет объявлять соседям вначале только явно указанные командой network маршруты. Т.е. в результате взаимодействия RTC будет знать о маршрутах 150.10.0.0 и 160.10.0.0, а маршрутизатор RTA – только о маршруте 170.10.0, как и маршрутизатор RTB – только о маршруте 170.10.0.0.

Важно понимать, что протокол BGP не принимает объявления, рожденные в его собственной AS. Это делается для предотвращения образования маршрутных петель. Например, предположим что AS200, из приведенного выше примера имеет прямое BGP подключение к AS100. RTA генерирует маршрутное объявление 150.10.0.0 и посылает его в адрес маршрутизатора RTC, расположенного в AS300. RTC передает этот маршрут в AS200, при этом сохраняя значение атрибута ORIGIN соответствующее AS100. RTB передает маршрут 150.10.0.0 в AS100. RTA анализирует значение атрибута ORIGIN в полученном объявлении, и понимает что это его собственное объявление, после чего принятый пакет сбрасывается, а сообщаемый маршрут не применяется.

Однако, если бы маршрутизатор RTC создал объявление маршрута 150.10.0.0 от своего имени, тогда дальнейшая судьба данного объявления при достижении RTA, зависела бы от принятой политики этого маршрутизатора, описывающей взаимодействия с внешними маршрутизаторами. Т.е. маршрут мог быть принят либо сброшен.

При использовании варианта iBGP, существует ряд преимуществ по сравнению с конфигурацией eBGP+внутренние протоколы машрутизации. Например, iBGP позволяет выделять оптимальную точку выхода из AS (маршрут во внешнюю сеть), используя преимущества локальных маршрутов, сообщаемые в пакетах объявлений дополнительно.

Рассмотрим пример:

RTA#

router bgp 100

neighbor 190.10.50.1 remote-as 100

neighbor 170.10.20.2 remote-as 300

network 150.10.0.0

RTB#

router bgp 100

neighbor 150.10.30.1 remote-as 100

neighbor 175.10.40.1 remote-as 400

network 190.10.50.0

RTC#

router bgp 400

neighbor 175.10.40.2 remote-as 100

network 175.10.0.0

Если BGP спикер принимает объявление от маршрутизаторов расположенных в своей AS (iBGP), то этот маршрутизатор не передает данное объявление дальше в свою AS. Передача принятого таким образом маршрутного объявления, осуществляется только за пределы AS.

На приведенной выше схеме маршрутизаторы RTA и RTB работают в режиме iBGP, RTA и RTD также работают в режиме iBGP. Объявления BGP переданные от маршрутизатора RTB маршрутизатору RTA передаются далее за пределы AS – маршрутизатору RTE. Объявление не передается на маршрутизатор RTD, так как данный маршрутизатор находится внутри AS, в которой находятся маршрутизаторы RTA и RTB. Что бы изменить существующую схему раздачи объявлений, и дать возможность RTB так же объявлять маршрут от RTB, необходимо настроить прямое взаимодействие между маршрутизаторами RTB и RTD.

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

9.Заключение

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

10. Список используемой литературы

  1. https://ru.wikipedia.org
  2. Д.М. Чистова, К.Р. Казарьяна «Интернет в России. Состояние, тенденции и перспективы развития», Москва, 2011 год.
  3. Журнал студРИНГ №12 январь 2011 год.
  4. Леонтьев В.А. – «Новейшая энциклопедия интернета 2008» - ОЛМА-ПРЕСС Образование 2008г.
  5. Симонович С. Евсеев Г. Новейший самоучитель по работе в Internet. М.: изд. «ДЕСС КОМ», 2011.
  6. Шафрин Ю.А. Информационные технологии. М.: изд. ЛБЗ, 2010 год.
  7. Internet в группах (технологии Intranet). К. Терлекчиев, "LAN Magazine/Русское Издание"2012 год.