По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как 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.
В данной статье будет произведен общий обзор одного из важнейших модулей для FreePBX – System Status
Настройка
В данный модуль администратор АТС попадает сразу после прохождения процедуры авторизации, и здесь можно найти следующую информацию:
Количество одновременных вызовов
Количество активных транков
Использование центрального процессора/жёсткого диска/сетевых ресурсов
Статус Asterisk/Apache/MySQL/SSH серверов
Статус основных компонент АТС
Общий вид данного модуля можно увидеть на скриншоте ниже:
Далее пройдемся по каждому разделу, начиная со статистики:
На графиках изображена по умолчанию статистика по зарегистрированным телефонам, транкам и активным звонкам. В данном случае – два транка онлайн, один зарегистрированный экстеншен, и ноль активных вызовов. На рисунке видно, что статистику можно вывести за час, день, неделю или месяц:
Далее можно в таком же виде посмотреть статистику по аптайму сервера с АТС, загрузку процессора, использование памяти, дискового пространства и использования полосы.
Конечно, данную информацию так же можно получить с помощью CLI – но, на мой взгляд, так удобнее и нагляднее.
Следующий раздел – System Overview
Так же очень важный раздел – здесь демонстрируется статус ключевых подсистем – сам Asterisk, MySQL, Apache (Web Server) и так далее. Кроме того, под надписью «Show New» находятся уведомления:
Количество модулей, доступных для обновления
«Неподписанные» модули (которые теоретически могут являть собой уязвимость)
Ошибки модулей
Ошибки в маршрутизации (например, очередей - Queues)
И многие другие. Кроме того – сразу виден номер версии FreePBX. В данном случае – 13.0.120
Следующий раздел – краткая статистика по аптайму и нагрузке на сервер
Так же в данном модуле есть возможность подключения необходимой информации по RSS (в Advanced Settings)
Кроме того, в Advanced Settings имеется возможность настройки собственного логотипа и дальнейшей кастомизации Dashboard.
Вопрос о балансировке нагрузки на WAN-линках встает довольно часто, и, к сожалению, в отличие от некоторых других вещей, которые можно настроить на оборудовании MikroTik быстро и безболезненно - в случае настройки Load Balancing придется немного постараться. Тема относительно сложная, наличие нескольких WAN-линков и задача по настройке балансировки нагрузки включает в себя настройку нескольких шлюзов и маршрутов по умолчанию, множество правил трансляции NAT и так далее.
Настройка маршрутизатора
Итак, в наличие у нас имеется один маршрутизатор MikroTik, который подключен к двум провайдерам - Тарс Телеком и Милайн на портах ether1 и ether2 соответственно, и локальной сетью на порту ether3. Трафик из локальной сети будет NATирован из обоих WAN портов и будет сбалансирован по нагрузке. Топология ниже:
Настраиваем локальные IP-адреса:
/ip address
add address=1.1.1.199/24 interface=ether1 comment="Tars"
add address=2.2.2.199/24 interface=ether2 comment="Meeline"
add address=192.168.1.1/24 interface=ether3 comment="LAN Gateway"
Настраиваем шлюзы по умолчанию:
/ip route
add dst-address=0.0.0.0/0 check-gateway=ping gateway=1.1.1.1,2.2.2.1
Настраиваем NAT на WAN портах для исходящего направления:
/ip firewall nat
add action=masquerade chain=srcnat comment="Tars" out-interface=ether1
add action=masquerade chain=srcnat comment="Meeline" out-interface=ether2
Если на данном этапе перестать настраивать роутер, то это будет являть собой пример настройки отказоустойчивости. Если один из линков “отвалится”, то вместо него будет использоваться второй. Однако, никакой балансировки нагрузки здесь нет и в помине, и, с экономической точки зрения, это является плохой идеей - вряд ли найдется компания, которая захочет платить абонентскую плату за второй канал и использовать его только в случае аварии.
Исходящая и входящая Mangle маркировка
Одной из типичных проблем при использовании более одного WAN-соединения является то, что пакеты принятые на одном WAN интерфейсе, могут тут же быть отправлены через другой WAN-интерфейс, что может, к примеру, сломать VPN-based сеть. Нам нужно чтобы пакеты “принадлежащие” одному и тому же соединению принимались и отправлялись через один и тот же WAN порт. В случае аварии у одного из провайдеров, все подключения на порту “умрут” и затем будут переподключены на другом WAN порту. Для этого необходимо промаркировать соединения:
/ip firewall mangle
add action=mark-connection chain=input comment="Tars Input" in-interface=ether1 new-connection-mark="Tars Input"
add action=mark-connection chain=input comment="Meeline Input" in-interface=ether2 new-connection-mark="Meeline Input"
Это поможет маршрутизатору отслеживать порт для каждого входящего подключения.
Теперь мы будем использовать отметку подключения для входящих пакетов для вызова отметки маршрутизации. Это отметка маршрутизации будет использована позднее на маршруте, который будет сообщать подключению через какой WAN-порт необходимо слать пакеты наружу.
add action=mark-routing chain=output comment="Tars Output" connection-mark="Tars Input" new-routing-mark="Out Tars"
add action=mark-routing chain=output comment="Meeline Output" connection-mark="Meeline Input" new-routing-mark="Meeline Telecom"
Помеченные подключения затем получают метку маршрута, так что роутер сможет маршрутизировать пакеты так, как нам необходимо. В следующем шаге мы настроим роутер таким образом, чтобы помеченные пакеты отправлялись наружу из корректного WAN-подключения.
Маркировка LAN маршрута
Понадобится также настроить несколько Mangle правил - они необходимы, чтобы сообщить роутеру о необходимости балансировки пакетов, которые отправляются из локальной сети. Сам механизм балансировки в этой статье не описывается, можно только сказать что происходить много операций хеширования - если же интересно копнуть глубже, то вы можете обратиться к официальной документации MikroTik. В соответствии с этими правилами маршрутизатор будет балансировать трафик приходящий на порт ether3 (LAN-порт), который направлен на любой нелокальный адрес в Интернете. Мы захватываем трафик в цепочке предварительной маршрутизации для перенаправления его на необходимый нам WAN-порт в соответствии с меткой маршрутизации.
Следующие команды балансируют трафик на LAN-интерфейсе через две группы:
add action=mark-routing chain=prerouting comment="LAN load balancing 2-0"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Tars" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/0
add action=mark-routing chain=prerouting comment="LAN load balancing 2-1"
dst-address-type=!local in-interface=ether3 new-routing-mark=
"Out Meeline" passthrough=yes per-connection-classifier=
both-addresses-and-ports:2/1
Настройка меток маршрутизации выше была выполнена точно такие же как и в предыдущем шаге и соответствуют тем маршрутам, которые будут созданы в следующем шаге.
Особые маршруты по умолчанию.
В данный момент у нас должны быть помечены соединения поступающие на WAN-порты и эти метки были использованы для создания меток маршрутизации. Балансировка нагрузки в LAN, описанная в предыдущем шаге, также создает метки маршрутизации в соответствии со следующим шагом, в котором будут созданы маршруты по умолчанию, которые будут захватывать трафик с данными метками маршрутизации.
/ip route
add distance=1 gateway=1.1.1.1 routing-mark="Out Tars"
add distance=1 gateway=2.2.2.1 routing-mark="Out Meeline"
Данные маршруты используются только при наличии необходимой метки маршрутизации. Непомеченные пакеты используют обычный маршрут по умолчанию.
Маршруты, относящиеся к Тарс Телеком получают метку подключения, которая вызывает метку маршрутизации. Эта метка маршрутизации совпадает с меткой в маршруте выше и обратный пакет выходит из того же интерфейса, на котором был получен изначальный пакет.
Заключение
Итого, какие шаги по настройке роутера были выполнены:
Маркировка новых подключений в WAN
Соединения с этой маркировкой получают метку маршрутизации
Исходящий из локальной сети трафик балансируется с теми же метками маршрутизации
Метки маршрутизации соответствуют маршрутам по умолчанию и отправляются из соответствующего интерфейса
Если количество WAN-линков более 2 - необходимо проделать такие же действия для остальных подключений.
Итого, теперь у вас настроена балансировка трафика для двух WAN-соединений.