69577

BGP

Практическая работа

Информатика, кибернетика и программирование

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

Русский

2014-10-07

617.5 KB

4 чел.

BGP

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

Как известно, сеть 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. Сеть NSFNET представляла собой объединение нескольких региональных компьютерных сетей и сетей правительственных организаций (таких как NASA Science Network), которые подключались к опорной сети, составляющей ядро всей NSFNET. Первоначально (1986 год) в NSFNET была создана трехуровневая сетевая архитектура. Она предполагала подключение университетских городков и исследовательских центров к региональным сетям, которые, в свою очередь, подключались к опорной сети, поддерживаемой шестью общенациональными суперкомпьютерными центрами. В 1988 году существующие каналы передачи данных, работа по которым велась со скоростью 56 Кбит/с, были расширены до более быстрых каналов типа Т1 (1,544 Мбит/с). Все эти изменения стали возможными благодаря тендеру на модернизацию и обслуживание сети, объявленному NSF, в котором победила корпорация Merit Network, Inc. И ее партнеры — компании MCI, IBM и администрация штата Мичиган. Таким образом, опорная сеть NSFNET на базе каналов передачи данных Т1 объединила 13 узлов по всем Соединенным Штатам Америки — Merit, BARNET, MidNet, Westnet, NorthWestNet, SESQUINET, SURAnet, узел Национального центра исследований атмосферы (National Center for Atmospheric Research —NCAR) и шесть вычислительных центров самого NSF.

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

К 1991 году трафик сети возрос настолько, что понадобилось срочно расширять пропускную способность магистральных каналов опорной сети до каналов ТЗ (45 Мбит/с). В начале 90-х годов сеть NSFNET по-прежнему использовалась в исследовательских и образовательных целях. Все магистральные каналы передачи данных были зарезервированы правительственными агентствами для стратегических целей. Вместе с тем, ощущалась острая потребность в подключении все большего числа организаций (как правительственных, так и коммерческих). Коммерческие и общенациональные интересы в наращивании сети совпадали, и Internet-сервис провайдеры (Internet Service Provider — ISP) вынуждены были срочно объединить усилия для реализации постаdленной задачи, это привело к формированию абсолютно новой индустрии – коммерческим информационным сетям. Компьютерные сети вне США развивались по мере развития международной сети каналов передачи данных. Наравне с создаваемыми и существующими объектами в рамках государств и регионов росла инфраструктура всемирной глобальной сети. В США сети правительственных агентств объединялись между собой с помощью федеральных точек обмена трафиком (Federal Internet eXchange points — FIX), соединявших Восток и Запад страны. Сети коммерческих организаций сформировали собственные точки обмена трафиком (Commercial Internet eXchange points — CIX), которые объединили весь Запад США. В то же время провайдеры Internet по всему миру, в частности в Европе и Азии, разработали и подготовили инфраструктуру мировой глобальной сети, объединив магистральные каналы передачи данных между собой.

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

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

Провайдеры, у которых имеются точки присутствия в большинстве регионов страны, считаются национальными провайдерами (national provider). Провайдеры, которые обслуживают определенный регион, называются региональными провайдерами (regional provider). Такие провайдеры соединяются друг с другом через одну или несколько точек обмена трафиком. Клиенты, подключенные к одному провайдеру могут общаться по сети с клиентами другого провайдера благодаря точкам доступа к сети (Network Access Points -- NAP) или через непосредственное сетевое соединение между двумя провайдерами. Термин сервис-провайдер Internet (Internet Service Provider —ISP) обычно используется применительно к компании, обеспечивающей подключение к сети Internet других провайдеров либо конечных пользователей. Термин сетевой сервис-провайдер (Network Service ProviderNSP) традиционно относится лишь к провайдерам, обеспечивающим  подключение к опорной сети передачи данных. Однако сегодня термин NSP все чаще употребляется в связи с провайдером, представленным в NAP и обслуживающем опорную сеть.

Фонд NSF с 1986 года финансировал исследования в области передачи данных к разработки компьютерных сетей. Кроме того, Фондом финансировалась Программа высокопроизводительных вычислений и передачи данных (High Performance Computing and Communications Program — HPCC), которая включала целый ряд передовых научно-исследовательских программ. Одним из проектов в рамках программы развития национальной исследовательской и образовательной сети (National Research and Education Network — NREN) был проект создания к середине 90-х годов сети с пропускной способностью до 1 Гбит/с. Все это, вместе с истечением срока действия в апреле 1995 года Соглашения о сотрудничестве с NSFNET Backbone Network Services, стало причиной появления, так называемых, ходатайств NSF о сохранении услуг сети NSFNET.

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

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

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

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

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

