Какая функция маршрутизатора Cisco позволяет перенаправлять трафик без определенного маршрута

Обновлено: 21.11.2024

Маршрутизация на основе политик (PBR) – очень популярная функция маршрутизаторов Cisco. Она позволяет создавать политики, которые могут выборочно изменять путь, по которому проходят пакеты в сети. Маршрутизацию на основе политик можно использовать для маркировки пакетов, чтобы определенные типы трафика имели приоритет над остальными, отправлялись в другое место назначения или существовали через другой физический интерфейс на маршрутизаторе.

Классификация интересующего трафика выполняется с помощью списков контроля доступа (ACL). Это могут быть стандартные, расширенные или именованные списки доступа, какими мы их знаем.

После того, как интересующий трафик будет «сопоставлен» с использованием списков ACL, маршрутизатор выполнит настроенную функцию «установки», которая определяется администратором. Эта функция «установить», по сути, сообщает маршрутизатору, что делать с согласованным трафиком, и может включать его отправку на другой шлюз, отбрасывание, определение приоритета над другим трафиком и многое другое.

Маршрутизация на основе политик с мониторингом IP SLA для автоматического аварийного переключения

При таких настройках пользователи сети не знают о существовании прокси-сервера, поскольку им не требуется настраивать свой веб-браузер для использования прокси-сервера. Весь пользовательский трафик направляется на один шлюз (Cisco ASA Firewall), а оттуда на маршрутизатор R1. Этот пример является хорошим решением для создания прозрачного прокси-сервера с автоматическим переходом на другой ресурс.

Прокси-сервер Linux принимает трафик, выполняет необходимые проверки, определенные администратором, и перенаправляет его в Интернет через маршрутизатор R2.

На следующей диаграмме показано, как маршрутизатор R1 будет реагировать на сбой прокси-сервера Linux, как описано выше:

Примечание. Дополнительные примеры отслеживания IP SLA можно найти в нашей статье «Настройка статического отслеживания маршрутов с использованием IP SLA (базовая)».

Как настроить отслеживание IP SLA для хоста

Приведенная выше конфигурация определяет и запускает проверку IP SLA на маршрутизаторе R1.

Проверка ICMP Echo отправляет пакет ICMP Echo (ping) на IP 192.168.150.2 каждые 4 секунды, как определено параметром частоты.

Тайм-аут устанавливает количество времени (в миллисекундах), в течение которого операция Cisco IOS IP SLA ожидает ответа от своего пакета запроса. Установлено значение 2000 миллисекунд, или 2 секунды, что дает хосту достаточно времени для ответа.

Порог задает возрастающий порог, при котором генерируется событие реакции и сохраняется информация об истории операций Cisco IOS IP SLA.

После определения операции IP SLA нашим следующим шагом будет определение объекта, который отслеживает проверку SLA. Этого можно добиться с помощью объекта Track IOS, как показано ниже:

Приведенная выше команда будет отслеживать состояние операции IP SLA. Если от отслеживаемого IP-адреса (192.168.150.2) нет ответов на проверку связи, отслеживание отключится и возобновится, когда операция IP SLA снова начнет получать ответы на проверку связи.

Чтобы проверить статус трека, используйте команду «показать трек», как показано ниже:

Вывод команды подтверждает, что отслеживаемый объект находится в состоянии UP и имеет время отклика 1 мс. При ближайшем рассмотрении видно, что за время отслеживания состояние менялось 30 раз, а последнее изменение было 1 день 8 часов назад. Эта информация чрезвычайно важна, если она необходима для устранения периодически возникающих проблем, о которых могут сообщать пользователи.

Во-первых, нам нужно использовать списки контроля доступа, чтобы выбрать трафик, который мы хотим перенаправить. Имейте в виду, что PBR не ограничивает тип используемого ACL. Это означает, что вы можете использовать списки управления доступом с IP-адресами, стандартные списки управления доступом, расширенные списки управления доступом, списки управления доступом на основе времени и другие. В нашем примере мы собираемся использовать списки управления доступом с IP-адресами:

Теперь мы должны создать карту маршрутов, которая будет использовать указанные выше списки управления доступом, и указать маршрутизатору перенаправлять трафик на прокси-сервер Linux:

Приведенная выше команда создает разрешающую карту маршрутов с именем linux-proxy. Параметр match IP address в карте маршрутов информирует маршрутизатор о том, какой набор ACL определяет интересующий нас трафик. Поскольку мы определили интересующий нас трафик с помощью IP-именованных ACL, все, что нам нужно сделать, это сослаться на имя нашего ACL. ранее созданный.

Последняя команда настраивает карту маршрутов для проверки доступности отслеживаемого объекта (192.168.150.2). Если отслеживаемый объект доступен (IP SLA сообщает, что он доступен), то наш маршрут на основе политики перенаправит на него определенный трафик. Если отслеживаемый объект недоступен (соглашение об уровне обслуживания IP сообщает, что хост недоступен — недоступен), то наш маршрут на основе политики прекратит перенаправление трафика.

Применение маршрута на основе политик

Мы почти закончили. Самый последний шаг — включить и определить карту маршрутов, которая будет использоваться для маршрутизации политики. Это выполняется путем выбора интерфейса маршрутизатора, для которого будет включена политика маршрутизации, и применения политики-маршрута:


В нашем сценарии интерфейс VLAN1 маршрутизатора R1 подключен к сети 192.168.150.0/24, в которой находятся наши прокси-серверы ASA и Linux, поэтому мы применяем к ней политику маршрутизации.

Карта маршрутов и статистика IP SLA

Внимательно следить за картой маршрутов маршрутизатора и производительностью IP SLA можно с помощью нескольких простых команд. Мониторинг производительности вашей карты маршрутов в первые пару дней – очень хорошая идея, так как это поможет убедиться, что трафик по-прежнему перенаправляется на хост.

