По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌 В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как 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.
img
Сетевые пользователи часто сталкиваются с необходимостью наличия статического общедоступного IP-адреса, например, при настройке веб-сервера, лаборатории с доступом через Интернет или даже при настройке почтового сервера. В таких случаях приходиться либо покупать новый интернет-пакет, включающий общедоступные IP-адреса, либо покупать новый пул статических общедоступных адресов у провайдера. Однако начиная с Сisco IOS 12.4 и далее на маршрутизаторах Cisco можно настроить протокол DDNS (Dynamic DNS), который позволяет обновлять запись DNS при изменении IP – адреса маршрутизатора-следовательно, требование к статическому IP-адреу смягчается. На приведенной ниже диаграмме показано функционирование службы DDNS: Ниже приведено краткое описание работы DDNS с Cisco IOS: Для регистрации у провайдера DDNS необходимо создать учетную запись. Настройте Интернет-маршрутизатор Cisco для работы в качестве клиента DDNS. Поставщик DNS создает уникальное доменное имя, указывающее на текущий динамический IP-адрес на Интернет-маршрутизаторе Cisco. При перезагрузке интернет-маршрутизатора или изменении динамического IP-адреса он получает новый IP-адрес от провайдера. Клиент DDNS уведомляет сервер DDNS, и запись DNS обновляется с новым общедоступным IP-адресом. Когда Интернет-пользователь хочет получить доступ к «test.dyndns.org», он отправляет DNS-запрос. DDNS отвечает на запрос DNS, предоставляя IP-адрес 100.100.100.1 Интернет-маршрутизатора. Как только пользователь получает динамический общедоступный IP-адрес интернет-маршрутизатора (100.100.100.1), пользователь может связываться с интернет-маршрутизатором через его вновь назначенный IP-адрес. Ниже приведена конфигурация маршрутизатора Cisco для поддержки службы DDNS. Шаг № 1 - Включите поиск DNS и настройте сервер IP-имен HQ# configure terminalHQ(config)# ip domain-lookup HQ(config)# ip name-server 4.4.4.4 HQ(config)# ip name-server 8.8.8.8 Шаг № 2 - Затем определите метод обновления DDNS: HQ(config)# ip ddns update method dyndns Шаг № 3 - В этом сценарии мы будем использовать HTTP в качестве метода обновления в конфигурации, чтобы указать URL-адрес, который маршрутизатор будет использовать для связи с поставщиком DDNS с новым публичным динамическим IP - адресом при изменении. HQ(DDNS-update-method)# HTTP add http://username:password@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a> Шаг № 4 - Далее мы устанавливаем интервал обновления, чтобы гарантировать, что FQDN обновляется как можно чаще. Конфигурация параметров интервала обновляется до 1 дня, 0 часов, 0 минут и 0 секунд. HQ(DDNS-HTTP)# interval maximum 1 0 0 0 Шаг № 5 - Наконец, установите FQDN, которое будет обновляться, и включите службу DDNS на общедоступном интерфейсе (в этом сценарии будет использоваться Dialer0): HQ(DDNS-update-method)# interface dialer0 HQ(config-if)# ip ddns update hostname test.dyndns.org HQ(config-if)# ip ddns update dyndns Для отладки DDNS введите следующие команды HQ#debug ip ddns update
img
Hiya! Merion Metrics our call stats (CDR) application for Asterisk, it shows the most important diagrams and call graphs as well as call history in an easy and convenient format. Showing call stats this way makes them easy to understand for everyone - from CEO to an office manager About Merion Metrics Short description of Merion Metrics: Full statistics - the most important info only: date, time, source and destination of a call, as well as it’s recording; Free trial - try the whole spectrum of these features - completely for free; Easy and quick installation - we are always here to help you; Cross-platform - developed in Java. Compatible with any UNIX platform; For supervisors - Got tired of heavy and awkward CDR interface in FreePBX? Or maybe you experienced something similar with CDR Viewer? we know that feeling; Easy to export in PDF and CSV - export all your calls into PDF and send it over to your colleagues in an easy readable format; Try Merion Metrics for free: Try Merion Metrics Merion Metrics Installation Attention! You should to have a license key from our support team at this point. You can get it by follow link: https://asterisk.merionet.ru/merionmetrics Of course for your convenience we have a step by step video guide. Enjoy :) Installation video - guide Installation guide by plain text System Requirements RAM: 256 MB min CPU: Pentium 2 266 МГц + минимум Java Runtime Environment (JRE): version 8+ Browser: Internet Explorer 9+ Preparation Firstly, connect to your Asterisk via SSH using user root. Directory creation for the app Run the following commands: mkdir /home/merionstat Upload app distro MerionMonitoring-*.*.*.jar into the directory you’ve just created: /home/merionstat. You can do that using WinSCP, for example. Important: App distro will have a certain version number. Here, in the installation guide, we always put version number as MerionMonitoring-*.*.*.jar. In your case it will be something like MerionMonitoring-1.1.9.jar. SQL user creation Follow the link that will generate an uncrackable password and right it down on save it somewhere. After that, execute the following command sequence: mysql CREATE USER 'interface'@'localhost' IDENTIFIED BY 'your_password'; GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY 'your_password'; Where your_password - some freshly generated password from the link above пароль. For example: mysql CREATE USER 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz'; GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'localhost' IDENTIFIED BY '6nzB0sOWzz'; And yet another reminder – save your password somewhere else. Call recordings directory For sake of playing call recordings through our app, you have to do the following: Generate another password via our password generator and save it;. Execute the following commands: mkdir /var/www/html/generated_password chown asterisk:asterisk /var/www/html/generated_password chmod 775 /var/www/html/generated_password For example: mkdir /var/www/html/5v9MpbtUA8 chown asterisk:asterisk /var/www/html/5v9MpbtUA8 chmod 775 /var/www/html/5v9MpbtUA8 Open file /etc/fstab and add there the following sequence: /var/spool/asterisk/monitor/ /var/www/html/generated_password/ none rbind 0 0 For example: /var/spool/asterisk/monitor/ /var/www/html/5v9MpbtUA8/ none rbind 0 0 Save all the changes in fstab file. After that, execute the following command in CLI: mount -a Start Application launch Run the following commands: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar & Right after command’s execution press Enter. Application setup The first connection After launching .jar archive, please open the following address in your web-browser: http://your_IP_address:7070/#!/config (You can use any browser, we recommend using Google Chrome). Once it opened, enter your license key – you can get it from our support engineer. Click “Check the license”. If you encounter any kind of a problem during that phase, please address it to our technical support team: helpdesk@merionet.ru. After that you have to pass the initial authorization, and to do that, you need to use the following credentials: admin/IEJu1uh32 On the next step you’ll need to configure database connection. If you are using Asterisk IP - PBX, just follow the guide: Database - mysql or mariadb; DB host: If your DB installed on the same server as our application - localhost; If your DB installed on some kind of external server - IP_address_of_your_database; DB port - is being set up automatically, so please change it only if your DB is listening for requests on another port; DB connection string - leave this without changes; Table name - In case of Asterisk it’s cdr; Scheme - that should be the name of database, for Asterisk it’s asteriskcdrdb; User - You created the user some time ago in “SQL user creation” part of this guide. If you copied all the commands without any changes – that would be interface; Password - the one you’ve probably generated using our password generator; Voice recordings host - link like http://your_ip_address/generated_password/, where generated_password is a sequence you created on a previous stage Call recordings directory. So, it’s gonna be something like http://192.168.1.7/5v9MpbtUA8/; Station type - Asterisk; After you finish all the above, click “Connect”. If something went wrong, address the issue to our support team helpdesk@merionet.ru. On the next step, you have to match field name in the table with it’s actual meaning. In case of Asterisk you can leave everything as it is. At the bottom of this page click the button “Set the matches” and “Launch the Application”. Our app will redirect you to the application’s initial page. By default, administrator’s login and password are: admin/admin Known issues Application is already launched If you can’t open the app using the default link http://IP_ADDRESS:7070/#!/config, please check if it wasn’t launched before. To do so, please run the command below: ps aux | grep Merion Analyze the command output: root 4919 0.1 13.1 2120384 801784 ? Sl Dec11 19:12 java -jar MerionMonitoring-*.*.*.jar If you see something similar, you have to kill the process using it’s PID (marked with orange in output example above). So execute the following command: kill -9 4919 Check the output again: ps aux | grep Merion If the one you’ve seen before is gone, then you can try to lauch it again: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar & Database on the external server If you are connecting to an external data base, you need to add some additional configuration for MySQL settings, that you’ve done in “SQL user creation”. You might need it if you install call stats app on a different server, not the one you have Asterisk installed on. In this case you need to run the following commands on the server where you have your DB (usually it’s your Asterisk server): mysql GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'IP_адрес_интерфейса' IDENTIFIED BY ''your_password'; Where: your_password - password generated with our our tool; Call_stats_app_IP_ADDRESS - IP-address of the server where you decided to install our Call Stats Application. For example: mysql GRANT SELECT, CREATE, INSERT ON asteriskcdrdb.* TO 'interface'@'192.168.1.78' IDENTIFIED BY '6nzB0sOWzz'; Also, please check that the following ports are open: 3306 - for MySQL and MariaDB; 5432 - for PostgreSQL. Slow data loading If you are experiencing some issues with data download – it might be related to the big size of your database. We recommend to launch our app (.jar file) with some additional keys. According to the “Application launch”, run the following command: cd /home/merionstat nohup java -jar MerionMonitoring-*.*.*.jar -Xms128m -Xmx256m & Where: -Xms128m - minimal amount of RAM available for the app. In our example – it’s 128 Megabytes. -Xmx256m - maximum amount of RAM available for the app. In our example – it’s 256 Megabytes; How to send a request to our support team? If you are experiencing any technical issues with configuration of our app – we will definitely help you. We’ll need the files from /home/merionstat directory – the one where you’ve put our distro MerionMonitoring-*.*.*.jar, according to step “Directory creation for the app”. Depending on the phase where you’ve encountered any technical issues, you might have the following files there: columns_mapping.cfg configuration.properties nohup.out Please send us those files and description of your issue – we’ll try to help you. Telegram - @merion_support_bot Email - helpdesk@merionet.ru
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59