По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Наряду с Laravel, существует множество PHP-фреймворков с достаточно мощными техническими возможностями, такие как Symfony, CodeIgniter, Phalcon и другие.
Тем не менее, Laravel бесподобен.
Именно поэтому, наверное, этот фреймворк обрел широкую популярность за последние несколько лет. Он до сих пор входит в топ GitHub, с большим, чем 62k звездами.
В данной статье обсудим Laravel, почему он так распространен, а затем некоторые из лучших хостинг платформ где установлен Laravel.
Что такое Laravel?
Laravel - часто используемый PHP-фреймворк с открытым исходным кодом, созданный в 2011 году Тейлором Отвеллом. Он используется для разработки от простых веб-сайтов до сложных веб-приложений.
Он основан на архитектуре MVC (model, view, controller). Принцип этой архитектуры - разделение входных, выходных данных и основного функционала интерактивных приложений на отдельные составляющие, что позволяет писать хорошо отлаженный, гибкий и простой в обслуживании код.
Есть и другие причины, по которым Laravel знаменит:
Объектно-ориентированный подход с выразительным синтаксисом
Встроенная авторизация и аутентификация
Пакетная система для ускорения разработки приложений
Несколько файловых систем - локальное хранилище и облачное хранилище, например RackSpace и Amazon S3
Консоль Artisan для управления миграциями баз данных, публикации ресурсов пакетов и т.д.
Мощный ORM
Отличные показатели при тестировании
Трансляция и планирование задач
Учитывая популярность данного фреймворка, недостатка в хостинг-платформах для него нет, но не все они имеют нужный функционал и надежность. И если решили работать с Laravel и хотите выжать максимальную пользу из этой PHP-фреймфорка, важно использовать надежную платформу.
Технически приложение на Laravel можно разместить на хостинг-платформе с поддержкой PHP, но не все они будут оптимизированы под Laravel.
1. Forge
Первый кандидат - Forge. Он позволяет развертывать и предоставлять неограниченные приложения на Linode, DigitalOcean, AWS, Hetzner, Vultr и других.
На сегодня Forge управляет более чем 352 тысячами приложений и заслужил доверие тысячи компаний и разработчиков. Он позволяет размещать приложения на нескольких облачных среда на ваш выбор.
Всю заботу по установке PHP, Nginx, MySQL, Redis, Postgres и других важных программ Forge берет на себя. И не надо беспокоиться по поводу обновления всего арсенала вручную. Буквально простым нажатием можно развернуть коды из GitHub или Bitbucket.
Для эффективной совместной работы членам команды можно выдавать разные права на панель управления сервером. Forge предоставляет функцию изоляции пользователей, которая помогает разделять и защищать учетные записи пользователей. Аутентификация сервера выполняется по протоколу SSH, но необходимый брандмауэр не используется.
Управлять сервером можно с помощью удобной веб-панели или API. На Forge достаточно хорошо организована интеграция с LetsEncrypt, так что можно получить SSL сертификаты бесплатно.
Он предлагает доступные планы, которые начинаются с $12 в месяц за 1 сервер, неограниченное развертывание и сайты, а также функцию Push-to-Deploy.
2. A2 Hosting
Если нужно чтобы веб-сайт работал отлажено и показывал высокую производительность, а это нужно, то следует обратить внимание на уже известный читателям нашей базы знаний хостинг-провайдера A2.
A2 Hosting обеспечивает высокопроизводительный серверный хостинг для Laravel на платформе SwedingServer. Также можно выбрать опцию Turbo Servers, что даст в 20 раз большую производительность, чем стандартный план.
Их серверы оснащены твердотельными накопителями, а Turbo Server имеет AMD EPYC с драйверами NVMEe. В результате можно ожидать, что процессоры будут на 40% быстрее, скорость записи/чтения - в 3 раза, время до первого байта (TTFB) - в 2 раза, а трафик будет обрабатываться в 9 раз быстрее.
Установка Laravel буквально производится одним щелчком мыши. Их практика Perpetual Security помогает уменьшить количество интернет-угроз, постоянно скрывающихся в Интернете. Для всех планов бесплатно доступны защита HackScan, которая блокирует попытки взлома, обновления KernelCare, двусторонний брандмауэр, защита от подбора, DDoS и другие функции безопасности.
A2 Хостинг удобен для разработчиков и ориентирован на предоставление лучших версий программного обеспечения для разработки с момента его создания в 2003 году. Вы можете выбрать несколько версий PHP, MySQL, MariaDB, Python, PostgreSQL, Apache, SSH доступ и бесплатный SSL.
A2 Хостинг предлагает бесплатную миграцию учетных записей. Они также гарантируют 99,9% времени безотказной работы, так что на них можно положиться.
Цены начинаются всего с $2,99 за 1 сайт, 100GB SSD и другие функции. Он также включает 30-дневную гарантию возврата денег.
3. Cloudways
Cloudways, обеспечивает почти в 300 раз высокую скорость работы сервера и полностью оптимизированную для веб-приложений производительность. Он поставляется с функциями хостинга высшего класса, которые помогают легко управлять приложением.
Cloudways помогает повысить производительность приложения с помощью предварительно настроенных решений оптимизации, таких как PHP-FPM, Redis, Supervisord и других.
Вы получаете хостинг на базе твердотельных накопителей с выделенным IP-адресом, чтобы пользоваться полным контролем над вашим сервером. Для более быстрой доставки контента здесь используется продвинутый стек приложений, который включает в себя современные технологии кэширования, такие как Lacnish, Memcached и CloudingCDN.
Для обеспечения безопасности Cloudways регулярно обновляет брандмауэры и микропрограммы на уровне платформы. Для защиты от злоумышленников в дополнение к двухфакторной аутентификации можно использовать белый список IP-адресов.
Хостинг предлагает возможность автоматического резервного копирование каждый час или каждые 7 дней и функцию автоматического восстановления. Также можно выбрать частоту резервного копирования исходя из нужд проектов.
Cloudways использует таких поставщиков IaaS, как AWS, GCE, Linode, DigityOcean и Vultr, для размещения приложений в более чем 60 центрах обработки данных по всему миру. Это дает вам гибкость вертикального масштабирования, и нет сковывающего вас долгосрочного контракта.
Cloudways поддерживает интеграцию Git, клонирование серверов и приложений, а также области размещения, что способствует эффективной совместной работе путем добавления членов группы.
Цена зависит от выбранной платформы IaaS.
4. Servebolt
Servebolt предлагает удобную среду Laravel, предоставляя Git, Composer и другие инструменты командной строки. Его серверы способны адаптироваться к настройкам и пользовательским рабочим процессам.
Провайдер предлагает полное управление сервером с помощью SSH-доступа и быстрых баз данных для исключительной производительности. Servebolt предлагает устойчивую сеть, а также мониторинг серверов 24/7/365 для обеспечения высокой производительности и стабильности.
Они обеспечивают интеграцию Git на панели управления с webhooks, что удобно для автоматизированного развертывания.
Вы также можете интегрировать такие популярные инструменты, как Codeship, DeployHQ, Capistrano, StartCity, Jenkins и другими.
Servebolt предоставил вам бесплатную помощь миграции. Они также обеспечивают 99,90% гарантии безотказной работы, включая SLA.
5. fortrabbit
fortrabbit является одним из лучших провайдеров для хостинга Laravel и получил хорошие отзывы от своих пользователей. Он предлагает довольно простую установку Laravel и позволяет развертывать коды через Git push, поручая Composer обрабатывать остальное.
Он имеет отзывчивое сообщество и известен своим качеством поддержки клиентов. Функции, входящие в состав fortrabbit, представляют собой полностью управляемые серверы с твердотельным накопителем, что обеспечивает высокую скорость работы. Поскольку сервер поддерживает масштабирование, его можно увеличивать или уменьшать в зависимости от потребностей.
Кроме того, вы получаете поддержку SSH и SFTP, HTTPS, резервное копирование серверов и PHP 7. Они также предоставляют вам Memcache, чтобы в свою очередь обеспечивает высокую скорость и уменьшает нагрузку на базу данных.
6. ServerPilot
ServerPilot позволяет размещать приложения и сайты Laravel на таких популярных платформах, как DigityOcean, с его простым, но интуитивно понятным интерфейсом и автоматизированным управлением серверами. Достаточно установите Ubuntu и ServerPilot сам построит стек приложений, настроит брандмауэры и т. д., подключив облачный сервер.
На ServerPilot разработчики и агентства могут выбрать несколько версий Laravel. Гибкость и скорость поддерживаются за счет оптимизации Apache, Nginx, PHP-FPM. На одном сервере можно разместить несколько приложений Laravel.
ServerPilot обеспечивает автоматизированную защиту, созданную исследователями, и включает автоматические обновления серверов и SSL-сертификаты с поддержкой HTTP/2. В дополнение к просмотру журналов и управлению производительностью приложений, можно отслеживать состояние сервера и получать подробные статистические данные.
На данном хостинге также можно изолировать приложения, чтобы предотвратить случайное разрушительное влияние небезопасных плагинов, размещенные на том же сервере, на другие части сайта,.
Цена ServerPilot начинается с $5/сервер в месяц, включая $0,50/приложение.
7. FastComet
Облачный хостинг Laravel, предоставляемый SunComet, эффективен и экономичен. Они помогают развертывать и оптимизировать облачный сервер не за несколько часов, а за несколько минут. Даже можно бесплатно запросить перенос Laravel с помощью экспертов технической поддержки хостинг-провайдера.
FastComet предлагает cPanel, самую мощную и популярную панель управления хостингом, включая удобную управление учетными записями. С помощью твердотельных накопителей можно получите доступ к файлам на 300% быстрее. Вы можете управлять всем, как профессионал с доступом ROOT.
Еженедельное или ежедневное автоматизированное резервное копирование вместе со снимками данных по требованию. FastComet позволяет изменять размер сервера в любое время в зависимости от ваших потребностей. С помощью RocketBooster провайдер обеспечивает превосходную производительность и мониторинг серверов.
FastComet защищает ваши серверы от угроз в Интернете с помощью SunGuard и информирует сети о вредоносных атаках. Его набор средств защиты включает полную изоляцию учетных записей, защиту от грубого перебора, брандмауэр, предотвращение DDoS, обнаружение вредоносных программ и удаление, а также фильтр ботнетов.
SunComet имеет 9 глобальных центров обработки данных корпоративного уровня, а также 200 точек доступа Anycast Network для глобальной сети CDN.
8. Vapor
А для тех, кто предпочитает безсерверные решения, есть Laravel Vapar - платформа для безсерверного развертывания Laravel, которая работает на базе AWS. Его масштабируемость - это то, чем вы увлекаетесь при использовании его платформы без сервера. Он не требует обслуживания сервера, и его можно автоматически масштабировать по требованию в течение нескольких секунд.
Можно создавать, восстанавливать и управлять традиционными базами данных без сервера непосредственно с интуитивно понятной панели мониторинга Vapar.
Получите всю необходимую скорость для хостинга Laravel как Vapar предоставляет вам возможность создавать кластеры ElastiCache, Redis и легко управлять ими.
Наслаждайтесь мощью бессерверных вычислений, записывая и отправляя задания Laravel, и вы увидите, как сотни заданий выполняются одновременно без какой-либо конфигурации. Потоковый файл легко загружается в S3 с помощью встроенных утилит JavaScript.
Хостинг предлагает отслеживание метрики приложения о базах данных, приложениях и кэшах. Они также предупреждают вас в случае, если производительность не достигает нужной отметки. Для увеличения скорости загрузки сайта, Vapor автоматически загружает и сохраняет данные через CloudFront CDN или S3.
Есть возможность управления DNS-записями приложения из интерфейса командной строки или пользовательского интерфейса. В дополнение к этому вы получаете несколько сред для вашего приложения, быстрые откаты в случае ошибок и бесконечные развертывания.
Цена Laravel Vapor начинается от 39 долларов в месяц.
Заключение
Выбор в пользу того или иного из перечисленных выше хостингов для приложений Laravel не будет проигрышным выбором. Тем более, что большинство из них гарантируют возврат денег, так что можно попробовать и выбрать именно то, что лучше всего подходит для ваших нужд.
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
Иногда нам хочется, чтобы интерфейс роутера участвовал в процессе маршрутизации EIGRP, но без отправки Hello сообщений EIGRP с этого интерфейса. Именно об этом мы и поговорим в этой статье.
Ранее мы говорили о команде Network net-id wildcard-mask, вводимой в режиме конфигурации роутера EIGRP. Эта команда вызывает два основных действия:
Отправляет EIGRP Hello multicast сообщения с любого интерфейса, чей IP-адрес попадает в сетевое адресное пространство, указанное командой network.
Объявляет подсеть любого интерфейса, IP-адрес которого попадает в сетевое адресное пространство, заданное командой network.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Следующие статьи из цикла:
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Однако в некоторых случаях нам нет необходимости в том, чтобы команда network выполняла перовое действие, указанное выше. Например, если интерфейс подключается к хостам в локальной сети, а не к другим EIGRP-спикер роутерам. В этом случае нет необходимости отправлять Hello сообщения с этого интерфейса. К счастью, мы можем выборочно отключать отправку приветствий с интерфейса, все еще объявляя подсеть этого интерфейса нашим соседям EIGRP. Это стало возможным благодаря функции пассивного интерфейса.
Рассмотрим топологию ниже:
Обратите внимание, что каждый роутер имеет интерфейс, указывающий на сегмент локальной сети (то есть интерфейс, подключенный к коммутатору). Мы действительно хотим, чтобы подсети этих интерфейсов объявлялись через EIGRP, но нам не надо отправлять Hello сообщения c этого интерфейса (поскольку они не подключаются ни к каким другим EIGRP - спикер роутерам). Это делает эти интерфейсы (то есть интерфейс Gig0/3 на роутерах OFF1, OFF2 и OFF3) отличными кандидатами на роль пассивных интерфейсов. В следующем примере показано, как использовать команду passive-interface interface_id.
OFF1# configurationterminal
Enter configuration commands, one per line. End with CNTL/Z.
OFF1(config)#router eigrp 1
OFF1(config-router)#passive-interface gig0/3
OFF1(config-router)#end
OFF1#
OFF2# configurationterminal
Enter configuration commands, one per line. End with CNTL/Z.
OFF2 (config)#router eigrp 1
OFF2 (config-router)#passive-interface gig0/3
OFF2 (config-router)#end
OFF2#
OFF3# configurationterminal
Enter configuration commands, one per line. End with CNTL/Z.
OFF3 (config)#router eigrp 1
OFF3 (config-router)#passive-interface default
OFF3 (config-router)#no passive-interface gig0/1
OFF3 (config-router)#no passive-interface gig0/2
OFF3 (config-router)#end
OFF3#
В приведенном примере команда passive-interface gig0/3 была введена на роутерах OFF1 и OFF2, чтобы сообщить, что эти роутеры должны блокировать отправку Hello сообщений со своих интерфейсов Gig0/3 (то есть интерфейсов, соединяющихся с сегментами локальной сети). Однако конфигурация на роутере OFF3 использует несколько иной подход. Вместо указания интерфейсов, которые должны быть пассивными, дается команда passive-interface default, которая делает все интерфейсы пассивными. Затем были даны команды no passive-interface gig 0/1 и no passive-interface gig 0/2, чтобы выборочно сообщить, что эти интерфейсы не должны быть пассивными (так как эти интерфейсы используются для подключения к соседям EIGRP). Этот подход может быть полезен на роутерах с несколькими интерфейсами LAN и только несколькими интерфейсами, соединяющимися с соседями EIGRP.
Как только мы выполняем команду passive-interface interface_id для определенного интерфейса, этот интерфейс больше не появляется в выходных данных команды show ip eigrp interfaces, как показано в примере ниже. Обратите внимание, что интерфейс Gig0/3, который был настроен как пассивный интерфейс, не отображается в списке. Однако EIGRP все еще объявляет подсеть, к которой принадлежит интерфейс Gig0/3.
Мы можем определить, какие интерфейсы на роутере действуют в качестве пассивных интерфейсов, выполнив команду show ip protocols. В отображаемых данных этой команды, как видно в примере ниже, обратите внимание, что интерфейс Gig0/3 на роутере OFF2 является пассивным интерфейсом, в то время как его подсеть (198.51.100.0/24) объявляется EIGRP.
Следом вас ждет статья про настройку статического соседства в EIGRP