По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! Мы продолжаем знакомить вас с бесплатным дайлером GoAutodial и сегодня расскажем, как создать простейшую компанию, загрузить в неё лидов для обзвона и, собственно, начать уже пользоваться благами данного решения.
Предисловие
В нашей прошлой статье мы показали пошаговую установку GoAutoDial и остановились на том, что получили доступ к вэб-интерфейсу администратора.
Не лишним будет отметить, что помимо интерфейса администратора, GoAutoDial CE 3.0 устанавливает ещё кучу полезных дополнительных интерфейсов. Ниже приводим таблицу всех доступов и дефолтные пароли всех интерфейсов, которые становятся доступными после установки:
Доступы
Логин
Пароль
MySQL (mysql -u root -p) http://IP-адрес_сервера/phpmyadmin/
root
vicidialnow
Limesurvey (Опросы) http://IP-адрес_сервера/limesurvey/admin/admin.php
admin
kamote1234
Интерфейс администратора – http://IP-адрес_сервера/
admin
goautodial
Интерфейс агента - http://IP-адрес_сервера/agent/
с agent001 до agent020
goautodial
Учётная запись (SIP)
с 8001 до 8020
goautodial
Настройка
Теперь, когда мы разобрались с доступами, переходим к настройке. Пока что нас интересует интерфейс администратора, поэтому просто вписываем адрес нашего сервера в адресную строку любимого браузера и вводим дефолтные реквизиты доступа: admin/ goautodial. Нас встречает довольно симпатичный дашборд:
Управление и навигация в интерфейсе администратора осуществляются с помощью панели задач, которая находится слева. Первое, что необходимо сделать, прежде чем мы сможем начать использовать GoAutoDial по назначению - это, конечно, настройка внешней линии (trunk) для звонков в PSTN. В GoAutoDial это называется - Carriers.
Итак, наводимся на панельку слева и выбираем Admin Settings → Carriers:
Перед нами открывается пошаговый помощник добавления новой внешней линии. Выберем тип Manual и продолжим:
В GoAutoDial доступно два вида аутентификации – IP Based и Registrationв зависимости от того, какой использует ваш VoIP провайдер – выберите подходящий. Заполняем все поля, как если бы создавали новый транк на FreePBX. Подробнее о том, как зарегистрировать транк – читайте в нашей статье. Заполняем все необходимые поля и кликаем Submit. Теперь линию нужно активировать, для этого открываем её ещё раз для редактирования и меняем предпоследний параметр в открывшемся к окне - Active с N на Y.
Отлично, теперь мы можем создать компанию обзвона. Для этого в панели слева выбираем Telephony → Campaigns. Откроется пошаговый помощник, который по умолчанию начнёт создавать компанию. Если вы хотите ввести ID и название компании самостоятельно - поставьте галочку в (check to edit campaign id and name):
Далее необходимо загрузить файл Excel, содержащий необходимые для обзвона данные. Главное- это сами номера и имена абонентов. Вы можете скачать пример нашего файла по ссылке, чтобы понять какой формат распознаёт GoAutoDial (поля не обязательно должны называться именно так как у нас в файле, также вы можете сделать дополнительные поля). Выберите код страны (в нашем случае это 7) и нажмите Next.
Скачать шаблон
Наконец, на последнем шаге выбираем метод набора (Есть автоматический - Auto-Dial, ручной - Manual и предиктивный - Predictive) и транк, который создавали ранее.
Чтобы загруженные лиды отображались корректно на русском, нужно зайти в mysql и для базы asterisk дать команду set names utf8;
Итак, наша компания обзвона готова к использованию, дело за малым. В первую очередь, нужно зарегистрировать на нашем сервере какую-нибудь конечную точку, например –софтфон Zoiper. В SIP Credentials нужно всего лишь ввести адрес нашего сервера, номер и пароль:
После чего, заходим в интерфейс соответствующего агента (в нашем случае agent005, так как его номер - 8005) и выбираем ранее созданную компанию.
Как только мы авторизовались, на наш софтфон поступит входящий звонок, необходимо его принять и не класть трубку, пока не закончится обзвон. Однако, на данном этапе звонки из компании обзвона поступать ещё не будут, так как наш агент стоит на холде. Чтобы начать обзвон – нужно нажать Resume
Можно также выбрать Manual Dial, набрать номер абонента вручную и нажать Dial Now.
После того, как разговор будет завершён можно указать результат звонка:
Виртуальные сети - это, в простейшем виде, создание логических топологий, построенных на основе физической топологии. Эти логические топологии часто называют виртуальными топологиями - отсюда и концепция виртуализации сети. Эти топологии могут состоять из одного виртуального канала в более крупной сети, называемого туннелем, или набора виртуальных каналов, которые кажутся полной сетью поверх физической сети, называемой наложением.
Этот раздел лекций начнется с обсуждения того, почему создаются и используются виртуальные топологии, проиллюстрированные двумя примерами использования. Во втором разделе этих лекций будут рассмотрены проблемы, которые должно решить любое решение виртуализации, а в третьем разделе будут рассмотрены сложности при виртуализации сети. Далее будут рассмотрены два примера технологий виртуализации: сегментная маршрутизация (segment routing-SR) и программно - определяемые глобальные сети (Software-Defined Wide Area Networks- SD-WAN).
Понимание виртуальных сетей
Виртуализация усложняет проектирование протоколов, сетей и устранение неполадок, так зачем же виртуализировать? Причины, как правило, сводятся к разделению нескольких потоков трафика в одной физической сети. Это может показаться подозрительно похожим на другую форму мультиплексирования, потому что это еще одна форма мультиплексирования. Основные различия между рассмотренными до сих пор формами мультиплексирования и виртуализацией заключаются в следующем:
Позволяет нескольким плоскостям управления работать с различными наборами информации о достижимости в рамках одной физической топологии;
Позволяет нескольким наборам достижимых пунктов назначения работать в одной физической топологии без взаимодействия друг с другом;
Рассмотренные до этого момента методы мультиплексирования были сосредоточены на том, чтобы позволить нескольким устройствам использовать одну физическую сеть (или набор проводов), позволяя каждому устройству взаимодействовать с любым другим устройством (при условии, что они знают друг о друге с точки зрения достижимости). Виртуализация направлена на разбиение одной физической сети на несколько доменов достижимости, где каждое устройство в домене достижимости может взаимодействовать с любым другим устройством в том же домене достижимости, но устройства не могут связываться между доменами достижимости (если нет какой-либо точки соединения между достижимостью домены).
На рисунке 1 показана сеть с виртуальной топологией, расположенной поверх физической топологии.
На рисунке 1 виртуальная топология была создана поверх физической сети, с виртуальным каналом [C,H], созданным для передачи трафика по сети. Чтобы создать виртуальную топологию, C и H должны иметь некоторую локальную информацию пересылки, отделяющую физическую топологию от виртуальной топологии, которая обычно проходит либо через E, либо через D. Это обычно принимает форму либо специального набора записей виртуального интерфейса в локальной таблице маршрутизации, либо таблицы виртуальной маршрутизации и пересылки (VRF), содержащей только информацию о виртуальной топологии.
Рассмотрение потока пакетов через виртуальную топологию может быть полезно для понимания этих концепций. Как бы выглядел поток пакетов, если бы C и H имели виртуальные интерфейсы? Рисунок 2 демонстрирует это.
На рисунке 2 процесс пересылки выполняется следующим образом:
A передает пакет к M.
C получает этот пакет и, исследуя свою локальную таблицу маршрутизации, находит, что кратчайший путь к месту назначения лежит через виртуальный интерфейс к H. Этот виртуальный интерфейс обычно называется туннельным интерфейсом; он выглядит с точки зрения таблицы маршрутизации, как и любой другой интерфейс маршрутизатора.
Виртуальный интерфейс, через который необходимо передать пакет, имеет инструкции перезаписи, которые включают добавление нового заголовка, заголовка туннеля или внешнего заголовка в пакет и пересылку полученного пакета. Исходный заголовок пакета теперь называется внутренним заголовком. C добавляет внешний заголовок и обрабатывает новый пакет для пересылки.
Теперь C исследует новый пункт назначения, которым является H (помните, что исходным пунктом назначения был M). H не подключен напрямую, поэтому C необходимо выяснить, как достичь H. Это называется рекурсивным поиском, поскольку C ищет путь к промежуточному месту назначения, чтобы доставить пакет к конечному месту назначения, но не к нему.
Теперь C поместит правильную информацию в пакет в заголовок link local, чтобы перенаправить трафик на E.
Когда E получает этот пакет, он удаляет внешнюю информацию о переадресации, Заголовок link local и пересылает трафик на основе первого заголовка C, помещенного в пакет, во время первоначального поиска. Этот внешний заголовок говорит E переслать пакет в H; E не видит и не включает исходный внутренний заголовок, помещенный на пакет A.
E добавит новый Заголовок link local, чтобы пакет был правильно переадресован в H, и передаст пакет по правильному интерфейсу.
Когда H получает пакет, он удаляет Заголовок link local и обнаруживает внешний заголовок. Внешний заголовок говорит, что пакет предназначен для самого H, поэтому он очистит этот заголовок и обнаружит исходный заголовок пакета или внутренний заголовок.
Теперь H посмотрит в своей локальной таблице маршрутизации и обнаружит, что M локально подключен. H поместит правильный Заголовок link local в пакет и передаст его через правильный интерфейс, чтобы пакет достиг M.
Если C и H используют VRF, а не туннельные интерфейсы, процесс в предыдущем списке изменяется на шагах 2 и 8. На шаге 2 C будет искать M как пункт назначения в VRF, связанном каналом [A, C]. Когда C обнаруживает, что трафик к M должен пересылаться через виртуальную топологию через H, он помещает внешний заголовок в пакет и снова обрабатывает пакет на основе этого внешнего заголовка через базовый VRF или, скорее, таблицу маршрутизации, представляющую физическую топологию. Когда H получает пакет, он удаляет внешний заголовок и снова обрабатывает пакет, используя VRF, к которому подключен M, для поиска информации, необходимой для пересылки трафика в его конечный пункт назначения. В этом случае интерфейс туннеля заменяется отдельной таблицей пересылки; вместо того, чтобы обрабатывать пакет через одну и ту же таблицу дважды с использованием двух разных адресатов, пакет обрабатывается через две разные таблицы пересылки.
Термин туннель имеет много различных определений; в этих статьях туннель будет использоваться для описания виртуального канала, где внешний заголовок используется для инкапсуляции внутреннего заголовка, и:
Внутренний заголовок находится на том же уровне или более низком уровне, чем внешний заголовок (например, заголовок Ethernet, переносимый внутри заголовка IPv6; обычно IPv6 переносится внутри Ethernet).
По крайней мере, некоторые сетевые устройства на пути, будь то виртуальные или физические, пересылают пакет только на основе внешнего заголовка.
Переход от виртуальных интерфейсов к VRFs концептуально отличается достаточно, чтобы породить различные описательные термины. Underlay -это физическая (или потенциально логическая!) топология, через которую туннелируется трафик. Overlay - это набор туннелей, составляющих виртуальную топологию. В большинстве случаев термины Underlay и Overlay не используются с отдельными туннелями или в случае службы, работающей через общедоступный Интернет. Сервис, который создает виртуальную топологию через общедоступный Интернет, часто называют сервисом over-the-top.
Опять же, эти термины используются в некоторой степени взаимозаменяемо и даже очень небрежно в более широком мире сетевой инженерии. На этом фоне пора перейти к вариантам использования, чтобы узнать о наборе проблем, которые необходимо решить виртуализацией.
Предоставление услуг Ethernet по IP-сети.
Хотя приложения не должны создаваться с использованием подключения Ethernet в качестве базового, многие из них это делают. Например:
Некоторые поставщики систем хранения данных и баз данных строят свои устройства с предположением, что подключение Ethernet означает короткое расстояние и короткую задержку, или они проектируют системы поверх проприетарных транспортных протоколов непосредственно поверх кадров Ethernet, а не поверх пакетов интернет-протокола (IP).
Некоторые продукты виртуализации включают в свои продукты предположения о возможности подключения, такие как надежность кеширования Ethernet для IP-адресов для шлюза по умолчанию и других доступных мест назначения.
Для таких приложений требуется то, что выглядит как соединение Ethernet между устройствами (физическими или виртуальными), на которых работают различные узлы или копии приложения. Помимо этого, некоторые сетевые операторы считают, что запуск большого плоского домена Ethernet проще, чем запуск крупномасштабного IP-домена, поэтому они предпочли бы создавать самые большие домены Ethernet, которые они могут ("коммутация, где можно, маршрутизация, где необходимо", была распространенная поговорка в те времена, когда коммутация выполнялось аппаратно, а маршрутизация выполнялась программно, поэтому коммутация пакетов выполнялась намного быстрее, чем их маршрутизация). Некоторые кампусы также построены с основной идеей - никогда не просить устройство коммутировать свой IP-адрес после подключения. Поскольку пользователи могут быть подключены к разным сегментам Ethernet в зависимости от их домена безопасности, каждый сегмент Ethernet должен быть доступен в каждой точке беспроводного доступа и часто на каждом порте Ethernet в кампусе.
Учитывая сеть, основанную на IP, которая предполагает Ethernet как один из многих транспортных средств, поверх которых будет работать IP, как вы можете обеспечить подключение Ethernet к устройствам, связанным по IP-сети? На рисунке 3 показаны задачи, которые необходимо решить.
На рисунке 3 процесс, работающий на A с IP-адресом 2001:db8:3e8:100::1, должен иметь возможность взаимодействовать со службой, работающей на B с IP-адресом 2001:db8:3e8:100::2, как если бы они находились в одном сегменте Ethernet (две службы должны видеть друг друга в обнаружении соседей и т. д.). Чтобы сделать проблему более сложной, служба на A также должна иметь возможность перемещаться в K без изменения своего локального кэша обнаружения соседей или маршрутизатора по умолчанию. Сама сеть, является маршрутизируемой сетью, работающей под управлением IPv6.
Что необходимо для выполнения требований?
Должен быть способ передачи кадров Ethernet по IP-сети, разделяющей серверы. Обычно это будет своего рода туннельная инкапсуляция, как описано в начале этого раздела. Туннелирование позволило бы принимать кадры Ethernet на C, например, инкапсулированные в какой-то внешний заголовок, чтобы их можно было транспортировать по маршрутизируемой сети. Когда пакет, содержащий кадр Ethernet, достигает D, этот внешний заголовок может быть удален, и кадр Ethernet пересылается локально. С точки зрения D, фрейм имеет локальное происхождение.
Должен быть способ узнать о пунктах назначения, доступных через туннель, и привлечь трафик в туннель. На самом деле это две отдельные, но взаимосвязанные проблемы. Привлечение трафика в туннель может включать запуск второй плоскости управления с ее собственными VRFs или добавление дополнительной информации в существующую плоскость управления об адресах Ethernet Media Access Control (MAC), доступных на каждом пограничном маршрутизаторе.
Может потребоваться перенести маркировку качества обслуживания (QoS) из внутреннего заголовка во внешний заголовок, чтобы трафик обрабатывался правильно при его пересылке.
Виртуальный частный доступ к корпоративной сети.
Почти в каждой организации есть какие-то удаленные сотрудники, либо на полную ставку, либо просто люди, которые перемещаются, и у большинства организаций есть какие-то удаленные офисы, где часть сотрудников работает вдали от главного офиса, чтобы напрямую взаимодействовать с местным организациями в некоторых отраслях, например, с покупателями или поставщиками. Все эти люди по-прежнему нуждаются в доступе к сетевым ресурсам, таким как электронная почта, системы путешествий, файлы и т. д. Эти службы, конечно, не могут быть доступны в общедоступном Интернете, поэтому необходимо предоставить какой-то другой механизм доступа. На рисунке 4 показаны типичное проблемное пространство.
В этом варианте использования есть две основные проблемы:
Как можно защитить трафик между отдельным хостом - B - и тремя хостами в небольшом офисе - C, D и E - от перехвата и чтения злоумышленником? Как можно защитить сами адреса назначения от попадания в публичную сеть? Эти проблемы связаны с некоторой защитой, которая, в свою очередь, подразумевает некоторую форму инкапсуляции пакетов.
Как можно управлять качеством работы пользователей в этих удаленных местах для поддержки передачи голоса по IP и других приложений в реальном времени? Поскольку провайдеры в Интернете не поддерживают QoS, необходимо обеспечить другие формы гарантии качества.
Таким образом, задача, которую необходимо решить, включает еще две общие проблемы.
Должен быть способ инкапсулировать трафик, передаваемый по общедоступной сети, без раскрытия исходной информации заголовка и без подвергания информации, содержащейся в пакете, для проверки. Самым простым решением этих проблем является туннелирование (часто в зашифрованном туннеле) трафика от A и F к граничному маршрутизатору в сети организации G, где инкапсуляция может быть удалена, а пакеты перенаправлены на A.
Должен быть способ объявить достижимые пункты назначения от G к удаленным пользователям, а также существование (или достижимость) удаленных пользователей к G и сети позади G. Эта информация о достижимости должна использоваться для привлечения трафика в туннели. В этом случае плоскости управления может потребоваться перенаправить трафик между различными точками входа и выхода в общедоступную сеть и попытаться контролировать путь трафика через сеть, чтобы обеспечить удаленным пользователям хорошее качество работы.
Подведем итоги
Два варианта использования, показанные выше, актуализируют два вопроса, которые должно решить каждое решение сетевой виртуализации:
Как трафик инкапсулируется в туннель, чтобы можно было отделить пакеты и информацию плоскости управления от базовой сети?
Решением этой проблемы обычно является некоторая форма инкапсуляции, в которую помещается исходный пакет, когда он передается по сети. Основное внимание при инкапсуляции - поддержка аппаратной коммутации в базовой сети, чтобы обеспечить эффективную пересылку инкапсулированных пакетов. Второстепенным соображением является размер формата инкапсулирующего пакета; каждый октет дополнительного заголовка инкапсуляции уменьшает объем полезной нагрузки, которую туннель может нести (если нет разницы между максимальной единицей передачи или MTU в сети, предназначенной для учета дополнительной информации заголовка, налагаемой туннелированием).
Примечание
Path MTU Detection (PMTUD) часто плохо определяет MTU инкапсулированных пакетов. Из-за этого часто требуется ручная настройка MTU в точке наложения заголовка туннеля.
Как пункты назначения достигаются через туннель, объявленный через сеть?
В более общих туннельных решениях туннель становится "просто еще одним звеном" в общей топологии сети. Пункты назначения, доступные через туннель, и дополнительная виртуальная связь просто включены как часть плоскости управления, как и любые другие пункты назначения и каналы. В этих решениях существует одна таблица маршрутизации или пересылки в каждом устройстве, и рекурсивный поиск используется для обработки пакета посредством пересылки в точке, где трафик входит в туннель или головной узел туннеля. Трафик привлекается в туннель путем изменения метрик таким образом, чтобы туннель был более желательным путем через сеть для тех пунктов назначения, которые оператор сети хотел бы получить через туннель. Это обычно означает в основном ручные решения проблемы привлечения трафика в туннель, такие как установка метрики туннеля ниже пути, по которому проходит туннель, а затем фильтрация пунктов назначения, объявленных через туннель, чтобы предотвратить объявления пунктов назначения, которые должны быть недоступны через туннель. На самом деле, если пункты назначения, достижимые через туннель, включают конечную точку туннеля (хвост туннеля), может образоваться постоянная петля маршрутизации, или туннель будет циклически переключаться между правильной переадресацией трафика и не переадресацией трафика вообще.
В решениях с overlay и over-the-top развертывается отдельная плоскость управления (или передается отдельная база данных с информацией о доступности для адресатов, достижимых в underlay и overlay в единой плоскости управления). Пункты назначения, доступные через underlay и overlay, помещаются в отдельные таблицы маршрутизации (VRF) на головной станции туннеля, а таблица, используемая для пересылки трафика, основана на некоторой форме системы классификации. Например, все пакеты, полученные на конкретном интерфейсе, могут быть автоматически помещены в оверлейный туннель, или все пакеты с определенным классом обслуживания, установленным в их заголовках пакетов, или весь трафик, предназначенный для определенного набора пунктов назначения. Механизмы полного наложения и верхней виртуализации обычно не полагаются на метрики для привлечения трафика в туннель на головной станции.
Еще одно необязательное требование - обеспечить качество обслуживания либо путем копирования информации QoS из внутреннего заголовка во внешний заголовок, либо путем использования какой-либо формы проектирования трафика для передачи трафика по наилучшему доступному пути.
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево.
Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree".
Азы Rapid spanning tree
Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов:
Отбрасывание;
Обучение;
Пересылка.
Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта.
Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет.
Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree.
Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree.
На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом.
Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree.
Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree.
BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита:
Topology change.;
Topology change acknowledgment.;
Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры:
Unknown;
Alternate / Backup port;
Root port;
Designated port.
Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree.
Что поменялось
BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить.
classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса.
Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах.
Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает.
Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port).
Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types:
Point-to-point (full duplex);
Shared (half duplex).
Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree.
Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root).
Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией.
После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние.
Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние.
Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding).
Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU.
Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D.
Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение.
Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding.
Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B?
Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D.
Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B.
Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree!
Что еще нового в rapid spanning tree?
Есть еще три вещи:
UplinkFast;
Механизм изменения топологии;
Совместимость с классическим связующим деревом.
Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding.
Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов.
Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии?
С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет:
Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.;
Он будет очищать MAC-адреса, которые изучаются на этих портах.;
До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.;
Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее:
Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.;
Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.;
Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети.
И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать!
В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.