Ходатайство о создании точек доступа к сети (Network Access Points — NAP) было направлено на реализацию предложений, поступивших от некоторых компаний, по учреждению специальных узлов в сети — NAP, где осуществлялись бы межсетевые соединения в рамках vBNS или других сетей. В этих NAP требовалось обеспечить возможность обмена трафиком между региональными сетями, сетями сервис-провайдеров, а также исследовательскими и образовательными центрами по всей Америке. Такого рода точки доступа к сети нужны были для формирования соединений между сетями, которые не были субъектами «Свода правил применения сети NSF» (NSF Acceptable Usage Policy), ограничившего использование сети Internet только исследовательскими и образовательными целями. Таким образом, использование сети в коммерческих или каких-либо других целях, не соответствующих этому своду правил, автоматически пресекалось на уровне точек доступа к сети.

Согласно терминологии NSF, точка доступа к сети (NAP) — это высокоскоростной коммутатор или сеть коммутаторов, к которой подключается определенное число маршрутизаторов для обмена трафиком. Любая NAP должна работать со скоростью не ниже 100 Мбит/с и иметь возможность повышения пропускной способности по запросу или в зависимости от нагрузки. Работа каждой NAP при передаче трафика от одного провайдера другому должна быть так же прозрачна и проста, как работа АТМ-коммутатора (45+ Мбит/с) или коммутатора FDDI (100 Мбит/с). Концепция построения NAP основана на применении точек обмена трафиком FIX и CIX (о них далее), которые были созданы в свое время вокруг магистральных колец FDDI для подключения сетей на скоростях до 45 Мбит/с. Трафик через NAP уже не имеет ограничений со стороны Свода правил, т.е. это может быть не только информация в интересах образовательных или исследовательских учреждений. Все сети при подключении к 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.

Сети при подключении к NAP должны были иметь пропускную способность, соразмерную с подключенными ранее сетями (т.е. не менее 1,5 Мбит/с), и возможность повышения пропускной способности по запросу, в зависимости от нагрузки или целей применения. Назначенные NSF точки NAP должны были обеспечивать коммутацию не только пакетов протокола IP, но и сетевого протокола без установки соединения CLNP (Connectionless Networking Protocol). Необходимость коммутации CLNP-пакетов и реализации процедур, предусмотренных протоколом междоменной маршрутизации IDRP (Inter-Domain Routing Protocol) и протоколом внешнего шлюза (ISO OSI Exterior Gateway Protocol— EGP), могла быть обусловлена общим уровнем сервиса, предоставляемого на той или иной NAP.

Для каждой NAP назначалось ответственное лицо — менеджер NAP. В его обязанности входило:

- Развертывание и обслуживание NAP при подключении ее к vBNS и другим сетям.

- Установка правил работы и цен на услуги, предоставляемые сервис-провайдерам при подключении к NAP.

- Подача предложений о развертывании NAP в зависимости от географических особенностей местности.

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

- Разработка стандартов по надежности и безопасности работы NAP, а также процедур, с помощью которых можно было бы определить степень соответствия NAP этим стандартам.

- Обеспечение ведения учета трафика в NAP и сбора статистики для последующего анализа состояния NAP.

- Определение соответствующих процедур по ограничению доступа персонала на узлы NAP и контролю, за их выполнением.

В переходный период от сети ARPANET к NSFNET были созданы восточная FIXEast (Колледж-Парк, штат Мериленд) и западная FIX-West (NASA AMES, Маунтин Вью, штат Калифорния) федеральные точки обмена трафиком (Federal Internet eXchange — FIX). Вскоре они стали стратегически важными узлами, через которые велся обмен информацией между сетями исследовательских центров, университетов и государственных учреждений. Однако правила работы данных точек не позволяли вести обмен данными коммерческого характера. Вследствие чего стали появляться коммерческие точки обмена трафиком — Commercial Internet eXchange points (CIX). В 1996 году была прекращена работа точки FIX-East. Вторая федеральная точка обмена трафиком — FIX-West — до сих пор используется в интересах федеральных служб США.

