По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Это продолжение статьи про пакетную коммутацию. Первая часть тут. Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом. Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 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. Специализированные структуры памяти и наборы инструкций, предназначенные для хранения и поиска адресов назначения для ускорения обработки пакетов Возможность повторного использования пакета через конвейер пакетов для выполнения операций, которые не могут поддерживаться за один проход, таких как глубокая проверка пакетов или специализированные задачи фильтрации.
img
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке. Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP! Урок 1 В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит? Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию. Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес. Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3. Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4. Увы ...пинг не проходит. Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом. Ну вот...интерфейс отключен. R3(config)#interface fastEthernet 1/0 R3(config-if)#no shutdown Включим его! Ну вот, теперь он работает. Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление? interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP. R2(config)#interface fastEthernet 0/0 R2(config-if)#standby 1 preempt R3(config)#interface fastEthernet 0/0 R3(config-if)#standby 1 preempt Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово! Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking Урок 2 Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4. Некоторые из IP-пакетов не поступают в 4.4.4.4. IP-адрес шлюза: 192.168.123.254. Шлюз пингуется без проблем. R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным. Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию: R2(config)#interface fa0/0 R2(config-if)#vrrp 1 authentication md5 key-string SECRET Мы сделаем key-string одинаковыми. Это сообщение в консоли R2 является многообещающим. R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена. Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0. Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все! R2(config)#interface fastEthernet 1/0 R2(config-if)#no shutdown Включим интерфейс! Проблема устранена! Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
img
232 или 4 294 967 296 IPv4 адресов это много? Кажется, что да. Однако с распространением персональных вычислений, мобильных устройств и быстрым ростом интернета вскоре стало очевидно, что 4,3 миллиарда адресов IPv4 будет недостаточно. Долгосрочным решением было IPv6, но требовались более быстрое решение для устранения нехватки адресов. И этим решением стал NAT (Network Address Translation). Что такое NAT Сети обычно проектируются с использованием частных IP адресов. Это адреса 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Эти частные адреса используются внутри организации или площадки, чтобы позволить устройствам общаться локально, и они не маршрутизируются в интернете. Чтобы позволить устройству с приватным IPv4-адресом обращаться к устройствам и ресурсам за пределами локальной сети, приватный адрес сначала должен быть переведен на общедоступный публичный адрес. И вот как раз NAT переводит приватные адреса, в общедоступные. Это позволяет устройству с частным адресом IPv4 обращаться к ресурсам за пределами его частной сети. NAT в сочетании с частными адресами IPv4 оказался полезным методом сохранения общедоступных IPv4-адресов. Один общедоступный IPv4-адрес может быть использован сотнями, даже тысячами устройств, каждый из которых имеет частный IPv4-адрес. NAT имеет дополнительное преимущество, заключающееся в добавлении степени конфиденциальности и безопасности в сеть, поскольку он скрывает внутренние IPv4-адреса из внешних сетей. Маршрутизаторы с поддержкой NAT могут быть настроены с одним или несколькими действительными общедоступными IPv4-адресами. Эти общедоступные адреса называются пулом NAT. Когда устройство из внутренней сети отправляет трафик из сети наружу, то маршрутизатор с поддержкой NAT переводит внутренний IPv4-адрес устройства на общедоступный адрес из пула NAT. Для внешних устройств весь трафик, входящий и выходящий из сети, выглядит имеющим общедоступный IPv4 адрес. Маршрутизатор NAT обычно работает на границе Stub-сети. Stub-сеть – это тупиковая сеть, которая имеет одно соединение с соседней сетью, один вход и выход из сети. Когда устройство внутри Stub-сети хочет связываться с устройством за пределами своей сети, пакет пересылается пограничному маршрутизатору, и он выполняет NAT-процесс, переводя внутренний частный адрес устройства на публичный, внешний, маршрутизируемый адрес. Терминология NAT В терминологии NAT внутренняя сеть представляет собой набор сетей, подлежащих переводу. Внешняя сеть относится ко всем другим сетям. При использовании NAT, адреса IPv4 имеют разные обозначения, основанные на том, находятся ли они в частной сети или в общедоступной сети (в интернете), и является ли трафик входящим или исходящим. NAT включает в себя четыре типа адресов: Внутренний локальный адрес (Inside local address); Внутренний глобальный адрес (Inside global address); Внешний местный адрес (Outside local address); Внешний глобальный адрес (Outside global address); При определении того, какой тип адреса используется, важно помнить, что терминология NAT всегда применяется с точки зрения устройства с транслированным адресом: Внутренний адрес (Inside address) - адрес устройства, которое транслируется NAT; Внешний адрес (Outside address) - адрес устройства назначения; Локальный адрес (Local address) - это любой адрес, который отображается во внутренней части сети; Глобальный адрес (Global address) - это любой адрес, который отображается во внешней части сети; Рассмотрим это на примере схемы. На рисунке ПК имеет внутренний локальный (Inside local) адрес 192.168.1.5 и с его точки зрения веб-сервер имеет внешний (outside) адрес 208.141.17.4. Когда с ПК отправляются пакеты на глобальный адрес веб-сервера, внутренний локальный (Inside local) адрес ПК транслируется в 208.141.16.5 (inside global). Адрес внешнего устройства обычно не переводится, поскольку он является общедоступным адресом IPv4. Стоит заметить, что ПК имеет разные локальные и глобальные адреса, тогда как веб-сервер имеет одинаковый публичный IP адрес. С его точки зрения трафик, исходящий из ПК поступает с внутреннего глобального адреса 208.141.16.5. Маршрутизатор с NAT является точкой демаркации между внутренней и внешней сетями и между локальными и глобальными адресами. Термины, inside и outside, объединены с терминами local и global, чтобы ссылаться на конкретные адреса. На рисунке маршрутизатор настроен на предоставление NAT и имеет пул общедоступных адресов для назначения внутренним хостам. На рисунке показано как трафик отправляется с внутреннего ПК на внешний веб-сервер, через маршрутизатор с поддержкой NAT, и высылается и переводится в обратную сторону. Внутренний локальный адрес (Inside local address) - адрес источника, видимый из внутренней сети. На рисунке адрес 192.168.1.5 присвоен ПК – это и есть его внутренний локальный адрес. Внутренний глобальный адрес (Inside global address) - адрес источника, видимый из внешней сети. На рисунке, когда трафик с ПК отправляется на веб-сервер по адресу 208.141.17.4, маршрутизатор переводит внутренний локальный адрес (Inside local address) на внутренний глобальный адрес (Inside global address). В этом случае роутер изменяет адрес источника IPv4 с 192.168.1.5 на 208.141.16.5. Внешний глобальный адрес (Outside global address) - адрес адресата, видимый из внешней сети. Это глобально маршрутизируемый IPv4-адрес, назначенный хосту в Интернете. На схеме веб-сервер доступен по адресу 208.141.17.4. Чаще всего внешние локальные и внешние глобальные адреса одинаковы. Внешний локальный адрес (Outside local address) - адрес получателя, видимый из внутренней сети. В этом примере ПК отправляет трафик на веб-сервер по адресу 208.141.17.4 Рассмотрим весь путь прохождения пакета. ПК с адресом 192.168.1.5 пытается установить связь с веб-сервером 208.141.17.4. Когда пакет прибывает в маршрутизатор с поддержкой NAT, он считывает IPv4 адрес назначения пакета, чтобы определить, соответствует ли пакет критериям, указанным для перевода. В этом пример исходный адрес соответствует критериям и переводится с 192.168.1.5 (Inside local address) на 208.141.16.5. (Inside global address). Роутер добавляет это сопоставление локального в глобальный адрес в таблицу NAT и отправляет пакет с переведенным адресом источника в пункт назначения. Веб-сервер отвечает пакетом, адресованным внутреннему глобальному адресу ПК (208.141.16.5). Роутер получает пакет с адресом назначения 208.141.16.5 и проверяет таблицу NAT, в которой находит запись для этого сопоставления. Он использует эту информацию и переводит обратно внутренний глобальный адрес (208.141.16.5) на внутренний локальный адрес (192.168.1.5), и пакет перенаправляется в сторону ПК. Типы NAT Существует три типа трансляции NAT: Статическая адресная трансляция (Static NAT) - сопоставление адресов один к одному между локальными и глобальными адресами; Динамическая адресная трансляция (Dynamic NAT) - сопоставление адресов “многие ко многим” между локальными и глобальными адресами; Port Address Translation (PAT) - многоадресное сопоставление адресов между локальными и глобальными адресами c использованием портов. Также этот метод известен как NAT Overload; Static NAT Статический NAT использует сопоставление локальных и глобальных адресов один к одному. Эти сопоставления настраиваются администратором сети и остаются постоянными. Когда устройства отправляют трафик в Интернет, их внутренние локальные адреса переводятся в настроенные внутренние глобальные адреса. Для внешних сетей эти устройства имеют общедоступные IPv4-адреса. Статический NAT особенно полезен для веб-серверов или устройств, которые должны иметь согласованный адрес, доступный из Интернета, как например веб-сервер компании. Статический NAT требует наличия достаточного количества общедоступных адресов для удовлетворения общего количества одновременных сеансов пользователя. Статическая NAT таблица выглядит так: Dynamic NAT Динамический NAT использует пул публичных адресов и назначает их по принципу «первым пришел, первым обслужен». Когда внутреннее устройство запрашивает доступ к внешней сети, динамический NAT назначает доступный общедоступный IPv4-адрес из пула. Подобно статическому NAT, динамический NAT требует наличия достаточного количества общедоступных адресов для удовлетворения общего количества одновременных сеансов пользователя. Динамическая NAT таблица выглядит так: Port Address Translation (PAT) PAT транслирует несколько частных адресов на один или несколько общедоступных адресов. Это то, что делают большинство домашних маршрутизаторов. Интернет-провайдер назначает один адрес маршрутизатору, но несколько членов семьи могут одновременно получать доступ к Интернету. Это наиболее распространенная форма NAT. С помощью PAT несколько адресов могут быть сопоставлены с одним или несколькими адресами, поскольку каждый частный адрес также отслеживается номером порта. Когда устройство инициирует сеанс TCP/IP, оно генерирует значение порта источника TCP или UDP для уникальной идентификации сеанса. Когда NAT-маршрутизатор получает пакет от клиента, он использует номер своего исходного порта, чтобы однозначно идентифицировать конкретный перевод NAT. PAT гарантирует, что устройства используют разный номер порта TCP для каждого сеанса. Когда ответ возвращается с сервера, номер порта источника, который становится номером порта назначения в обратном пути, определяет, какое устройство маршрутизатор перенаправляет пакеты. Картинка иллюстрирует процесс PAT. PAT добавляет уникальные номера портов источника во внутренний глобальный адрес, чтобы различать переводы. Поскольку маршрутизатор обрабатывает каждый пакет, он использует номер порта (1331 и 1555, в этом примере), чтобы идентифицировать устройство, с которого выслан пакет. Адрес источника (Source Address) - это внутренний локальный адрес с добавленным номером порта, назначенным TCP/IP. Адрес назначения (Destination Address) - это внешний локальный адрес с добавленным номером служебного порта. В этом примере порт службы 80: HTTP. Для исходного адреса маршрутизатор переводит внутренний локальный адрес во внутренний глобальный адрес с добавленным номером порта. Адрес назначения не изменяется, но теперь он называется внешним глобальным IP-адресом. Когда веб-сервер отвечает, путь обратный. В этом примере номера портов клиента 1331 и 1555 не изменялись на маршрутизаторе с NAT. Это не очень вероятный сценарий, потому что есть хорошая вероятность того, что эти номера портов уже были прикреплены к другим активным сеансам. PAT пытается сохранить исходный порт источника. Однако, если исходный порт источника уже используется, PAT назначает первый доступный номер порта, начиная с начала соответствующей группы портов 0-511, 512-1023 или 1024-65535. Когда портов больше нет, и в пуле адресов имеется более одного внешнего адреса, PAT переходит на следующий адрес, чтобы попытаться выделить исходный порт источника. Этот процесс продолжается до тех пор, пока не будет доступных портов или внешних IP-адресов. То есть если другой хост может выбрать тот же номер порта 1444. Это приемлемо для внутреннего адреса, потому что хосты имеют уникальные частные IP-адреса. Однако на маршрутизаторе NAT номера портов должны быть изменены - в противном случае пакеты из двух разных хостов выйдут из него с тем же адресом источника. Поэтому PAT назначает следующий доступный порт (1445) на второй адрес хоста. Подведем итоги в сравнении NAT и PAT. Как видно из таблиц, NAT переводит IPv4-адреса на основе 1:1 между частными адресами IPv4 и общедоступными IPv4-адресами. Однако PAT изменяет как сам адрес, так и номер порта. NAT перенаправляет входящие пакеты на их внутренний адрес, ориентируясь на входящий IP адрес источника, заданный хостом в общедоступной сети, а с PAT обычно имеется только один или очень мало публично открытых IPv4-адресов, и входящие пакеты перенаправляются, ориентируясь на NAT таблицу маршрутизатора. А что относительно пакетов IPv4, содержащих данные, отличные от TCP или UDP? Эти пакеты не содержат номер порта уровня 4. PAT переводит наиболее распространенные протоколы, переносимые IPv4, которые не используют TCP или UDP в качестве протокола транспортного уровня. Наиболее распространенными из них являются ICMPv4. Каждый из этих типов протоколов по-разному обрабатывается PAT. Например, сообщения запроса ICMPv4, эхо-запросы и ответы включают идентификатор запроса Query ID. ICMPv4 использует Query ID. для идентификации эхо-запроса с соответствующим ответом. Идентификатор запроса увеличивается с каждым отправленным эхо-запросом. PAT использует идентификатор запроса вместо номера порта уровня 4. Преимущества и недостатки NAT NAT предоставляет множество преимуществ, в том числе: NAT сохраняет зарегистрированную схему адресации, разрешая приватизацию интрасетей. При PAT внутренние хосты могут совместно использовать один общедоступный IPv4-адрес для всех внешних коммуникаций. В этом типе конфигурации требуется очень мало внешних адресов для поддержки многих внутренних хостов; NAT повышает гибкость соединений с общедоступной сетью. Многочисленные пулы, пулы резервного копирования и пулы балансировки нагрузки могут быть реализованы для обеспечения надежных общедоступных сетевых подключений; NAT обеспечивает согласованность для внутренних схем адресации сети. В сети, не использующей частные IPv4-адреса и NAT, изменение общей схемы адресов IPv4 требует переадресации всех хостов в существующей сети. Стоимость переадресации хостов может быть значительной. NAT позволяет существующей частной адресной схеме IPv4 оставаться, позволяя легко изменять новую схему общедоступной адресации. Это означает, что организация может менять провайдеров и не нужно менять ни одного из своих внутренних клиентов; NAT обеспечивает сетевую безопасность. Поскольку частные сети не рекламируют свои адреса или внутреннюю топологию, они остаются достаточно надежными при использовании в сочетании с NAT для получения контролируемого внешнего доступа. Однако нужно понимать, что NAT не заменяет фаерволы; Но у NAT есть некоторые недостатки. Тот факт, что хосты в Интернете, по-видимому, напрямую взаимодействуют с устройством с поддержкой NAT, а не с фактическим хостом внутри частной сети, создает ряд проблем: Один из недостатков использования NAT связан с производительностью сети, особенно для протоколов реального времени, таких как VoIP. NAT увеличивает задержки переключения, потому что перевод каждого адреса IPv4 в заголовках пакетов требует времени; Другим недостатком использования NAT является то, что сквозная адресация теряется. Многие интернет-протоколы и приложения зависят от сквозной адресации от источника до места назначения. Некоторые приложения не работают с NAT. Приложения, которые используют физические адреса, а не квалифицированное доменное имя, не доходят до адресатов, которые транслируются через NAT-маршрутизатор. Иногда эту проблему можно избежать, реализуя статические сопоставления NAT; Также теряется сквозная трассировка IPv4. Сложнее трассировать пакеты, которые подвергаются многочисленным изменениям адресов пакетов в течение нескольких NAT-переходов, что затрудняет поиск и устранение неполадок; Использование NAT также затрудняет протоколы туннелирования, такие как IPsec, поскольку NAT изменяет значения в заголовках, которые мешают проверкам целостности, выполняемым IPsec и другими протоколами туннелирования; Службы, требующие инициирования TCP-соединений из внешней сети, или stateless протоколы, например, использующие UDP, могут быть нарушены. Если маршрутизатор NAT не настроен для поддержки таких протоколов, входящие пакеты не могут достичь своего адресата; Мы разобрали основные принципы работы NAT. Хотите больше? Прочитайте нашу статью по настройке NAT на оборудовании Cisco.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59