С другой стороны, просмотр статистики IP SLA поможет выявить возможные сбои или изменения состояния, которые никто не заметил.

Предпочтительнее использовать команду show route-map, поскольку она объединяет достаточно информации, чтобы убедиться, что все работает должным образом:

Числа, показанные здесь, немедленно подтверждают, что наш хост доступен (работает) и что маршрутизатор R1 перенаправил более 510 МБ трафика через прокси-сервер Linux!

Команда show IP SLAstatistics аналогичным образом предоставляет полезную информацию, которая помогает убедиться, что отслеживание объектов работает правильно и отслеживаемый хост работает:

Идентификатор операции IPSLA: 1
Последний RTT: 1 миллисекунда
Время начала последней операции: *21:36:47.855 UTC, вторник, 3 апреля 2012 г.
Код возврата последней операции: OK
>Количество успехов: 16
Количество неудач: 0
Время работы до жизни: Навсегда

Маршрутизация на основе политик (PBR) предоставляет сетевым администраторам гибкость и гибкость для более эффективного управления трафиком. С помощью тщательно разработанных политик вы можете оптимизировать то, как сегменты вашей сети обрабатывают данные, а также как управлять пропускной способностью для критически важных бизнес-приложений.

Что мы рассматриваем в этой статье:

• Что такое маршрутизация на основе политик, начиная с базового введения в маршрутизацию
• Как работает маршрутизация на основе политик
• Как можно использовать маршрутизацию на основе политик
• Некоторые примеры маршрутизация на основе политик

Улучшите свои знания в области сетей и пройдите наш курс «Основы работы с сетями» сегодня.

Что такое маршрутизация?

Маршрутизация – это процесс обнаружения сетей назначения, их объявления, определения наилучшего пути для трафика и сохранения этой информации.

Маршрутизация — это не процесс перемещения данных через маршрутизатор. Это называется коммутацией внутри маршрутизатора, которую не следует путать с коммутатором.

В современном понимании коммутатор – это аппаратное или программное устройство, которое перенаправляет трафик. Обычно это основано на адресации уровня 2, но также может выполняться в многоуровневой структуре.

С другой стороны, маршрутизация обычно происходит на уровне 3.

В зависимости от протокола уровня 3 доступны разные протоколы маршрутизации. Протокол с адресацией на уровне 3 называется маршрутизируемым протоколом. Важно понимать, что протоколы маршрутизации не пропускают пользовательский трафик, они передают информацию о сетях назначения.

Независимо от типа протокола все они делают одно и то же: рекламируют сети, создают локальную таблицу определенного типа, выбирают лучший путь, пытаются внести свой вклад в таблицу маршрутизации, также известную как информационная база маршрутизации (RIB). — а затем должны поддерживать эту информацию, чтобы гарантировать, что она по-прежнему актуальна.

В этих протоколах можно реализовать политику, но это не маршрутизация на основе политик (PBR). Политика в рамках перечисленных динамических протоколов будет фильтровать или управлять тем, как вы используете информацию.

При статической маршрутизации тот, кто настроил статическую маршрутизацию, управляет протоколом маршрутизации. Это определяет путь к заданной сети назначения или хосту. PBR отличается тем, что дает вам больше контроля — в дополнение к месту назначения — для процесса пересылки трафика.

Что такое PBR?

PBR — это процесс использования карты маршрутов для указания атрибута, отличного от пункта назначения, и последующего определения пути от маршрутизатора на основе этих условий.

С помощью PBR сетевой администратор может выбирать политики в соответствии с определенными параметрами, такими как:

• IP-адрес источника или получателя
• Порт источника или получателя
• Тип трафика
• Сетевые протоколы
• Объемы данных пакеты
• Список доступа

После установки таких параметров пакеты данных маршрутизируются соответствующим образом. Это позволяет повысить гибкость сети.

Поскольку вы можете определить свою стратегию маршрутизации, используя атрибуты приложений, вы можете выполнять определенные политики управления трафиком, которые контролируют пересылку пакетов.

Таким образом, вы можете оптимизировать использование полосы пропускания наиболее важными приложениями.

Как работает PBR?

PBR считается исключением из базы информации о маршрутизации (RIB) и рассматривается перед проверкой RIB. Это позволяет использовать больше вариантов маршрутизации.

Например, в карте маршрутов, используемой для PBR, вы можете сопоставить список управления доступом (ACL), который затем сопоставляется по источнику, месту назначения, типу протокола и/или номерам портов.

Вы также можете сопоставлять:

• Маркировка качества обслуживания (QoS), например приоритет интернет-протокола (IP) или кодовая точка дифференцированного обслуживания (DSCP)
• Размер пакетов, позволяющий эффективно отправлять данные в нужное место. идти в зависимости от того, насколько велики или малы его пакеты

После положительного совпадения вы можете установить адрес устройства следующего перехода и/или исходящий интерфейс. Вы также можете одновременно установить значения QoS, которые позволят вам гарантировать, что приложение получит ресурсы, необходимые для его работы, так, как вам нужно.

Карта маршрутов может содержать несколько операторов, которые обычно следуют с шагом 10. Это дает вам возможность управлять сопоставлением нескольких наборов условий совпадения.

Карта маршрутов также может содержать операторы «запретить». (По умолчанию, если не указано, это «разрешить».) Их также можно использовать в качестве фильтра. Когда карта маршрутов совпадает в ACL, если она соответствует запрету, она исключается из этого оператора карты маршрутов и переходит к следующему оператору в карте. Отказ или удаление определяется картой маршрутов, а не ACL, на который ссылается карта маршрутов.

Если в карте маршрутов нет положительных совпадений или вы попали в оператор карты маршрута, в котором нет оператора разрешения, то он обозначается как «политика отклонена». Если у вас есть условие отклонения политики, то трафик перенаправляется в обычном режиме на основе RIB.

