По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4. Предыдущие статьи из цикла: Часть 1. Перераспределение маршрутов (Route redistribution) Часть 2. Фильтрация маршрутов с помощью карт маршрутов Часть 3. Перераспределение маршрутов между автономными системами (AS) Перераспределение подключенных сетей Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов. Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются. Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации. В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже. Перераспределение в OSPF В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода. Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях. Пример route redistribution IPv6 Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию: Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR. Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6. CENTR # conf term Enter configuration commands, one per line. End with CNTL/Z. CENTR (config)# ipv6 router eigrp 1 CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500? include-connected Include connected match Redistribution of OSPF routes route-map Route map reference cr CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected CENTR (config-rtr) #exit CENTR (config) # ipv6 router ospf 1 CENTR (config-rtr) #redistribute eigrp 1? include-connected Include connected metric Metric f or redistributed routes metric-type OSPF/IS-IS exterior metric type for redistributed routes nssa-only Limit redistributed routes to NSSA areas route-map Route map reference tag Set tag for routes redistributed into OSPF cr CENTR (config-rtr) #redistribute eigrp 1 include-connected CENTR (config-rtr) #end CENTR# Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF. Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии. Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.
img
Если вам нужно заставить curl игнорировать ошибки сертификата, убедитесь, что вы знаете о последствиях небезопасных соединений и передач SSL. Вам следует практиковаться в пропуске проверки сертификатов только в целях разработки. В этом руководстве вы узнаете, как заставить curl игнорировать ошибки сертификата. Заставить curl игнорировать ошибки SSL Основной синтаксис игнорирования ошибок сертификата с помощью команды curl: curl --insecure [URL] В качестве альтернативы вы можете использовать: curl -k [URL] Веб-сайт считается небезопасным, если у него истек срок действия, он неправильно настроен или не имеет сертификата SSL, обеспечивающего безопасное соединение. Когда вы пытаетесь использовать curl для подключения к такому веб-сайту, вывод выдает ошибку. Примечание. Параметры --insecure (-k) аналогичны команде wget --no-check-certificate, используемой для предотвращения проверки центрами сертификации сертификата сервера. Например, если вы запустите команду: curl myawesomewebsite.com Вывод должен отображать содержимое URL-адреса. Однако, поскольку этот веб-сайт имеет недействительный сертификат SSL, он показывает ошибку, как в примере ниже. curl: (60) SSL: no alternative certificate subject name matches target host name 'unixtutorial.test' Это означает, что «сертификат узла не может быть аутентифицирован с помощью известных сертификатов CA». Чтобы обойти это ограничение, вы можете использовать параметр --insecure (или -k), разрешающий небезопасные соединения с сервером при использовании SSL. Следовательно, вы должны запустить: curl -k myawesomewebsite.com Итоги Прочитав эту статью, вы должны знать, как заставить curl игнорировать ошибки сертификата. Хотя это делается просто путем добавления опции -k, не указывайте curl игнорировать ошибки SSL, если это не требуется для целей разработки.
img
Салют! В статье расскажем о модуле для работы с лог-файлами Asterisk, который позволяет настроить какие события должны попадать в лог и в каких файлах он должен храниться. Итак, речь пойдёт о модуле Asterisk Logfile Settings. Все лог-файлы нашей IP-АТС Asterisk, как известно, хранятся в папке /var/log/asterisk и мы можем просматривать их, не выходя из GUI FreePBX, благодаря модулю Asterisk Logfiles. Однако, по дефолту, вывод имеющихся лог файлов может не содержать много нужной и полезной информации, особенно это актуально в процессе траблшутинга. Итак, давайте рассмотрим возможности данного модуля. Для этого открываем Settings → Asterisk Logfile Settings. Перед нами должно открыться следующее окно: Как видно функционал данного модуля разбит по двум вкладкам: General Settings и Log Files General Settings На данной вкладке настраивается формат и представление лог-файлов: Date Format - Параметр отображения даты и временной метки в логе. Для того, чтобы ознакомиться с другими возможными спецификаторами, предлагается ознакомиться с мануалом Linux strftime(3). Можно также добавить десятые 1%, сотые 2% и т.д. Формат даты по умолчанию ISO 8601 yyyy-mm-dd HH:MM:SS (%F %T). Log Rotation - Здесь можно выбрать как будут храниться старые записи в логах, по умолчанию – они записываются в отдельный файл каждую ночь Sequential - Записи будут переименовываться с определённым порядковым номером, у самого нового лога будет самый высокий порядковый номер Rotate – Самый старый лог будет иметь самый высокий порядковый номер. Данная настройка стоит по умолчанию Timestamp – Использовать временную метку вместо порядкового номера лог-файла. Append Hostname - Определяет добавлять ли имя сервера к в записи лог-файла. Это полезно, если вы используете центральный сервер для хранения логов, куда поступает информация со всех остальных серверов. В этом случае, эта настройка может быть полезна чтобы идентифицировать источник информации. В противном случае, оставьте No Log Queues - Включает логгирование событий очередей, созданных с помощью модуля Queues. Создаёт для этого отдельный файл queue_log. Log Files В этой секции, собственно, и настраивается каким должен быть лог, какие события он должен логировать, насколько подробно и так далее. Здесь вы также можете создать свой собственный тип лог-файла и определить нужные вам параметры. Рассмотрим какие опции нам доступны: Debug - Очень подробный тип сообщений, который будет занесён в лог. Рекомендуется устанавливать данный параметр только если вы столкнулись с какой либо проблемой и для её отладки вам нужна более подробная информация DTFM - События, свидетельствующие о факте нажатия на кнопки телефона. Полезно при исследовании проблем с IVR и голосовой почтой Error - Критические ошибки и проблемы Fax - События передачи и приёма факсов Verbose - События, отображающие пошаговое установление соединения и дальнейшую информацию на протяжении звонка. Полезно при анализе неправильно отрабатывающих настроек call flow Warning - Возможные ошибки в синтаксисе дайлплана или call flow, не критично. Давайте сделаем отдельный файл, который будет логгировать только события нажатия клавиш на телефоне и назовём его dtfm Теперь позвоним на общий номер, на входящем маршруте которого стоит IVR. В данном IVR стоит правило – после нажатия на кнопку 5 соединить с неким внутренним номером. А теперь посмотрим новый лог в модуле Asterisk Log Files - dtfm:
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59