По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Наряду с 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 не будет проигрышным выбором. Тем более, что большинство из них гарантируют возврат денег, так что можно попробовать и выбрать именно то, что лучше всего подходит для ваших нужд.
Если вы работаете в IT, то наверняка тысячу раз сталкивались с необходимостью зайти на какое-то устройство или сервер удалённо – такая задача может быть выполнена несколькими путями, основные два для управления устройством через командную строку – Telnet и Secure Shell (SSH) .
Между ними есть одно основное различие – в протоколе Telnet все данные передаются по сети в незашифрованном виде, а в случае SSH все команды шифруются специальным ключом. SSH был разработан как замена Telnet, для безопасного управления сетевыми устройствами через небезопасную сеть, такую как Интернет. На всякий случай запомните, что Telnet использует порт 22, а SSH – 23.
Поэтому наша рекомендация – используйте SSH всегда, когда возможно.
Настройка
Для начала, вам понадобится Packet Tracer – программа для эмуляции сетей от компании Cisco. Он полностью бесплатен и его можно скачать с сайта netacad.com после регистрации. Запустите Packet Tracer и приступим к настройке.
Постройте топологию как на скриншоте ниже – один компьютер и один коммутатор третьего уровня. Нужно будет подключить их между собой и приступить к настройке.
Готово? Теперь обеспечим сетевую связность и настроим интерфейс vlan 1 на коммутаторе, для этого введите следующие команды:
Если сразу после создания в консоли коммутатора будет вопрос начать ли диалог изначальной настройки – ответьте «No».
en
conf t
interface vlan 1
ip address 192.168.1.1 255.255.255.0
no shutdown
Далее, настроим сетевую карту компьютера – укажем сетевой адрес в настройках FastEthernet0: 192.168.1.2. По умолчанию все новые компьютеры будут находиться в vlan 1.
Теперь давайте попробуем пингануть коммутатор и зайти на него по протоколу telnet с нашего ПК на коммутатор – и вы увидите, что соединение будет отклонено по причине того, что мы еще не настроили аутентификацию на коммутаторе.
Перейдем к настройке аутентификации. Система поддерживает 20 виртуальных tty/vty линий для Telnet, SSH и FTP сервисов. Каждая сессия, использующая вышеупомянутый протокол занимает одну линию. Также можно усилить общую безопасность с помощью валидации запросов на авторизацию на устройстве. Перейдите обратно в режим общей конфигурации (conf t) на коммутаторе с помощью команды exit и введите следующие команды:
line vty 0 15
password cisco
login
end
Пароль cisco, используемый в статье, является крайне небезопасным и служит исключительно для демонстрационных целей. Если вы оставите такой пароль на настоящем оборудовании, шансы, что вас взломают будут стремиться к бесконечности. Лучше используйте наш генератор устойчивых ко взлому паролей :)
Теперь снова попробуйте зайти по Telnet на свитч – все должно получиться!
Однако, при попытке перейти к настройке и выполнении команды enable вы увидите, что это невозможно, по причине того, что не установлен пароль на глобальный режи enable.
Чтобы исправить это, введите следующие команды:
conf t
enable password cisco
Попробуйте еще раз – теперь все должно получиться!
Теперь настроим SSH на коммутаторе – для этого обязательно нужно указать хостнейм, доменное имя и сгенерировать ключ шифрования.
Вводим следующие команды (из основного конфигурационного режима):
hostname merionet_sw1
ip domain name merionet
crypto key generate rsa
Выбираем длину ключа – по умолчанию значение стоит равным 512 битам, для SSH версии 2 минимальная длина составляет 768 бит. Генерация ключа займет некоторое время.
После генерации ключа продолжим настройку коммутатора:
ip ssh version 2
line vty 0 15
transport input ssh
Теперь зайти по протоколу Telnet уже не выйдет, так как мы заменили его на SSH. Попробуйте зайти по ssh, используя логин по умолчанию – admin. Давайте-ка поменяем его на что-то поприличнее (опять из conf t):
username admin secret cisco
line vty 0 15
login local
do wr
Теперь попробуйте зайти с рабочей станции на коммутатор и удостоверьтесь, что новые настройки вступили в силу.
Все маршрутизаторы добавляют подключенные маршруты. Затем в большинстве сетей используются протоколы динамической маршрутизации, чтобы каждый маршрутизатор изучал остальные маршруты в объединенной сети. Сети используют статические маршруты - маршруты, добавленные в таблицу маршрутизации посредством прямой настройки - гораздо реже, чем динамическая маршрутизация. Однако статические маршруты иногда могут быть полезны, и они также могут быть полезными инструментами обучения.
Статические сетевые маршруты
IOS позволяет назначать отдельные статические маршруты с помощью команды глобальной конфигурации ip route. Каждая команда ip route определяет пункт назначения, который может быть сопоставлен, обычно с идентификатором подсети и маской. Команда также перечисляет инструкции пересылки, обычно перечисляя либо исходящий интерфейс, либо IP-адрес маршрутизатора следующего перехода. Затем IOS берет эту информацию и добавляет этот маршрут в таблицу IP-маршрутизации.
Статический маршрут считается сетевым, когда пункт назначения, указанный в команде ip route, определяет подсеть или всю сеть класса A, B или C. Напротив, маршрут по умолчанию соответствует всем IP-адресам назначения, а маршрут хоста соответствует одному IP-адресу (то есть адресу одного хоста).
В качестве примера сетевого маршрута рассмотрим рисунок 1. На рисунке показаны только детали, относящиеся к статическому сетевому маршруту на R1 для подсети назначения 172.16.2.0/24, которая находится справа. Чтобы создать этот статический сетевой маршрут на R1, R1 настроит идентификатор и маску подсети, а также либо исходящий интерфейс R1 (S0/0/0), либо R2 в качестве IP-адреса маршрутизатора следующего перехода (172.16.4.2).
Схема сети устанавливает соединение между двумя маршрутизаторами R1, R2 и двумя хостами 1 и 2. Порт G0/0 .1 R1 подключен к шлейфу слева, который, в свою очередь, подключен к хосту 1, имеющему подсеть 172.16. 1.9. Интерфейс S0/0/0 R1 последовательно подключен к R2 с IP-адресом 172.16.4.2. Интерфейс G0/0.2 на R2 подключен к шлейфу, который, в свою очередь, подключен к хосту 2 с IP-адресом 172.16.2.0.9. Здесь маршрутизатор R1 предназначен для адреса 172.16.2.0/24 в подсети. Пакеты должны перемещаться либо с интерфейса S0/0/0 маршрутизатора R1, либо с маршрутизатора R2 с IP-адресом 172.16.2.0/24.
В примере 1 показана конфигурация двух примеров статических маршрутов. В частности, он показывает маршруты на маршрутизаторе R1 на рисунке 2 для двух подсетей в правой части рисунка.
При настройке сети маршрутизатор R1 имеет соединение с двумя маршрутизаторами R2 и R3 справа. Интерфейс G0/0 .1 маршрутизатора R1 подключен к заглушке слева и, в свою очередь, подключен к хосту A, имеющему подсеть 172.16.1.9 с маской подсети 172.16.1.0 /24. Справа-интерфейс S0/0/1.1 из R1 с маской подсети 172.16.4.0 / 24 подключается к интерфейсу S0/0/1.2 из R2 с маской подсети 172.16.2.0 / 24 через последовательную линию. Кроме того, интерфейс G0/1/ 0.1 из R1 с маской подсети 172.16.5.0 / 24 подключается к интерфейсу G0/0/0 .3 из R3 с маской подсети 172.16.3.0 / 24 через глобальную сеть. Заглушка подключается к интерфейсу G0/0 .2 из R2, где маска подсети равна 172.16.2.0 / 24 и, в свою очередь, подключена к хосту B, имеющему подсеть 172.16.2.9. Заглушка подключается к интерфейсу G0/0 .3 из R3, где маска подсети равна 172.16.3.0 / 24 и, в свою очередь, подключена к хосту C, имеющему подсеть 172.16.3.9.
ip route 172.16.2.0 255.255.255.0 S0/0/0
ip route 172.16.3.0 255.255.255.0 172.16.5.3
Пример 1 Добавление статических маршрутов в R1
В двух примерах команд ip route показаны два разных стиля инструкций пересылки. Первая команда показывает подсеть 172.16.2.0, маска 255.255.255.0, которая находится в локальной сети рядом с маршрутизатором R2. Эта же первая команда перечисляет интерфейс S0 / 0/0 маршрутизатора R1 как исходящий интерфейс. Этот маршрут в основном гласит: Чтобы отправить пакеты в подсеть с маршрутизатора R2, отправьте их через мой собственный локальный интерфейс S0/0/0 (который подключается к R2).
Второй маршрут имеет такую же логику, за исключением использования различных инструкций пересылки. Вместо того, чтобы ссылаться на исходящий интерфейс R1, он вместо этого перечисляет IP-адрес соседнего маршрутизатора на WAN-канале в качестве маршрутизатора следующего прыжка. Этот маршрут в основном говорит следующее:чтобы отправить пакеты в подсеть с маршрут.
Маршруты, созданные этими двумя командами ip route, на самом деле выглядят немного иначе в таблице IP-маршрутизации по сравнению друг с другом. Оба являются статическими маршрутами. Однако маршрут, который использовал конфигурацию исходящего интерфейса, также отмечается как подключенный маршрут; это всего лишь причуда вывода команды show ip route.
В примере 2 эти два маршрута перечислены с помощью статической команды show ip route. Эта команда выводит подробную информацию не только о статических маршрутах, но также приводит некоторые статистические данные обо всех маршрутах IPv4. Например, в этом примере показаны две строки для двух статических маршрутов, настроенных в примере 2, но статистика утверждает, что этот маршрутизатор имеет маршруты для восьми подсетей.
IOS динамически добавляет и удаляет эти статические маршруты с течением времени в зависимости от того, работает исходящий интерфейс или нет. Например, в этом случае, если интерфейс R1 S0/0/0 выходит из строя, R1 удаляет статический маршрут к 172.16.2.0/24 из таблицы маршрутизации IPv4. Позже, когда интерфейс снова открывается, IOS добавляет маршрут обратно в таблицу маршрутизации.
Обратите внимание, что большинство сайтов используют протокол динамической маршрутизации для изучения всех маршрутов к удаленным подсетям, а не статические маршруты. Однако если протокол динамической маршрутизации не используется, сетевому администратору необходимо настроить статические маршруты для каждой подсети на каждом маршрутизаторе. Например, если бы маршрутизаторы имели только конфигурацию, показанную в примерах до сих пор, ПК А (из рис. 2) не смог бы получать пакеты обратно от ПК В, потому что маршрутизатор R2 не имеет маршрута для подсети ПК А. R2 понадобятся статические маршруты для других подсетей, как и R3.
Наконец, обратите внимание, что статические маршруты, которые будут отправлять пакеты через интерфейс Ethernet - LAN или WAN, - должны использовать параметр IP-адреса следующего перехода в команде ip address, как показано в примере 2. Маршрутизаторы ожидают, что их интерфейсы Ethernet смогут достичь любого количества других IP-адресов в подключенной подсети. Ссылка на маршрутизатор следующего перехода определяет конкретное устройство в подключенной подсети, а ссылка на исходящий интерфейс локального маршрутизатора не определяет конкретный соседний маршрутизатор.
Статические маршруты хоста
Ранее в этой лекции маршрут хоста определялся как маршрут к одному адресу хоста. Для настройки такого статического маршрута команда ip route использует IP-адрес плюс маску 255.255.255.255, чтобы логика сопоставления соответствовала только этому одному адресу.
Сетевой администратор может использовать маршруты хоста для направления пакетов, отправленных одному хосту по одному пути, а весь остальной трафик - в подсеть этого хоста по другому пути. Например, вы можете определить эти два статических маршрута для подсети 10.1.1.0 / 24 и Хоста 10.1.1.9 с двумя различными адресами следующего перехода следующим образом:
ip route 10.1.1.0 255.255.255.0 10.2.2.2
ip route 10.1.1.9 255.255.255.255 10.9.9.9
Обратите внимание, что эти два маршрута перекрываются: пакет, отправленный в 10.1.1.9, который поступает на маршрутизатор, будет соответствовать обоим маршрутам. Когда это происходит, маршрутизаторы используют наиболее конкретный маршрут (то есть маршрут с наибольшей длиной префикса). Таким образом, пакет, отправленный на 10.1.1.9, будет перенаправлен на маршрутизатор следующего прыжка 10.9.9.9, а пакеты, отправленные в другие пункты назначения в подсети 10.1.1.0/24, будут отправлены на маршрутизатор следующего прыжка 10.2.2.2.
Плавающие статические маршруты
Затем рассмотрим случай, когда статический маршрут конкурирует с другими статическими маршрутами или маршрутами, изученными протоколом маршрутизации. То есть команда ip route определяет маршрут к подсети, но маршрутизатор также знает другие статические или динамически изученные маршруты для достижения этой же подсети. В этих случаях маршрутизатор должен сначала решить, какой источник маршрутизации имеет лучшее административное расстояние, а чем меньше, тем лучше, а затем использовать маршрут, полученный от лучшего источника.
Чтобы увидеть, как это работает, рассмотрим пример, проиллюстрированный на рисунке 3, который показывает другую конструкцию, чем в предыдущих примерах, на этот раз с филиалом с двумя каналами WAN: одним очень быстрым каналом Gigabit Ethernet и одним довольно медленным (но дешево) Т1. В этом проекте сеть Open Shortest Path First Version 2 (OSPFv2) по первичному каналу, изучая маршрут для подсети 172.16.2.0/24. R1 также определяет статический маршрут по резервному каналу к той же самой подсети, поэтому R1 должен выбрать, использовать ли статический маршрут или маршрут, полученный с помощью OSPF.
Сетевая диаграмма показывает интерфейс G0 / 0 маршрутизатора R1, который подключен к маршрутизатору R2 через ethernet через облако MPLS. Интерфейс S0 / 0 / 1 R1 соединен с маршрутизатором R3 по последовательной линии. R2 и R3 соединены в ядре облака корпоративной сети, имеющего подсеть 172.16.2.0/24. Маршрутизатор R1 достигает подсети либо по OSPF v1 по основному каналу, либо по статическому маршруту по резервному каналу.
По умолчанию IOS отдает предпочтение статическим маршрутам, чем маршрутам, изученным OSPF. По умолчанию IOS предоставляет статическим маршрутам административное расстояние 1, а маршрутам OSPF-административное расстояние 110. Используя эти значения по умолчанию на рисунке 3, R1 будет использовать T1 для достижения подсети 172.16.2.0 / 24 в этом случае, что не является удачным решением. Вместо этого сетевой администратор предпочитает использовать маршруты, изученные OSPF, по гораздо более быстрому основному каналу и использовать статический маршрут по резервному каналу только по мере необходимости, когда основной канал выходит из строя.
Чтобы отдавать предпочтение маршрутам OSPF, в конфигурации необходимо изменить настройки административного расстояния и использовать то, что многие сетевики называют плавающим статическим маршрутом. Плавающий статический маршрут перемещается в таблицу IP-маршрутизации или перемещается из нее в зависимости от того, существует ли в настоящее время лучший (меньший) маршрут административного расстояния, полученный протоколом маршрутизации. По сути, маршрутизатор игнорирует статический маршрут в то время, когда известен лучший маршрут протокола маршрутизации.
Чтобы реализовать плавающий статический маршрут, вам необходимо использовать параметр в команде ip route, который устанавливает административное расстояние только для этого маршрута, делая значение больше, чем административное расстояние по умолчанию для протокола маршрутизации. Например, команда ip route 172.16.2.0 255.255.255.0 172.16.5.3 130 на маршрутизаторе R1 будет делать именно это - установив административное расстояние статического маршрута равным 130. Пока основной канал остается активным, а OSPF на маршрутизаторе R1 изучает маршрут для 172.16.2.0/24, с административным расстоянием по умолчанию 110, R1 игнорирует статический маршрут.
Наконец, обратите внимание, что хотя команда show ip route перечисляет административное расстояние большинства маршрутов в виде первого из двух чисел в двух скобках, команда show ip route subnet явно указывает административное расстояние. В примере 3 показан образец, соответствующий этому последнему примеру.
Статические маршруты по умолчанию
Когда маршрутизатор пытается маршрутизировать пакет, он может не совпадать с IP-адресом назначения пакета ни с одним маршрутом. Когда это происходит, маршрутизатор обычно просто отбрасывает пакет.
Маршрутизаторы могут быть сконфигурированы таким образом, чтобы они использовали либо статически настроенный, либо динамически изучаемый маршрут по умолчанию. Маршрут по умолчанию соответствует всем пакетам, так что, если пакет не соответствует какому-либо другому более конкретному маршруту в таблице маршрутизации, маршрутизатор может, по крайней мере, переслать пакет на основе маршрута по умолчанию.
Классический пример, когда компании могут использовать статические маршруты по умолчанию в своих корпоративных сетях TCP / IP, - это когда компания имеет много удаленных узлов, каждый из которых имеет одно относительно медленное WAN-соединение. Каждый удаленный узел имеет только один возможный физический маршрут для отправки пакетов в остальную часть сети. Таким образом, вместо использования протокола маршрутизации, который отправляет сообщения по глобальной сети и использует драгоценную полосу пропускания глобальной сети, каждый удаленный маршрутизатор может использовать маршрут по умолчанию, который направляет весь трафик на центральный сайт, как показано на рисунке 4.
Соединение состоит из трех маршрутизаторов: Core, B1 и B1000. Последовательные соединения показаны между маршрутизаторами Core - B1 и Core - B1000. Все эти маршрутизаторы подключены к подсети индивидуально. Маршрутизатор B1 отправляет все нелокальные пакеты в Core через интерфейс S0/0/1. Существует также связь между B1 и B1000.
IOS позволяет настроить статический маршрут по умолчанию, используя специальные значения для полей подсети и маски в команде ip route: 0.0.0.0 и 0.0.0.0. Например, команда ip route 0.0.0.0 0.0.0.0 S0/0/1 создает статический маршрут по умолчанию на маршрутизаторе B1-маршрут, который соответствует всем IP-пакетам-и отправляет эти пакеты через интерфейс S0/0/1.
В примере 4 показан пример статического маршрута по умолчанию с использованием маршрутизатора R2 с рисунка 1. Ранее на этом рисунке вместе с примером 3 был показан маршрутизатор R1 со статическими маршрутами к двум подсетям в правой части рисунка. Пример 4 завершает настройку статических IP-маршрутов путем настройки R2 в правой части рисунка 1 со статическим маршрутом по умолчанию для маршрутизации пакетов обратно к маршрутизаторам в левой части рисунка.
Вывод команды show ip route содержит несколько новых и интересных фактов. Во-первых, он перечисляет маршрут с кодом S, что означает статический, но также со знаком *, что означает, что это кандидат в маршрут по умолчанию. Маршрутизатор может узнать о нескольких маршрутах по умолчанию, и затем маршрутизатор должен выбрать, какой из них использовать; * означает, что это, по крайней мере, кандидат на то, чтобы стать маршрутом по умолчанию. Чуть выше "шлюз последней надежды" относится к выбранному маршруту по умолчанию, который в данном случае является только что настроенным статическим маршрутом с исходящим интерфейсом S0/0/1.