По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы рассмотрим протокол маршрутизации Cisco EIGRP. EIGRP (Enhanced Interior Gateway Routing Protocol) - это протокол расширенной векторной маршрутизации, который должен устанавливать отношения соседства перед отправкой обновлений. Из-за этого первое, что нам нужно сделать, это проверить, правильно ли работает соседство. Если это так, мы можем продолжить, проверив, объявляются сети или нет. В этой статье рассмотрим все, что может пойти не так с EIGRP, как это исправить и в каком порядке. Давайте начнем с проверки соседства!
Существует ряд элементов, которые вызывают проблемы соседства EIGRP:
Неизвестная подсеть: соседи EIGRP с IP-адресами, которые не находятся в одной подсети.
Несоответствие значений K: по умолчанию пропускная способность и задержка включены для расчета метрики. Мы можем включить нагрузку и надежность, но мы должны сделать это на всех маршрутизаторах EIGRP.
Несоответствие AS: номер автономной системы должен совпадать на обоих маршрутизаторах EIGRP, чтобы сформировать соседство.
Проблемы уровня 2: EIGRP работает на уровне 3 модели OSI. Если уровни 1 и 2 не работают должным образом, у нас будут проблемы с формированием соседства.
Проблемы со списком доступа: возможно, кто-то создал список доступа, который отфильтровывает многоадресный трафик. EIGRP по умолчанию использует 224.0.0.10 для связи с другими соседями EIGRP.
NBMA: по умолчанию Non Broadcast Multi Access сети, такие как Frame Relay, не разрешают широковещательный или многоадресный трафик. Это может препятствовать тому, чтобы EIGRP формировал соседние отношения EIGRP.
OFF1(config)#int f0/0
OFF1(config-if)#ip address 192.168.12.1 255.255.255.0
OFF1(config-if)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF2(config)#int f0/0
OFF2(config-if)#ip address 192.168.21.2 255.255.255.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.21.0
Ошибку неверной подсети легко обнаружить. В приведенном выше примере у нас есть 2 маршрутизатора, и вы можете видеть, что были настроены разные подсети на каждом интерфейсе.
После включения EIGRP всплывают следующие ошибки:
Оба маршрутизатора жалуются, что находятся не в одной подсети.
OFF2(config-router)#int f0/0
OFF2(config-if)#ip address 192.168.12.2 255.25
OFF2(config)#router eigrp 12
OFF2(config-router)#no network 192.168.21.0
OFF2(config-router)#network 192.168.12.0
Мы изменили IP-адрес на OFF2 и убедились, что для EIGRP правильно настроена команда network.
Вуаля! Теперь у нас есть соседство EIGRP.
Проверим это с помощью команды show ip eigrp neighbors.
Извлеченный урок: убедитесь, что оба маршрутизатора находятся в одной подсети.
Case #2
На этот раз IP-адреса верны, но мы используем разные значения K с обеих сторон. OFF1 включил пропускную способность, задержку, нагрузку и надежность. OFF2 использует только пропускную способность и задержку.
Эту ошибку легко обнаружить, поскольку сообщение в консоли гласит "Несоответствие K-значений" на обоих маршрутизаторах.
Мы можем проверить нашу конфигурацию, посмотрев ее на обоих маршрутизаторах. Как вы видите, что значения K были изменены на OFF1.
OFF2(config)#router eigrp 12
OFF2(config-router)#metric weights 0 1 1 1 1 0
Давайте убедимся, что значения K одинаковы на обоих маршрутизаторах, так как мы изменили их на OFF2.
После изменения значений K у нас появилось соседство EIGRP-соседей.
Еще одна проблема решена!
Извлеченный урок: убедитесь, что значения K одинаковы на всех маршрутизаторах EIGRP в одной и той же автономной системе.
Case #3
Давайте продолжим со следующей ошибкой ...
Вот еще один пример типичной проблемы. Несоответствие номера AS. Когда мы настраиваем EIGRP, мы должны ввести номер AS. В отличие от OSPF (который использует ID процесса) этот номер должен быть одинаковым на обоих маршрутизаторах.
В отличие от других неверных настроек конфигурации EIGRP, эта проблема не выдает сообщение об ошибке. Используем команду show ip eigrp neighbors и видим, что соседей нет. Внимательно изучите выходные данные, чтобы обнаружить различия, и вы увидите, что маршрутизаторы используют разные номера AS.
Если посмотреть на работающую конфигурацию, и мы увидим то же самое.
Давайте изменим номер AS на OFF2.
После смены номера AS все заработало как положено.
Извлеченный урок: убедитесь, что номера AS одинаковые, если вы хотите соседства EIGRP.
Case #4
И последнее, но не менее важное: если вы проверили номер AS, значения K, IP-адреса и у вас все еще нет работающего соседства EIGRP, вам следует подумать о безопасности. Возможно, access-list блокирует EIGRP и/или многоадресный трафик.
Следующая ситуация: опять два маршрутизатора EIGRP и отсутствие соседства. Что здесь происходит?
Мы видим, что нет соседей ...
Если вы посмотрите на вывод команды show ip protocols, то увидите, что сеть была объявлена правильно. Если вы посмотрите внимательно на OFF2, вы увидите, что у нас есть пассивный интерфейс.
Удалим настройки пассивного интерфейса!
OFF2(config)#router eigrp 12
OFF2(config-router)#no passive-interface fastEthernet 0/0
Еще одна неправильная настройка создала нам проблемы, но мы ее решили.
Задача решена!
Извлеченный урок: не включайте пассивный интерфейс, если вы хотите установить соседство EIGRP.
Case #5
В приведенном выше примере у нас есть те же 2 маршрутизатора, но на этот раз кто-то решил, что было бы неплохо настроить список доступа на OFF2, который блокирует весь входящий многоадресный трафик.
Здесь можно запутаться. На OFF1 мы видим, что он считает, что установил соседство EIGRP с OFF2. Это происходит потому, что мы все еще получаем пакеты EIGRP от OFF2.
Используем команду debug eigrp neighbors, чтобы посмотреть, что происходит. Очевидно, что OFF1 не получает ответ от своих hello messages, holdtime истекает, и это отбрасывает установление соседства EIGRP.
Быстрый способ проверить подключение - отправить эхо-запрос по адресу многоадресной рассылки 224.0.0.10, который использует EIGRP. МЫ видим, что мы ответа нет от этого запроса. Рекомендуется проверить, есть ли в сети списки доступа.
Так, так! Мы нашли что-то ...
Этот список доступа блокирует весь многоадресный трафик. Давайте сделаем настройку, которая разрешит EIGRP.
OFF2(config)#ip access-list extended BLOCKMULTICAST
OFF2(config-ext-nacl)#5 permit ip any host 224.0.0.10
Мы создаем специальное правило, которое будет разрешать трафик EIGRP.
Как мы видим, что трафик EIGRP разрешен - это соответствует правилу, которое мы выше создали.
Оба маршрутизатора теперь показывают рабочее соседство EIGRP.
Эхо-запрос, который мы только что отправили, теперь работает.
Извлеченный урок: не блокируйте пакеты EIGRP!
Case #6
Рассмотрим очередную ситуацию, в которой нет соседства EIGRP. На картинке выше мы имеем сеть Frame Relay и один канал PVC между OFF1 и OFF2. Вот соответствующая конфигурация:
Оба маршрутизатора настроены для Frame Relay, а EIGRP настроен.
Видно, что нет соседей ... это не хорошо! Можем ли мы пропинговать другую сторону?
Пинг проходит, поэтому мы можем предположить, что PVC Frame Relay работает. EIGRP, однако, использует многоадресную передачу, а Frame Relay по умолчанию - NBMA. Можем ли мы пропинговать адрес многоадресной рассылки EIGRP 224.0.0.10?
Здесь нет ответа на наш вопрос, по крайней мере, теперь мы знаем, что unicast трафик работает, а multicast не работает. Frame Relay может быть настроен для point-to-point или point-to-multipoint соединения. Физический интерфейс всегда является интерфейсом frame-relay point-tomultipoint, и для него требуются frame-relay maps, давайте проверим это:
Мы видим, что оба маршрутизатора имеют DLCI-to-IP карты, поэтому они знают, как связаться друг с другом. Видим, что они используют ключевое слово "статический", а это говорит о том, что это сопоставление было кем-то настроено и не изучено с помощью Inverse ARP (в противном случае вы увидите "динамический"). Мы не видим ключевое слово "broadcast", которое требуется для пересылки широковещательного или многоадресного трафика. На данный момент у нас есть 2 варианта решения этой проблемы:
Настроить EIGRP для использования одноадресного трафика вместо многоадресного.
Проверить конфигурацию Frame Relay и убедится, что многоадресный трафик не перенаправляется.
Давайте сначала сделаем unicast настройку EIGRP:
OFF1(config)#router eigrp 12
OFF1(config-router)#neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#neighbor 192.168.12.1 serial 0/0
Нам нужна команда neighbor для конфигурации EIGRP. Как только вы введете эту команду и нажмете enter, вы увидите это:
Задача решена! Теперь давайте попробуем другое решение, где мы отправляем multicast трафик по PVC Frame Relay:
OFF1(config)#router eigrp 12
OFF1(config-router)#no neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#no neighbor 192.168.12.1 serial 0/0
Если это не работает ... не исправляйте это... , но не в этот раз! Пришло время сбросить соседство EIGRP.
OFF1(config)#interface serial 0/0
OFF1(config-if)#frame-relay map ip 192.168.12.2 102 broadcast
OFF2(config)#interface serial 0/0
OFF2(config-if)#frame-relay map ip 192.168.12.1 201 broadcast
Broadcast - это ключевое волшебное слово здесь. Это разрешит широковещательный и многоадресный трафик.
После изменения конфигурации frame-relay map появляется соседство EIGRP! Это все, что нужно сделать.
Извлеченный урок: проверьте, поддерживает ли ваша сеть Frame Relay broadcast или нет. Настройте EIGRP для использования unicast передачи или измените конфигурацию Frame Relay для поддержки широковещательного трафика.
Продолжение цикла про поиск и устранение неисправностей протокола EIGRP можно почитать тут.
Вторая часть тут
Пересечение многочисленных дискуссий в мире сетевого инжиниринга, было одной из проблем, которая затрудняла принятие решения о том, является ли коммутация пакетов или каналов лучшим решением. Как следует вычислять loop-free пути в сети с коммутацией пакетов?
Поскольку сети с коммутацией пакетов на протяжении всей истории сетевой инженерии ассоциировались с распределенными плоскостями управления (control plane), а сети с коммутацией каналов -с централизованными плоскостями управления (control plane), проблема эффективного вычисления безцикловых (loop-free) путей оказала значительное влияние на принятие решения о том, являются ли сети с коммутацией пакетов жизнеспособными или нет.
На заре сетевой инженерии доступная вычислительная мощность, память и пропускная способность часто были в дефиците.
В 1984 году, когда происходили в основном своем эти дискуссии, любая разница в объеме процессора и памяти между двумя способами расчета безцикловых путей через сеть оказала бы существенное влияние на стоимость построения сети. Когда пропускная способность имеет первостепенное значение, уменьшение количества битов, требуемых плоскостью управления (control plane) для передачи информации, необходимой для вычисления набора loop-free путей через сеть, создает реальную разницу в объеме пользовательского трафика, который может обрабатывать сеть. Уменьшение количества битов, необходимых для работы элемента управления, также вносит большую разницу в стабильность сети при более низких полосах пропускания.
Например, использование формата Type Length Vector (TLV) для описания информации о плоскости управления (control plane), передаваемой по сети, добавляет несколько октетов информации к общей длине пакета-но в контексте канала 2 Мбит / с, усугубленного chatty control plane, затраты могут значительно перевесить долгосрочное преимущество расширяемости протокола.
Протокольные войны в некоторых моментах были довольно жаркими. Были организованы целые исследовательские проекты и написаны статьи о том, почему и как один протокол лучше другого.
Было предложено большое разнообразие механизмов для решения задач вычисления loop-free путей через сеть. В конечном счете были широко развернуты и использованы три общих класса решений:
Distance Vector protocols (протоколы вектора расстояния), которые вычисляют свободные от петель пути hop by hop на основе стоимости пути.
Link State protocols (протоколы состояния связи), которые вычисляют свободные от петель пути через базу данных, синхронизированную между сетевыми устройствами.
Path Vector protocols (протоколы вектора пути), которые вычисляют свободные от петель пути hop by hop на основе записи предыдущих прыжков.
Дискуссия о том, какой протокол лучше всего подходит для каждой конкретной сети и по каким конкретным причинам, все еще продолжается. И это, возможно, бесконечный спор, поскольку нет окончательного ответа на этот вопрос. Возможно, как и при подгонке сети под бизнес, всегда будет какая-то степень искусства, связанная с тем, чтобы заставить конкретную плоскость управления (control plane) работать в конкретной сети. Однако большая часть актуальности этого вопроса была вызвана ростом скорости сетей-вычислительной мощности, памяти и пропускной способности.
Четвертую часть цикла статей про QoS можно почитать по ссылке.
Итак, вы полностью укомплектовали и настроили ваш умный дом. И конечно, вам нравится периодически показывать выпендриваться перед друзьям, как круто включать лампы, проигрывать видео и фильмы подсказкой голосовому помощнику, приготовить кофе или регулировать термостат коснувшись приложения на экране смартфона. Поздравляем!
Но если вы любитель автоматизации (как и мы), который редко останавливается на достигнутом, то возможно будете разочарованы количеством необходимых программ, которые нужно загрузить, интерфейсов, которые вам придётся усваивать, чтобы управлять гаджетами. Скорее всего, будут отдельные приложения для управления освещением, медиацентром, термостатом и приложение Google Home, который изо всех сил (но безнадежно) старается собрать всё это воедино.
Большая вероятность того, что некоторые приложения будут несовместимы с другими и, вероятно, многие из них не будут работать, если они не в одной сети с гаджетом. Представьте если бы мы смогли управлять всем этим из одного интерфейса, на засоряя телефон или компьютер сотнями приложений, через интерфейс, который доступен как на смартфонах, так и на компьютерах, а также с помощью сторонних сценариев вне зависимости от того, находимся ли мы в одной сети с умным домом или нет. Интерфейс, который был бы легким и простым в использовании?
А что если мы будем делать это через мессенджер или чат? В конце концов, разве не легче было бы контролировать наш дом, гаджеты и облачные сервисы через тот же интерфейс, который мы используем для отправки фотографий котиков нашим друзьям, и через бот, полностью адаптированный к нашим потребностям?
В этой статье я покажу вам, как настроить команды и процедуры в дополнение к существующим сетапам умного дома. В данном руководстве мы используем два основных инструмента:
Telegram: существует много мессенджеров и платформ, но до сих пор попытки многих из них (Facebook Messenger, Whatsapp, Hangouts и т.д.) в предоставлении пригодного для разработчиков API, мягко говоря, были тщетны. Ушли те дни, когда все использовали XMPP или IRC в качестве своего мессенджер. Сегодняшний мир мессенджеров очень разнообразен.
Кроме того, поскольку в интересах многих крупных игроков создавать изолированные ИТ экосистемы, наиболее часто используемые решения не поставляются с официально поддерживаемыми API/интерфейсами разработчиков. Мало того: некоторые из них активно отговаривает пользователей от использования чего-либо, кроме официального приложения, для взаимодействия с платформой (почитайте, как Whatsapp может забанить вас).
В этом чрезвычайно разнообразном мире, состоящем из нескольких несвязанных островов, Telegram представляет собой радостное исключение: их официальный bot API хорошо задокументирован и поддерживается, и для тех, кто знает немного программирования, очень легок в интеграции.
Platypush: Platypush поставляется с плагином для Telegram и бэкэндом. Так что давайте начнем и создадим первый бот для автоматизации управления домом!
Создание Telegram-бота
Начните беседу с Botfather.
Наберите /start, а затем /newbot для создания нового бота. Задайте боту ник и имя.
Вы получите ссылку, чтобы начать беседу с вашим ботом и уникальный API-ключ. Сохраните его где-нибудь, так как он нам понадобится для конфигурации плагина platypush.
Конфигурация бота в platypush
1. Установите platypush с основными расширения и интеграцией с Telegram:
pip install 'platypush[http,db,telegram]'
apt-get install redis-server
[sudo] systemctl start redis
[sudo] systemctl enable redis
2. Изучите platypush хотя бы немного, если еще не сделали этого. Определите несколько вещей, которыми вы хотите управлять/автоматизировать - источники света, музыку, датчики, базу данных, роботы - и установите/настройте соответствующие расширения.
В этой статье мы рассмотрим, как настроить наш новый бот для управления освещением Philips Hue, воспроизведением музыки и потоковой передачей PiCamera.
3. Добавьте настройки Telegram в файл ~/.config/platypush/config.yaml:
chat.telegram:
api_token: <your bot token>
backend.chat.telegram:
enabled: true
Бэкэнд-система позволяет получать события (например, новые сообщения, вложения, запросы и т.д.) и создавать на них пользовательские "хуки". Плагин позволяет писать вам чаты, программно отправлять сообщения и вложения, администрировать каналы и т.д.
Допустим, мы хотим, чтобы бот реализовал следующие команды:
/start
Приветствие пользователя
/help
Показать доступные команды
/lights_on
Включить свет
/lights_off
Выключить свет
/music_play
Включить музыку
/music_pause
Приостановить музыку
/music_next
Перейти на следующую песню
/music_prev
Перейти на предыдущую песню
/start_streaming
Начать удаленное вещание PiCamera
/stop_streaming
Остановить удалённое вещание PiCamera
Всё что мы должны сделать это создать действие в конфигурационном файле platypush config.yaml. В этом контексте вы должны:
Установить и настроить плагины Philips Hue, mopidy и PiCamera:
pip install 'platypush[hue,mpd,picamera]'
# Hue lights configuration
light.hue:
# Hue bridge IP address
bridge: 192.168.1.10
# Default groups to control
groups:
- Living Room
# MPD/Mopidy configuration
music.mpd:
host: localhost
port: 6600
# PiCamera configuration
camera.pi:
vflip: False
hflip: False
Чтобы не засорять файл config.yaml, создайте новый файл с названием ~/.config/platypush/include/bot.yaml:
# /start command handler
event.hook.OnTelegramStartCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: start
then:
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Welcome! Type /help to see the available commands"
# /help command handler
event.hook.OnTelegramHelpCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: help
then:
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Available commands:
- /lights_on
- /lights_off
- /music_play [resource]
- /music_pause
- /music_prev
- /music_next
- /start_streaming
- /stop_streaming
"
# /lights_on command handler
event.hook.OnTelegramLightsOnCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: lights_on
then:
- action: light.hue.on
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Lights turned on"
# /lights_off command handler
event.hook.OnTelegramLightsOffCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: lights_off
then:
- action: light.hue.off
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Lights turned off"
# /music_play command handler
event.hook.OnTelegramMusicPlayCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_play
then:
- if ${cmdargs}:
- action: music.mpd.play
args:
resource: cmdargs[0]
- else:
- action: music.mpd.play
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Music playing"
# /music_pause command handler
event.hook.OnTelegramMusicPauseCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_pause
then:
- action: music.mpd.pause
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Music paused"
# /music_prev command handler
event.hook.OnTelegramMusicPrevCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_prev
then:
- action: music.mpd.previous
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Playing previous track"
# /music_next command handler
event.hook.OnTelegramMusicNextCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_next
then:
- action: music.mpd.next
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Playing next track"
# /start_streaming command handler
event.hook.OnTelegramCameraStartStreamingCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: start_streaming
then:
- action: camera.pi.start_streaming
args:
listen_port: 2222
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "PiCamera streaming started. Check it out with vlc tcp/h264://hostname:2222"
# /stop_streaming command handler
event.hook.OnTelegramCameraStopStreamingCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: stop_streaming
then:
- action: camera.pi.stop_streaming
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "PiCamera streaming stopped"
Подключите файл конфигурации бота в config.yaml:
include:
-include/bot.yaml
Запустите platypush:
# Manual start
platypush
# Service start
systemctl start platypush.service
Создайте беседу в вашим ботом перейдя по ссылке, выданной BotFather и начните говорить ему, что делать:
Сейчас бот доступен любому мы этого явно не хотим. Представьте, что кто-то включит на полную громкость System Of A Down- Jet Pilot вам ночью. Так себе пробуждение. Можно настроить бэкэнд Telegram так, чтобы он принимал сообщения только из определенного списка идентификаторов чатов (в Telegram chat_id используется как для частных пользователей, так и для групп).
Отправьте сообщение боту и откройте журналы platypush или проверьте его стандартные выходные данные. На экране появятся следующие сообщения:
2020-01-03 19:09:32,701| INFO|platypush|Received event: {"type": "event", "target": "turing", "origin": "turing", "id": "***", "args": {"type": "platypush.message.event.chat.telegram.CommandMessageEvent", "chat_id": your_chat_id, "message": {"text": "/help", ...}, "user": {"user_id": your_user_id, "username": "****", "is_bot": false, "link": "https://t.me/you", "language_code": "en", "first_name": "***", "last_name": "***"}, "command": "help", "cmdargs": []}}
Скопируйте chat_id своего пользователя и вставьте в бак-энд файл:
backend.chat.telegram:
authorized_chat_ids:
- your_user_id
Теперь бот ответит ошибкой, если вы попытаетесь отправить сообщение от неавторизованного пользователя.
Вы также можете пригласить своего бота в групповой чат и позволить вашим друзьям или членам семьи регулировать свет в вашем доме, если вы захотите!
Что дальше?
В этой статье мы изучили только одну специфическую особенность интеграции Telegram - способность бота реагировать на события в команде, запускать действия и отвечать текстовыми сообщениями.
Как видно из списка поддерживаемых событий Telegram, можно сделать больше, например:
Создавать обработчики, когда кто-то делится контактной информацией - когда-нибудь думали разрешить боту автоматически хранить новые контакты, отправленные вам вашими друзьями в чате?
Создавайте обработчики при совместном использовании документов, видео или изображения - например, автоматически загружайте все файлы мультимедиа, отправленные в чат, на жесткий диск или удаленную папку Dropbox.
Выполнять действия с текстовыми сообщениями вместо команд - можно использовать TextNewsEvent, например, если вы предпочитаете вводить "включить свет" вместо "/lights_on."
Сделайте снимок на камеру наблюдения и отправьте ее себе командой send_photo. Можно также развернуть несколько ботов, например, для каждого устройства, чтобы можно было запускать действия на конкретном устройстве из связанного чата или вместо этого использовать один бот в качестве точки входа и доставлять сообщения другим устройствам через MQTT, Kafka или HTTP API.