Коммерческие точки обмена трафиком (Commercial Internet eXchange — CIX (произносится "кикс")добровольные объединения сервис-провайдеров, способствующие развитию инфраструктуры межсетевых соединений, как в масштабах одного государства, так и во всем мире. Создание CIX явилось прямым следствием нежелания операторов федеральных точек обмена трафиком FIX поддерживать сети, которые не являются государственными. Кроме обеспечения межсетевых соединений в интересах коммерческих провайдеров, CIX также стали своего рода форумами, где специалисты могут обмениваться новыми идеями, свежей информацией и проводить эксперименты совместно с другими поставщиками услуг сети. Ниже приведено лишь несколько преимуществ, которыми обладают члены CIX:

- В основу соглашения об использовании СIX положен принцип добровольного объединения сетей. Здесь не существует ограничений по типу трафика, которым члены CIX могут вести обмен друг с другом.

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

Несмотря на то что сегодня CIX в сети Internet играют менее важную роль в объединении сетей, чем NAP, они все же остаются важным звеном в обеспечении физического соединения различных вычислительных сетей, в координации законотворчества для глобальной сети и при разработке правил объединения сетей. Дополнительную информацию о CIX можно получить на Web-сервере www.cix.org.

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

Смысл прямых межсетевых соединений достаточно прозрачен. Обеспечивая соединение сетей напрямую, и одновременно избегая NAP, провайдеры Internet могут уменьшить их значимость для сети в целом и увеличить при этом надежность сетевых соединений со значительным повышением уровня масштабируемости узлов сети. Ширина полосы пропускания и местоположение прямых соединений обсуждаются в двустороннем порядке на взаимовыгодных условиях. К тому же прямые межсетевые соединения, как правило, поддерживаются между двумя сетями пока одна или обе стороны с экономической точки зрения заинтересованы в их работе. Однако следует помнить о том, что прямые межсетевые соединения обеспечивают не только дополнительную полосу пропускания между двумя сетями. Они также смягчают нагрузку на NAP — освобождают на них полосу пропускания, увеличивая, таким образом, пропускную способность и производительность последних. Также в связи с тем, что ведущие компании на рынке обладают, как правило, крупными сетями с похожей топологией, это сходство топологий и требований к узлам сети позволяет с помощью прямых межсетевых соединений производить более рациональное географически распределение потоков данных, чем при использовании NAP. Прямые соединения обеспечивают оптимальный обмен трафиком между региональными сетями, увеличивая вместе с тем пропускную способность сети и снижая время задержки для заданного набора хостов. Более мелкие провайдеры не стремятся к установлению прямых межсетевых соединений с крупными провайдерами по следующим причинам:

- Высокие затраты со стороны провайдеров на поддержку существующей инфраструктуры прямых соединений.

- Рост затрат, связанных с обслуживанием служебных помещений для локальных и межузловых пунктов обмена трафиком — LEG (local exchange carriers) и IXC (interexchange carriers).

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

Еще один проект, инициированный Национальным научным фондом NSF — проект арбитража маршрутизации (Routing Arbiter — RA project). Данный проект был направлен на обеспечение равноправного обслуживания провайдеров со стороны органов администрирования и управления маршрутизацией. Провайдеры, участвующие в проекте RA, создали общую базу данных маршрутной информации в целях повышения стабильности и управляемости сетей, объединенных в Internet.

С ростом количества провайдеров, подключенных к 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 InstituteUSC ISI), компании Cisco Systems (как субподрядчика ISI) и Университета штата Мичиган (University of Michigan ROC) (с компанией Merit в качестве субподрядчика).

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

- Сервер маршрутов (Route Server — RS) — В качестве RS может выступать рабочая станция Sun, установленная на каждой NAP. Сервер маршрутов обменивается с маршрутизаторами провайдеров, установленными в NAP, только информацией о маршрутах. Кроме того, он может отвечать за соблюдение заданных правил маршрутизации для каждого конкретного провайдера (RIPE 181). Сам по себе сервер маршрутов не пересылает пакеты и не выполняет какую-либо коммутацию между сервис-провайдерами. Сервер маршрутов всего лишь облегчает взаимодействие провайдеров путем сбора информации о маршрутах от каждого провайдера и ее последующего оптимального распределения среди провайдеров. Таким образом, устраняется необходимость в организации среди провайдеров соединений типа "каждый с каждым", и сокращается общее число узлов с (n-1) до 1, где п — количество необходимых маршрутизаторов. При такой конфигурации маршрутизаторы провайдеров заняты исключительно коммутацией трафика от одного провайдера к другому и практически не участвуют в фильтрации пакетов и соблюдении правил маршрутизации (эта задача перекладывается на серверы маршрутов).

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