Когда вы выполняете команду show ip route или show ipv6 route, вы не увидите, что PBR используется. Вы можете сделать политику показа ip или показать политику ipv6. Это покажет вам, что для PBR определена политика, но не там, где она связана. Чтобы увидеть, как он применяется к интерфейсу, используйте интерфейс show ip. Конечно, если у вас есть права доступа, вы можете просто посмотреть конфигурацию.

Как вы можете использовать PBR?

Обычная маршрутизация касается только переадресации на основе пункта назначения, в то время как PBR дает вам больше контроля.

Вы можете использовать PBR для:

• Прямые нисходящие каналы трафика, которые зарезервированы для определенных типов трафика или уровней приоритета.
• Направлять трафик на основе источника, а не пункта назначения, чтобы направлять трафик определенных клиентов по нисходящим каналам, которые соответствуют их соглашению об уровне обслуживания.
• Направляйте трафик в определенные туннели с многопротокольной коммутацией трафика по меткам (MPLS TE), особенно при использовании в сочетании с MPLS TE.
• Выберите пропускную способность для предоставления определенных приложений.
• Создайте резервные ссылки для наиболее важного трафика, чтобы в случае сбоя основного канала вы могли обеспечить непрерывность.
• Выберите, какой трафик будет подвергаться тщательной проверке пакетов, например, для некоторых критически важных для бизнеса приложений.< br />• Разделяйте трафик, отдавая приоритет одним, а не другим, в частности, для выполнения требований соглашения об уровне обслуживания.
• Выделите трафик определенных приложений для оптимизации глобальной сети (WAN).

Примеры использования PBR

Вот несколько примеров того, как конфигурация PBR может выглядеть на практике. Каждый пример дает общее представление о том, что делает PBR в этом конкретном контексте, но вы можете использовать эти конфигурации для индивидуальной настройки того, как ваша сеть обрабатывает трафик, чтобы улучшить различные бизнес-процессы.

Например, используя первый пример конфигурации, ориентированный на предоставление равного доступа, вы можете использовать его для обеспечения баланса использования пропускной способности между двумя критически важными бизнес-приложениями, обеспечив им равный доступ к поставщикам услуг.

Равный доступ

Эту конфигурацию можно использовать для предоставления равного доступа двум отдельным поставщикам услуг. Пакеты, поступающие через интерфейс под названием «boostedethernet 3/1» и исходящие из источника 1.1.1.1, отправляются на маршрутизатор с адресом 6.6.6.6 в случае, если у этого маршрутизатора еще нет явного маршрута, указывающего, куда должен идти пакет. .

Пакеты, поступающие из другого источника с пометкой 2.2.2.2, отправляются на другой маршрутизатор с адресом 7.7.7.7, если, как и в первой конфигурации, для пакета не указан заранее определенный пункт назначения. Другие пакеты без определенного маршрута отбрасываются.

Список доступа 1 разрешает ip 1.1.1.1
!
interface boostedethernet 3/1
ip poicy route-map equal-access
!
route-map разрешение на равный доступ 10
соответствует IP-адресу 1
установить IP-адрес по умолчанию next-hop 6.6.6.6
карта маршрутов разрешение на равный доступ 20
соответствует IP-адресу 2
установить IP-адрес по умолчанию для следующего перехода 7.7.7.7
разрешение на равный доступ для карты маршрутов 30
установить интерфейс по умолчанию null0

Определить следующий переход

В этом примере вы используете PBR для определения следующего прыжка пакетов данных при прохождении через разные сегменты вашей сети. Переход — это когда пакет данных проходит из одного сегмента вашей сети в другой, переходя от одного маршрутизатора к другому.

Использование PBR для определения следующего прыжка может решить несколько разных задач, когда речь идет об эффективности или безопасности вашей сети.
Например, если вы убедились, что один маршрутизатор, без сомнения, имеет конфигурацию, меры предосторожности и инструменты, необходимые для обеспечения максимально безопасного прыжка, вы можете отправить трафик на этот маршрутизатор с другого маршрутизатора. .

Если, например, вы уверены, что его прошивка была обновлена, его брандмауэр включен и использует последнюю информацию об угрозах, а также имеет уникальное имя и сложный для угадывания пароль, маршрутизация данных напрямую к нему может быть хороший способ обеспечить безопасность вашей передачи — по крайней мере, для этого прыжка.

Вот как может выглядеть конфигурация для определения следующего прыжка. В этом примере трафик идет от источника 2.2.2.2 к следующему переходу 5.5.5.7, а пакеты, поступающие от источника 8.8.8.8, переходят к 4.4.4.4.

список доступа 1 разрешает IP 2.2.2.2
список доступа 2 разрешает IP 8.8.8.8
!
интерфейс boostedethernet 3/1
ip policy route-map Массачусетс
!
route-map Массачусетс, разрешение 10
соответствие IP-адресу 1
установить ip next-hop 5.5.5.7
!
route-map Массачусетс, разрешение 20
соответствовать IP-адресу 2
установить IP-адрес следующего перехода 4.4.4.4

Ограничения PBR

Одна из проблем с PBR заключается в том, что он похож на статический маршрут в том смысле, что он имеет локальное значение. Если вам нужно, чтобы политика применялась к нескольким маршрутизаторам на пути между устройствами, необходимо настроить PBR для каждого прыжка.

PBR — это интересный инструмент для управления потоком трафика, основанный на чем-то другом, кроме обычной маршрутизации на основе пункта назначения, но некоторые считают его громоздким и трудно масштабируемым.

Однако маршрутизация на основе политик обеспечивает гибкость и контроль, которых нет у других методов маршрутизации. Это дает вам уровень контроля, который протокол маршрутизации сам по себе не может обеспечить. Гибкость обычно требует затрат, и в данном случае это масштабируемость и управляемость.

Это отличный инструмент, но его нельзя использовать во всех случаях. Если вам нужна переадресация на основе чего-то другого, кроме пункта назначения, тогда PBR — ваш ответ.

