По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перед тем как говорить о технологии 802.1ad (QinQ) нужно вспомнить о технологии 802.1q. Если коротко, то это технология тегирования трафика, то есть деление его на 2 уровне модели OSI (так как на L3 сеть мы делим уже по маске)
Чем же отличается трафик обычный от тегированного спросите вы? Практически ничем, кроме добавления добавление тега в заголовок фрейма.
Размер такого тега всего 4 байта (32 бита) и он состоит:
TPID (Tag Protocol Identifier): на него уходит половина размера тега и это значение равно 0x8100 для 802.1q (VLAN) , а для 802.1ad(QinQ) заголовок выглядит так: 0x88a8.
TCI (Tag Control Information): на это поле уходит оставшийся половина 16 бит тега.
В него входит:
PCP(Priority) - 3-битное поле, которое относится к классу обслуживания IEEE 802.1p и сопоставляется с уровнем приоритета кадра. (3 бита)
Drop eligible indicator (DEI) (ранее CFI - Canonical Format Indicator) - Может использоваться отдельно или вместе с PCP для обозначения фреймов, которые могут быть отброшены при наличии перегрузки. (1 бит )
VID (VLAN Identifier) - VLAN ID . размером он в 12 бит ,а это значит что в него можно заложить 2^12 = 4096 VLAN . Но на самом деле меньше ,так как 0 и 4095( 0x000 и 0xFFF) зарезервированы , в итоге 4094 получается. (12 бит)
Зачем же понадобилась технология двойного тегирования QinQ? Вот тут возникает как раз ограничение поля VID на количество VLAN (4094) и тут на помощь приходит стандарт 802.1ad, который позволяет уже увеличить количество VLAN. (4094*4094 = 16760836 - больше пока никому не потребовалось.)
Ниже укажу dump трафика вначале обычного 802.1q:
А потом 802.1ad наш QinQ о котором как раз и шла речь:
Как видно из вывода, тип трафика указывается в самом фрейме. (см картинки выше), а далее идёт тег и в случае QinQ ещё один тег.
Практика
А теперь давайте немного попрактикуемся.
Клиенты VPC1 и VPC2 будут находиться в одной подсети, это было сделано для удобства.
VPC1 : 172.16.20.1/24
VPC2 : 172.16.20.2/24
Теперь первый Mikrotik, который будет отвечать за access и trunk порты
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=100
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
Mikrotik4 конфигурируется точно по такой же логике
/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=100
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
Теперь самое интересное: Mikrotik2
/interface bridge
add ether-type=0x88a8 name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 pvid=200 tag-stacking=yes
add bridge=bridge interface=ether2
/interface bridge vlan
add bridge=bridge tagged=ether1 vlan-ids=100
add bridge=bridge tagged=ether2 vlan-ids=200
Mikrotik3
/interface bridge
add ether-type=0x88a8 name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=ether2 pvid=200 tag-stacking=yes
/interface bridge vlan
add bridge=bridge tagged=ether2 vlan-ids=100
add bridge=bridge tagged=ether1 vlan-ids=200
Я указал только простую настройку для понимания настройки его на оборудовании Mikrotik. Не стал копать глубоко и указывать что и зачем каждый заголовок значит, так как моей задачей было указать основную настройку оборудования и по какой логике работает Q-in-Q, и с этой задачей я справился. Удачи!
Одной из основных составляющих IP – PBX на базе Asterisk являются SIP – транки в сторону провайдера и оконечные телефонные аппараты, или как их принято называть «пиры» (peers). Сегодня мы расскажем о способе автоматизации мониторинга состояния транков и пиров, с отправлением на почту системного администратора.
Мониторинг пиров
Итак, начнем с мониторинга состояния пиров. Для этого мы напишем небольшой bash – скрипт. Предположим, что у нас есть 3 площадки, А, B и C. АТС Asterisk находится на площадке A. Предварительно, перед началом работы, создадим 2 файлы: первый – для логов нашего скрипта, а второй, будет служебным, и будет использоваться только в рамках исполнения скрипта. Внутри каждого скрипта, мы будем писать комментарии к каждой из его строк.
Скачать скрипт мониторинга пиров вы можете по ссылке ниже:
Скачать скрипт мониторинга пиров
[root@asteriskpbx]# touch /home/admin/log_mail.txt
[root@asteriskpbx]# touch /home/admin/message.txt
Далее, создаем переменные для нашего скрипта:
#!/bin/sh
LOGSIZE=`ls -l /home/admin/log_mail.txt | awk '{ print $5 }'` //проверяем размер файла с логами
problempeers=`/usr/sbin/asterisk -rx 'sip show peers' | grep UNKNOWN` //выводим командой 'sip show peers' через консоль Asterisk, и затем, с помощью команды grep UNKNOWN фильтруем пиры, чтобы отобразить только те, состояние которых является UNKNOWN
GWB=`ping -c4 11.22.33.44 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //по протоколу ICMP, пингуем IP – адрес шлюза на удаленной площадке четырьмя пакетами. Если все ОК, и шлюз доступен, до значение переменной будет равно 4. В противном случае, оно будет равно 0.
GWC=`ping -c4 44.33.22.11 | grep 'received' | awk -F',' '{ print $2}' | awk '{ print $1}'` //аналогичным образом пингуем шлюз на площадке C
ResultB="" //служебная переменная
ResultC="" //служебная переменная
FILENAME=/home/admin/message.txt //записываем в переменную путь к лог- файлам
LOGFILE=/home/admin/log_mail.txt
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //выводим текущую дату и время в формате дд.мм.гггг чч:мм:сс
echo "$problempeers" > /home/admin/message.txt //записываем содержимое переменной problempeers в служебный файл. В этой переменной содержится результат вывода команды по статусу пиров.
FILESIZE=$(stat -c%s "$FILENAME") //проверяем размер служебного файла message.txt. Если в нем есть какая-либо информация, значит есть проблемы с пирами (имеются в статусе UNKNOWN), если он пустой, то все ОК.
На этом этапе, мы сформировали все необходимые переменные и у нас имеются все необходимые для формирования письма (если надо) на email системному администратору. Перейдем к исполнительной части скрипта:
if [ $GWB -eq 0 ]; then //если число ответов шлюза на площадке B на пинг равно 0, то запускаем процесс формирования письма
ResultB ="на площадке B НЕ ДОСТУПЕН!" //формируем часть текста. Мы ее включим в заголовок письма
else
ResultB ="" //если все таки шлюз ответил на пинг, то оставляем переменную пустой
fi
if [ $GWС -eq 0 ]; then //если число ответов шлюза на площадке С на пинг равно 0, то запускаем процесс формирования письма
ResultС="на площадке С НЕ ДОСТУПЕН!" //по аналогии. Указываем в заголовок, что роутер C недоступен
else
ResultС ="" //если все ОК, то оставляем переменную пустой
fi
if [ $FILESIZE -ne 1 ]; then //если наш служебный файл message.txt не пустой, то проверяем следующее условие
if [ $GWB -eq 0 ] || [ $GWC -eq 0 ]; then //если хотябы один из роутеров недоступен по пинг, то переходим к следующему пункту скрипта
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутер $ResultB $ResultC!" -r "info@merionet.ru" youremail@some.ru </home/admin/message.txt && //отправляем на почту письмо, где указываем, что у нас есть проблемы с пирами, и, если какой-то из роутеров не доступен, указываем это. В теле письма мы отправляем вывод недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //параллельно с отправкой письма, записываем в лог файл запись, что у нас есть проблемы с пирами (в вывод так же можно добавить с какими именно)
else
echo "$problempeers"| mailx -s "Проблемы с SIP пирами | Роутеры ДОСТУПНЫ!" -r "info@merionet.ru" youremail@some.ru < /home/admin/message.txt && //если оба наших роутера доступны, то мы просто формируем письмо, в котором указываем перечень недоступных пиров.
echo "FAIL :: $DATE :: Some problems with phones" >> "$LOGFILE" //аналогично вносим запись в лог – файл.
fi
else
echo "OK :: $DATE :: all phones are OK" >> "$LOGFILE" //если служебный файл пустой, то мы вносим запись в лог – файл что все хорошо и проверка успешно прошла.
fi
if [ $LOGSIZE -ge 150000 ]; then //елси размер нашего лог – файла больше или равен 150 КБ, то мы очищаем этого (можете подкрутить эту величину, как вам угодно.)
cat /dev/null > /home/admin/log_mail.txt
fi
cat /dev/null > /home/admin/message.txt //на выходе чисти служебный файл message.txt, для последующего использования
Теперь давайте проверим, что приходит нам на почту в случае, если несколько пиров стали недоступны, но все роутеры доступны:
Мониторинг транков
Отлично, перейдем к формированию скрипта по мониторингу транков. Здесь все несколько проще, и мы просто будем сравнивать общее количество транков, и количество зарегистрированных транков:
Скачать сам скрипт можете ниже:
Скачать скрипт мониторинга транков
#!/bin/bash
ALLTRUNKSMINIMUM="`/usr/sbin/asterisk -rx "sip show registry"`" //выводим регистрации по протоколу SIP
ALLTRUNKS=`echo "$ALLTRUNKSMINIMUM" |grep "SIP registrations" |awk '{print $1}'` //численное обозначение всех имеющихся транков
REGTRUNKS=`/usr/sbin/asterisk -rx "sip show registry" |grep Registered |wc -l` //численное обозначение всех зарегистрированных транков
DATE="`date +%d.%m.%Y" "%H:%M:%S`" //формируем текущую дату, для логов
LOGFILE=/home/admin/log_mail.txt //для лог – файла, указываем тот же файл, что и для скрипта по мониторингу пиров
if [ "$REGTRUNKS" -lt "$ALLTRUNKS" ]; then //если число зарегистрированных транков меньше чем число всех транков
sleep 5 //ждем 5 секунд
echo `/usr/sbin/asterisk -rx "sip reload"` \ перезагружаем модуль SIP, в целях перерегистрации. Эта команда автоматически перерегистрирует транк на оборудовании провайдера, после чего, он, зачастую, начинает работать.
sleep 5 //ждем еще 5 секунд
VAR=`/usr/sbin/asterisk -rx "sip show registry"` //после перезагрузки SIP модуля, снова смотрим SIP –регистрации. Если данная команда не дала своих результатов, то в переменной VAR будет записаны не работающие транки. Если она помогла, то на email админу придет рабочий вывод всех зарегистрированных транков. Это весьма удобно.
echo "$VAR"| mailx -s "Мониторинг транков" -r "info@merionet.ru" youremail@some.ru // отправляем письмо на почту системного администратора, с выводом SIP регистраций после перезагрузки модуля
else
echo "OK :: $DATE :: all trunks are OK" >> "$LOGFILE" //если число зарегистрированных транков, равно общему числу, то записываем в лога файл соответствующую запись.
fi
Теперь, когда мы автоматизировали процессы мониторинга состояния на Asterisk, сделаем выполнение этих скриптов регулярным. Сохраним наши скрипты в формате .sh, можно сделать это, например, в Notepad ++. Сделаем выполнение мониторинг транков раз в 2 минуты, а выполнение мониторинга пиров раз в 10 минут. Перед загрузкой скриптов на сервер, дадим им необходимые права и, что очень важно, преобразуем скрипт в Linux формат:
[root@asteriskpbx]# dos2unix peer.sh //преобразуем скрипт для мониторинга пиров
[root@asteriskpbx]# dos2unix trunk.sh //преобразуем скрипт для мониторинга транков
[root@asteriskpbx]# chmod 777 peer.sh //дадим необходимые права обоим скриптам
[root@asteriskpbx]# chmod 777 trunk.sh
[root@asteriskpbx]# crontab -e
В открывшемся cron, задаем задачи для выполнения наших скриптов:
*/10 * * * * /bin/bash /home/peer.sh >/dev/null //исполнять файл раз в 10 минут
*/2 * * * * /bin/bash /home/trunk.sh >/dev/null //исполнять файл раз в 2 минуты
Вот и все. Теперь мы имеет достаточно простой, но порой очень нужный и эффективный мониторинг состояния транков и пиров на нашем Asterisk
Веб-разработчики являются неотъемлемой частью эпохи Интернета. Веб-сайты и мобильные страницы, с которых мы получаем большую часть нашей информации, совершаем покупки, бронируем билеты и так далее, созданы и управляются веб-разработчиками. Веб-разработчики - это люди, которые проектируют и разрабатывают веб-сайты и мобильные приложения. Они используют несколько языков программирования для реализации необходимых функций. Веб-приложение или мобильное приложение имеют множество различных компонентов, которые взаимодействуют друг с другом для создания всей функциональности системы. Из-за этого сложного характера веб-разработчиков можно разделить на Front-End, Back-End и Full-stack разработчиком.
Как стать веб-разработчиком
Front-End веб-разработчики также известны как разработчики на стороне клиента. Они работают над внешним видом и ощущением веб-приложения. Вы, наверное, не раз слышали эти модные аббревиатуры UX и UI, которые как раз обозначают User Experience (пользовательский опыт) и User Interface (пользовательский интерфейс), за которые ответственен фронтенд разработчик.
Back-End разработчики используют языки программирования и реляционные базы данных для интеграции внешнего интерфейса с внутренним. Со временем наборы умений фронт-энда и бэк-энда разработчиков пересекались, и в настоящее время индустрия предпочитает разработчиков с мастерством в обоих. Такие эксперты называются Full Stack Developers, и они обладают навыками как Front-End, так и Back-End разработки.
Давайте рассмотрим навыки, необходимые для того, чтобы стать веб-разработчиком.
1. Графика или пользовательский интерфейс (UI)
Знание графики или пользовательского интерфейса имеет большое значение для понимания эстетического аспекта веб-дизайна. Это позволяет выявлять и устранять проблемы совместимости между веб-браузерами при отображении страниц.
2. HTML, CSS, JavaScript
Это строительные блоки веб-разработки. Они позволяют разработчику создавать структуру, стиль и содержание веб-сайта. Дополнительное знание сторонних библиотек, таких как jQuery, LESS, Angular и React JS, крайне желательно. HTML определяет структуру представления страниц. CSS обеспечивает контроль над макетом, позволяя создавать точные секционные модули, а также позволяет разработчикам настраивать макет страницы, цвета, шрифты и добавлять эффекты анимации. JavaScript является продвинутым по своей природе, что помогает сделать веб-страницу более интерактивной. Он предлагает изысканные функции, которые помогают сделать веб-страницы более отзывчивыми. Зная DOM, JSON позволяет вам манипулировать Javascript кодом.
3. CMS
Система управления контентом (Content Management Systems) - это приложение, которое позволяет пользователям эффективно публиковать и управлять контентом веб-сайта. Это интуитивно понятный пользовательский интерфейс, который помогает в создании и изменении содержимого веб-страницы. Несмотря на то, что здесь не требуется опыта в программировании бэкэнда, знание HTML и CSS необходимо. В зависимости от используемой CMS вы можете реализовать расширенные функции, установив плагины и расширения. Wordpress, Joomla, Drupal, Magento, Laravel, Typo3, Serendipity, Chamilo - вот некоторые из них, которые стоит добавить в вашу базу знаний.
4. UX
Пользовательский опыт не имеет прямого отношения к знаниям о дизайне; напротив, это относится к аналитическому и техническому пониманию того, как должно работать веб-приложение. Это понимание факторов, которые удерживают пользователей на сайте, помогают им найти то, что они ищут, и оптимизируют поддерживаемые функции.
5. Языки программирования
Языки программирования помогают внедрять интерактивные функции на сайт. Они несут ответственность за возможность хранить, обновлять, манипулировать и получать доступ к данным из базы данных в пользовательский интерфейс. Для веб-разработки основными языками программирования, с которыми нужно ознакомиться, являются Java, Javascript, .NET, PHP, Perl, Python, C, C ++ и Ruby. Выбор языка программирования в основном зависит от программного стека и типа разрабатываемого проекта. Про выбор языка программирования можно прочитать в нашей статье.
6. СУБД
Веб-приложения должны хранить данные, с возможностью для доступа к ним, и когда это необходимо, что требует хорошего знания системы управления реляционными базами данных. Веб-разработчик должен хорошо понимать его синтаксис для создания, обновления, манипулирования и доступа к базе данных до ее оптимального уровня. Он должен понимать разницу между реляционной и нереляционной базой данных наряду со знанием XML/JSON. Понимание особенностей реляционной базы данных, веб-хранилища, знание NoSQL и связей с базами данных укрепляют карьеру веб-разработчика.
7. Программный стек
Это совокупность программных подсистем, которые вместе работают вместе, чтобы создать платформу для поддержки приложения без необходимости в дополнительном программном обеспечении. Говорят, что приложение «работает поверх» определенного программного стека. Независимо от программного стека, всегда существует сходство в архитектуре программного стека. Примеры программных стеков для веб-разработки:
LAMP [Linux | Apache | MySQL | PHP]
MERN [MongoDB | Express | React | Node.js]
MEAN [MongoDB | Express | Angular | Node.js]
Понимание стека программного обеспечения требуется при работе над проектом, поскольку оно дает лучшее техническое представление о разрабатываемом программном обеспечении. Вы можете оптимизировать производительность, предлагать изменения и устранять технические проблемы.
8. SEO
Поисковая оптимизация (Search Engine Optimization) не может считаться обязательным требованием для веб-разработчика. Но знания в этой области помогут вам с самого начала структурировать веб-сайт как оптимизированный для SEO. Это, в конечном счете, облегчит работу профессионалов SEO, но более того, веб-приложение имеет больше шансов на успех.
Итог
Наличие всех вышеперечисленных навыков дает вам возможность выбора из нескольких карьерных возможностей. На сегодняшнем рынке веб-разработчики должны иметь более одного определенного набора навыков.