- База данных арбитража маршрутизации (Routing Arbiter Database — RADB) — Эта база данных является одной из нескольких баз данных маршрутов, известных как регистр маршрутов сети Internet (Internet Routing RegistryIRR). Правила маршрутизации в RADB выражаются с помощью синтаксиса, описанного в документе RIPE-181, который был разработан координационным центром сети RIPE (RIPE Network Coordination Center — RCC). Совместно с RADB была разработана и база данных правил маршрутизации Policy Routing Database (PRDB). База данных PRDB с 1986 года использовалась для конфигурирования магистральных маршрутизаторов в сети NSFNET. В 1995 году, с вводом в действие определенных в RIPE-181 терминологии и процедур, которые при соблюдении глобальных правил маршрутизации обеспечивали лучшую функциональность, эта база данных прекратила свое существование, а все ее функции были переданы базе RADB.

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

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

Итак, основными частями концепции арбитража маршрутов являются серверы маршрутов и RADB. Практическими и административными целями RADB является оказание содействия при подключении провайдеров к NAP. Внесение правильной информации в RADB является существенным при избрании определенного набора правил маршрутизации. В настоящее время большинство IRR постепенно переходят на новую спецификацию правил — так называемый язык спецификации правил маршрутизации — Routing Policy Specification Language (RPSL). RPSL представляет собой новое поколение языка описания правил маршрутизации в IRR. Он был разработан подразделением Routing Policy Specification (RPS) Working Group, входящим в инженерную группу Internet Engineering Task Force (IETF)8. Позднее он был утвержден в качестве стандарта в RFC 2622 с пояснениями, вышедшими в RFC 2650, под руководством USC ISI.

Для перехода от RIPE-181 к RPSL имеется несколько объективных причин. В RPSL включены улучшенные механизмы для масштабирования правил маршрутизации и алгоритмы аутентификации, которые позволяют обеспечить целостность адресной и другой информации между операторами сети.

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

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

В марте 1998 года компания Merit успешно завершила реализацию проекта арбитража маршрутизации. Сегодня компания Merit и ее партнер по проекту RA —Институт информационных технологий при Южнокалифорнийском университете продолжают проводить исследования в рамках проекта RA. Следуя рекомендациям NSF, компания Merit совместно с ISI выполнила комплекс работ по переходу с серверов маршрутов проекта RA на сервер маршрутов следующего поколения — Route Server Next Generation (RSng), согласно которому предполагалось предоставлять услуги сервера маршрутов компании Merit на коммерческой основе путем покупки операторами услуг серверов друг друга. Все операции в NAP также были подвергнуты коммерциализации с учетом того, что они преследуют цель создания на рынке провайдеров Internet равных условий для ведения бизнеса.

В 1997 году компания Merit при финансовой поддержке NSF начала работу над проектом анализа и измерения производительности в Internet — Internet Performance Measurement and Analysis (IPMA). Основное назначение IPMA — изучение производительности сетей и сетевых протоколов путем сбора и анализа статистики о маршрутах и производительности в сетях с целью повышения стабильности работы в сети Internet. Кроме того, в рамках IPMA предполагается разработать средства, которые бы облегчили функционирование сети и некоторые инженерные процедуры. Североамериканская группа операторов сети North American Network Operators Group (NANOG) была основана NSF с первых дней работы NSFNET и проекта RA. Работа в этой группе началась с региональных технических семинаров, проходивших для персонала, который занимался обслуживанием сети NSFNET. Сегодня она финансируется от регистрационных взносов, собираемых на проведение конференций, которые организует компания Merit. Группа NANOG предоставляет открытый форум для обсуждения технических вопросов, связанных с функционированием сетей в Северной Америке. В настоящее время базы данных и другие инструменты, созданные в процессе работы над проектами RADB широко используются провайдерами Internet и стали сегодня неотъемлемой частью сети Internet.

Проекты, подобные проекту арбитража маршрутов, представляют собой яркий пример для понимания архитектуры сети Internet.

Следующим проектом, предложенным для оптимизации работы глобальной составной сети, стал проект vBNS. Проект организации высокоскоростной магистральной сетевой службы (very highspeed Backbone Network Service — vBNS) был призван обеспечить специализированную магистральную службу для пользователей с высокопроизводительными компьютерными системами в государственных суперкомпьютерных центрах (Supercomputer Centers —SCC). 24 апреля 1995 года компании MCI и NSF объявили о начале работы службы vBNS. Компания MCI обязалась обеспечить:

-    монтаж и обслуживание транзитной сети с пропускной способностью от 155 Мбит/с и выше, которая бы коммутировала IP и CLNP и объединяла все NAP, финансируемые NSFNET;

- установку и определение метрики сети для мониторинга производительности сети;

-     описание наборов правил для менеджеров NAP и RA;

-     сервисы мультимедиа;

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

