По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Хочу рассказать, как с минимальным даунтаймом на продакшн оборудовании настроить EtherChannel. Для начала нужно подключить оборудование, и оно начнет работать в режиме STP. На коммутаторе уровня агрегации (ядра) в зависимости от топологии нужно узнать порты к которому подключено оборудование. Для этого есть команда show cdp neighbors, которую нужно запустить на коммутаторе уровня доступа. Так удобней будет. Для мониторинга запускаем PING на IP коммутатора.
После этого выключаем порт, который заблокирован по протоколу STP. Советую сделать это на коммутаторе агрегации (ядра). Далее по очереди настраиваем логический порт на обоих коммутаторах.
AccSwitch-2#conf t
AccSwitch-2(config)#int port-channel 1
AccSwitch-2(config-if)#switchport mode trunk
CoreSW#conf t
CoreSW(config)#int port-channel 10
CoreSW(config)#switchport mode trunk
После этого уже настраиваем отключенный физический порт:
AccSwitch-2(config-if)#int gi1/0/47
AccSwitch-2(config-if)#switchport mode trunk
AccSwitch-2(config-if)#channel-group 1 mode on
CoreSW (config-if)#int gi2/0/38
CoreSW (config-if)#switchport mode trunk
CoreSW (config-if)#channel-group 10 mode on
Для начала ставим минимальную настройку. Но если на свитчах настроен DHCP Snooping или Dynamic Arp Inspection, то под логическим и физическим транк портом нужно прописать ip dhcp snooping trust и ip arp inspection trust.
После того как все настройки сделаны и проверены можно включить настроенный порт не отключая работающий. В этом случае должен потеряться максимум один PING, что совсем не критично так, как TCP сессия не обрывается. Далее выключаем уже другой порт, настраиваем аналогично и включаем.
Внимание, после этого все настройки на UpLink портах нужно производить на логическом интерфейсе. Все изменения автоматически применяются на порты, которые входят в port-channel. Надеюсь статья окажется полезной!
В статье поговорим о борьбе со спамом в мире телефонии. Существует множество различных программ для блокировки спама на мобильных телефонах, а вот найти что-то подобное для IP-АТС и IP-телефонов – уже сложнее.
В Telegram есть специальный бот для определения спам-звонков. Бот определяет спамеров, местоположение и оператора связи. Предназначен для IP-АТС (Asterisk, FreePBX, FreeSWITCH), IP-телефонов и CRM. Если фиксируется спам-звонок, то сервис присылает уведомление в Telegram с соответствующей пометкой и названием оператора связи. API ссылка так же возвращает текст с названием оператора.
Таким образом если указать эту ссылку в Asterisk, то сообщение с пометкой спам и оператором связи отобразится в Telegram и на экране IP-телефона, а в статистике CDR всегда можно будет фильтровать выдачу по операторам связи.
Помечая звонок как “спам”, все пользователи вносят свой вклад в расширение спам-базы. Возможности сервиса:
Определение номеров по спам-базам;
Персональный спам список;
Определение страны/города;
Определение оператора связи;
Добавление комментариев к звонку.
Подключение API
Телеграм бот:
telegram.org/phone_info_bot
t.me/phone_info_bot
Альтернативная ссылка:
tele.gg/phone_info_bot
Ссылка:
http://rustyle.tmweb.ru/bots/tgbots/phone_info_bot/callerid_lookup_src/callerid_lookup.php?in_num=ВХОДЯЩИЙ_НОМЕР&dst_num=НОМЕР_НАЗНАЧЕНИЯ&user_id=ВАШ_USER_ID
Получить user ID можно обратившись к боту по одной из ссылок выше.
Подключение FreePBX
Перейдите в Web-интерфейс, в меню Admin → CallerID Lookup Sources → Add CID Lookup Source и заполните следующие поля:
В поле Source type выберите HTTP;
В поле Host укажите rustyle.tmweb.ru;
В поле Path введите bots/tgbots/phone_info_bot/callerid_lookup_src/callerid_lookup.php;
И наконец – в поле Query введите следующее: in_num=[NUMBER]&dst_num=${FROM_DID}&user_id=ВАШ_USER_ID;
В поле Query не забудьте заменить ВАШ_USER_ID. Параметры [NUMBER] и ${FROM_DID} менять не нужно - оставьте без изменений.
Далее переходим в меню Connectivity → Inbound Routes, выбираем или создаем маршрут, переходим на вкладку Other → CID Lookup Source и выбираем источник из предыдущего шага.
ВХОДЯЩИЙ_НОМЕР - Код страны и телефон. Пример: 74991234567;
НОМЕР_НАЗНАЧЕНИЯ - Код страны и телефон. Пример: 74991234567;
ВАШ_USER_ID = Выдается при запуске бота;
Готово. Есть вопрос – пиши в комментариях :)
Предыдущая статья из цикла про популярные приложения TCP/IP тут.
Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.
Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.
TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP.
На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.
TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:
Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками.
Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками.
Восстановление после ошибок и надежность
TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.
На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)
Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)
Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.
Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.
Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.
Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.
Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.
Управление потоком с использованием окон
TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель.
Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках.
Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.
Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).
Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.
Закрепим самое важное про TCP и UDP в следующей статье.