По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вторая часть тут
Пересечение многочисленных дискуссий в мире сетевого инжиниринга, было одной из проблем, которая затрудняла принятие решения о том, является ли коммутация пакетов или каналов лучшим решением. Как следует вычислять loop-free пути в сети с коммутацией пакетов?
Поскольку сети с коммутацией пакетов на протяжении всей истории сетевой инженерии ассоциировались с распределенными плоскостями управления (control plane), а сети с коммутацией каналов -с централизованными плоскостями управления (control plane), проблема эффективного вычисления безцикловых (loop-free) путей оказала значительное влияние на принятие решения о том, являются ли сети с коммутацией пакетов жизнеспособными или нет.
На заре сетевой инженерии доступная вычислительная мощность, память и пропускная способность часто были в дефиците.
В 1984 году, когда происходили в основном своем эти дискуссии, любая разница в объеме процессора и памяти между двумя способами расчета безцикловых путей через сеть оказала бы существенное влияние на стоимость построения сети. Когда пропускная способность имеет первостепенное значение, уменьшение количества битов, требуемых плоскостью управления (control plane) для передачи информации, необходимой для вычисления набора loop-free путей через сеть, создает реальную разницу в объеме пользовательского трафика, который может обрабатывать сеть. Уменьшение количества битов, необходимых для работы элемента управления, также вносит большую разницу в стабильность сети при более низких полосах пропускания.
Например, использование формата Type Length Vector (TLV) для описания информации о плоскости управления (control plane), передаваемой по сети, добавляет несколько октетов информации к общей длине пакета-но в контексте канала 2 Мбит / с, усугубленного chatty control plane, затраты могут значительно перевесить долгосрочное преимущество расширяемости протокола.
Протокольные войны в некоторых моментах были довольно жаркими. Были организованы целые исследовательские проекты и написаны статьи о том, почему и как один протокол лучше другого.
Было предложено большое разнообразие механизмов для решения задач вычисления loop-free путей через сеть. В конечном счете были широко развернуты и использованы три общих класса решений:
Distance Vector protocols (протоколы вектора расстояния), которые вычисляют свободные от петель пути hop by hop на основе стоимости пути.
Link State protocols (протоколы состояния связи), которые вычисляют свободные от петель пути через базу данных, синхронизированную между сетевыми устройствами.
Path Vector protocols (протоколы вектора пути), которые вычисляют свободные от петель пути hop by hop на основе записи предыдущих прыжков.
Дискуссия о том, какой протокол лучше всего подходит для каждой конкретной сети и по каким конкретным причинам, все еще продолжается. И это, возможно, бесконечный спор, поскольку нет окончательного ответа на этот вопрос. Возможно, как и при подгонке сети под бизнес, всегда будет какая-то степень искусства, связанная с тем, чтобы заставить конкретную плоскость управления (control plane) работать в конкретной сети. Однако большая часть актуальности этого вопроса была вызвана ростом скорости сетей-вычислительной мощности, памяти и пропускной способности.
Четвертую часть цикла статей про QoS можно почитать по ссылке.
Типичный эксплойт может начать с получения злоумышленником доступа к учетной записи с меньшими привилегиями. После входа в систему злоумышленники будут изучать систему для выявления других уязвимостей, которые они могут использовать в дальнейшем. Затем они используют привилегии для олицетворения фактических пользователей, получения доступа к целевым ресурсам и выполнения различных необнаруженных задач.
Атаки типа эскалации привилегий бывают вертикальными и горизонтальными.
В вертикальном типе злоумышленник получает доступ к учетной записи, а затем выполняет задачи в качестве этого пользователя. Для горизонтального типа злоумышленник сначала получит доступ к одной или нескольким учетным записям с ограниченными привилегиями, а затем скомпрометирует систему, чтобы получить больше прав на выполнение административных ролей.
Такие права позволяют злоумышленникам выполнять административные задачи, развертывать вредоносные программы или выполнять другие нежелательные действия. Например, они могут нарушить работу, изменить параметры безопасности, украсть данные или скомпрометировать системы таким образом, чтобы оставить открытые бэкдоры для использования в будущем.
Как правило, подобно кибератакам, эскалация привилегий использует систему и обрабатывает уязвимости в сетях, службах и приложениях. Таким образом, их можно предотвратить, сочетая передовые методов и инструменты обеспечения безопасности. В идеале организация должна развертывать решения, которые могут сканировать, обнаруживать и предотвращать широкий спектр потенциальных и существующих уязвимостей и угроз безопасности.
Рекомендации по предотвращению атак эскалации привилегий
Организации должны защищать все критически важные системы и данные, а также другие области, которые могут выглядеть непривлекательными для злоумышленников. Все, что требуется злоумышленнику – это проникнуть в систему. Находясь внутри, они могут искать уязвимости, которые используют в дальнейшем, чтобы получить дополнительные привилегии. Помимо защиты активов от внешних угроз, важно принять достаточные меры для предотвращения и внутренних атак.
Хотя применяемые методы могут отличаться в зависимости от систем, сетей, среды и других факторов, ниже приведены некоторые методы, которые организации могут использовать для защиты своей инфраструктуры.
Защита и сканирование сети, систем и приложений
В дополнение к развертыванию решения по обеспечению безопасности в режиме реального времени необходимо регулярно проверять все компоненты ИТ-инфраструктуры на наличие уязвимостей, которые могут привести к новым угрозам проникновения. Для этого можно использовать эффективный сканер уязвимостей для поиска незащищенных операционных систем и приложений, неправильных настроек, слабых паролей и других недостатков, которые могут быть использованы злоумышленниками.
Хотя можно использовать различные сканеры уязвимостей для выявления слабых мест в устаревшем программном обеспечении, обычно трудно или нецелесообразно обновлять, или исправлять все системы. В частности, это является проблемой при работе с устаревшими компонентами или крупномасштабными производственными системами.
В таких случаях можно развернуть дополнительные уровни безопасности, такие как брандмауэры веб-приложений (WAF), которые обнаруживают и останавливают вредоносный трафик на сетевом уровне. Как правило, WAF обеспечивает защиту базовой системы даже в том случае, если на нем не установлены необходимые патчи или устарела.
Правильное управление учетными записями с привилегиями
Важно управлять привилегированными учетными записями и гарантировать, что все они безопасны, используются в соответствии с передовыми практиками и не раскрываются. Группы безопасности должны иметь список всех привилегированных учетных записей, их расположение и для чего они используются.
Другие меры включают:
Минимизация количества и объема привилегированных учетных записей, мониторинг и ведение журнала их деятельности;
Анализ каждого привилегированного пользователя или учетной записи для выявления и устранения любых рисков, потенциальных угроз, источников и намерений злоумышленников;
Основные виды атак и меры по предотвращению;
Соблюдайте принцип наименьших привилегий;
Запретить администраторам предоставлять общий доступ к учетным записям и учетным данным.
Мониторинг поведения пользователей
Анализ поведения пользователя позволяет определить наличие скомпрометированных учетных записей. Обычно злоумышленники нацеливаются на пользователей, которые обеспечивают доступ к системам организации. Если им удастся получить учетные данные, они войдут в сеть и могут остаться незамеченными в течение некоторого времени.
Поскольку трудно вручную контролировать поведение каждого пользователя, оптимальным подходом является развертывание решения UEBA (User and Entity Behavior Analytics). Такой инструмент непрерывно отслеживает активность пользователя за определённое время. Затем создает нормальный базовый уровень поведения, который используется для обнаружения необычных действий. Это один из показателей скомпрометированных учетных записей.
Результирующий профиль содержит такую информацию, как местоположение, ресурсы, файлы данных и услуги, к которым обращается пользователь, и их частота, конкретные внутренние и внешние сети, количество хостов, а также выполняемые процессы. С помощью этой информации инструмент может идентифицировать подозрительные действия или параметры, которые отклоняются от базовой линии.
Создание и применение политики надёжных паролей
Создайте и применяйте надежные политики, чтобы пользователи имели уникальные и трудноугадываемые пароли. Кроме того, многофакторная аутентификация добавляет дополнительный уровень безопасности при преодолении уязвимостей, которые могут возникнуть, когда трудно вручную применить надежные политики паролей.
Группы безопасности также должны развернуть необходимые средства, которые могут сканировать системы, выявлять и отмечать слабые пароли или предлагать действия. Это аудиторы паролей, средства защиты политик и другие. Средства принудительного применения гарантируют наличие у пользователей надежных паролей с точки зрения длины, сложности и политик компании.
Организации также могут использовать корпоративные средства управления паролями, помогающие пользователям создавать и использовать сложные и безопасные пароли, соответствующие политикам служб, требующих проверки подлинности.
Дополнительные меры, такие как многофакторная аутентификация для разблокировки диспетчера паролей, повышают его безопасность, что делает практически невозможным доступ злоумышленников к сохраненным учетным данным. Типичные корпоративные менеджеры паролей включают Keeper, Dashlane, 1Password.
Обезопасить пользовательские вводы и защитить базы данных
Злоумышленники могут использовать уязвимые поля пользовательского ввода, а также базы данных для ввода вредоносного кода, получения доступа и компрометации систем. По этой причине группы безопасности должны использовать такие передовые методы, как строгая аутентификация и эффективные инструменты для защиты баз данных и всех типов полей ввода данных.
В дополнение к своевременному установлению патчей баз данных и защите всех пользовательских входных данных, хорошей практикой считается шифрование всех передаваемых и хранящихся данных. Не лишним будет назначение файлам атрибута только для чтения, а доступ для записи предоставлять группам и пользователям по запросу.
Обучение пользователей
Пользователи являются самым слабым звеном в цепочке обеспечения безопасности организации. Поэтому важно расширить их возможности и обучить тому, как безопасно выполнять свои задачи. В противном случае один щелчок пользователя может привести к компрометации всей сети или системы. Некоторые из рисков включают открытие вредоносных ссылок или вложений, посещение веб-сайтов с нарушением безопасности, использование слабых паролей и многое другое.
В идеале организация должна иметь регулярные программы повышения уровня безопасности. Кроме того, они должны иметь методологию проверки эффективности обучения.
Средства предотвращения атак эскалации привилегий
Предотвращение атак эскалации привилегий требует сочетания инструментов. Они включают, но не ограничиваются приведенными ниже решениями.
Решение для анализа поведения пользователей и объектов (UEBA)
1. Exabeam
Платформа Exabeam Security Management - это быстрое и простое в развертывании решение для анализа поведения на основе ИИ, которое помогает отслеживать действия пользователей и учетных записей в различных службах. С помощью Exabeam можно также получать журналы из других ИТ-систем и средств безопасности, анализировать их, выявлять и отмечать опасные действия, угрозы и другие проблемы.
Функции:
Ведение журнала и предоставление полезной информации для расследования инцидентов. К ним относятся все сеансы, когда конкретная учетная запись или пользователь впервые получили доступ к службе, серверу, приложению или ресурсу, учетная запись входит в систему с нового VPN-соединения, из другой страны и т.д;
Масштабируемое решение применимо для развертывания в одном экземпляре, облаке и локально;
Создает всеобъемлющую временную шкалу, которая четко показывает полный путь злоумышленника на основе нормальной и ненормальной учетной записи или поведения пользователя.
2. Cynet 360
Платформа Cynet 360 - это комплексное решение, обеспечивающее поведенческую аналитику, защиту сети и конечных точек. Она позволяет создавать профили пользователей, включая их геолокации, роли, часы работы, шаблоны доступа к локальным и облачным ресурсам и т.д.
Платформа помогает выявлять необычные виды деятельности, такие как;
Вход в систему или ресурсы в первый раз
Вход с нового места или использование нового VPN-подключения
Несколько параллельных подключений к нескольким ресурсам в течение очень короткого времени
Учетные записи, получающие доступ к ресурсам в нерабочее время
Средства защиты паролей
3. Password Auditor
Средства аудита паролей сканируют имена хостов и IP-адреса, чтобы автоматически идентифицировать слабые учетные данные для таких сетевых служб и веб-приложений, как веб-формы HTTP, MYSQL, FTP, SSH, RDP, сетевые маршрутизаторы и другие, требующие аутентификации сервисы. Затем он пытается войти в систему с использованием слабых, а также часто используемых комбинаций имен пользователей и паролей для идентификации и оповещения об учетных записях со слабыми учетными данными.
4. Password Manager Pro
Менеджер паролей ManageEngine pro предоставляет комплексное решение по управлению, контролю, мониторингу и аудиту привилегированной учетной записи на протяжении всего ее жизненного цикла. Он может управлять привилегированной учетной записью, SSL-сертификатом, удаленным доступом, а также привилегированным сеансом.
Функции:
Автоматизация и обеспечение частого сброса паролей для критически важных систем, таких как серверы, сетевые компоненты, базы данных и другие ресурсы
Хранение и организация всех привилегированных и конфиденциальных учетных записей и паролей в централизованном и безопасном хранилище.
Позволяет организациям выполнять критические аудиты безопасности, а также соответствовать нормативным требованиям, таким как HIPAA, PCI, SOX и т.д.
Позволяет участникам группы безопасно обмениваться административными паролями.
Сканер уязвимостей
5. Netsparker
Netsparker - это масштабируемое автоматизированное решение для поиска уязвимостей и управления, которое может масштабироваться в соответствии с требованиями любой организации. Это средство может сканировать сложные сети и среды, обеспечивая прозрачную интеграцию с другими системами, включая решения CI/CD, SDLC и другие. Она обладает расширенными возможностями и оптимизирована для сканирования и выявления уязвимостей в сложных средах и приложениях.
Кроме того, Netsparker можно использовать для проверки веб-серверов на наличие неправильных настроек безопасности, которые могут использоваться злоумышленниками. Как правило, средство обнаруживает возможность SQL-инъекций, удаленное включение файлов, межсайтовый скриптинг (XSS) и другие уязвимости из Top-10 OWASP в веб-приложениях, веб-службах, веб-страницах, API и т.д.
6. Acunetix
Acunetix - это комплексное решение со встроенными средствами поиска уязвимостей, управления и простой интеграции с другими средствами безопасности. Это помогает автоматизировать такие задачи управления уязвимостями, как сканирование и исправление, что позволяет экономить ресурсы.
Функции:
Интегрируется с другими инструментами, вроде Jenkins, GitHub, Jira, Mantis и многое другое;
Локальные и облачные варианты развертывания;
Возможность настройки в соответствии со средой и требованиями заказчика, а также межплатформенная поддержка;
Быстрое выявление и реагирование на широкий спектр проблем безопасности, включая распространенные веб-атаки, межсайтовые скриптинг (XSS), SQL- инъекции, вредоносные программы, неправильные настройки, незащищенные ресурсы и т.д.
Решения PAM (Privileged Access Management)
7. JumpCloud
Jumpcloud - это решение Directory as a Service (DaaS), которое обеспечивает безопасную аутентификацию и подключение пользователей к сетям, системам, службам, приложениям и файлам. Как правило, масштабируемый облачный каталог представляет собой службу, которая управляет, аутентифицирует и авторизирует пользователей, приложения и устройства.
Функции:
Создает безопасный и централизованный авторитетный каталог;
Поддержка межплатформенного управления доступом пользователей;
Предоставляет функции единого входа, поддерживающие управление доступом пользователей к приложениям через LDAP, SCIM и SAML 2.0;
Обеспечивает безопасный доступ к локальным и облачным серверам;
Поддержка многофакторной аутентификации;
Автоматизированное администрирование безопасности и связанных с ней функций, вроде ведения журнала событий, создания сценариев, управления API, PowerShell и многое другое
8. Ping Identity
Ping Identity - это интеллектуальная платформа, обеспечивающая многофакторную аутентификацию, единый вход, службы каталогов и многое другое. Это позволяет организациям повысить безопасность и эффективность идентификации пользователей.
Особенности:
Единый вход, обеспечивающий безопасную и надежную аутентификацию и доступ к услугам;
Многофакторная аутентификация, добавляющая дополнительные уровни безопасности;
Улучшенное управление данными и способность соблюдать правила конфиденциальности;
Службы каталогов, обеспечивающие безопасное управление идентификационными данными пользователей и данными;
Гибкие возможности развертывания облачных сред, такие как Identity-as-a-Service (IDaaS), контейнерное программное обеспечение и т.д.
9. Foxpass
Foxpass - это масштабируемое решение для управления идентификацией и доступом корпоративного уровня для локальных и облачных развертываний. Она предоставляет функции управления ключами RADIUS, LDAP и SSH, которые обеспечивают доступ каждого пользователя только к определенным сетям, серверам, VPN и другим услугам в разрешенное время.
Средство легко интегрируется с другими службами, такими как Office 365, Google Apps и т.д.
10. AWS Secrets Manager
AWS Secrets Manager предоставляет надежные и эффективные средства защиты паролей и других данных, необходимых для доступа к службе, приложениям и другим ресурсам. Она позволяет легко управлять ключами API, учетными данными базы данных и т.д.
Заключение
Подобно кибератакам, эскалация привилегий использует уязвимости в системе, сетях, службах и приложениях. Таким образом, их можно предотвратить, развернув правильные средства и методы обеспечения безопасности.
Эффективные меры включают обеспечение наименьших привилегий, надежных паролей и политик проверки подлинности, защиту конфиденциальных данных, уменьшение поверхности атаки, защиту учетных данных пользователей и многое другое. Не будет лишним своевременное обновление и исправление всех систем, программного обеспечения и встроенного ПО, мониторинг поведения пользователей и обучение пользователей методам безопасной работы с вычислительными системами.
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки:
Первую часть статьи про траблшутинг EIGRP можно почитать здесь.
Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась.
Было настроено автосуммирование или кто-то настроил суммирование вручную
Split-horizon блокирует объявление маршрутной информации.
Перераспределение было настроено, но информация из EIGRP не используется.
Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются.
Case #1
Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов:
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 1.1.1.0 0.0.0.255
OFF1(config-router)#network 192.168.12.0 0.0.0.255
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config-router)#network 192.168.12.0 0.0.0.255
Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите:
По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации.
Видно, что на OFF1 не настроен distribute lists.
OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит.
Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list.
Другой быстрый способ проверить это - использовать команду show ip protocol.
В этом случае использование show run могло бы быстрее обнаружить distribute-list.
Вот список доступа, доставляющий нам неприятности.
OFF2(config)#router eigrp 12
OFF2(config-router)#no distribute-list 1 out
Удалим distribute-list.
Задача решена!
Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации.
Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа.
Case #2
В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация:
OFF1(config)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF1(config-router)#network 10.0.0.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.12.0
OFF2(config-router)#network 10.0.0.0
Как вы видите - это довольно базовая конфигурация.
Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации.
Давайте включим отладку и посмотрим, что мы можем найти.
OFF2#clear ip eigrp 12 neighbors
Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс.
Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам:
Суммирование было кем-то настроено
Авто-суммирование включено для EIGRP.
Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
Отключение автоматического суммирования должно помочь.
Ну что, наши сети появились в таблице маршрутизации.
Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями.
Case #3
Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов:
Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование.
Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16.
Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит?
OFF2#clear ip eigrp 12 neighbors
Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс.
Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1.
Давайте проведем отладку OFF1.
Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его.
Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование.
Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена!
Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов.
Case #4
Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов.
Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах.
Суммирование было настроено на OFF2 и должно быть объявлено к OFF1.
К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так.
Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show.
Странно, это единственная сеть, которую OFF2 объявляет.
Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24.
Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи.
OFF2(config)#interface loopback 0
OFF2(config-if)#no shutdown
OFF2(config)#interface loopback 1
OFF2(config-if)#no shutdown
Включим интерфейсы.
Теперь мы видим, что суммирование объявляется.
Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена!
Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации.
ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон!
Case #5
Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов:
CONC(config)#router eigrp 123
CONC(config-router)#no auto-summary
CONC(config-router)#network 192.168.123.0
OFF1(config-if)#router eigrp 123
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 192.168.123.0
OFF1(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config)#router eigrp 123
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 192.168.123.0
OFF2(config-router)#network 3.3.3.0 0.0.0.255
Видно, что все сети объявлены.
Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов.
К сожалению, наши маршрутизаторы не видят ничего ...
Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит.
CONC#clear ip eigrp 123 neighbors
Сбросим соседство EIGRP, чтобы ускорить процесс.
В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой.
CONC(config)#interface serial 0/0
CONC(config-if)#no ip split-horizon eigrp 123
Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора.
Теперь мы видим, что маршрутизатор-концентратор объявляет все сети.
OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все.
Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали.
Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить.
Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом:
Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3:
Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1?
Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC.
У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2.
Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом:
Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем!
Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2
Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3.
Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2.
OFF2(config)#int s0/0
OFF2(config-if)#frame-relay map ip 192.168.123.2 301
Давайте frame-relay map сами.
Теперь роутер OFF2 знает, как связаться с роутером OFF1
Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map:
OFF1(config)#int s0/0
OFF1(config-if)#frame-relay map ip 192.168.123.3 201
Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1.
И наш пинг проходит!