Согласно контракту стоимостью 50 миллионов долларов, заключенному на 5 лет, компания MCI и NSFNET обязались связать воедино пять основных высокопроизводительных коммуникационных центров, принадлежащих NSF:

-   Центр теории имени Корнелла (Cornell Theory Center — СТС) в Итаке (штат Нью- Йорк);

- Национальный центр исследований атмосферы (National Center for Atmospheric Research —NCAR) в Боулдере (штат Колорадо);

-  Национальный центр по применению суперкомпьютеров (National Center for SuperComputing Applications —NCSA) при университете штата Иллинойс;

- Питгсбургский суперкомпьютерный центр (Pittsburg SuperComputing Center—PSC):

-  Суперкомпьютерный центр в Сан-Диего (San Diego Supercomputer Center—SDSC).

Служба vBNS создавалась как своего рода исследовательская лаборатория XXI века. Применение новейших технологий коммутации и оптоволоконных линий связи, режима асинхронной передачи (Asyncronous Transfer Mode — ATM) и создание синхронной оптической сети (Syncronous Optical Network — SONET) позволило обеспечить одновременную передачу с высокой скоростью голосовых и видеосигналов, чувствительных к задержкам. С разрешения NSF служба vBNS используется для высокоемких приложений, требующих большой полосы пропускания (например, суперкомпьютерное моделирование обледенения самолетов в NCAR).

Ввиду комплексных исследований в области QoS и управления трафиком в настоящее время за службой vBNS закрепился термин сверхвысокопроизводительная магистральная сетевая служба (very high-performance Backbone Network Service). Таким образом, vBNS продолжает традиции, заложенные сетью NSFNET.

В ходатайство о переходе на новую архитектуру сети Internet NSF включил раздел, в котором региональные сети (также именуемые сетями среднего уровня (mid-level networks)) должны были обеспечить соединение магистральных каналов NSFNET с другими провайдерами. С момента создания NSFNET основную роль в сетях образовательных и научно-исследовательских центров играли региональные сети. Провайдеры региональных сетей (Regional Network Provider — RNP) подключали к сети клиентов лишь на основе их принадлежности к определенным организациям (например, университеты), обеспечивая при этом широкий спектр сетевых услуг для них и поддержку межрегиональных соединений (Inter-Regional Connectivity —IRC).

Ниже приведены оговоренные в NSF 93-52 обязанности RNP.

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

-Обеспечить снабжение организаций-клиентов новейшими сетевыми информационными службами совместно с InterNIC и менеджером информационных служб NSFNET (NSFNET Information Services Manager).

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

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

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

-Обслуживание сетевых соединений организаций — участников сети.

В процессе выделения региональных сетей из сети NSFNET и формирования новых соединений между ISP, NSF предложил подключать их либо напрямую к NAP, либо через провайдеров, уже подключенных к NAP. На переходный период NSF определил цены на организацию соединений, которые в течение 1 года должны были постепенно снижаться до нуля (по истечении первого срока соглашения о Сотрудничестве между менеджерами NAP и RA (NAP Manager/RA Cooperative Agreement), т.е. четырех лет).

Работы, проводимые NSF по изучению приоритетов развития Internet, показали, что наиболее критичным компонентом в разветвленной стихийно развивающейся сети являются информационные сетевые службы. Как результат появился документ об учреждении в сети NSFNET сетевой информационной службы (Network Information Services — NIS). В этом документе содержались следующие предложения.

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

- Обеспечить регистрацию в сетях невоенного назначения, входящих в Internet. В военных же сетях, регистрацию будет продолжать Сетевой информационный центр Агентства оборонных информационных систем (Defense Information Systems Agency Network Information CenterDISA NIC).

Ко времени выхода документа невоенную часть сети Internet составляли NSFNET и другие сети, финансируемые федеральным правительством США, например научная сеть Национального агентства аэрокосмических исследований (NASA Science Internet — NSI) и научная сеть Министерства энергетики США (Energy Sciences Network — ESnet). Поддержание и развитие этих сетей вместе с несколькими другими сетями, входящими в Internet, были включены в бюджет США 1992 года как Национальная исследовательская и образовательная сеть (National Research and Education NetworkNREN).

Ко времени подачи NSF ходатайства, многие провайдеры уже предлагали в той или иной форме услуги сетевых информационных служб (Network Information Services — NIS).

Ниже приведены некоторые из них.

- Информационная служба для конечных пользователей, обеспечиваемая Центром сетевых услуг NSF (NSF Network Services CenterNNSC). Услуги этой службы предоставляла компания Bolt, Beranek and Newman (BBN). Другие пользовательские службы NSFNET, организованные в университетских городках и организациях, занимающихся обеспечением работоспособности сети.

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