Популярные курсы по нетворкингу

Эксклюзивность. Создайте основу для сетевых знаний в реальной среде с различными поставщиками.

Получите базовые знания, необходимые для поддержки маршрутизаторов Cisco, и подготовьтесь к сертификации CCNA-Implementing and Administering Cisco Solutions v1.0 и CCT Routing & Switching.

Эксклюзивно - Эксклюзивно. Изучите основные навыки, необходимые для настройки, настройки, поддержки и устранения неполадок в сети на основе TCP/IP.

Независимо от того, как вы настраиваете SteelHead, если версия Cisco IOS на маршрутизаторе или коммутаторе ниже текущих минимальных рекомендаций Cisco, может быть невозможно иметь функционирующую реализацию WCCP или реализация может не иметь оптимальной производительности.

В этом разделе описываются некоторые основные принципы настройки WCCP. Этот раздел включает следующие темы:

Основной концепцией WCCP является сервисная группа. Логически сервисная группа состоит из 32 маршрутизаторов WCCP и 32 клиентов WCCP, которые совместно перенаправляют и оптимизируют трафик. Маршрутизаторы WCCP — это маршрутизаторы или коммутаторы Cisco, способные пересылать трафик, отвечающий определенным критериям. Клиенты WCCP — это устройства, получающие этот трафик. RiOS 6.1 или более поздняя версия включает несколько WCCP в пути (подробности см. в разделе Несколько WCCP в пути). Одни и те же маршрутизаторы и клиенты WCCP могут участвовать в одной или нескольких сервисных группах.

Сервисные группы различаются по номеру сервисной группы. Номер сервисной группы является локальным для сайта, где используется WCCP. Номер сервисной группы не передается по глобальной сети.

Когда маршрутизатор входит в сервисную группу WCCP, он настраивается на мониторинг трафика, проходящего через определенный пользователем набор интерфейсов. Когда маршрутизатор получает интересующий трафик, он перенаправляет IP-пакеты для передачи на назначенный интерфейс в другой системе в группе обслуживания WCCP.

Маршрутизаторы перенаправляют трафик на интерфейсы SteelHead в своей сервисной группе WCCP. Метод назначения и конфигурация балансировки нагрузки определяют, на какой интерфейс SteelHead маршрутизатор перенаправляет трафик.

Маршрутизаторы, участвующие в WCCP, поддерживают два метода назначения. Метод назначения влияет на то, как маршрутизатор перенаправляет трафик, когда в сервисной группе указано несколько целевых систем. Методы назначения важны, когда два или более SteelHead развернуты на одном сайте для обеспечения высокой доступности или балансировки нагрузки. Методы назначения следующие:

• Назначение хэша — использует программное обеспечение для расчета части распределения нагрузки, создавая значительную нагрузку на ЦП коммутатора.

• Назначение маски — трафик полностью обрабатывается аппаратно, поэтому влияние на ЦП коммутатора минимально. Назначение маски было специально разработано для аппаратных коммутаторов и маршрутизаторов.

Не путайте методы назначения с методами переадресации. Методы назначения определяют, как пакеты распределяются между несколькими SteelHeads (через маску или хэш), а методы пересылки определяют, как перехваченные пакеты пересылаются с маршрутизатора или коммутатора на SteelHead (через GRE или уровень 2).

Метод назначения хэша перенаправляет трафик на основе схемы хеширования и веса интерфейсов SteelHead. Схема хеширования представляет собой комбинацию IP-адреса источника, IP-адреса назначения, порта источника или порта назначения. Метод назначения хэша является коммутативным: пакет с IP-адресом источника X и IP-адресом назначения Y хешируется до того же значения, что и пакет с IP-адресом источника Y и IP-адресом назначения X.

Вес SteelHead определяется количеством подключений, которые поддерживает SteelHead. Вес по умолчанию зависит от номера модели SteelHead. Чем больше соединений поддерживает модель SteelHead, тем больше весит эта модель. Вы можете изменить вес каждого интерфейса в пути, чтобы вручную настроить долю трафика, получаемого интерфейсом SteelHead.

Метод назначения хэша поддерживает отработку отказа и балансировку нагрузки. В аварийной конфигурации вы настраиваете один или несколько интерфейсов SteelHead для использования только в том случае, если никакие другие интерфейсы SteelHead в сервисной группе WCCP не работают. Чтобы настроить интерфейс SteelHead для аварийного переключения, установите вес интерфейса SteelHead равным 0 в нужной сервисной группе.

Если интерфейс SteelHead имеет вес 0, а другой интерфейс SteelHead в той же сервисной группе WCCP имеет ненулевой вес, интерфейс SteelHead с весом 0 не получает перенаправленный трафик. Если вес всех работающих интерфейсов SteelHeads равен 0, трафик перенаправляется между ними поровну.

Метод назначения маски перенаправляет трафик на основе заданных администратором битов, извлеченных или замаскированных из полей IP-адреса и порта TCP. В отличие от метода назначения хэшей, эти биты не хэшируются. Вместо этого коммутатор Cisco концентрирует биты для создания индекса в таблице балансировки нагрузки.

Вы должны тщательно выбирать эти биты. При назначении маски используется до 7 бит, что позволяет использовать до 128 сегментов (2^7=128) для балансировки нагрузки между интерфейсами SteelHead в одной сервисной группе. RiOS 6.1 или более поздняя версия поддерживает балансировку нагрузки и избыточность для каждого интерфейса путем настройки каждого интерфейса SteelHead с соответствующими сервисными группами и привязками маршрутизатора (подробности см. в разделе Множественный WCCP в пути).

Метод назначения маски обрабатывает первый пакет для соединения в оборудовании маршрутизатора. Чтобы принудительно назначить маску, используйте параметр assign-scheme для команды wccp service-group:

Некоторые платформы Cisco, такие как Catalyst 4500 и Catalyst 3750, поддерживают только метод назначения маски.

