По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Буферизация пакетов для работы с перегруженным интерфейсом кажется прекрасной идеей. Действительно, буферы необходимы для обработки трафика, поступающего слишком быстро или несоответствия скорости интерфейса - например, при переходе от высокоскоростной LAN к низкоскоростной WAN. До сих пор это обсуждение QoS было сосредоточено на классификации, приоритизации и последующей пересылке пакетов, помещенных в очередь в этих буферах, в соответствии с политикой. Максимально большой размер буферов кажется хорошей идеей. Теоретически, если размер буфера достаточно велик, чтобы поставить в очередь пакеты, превышающие размер канала, все пакеты в конечном итоге будут доставлены. Однако, как большие, так и переполненные буферы создают проблемы, требующие решения.
Когда пакеты находятся в буфере, они задерживаются. Некоторое количество микросекунд или даже миллисекунд добавляется к пути пакета между источником и местом назначения, пока они находятся в буфере, ожидая доставки. Задержка перемещения является проблемой для некоторых сетевых разговоров, поскольку алгоритмы, используемые TCP, предполагают предсказуемую и в идеале небольшую задержку между отправителем и получателем.
В разделе активного управления очередью вы найдете различные методы управления содержимым очереди. Некоторые методы решают проблему переполненной очереди, отбрасывая достаточно пакетов, чтобы оставить немного места для вновь поступающих. Другие методы решают проблему задержки, поддерживая небольшую очередь, минимизируя время, которое пакет проводит в буфере. Это сохраняет разумную задержку буферизации, позволяя TCP регулировать скорость трафика до скорости, соответствующей перегруженному интерфейсу.
Управление переполненным буфером: взвешенное произвольное раннее обнаружение (WRED)
Произвольное раннее обнаружение (RED) помогает нам справиться с проблемой переполненной очереди. Буферы не бесконечны по размеру: каждому из них выделено определенное количество памяти. Когда буфер заполняется пакетами, новые поступления отбрасываются. Это не сулит ничего хорошего для критического трафика, такого как VoIP, от которого нельзя отказаться, не повлияв на взаимодействие с пользователем. Способ решения этой проблемы - убедиться, что буфер никогда не будет полностью заполнен. Если буфер никогда не заполняется полностью, то всегда есть место для приема дополнительного трафика.
Чтобы предотвратить переполнение буфера, RED использует схему упреждающего отбрасывания выбранного входящего трафика, оставляя места открытыми. Чем больше заполняется буфер, тем больше вероятность того, что входящий пакет будет отброшен. RED является предшественником современных вариантов, таких как взвешенное произвольное раннее обнаружение (WRED). WRED учитывает приоритет входящего трафика на основе своей отметки. Трафик с более высоким приоритетом будет потерян с меньшей вероятностью. Более вероятно, что трафик с более низким приоритетом будет отброшен. Если трафик использует какую-либо форму оконного транспорта, например, такую как TCP, то эти отбрасывания будут интерпретироваться как перегрузка, сигнализирующая передатчику о замедлении.
RED и другие варианты также решают проблему синхронизации TCP. Без RED все входящие хвостовые пакеты отбрасываются при наличии переполненного буфера. Для трафика TCP потеря пакетов в результате отбрасывания хвоста приводит к снижению скорости передачи и повторной передаче потерянных пакетов. Как только пакеты будут доставлены снова, TCP попытается вернуться к более высокой скорости. Если этот цикл происходит одновременно во многих разных разговорах, как это происходит в сценарии с отключением RED-free, интерфейс может испытывать колебания использования полосы пропускания, когда канал переходит от перегруженного (и сбрасывания хвоста) к незагруженному и недоиспользованному, поскольку все д throttled-back TCP разговоры начинают ускоряться. Когда уже синхронизированные TCP-разговоры снова работают достаточно быстро, канал снова становится перегруженным, и цикл повторяется.
RED решает проблему синхронизации TCP, используя случайность при выборе пакетов для отбрасывания. Не все TCP-разговоры будут иметь отброшенные пакеты. Только определенные разговоры будут иметь отброшенные пакеты, случайно выбранные RED. TCP-разговоры, проходящие через перегруженную линию связи, никогда не синхронизируются, и колебания избегаются. Использование каналов связи более устойчиво.
Управление задержкой буфера, Bufferbloat и CoDel
Здесь может возникнуть очевидный вопрос. Если потеря пакетов - это плохо, почему бы не сделать буферы достаточно большими, чтобы справиться с перегрузкой? Если буферы больше, можно поставить в очередь больше пакетов, и, возможно, можно избежать этой досадной проблемы потери пакетов. Фактически, эта стратегия больших буферов нашла свое применение в различных сетевых устройствах и некоторых схемах проектирования сети. Однако, когда перегрузка канала приводит к тому, что буферы заполняются и остаются заполненными, большой буфер считается раздутым. Этот феномен так хорошо известен в сетевой индустрии, что получил название: bufferbloat.
Bufferbloat имеет негативный оттенок, потому что это пример слишком большого количества хорошего. Буферы - это хорошо. Буферы предоставляют некоторую свободу действий, чтобы дать пачке пакетов где-нибудь остаться, пока выходной интерфейс обработает их. Для обработки небольших пакетов трафика необходимы буферы с критическим компромиссом в виде введения задержки, однако превышение размера буферов не компенсирует уменьшение размера канала. Канал имеет определенную пропускную способность. Если каналу постоянно предлагается передать больше данных, чем он может передать, то он плохо подходит для выполнения требуемой от него задачи. Никакая буферизация не может решить фундаментальную проблему пропускной способности сети.
Увеличение размера буфера не улучшает пропускную способность канала. Фактически, постоянно заполненный буфер создает еще большую нагрузку на перегруженный интерфейс. Рассмотрим несколько примеров, противопоставляющих протоколов Unacknowledged Datagram Protocol (UDP) и Transmission Control Protocol (TCP).
В случае VoIP-трафика буферизованные пакеты прибывают с опозданием. Задержка чрезвычайно мешает голосовой беседе в реальном времени. VoIP - это пример трафика, передаваемого посредством UDP через IP. UDP-трафик не подтверждается. Отправитель отправляет пакеты UDP, не беспокоясь о том, доберутся ли они до места назначения или нет. Повторная передача пакетов не производится, если хост назначения не получает пакет UDP. В случае с VoIP - здесь важно, пакет приходит вовремя или нет. Если это не так, то нет смысла передавать его повторно, потому что уже слишком поздно. Слушатели уже ушли. LLQ может прийти вам в голову как ответ на эту проблему, но часть проблемы - это слишком большой буфер. Для обслуживания большого буфера потребуется время, вызывающее задержку доставки трафика VoIP, даже если LLQ обслуживает трафик VoIP. Было бы лучше отбросить VoIP-трафик, находящийся в очереди слишком долго, чем отправлять его с задержкой.
В случае большинства приложений трафик передается по протоколу TCP через IP, а не по протоколу UDP. TCP - протокол подтверждений. Отправитель трафика TCP ожидает, пока получатель подтвердит получение, прежде чем будет отправлен дополнительный трафик. В ситуации bufferbloat пакет находится в переполненном, слишком большом буфере перегруженного интерфейса в течение длительного времени, задерживая доставку пакета получателю. Получатель получает пакет и отправляет подтверждение. Подтверждение пришло к отправителю с большой задержкой, но все же пришло. TCP не заботится о том, сколько времени требуется для получения пакета, пока он туда попадает. И, таким образом, отправитель продолжает отправлять трафик с той же скоростью через перегруженный интерфейс, что сохраняет избыточный буфер заполненным и время задержки увеличивается. В крайних случаях отправитель может даже повторно передать пакет, пока исходный пакет все еще находится в буфере. Перегруженный интерфейс, наконец, отправляет исходный буферизованный пакет получателю, а вторая копия того же пакета теперь находится в движении, что создает еще большую нагрузку на уже перегруженный интерфейс!
Эти примеры демонстрируют, что буферы неподходящего размера на самом деле не годятся. Размер буфера должен соответствовать как скорости интерфейса, который он обслуживает, так и характеру трафика приложения, который может проходить через него.
Одна из попыток со стороны сетевой индустрии справиться с большими буферами, обнаруженными вдоль определенных сетевых путей, - это контролируемая задержка, или CoDel. CoDel предполагает наличие большого буфера, но управляет задержкой пакетов, отслеживая, как долго пакет находится в очереди. Это время известно, как время пребывания. Когда время пребывания пакета превысило вычисленный идеал, пакет отбрасывается. Это означает, что пакеты в начале очереди-те, которые ждали дольше всего-будут отброшены до пакетов, находящихся в данный момент в хвосте очереди.
Агрессивная позиция CoDel в отношении отбрасывания пакетов позволяет механизмам управления потоком TCP работать должным образом. Пакеты, доставляемые с большой задержкой, не доставляются, а отбрасываются до того, как задержка станет слишком большой. Отбрасывание вынуждает отправителя TCP повторно передать пакет и замедлить передачу, что очень желательно для перегруженного интерфейса. Совокупный результат - более равномерное распределение пропускной способности для потоков трафика, конкурирующих за интерфейс.
В ранних реализациях CoDel поставлялся в устройства потребительского уровня без параметров. Предполагаются определенные настройки по умолчанию для Интернета. Они включают 100 мс или меньше времени двустороннего обмена между отправителями и получателями, а задержка 5 мс является максимально допустимой для буферизованного пакета. Такая конфигурация без параметров упрощает деятельность поставщиков сетевого оборудования потребительского уровня. Потребительские сети являются важной целью для CoDel, поскольку несоответствие высокоскоростных домашних сетей и низкоскоростных широкополосных сетей вызывает естественную точку перегрузки. Кроме того, сетевое оборудование потребительского уровня часто страдает от слишком большого размера буферов.
В этой статье мы рассмотрим протокол маршрутизации Cisco EIGRP. EIGRP (Enhanced Interior Gateway Routing Protocol) - это протокол расширенной векторной маршрутизации, который должен устанавливать отношения соседства перед отправкой обновлений. Из-за этого первое, что нам нужно сделать, это проверить, правильно ли работает соседство. Если это так, мы можем продолжить, проверив, объявляются сети или нет. В этой статье рассмотрим все, что может пойти не так с EIGRP, как это исправить и в каком порядке. Давайте начнем с проверки соседства!
Существует ряд элементов, которые вызывают проблемы соседства EIGRP:
Неизвестная подсеть: соседи EIGRP с IP-адресами, которые не находятся в одной подсети.
Несоответствие значений K: по умолчанию пропускная способность и задержка включены для расчета метрики. Мы можем включить нагрузку и надежность, но мы должны сделать это на всех маршрутизаторах EIGRP.
Несоответствие AS: номер автономной системы должен совпадать на обоих маршрутизаторах EIGRP, чтобы сформировать соседство.
Проблемы уровня 2: EIGRP работает на уровне 3 модели OSI. Если уровни 1 и 2 не работают должным образом, у нас будут проблемы с формированием соседства.
Проблемы со списком доступа: возможно, кто-то создал список доступа, который отфильтровывает многоадресный трафик. EIGRP по умолчанию использует 224.0.0.10 для связи с другими соседями EIGRP.
NBMA: по умолчанию Non Broadcast Multi Access сети, такие как Frame Relay, не разрешают широковещательный или многоадресный трафик. Это может препятствовать тому, чтобы EIGRP формировал соседние отношения EIGRP.
OFF1(config)#int f0/0
OFF1(config-if)#ip address 192.168.12.1 255.255.255.0
OFF1(config-if)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF2(config)#int f0/0
OFF2(config-if)#ip address 192.168.21.2 255.255.255.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.21.0
Ошибку неверной подсети легко обнаружить. В приведенном выше примере у нас есть 2 маршрутизатора, и вы можете видеть, что были настроены разные подсети на каждом интерфейсе.
После включения EIGRP всплывают следующие ошибки:
Оба маршрутизатора жалуются, что находятся не в одной подсети.
OFF2(config-router)#int f0/0
OFF2(config-if)#ip address 192.168.12.2 255.25
OFF2(config)#router eigrp 12
OFF2(config-router)#no network 192.168.21.0
OFF2(config-router)#network 192.168.12.0
Мы изменили IP-адрес на OFF2 и убедились, что для EIGRP правильно настроена команда network.
Вуаля! Теперь у нас есть соседство EIGRP.
Проверим это с помощью команды show ip eigrp neighbors.
Извлеченный урок: убедитесь, что оба маршрутизатора находятся в одной подсети.
Case #2
На этот раз IP-адреса верны, но мы используем разные значения K с обеих сторон. OFF1 включил пропускную способность, задержку, нагрузку и надежность. OFF2 использует только пропускную способность и задержку.
Эту ошибку легко обнаружить, поскольку сообщение в консоли гласит "Несоответствие K-значений" на обоих маршрутизаторах.
Мы можем проверить нашу конфигурацию, посмотрев ее на обоих маршрутизаторах. Как вы видите, что значения K были изменены на OFF1.
OFF2(config)#router eigrp 12
OFF2(config-router)#metric weights 0 1 1 1 1 0
Давайте убедимся, что значения K одинаковы на обоих маршрутизаторах, так как мы изменили их на OFF2.
После изменения значений K у нас появилось соседство EIGRP-соседей.
Еще одна проблема решена!
Извлеченный урок: убедитесь, что значения K одинаковы на всех маршрутизаторах EIGRP в одной и той же автономной системе.
Case #3
Давайте продолжим со следующей ошибкой ...
Вот еще один пример типичной проблемы. Несоответствие номера AS. Когда мы настраиваем EIGRP, мы должны ввести номер AS. В отличие от OSPF (который использует ID процесса) этот номер должен быть одинаковым на обоих маршрутизаторах.
В отличие от других неверных настроек конфигурации EIGRP, эта проблема не выдает сообщение об ошибке. Используем команду show ip eigrp neighbors и видим, что соседей нет. Внимательно изучите выходные данные, чтобы обнаружить различия, и вы увидите, что маршрутизаторы используют разные номера AS.
Если посмотреть на работающую конфигурацию, и мы увидим то же самое.
Давайте изменим номер AS на OFF2.
После смены номера AS все заработало как положено.
Извлеченный урок: убедитесь, что номера AS одинаковые, если вы хотите соседства EIGRP.
Case #4
И последнее, но не менее важное: если вы проверили номер AS, значения K, IP-адреса и у вас все еще нет работающего соседства EIGRP, вам следует подумать о безопасности. Возможно, access-list блокирует EIGRP и/или многоадресный трафик.
Следующая ситуация: опять два маршрутизатора EIGRP и отсутствие соседства. Что здесь происходит?
Мы видим, что нет соседей ...
Если вы посмотрите на вывод команды show ip protocols, то увидите, что сеть была объявлена правильно. Если вы посмотрите внимательно на OFF2, вы увидите, что у нас есть пассивный интерфейс.
Удалим настройки пассивного интерфейса!
OFF2(config)#router eigrp 12
OFF2(config-router)#no passive-interface fastEthernet 0/0
Еще одна неправильная настройка создала нам проблемы, но мы ее решили.
Задача решена!
Извлеченный урок: не включайте пассивный интерфейс, если вы хотите установить соседство EIGRP.
Case #5
В приведенном выше примере у нас есть те же 2 маршрутизатора, но на этот раз кто-то решил, что было бы неплохо настроить список доступа на OFF2, который блокирует весь входящий многоадресный трафик.
Здесь можно запутаться. На OFF1 мы видим, что он считает, что установил соседство EIGRP с OFF2. Это происходит потому, что мы все еще получаем пакеты EIGRP от OFF2.
Используем команду debug eigrp neighbors, чтобы посмотреть, что происходит. Очевидно, что OFF1 не получает ответ от своих hello messages, holdtime истекает, и это отбрасывает установление соседства EIGRP.
Быстрый способ проверить подключение - отправить эхо-запрос по адресу многоадресной рассылки 224.0.0.10, который использует EIGRP. МЫ видим, что мы ответа нет от этого запроса. Рекомендуется проверить, есть ли в сети списки доступа.
Так, так! Мы нашли что-то ...
Этот список доступа блокирует весь многоадресный трафик. Давайте сделаем настройку, которая разрешит EIGRP.
OFF2(config)#ip access-list extended BLOCKMULTICAST
OFF2(config-ext-nacl)#5 permit ip any host 224.0.0.10
Мы создаем специальное правило, которое будет разрешать трафик EIGRP.
Как мы видим, что трафик EIGRP разрешен - это соответствует правилу, которое мы выше создали.
Оба маршрутизатора теперь показывают рабочее соседство EIGRP.
Эхо-запрос, который мы только что отправили, теперь работает.
Извлеченный урок: не блокируйте пакеты EIGRP!
Case #6
Рассмотрим очередную ситуацию, в которой нет соседства EIGRP. На картинке выше мы имеем сеть Frame Relay и один канал PVC между OFF1 и OFF2. Вот соответствующая конфигурация:
Оба маршрутизатора настроены для Frame Relay, а EIGRP настроен.
Видно, что нет соседей ... это не хорошо! Можем ли мы пропинговать другую сторону?
Пинг проходит, поэтому мы можем предположить, что PVC Frame Relay работает. EIGRP, однако, использует многоадресную передачу, а Frame Relay по умолчанию - NBMA. Можем ли мы пропинговать адрес многоадресной рассылки EIGRP 224.0.0.10?
Здесь нет ответа на наш вопрос, по крайней мере, теперь мы знаем, что unicast трафик работает, а multicast не работает. Frame Relay может быть настроен для point-to-point или point-to-multipoint соединения. Физический интерфейс всегда является интерфейсом frame-relay point-tomultipoint, и для него требуются frame-relay maps, давайте проверим это:
Мы видим, что оба маршрутизатора имеют DLCI-to-IP карты, поэтому они знают, как связаться друг с другом. Видим, что они используют ключевое слово "статический", а это говорит о том, что это сопоставление было кем-то настроено и не изучено с помощью Inverse ARP (в противном случае вы увидите "динамический"). Мы не видим ключевое слово "broadcast", которое требуется для пересылки широковещательного или многоадресного трафика. На данный момент у нас есть 2 варианта решения этой проблемы:
Настроить EIGRP для использования одноадресного трафика вместо многоадресного.
Проверить конфигурацию Frame Relay и убедится, что многоадресный трафик не перенаправляется.
Давайте сначала сделаем unicast настройку EIGRP:
OFF1(config)#router eigrp 12
OFF1(config-router)#neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#neighbor 192.168.12.1 serial 0/0
Нам нужна команда neighbor для конфигурации EIGRP. Как только вы введете эту команду и нажмете enter, вы увидите это:
Задача решена! Теперь давайте попробуем другое решение, где мы отправляем multicast трафик по PVC Frame Relay:
OFF1(config)#router eigrp 12
OFF1(config-router)#no neighbor 192.168.12.2 serial 0/0
OFF2(config)#router eigrp 12
OFF2(config-router)#no neighbor 192.168.12.1 serial 0/0
Если это не работает ... не исправляйте это... , но не в этот раз! Пришло время сбросить соседство EIGRP.
OFF1(config)#interface serial 0/0
OFF1(config-if)#frame-relay map ip 192.168.12.2 102 broadcast
OFF2(config)#interface serial 0/0
OFF2(config-if)#frame-relay map ip 192.168.12.1 201 broadcast
Broadcast - это ключевое волшебное слово здесь. Это разрешит широковещательный и многоадресный трафик.
После изменения конфигурации frame-relay map появляется соседство EIGRP! Это все, что нужно сделать.
Извлеченный урок: проверьте, поддерживает ли ваша сеть Frame Relay broadcast или нет. Настройте EIGRP для использования unicast передачи или измените конфигурацию Frame Relay для поддержки широковещательного трафика.
Продолжение цикла про поиск и устранение неисправностей протокола EIGRP можно почитать тут.
Исследователи кибербезопасности выявили новую уязвимость, которая может повлиять на устройства в миллиардах по всему миру, включая серверы, рабочие станции, настольные компьютеры, ноутбуки, системы Интернета вещей и многое другое, работающие на системах Windows и Linux.
Исследователи говорят, что BootHole - это своего рода уязвимость переполнения буфера, способная воздействовать на все версии загрузчика GRUB2. Он ведет себя аналогично тому, как он разобрал содержимое файла конфигурации. Этот процесс по-разному подписывается другими исполняемыми и системными файлами.
Следовательно, это создает почву киберпреступникам для разрушения механизма аппаратного доверия на корне.
Вследствие переполнения буфера злоумышленники могут выполнять произвольные коды в среде UEFI. Затем они могут запускать вредоносные программы, вносить изменения в ядро операционной системы напрямую, изменять загрузку или выполнять другие вредоносные действия.
Данная уязвимость представляет собой большой риск и называется BootHole или CVE-2020-10713. В настоящее время данной уязвимости подвержен загрузчике GRUB2. Если злоумышленникам удастся его использовать, это может позволить им обойти функцию "Безопасной загрузки". Кроме того, атакующие также могут получить незаметный и постоянный доступ к целевым системам.
Безопасная загрузка является одной из функций Унифицированного Расширяемого Интерфейса Встроенного ПО (UEFI). Люди используют его для загрузки определенных критически важных периферийных устройств, операционных систем и компонентов, обеспечивая при этом выполнение только криптографически подписанных кодов во время загрузки.
Согласно отчету исследователей Eclypsium, данная функция предназначена для предотвращения выполнения не доверенных кодов до загрузки ОС. Для этого он изменяет цепочку загрузки или отключает безопасную загрузку.
В Windows злоумышленники могут использовать BootHole, заменив уже установленные загрузчики по умолчанию слабой версией GRUB2, а затем установить вредоносную программу rootkit.
Последствия уязвимости BootHole
Уязвимость BootHole может вызвать серьезные проблемы из-за того, что она позволяет злоумышленникам выполнять свои вредоносные коды до загрузки ОС. Следовательно, системам безопасности становится трудно обнаруживать вредоносные программы или устранять их.
Другая причина, по которой BootHole может легко создавать ошибки в системах, заключается в том, что в среде выполнения UEFI отсутствует возможность случайного размещения адресного пространства (ASLR), предотвращение выполнения данных (DEP) или другие технологии предотвращения использования уязвимостей.
Установка обновлений не решает проблему
Эксперты Eclypsium недавно связались с производителями компьютеров и поставщиками ОС, чтобы помочь смягчить проблему. Выяснилось, что решение не так просто.
Установки исправлений и обновление загрузчиков GRUB2 недостаточно для устранения проблемы. Причина в том, что злоумышленники могут заменить существующий загрузчик устройства на более слабую версию.
Эксперты говорят, что для смягчения последствий потребуется вновь развернутые и подписанные загрузчики. Кроме того, скомпрометированные загрузчики должны быть убраны.
Корпорация Майкрософт признает эту проблему и сообщает, что она работает над тестированием совместимости и проверкой обновления Windows, которое может устранить эту уязвимость. Кроме того, он рекомендует пользователям обновлять исправления безопасности по мере их доступности в ближайшие недели.
Разработчики некоторых дистрибутивов Linux следуя их примеру также выпустили рекомендации, связанные с данной уязвимостью и готовящимися исправлениями.