- Услуги регистрации в сети Internet предоставлялись центром DISA NIC, который работал под управлением специально созданной государственной компании Government Services, Inc. (GSI).

- Информационные услуги на уровне провайдеров в университетских городках предоставлялись сетевыми структурами NSFNET среднего уровня.

Согласно новому ходатайству, менеджеры NIS должны были обеспечить предоставление информационных услуг конечным пользователям, провайдерам университетских городков и провайдерам среднего уровня. Кроме того, они должны взаимодействовать с другими сетевыми организациями, такими как Merit, Inc.

В январе 1993 года в качестве совместного проекта, инициированного компаниями AT&T, General Atomics и Network Solutions, Inc11, был создан Международный сетевой информационный центр (International Network Information Center — InterNIC). Его работа обеспечивалась тремя двусторонними соглашениями сроком на пять лет, заключенными инициаторами проекта с NSF. Однако на втором году действия соглашений NSF прекратил финансирование General Atomics. Компания AT&T стала полностью вести службы каталогов и баз данных (Database and Directory Services), а на долю Network Solutions выпало обслуживание службы регистрации и поддержки сетевого информационного центра (Registration and NIC Support Services).

Менеджер NIS был обязан действовать в соответствии с RFC 1174, где говорилось следующее:

Для определения и назначения различных цифровых идентификаторов в сети