При использовании метода назначения маски вы настраиваете отработку отказа так же, как и в случае метода назначения хэша.

Метод назначения маски требует, чтобы для каждого соединения пакеты перенаправлялись на один и тот же SteelHead или интерфейс в обоих направлениях (клиент-сервер и сервер-клиент). Чтобы добиться перенаправления, вы настраиваете следующие параметры:

• Поскольку для каждой сервисной группы можно использовать только один набор масок, мы рекомендуем использовать две разные сервисные группы для входящего трафика от клиента (группа 61) и входящего трафика от сервера (группа 62).

• Настройте коммутатор Cisco для перенаправления пакетов в группу обслуживания WCCP в направлении от клиента к серверу и для перенаправления пакетов в другую группу WCCP в направлении от сервера к клиенту. В большинстве случаев сервисная группа 61 размещается на входящем интерфейсе, ближайшем к клиенту, а сервисная группа 62 размещается на входящем интерфейсе, ближайшем к серверу. Как правило, при использовании маски сервисная группа 61 настраивается на основе исходного IP-адреса, а сервисная группа 62 настраивается на IP-адрес назначения, чтобы поддерживать согласованное назначение в любом направлении.

Информацию о параметрах метода назначения маски см. в Справочном руководстве по интерфейсу командной строки Riverbed .

Если иное не указано в настройках сервисной группы WCCP интерфейса SteelHead, и если маршрутизатор поддерживает это, выберите метод назначения хэша. Метод назначения хэшей обычно обеспечивает лучшее распределение нагрузки, а назначение масок обеспечивает более контролируемую пользователем настройку, включая возможность распределять трафик на основе значений маски подсети.

• Некоторые коммутаторы Cisco нижнего уровня (серии 3750, 4000, 4500 и другие) не поддерживают назначение хэшей.

• Метод назначения хэша использует запись таблицы NetFlow на коммутаторе для каждого соединения. Запись в таблице NetFlow может поддерживать до 256 тыс. подключений, в зависимости от аппаратного обеспечения.Однако, когда на коммутаторе заканчиваются записи таблицы NetFlow, каждый пакет, перенаправленный с помощью WCCP, коммутируется процессом, что отрицательно сказывается на ЦП коммутатора, и очень большие развертывания WCCP ограничиваются методом распределения нагрузки с назначением маски.

• Метод назначения хэша обрабатывает первый пакет каждого нового перенаправленного соединения с использованием ЦП коммутатора. ЦП коммутатора устанавливает запись таблицы NetFlow, которая используется для аппаратного переключения последующих пакетов для данного соединения. Этот процесс ограничивает количество установок соединения, которые коммутатор может выполнить в единицу времени. Таким образом, в развертываниях WCCP, где скорость установления соединения очень высока, метод назначения маски является единственным вариантом.

• В нескольких средах SteelHead часто желательно отправить всех пользователей в диапазоне подсети на один и тот же SteelHead. Назначение маски обеспечивает базовую возможность использования подсети филиала и SteelHead для одного и того же SteelHead в кластере WCCP.

WCCP поддерживает два метода передачи пакетов между маршрутизатором или коммутатором и интерфейсами SteelHead: метод инкапсуляции GRE и метод уровня 2. SteelHeads поддерживает методы инкапсуляции Layer-2 и GRE в обоих направлениях, от маршрутизатора или коммутатора и от них.

Метод уровня 2 обычно предпочтительнее с точки зрения производительности, поскольку он требует меньше ресурсов от маршрутизатора или коммутатора, чем инкапсуляция GRE. Метод уровня 2 изменяет только адрес Ethernet назначения. Однако не все комбинации аппаратного обеспечения Cisco и версий IOS поддерживают метод уровня 2. Кроме того, метод уровня 2 требует отсутствия переходов уровня 3 между маршрутизатором или коммутатором и SteelHead.

Метод инкапсуляции GRE добавляет заголовок GRE к пакету перед его пересылкой. Этот метод может вызвать фрагментацию и снизить производительность маршрутизатора и коммутатора, особенно в процессе деинкапсуляции пакетов GRE. Это снижение производительности может быть слишком большим для производственных развертываний.

Если ваше развертывание требует использования возврата GRE, SteelHead автоматически изменяет максимальный размер сегмента (MSS) для соединений на 1432 байта. Вы можете перезаписать этот параметр с помощью команды no wccp Adjust-mss enable, хотя мы не рекомендуем это делать.

Вы можете избежать использования метода инкапсуляции GRE для обратного пути трафика от SteelHead, используя команду SteelHead wccp override-return route-no-gre или wccp override-return sticky-no-gre. Команда wccp override-return route-no-gre позволяет SteelHead возвращать трафик без инкапсуляции GRE на внутрипутевой шлюз SteelHead, определяемый таблицей маршрутизации. Команда wccp override-return sticky-no-gre позволяет SteelHead возвращать трафик без инкапсуляции GRE на маршрутизатор, который перенаправил трафик. Обе команды выполняют одинаковую задачу, заставляя SteelHead возвращать пакеты через уровень 2, но обычно используется команда wccp override-return sticky-no-gre, поскольку чаще всего предпочтительнее возвращать пакеты исходному маршрутизатору.

Используйте команду wccp override-return route-no-gre или wccp override-return sticky-no-gre только в том случае, если SteelHead находится не более чем в шаге уровня 2 от потенциальных маршрутизаторов следующего перехода и если неинкапсулированный трафик не проходит через интерфейс, который перенаправляет пакет обратно на SteelHead (то есть отсутствует петля перенаправления WCCP). Для получения информации о командах wccp override-return route-no-gre или wccp override-return sticky-no-gre см. Справочное руководство по интерфейсу командной строки Riverbed .

