По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В предыдущем материале мы рассмотрели, как работает Интернет на базовом уровне, включая взаимодействие между клиентом (вашим компьютером) и сервером (другим компьютером, который отвечает на запросы клиента о веб-сайтах). В этой же части рассмотрим, как устроены клиент, сервер и веб-приложение, что мы можем удобно серфить в Интернете. Модель клиент-сервер Эта идея взаимодействия клиента и сервера по сети называется моделью «клиент-сервер». Это делает возможным просмотр веб-сайтов (например, сайт wiki.merionet.ru) и взаимодействие с веб-приложением (как Gmail). На самом деле, модель клиент-сервер - это ни что иное, как способ описать отношения между клиентом и сервером в веб-приложении. Это детали того, как информация переходит от одного конца к другому, где картина усложняется. Базовая конфигурация веб-приложения Существует сотни способов настройки веб-приложения. При этом большинство из них следуют одной и той же базовой структуре: клиент, сервер, база данных. Клиент Клиент - это то, с чем взаимодействует пользователь. Так что «клиентский» код отвечает за большую часть того, что на самом деле видит пользователь. Это включает в себя: Определение структуры веб-страницы Настройка внешнего вида веб-страницы Реализация механизма пользовательского взаимодействия (нажатие кнопок, ввод текста и т.д.) Структура: Макет и содержимое веб-страницы определяются с помощью HTML (обычно HTML 5, если речь идет о современных веб-приложениях, но это другая история.) HTML означает язык гипертекстовой разметки (Hypertext Markup Language). Он позволяет описать основную физическую структуру документа с помощью HTML-тэгов. Каждый HTML-тэг описывает определенный элемент документа. Например: Содержимое тега «<h1>» описывает заголовок. Содержимое тега «<p>» описывает абзац. Содержимое тега «<button>» описывает кнопку. И так далее... Веб-браузер использует эти HTML-тэги для определения способа отображения документа. Look and Feel: Чтобы определить внешний вид веб-страницы, веб-разработчики используют CSS, который расшифровывается как каскадные таблицы стилей (Cascading Style Sheets). CSS - это язык, который позволяет описать стиль элементов, определенных в HTML, позволяя изменять шрифт, цвет, макет, простые анимации и другие поверхностные элементы. Стили для указанной выше HTML-страницы можно задать следующим образом: Взаимодействие с пользователем: Наконец, для реализации механизма взаимодействия с пользователем, на сцену выходит JavaScript. Например, если вы хотите что-то сделать, когда пользователь нажимает кнопку, вы можете сделать что-то подобное: Иногда взаимодействие с пользователем, может быть реализовано без необходимости обращения к вашему серверу - отсюда и термин "JavaScript на стороне клиента". Другие типы взаимодействия требуют отправки запросов на сервер для обработки. Например, если пользователь публикует комментарий в потоке, может потребоваться сохранить этот комментарий в базе данных, чтобы весь материал был структурирован и собран в одном месте. Таким образом, вы отправляете запрос на сервер с новым комментарием и идентификатором пользователя, а сервер прослушивает эти запросы и обрабатывает их соответствующим образом. Сервер Сервер в веб-приложении прослушивает запросы, поступающие от клиента. При настройке HTTP-сервера он должен прослушивать конкретный номер порта. Номер порта всегда связан с IP-адресом компьютера. Вы можете рассматривать порты как отдельные каналы на каждом компьютере, которые можно использовать для выполнения различных задач: один порт может быть использован для серфинга на wiki.merionet.ru, в то время как через другой получаете электронную почту. Это возможно, поскольку каждое из приложений (веб-браузер и клиент электронной почты) использует разные номера портов. После настройки HTTP-сервера для прослушивания определенного порта сервер ожидает клиентские запросов, поступающие на этот порт, выполняет все действия, указанные в запросе, и отправляет все запрошенные данные через HTTP-ответ. База данных Базы данных – это подвалы веб-архитектуры - большинство из нас боятся туда спускаться, но они критически важны для прочного фундамента. База данных - это место для хранения информации, чтобы к ней можно было легко обращаться, управлять и обновлять. Например, при создании сайта в социальных сетях можно использовать базу данных для хранения сведений о пользователях, публикациях и комментариях. Когда посетитель запрашивает страницу, данные, вставленные на страницу, поступают из базы данных сайта, что позволяет нам воспринимать взаимодействие пользователей в реальном времени как должное на таких сайтах, как Facebook или в таких приложениях, как Gmail. Как масштабировать простое веб-приложение Вышеописанная конфигурация отлично подходит для простых приложений. Но по мере роста приложения один сервер не сможет обрабатывать тысячи - если не миллионы - одновременных запросов от посетителей. Чтобы выполнить масштабирование в соответствии с этими большими объемами, можно распределить входящий трафик между группой внутренних серверов. Здесь все становится интересно. Имеется несколько серверов, каждый из которых имеет собственный IP-адрес. Итак, как сервер доменных имен (DNS) определяет, на какой экземпляр вашего приложения отправить трафик? Ответ очевиден - никак. Управление всеми этими отдельными экземплярами приложения происходит через средство балансировки нагрузки. Подсистема балансировки нагрузки действует как гаишник, который маршрутизирует клиентские запросы по серверам как можно быстрее и эффективнее, насколько это возможно. Поскольку вы не можете транслировать IP-адреса всех экземпляров сервера, вы создаете виртуальный IP-адрес, который транслируется клиентам. Этот виртуальный IP-адрес указывает на подсистему балансировки нагрузки. Таким образом, когда DNS ищет ваш сайт, он указывает на балансировщик нагрузки. Затем подсистема балансировки нагрузки перескакивает для распределения трафика на различные внутренние серверы в реальном времени. Возможно, вам интересно, как подсистема балансировки нагрузки узнаёт, на какой сервер следует отправлять трафик. Ответ: алгоритмы. Один популярный алгоритм, Round Robin, включает равномерное распределение входящих запросов по ферме серверов (все доступные серверы). Вы обычно выбираете такой подход, если все ваши серверы имеют одинаковую скорость обработки и память. С помощью другого алгоритма, Least Connections, следующий запрос отправляется на сервер с наименьшим количеством активных соединений. Существует гораздо больше алгоритмов, которые вы можете реализовать, в зависимости от ваших потребностей. Теперь поток трафика выглядит следующим образом: Службы Итак, мы решили проблему трафика, создав пулы серверов и балансировщик нагрузки для управления ими. Но одной репликация серверов может быть недостаточно для обслуживания приложения по мере его роста. По мере добавления дополнительных функциональных возможностей в приложение необходимо поддерживать тот же монолитный сервер, пока он продолжает расти. Для решения этой проблемы нам нужен способ разобщить функциональные возможности сервера. Здесь и появляется идея служб. Служба является просто другим сервером, за исключением того, что она взаимодействует только с другими серверами, в отличие от традиционного веб-сервера, который взаимодействует с клиентами. Каждая служба имеет автономную единицу функциональности, такую как авторизация пользователей или предоставление функции поиска. Службы позволяют разбить один веб-сервер на несколько служб, каждая из которых выполняет отдельные функции. Основное преимущество разделения одного сервера на множество сервисов заключается в том, что он позволяет масштабировать сервисы полностью независимо. Другое преимущество здесь заключается в том, что он позволяет командам внутри компании работать независимо над конкретной услугой, а не иметь 10, 100 или даже 1000 инженеров, работающих на одном монолитном сервере, который быстро становится кошмаром для менеджера проекта. Краткое примечание: эта концепция балансировщиков нагрузки и пулов внутренних серверов и служб становится очень сложной, поскольку вы масштабируете все больше и больше серверов в вашем приложении. Это особенно сложно с такими вещами, как, например, сохранение сеанса, обработка отправки нескольких запросов от клиента на один и тот же сервер в течение сеанса, развертывания решения для балансировки нагрузки. Такие продвинутые темы не будет затрагивать в данном материале. Сети доставки контента (Conten Delivery Network – CDN) Все вышеперечисленное отлично подходит для масштабирования трафика, но приложение все еще централизовано в одном месте. Когда ваши пользователи начинают посещать ваш сайт из других концов страны или с другого конца мира, они могут столкнуться с длительной задержкой из-за увеличенного расстояния между клиентом и сервером. Ведь речь идет о "всемирной паутине" - не о "местной соседней паутине". Популярная тактика решения этой проблемы - использование сети доставки контента (CDN). CDN - это большая распределенная система «прокси» серверов, развернутая во многих центрах обработки данных. Прокси-сервер - это просто сервер, который действует как посредник между клиентом и сервером. Компании с большим объемом распределенного трафика могут платить CDN-компаниям за доставку контента конечным пользователям с помощью серверов CDN. CDN имеет тысячи серверов, расположенных в стратегических географических точках по всему миру. Давайте сравним, как веб-сайт работает с CDN и без него. Как мы уже говорили в разделе 1, для типичного веб-сайта доменное имя URL преобразуется в IP-адрес сервера хоста. Однако если клиент использует CDN, доменное имя URL преобразуется в IP-адрес пограничного сервера, принадлежащего CDN. Затем CDN доставляет веб-контент пользователям клиента, не затрагивая серверы клиента. CDN может сделать это, сохраняя копии часто используемых элементов, таких как HTML, CSS, загрузки программного обеспечения и медиаобъектов с серверов клиентов. Главная цель - расположить контент сайта как можно ближе к конечному пользователю. В итоге пользователь получает более быструю загрузку сайта.
img
Frontend-разработчики — ключевая IT-профессия: фронтендеры отвечают за создание интерфейсов сайтов и приложений, которые привлекают внимание конечных пользователей по всему миру. В этой статье мы расскажем, что должен уметь фронтенд-разработчик, сколько получают такие специалисты и откуда взять опыт в этой сфере. Прежде всего, кто такой frontend-разработчик? Frontend-разработчик — это специалист, задачей которого является создание пользовательского интерфейса (UI) и пользовательского опыта (UX) для веб-сайтов или приложений. Проще говоря, frontend-разработчик отвечает за проектирование и создание визуальной части веб-сайтов и приложений. Сюда входят макеты, графика, текст и другие визуальные элементы, составляющие дизайн, а также код, который обеспечивают правильную работу всего этого. Что вообще означает Frontend? Frontend сайта, также называемый клиентской стороной или, в более широком смысле, пользовательским интерфейсом (UI), относится к тем частям сайта или приложения, которые видны пользователям и с которыми они могут взаимодействовать. Это всем нам знакомые кнопки, макеты, меню, формы обратной связи. Backend же, или серверная часть, относится к тем частям сайта, которые не видны конечному пользователю. Они управляет данными, которые обеспечивают работу сайта и отслеживают такие элементы, как учетные записи пользователей и историю. Несмотря на то, что фронтенд и бэкэнд противопоставляют, они тесно взаимодействуют друг с другом, обеспечивая правильную работу веб-страниц и приложений. Какие задачи решает фронтенд-разработчик? Frontend-разработчика можно назвать художником, который делает веб-сайты и приложения красивыми и плавно работающими. Для этого они используют различные языки программирования, инструменты и технологии. Основные обязанности фронтенд-разработчика включают: верстку — создание структуры и визуального оформления веб-страниц с использованием HTML и CSS. Программирование — реализацию интерактивности и динамического поведения веб-страниц с использованием JavaScript. Оптимизацию производительности — фронтенд-разработчики заботятся о том, чтобы веб-страницы загружались быстро и эффективно. Кроссбраузерную и кроссплатформенную совместимость — фронтенд-разработчики уделяют внимание тому, чтобы их код корректно отображался на различных браузерах и устройствах. Работу с фреймворками и библиотеками — использование различных инструментов, таких как React, Angular, или Vue.js, упрощающих разработку сложных пользовательских интерфейсов и обеспечивающих повторное использование кода. Frontend-разработчики часто работают в тесном сотрудничестве с дизайнерами, backend-разработчиками и другими специалистами по разработке, чтобы на сайте или в приложении все выглядело хорошо и работало слаженно. Что должен уметь фронтенд-разработчик? Хотя наличие формального образования может быть полезным для получения работы, следует отметить, что многие frontend-разработчики являются самоучками или приобретают свои знания на онлайн-курсах, например, Merion Academy, или на практике. В любом случае важно, чтобы вы могли продемонстрировать свои знания и умения с помощью портфолио и уверенного практического опыта. Ниже расскажем про ключевые навыки, которыми необходимо овладеть: Знание HTML, CSS и JavaScript: для успешной фронтенд-разработки необходимо хорошо разбираться в этих основных технологиях. Эти языки составляют основу frontend-разработки, и в создании пользовательских интерфейсов без них никуда. Знание фреймворков и библиотек: знание React, Angular и Vue.js, может оказаться полезным при разработке более сложных веб-приложений. Эти инструменты — база для создания отзывчивых, интерактивных и масштабируемых интерфейсов, которые так нравятся пользователям. Опыт работы с отзывчивым дизайном: frontend-разработчики должны уметь создавать веб-сайты и приложения, которые классно выглядят и легко работают на различных устройствах — смартфонах, планшетах, ПК. Это обеспечит пользователю позитивное восприятие продукта вне зависимости от девайса, которым он пользуется. Понимание основ дизайна: frontend-разработчик должен иметь насмотренность и понимать основы типографики, теории цвета и верстки. Эти навыки очень важны для создания интерфейсов, которые будут не только красивыми, но и удобными. Понимание кроссбраузерной совместимости: для frontend-разработчика очень важно, чтобы продукты, которые он создает, работали без сбоев в различных браузерах. Обеспечение корректной работы интерфейса в различных браузерах является важнейшей составляющей frontend-разработки. Верстка и frontend-разработка — одно и то же? Хоть верстальщик и фронтенд-разработчик выполняют различные задачи, у них есть много общих черт. Оба специалиста работают над созданием веб-интерфейсов и взаимодействуют с дизайнерами и backend-разработчиками. Оба они должны обладать хорошим пониманием HTML и CSS, а также знанием основ JavaScript. Важные навыки для обеих профессий — умение работать в команде, понимание принципов отзывчивого дизайна, владение инструментами контроля версий, такими как Git. Но все же нельзя говорить, что эти профессии идентичны. Frontend-разработчики в большей степени специализируются на пользовательской части сайта или приложения. Frontend-разработчики глубже понимают принципы пользовательского опыта и дизайна, и могут обеспечить интуитивную, простую в использовании и визуально привлекательную фичу на сайте или в приложении, которая зацепит пользователя. Основное различие между верстальщиком и фронтенд-разработчиком заключается в уровне сложности выполняемых задач. Верстальщик занимается преобразованием статического дизайна в код, в то время как фронтенд-разработчик работает над созданием динамических и интерактивных элементов веб-сайта с использованием языков программирования. Успешные фронтенд-разработчики часто стремятся расширять свои знания и умения в соответствии с требованиями индустрии, и они могут специализироваться в конкретных областях, таких как мобильная разработка, анимация интерфейсов, или работа с определенными фреймворками. Что объединяет верстальщика и фронтенд-разработчика Несмотря на то что верстальщик и фронтенд-разработчик выполняют различные задачи, у них есть много общих черт. Оба специалиста работают над созданием веб-интерфейсов и взаимодействуют с дизайнерами и backend-разработчиками. Они оба должны обладать хорошим пониманием HTML и CSS, а также знанием основ JavaScript. Важными навыками для обеих профессий являются умение работать в команде, понимание принципов отзывчивого дизайна и владение инструментами контроля версий, такими как Git. Основные различия между верстальщиком и фронтенд-разработчиком Основное различие между верстальщиком и фронтенд-разработчиком заключается в уровне сложности выполняемых задач. Верстальщик занимается преобразованием статического дизайна в код, в то время как фронтенд-разработчик работает над созданием динамических и интерактивных элементов веб-сайта с использованием языков программирования. Верстальщики фокусируются на "видимой" части веб-сайта, обеспечивая точное воплощение макетов дизайнеров в коде. Они также следят за тем, чтобы сайт корректно отображался в различных браузерах и на различных устройствах. Фронтенд-разработчики, с другой стороны, сосредотачиваются на создании интерактивности и функциональности веб-сайта. Они используют JavaScript и его фреймворки для разработки интерактивных элементов, таких как слайдеры, выпадающие меню, формы и другие. Как стать фронтенд-разработчиком? Чтобы стать хорошим специалистом, потребуется время и преданность делу. Поэтому лучше всего изучить все аспекты будущей профессии, прежде чем начать свой путь. Что бы мы посоветовали: Изучите основы: начните с онлайн-курса Merion Academy Frontend-разработчик с нуля. Затем испытайте полученные навыки на практике, создав несколько собственных проектов. Займитесь самообразованием: после того, как вы прошли курсы фронтенд-разработчика, не бросайте учиться. Существует множество образовательных программ по фронтенд-направлению — выберите ту, которая соответствует вашим способностям к обучению, бюджету, требованиям к работе, о которой вы мечтаете. Общайтесь и набирайтесь опыта: начните искать проекты для совместной работы, общайтесь с другими разработчиками, посещайте встречи и конференции, ищите наставников. Нетворкинг играет неоценимую роль в трудоустройстве! Сколько зарабатывают фронтенд-разработчики? Фронтенд-разработчики в России на сегодняшний день могут рассчитывать на зарплаты в весьма широком диапазоне. Разумеется, оплата зависит от навыков, опыта и уровня квалификации конкретного специалиста. Согласно hh.ru, заработная плата по вакансии фронтенд-разработчик может колебаться от 100 000 до 600 000 рублей и даже более в месяц. На уровень зарплаты влияет и грейд, и регион работы, а также любые дополнительные навыки — знание языков программирования, основ дизайна и даже маркетинга. Таким образом, фронтенд-разработчики в России имеют возможность получать действительно конкурентоспособные заработные платы, особенно если они совершенствуют свои навыки, следят за трендами в отрасли и стараются учиться новому. Не бойтесь экспериментировать и постоянно развиваться. Фронтенд-разработка — это не только профессия, но и постоянный поток на стыке технологий, дизайна и творчества.
img
Метрические веса TOS K1 K2 K3 K4 K5, выданные командой в режиме конфигурации маршрутизатора EIGRP, может быть использована для установки K-значений, используемых EIGRP в своем расчете. Параметр TOS был предназначен для использования маркировки качества обслуживания (где TOS обозначает тип служебного байта в заголовке IPv4). Однако параметр TOS должен быть равен 0. На самом деле, если вы введете число в диапазоне 1 - 8 и вернетесь назад, чтобы изучить свою текущую конфигурацию, вы обнаружите, что Cisco IOS изменила это значение на 0. Пять оставшихся параметров в команде metric weights - это пять K-значений, каждое из которых может быть задано числом в диапазоне от 0 до 255. Предыдущие статьи из цикла про EIGRP: Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка Часть 2. Про соседство и метрики EIGRP Следующие статьи из цикла: Часть 3. Конвергенция EIGRP – настройка таймеров Часть 4. Пассивные интерфейсы в EIGRP Часть 5. Настройка статического соседства в EIGRP Часть 6. EIGRP: идентификатор роутера и требования к соседству Например, представьте, что в нашем проекте мы обеспокоены тем, что нагрузка на наши линии может быть высокой в разы, и мы хотим, чтобы EIGRP учитывал уровень насыщения линии при расчете наилучшего пути. Изучая полную формулу расчета метрики EIGRP, мы замечаем, что наличие ненулевого значения для K2 приведет к тому, что EIGRP будет учитывать нагрузку. Поэтому мы решили установить K2 равным 1, в дополнение к K1 и K3, которые уже установлены в 1 по умолчанию. Значения К4 и К5 сохранится на уровне 0. В приведенном ниже примере показано, как можно настроить такой набор K-значений. OFF1#conf term Enter configuration commands, one per line. End with CNTL/Z . OFF1(config)#router eigrp 1 OFF1(config-router)#metric weights 0 1 1 1 0 0 OFF1(config-router)#end Первый 0 в команде metric weights 0 1 1 1 0 0, показанной в приведенном выше примере, задает значение TOS равное 0. Следующие пять чисел задают наши пять K-значений: K1 = 1, K2 = 1, K3 = 1, K4 = 0, K5 = 0. Этот набор K-значений теперь будет учитывать не только пропускную способность и задержку, но и нагрузку при выполнении расчета метрики. Однако есть проблема. Обратите внимание на сообщения консоли, появляющиеся после нашей конфигурации. Оба наших соседства были разрушены, потому что маршрутизатор OFF1 теперь имеет другие K-значения, чем маршрутизаторы OFF2 и OFF3. Напомним, что соседи EIGRP должны иметь соответствующие K-значения, а это означает, что при изменении K-значений на одном EIGRP-спикер маршрутизаторе, вам нужен идентичный набор K-значений на каждом из его соседей EIGRP. Как только вы настроите соответствующие K-значения на этих соседях, то каждый из этих соседей должен соответствовать K-значениям. Как вы можете видеть, в большой топологии может возникнуть значительная административная нагрузка, связанная с манипуляцией K-значением. Преемник и возможные маршруты преемников Одна из причин, по которой EIGRP быстро восстанавливает соединения в случае сбоя маршрута, заключается в том, что EIGRP часто имеет резервный маршрут, готовый взять на себя управление, если основной маршрут уходит в down. Чтобы убедиться, что резервный маршрут не зависит от основного маршрута, EIGRP тщательно проверяет резервный маршрут, убедившись, что он соответствует условию осуществимости EIGRP. В частности, условие осуществимости гласит: Маршрут EIGRP является возможным маршрутом-преемником, если его сообщенное расстояние (RD) от нашего соседа меньше возможного расстояния (FD) маршрута-преемника. Например, рассмотрим топологию, показанную на следующем рисунке, и соответствующую конфигурацию, приведенную ниже. Обратите внимание, что сеть 10.1.1.8/30 (между маршрутизаторами OFF2 и OFF3) доступна из OFF1 через OFF2 или через OFF3. Если маршрутизатор OFF1 использует маршрут через OFF2, он пересекает канал связи 1 Гбит/с, чтобы достичь целевой сети. Однако маршрут через OFF3 заставляет трафик пересекать более медленное соединение со скоростью 100 Мбит/с. Поскольку EIGRP учитывает пропускную способность и задержку по умолчанию, мы видим, что предпочтительный маршрут проходит через маршрутизатор OFF2. Однако, что делать, если связь между маршрутизаторами OFF1 и OFF2 обрывается? Есть ли возможный преемственный маршрут, который может почти сразу заработать? Опять же, мы видим, что маршрутизатор OFF1 будет использовать возможный маршрут преемника через маршрутизатор OFF3. Однако, прежде чем мы убедимся в этом, мы должны подтвердить, что путь через OFF3 соответствует условию осуществимости. Возможное условие преемника выполнено на маршрутизаторе OFF1 Просто в силу того, что маршрут через маршрутизатор OFF3 (то есть через 10.1.1.6) появляется в выходных данных команды show ip eigrp topology, выполненной на маршрутизаторе OFF1, мы делаем вывод, что путь через OFF3 действительно является возможным маршрутом-преемником. Однако давайте рассмотрим выходные данные немного более внимательно, чтобы определить, почему это возможный маршрут-преемник. Во-первых, рассмотрим запись из выходных данных в приведенном выше примере, идентифицирующую последующий маршрут (то есть предпочтительный маршрут): via 10.1.1.2 (3072/2816), GigabitEthernet0/1 Часть выходных данных via 10.1.1.2 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.2, который является маршрутизатором OFF2. На интерфейсе GigabitEthernet0/1 часть выходных данных указывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/1 (то есть выходной интерфейс). Теперь давайте рассмотрим эти два числа в скобках: (3072/2816). Стоимость 2816 называется зафиксированная дистанция (reported distance (RD). В некоторых литературных источниках это значение также называется advertised distance (AD). Эти термины, синонимы, относятся к метрике EIGRP, сообщенной (или объявленной) нашим соседом по EIGRP. В данном случае значение 2816 говорит нам, что метрика маршрутизатора OFF2 (то есть расстояние) до cети 10.1.1.8/30 равна 2816. Значение 3072 на выходе - это допустимое расстояние маршрутизатора OFF1 (FD). FD вычисляется путем добавления RD нашего соседа к метрике, необходимой для достижения нашего соседа. Поэтому, если мы добавим метрику EIGRP между маршрутизаторами OFF1 и OFF2 к RD маршрутизатора OFF2, мы получим FD (то есть общее расстояние), необходимое для того, чтобы OFF1 добрался до 10.1.1.8/30 через маршрутизатор OFF2. Кстати, причина, по которой маршрутизатор OFF1 определяет наилучший путь к сети 10.1.1.8/30, - это via via router OFF2 (то есть 10.1.1.2) В отличие от маршрутизатора OFF3 (то есть 10.1.1.6), потому что FD пути через OFF1 (3072) меньше, чем FD пути через OFF2 (28,416). Далее рассмотрим запись для возможного последующего маршрута из приведенного выше примера: via 10.1.1.6 (28416/2816), GigabitEthernet0/2 Часть выходных данных via 10.1.1.6 говорит, что этот маршрут указывает на адрес следующего прыжка 10.1.1.6, который является маршрутизатором OFF3. На интерфейсе GigabitEthernet0/2 часть результатов показывает, что мы выходим из маршрутизатора OFF1 через интерфейс Gig0/2. Эта запись имеет FD 28 416 и RD 2816. Однако прежде, чем EIGRP просто слепо сочтет этот резервный путь возможным преемником, он проверяет маршрут на соответствие условию осуществимости. В частности, процесс EIGRP на маршрутизаторе OFF1 запрашивает, является ли RD от маршрутизатора OFF3 меньше, чем FD последующего маршрута. В этом случае RD от маршрутизатора OFF3 составляет 2816, что действительно меньше, чем FD преемника 3072. Поэтому маршрут через маршрутизатор OFF3 считается возможным преемником маршрута. Чтобы утвердить эту важную концепцию, рассмотрим топологию, показанную ниже. Процесс EIGRP на маршрутизаторе OFF1 изучил три пути для достижения сети 10.1.1.0/24. Однако далее EIGRP должен определить, какой из этих путей является маршрутом-преемником, какие (если таковые имеются) пути являются возможными маршрутами-преемниками, а какие (если таковые имеются) пути не являются ни преемником, ни возможным маршрутом-преемником. Результаты расчетов EIGRP приведены в таблице ниже. Примеры расчетов Feasible Successor Используя приведенную выше таблицу в качестве рассмотрения, сначала рассмотрим путь маршрутизатора OFF1 к сети 10.1.1.0/24 через маршрутизатор OFF2. С точки зрения маршрутизатора OFF2, расстояние до сети 10.1.1.0/24 - это расстояние от OFF2 до OFF5 (которое равно 5000) плюс расстояние от OFF5 до сети 10.1.1.0/24 (которое равно 1000). Это дает нам в общей сложности 6000 для расстояния от маршрутизатора OFF2 до сети 10.1.1.0/24. Это расстояние, которое маршрутизатор OFF2 сообщает маршрутизатору OFF1. Таким образом, маршрутизатор OFF1 видит RD 6000 от маршрутизатора OFF2. Маршрутизатор OFF1, затем добавляет расстояние между собой и маршрутизатором OFF2 (который равен 10 000) к RD от OFF2 (который равен 6000), чтобы определить его FD для достижения сети 10.1.1.0/24 составляет 16 000 (то есть 10 000 + 6000 = 16 000). Процесс EIGRP на маршрутизаторе OFF1 выполняет аналогичные вычисления для путей к сети 10.1.1.0/24 через маршрутизаторы OFF3 и OFF4. Ниже приведены расчеты, которые привели к значениям, приведенным в таблице. Затем маршрутизатор OFF1 проверяет результаты этих вычислений и определяет, что кратчайшее расстояние до сети 10.1.1.0/24 проходит через маршрутизатор OFF2, поскольку путь через OFF2 имеет самый низкий FD (16 000). Этот путь, определяемый как кратчайший, считается следующим маршрутом. Затем маршрутизатор OFF1 пытается определить, соответствует ли любой из других маршрутов условию выполнимости EIGRP. В частности, маршрутизатор OFF1 проверяет, чтобы увидеть, что RD от маршрутизаторов OFF3 или OFF4 меньше, чем FD последующего маршрута. В случае OFF3 его RD в 11 000 действительно меньше, чем FD последующего маршрута (который составляет 16 000). Таким образом, путь к сети 10.1.1.0 /24 через OFF3 квалифицируется как возможный маршрут-преемник. Однако маршрут через OFF4 не подходит, потому что RD OFF4 из 18 000 больше, чем 16 000 (FD последующего маршрута). В результате путь к сети 10.1.1.0/24 через маршрутизатор OFF4 не считается возможным маршрутом-преемником. Мы изучили K - значения, теперь почитайте про конвергенцию EIGRP и настройку таймеров
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59