По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Введение
Однажды в организации, где я работаю, случился Asterisk
Случился не без моего участия, а если быть точным, то я и был главным виновником, и как следствие - главным исполнителем. Напасть была локальной, но достаточно быстро получила широкое распространение, хотя, в отдельных уголках приходилось нести прогресс в массы с применением тяжелой артиллерии и напалма. В итоге Asterisk`ом было охвачено порядка полутора тысяч абонентов.
Процесс настройки абонента изначально выглядел следующим образом:
Включил телефон, обновил прошивку. Пока он перезагружается, завел абонента на Asterisk (создал запись для регистрации SIP-клиента). Далее, самый очевидный способ настройки телефона - web-интерфейс; набрал в адресной строке браузера IP-адрес телефона, авторизовался, настроил два десятка параметров и готово. На всё ушло 2-3 минуты.
Следующий абонент - повторяем.
На втором десятке абонентов начало надоедать, появилось желание как-нибудь упростить процесс.
Заглянул в настройки: экспорт и импорт конфигурации присутствует; сохранил конфигурацию телефона в файл, заглянул в него - обычный текстовый файл, в котором перечислены параметры с их значениями.
Нашел параметры, значения которых менял в web-интерфейсе, причем большинство из этих параметров, хоть и отличается от дефолтных, но одинаково для всех настраиваемых в рамках данной организации телефонов. Таким образом, имея эталонный файл конфигурации и редактируя в нем всего 5-6 строк, я получал конфигурации для остальных телефонов, которые "заливал" в аппараты всё через тот же web-интерфейс.
Спустя какое-то время количество абонентов заметно выросло, компания продолжала развиваться, сотрудники мигрировали между подразделениями, увольнялись, появлялись новые, некоторые телефоны выходили из строя, и возня с файлами стала постепенно отнимать много времени и раздражала с каждым днем всё больше. Тут я вспомнил про пункт меню из web-интерфейса, в котором были написаны многообещающие слова "Auto Provision".
Обратимся за определением к производителям телефонов. У Dlink или Fanvil мы получим следующее:
Auto Provisioning используется для реализации удаленной/автоматической инсталляции, развертывания конфигурационных и некоторых других связанных файлов.
Snom дает нам практически такое же:
Auto Provisioning может использоваться для предоставления общих и специфических параметров конфигурации на телефоны и для актуализации прошивки.
Вроде бы всё устраивает, значит, будем для наших целей отталкиваться от этих определений.
Вариантов автоматической настройки предусмотрено несколько, и без долгих терзаний, как наиболее понятный и доступный был выбран следующий:
Развертывание конфигурации с tftp сервера, адрес которого телефон будет получать по DHCP в Option 66.
Разберемся вкратце, что есть что.
TFTP - простой протокол передачи файлов (Trivial File Transfer Protocol). В отличие от FTP основан на транспортном протоколе UDP и в нем отсутствует возможность аутентификации (однако, возможна фильтрация по IP-адресу). Одно из основных преимуществ TFTP - простота реализации клиента, поэтому он достаточно широко используется в частности для загрузки обновлений и конфигураций сетевых устройств.
DHCP - протокол динамической настройки узла (Dynamic Host Configuration Protocol); сетевой протокол, позволяющий сетевым устройствам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP.
Не вдаваясь глубоко в подробности, схема обмена сообщениями DHCP при получении параметров выглядит следующим образом:
DHCPDISCOVER: клиент (в нашем случае, телефон) передает это сообщение broadcast, и использует его для поиска DHCP-серверов в своей канальной среде.
В одном из полей этого пакета, в поле options, клиент передает список необходимых ему опций, наиболее распространенными из которых являются:
(1) - Subnet Mask
(3) - Router
(6) - Domain Name Server
(15) - Domain Name
именно в этом поле клиент сообщает о том, что ему нужен адрес tftp сервера для загрузки конфигурационного и/или других связанных файлов. Номер опции, которая его содержит - 66 (у cisco есть аналогичная опция 150, основное отличие которой в том, что она может содержать адреса нескольких tftp серверов).
DHCPOFFER: cервер отвечает на запрос клиента. Сервер может передать это сообщение как broadcast так и unicast (зависит от значений полей полученных от клиента). В этом сообщении сервер предлагает клиенту параметры, которые он может отдать в текущей конфигурации. Если в сегменте сети клиента несколько DHCP серверов, то получив запрос, они все отправляют OFFER-ы.
После того, как клиент выбрал, OFFER какого из DHCP серверов принять, он отправляет следующий пакет:
DHCPREQUEST: казалось бы, если клиент определился, какой DHCP сервер "пришелся ему по душе", можно передать unicast-запрос этому серверу; однако предается broadcast, чтобы уведомить остальные DHCP серверы о своём выборе (добавляется опция 54, указывающая адрес выбранного DHCP-сервера), и они могли освободить зарезервированные OFFER-ы.
DHCPACK: cервер отправляет подтверждение клиенту. После этого клиент настраивает свой сетевой интерфейс, используя предоставленные параметры и опции.
В различных ситуациях могут еще возникать DHCPDECLINE, DHCPNAK, DHCPRELEASE, DHCPINFORM, но их рассмотрение в рамки данной статьи не входит.
Для получения исчерпывающей информации о работе DHCP можно обратиться к RFC 2131:
https://tools.ietf.org/html/rfc2131
Про опции 66 и 150 можно почитать здесь:
https://wiki.merionet.ru/ip-telephoniya/67/dhcp-opciya-150-i-66/
https://blog.router-switch.com/2013/03/dhcp-option-150-dhcp-option-66/
Про настройку DHCP сервера и Option 66 на Mikrotik можно почитать здесь:
https://wiki.merionet.ru/seti/5/nastrojka-dhcp-servera-na-mikrotik/
Чтобы передать телефону адрес tftp сервера, с которого он может получить конфигурационный файл, на DHCP сервере в параметрах области задаем Option 66, в которой указываем hostname либо IP адрес нашего tftp сервера.
Настройки по-умолчанию в большинстве телефонов подразумевают получение IP-адреса по DHCP и запрос Option 66.
В итоге, телефон получает IP, получает адрес tftp сервера и пытается "стянуть" оттуда файл своей конфигурации.
Согласно документации Dlink, загрузка файла конфигурации происходит следующим образом:
Устанавливается соединение с сервером.
Проверяется наличие файла с соответствующим именем:
- в первую очередь проверяется файл с именем соответствующим аппаратной платформе;
- во вторую - соответствующий MAC адресу устройства;
- в третью - соответствующий ID устройства;
- файл с произвольным именем проверяется либо в последнюю очередь (DHCP option, UpnP) либо в первую, если он явно указан в конфигурации телефона.
Проверяется версия конфигурационного файла.
Если версия выше, чем текущая на телефоне, файл конфигурации применяется.
Как уже говорилось ранее, файл конфигурации представляет собой текстовый документ определенного вида:
Первая строка: <<VOIP CONFIG FILE>>Version:2.0002
Для того, чтобы конфигурация была применена, версия файла должна быть выше, нежели текущая на телефоне, инкрементировать требуется последний разряд версии. По-умолчанию версия конфигурации 2.0002
Пример:
Текущая версия конфигурации 2.0002 на одном телефоне и 2.0004 на еще двух. Для того чтобы конфигурация применилась только на один телефон в первой строке файла конфигурации ставим <<VOIP CONFIG FILE>>Version:2.0004
для того чтобы обновить конфигурацию на всех телефонах ставим в первой строке
<<VOIP CONFIG FILE>>Version:2.0005
Разделы:
<GLOBAL CONFIG MODULE - содержит данные о сетевых настройках, серверах DNS, SNTP...
<LAN CONFIG MODULE> - содержит данные о настройках LAN, режимах работы LAN
<TELE CONFIG MODULE> - настройки расширенных функций телефонной части (Call Feature)
<DSP CONFIG MODULE> - настройка кодеков
<SIP CONFIG MODULE> - настройки SIP, серверы, регистрация etc...
<PPPoE CONFIG MODULE> - настройки PPPoE
<MMI CONFIG MODUL>E - настройки доступа и WEB интерфейса
<QOS CONFIG MODULE> - qos и vlan
<DHCP CONFIG MODULE> - настройки внутреннего DHCP
<NAT CONFIG MODULE> - настройки NAT и ALG
<PHONE CONFIG MODULE> - настройки телефонной части, в этом же разделе настраивается remote phonebook и extension key.
<SCREEN KEY CONFIG MODULE> - настройка программных клавиш (для версии F3)
<AUTOUPDATE CONFIG MODULE> - настройки Autoprovision
<VPN CONFIG MODULE> - настройки VPN
<TR069 CONFIG MODULE> - настройки TR069
Заканчивается файл строкой <<END OF FILE>>
Для обновления какой-либо опции конфигурации телефона, чтобы файл конфигурации был принят телефоном достаточно наличие следующих полей:
<<VOIP CONFIG FILE>> Version:2.0002
<Название необходимого раздела>
Название опции: значение
<<END OF FILE>>
Например, для обновления имени хоста телефона необходимо создать следующий файл конфигурации:
<<VOIP CONFIG FILE>>Version:2.0003
<GLOBAL CONFIG MODULE>
Host Name :ReceptionPhone
<<END OF FILE>>
Все остальные элементы являются необязательными.
Итак, овал нарисован.
Остались сущие мелочи - реализовать инструмент для создания конфигураций и дальнейшего управления ими. Займемся этим в следующей публикации.
В одном из прошлых статей мы рассмотрели способы фильтрации маршрутов для динамического протокола маршрутизации EIGRP. Следует отметить, что EIGRP проприетарная разработка Cisco, но уже открыта другим производителям. OSPF же протокол открытого стандарта и поддерживается всем вендорами сетевого оборудования. Предполагается, что читатель знаком с данным протоколом маршрутизации и имеет знания на уровне CCNA.
OSPF тоже поддерживает фильтрацию маршрутов, но в отличии от EIGRP, где фильтрацию можно делать на любом маршрутизаторе, здесь она возможна только на пограничных роутерах, которые называются ABR (Area Border Router) и ASBR (Autonomous System Boundary Router). Причиной этому является логика анонсирования маршрутов в протоколе OSPF. Не вдаваясь в подробности скажу, что здесь маршруты объявляются с помощью LSA (Link State Advertisement). Существует 11 типов LSA, но рассматривать их мы не будем. По ходу статьи рассмотрим только Type 3 LSA и Type 5 LSA.
LSA третьего типа создаются пограничными роутерами, которые подключены к магистральной области (backbone area) и минимум одной немагистральной. Type 3 LSA также называются Summary LSA. С помощью данного типа LSA ABR анонсирует сети из одной области в другую. В таблице базы данных OSPF они отображается как Summary Net Link States:
Фильтрация LSA третьего типа говорит маршрутизатору не анонсировать сети из одной области в другую, тем самым закрывая доступ к сетям, которые не должны отображаться в других областях.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для настройки фильтрации применяется команда area area-num filter-list prefix prefix-list-name {in | out} в интерфейсе конфигурации OSPF. Как видно, здесь применяются списки префиксов или prefix-list, о которых мы говорили в предыдущей статье. Маршрут не анонсируется если попадает под действие deny в списке префиксов.
Камнем преткновения в данной команде являются ключевые слова in и out. Эти параметры определяют направление фильтрации в зависимости от номера области, указанного в команде area are-num filter. А работают они следующим образом:
Если прописано слово in, то маршрутизатор предотвращает попадание указанных сетей в область, номер которого указан в команде.
Если прописано слово out, то маршрутизатор фильтрует номера сетей, исходящих из области, номер которого указан в команде.
Схематически это выглядит так:
Команда area 0 filter-list in отфильтрует все LSA третьего типа (из областей 1 и 2), и они не попадут в area 0. Но в area 2 маршруты в area 1 попадут, так как нет команд вроде area 2 filter-list in или area 1 filter-list out. Вторая же команда: area 2 filter-list out отфильтрует все маршруты из области 2. В данном примере маршрутная информация из второй области не попадёт ни в одну из областей.
В нашей топологии, показанной на рисунке, имеются две точки фильтрации, то есть два пограничных маршрутизатора:
При чем каждый из этих маршрутизаторов будет фильтровать разные сети. Также мы здесь используем обе ключевых слова in и out. На ABR1 напишем следующие prefix-list-ы:
ip prefix-list FILTER-INTO-AREA-34 seq 5 deny 10.16.3.0/24
ip prefix-list FILTER-INTO-AREA-34 seq 10 permit 0.0.0.0/0 le 32
А на ABR2
ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24
ip prefix-list FILTER-OUT-OF-AREA-0 seq 10 permit 0.0.0.0/0 le 32
Теперь проверив таблицу маршрутизации на R3, увидим, что маршрут до сети 10.16.3.0 отсутствует:
Теперь поясним, что мы сказали маршрутизатору. В конфигурации ABR1 первый prefix-list с действием deny совпадет только с маршрутом, который начинается на 10.16.3.0, а длина префикса равна 24. Второй же префикс соответствует всем остальным маршрутам. А командой area 34 filter-list prefix FILTER-INTO-AREA-34 in сказали отфильтровать все сети, которые поступают в 34 область. Поэтому в базе OSPF маршрута в сеть 10.16.3 через R1 не будет.
На втором же маршрутизаторе пошли другим путём. Первый команда ip prefix-list FILTER-OUT-OF-AREA-0 seq 5 deny 10.16.2.0/23 ge 24 le 24 совпадет с маршрутами, который начинается на 10.16.2.0 и 10.16.3.0, так как указан /23. На языке списка префиксов означает взять адреса, которые могут соответствовать маске 255.255.254.0, а длина префикса адреса равна 24. А командой area 0 out сказали отфильтровать все LSA 3 типа, которые исходят из области 0. На первый взгляд кажется сложным, но если присмотреться, то все станет ясно.
Фильтрация маршрутов в OSPF через distribute-list
Фильтрация LSA третьего типа не всегда помогает. Представим ситуацию, когда в какой-то области 50 маршрутизаторов, а нам нужно чтобы маршрутная информация не попала в таблицу только 10 роутеров. В таком случае фильтрация по LSA не поможет, так как он фильтрует маршрут исходящий или входящий в область, в нашем случае маршрут не попадёт ни на один маршрутизатор, что противоречит поставленной задаче.
Для таких случаев предусмотрена функция distribute-list. Она просто не добавляет указанный маршрут в таблицу маршрутизации, но в базе OSPF маршрут до сети будет.
В отличии от настройки distribute-list в EIGRP, в OSPF нужно учесть следующие аспекты:
Команда distribute-list требует указания параметров in | out, но только при применении in фильтрация будет работать.
Для фильтрации команда может использовать ACL, prefix-list или route-map.
Можно также добавить параметр interface interface-type-number, чтобы применить фильтрацию для конкретного интерфейса.
Внесем некоторые изменения в конфигурацию маршрутизатора R3, чтобы отфильтровать маршрут до сети 10.16.1.0:
Как видно на выводе, до применения prefix-list-а, в таблице маршрутизации есть маршрут до сети 10.16.1.0. Но после внесения изменений маршрут исчезает из таблицы, но вывод команды show ip ospf database | i 10.16.1.0 показывает, что в базе OSPF данный маршрут существует.
Фильтрация маршрутов на ASBR
Как уже было сказано в начале материала, ASBR это маршрутизатор, который стоит между двумя разными автономными системами. Именно он генерирует LSA пятого типа, которые включают в себя маршруты в сети, находящиеся вне домена OSPF.
Топология сети показана ниже:
Конфигурацию всех устройств из этой статьи можно скачать в архиве по ссылке ниже.
Скачать конфиги тестовой лаборатории
Как видно из рисунка, у нас есть два разных домена динамической маршрутизации. На роутере ASBR настроена редистрибюция маршрутов, то есть маршруты из одно домена маршрутизации попадают во второй. Нам нужно отфильтровать маршруты таким образом, чтобы сети 172.16.101.0/24 и 172.16.102.0/25 не попали в домен EIGRP. Все остальные, включая сети точка-точка, должны быть видны для пользователей в сети EIGRP.
Для фильтрации Cisco IOS нам дает всего один инструмент route-map. О них мы подробно рассказывали в статье и фильтрации маршрутов в EIGRP.
Можно пойти двумя путями. Либо запрещаем указанные маршруты, в конце добавляем route-map с действием permit, который разрешит все остальные, либо разрешаем указанным в списке префиксов маршруты, а все остальное запрещаем (имейте ввиду, что в конце любого route-map имеется явный запрет deny).
Покажем второй вариант, а первый можете протестировать сами и поделиться результатом.
Для начала создаем списки префиксов с разрешёнными сетями:
ip prefix-list match-area0-permit seq 5 permit 172.16.14.0/30
ip prefix-list match-area0-permit seq 10 permit 172.16.18.0/30
ip prefix-list match-area0-permit seq 15 permit 172.16.8.1/32
ip prefix-list match-area0-permit seq 20 permit 172.16.4.1/32
ip prefix-list match-area0-permit seq 25 permit 172.16.48.0/25
ip prefix-list match-area0-permit seq 30 permit 172.16.49.0/25
ip prefix-list match-area3-permit seq 5 permit 172.16.103.0/24 ge 26 le 26
Еще раз отметим, что фильтрация LSA Type 5 делается только на ASBR маршрутизаторе. До внесения изменений на маршрутизаторе R1 видны сети до 101.0 и 102.0:
Применим изменения на ASBR:
Проверим таблицу маршрутизации R1 еще раз:
Как видим, маршруты в сеть 101.0 и 102.0 исчезли из таблицы.
На этом, пожалуй, завершим это материал. Он и так оказался достаточно большим и сложным. Удачи в экспериментах!
Сегодняшняя статья будет посвящена основному протоколу динамической маршрутизации – BGP (Border Gateway Protocol). Почему основному? – Потому что с именно с помощью BGP организована топология всего Интернета.
Итак, в данной статье разберем следующие моменты:
Основные термины протокола BGP
Принципы работы протокола BGP
Типы сообщений протокола BGP
Видео: Основы BGP за 7 минут
Терминология
Когда речь идёт BGP, первое на чем необходимо остановиться - это понятие автономной системы AS(Autonomus System). Автономная система - это совокупность точек маршрутизации и связей между ними, объединенная общей политикой взаимодействия, которая позволяет этой системе обмениваться данными с узлами, находящимися за ее пределами.
AS характеризуется (с недавних пор 32 битным) номером ASN (Autonomus System Number) и пулом IP-адресов. Выдачей и того и другого занимается организация IANA (Internet Assigned Numbers Authority), делегируя контроль за распределением ASN и других интернет ресурсов, региональным регистраторам.
Связность автономных систем достигается благодаря статической или динамической маршрутизации.
Со статической маршрутизацией всё просто. Вы заходите на устройство и вручную прописываете маршрут до его ближайшего соседа. На практике, связать даже 10 маршрутизаторов между собой уже представляется довольно сложной задачей.
Поэтому для больших сетей придумали динамическую маршрутизацию, при которой устройства автоматически делятся друг с другом информацией об имеющихся у них маршрутах и, более того, подстраиваются под изменения топологии.
Как известно, протоколы динамической маршрутизации классифицируются по двум основным признакам:
Тип работы протокола относительно AS
IGP (Interior Gateway Protocol) – работают внутри автономной системы. Сюда относятся: RIP, OSPF, EIGRP, IS-IS
EGP (Exterior Gateway Protocol) – работают вне автономных систем и обеспечивают их связность. Сюда относится BGP
Алгоритм работы протокола
Distance-Vector - знает маршруты только до своих ближайших соседей и обменивается с ними таблицей маршрутизации. (RIP, EIGRP)
Link State – знает всю топологию сети и обменивается таблицей топологии со своими соседями (OSPF, IS-IS)
Очевидно BGP не может быть Link State протоколом. Только представьте себе сколько автономных систем в Интернете, любой маршрутизатор просто выйдет из строя если получит такое количество информации.
Итак, BGP – это протокол внешней маршрутизации, использующийся для соединения двух AS. Схема выглядит примерно так:
Так как на BGP возложена великая задача – соединение автономных систем во всем Интернете, то он должен быть очень надежным. Для этих целей, в самом начале работы, BGP-маршрутизатор инициирует установление TCP сессии на 179 порт к своему соседу, происходит стандартных обмен SYN и ACK.
Соединения по протоколу BGP должно быть абсолютно согласовано администраторами автономных систем, желающих организовать стык. Если, скажем, администратор AS402 запустил процесс BGP на маршрутизаторе BR2 (Border Router), указав в качестве соседа BR1 и его ASN, а администратор AS401 никаких действий не произвел, то TCP-сессия не поднимется и системы так и останутся несвязными. Кроме того, должны соблюдаться следующие условия:
179 порт не блокируется ACL (Access Control List)
Маршрутизаторы пингуют друг друга
При запуске BGP процесса ASN удаленной стороны был указан верно
RouterID не совпадают
Если TCP-сессия установлена успешно, то BGP-маршрутизаторы начинают обмен
сообщениями OPEN, в котором сообщают свои ASN, RouterID и Hold timer. Hold timer это время, в течение которого будет поддерживаться TCP-сессия. Если условия, перечисленные ранее, не соблюдаются, например не совпадает информация о номере AS, то сообщением NOTIFICATION маршрутизатор, получивший неверный ASN уведомит об этом своего соседа и сбросит TCP-сессию.
Если же все условия соблюдаются, то маршрутизаторы, с определенным интервалом, начинают высылать друг другу сообщения KEEPALIVE, означающие подтверждение параметров, принятых в OPEN и уведомление “я ещё жив”.
Наконец, маршрутизаторы могут приступать к обмену маршрутной информацией по средствам сообщения UPDATE. Структура данного сообщения делится на две части:
Path Attributes (Атрибуты пути). Здесь указывается из какой AS поступил маршрут, его происхождение и Next Hop для данного пути.
NRLI (Network Layer Reachability Information). Здесь указывает информация непосредственно о сетях, подлежащих добавлению в таблицу маршрутизации, т.е IP-адрес сети и ее маска.
Сообщение UPDATE будет передаваться каждый раз, когда один из маршрутизаторов получит информацию о новых сетях, а сообщение KEEPALIVE на протяжении всей TCP-сессии.
Именно таким образом и работает маршрутизация во всем Интернете. Истории известно множество инцидентов, когда неправильная работа протокола BGP приводила к сбоям обширных частей глобальной сети, поэтому недооценивать его важность категорически нельзя.