Когда SteelHead в кластере WCCP передает пакеты для оптимизированных или сквозных соединений, то, как он решает адресовать эти пакеты, зависит от версии RiOS, конфигурации WCCP и таблицы маршрутизации в пути. RiOS 6.0 или более поздней версии включает больше методов для отслеживания состояния исходного маршрутизатора как для методов уровня 2, так и для методов GRE.

• Разработайте развертывание WCCP таким образом, чтобы ваши SteelHeads находились на расстоянии не более одного перехода уровня 2 от маршрутизатора или коммутатора, выполняющего перенаправление WCCP.

• Не настраивайте особый метод перенаправления или назначения на SteelHead. Разрешите SteelHead согласовать эти настройки с маршрутизатором, если только одна из причин использования назначения маски не относится к вашему развертыванию.

• Используйте команды wccp override-return route-no-gre или wccp override-return sticky-no-gre только при соблюдении следующих условий:

– Неинкапсулированный трафик, идущий к маршрутизатору или коммутатору следующего перехода, не проходит через интерфейс, который перенаправляет пакет обратно в SteelHead (то есть отсутствует петля перенаправления WCCP). Если это условие не выполняется, трафик, перенаправленный SteelHead, постоянно возвращается к тому же самому SteelHead.

Кластеризация WCCP означает, что два или более SteelHeads участвуют в одной сервисной группе. Одна сервисная группа может поддерживать 32 клиента WCCP, считая один интерфейс SteelHead клиентом.Однако один SteelHead с несколькими интерфейсами обычно не считается кластером, хотя каждый интерфейс считается клиентом.

Балансировка нагрузки и резервирование обеспечиваются для всех участвующих SteelHeads в кластере WCCP по умолчанию. Вы можете настроить вес для каждого интерфейса в пути, чтобы изменить поведение для балансировки нагрузки и избыточности. Например, вы можете настроить второй интерфейс в пути, подключенный к избыточному устройству, с меньшим весом, чтобы получить меньшую долю трафика.

Некоторые таймеры в реализации WCCPv2 напрямую влияют на время аварийного переключения и не подлежат настройке. Каждые 10 секунд SteelHead и маршрутизатор обмениваются сообщениями WCCP Here I Am и I See You (сообщения Hello). Маршрутизатор объявляет о сбое клиента после пропуска трех сообщений. В случае сбоя интерфейса SteelHead или SteelHead маршрутизатор всегда ждет от 20 до 30 секунд, прежде чем объявить SteelHead отключенным. Если отказавшему клиенту назначены сегменты (распределение трафика), маршрутизатор перенаправляет трафик отказавшему клиенту в течение этого интервала, что может привести к тому, что этот трафик будет закрыт. Трафик к другим клиентам WCCP перенаправляется и оптимизируется как обычно. После того, как клиент WCCP объявляется неисправным, сегменты пересчитываются. Сегменты, принадлежащие неисправному устройству, распределяются между оставшимися клиентами WCCP. В текущей реализации WCCPv2 нельзя настроить интервалы времени приветствия и сбоя.

В средах с высокой доступностью избыточность оптимизации означает возможность быстрого переключения на другое устройство для продолжения ускорения приложений с минимальным воздействием на пользователей. Однако независимо от того, какой метод развертывания выбран, оптимизированные соединения с одним SteelHead никогда не перестанут работать с другим SteelHead. SteelHeads, оптимизирующие соединение, действуют как TCP-прокси и, следовательно, полностью осведомлены о состоянии соединения. Хотя переадресация соединений позволяет SteelHead информировать соседей о том, какие соединения являются текущими, он не обменивается полным состоянием каждого соединения, потому что для этого требуются обширные и непрерывные обновления со всеми соседями. Не зная полного состояния соединения, новое устройство не может безопасно возобновить оптимизацию существующего соединения. Большинство приложений повторно отправляют SYN, чтобы установить новое соединение с избыточным узлом, прозрачное для пользователя. Однако не все приложения ведут себя таким образом. Имейте в виду, что потеря SteelHead требует от клиента повторной установки нового TCP-соединения, которое обычно прозрачно для пользователя.

В RiOS 6.5 или более поздних версиях необходимо включить переадресацию соединений в кластере WCCP. При включенной переадресации соединений алгоритм балансировки нагрузки WCCP учитывает общее количество интерфейсов в пути всех соседей в сервисной группе при балансировке нагрузки между интерфейсами. Если вы не включите переадресацию соединений, SteelHead с наименьшим IP-адресом назначит себе все потоки трафика.

RiOS 6.1 или более поздней версии обеспечивает дополнительную настройку WCCP, позволяя настроить каждый отдельный интерфейс SteelHead in-path в качестве клиента WCCP. Каждый настроенный интерфейс в пути участвует в сервисных группах WCCP как отдельный клиент WCCP, обеспечивая гибкость для определения пропорций балансировки нагрузки и избыточности.

До RiOS 6.1 WCCP настраивался с помощью команды wccp service group. Эта команда теперь включает интерфейс в качестве обязательного параметра, изменив синтаксис команды на группу обслуживания интерфейса wccp .

Физическое развертывание в пути требует меньше начальной и текущей настройки и обслуживания, чем развертывание вне пути или виртуальное развертывание в пути. Физические SteelHeads в пути размещаются в точках вашей сети, где данные уже передаются. Таким образом, при развертывании по пути вам не нужно изменять существующую сетевую инфраструктуру.

Технологии виртуального пути, такие как WCCP, требуют больше времени для настройки, поскольку сетевая инфраструктура должна быть настроена для перенаправления трафика на SteelHeads.

• Не требуется повторная проводка — вам не нужно перемещать какие-либо провода во время установки. На больших сайтах с несколькими активными ссылками вы можете настроить проводку, перемещая отдельные ссылки по одной через SteelHeads.

• Вариант, когда другой недоступен. На сайтах, где физическое развертывание в пути невозможно, WCCP может обеспечить необходимую интеграцию. Например, если на вашем сайте есть канал WAN, ведущий непосредственно к большому коммутатору доступа, нет места для физической установки SteelHead в пути.