Internet учреждается центральный орган — Организация по распределению цифровых адресов в сети Internet (Internet Assigned Numbers Authority IANA12). Функции IANA выполняются Институтом информационных технологий при Южнокалифорнийском университете (University of California's Information Sciences Institute). Организации IANA принадлежат исключительные права по делегированию ответственности за блоки IP- адресов и номера автономных систем, выделяемых организациям, на правах Реестра сети Internet (Internet Registry—IR).

Таким образом, менеджер NIS становился либо регистратором IR, либо делегировал это право с разрешения IR кому-либо другому. К вопросам, находящимся в ведении служб регистрации в сети Internet, относились:

• назначение сетевых адресов;

• назначение номеров автономных систем;

• регистрация доменных имен;

• регистрация серверов доменных имен.

С 1993 по 1998 год, согласно Договору о сотрудничестве с правительством США, NSI являлся единственным провайдером для регистрации доменных имен в доменах верхнего уровня .com, .net и .org. В 1998 году в Договор были внесены поправки, и теперь NSI разрабатывает программное обеспечение для поддержки распределенной системы регистрации (Shared Registration System) в доменах верхнего уровня. Сегодня правительство США начало процесс приватизации системы управления доменными именами в сети в надежде, что это даст новый толчок к развитию конкуренции, а, следовательно, и к развитию всего сетевого сообщества. Наблюдательные функции за этим процессом были возложены на Корпорацию по назначению адресов и доменов в сети Internet (Internet Corporation for Assigned Names and Numbers — ICANN). Эта организация отвечает за аккредитацию компаний, регистрирующих доменные имена. Организация ICANN является международной некоммерческой организацией.

С приватизацией служб регистрации изменились процедуры распределения пространства IP-адресов и назначения номеров автономным системам (Autonomous System — AS). В настоящее время Региональными реестрами сети Internet (Regional Internet Regisrty — RIR) обеспечивается регистрация в сети Internet по всему земному шару — это Американский реестр адресов сети Internet (American Registry for the Internet Numbers - ARIN), Европейский сетевой координационный центр (Reseaux IP Europeens Network Coordination Center — RIPE NCC) и Азиатско-Тихоокеанский сетевой информационный центр (APNIC).

Американский реестр адресов сети 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.

Европейский сетевой координационный центр. Созданный в 1989 году Европейский сетевой координационный центр (Reseaux IP Europeens Network Coordination Center — RIPE NCC или просто RIPE) представлял собой совещательный орган провайдеров сети Internet в Европе. Его основная цель — администрирование и координация работы в Европейском сегменте сети Internet. Для Европы и соседних с ней территорий RIPE выступает в качестве RIR. RIPE распределяет IP-адреса, координирует работу системы доменных имен (Domain Name System—DNS), а также ведет базу данных с информацией об IP-сетях, серверах DNS и правилах IP-маршрутизации. Она также обеспечивает функции хранилища программного обеспечения, необходимого для работы с Internet, документов RIPE. С ее помощью поддерживаются службы регистрации в реестре маршрутизации и интерактивные информационные службы. Подобно ARIN, RIPE является некоммерческой организацией и все финансовые поступления производятся лишь за счет предоставляемых ей услуг.

Азиатско-Тихоокеанский сетевой информационный центр. Созданный в 1993 году Азиатско-Тихоокеанский сетевой информационный центр (Asian Pasific Network Information CenterAPNIC) предоставляет услуги, сходные с услугами ARIN. Центр APNIC предоставляет эти услуги во всем Азпатско-Тихоокеанском регионе, включающем 62 страны и региона в Южной и Центральной Азии, в Юго-Восточной Азии, Индокитае и на островах Океании. В настоящее время APNIC не занимается администрированием DNS, хотя и оказывает посильную помощь в организации этой системы в регионе.

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

Реестры маршрутизации в Internet (Internet Routing Registries — IRR) служат общедоступной базой данных, содержащей информацию об организации маршрутов и об ответственных лицах, с которыми следует контактировать для координации работы системы маршрутизации и при разрешении проблем. Для того чтобы адресовать соответствующим образом все вызовы для каждого глобального домена, пришлось создать отдельный реестр маршрутизации (routing registry — RR). В каждом RR ведется своя база данных правил маршрутизации, которая обновляется всеми провайдерами, входящими в RR. Совокупность этих баз данных известна под названием Реестра маршрутизации в сети Internet (Internet Routing RegistryIRR). Главная задача RR — не определение правил маршрутизации, а хранение этих правил и другой информации административного характера. Таким образом, предполагается создать глобальную базу данных правил маршрутизации, используемых всеми провайдерами по всему земному шару. Большинство операторов сети получают информацию о маршрутизации из реестров маршрутизации, что позволяет им оперативно изменять правила маршрутизации.

Автономные системы (Autonomous Systems — AS) для работы друг с другом используют протоколы внешнего шлюза (Exterior Gateway Protocols — EGP), такие как протокол граничного шлюза (Border Gateway Protocol — BGP). В случае сложных сетей появляется необходимость в стандартизации правил описания и правил объединения различных AS. Поддержка гигантской базы данных, содержащей зарегистрированные по всему миру наборы правил, была бы обременительной и сложной. Поэтому было найдено другое решение — использовать распределенные базы данных. Каждый RR ведет собственную базу данных и обеспечивает ее согласованность с другими базами данных. Ниже приведено несколько существующих сегодня баз данных IRR:

- Реестр маршрутизации RIPE (RIPE Routing Registry), куда входят все европейские провайдеры Internet.

- Реестр маршрутизации компании Cable & Wireless (Cable & Wireless Routing Registry) для клиентов компании.

- Реестр маршрутизации CA*net для пользователей CA*net (CA*net Routine Registry).

- Реестр маршрутизации провайдеров Internet в Японии JPRR (Japanese Internet service providers Routing Registry).

- Общедоступная база данных арбитража маршрутизации (Routing Arbiter Database).

- Общедоступный реестр маршрутизации ARIN (ARIN Routing Registry).

Каждый из приведенных выше реестров служит базой провайдеров Internet, за исключением базы данных арбитража маршрутизации (Routing Arbiter Database — RADB) и ARIN, где регистрируются все желающие. Как уже упоминалось, RADB является частью проекта арбитража маршрутизации (Routing Arbiter project). Ввиду высокой гибкости и других преимуществ локальных реестров несколько других компаний, таких как Qwest, Level(3) и Verio, также учредили собственные RR.

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

Кроме ценовой политики, магистральных каналов и способов межсетевых соединений, следует также обсудить с провайдером вопрос о точке демаркации (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.

Далее, рассмотрим формат заголовка пакета 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.

Процесс переговоров между 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 для маршрута и информация о возможной агрегации.

Рассмотрим наиболее часто используемые атрибуты 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 работа с многоадресной междоменной маршрутизацией стала более гибкой, что предоставило новые возможности для управления сетевыми ресурсами.

Рассмотрим примеры практического применения протокола 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

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. Аналогично – для взаимодействия RTBRTA.

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 не зависимо от уровня сложности и количества взаимодействующих автономных систем.


 

А также другие работы, которые могут Вас заинтересовать

33165. Вечер знакомств 79 KB
  Набор команды: Садко набирает дружину Царь с царицей подданных в свое царство Капитан Врунгель команду. Творческая ромашка: детей делят на две или три команды Желтые лепестки цирк клоуны гимнасты дрессировщики жонглеры Красные лепесткитеатр инсценировать сказки ситуации . Далее все делятся на две команды. Способы деления на команды: 1 Первому игроку на ухо говорится цвет например красный.
33166. ВОЖАТОМУ НА ЗАМЕТКУ 71.5 KB
  ЛЕНИВЫЙ ВОЖАТЫЙ Ведя детей то в одно место то в другое исходя из запланированного в дне по дороге указывает рукой в разные направления и говорит: А это дети вон чо. Ведь надо отвечать на вопросы НОРМАЛЬНЫЙ ВОЖАТЫЙ В первые дни устроит игру по станциям в рамках Хозяйственного или Организационного сборов. ВОЖАТЫЙ С ФАНТАЗИЕЙ Заранее до начала смены выстроит экскурсионную программу по лагерю на всю смену продумав что показывать в первую очередь что в середине смены о чем говорить в конце. Договорится с вожатыми соседних отрядов...
33167. Возрастные особенности детей 32.5 KB
  Дети 79летнего возраста имеют следующие возрастные характеристики : высокий уровень активности; процессы возбуждения преобладают над процессами торможения; эмоциональная непосредственность; повышенная работоспособность но в то же время высокая утомляемость в следствии чего необходим отдых в течении дня ; Высокая потребность в игре движении во внешних впечатлениях; Предпочтение к шумным коллективным играм; Высокая чувствительность к критике со стороны взрослых; Сознание различий пола; Становление независимости; Развитие...
33168. Как не скучно ехать в автобусе 34.5 KB
  И если всё это время просто так сидеть и наблюдать в окно весёлой она точно не покажется. Чем же можно занять это время Вопервых уже по дороге в лагерь вожатый должен начинать формировать отряд. А самое главное на время дороги нужно придумать какоенибудь развлечение.Так как север это очень красивое но в то же время и очень опасное место вы все должны уметь четко и быстро выполнять наши команды что бы не погибнуть Кольцовка что нужно взять в экспедицию на Северный полюс А теперь проверим все ли вы взяли ничего не забыли а...
33169. КОНЦЕРТ ВОЖАТЫХ 28.5 KB
  если их нет изначально то скорее всего и не будет Основной этап: когда всю смену все говорят что нужен вожатник но кто его будет делать не понятно все кто действительно его будут делать об этом попрежнему не знают Внимание Время когда надо думать как быть с вожатником приходит нежданнонегадано как полный абзац Группа добровольцев сбивается в каком нибудь лагерном помещении и начинает судорожно перебирать все мыслимые и немыслимые варианты подготовки проведения и темы вожатника Внимание Водка и все заранее подготовленные...
33170. Чем развлекать детей 23 KB
  Например такие: Эстафеты разнообразные состязания в ловкости быстроте и силе Викторины интеллектуальные конкурсы КТД коллективное творческое дело постановки спектаклей концертов и представлений конкурсы красоты талантов разное рукоделие изготовление поделок и т. Тема: Море тогда или конкурсы могут быть связаны с морскими предметами или они могут быть объединены единой сюжетной линией морское путешествие. Тут все конкурсы так или иначе привязаны к этому предмету. Сами конкурсы 1.
33171. Центральный банк, основы его деятельности. Функции центральных банков. Активные и пассивные операции центральных банков 55.5 KB
  Функции центральных банков. Активные и пассивные операции центральных банков. Деятельность любых центральных банков как следует из анализа их исторического развития и современного положения в рыночной системе подчинена следующим основным целям: обеспечению стабильности покупательной способности и валютного курса национальной денежной единицы ликвидности банковской системы созданию эффективного и бесперебойного ведения расчетов включая расчеты наличными деньгами. Центральный банк хранит кассовые резервы коммерческих банков...
33172. Коммерческие банки, их виды. Роль коммерческих банков в рыночной экономике 57.5 KB
  Коммерческие банки их виды. Банки это огромное достижение цивилизации. Поскольку банки проводят в основном денежные операции и предметом их деятельности является денежный капитал то и содержание и масштабы последней зависят от степени развития товарноденежных отношений в стране уровня торговли темпов промышленного производства. Неэмиссионные банки подразделяются по направлению работы на коммерческие универсальные сберегательные инвестиционные ипотечные.
33173. Финансовые рынки. Финансовые институты 59 KB
  Формируется финансовый рынок. Современный финансовый рынок это сложный экономический механизм перераспределения денежных средств между странами регионами и отраслями. Свободные денежные средства сбережения всех экономических агентов поступают на финансовый рынок посредством сделок на котором происходит их инвестирование в различные финансовые активы. Финансовый рынок служит своего рода механизмом обеспечивающим перемещение потоков денежных сбережений от домашних хозяйств к предприятиям инвестирующим капиталы на свое развитие.