По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Это продолжение статьи про пакетную коммутацию. Первая часть тут.
Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом.
Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 10 Гбит/с можно объединить в один канал 20 Гбит/с, тем самым удвоив потенциальную полосу пропускания между двумя узлами, как показано на рисунке 6. Слово «потенциал» было выбрано тщательно, поскольку агрегированные каналы на практике не масштабируются линейно.
Проблема, с которой сталкивается агрегация каналов, заключается в определении, какие пакеты должны быть отправлены по какому элементу связи. Интуитивно это может показаться не проблемой. В конце концов, казалось бы, имеет смысл использовать группу каналов связи в циклическом режиме. Первоначальный фрейм будет отправлен по первому элементу связки, второй фрейм - по второму элементу и так далее, в конечном итоге возвращаясь к первому элементу связки. Таким образом, канал должен использоваться идеально равномерно, а пропускная способность - линейно.
В реальной жизни существует очень мало подобных реализаций, в которых агрегированные каналы используются на такой циклической основе, как эта, потому что они рискуют доставить неупорядоченные пакеты. Предположим, что первый кадр Ethernet отправляется первому звену нисходящего канала, а второй кадр - второму элементу нисходящего канала сразу после него. По какой-то причине второй кадр попадает на другой конец раньше первого кадра. Пакеты, содержащиеся в этих кадрах, будут доставлены принимающим узлам в неупорядоченном порядке - пакет два перед пакетом один. Это проблема, потому что теперь на хост возлагается вычислительная нагрузка по переупорядочению пакетов, чтобы можно было правильно собрать всю дейтаграмму.
Поэтому большинство поставщиков реализуют хеширование потоков, чтобы гарантировать, что весь поток трафика использует один и тот же элемент пакета. Таким образом, нет никакого риска того, что хост получит пакеты не по порядку, так как они будут отправляться последовательно через один и тот же элемент канала.
Хеширование потока работает путем выполнения математической операции над двумя или более статическими компонентами потока, такими как MAC-адреса источника и получателя, IP-адреса источника и получателя, протокол управления передачей (TCP) или протокол дейтаграмм пользователя (UDP). номера портов для вычисления элемента связи, который будет использовать поток. Поскольку характеристики потока статичны, алгоритм хеширования приводит к идентичным вычислениям для каждого кадра или пакета в потоке трафика, гарантируя, что один и тот же канал будет использоваться в течение всего срока службы потока.
Хотя хеширование потока решает проблему неупорядоченных пакетов, оно создает новую проблему. Не все потоки имеют одинаковый размер. Некоторые потоки используют большую полосу пропускания, например те, которые используются для передачи файлов, резервного копирования или хранения. Их иногда называют «слоновьими потоками» (elephant flows). Другие потоки довольно малы, например, те, которые используются для загрузки веб-страницы или связи с использованием передачи голоса по IP. Их иногда называют «мышиными потоками» (mouse flows). Поскольку потоки имеют разные размеры, некоторые элементы связи могут работать на полную мощность, а другие - недостаточно.
Это несоответствие в использовании возвращает нас к вопросу о линейном масштабировании. Если бы фреймы были сбалансированы по нагрузке через агрегированный набор каналов совершенно равномерно, то добавление новых каналов в набор равномерно увеличило бы емкость. Однако алгоритмы хэширования в сочетании с непредсказуемым объемом потоков трафика означают, что связанные каналы не будут загружаться равномерно.
Задача сетевого администратора - понять тип трафика, проходящего через агрегированный канал, и выбрать доступный алгоритм хеширования, который приведет к наиболее равномерному распределению нагрузки. Например, некоторые соображения по этому поводу:
Обмениваются ли многие хосты в одном широковещательном домене друг с другом через агрегированный канал? Хеширование против MAC-адресов, найденных в заголовке кадра Ethernet, является возможным решением, потому что MAC-адреса будут разными.
Обменивается ли небольшое количество хостов с одним сервером через агрегированный канал? В этом сценарии может не хватить разнообразия MAC-адресов или IP-адресов. Вместо этого хеширование по номерам портов TCP или UDP может привести к наибольшему разнообразию и последующему распределению трафика по агрегированным ссылкам.
Протокол управления агрегацией каналов (LACP)
При объединении каналов связи необходимо учитывать сетевые устройства на обоих концах канала связи и проявлять особую осторожность, чтобы обеспечить формирование пакета каналов связи при сохранении топологии без петель. Наиболее распространенным способом решения этой проблемы является использование отраслевого стандарта Link Aggregation Control Protocol (LACP), кодифицированного как стандарт 802.3 ad института инженеров электротехники и электроники (IEEE).
На каналах, обозначенных сетевым администратором, LACP объявляет о своем намерении сформировать агрегированный канал с другой стороной. Другая сторона, также выполняющая LACP, принимает это объявление, если объявленные параметры действительны, и формирует канал. Как только группа каналов сформирована, агрегированный канал переводится в состояние пересылки. Затем операторы сети могут запросить LACP для получения информации о состоянии агрегированного канала и о состоянии его членов.
LACP также знает, когда элемент связки выходит из строя, так как управляющие пакеты больше не проходят через сбойный канал. Эта возможность полезна, так как позволяет процессу LACP уведомлять сетевую операционную систему о необходимости пересчета хэшей потока. Без LACP сетевой операционной системе может потребоваться больше времени, чтобы узнать о сбойном канале, что приведет к хешированию трафика к элементу связи, который больше не является допустимым путем.
Существуют и другие протоколы управления агрегацией каналов. В некоторых случаях также возможно создавать пакеты каналов вручную без защиты управляющего протокола. Однако LACP доминирует в качестве стандарта, используемого сетевыми поставщиками, а также ведущими операционными системами и поставщиками гипервизоров для агрегации каналов.
Multichassis Link Aggregation
Multichassis Link Aggregation (MLAG) - это функция, предлагаемая некоторыми сетевыми поставщиками, позволяющая одному агрегированной связке каналов охватывать два или более сетевых коммутатора. Чтобы облегчить это, специальный протокол управления поставщика будет работать между коммутаторами-членами MLAG, заставляя несколько сетевых коммутаторов действовать так, как если бы они были одним коммутатором, в отношении LACP, протокола связующего дерева (STP) и любых других протоколов.
Обычным обоснованием для MLAG является физическая избыточность, когда сетевому инженеру требуется более низкий уровень (например, Ethernet) смежности между сетевыми устройствами (вместо маршрутизируемого соединения), а также требуется, чтобы связка каналов оставалась включенной, если удаленная сторона канала выходит из строя. Распространение связки каналов между двумя или более коммутаторами позволяет выполнить это требование. Рисунок 7 демонстрирует это.
В то время как многие сети используют некоторые разновидности MLAG в производстве, другие уклоняются от этой технологии, по крайней мере частично, потому что MLAG является собственностью. Нет такой вещи, как multivendor MLAG. Тенденции к лучшему проектированию сети в сторону от широко рассредоточенных коммутируемых доменов, сценарий, который выигрывает у MLAG. Вместо этого при проектировании сети наблюдается тенденция к ограниченным коммутируемым доменам, взаимосвязанным посредством маршрутизации, что устраняет необходимость в технологиях MLAG.
Маршрутизированные параллельные каналы
Маршрутизируемые плоскости управления, называемые протоколами маршрутизации, иногда вычисляют набор нескольких путей через сеть с равными затратами. В случае маршрутизации несколько каналов с одинаковой стоимостью могут даже не подключать одну пару устройств; Рисунок 8 демонстрирует это.
На рисунке 8 есть три пути:
[A, B, D] общей стоимостью 10
[A, D] общей стоимостью 10
[A, C, D] общей стоимостью 10
Поскольку эти три пути имеют одинаковую стоимость, все они могут быть установлены в локальной таблице переадресации в точках A и D. Маршрутизатор A, например, может пересылать трафик по любому из этих трех каналов в направлении D. Когда маршрутизатор имеет несколько вариантов. чтобы добраться до того же пункта назначения, как он решает, какой физический путь выбрать?
Как и в случае с ECMP нижнего уровня, ответ - хеширование. Маршрутизированное хеширование ECMP может выполняться в различных областях. Общие поля для хеширования включают IP-адреса источника или назначения и номера портов источника или назначения. В результате хеширования выбирается согласованный путь на протяжении потока L3. Только в случае сбоя канала потребуется перестроить поток и выбрать новый канал пересылки.
Механизмы обработки пакетов
Шаги, связанные с маршрутизацией одного пакета, могут показаться очень простыми—найдите пункт назначения в таблице, создайте (или извлеките) перезапись заголовка MAC, перепишите заголовок MAC, а затем поместите пакет в правильную очередь для исходящего интерфейса. Как бы просто это ни было, все равно требуется время, чтобы обработать один пакет. На рисунке 9 показаны три различных пути, по которым пакет может быть коммутироваться в сетевом устройстве.
Рисунок 9 иллюстрирует три различных пути коммутации через устройство; это не единственные возможные пути коммутации, но они являются наиболее распространенными. Первый путь обрабатывает пакеты через программное приложение, работающее на универсальном процессоре (GPP), и состоит из трех этапов:
Пакет копируется с физического носителя в основную память
Физический сигнальный процессор, чип PHY, посылает сигнал на GPP (вероятно, но не обязательно, главный процессор в сетевом устройстве), называемый прерыванием.
Прерывание заставляет процессор останавливать другие задачи (вот почему это называется прерыванием) и запускать небольшой фрагмент кода, который будет планировать запуск другого процесса, приложения коммутации, для выполнения позже.
Когда приложение коммутации запустится, оно выполнит соответствующий поиск и внесет соответствующие изменения в пакет.
После коммутации пакета он копируется из основной памяти исходящим процессором. Такое переключение пакета через процесс часто называется коммутацией процесса (по понятным причинам) или иногда медленным путем. Независимо от того, насколько быстрым является GPP, для достижения полной линейной скорости коммутации на высокоскоростных интерфейсах требуется большая настройка - до такой степени, что это практически невозможно. Второй путь коммутации, показанный на рисунке 9, был разработан для более быстрой обработки пакетов:
Пакет копируется с физического носителя в основную память
Микросхема PHY прерывает GPP; код обработчика прерывания, а не вызов другого процесса, фактически обрабатывает пакет.
После коммутации пакета, пакет копируется из основной памяти в процесс вывода, как описано ниже. По понятным причинам этот процесс часто называют interrupt context switching; многие процессоры могут поддерживать коммутацию пакетов достаточно быстро, чтобы передавать пакеты между интерфейсами с низкой и средней скоростью в этом режиме. Сам код коммутации, конечно же, должен быть сильно оптимизирован, потому что коммутация пакета заставляет процессор прекращать выполнение любых других задач (например, обработки обновления протокола маршрутизации). Первоначально это называлось - и до сих пор иногда называется fast switching path. Для действительно высокоскоростных приложений процесс коммутации пакетов должен быть выгружен с главного процессора или любого типа GPP на специализированный процессор, предназначенный для конкретной задачи обработки пакетов. Иногда эти процессоры называются сетевыми процессорами (Network Processing Units -NPU), подобно тому, как процессор, предназначенный для обработки только графики, называется графическим процессором (Graphics Processing Unit-GPU). Эти специализированные процессоры являются подмножеством более широкого класса процессоров, называемых специализированными интегральными схемами (Application-Specific Integrated Circuits -ASIC), и инженеры часто просто называют их ASIC. Переключение пакета через ASIC показано как шаги с 7 по 9 на рисунке 9:
Пакет копируется с физического носителя в память ASIC
Микросхема PHY прерывает работу ASIC; ASIC обрабатывает прерывание путем переключения пакета.
После коммутации пакета пакет копируется из памяти ASIC в процесс вывода, как описано ниже.
Многие специализированные ASIC для обработки пакетов имеют ряд интересных функций, в том числе:
Структуры внутренней памяти (регистры) настроены специально для обработки различных типов адресов, используемых в сетях.
Специализированные наборы команд, предназначенные для выполнения различных требований к обработке пакетов, таких как проверка внутренних заголовков, переносимых в пакете, и перезапись заголовка MAC.
Специализированные структуры памяти и наборы инструкций, предназначенные для хранения и поиска адресов назначения для ускорения обработки пакетов
Возможность повторного использования пакета через конвейер пакетов для выполнения операций, которые не могут поддерживаться за один проход, таких как глубокая проверка пакетов или специализированные задачи фильтрации.
Мы продолжаем рассказывать про протокол DHCP (Dynamic Host Configuration Protocol) . Мы уже знаем про принципы работы протокола и про его настройку на оборудовании Cisco, и сегодня речь пойдет о том, как находить и исправлять проблемы (заниматься траблшутингом) при работе с DHCP.
Проблемы с DHCP могут возникать по множеству причин, таких как проблемы программного обеспечения, в операционных системах, драйверов сетевых карт или агентах ретрансляции, но наиболее распространенными являются проблемы с конфигурацией DHCP. Из-за большого числа потенциально проблемных областей требуется систематический подход к устранению неполадок.
Задача 1. Устранение конфликтов IP адресов
Срок действия адреса IPv4 может истекать у клиента, все еще подключенного к сети. Если клиент не возобновляет аренду, то сервер может переназначить этот IP-адрес другому клиенту. Когда клиент перезагружается, то он запрашивает адрес и если DHCP сервер не отвечает быстро, то клиент использует последний IP-адрес. Тогда возникает ситуация, когда два клиента используют один и тот же адрес, создавая конфликт.
Команда show ip dhcp conflict отображает все конфликты адресов, записанные сервером DHCP. Сервер использует команду ping для обнаружения клиентов. Для обнаружения конфликтов клиент использует протокол ARP. Если обнаружен конфликт адресов, адрес удаляется из пула и не назначается, пока администратор не разрешит конфликт.
Выгладит это так:
Router# show ip dhcp conflict
IP address Detection Method Detection time
192.168.1.33 Ping Feb 19 2018 10:33 AM
192.168.1.48 Gratuitous ARP Feb 19 2018 11:29 AM
В столбце IP address указывается конфликтный адрес, в строке Detection Method указывается метод обнаружения (Ping – адрес был обнаружен когда при назначении нового адреса получил положительный ответ на пинг, Gratuitous ARP – конфликт обнаружен в ARP таблице) и Detection time показывает время обнаружения.
Чтобы посмотреть список всех выданных адресов сервером используется команда show ip dhcp binding.
Задача 2. Проверка физического подключения
Сначала нужно проверить, что интерфейс маршрутизатора, действующий как шлюз по умолчанию для клиента, является работоспособным. Для этого используется команда show interface [интерфейс] , и если интерфейс находится в каком либо состоянии кроме как UP, то это означает что порт не передает трафик, включая запросы клиентов DHCP.
Задача 3. Проверка связности, используя статический IP адрес
При поиске проблем DHCP проверить общую работоспособность сети можно задав статический IP адрес у клиента. Если он может достичь сетевых ресурсов со статически настроенным адресом, то основной причиной проблемы является не DHCP.
Задача 4: Проверить конфигурацию порта коммутатора
Если DHCP клиент не может получить IP адрес с сервера, то можно попробовать получить адрес вручную, заставляя клиента отправить DHCP запрос.
Если между клиентом и сервером DHCP есть маршрутизатор и клиент не может получить адрес, то причиной могут быть настройки портов. Эти причины могут включать в себя проблемы, связанные с транками и каналами, STP и RSTP. Конфигурация PortFast и настройка пограничных портов разрешают наиболее распространенные проблемы клиента DHCP, возникающие при первоначальной установке коммутатора.
Задача 5: Проверка работы DHCP в одной и той же подсети или VLAN
Важно различать, правильно ли работает DHCP, когда клиент находится в одной подсети или VLAN, что и DHCP-сервер. Если DHCP работает правильно, когда клиент находится в одной подсети, то проблема может быть ретранслятором DHCP (relay agent). Если проблема сохраняется даже при тестировании в одной подсети, то проблема может быть с сервером DHCP.
Проверка конфигурации DHCP роутера
Когда сервер DHCP находится в отдельной локальной сети от клиента, интерфейс маршрутизатора, обращенный к клиенту, должен быть настроен для ретрансляции запросов DHCP путем настройки helper адреса.
Чтобы проверить конфигурацию маршрутизатора для начала нужно убедиться, что команда ip helper-address настроена на правильном интерфейсе. Она должна присутствовать на входящем интерфейсе локальной сети, содержащей DHCP клиентов, и должна быть направлена на правильный сервер DHCP. Для проверки используется команда show ip interface [интерфейс] . Далее нужно убедиться, что в глобальном режиме не была введена команда no service dhcp . Эта команда отключает все функции сервера DHCP и ретрансляции на маршрутизаторе. Для проверки используется команда show running-config | include no service dhcp. Если команда была введена, то она отобразится в выводе.
Дебаг DHCP
На маршрутизаторах, настроенных как DHCP-сервер, процесс DHCP не выполняется если маршрутизатор не получает запросы от клиента. В качестве задачи по траблшутингу нужно убедиться, что маршрутизатор получает запрос от клиента. Для этого дебага понадобится конфигурация ACL (Access Control List).
Нужно создать расширенный Access List, разрешающий только пакеты с UDP портами назначения 67 или 68. Это типичные порты, используемые клиентами и серверами при отправке сообщений DHCP. Расширенный ACL используется с командой debug ip packet для того чтобы отображать только сообщения DHCP.
Router(config)# access-list 100 permit udp any any eq 67
Router(config)# access-list 100 permit udp any any eq 68
Router(config)# end
Router# debug ip packet 100
IP packet debugging is on for access list 100
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, rcvd 2
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, stop process pak for forus packet
*IP: s-192.168.1.1(local), d-255.255.255.255 (GigabitEthernet1/1), len 328, sending broad/multicast
Результат в примере показывает, что маршрутизатор получает запросы DHCP от клиента. IP-адрес источника равен 0.0.0.0, поскольку клиент еще не имеет адреса, адрес назначения - 255.255.255.255, потому что сообщение об обнаружении DHCP от клиента отправляется в виде широковещательной передачи. Этот вывод показывает только сводку пакета, а не сообщение DHCP. Тем не менее, здесь видно, что маршрутизатор получил широковещательный пакет с исходными и целевыми IP-адресами и портами UDP, которые являются правильными для DHCP.
Другой полезной командой для поиска неполадок DHCP является команда событий debug ip dhcp server. Эта команда сообщает о событиях сервера, таких как назначения адресов и обновления баз.
Router(config)#debug ip dhcp server events
DHCPD: returned 192.168.1.11 to address pool POOL-1
DHCPD: assigned IP address 192.168.1.12 to client 0011:ab12:cd34
DHCPD: checking for expired leases
DHCPD: the lease for address 192.168.1.9 has expired
DHCPD: returned 192.168.1.9 to address pool POOL-1
SSH (Secure Shell) обеспечивает безопасное удаленное соединение между двумя системами. С помощью этого криптографического протокола вы можете управлять машинами, копировать или перемещать файлы на удаленном сервере через зашифрованные каналы.
Существует два способа входа в удаленную систему через SSH - с использованием аутентификации по паролю или аутентификации с открытым ключом (вход SSH без пароля).
В этом руководстве вы узнаете, как настроить и включить вход по SSH без пароля.
Подготовка
Нам необходимо:
Доступ к командной строке или окну терминала
Пользователь с привилегиями sudo или root
Локальный сервер и удаленный сервер
Доступ по SSH к удаленному серверу через командную строку или окно терминала
Перед тем как начать проверьте существующие ключи SSH. Возможно, на вашем компьютере уже есть пара ключей SSH. Чтобы узнать, есть ли у вас в системе ключи SSH, выполните команду:
ls -al ~/.ssh/id_*.pub
Если в выводе указано, что таких файлов нет, переходите к следующему шагу, который показывает, как сгенерировать ключи SSH. Если они у вас есть, вы можете использовать существующие ключи, сделать их резервную копию и создать новую пару или перезаписать ее.
Шаг 1. Создайте пару ключей SSH
1. Первое, что вам нужно сделать, это сгенерировать пару ключей SSH на машине, на которой вы сейчас работаете.
В этом примере мы генерируем 4096-битную пару ключей. Мы также добавляем адрес электронной почты, но это необязательно. Команда такая:
ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"
2. Затем введите место, где вы хотите сохранить ключи, или нажмите Enter, чтобы принять путь по умолчанию.
3. Также вам будет предложено установить кодовую фразу. Хотя это делает соединение еще более безопасным, оно может прерываться при настройке автоматизированных процессов. Поэтому вы можете ввести пароль или просто нажать Enter, чтобы пропустить этот шаг.
4. Затем в выводе сообщается, где хранятся идентификационный и открытый ключ, а также выдается отпечаток ключа.
5. Убедитесь, что вы успешно создали пару ключей SSH, выполнив команду:
ls -al ~/.ssh/id_*.pub
Вы должны увидеть путь идентификационного ключа и открытого ключа, как на скриншоте ниже:
Шаг 2. Загрузите открытый ключ на удаленный сервер
Вы можете загрузить публичный SSH-ключ на удаленный сервер с помощью команды ssh-copy-id или команды cat.
Вариант 1. Загрузить открытый ключ с помощью команды ssh-copy-id
Чтобы включить беспарольный доступ, вам необходимо загрузить копию открытого ключа на удаленный сервер.
1. Подключитесь к удаленному серверу и используйте команду ssh-copy-id:
ssh-copy-ide [remote_username]@[server_ip_address]
2. Открытый ключ автоматически копируется в файл .ssh/authorized_keys.
Вариант 2: загрузить открытый ключ с помощью команды cat
Другой способ скопировать открытый ключ на сервер - использовать команду cat.
1. Начните с подключения к серверу и создания на нем каталога .ssh.
ssh [remote_username]@[server_ip_address] mkdir -p .ssh
2. Затем введите пароль для удаленного пользователя.
3. Теперь вы можете загрузить открытый ключ с локальной машины на удаленный сервер. Команда также указывает, что ключ будет храниться под именем authorized_keys во вновь созданном каталоге .ssh:
cat .ssh/id_rsa.pub | ssh [remote_username]@[server_ip_address] 'cat >> .ssh/authorized_keys'
Шаг 3. Войдите на сервер без пароля
После создания пары ключей SSH и загрузки открытого ключа на удаленный сервер вы должны иметь возможность подключаться к выделенному серверу без ввода пароля.
Проверьте, работает ли установка, выполнив команду:
ssh [remote_username]@[server_ip_address]
Система должна напрямую входить в систему на удаленном сервере, пароль не требуется.
Примечание: убедившись, что вы можете подключаться к удаленному серверу SSH без пароля, рассмотрите возможность полного отключения аутентификации по паролю SSH. Это добавит еще один уровень безопасности и защитит ваш сервер от bruteforce атак.
Дополнительно: Устранение неполадок с разрешениями файлов удаленного сервера
Права доступа к файлам на удаленном сервере могут вызвать проблемы с входом в SSH без пароля. Это обычная проблема со старыми версиями SSH.
Если после выполнения всех шагов вам все еще предлагается ввести пароль, начните с редактирования прав доступа к файлам на удаленном сервере.
Установите разрешения 700 для каталога .ssh.
Установите разрешения 640 для каталога .ssh/authorized_keys.
Отредактируйте права доступа к файлу с помощью следующей команды:
ssh [remote_username]@[server_ip_address] "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"
При появлении запроса введите свой пароль. Если действие было успешным, вывода не будет.
Итог
Если вы хотите автоматизировать обновления и другие задачи или беспрепятственно подключаться к удаленному серверу по SSH, вам следует включить вход по SSH без пароля.
Инструкции в этой статье должны помочь вам в этом.