• Требуются изменения в структуре сети. Для развертывания WCCP с несколькими маршрутизаторами могут потребоваться значительные изменения в сети (например, объединение VLAN и туннелей GRE).

• Требуются обновления аппаратного обеспечения и IOS. Чтобы избежать аппаратных ограничений и проблем с IOS, вы должны поддерживать версии платформы Cisco и IOS на текущих минимальных рекомендуемых уровнях.В противном случае может оказаться невозможным создать стабильное развертывание, независимо от того, как вы настроите SteelHead. Для будущего планирования функций IOS необходимо учитывать совместимость с WCCP.

• Дополнительные затраты на оценку. Оценка интеграции SteelHeads может занять больше времени. Эти накладные расходы дополняются оценкой прироста производительности SteelHead. Вам могут понадобиться профессиональные услуги Riverbed для тестирования и выполнения обновлений сетевой инфраструктуры, прежде чем можно будет выполнить какую-либо оптимизацию, особенно когда WCCP развернут на нескольких площадках.

• Дополнительное управление конфигурацией. Вы должны создавать списки контроля доступа и управлять ими на постоянной основе. На небольших площадках может оказаться целесообразным перенаправить весь трафик на SteelHeads. Однако на больших сайтах могут потребоваться списки контроля доступа, чтобы гарантировать, что трафик, который нельзя оптимизировать (например, трафик между локальными сетями), не будет отправляться на SteelHeads.

• Инкапсуляция GRE. Если схема вашей сети не поддерживает присутствие SteelHeads и маршрутизатора Cisco или интерфейса коммутатора в общей подсети, для пересылки пакетов необходимо использовать инкапсуляцию GRE. SteelHeads может обеспечить последующее дополнительное использование производительности, но ваш существующий маршрутизатор или коммутатор может использовать большие ресурсы.

В этом разделе описывается, как настроить WCCP, и приводятся примеры развертывания. Этот раздел включает следующие темы:

Возможности маршрутизации уровня 3 (L3) доступны на большинстве коммутаторов Cisco Meraki. Это позволяет коммутаторам направлять трафик между виртуальными локальными сетями в кампусной сети без необходимости в дополнительном устройстве уровня 3.

Поддерживаемые модели

Чтобы включить и настроить маршрутизацию уровня 3 на коммутаторах MS, требуется коммутатор с поддержкой уровня 3.

DHCP-сервер + реле

Теплый резерв (VRRP)**

Многоадресная маршрутизация (PIM-SM)

16384* (256 статических маршрутов)

Предупреждение "Этот коммутатор выполняет маршрутизацию для слишком большого числа хостов. Это может повлиять на производительность" будет отображаться, если текущее количество маршрутизируемых клиентов превышает значения, указанные в таблице выше.

* Чтобы защитить аппаратные ресурсы TCAM от исчерпания, применяются следующие ограничения на количество динамически (OSPF) изученных маршрутов для определенных платформ:

MS350, MS410: 15 000

Если предел достигнут, маршруты будут отклонены без разбора, что может привести к неустойчивому поведению маршрутизации. Чтобы свести к минимуму влияние этого ограничения, ограничение не повлияет на маршрут по умолчанию, и он будет принят в любом случае.

** В настоящее время не поддерживается на MS390

Инициализация маршрутизации уровня 3

Для маршрутизации трафика между виртуальными локальными сетями необходимо настроить маршрутизируемые интерфейсы. Только виртуальные локальные сети с настроенным маршрутизируемым интерфейсом смогут направлять трафик локально на коммутатор и только в том случае, если клиенты/устройства в виртуальной локальной сети настроены на использование IP-адреса маршрутизируемого интерфейса коммутатора в качестве своего шлюза или следующего перехода.

Чтобы начать использовать маршрутизацию уровня 3, перейдите на страницу сведений о коммутаторе, выбрав «Коммутатор» > «Монитор» > «Коммутаторы» и щелкнув коммутатор, который нужно настроить. В разделе Статус > Статус маршрутизации L3 нажмите Настроить параметры уровня 3.

Появившееся окно позволит настроить первый маршрутизируемый интерфейс и маршрут по умолчанию. Рекомендуется сначала настроить восходящую VLAN.

  • Имя интерфейса: понятное имя/описание интерфейса/VLAN.
  • Подсеть: сеть, в которой находится этот маршрутизируемый интерфейс, в нотации CIDR (например, 10.1.1.0/24).
  • IP-адрес интерфейса: IP-адрес, который этот коммутатор будет использовать для маршрутизации уровня 3 в этой VLAN/подсети. Он не может совпадать с IP-адресом управления коммутатора.
  • VLAN: сеть VLAN, в которую включен этот маршрутизируемый интерфейс.
  • Поддержка многоадресной рассылки. Включите поддержку многоадресной рассылки, если требуется маршрутизация многоадресной рассылки между виртуальными локальными сетями.
  • Шлюз по умолчанию: следующий переход для любого трафика, который не направляется в подсеть с прямым подключением или по статическому маршруту. Этот IP-адрес должен существовать в подсети с маршрутизируемым интерфейсом.
  • Настройки DHCP: если DHCP в этой VLAN должен обрабатываться коммутатором или перенаправляться на сервер, выберите соответствующие параметры. Дополнительную информацию см. в статье Настройка служб DHCP.
  • Настройки OSPF. Эта сеть VLAN может распространяться через OSPF. Дополнительную информацию см. в статье Обзор MS OSPF.

По завершении нажмите «Сохранить» или «Сохранить» и добавьте еще один, чтобы настроить дополнительные маршрутизируемые интерфейсы.

Настройка дополнительных интерфейсов уровня 3

