По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Мы уже рассказывали про мягкие и жесткие ссылки в Linux, и данная статья посвящена их более глубокому изучению. Ссылки в операционной системе Linux бывают 2-х типов мягкие и жесткие. Если провести аналогию с операционной системой Windows, то там мы в основном работаем с мягкими ссылками, символическими ярлыками. Но в операционной системе Windows есть и жесткие ссылки, просто они очень глубоко спрятаны внутри операционной системы. В статье будет рассказано:
Как идентифицировать тип ссылки
В чем разница между мягкой и жесткой ссылкой
В чем разница между копирование и создание ссылки
Итак, смотрим в домашнюю директорию пользователя. Я заранее создал файл и 2 ссылки жесткую и мягкую указывающие на данный файл.
Основной файл file.txt, жесткая ссылка hard.txt на файл file.txt и мягкая ссылка soft.txt на файл file.txt. Как можно заметить символические (мягкие) ссылки в оболочке, обычно, подкрашиваются ярко голубым цветом и показывают на какой файл она ссылается. Можно еще интересную вещь заменить основной файл весит 38 килобайт и жесткая ссылка столько же весит. Мягкая ссылка – это всего лишь ярлык и весит всего 8 килобайт. Посмотрим, что внутри файла основного. Файл содержит фразу.
Команда ls с ключем –li может отображать inodes. В результате ввода команды появился еще один столбец впереди. В данном столбце и отображается номер inodes, т.е идентификатор файла, индексный дескриптор, местонахождение файла на диске, метка файла.
В нашем же случае номера inodes у файла и у жесткой ссылки совпадает. Т.е жесткая ссылка указывает на то же место, где находиться основной файл, в то же самое место на жестком диске.
Мягкая же ссылка, сама по себе является отдельным файлом и у нее совершенно другой inode. А также можно видеть, что у данного файла в правах появилась буква l, которая указывает что это символьная ссылка. Причем попробовав просмотреть содержимое жесткой и мягкой ссылки, мы получим одинаковый результат. Все показывает на один и тот же файл.
Если мы попробуем дописать, какие-нибудь изменения в файл. Например, echo Hello>> file.txt
Получим один и тот же результат. Возьмем и переименуем наш основной файл mv file.txt newfile.txt.
Теперь мы можем увидеть, что ссылка мягкая у нас стала красной (Битой). Потому что, мягкие ссылки опираются на имя файла. Причем не просто на имя файла, а на полное имя файла. А жесткая ссылка, как была, так и осталась работоспособной. Потому, что она указывает на один и тот же inode, потому что она указывает на то место где данный файл находиться. И если мы утилитой cat скажем показать жесткую ссылку в выводе мы получим исходный файл, а мягкая ссылка выдаст нам ошибку. Основная разница между жесткой ссылкой и мягкой, заключается в том, что мягкая опирается на имя файла. А жесткая указывает на физическое место, определяемое дескриптором где находиться файл.
Создаются такие ссылки достаточно просто, командой ln с указанием основного файла и ссылки. Например, ln file.txt hard.txt. При создании мягкой ссылки добавляется ключик –s. Будет выглядеть примерно так - ln –s file.txt soft.txt. При создании ссылки, можно объекты указывать без расширения.
Т.к. жесткая ссылка у нас привязана к inode, то ее нельзя использовать с несколькими файловыми системами. Если у вас есть другой жесткий диск премонтированый в данную файловую систему, то вы не сможете создать жесткую ссылку из данной системы к премонтированному жесткому диску. Потому, что это все опирается на inode, а inode справедливы для конкретной файловой системе. Поэтому в операционной системе Windows все ссылки по умолчанию мягкие. Пригодиться это может где угодно. Например, мы в своей домашней директории можем создать ссылки на все свои важные папки или данные. Очень часто символические ссылки используются для администрирования. Операционной системы Linux. Например, для команд, если пользователь не хочет знать номер версии или дополнительные ключи, он может просто получать доступ к различным версиям просто используя ссылки.
Также стоит упомянуть ситуацию с папками.
Создадим папку - mkdir Folder. Попробуем создать жесткую ссылку на данную папку - ln Folder folder.lnk, данная команда выдаст ошибку указывая на то, что нельзя создать жесткую ссылку на папку, но, а если мы захотим создать мягкую (символическую ссылку), то проблемы не возникнет - ln –s Folder folder.lnk.
Хорошим тоном при создании ссылок символических это указание на полный путь файлу, т.к привязка идет к имени файла и при создании если указать относительны, мы можем столкнуться с ситуацией, когда получившаяся ссылка будет битой. Например, когда мы хотим создать ссылку на файл и положить ее во внутрь другие папки ln –s /home/siadmin/file.txt Folder/. данный вариант будет рабочим.
Разница между копирование файла и созданием ссылки. Когда копируем файл мы фактически создаем другой файл со всем его содержимым, а когда мы создаем ссылку – это некий ярлык на файл. Скопируем файл file.txt в newfile.txt и на file.txt создадим жесткую ссылку. Когда мы смотрим вывод команды ls –l по папке то визуально копию мы не отличим от жесткой ссылки, если мы конечно об этом не знаем. А отличие мы увидим только если мы посмотрим на inodes.
Как мы видим номера inode у файла и жесткой ссылки совпадают, причем мы не знаем, что из них первично. Можно заметить столбец с цифрами после указания прав на объекты, он показывает сколько ссылок жестких есть на данный inode. Создадим еще одну жесткую ссылку ln file.txt hard1.txt. Теперь если сделать вывод ls –li, то мы увидим цифру 3. Почему так происходит? Удалением файла у нас по умолчанию является действие, которое обнуляет количество всех жестких ссылок. Если мы удалим файл исходный file.txt. и посмотрим вывод то мы увидим, что если есть мягкие ссылки, то они прекратят работать, а файлы hard.txt и hard1.txt остались.
Более того, если обратиться к этим жестким ссылкам, например, с помощью утилиты просмотра cat hard.txt, то мы увидим текст, который был у нас изначально в файле.
Это происходит потому, что сам файл — это некоторое пространство занятое на диске, а имя файла и путь к нему – это и есть жесткая ссылка. Поэтому любой файл это есть жесткая ссылка на место на диске. Мы можем создать к нашему inode сколько угодно ссылок и пока мы их всех не удалим наш файл будет на месте.
Всем привет! Сегодня в статье мы хотим вам рассказать про то как зарегистрировать телефоны Cisco серии 78хх на IP-АТС Asterisk. Рассматривать настройку мы будем на примере телефона Cisco 7811, самого простого из этой серии, отличающегося от других тем что, имеет только одну линию. Если вам интересно как настроить телефон для работы с оригинальными АТС от Cisco, то тут вы можете прочитать про CUCM, а тут про CME.
Процесс загрузки телефона
Телефоны Cisco 78хх поддерживают протокол SIP, в отличие от старых моделей, которые работали по проприетарному протоколу SCCP, и это облегчит нам настройку.
Когда телефон Cisco загружается он выполняет следующие действия:
Телефон получает питание c помощью блока питания или при помощи PoE;
Телефон загружает ПО, которое хранится локально в его памяти;
Телефон узнает голосовой VLAN ID при помощи CDP;
Телефон использует DHCP чтобы узнать свой IP адрес, маску подсети, шлюз и адрес TFTP сервера;
Телефон связывается с TFTP сервером и запрашивает конфигурационный файл. (У каждого телефона есть конфигурационный файл, который имеет вид SEP<мак_адрес>.cnf.xml);
Телефон регистрируется на АТС CUCM, который указан в конфигурационном файле;
А нам, поскольку у нас Asterisk вместо CUCM, нужно изменить конфигурационный файл, который находится на TFTP и в нем указать адрес нашей АТС, его номер и прочие параметры.
Начнем по порядку.
Настройка DHCP и TFTP
Прежде всего нам нужно настроить DHCP сервер который будет выдавать адрес телефона и сообщать ему о TFTP сервере, а также соответственно сам TFTP сервер, на котором будут лежать все необходимые файлы.
Если вы используете в качестве DHCP сервера оборудование Cisco то прочитать про то как создать на нем DHCP сервер можно здесь, а если вы используете оборудование Mikrotik то здесь.
Основной момент – телефоны Cisco получают информацию о TFTP сервере при помощи параметра Option 150, и именно его нужно настроить и в нем указать адрес TFTP сервера, с которым должен связаться телефон чтобы забрать необходимые файлы.
Для Cisco нужно использовать следующую команду в настройках DHCP:
option 150 ip 192.168.1.20
Для Mikrotik нужно в WinBox перейти в меню IP - DHCP Server – Options и нажать “+”. Тут необходимо указать в поле Code значение 150, а в поле Value – адрес сервера. А затем в разделе Networks в поле DHCP Options указать созданную нами опцию.
В нашем примере мы будем использовать бесплатную программу Tftpd64, которая может выступать в качестве DHCP и TFTP сервера, а также может показывать логи, что очень удобно для траблшутинга.
В меню настроек во вкладке DHCP можно настроить все нужные параметры, в том числе и необходимую нам опцию 150.
Во вкладке TFTP указываем необходимые параметры, такие как адрес директории где будут находится файлы.
Если ваше оборудование не поддерживает Option 150 или вы не хотите заморачиваться с этим, то адрес TFTP сервера можно прописать на самом телефоне в разделе Настройки – Параметры администратора – Настройка сети – Настройка IPv4 и тут в пункте Дополнительный TFTP сервер установить значение “Да”, а ниже в поле TFTP-сервер вручную прописать нужный адрес.
Создание экстеншена на Asterisk
Создадим новый номер на нашей АТС при помощи графического интерфейса FreePBX.
Для этого переходим в меню Applications – Extensions, нажимаем Add Extension и выбираем Add New PJSIP Extension. Да мы будем использовать PJSIP, поскольку телефон будет слать пакеты на стандартный порт 5060, который в Asterisk использует PJSIP.
Этого будет достаточно, сохраняем и применяем конфиг.
Создание необходимых файлов
При загрузке телефона он будет пытаться скачать файл конфигурации и обновить свою прошивку.
После того как мы подняли наш TFTP сервер нам нужно залить на него все файлы, которые будут необходимы телефону.
Для начала нужно скачать файл прошивки для нашего телефона, потому что телефон будет всегда запрашивать его при загрузке. Скачать его можно с официального сайта Cisco, предварительно зарегистрировавшись там. Оттуда же нам нужно скачать файл с локалью.
Далее идет самое важное – файл конфигурации телефона. Нам нужно создать XML файл, который должен называться SEP<mac_адрес_телефона>.cnf.xml. Например, SEPA1B2C3D4E5F6.cnf.xml
Для создания этого файла лучше всего использовать специальный XML-редактор (например, EditiX), чтобы не было проблем с валидацией.
Его содержание должно быть таким:
<?xml version="1.0" encoding="UTF-8"
<device>
<versionStamp>{7821 Aug 28 2015 12:40:48}</versionStamp>
<devicePool>
<dateTimeSetting>
<dateTemplate>D.M.Y</dateTemplate>
<timeZone>E. Europe Standard/Daylight Time</timeZone>
<ntps>
<ntp>
<name>time.windows.com</name>
<ntpMode>Unicast</ntpMode>
</ntp>
</ntps>
</dateTimeSetting>
<callManagerGroup>
<members>
<member priority="0">
<callManager>
<ports>
<ethernetPhonePort>2000</ethernetPhonePort>
</ports>
<processNodeName>192.168.1.17</processNodeName>
</callManager>
</member>
</members>
</callManagerGroup>
</devicePool>
<commonProfile>
<callLogBlfEnabled>3</callLogBlfEnabled>
</commonProfile>
<loadInformation>sip78xx.12-5-1-16</loadInformation>
<userLocale>
<name>Russian_Russia</name>
<uid/>
<langCode>ru_RU</langCode>
<version/>
<winCharSet>utf-8</winCharSet>
</userLocale>
<networkLocale>United_States</networkLocale>
<networkLocaleInfo>
<name>Russian_Russia</name>
</networkLocaleInfo>
<idleTimeout>0</idleTimeout>
<authenticationURL/>
<directoryURL/>
<idleURL/>
<informationURL/>
<messagesURL/>
<proxyServerURL/>
<servicesURL/>
<capfAuthMode>0</capfAuthMode>
<capfList>
<capf>
<phonePort>5060</phonePort>
<processNodeName/>
</capf>
</capfList>
<deviceSecurityMode>1</deviceSecurityMode>
<sipProfile>
<sipCallFeatures>
<cnfJoinEnabled>true</cnfJoinEnabled>
<callForwardURI>x--serviceuri-cfwdall</callForwardURI>
<callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
<callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
<callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
<meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
<abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
<rfc2543Hold>true</rfc2543Hold>
<callHoldRingback>2</callHoldRingback>
<localCfwdEnable>true</localCfwdEnable>
<semiAttendedTransfer>true</semiAttendedTransfer>
<anonymousCallBlock>2</anonymousCallBlock>
<callerIdBlocking>0</callerIdBlocking>
<dndControl>0</dndControl>
<remoteCcEnable>true</remoteCcEnable>
</sipCallFeatures>
<sipStack>
<sipInviteRetx>6</sipInviteRetx>
<sipRetx>10</sipRetx>
<timerInviteExpires>180</timerInviteExpires>
<timerRegisterExpires>120</timerRegisterExpires>
<timerRegisterDelta>5</timerRegisterDelta>
<timerKeepAliveExpires>120</timerKeepAliveExpires>
<timerSubscribeExpires>120</timerSubscribeExpires>
<timerSubscribeDelta>5</timerSubscribeDelta>
<timerT1>500</timerT1>
<timerT2>4000</timerT2>
<maxRedirects>70</maxRedirects>
<remotePartyID>false</remotePartyID>
<userInfo>None</userInfo>
</sipStack>
<autoAnswerTimer>1</autoAnswerTimer>
<autoAnswerAltBehavior>false</autoAnswerAltBehavior>
<autoAnswerOverride>true</autoAnswerOverride>
<transferOnhookEnabled>true</transferOnhookEnabled>
<enableVad>false</enableVad>
<preferredCodec>g729</preferredCodec>
<dtmfAvtPayload>101</dtmfAvtPayload>
<dtmfDbLevel>3</dtmfDbLevel>
<dtmfOutofBand>avt</dtmfOutofBand>
<alwaysUsePrimeLine>false</alwaysUsePrimeLine>
<alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
<kpml>3</kpml>
<stutterMsgWaiting>1</stutterMsgWaiting>
<callStats>false</callStats>
<silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
<disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>
<startMediaPort>16384</startMediaPort>
<stopMediaPort>16399</stopMediaPort>
<voipControlPort>5069</voipControlPort>
<dscpForAudio>184</dscpForAudio>
<ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
<dialTemplate>dialplan.xml</dialTemplate>
<phoneLabel>Office</phoneLabel>
<sipLines>
<line button="1">
<featureID>9</featureID>
<featureLabel>Merion Networks</featureLabel>
<name>200</name>
<displayName>Cisco</displayName>
<contact>200</contact>
<proxy>192.168.1.17</proxy>
<port>5060</port>
<autoAnswer>
<autoAnswerEnabled>2</autoAnswerEnabled>
</autoAnswer>
<callWaiting>3</callWaiting>
<authName>200</authName>
<authPassword>qwe123</authPassword>
<sharedLine>false</sharedLine>
<messageWaitingLampPolicy>1</messageWaitingLampPolicy>
<messagesNumber>121</messagesNumber>
<ringSettingIdle>4</ringSettingIdle>
<ringSettingActive>5</ringSettingActive>
<forwardCallInfoDisplay>
<callerName>true</callerName>
<callerNumber>false</callerNumber>
<redirectedNumber>false</redirectedNumber>
<dialedNumber>true</dialedNumber>
</forwardCallInfoDisplay>
</line>
</sipLines>
</sipProfile>
</device>
Что нас здесь интересует и что нужно изменить:
<timeZone> - E. Europe Standard/Daylight Time - в нашем примере мы используем временную зону, которая подходит для Москвы UTC+3.
<processNodeName> – адрес нашего Asterisk
<loadInformation> – имя файла прошивки (который с расширением .loads)
<userLocale><name> и <networkLocaleInfo> - Russian_Russia – папка с локалью
<phonePort> - 5060 – номер SIP порта
<voipControlPort> - номер порта телефона
И рассмотрим блок <line button="1"> с настройкой линии. Здесь нужно изменить в соответствии с нашими данными:
<featureLabel>Merion Networks</featureLabel> - Имя на телефона
<name>200</name> - Номер экстеншена
<displayName>Cisco</displayName> - Имя экстеншена
<contact>200</contact> - Снова номер экстеншена
<proxy>192.168.1.17</proxy> - Адрес Asterisk
<port>5060</port> - номер SIP порта
<authName>200</authName> - Еще раз номер экстеншена
<authPassword>qwe123</authPassword> - Пароль экстеншена
Помимо этого, создаем файл диалпана dialplan.xml, без которого телефон не загрузится:
<DIALTEMPLATE>
<TEMPLATE MATCH="8,800......." Timeout="1"/>
<TEMPLATE MATCH="8,.........." Timeout="1"/>
<TEMPLATE MATCH="0.." Timeout="1"/>
<TEMPLATE MATCH="1..." Timeout="1"/>
<TEMPLATE MATCH="2..." Timeout="1"/>
<TEMPLATE MATCH="3..." Timeout="1"/>
<TEMPLATE MATCH="4..." Timeout="1"/>
<TEMPLATE MATCH="[5-7]..." Timeout="1"/>
<TEMPLATE MATCH="**...." Timeout="0"/>
<TEMPLATE MATCH="*" Timeout="3"/>
</DIALTEMPLATE>
Далее создаем файл g3-tones.xml со следующим содержанием:
<tones>
<trkLocaleName>Russian_Federation</trkLocaleName>
<trkBaseClearcaseVersion>/main/3.3.release/1</trkBaseClearcaseVersion>
<trkTranslationVersion>0</trkTranslationVersion>
<tone c1="30959" i1="-1879" d="1" t="ringing">
<part m="on" t="800"/>
<part m="off" t="3200"/>
<repeat c="65535"/>
</tone>
<tone c1="30959" i1="-1879" d="1" t="reorder">
<part m="on" t="200"/>
<part m="off" t="200"/>
<repeat c="65535"/>
</tone>
<tone c1="30959" i1="-1879" d="1" t="busy">
<part m="on" t="400"/>
<part m="off" t="400"/>
<repeat c="65535"/>
</tone>
<tone c1="30959" i1="-1879" d="1" t="odial">
<part m="on" t="65535"/>
<repeat c="65535"/>
</tone>
<tone c1="30959" i1="-1879" d="1" t="idial">
<part m="on" t="65535"/>
<repeat c="65535"/>
</tone>
<tone c1="14876" i1="-5346" d="1" t="recording">
<part m="on" t="400"/>
<part m="off" t="15000"/>
<repeat c="65535"/>
</tone>
<tone c1="30743" i1="-1384" c2="29780" i2="-1252" c3="30743" i3="-1384" c4="29780" i4="-1252" d="34" t="amwi">
<part m="on" t="100" />
<part m="off" t="100" />
<part m="on" t="65535" />
<repeat c="65535" pc1="10" pc2="65535"/>
</tone>
<tone c1="30831" i1="-2032" d="17" t="monitoring">
<part m="on" t="1500"/>
<part m="off" t="8000"/>
<part m="on" t="500"/>
<part m="off" t="8000"/>
<repeat c="65535"/>
</tone>
</tones>
После этого создаем в директории TFTP папку Russian_Russia (или ту которую указали в <userLocale><name> и <networkLocaleInfo><name>) и переносим туда файл g3-tones.xml. Также туда необходимо перенести файл локали sp-sip.jar.
И наконец нам нужно создать три пустых файла:
CTLSEPSEP<mac_адрес_телефона>.tlv
ITLSSEPSEP<mac_адрес_телефона>.tlv
ITLFile.tlv
Эти файлы нужны чтобы у нас не было ошибки “No Trust List Installed”.
На этом все. По итогу в директории нашего TFTP сервера должны быть следующие файлы:
SEP<mac_адрес_телефона>.cnf.xml
dialplan.xml
sip78xx.12-5-1-16.loads
CTLSEP<mac_адрес_телефона>.tlv
ITLSSEP<mac_адрес_телефона>.tlv
ITLFile.tlv
Папка Russian_Russia с файлами: g3-tones.xml и sp-sip.jar
Загрузка телефона
На этом наша подготовка закончена, и мы теперь можем включить телефон. Он начнет загружаться, получит IP адрес и пойдет на TFTP чтобы скачать все необходимые файлы.
При помощи Tftfd64 можно смотреть за происходящем через вкладку Log Viewer, где можно увидеть какие файлы скачивает, и каких ему не хватает, в случае ошибки.
Если все нормально, то телефон скачает файл конфигурации, затем установит новую версию прошивки с TFTP и выбранную локаль, после чего перезагрузится. После прошивки он начнет связываться с нашей IP-АТС Asterisk и начнется процесс регистрации в результате, которого мы получим телефон Cisco, работающий с Asterisk по протоколу SIP.
Успех! Теперь можем проверять телефон и делать звонки!
Первоначально BGP был разработан как протокол Внешнего шлюза (Exterior Gateway Protocol - EGP), что означает, что он предназначался для подключения сетей или автономных систем (AS), а не устройств. Если BGP является EGP, это должно означать, что другие протоколы маршрутизации, такие как RIP, EIGRP, OSPF и IS-IS, должны быть протоколами внутренних шлюзов (Interior Gateway Protocols- IGP). Четкое определение внутренних и внешних шлюзов оказалось полезным при проектировании и эксплуатации крупномасштабных сетей. BGP является уникальным среди широко распространенных протоколов в том, что касается расчета пути без петель. Существует три широко используемых протокола векторов расстояний (Spanning Tree, RIP и EIGRP). Существует два широко используемых протокола состояния канала связи (OSPF и IS-IS). И есть еще много примеров этих двух типов протоколов, разработанных и внедренных в то, что можно было бы считать нишевыми рынками. BGP, однако, является единственным широко развернутым протоколом вектора пути.
Каковы наиболее важные цели EGP? Первый - это, очевидно, выбор путей без петель, но это явно не означает кратчайшего пути. Причина, по которой кратчайший путь не так важен в EGP, как в IGP, заключается в том, что EGP используются для соединения объектов, таких как поставщики услуг, поставщики контента и корпоративные сети. Подключение сетей на этом уровне означает сосредоточение внимания на политике, а не на эффективности - с точки зрения сложности, повышение состояния с помощью механизмов политики при одновременном снижении общей оптимизации сети с точки зрения передачи чистого трафика.
BGP-пиринг
BGP не обеспечивает надежной передачи информации. Вместо этого BGP полагается на TCP для передачи информации между одноранговыми узлами BGP. Использование TCP гарантирует:
Обнаружение MTU обрабатывается даже для соединений, пересекающих несколько переходов (или маршрутизаторов).
Управление потоком осуществляется базовым транспортом, поэтому BGP не нуждается в непосредственном управлении потоком (хотя большинство реализаций BGP действительно взаимодействуют со стеком TCP на локальном хосте, чтобы повысить пропускную способность, в частности, для BGP).
Двусторонняя связь между одноранговыми узлами обеспечивается трехсторонним рукопожатием, реализованным в TCP.
Несмотря на то, что BGP полагается на базовое TCP-соединение для многих функций, которые плоскости управления должны решать при построении смежности, по-прежнему существует ряд функций, которые TCP не может предоставить. Следовательно, необходимо более подробно рассмотреть процесс пиринга BGP.
Рисунок 1 позволяет изучить этот процесс.
Сеанс пиринга BGP начинается в состоянии ожидания (idle state).
A отправляет TCP open на порт 179. B отвечает на временный порт (ephemeral port) на A. После завершения трехстороннего подтверждения TCP (сеанс TCP успешен), BGP перемещает состояние пиринга для подключения. Если пиринговый сеанс формируется через какой-либо тип фильтрации на основе состояния, такой как брандмауэр, важно, чтобы открытое TCP-сообщение передавалось «изнутри» фильтрующего устройства.
В случае сбоя TCP-соединения состояние пиринга BGP переводится в активное.
A отправляет BGP open в B и переводит B в состояние opensent. В этот момент A ожидает от B отправки сообщения keepalive. Если B не отправляет сообщение keepalive в течение определенного периода, A вернет сеанс обратно в состояние ожидания (idle state). Открытое сообщение содержит ряд параметров, например, какие семейства адресов поддерживают два спикера BGP и hold timer. Это называется согласованием возможностей. Самый низкий (минимальный) hold timer из двух объявленных выбирается в качестве hold timer для однорангового сеанса.
Когда B отправляет A сообщение keepalive, A переводит B в состояние openconfirm.
На этом этапе A отправит B сообщение keepalive для проверки соединения. Когда A и B получают сообщения поддержки активности друг друга, пиринговый сеанс переходит в established state.
Два узла BGP обмениваются маршрутами, поэтому их таблицы обновлены. A и B обмениваются только своими лучшими путями, если какая-либо форма многонаправленного распространения BGP не поддерживается и не настроена на двух спикерах.
Чтобы уведомить A, что он завершил отправку всей своей локальной таблицы, B отправляет A сигнал End of Table (EOT) или End of RIB (EOR).
Существует два типа пиринговых отношений BGP: одноранговые узлы BGP в одной и той же автономной системе (AS, что обычно означает набор маршрутизаторов в одном административном домене, хотя это довольно общее определение) называются внутренними одноранговыми узлами BGP (internal BGP - iBGP) и Одноранговые узлы BGP между автономными системами называются внешними (или внешними - exterior) узлами BGP (eBGP). Хотя два типа пиринговых отношений BGP построены одинаково, у них разные правила объявления.
Процесс выбора оптимального пути BGP
Поскольку BGP предназначен для соединения автономных систем, алгоритм наилучшего пути ориентирован в первую очередь на политику, а не на отсутствие петель. Фактически, если вы изучите какое-либо стандартное объяснение процесса наилучшего пути BGP, то, является ли конкретный путь свободным от петель, вообще не будет учитываться в процессе принятия решения. Как же тогда BGP определяет, что конкретный узел объявляет маршрут без петель? Рисунок 2 демонстрирует это.
На рисунке 2 каждый маршрутизатор находится в отдельной AS, поэтому каждая пара спикеров BGP будет формировать сеанс пиринга eBGP. A, который подключен к 2001: db8: 3e8: 100 :: / 64, объявляет этот маршрут к B и C. Объявления маршрута BGP несут ряд атрибутов, одним из которых является путь AS. Перед тем, как A объявит 100 :: / 64 для B, он добавляет свой номер AS в атрибут AS Path. B получает маршрут и объявляет его D. Перед объявлением маршрута к D он добавляет AS65001 к AS Path. Тогда путь AS, прослеживающийся от A до C, на каждом шаге выглядит примерно так:
Получено B: [AS65000]
Получено C: [AS65000, AS65001]
Получено D: [AS65000, AS65001, AS65003]
Когда D получил маршрут от B, он анонсирует его обратно в C (в BGP нет split horizon). Предположим, что C, в свою очередь, объявляет обратный маршрут к A по какой-то причине (в этой ситуации это не так, потому что путь через A был бы лучшим путем к месту назначения, а просто для демонстрации предотвращения петель), A будет проверять AS Path и обнаружение его локальной AS находится в AS Path. Это явно петля, поэтому A просто игнорирует маршрут. Поскольку этот маршрут игнорируется, он никогда не помещается в таблицу топологии BGP. Следовательно, с использованием процесса наилучшего пути BGP сравниваются только маршруты без петель.
В большинстве реализаций процесс наилучшего пути BGP состоит из 13 шагов (первый шаг реализуется не всегда, так как это локальное решение со стороны узла BGP):
Выбирается маршрут с наибольшим весом. Некоторые реализации не используют вес маршрута.
Выбирается маршрут с наивысшим местным предпочтением (local preference- LOCAL PREF). Local preference собой политику выхода локальной AS - какую точку выхода из доступных точек выхода предпочел бы владелец этой AS, как и узел BGP.
Предпочитайте маршрут с локальным происхождением, то есть на этом узле BGP. Этот шаг редко используется в процессе принятия решения.
Предпочитайте путь с самым коротким AS Path. Этот шаг предназначен для выбора наиболее эффективного пути через объединенную сеть, выбора пути, который будет проходить через наименьшее количество автономных систем для достижения пункта назначения. Операторы часто добавляют записи AS Path, чтобы повлиять на этот шаг в процессе принятия решения.
Предпочитайте путь с наименьшим значением координат. Маршруты, которые перераспределяются из IGP, предпочтительнее маршрутов с неизвестным происхождением. Этот шаг редко оказывает какое - либо влияние на процесс принятия решений.
Предпочитайте путь с самым низким multiexit discriminator (MED). MED представляет входную политику удаленной AS. Таким образом, MED сравнивается только в том случае, если от одной и той же соседней AS было получено несколько маршрутов. Если один и тот же маршрут получен от двух разных соседних автономных систем, MED игнорируется.
Предпочитайте маршруты eBGP маршрутам iBGP.
Предпочитайте маршрут с наименьшей стоимостью IGP до следующего перехода. Если политика локального выхода не задана (в форме локального предпочтения), и соседняя AS не установила политику входа (в форме MED), то путь с ближайшим выходом из локального маршрутизатора выбирается как точка выхода.
Определите, следует ли устанавливать несколько путей в таблице маршрутизации (настроена некоторая форма multipath).
При сравнении двух внешних маршрутов (полученных от однорангового узла eBGP) предпочтите самый старый маршрут или маршрут, изученный первым. Это правило предотвращает отток маршрутов только потому, что маршруты обновляются.
Предпочитайте маршрут, полученный от однорангового узла с наименьшим идентификатором маршрутизатора. Это просто средство разрешения конфликтов для предотвращения оттока в таблице маршрутизации.
Предпочитайте маршрут с наименьшей длиной кластера.
Предпочитайте маршрут, полученный от однорангового узла с наименьшим адресом пиринга. Это, опять же, просто тай-брейк, выбранный произвольно, чтобы предотвратить ненужные связи и вызвать отток в таблице маршрутизации, и обычно используется, когда два одноранговых узла BGP соединены по двум параллельным каналам.
Хотя это кажется долгим процессом, почти каждое решение наилучшего пути в BGP сводится к четырем факторам: локальному предпочтению (local preference), MED, длине AS Path и стоимости IGP.
Правила объявления BGP
BGP имеет два простых правила для определения того, где объявлять маршрут:
Объявляйте лучший путь к каждому пункту назначения каждому узлу eBGP.
Объявляйте лучший путь, полученный от однорангового узла eBGP, для каждого однорангового узла iBGP.
Еще один способ сформулировать эти два правила: никогда не объявлять маршрут, полученный от iBGP, другому узлу iBGP. Рассмотрим рисунок 3.
На рисунке 3 A и B - это одноранговые узлы eBGP, а B и C, а также C и D - одноранговые узлы iBGP. Предположим, A объявляет 2001: db8: 3e8: 100 :: / 64 для B. Поскольку B получил это объявление маршрута от однорангового узла eBGP, он объявит 100 :: / 64 на C, который является одноранговым узлом iBGP. C, изучив этот маршрут, не будет объявлять маршрут к D, поскольку C получил маршрут от однорангового узла iBGP, а D также является одноранговым узлом iBGP. Таким образом, на этом рисунке D не узнает о 100 :: / 64. Это не очень полезно в реальном мире, однако ограничение присутствует не просто так.
Рассмотрим, как BGP предотвращает образование петель маршрутизации - передавая список автономных систем, через которые прошел маршрут, в самом объявлении маршрута. При объявлении маршрута от одного спикера iBGP к другому AS Path не изменяется. Если узлы iBGP объявляют маршруты, полученные от одноранговых узлов iBGP, одноранговым узлам iBGP, петли маршрутизации могут быть легко сформированы. Одним из решений этой проблемы является простое построение многоуровневых пиринговых отношений между B и D (помните, что BGP работает поверх TCP. Пока существует IP-соединение между двумя узлами BGP, они могут построить пиринговые отношения). Предположим, что B строит пиринговые отношения с D через C, и ни B, ни D не строят пиринговые отношения с C. Что произойдет, когда трафик переключается на 100 :: / 64 посредством D на C? Что будет с пакетами в этом потоке на C? У C не будет маршрута к 100 :: / 64, поэтому он сбросит трафик. Это может быть решено несколькими способами - например, B и D могут туннелировать трафик через C, поэтому C не обязательно должен иметь доступность к внешнему пункту назначения. BGP также можно настроить для перераспределения маршрутов в любой основной запущенный IGP (это плохо - не делайте этого).
Для решения этой проблемы были стандартизированы рефлекторы маршрутов BGP. Рисунок 4 иллюстрирует работу отражателей маршрута.
На рисунке 4 E сконфигурирован как рефлектор маршрута. B, C и D настроены как клиенты рефлектора маршрутов (в частности, как клиенты E). A объявляет маршрут 2001: db8: 3e8: 100 :: / 64 к B. B объявляет этот маршрут E, потому что он был получен от однорангового узла eBGP, а E является одноранговым узлом iBGP. E добавляет новый атрибут к маршруту, список кластеров, который указывает путь обновления в AS через кластеры отражателя маршрута. Затем E объявит маршрут каждому из своих клиентов. Предотвращение зацикливания в этом случае обрабатывается списком кластеров.
Подведение итогов о BGP
Хотя изначально BGP был разработан для соединения автономных систем, его использование распространилось на центры обработки данных, передачу информации о виртуальных частных сетях. Фактически, использование BGP практически безгранично. Постепенно BGP превратился в очень сложный протокол.
BGP можно описать как:
Проактивный протокол, который узнает о достижимых местах назначения через конфигурацию, локальную информацию и другие протоколы.
Протокол вектора пути, который объявляет только лучший путь к каждому соседу и не предотвращает образование петель в автономной системе (если не развернуты рефлекторы маршрута или какая-либо дополнительная функция)
Выбор путей без петель путем изучения пути, по которому может быть достигнут пункт назначения
Проверка двустороннего подключения и MTU за счет использования TCP в качестве основы для передачи информации.