Чтобы настроить дополнительные интерфейсы уровня 3 для дополнительных сетей VLAN:

  1. Перейдите к коммутатору>Настроить>Маршрутизация и DHCP.
  2. Нажмите Добавить интерфейс.
  3. Выберите коммутатор, на котором должен существовать интерфейс.
  4. Укажите необходимые сведения о конфигурации, как описано в разделе "Инициализация маршрутизации уровня 3" выше.
  5. Нажмите «Сохранить» или «Сохранить и добавить еще один», чтобы добавить дополнительные интерфейсы.

В приведенном ниже примере виртуальная локальная сеть "data" настроена на использование удаленного DHCP-сервера для клиентских запросов.

После создания все интерфейсы уровня 3 или статические маршруты появятся в разделе «Коммутатор» > «Настроить» > «Маршрутизация уровня 3».

Примечание. Каждый коммутатор может иметь только один интерфейс уровня 3 на VLAN.

Настройка статических маршрутов

Чтобы направить трафик в другое место в сети, статические маршруты должны быть настроены для подсетей, которые не маршрутизируются коммутатором или не будут использовать уже настроенный маршрут по умолчанию, например, если другая часть сети находится позади маршрутизатор или другой коммутатор уровня 3 находится в нисходящем направлении от настраиваемого коммутатора уровня 3 Cisco Meraki.

Чтобы создать новый статический маршрут:

  1. Перейдите к коммутатору>Настроить>Маршрутизация и DHCP.
  2. Нажмите Добавить статический маршрут.
  3. Выберите переключатель, к которому он должен быть применен.
  4. Укажите следующую информацию:
    • Имя: понятное имя/описание статического маршрута.
    • Подсеть: сеть, для которой предназначен этот статический маршрут, в нотации CIDR (например, 10.1.1.0/24).
    • IP-адрес следующего перехода: IP-адрес следующего устройства уровня 3 на пути к этой сети. Этот адрес должен существовать в подсети с маршрутизируемым интерфейсом.
  5. Нажмите "Сохранить" или "Сохранить" и добавьте еще один, если нужны дополнительные статические маршруты.

Редактирование существующего интерфейса уровня 3 или статического маршрута

Чтобы изменить существующий интерфейс уровня 3 или статический маршрут на конкретном коммутаторе:

  1. Перейдите к коммутатору>Настроить>Маршрутизация и DHCP.
  2. Нажмите на нужный интерфейс или маршрут.
  3. Внесите необходимые изменения.
  4. Нажмите "Сохранить".

Перенос интерфейса уровня 3 на другой коммутатор

Чтобы переместить интерфейс уровня 3 с одного коммутатора на другой:

  1. Перейдите к Коммутатору > Настроить > Маршрутизация и DHCP.
  2. Выберите интерфейсы уровня 3, которые будут перемещены.
  3. Нажмите «Правка» > «Переместить».
  4. Выберите целевой коммутатор или стек коммутаторов, затем нажмите «Отправить».

Удаление интерфейса уровня 3 или статического маршрута

Чтобы удалить интерфейс уровня 3 или статический маршрут:

  1. Перейдите к коммутатору>Настроить>Маршрутизация и DHCP.
  2. Нажмите на нужный интерфейс или маршрут.
  3. Нажмите «Удалить интерфейс/маршрут», затем нажмите «Подтвердить удаление».

Примечание. Коммутатор должен сохранить хотя бы один маршрутизируемый интерфейс и маршрут по умолчанию. Маршрут по умолчанию нельзя удалить вручную.

Отключение маршрутизации уровня 3

Чтобы отключить маршрутизацию уровня 3, все настроенные статические маршруты и интерфейсы уровня 3 должны быть удалены в определенном порядке.

  1. Перейдите к коммутатору>Настроить>Маршрутизация и DHCP.
  2. Удалите все статические маршруты, кроме маршрута по умолчанию для нужного коммутатора.
  3. Удалите все интерфейсы уровня 3, кроме того, который содержит IP-адрес следующего перехода для маршрута по умолчанию на нужном коммутаторе.
  4. Удалите последний интерфейс третьего уровня, чтобы отключить маршрутизацию третьего уровня.

Выполнение этих шагов не по порядку приведет к ошибке и не позволит удалить маршрут/интерфейс.

Предостережения относительно интерфейса уровня 3

IP-адрес управления коммутатором и интерфейсы уровня 3

IP-адрес управления полностью отличается от маршрутизируемых интерфейсов уровня 3 и должен быть другим IP-адресом. Он может быть размещен в маршрутизируемой или немаршрутизируемой VLAN (например, в случае управляющей VLAN, независимой от клиентского трафика). Трафик, использующий IP-адрес управления для связи с облачным контроллером Cisco Meraki Cloud Controller, не будет использовать параметры маршрутизации уровня 3, вместо этого будет использоваться настроенный шлюз по умолчанию. Поэтому важно, чтобы IP-адрес, VLAN и шлюз по умолчанию, введенные для IP-адреса управления/LAN, по-прежнему обеспечивали подключение к Интернету.

Интерфейс управления для коммутатора (стека), выполняющего маршрутизацию L3, не может иметь настроенный шлюз одного из собственных интерфейсов L3

Для стеков коммутаторов, выполняющих маршрутизацию L3, убедитесь, что IP-подсеть управления не пересекается с подсетью любого из настроенных интерфейсов L3. Перекрывающиеся подсети на интерфейсах IP управления и L3 могут привести к потере пакетов при эхо-запросе или опросе (через SNMP) IP-адресов управления членов стека.

Примечание. Ограничение перекрывающихся подсетей не распространяется на коммутаторы серии MS390.

Эхо-запросы, предназначенные для интерфейса уровня 3

Коммутаторы MS с включенным уровнем 3 будут отдавать приоритет пересылке трафика, а не ответам на эхо-запросы. Из-за этого могут наблюдаться потеря пакетов и/или задержка для эхо-запросов, предназначенных для интерфейса уровня 3. В таких случаях рекомендуется проверить связь с другим устройством в данной подсети, чтобы определить стабильность и доступность сети.

Читайте также: