Балансировка и распределение нагрузки

Балансировка и распределение нагрузки

“А какие вы знаете способы балансировки трафика в BGP?” Это вопрос, который любят задавать на собеседованиях.

Начиная готовиться к этой статьей, я имел разговор с нашей Наташей, из которого стало понятно, что в BGP балансировка и распределение – это две большие разницы. *

Рассматриваемое дальше разделение условно и существуют альтернативные взгляды

  • Балансировка нагрузки

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

Включается она просто

router bgp 100
maximum-paths 2

При этом должны выполняться следующие условия:

  • Не менее двух маршрутов в таблице BGP для этой сети.

  • Оба маршрута идут через одного провайдера

  • Параметры Weight, Local Preference, AS-Path, Origin, MED, метрика IGP совпадают.

  • Параметр Next Hop должен быть разным для двух маршрутов.

Последнее условие обходится скрытой командой

router bgp 64500
bgp bestpath as-path multipath-relax

В этом случае умаляется также условие полного совпадения AS-path, но длина должна быть по-прежнему одинаковой.

Как мы можем проверить это на нашей сети? Нам ведь нужно убедиться, что балансировка работает.

Балансировка обычно осуществляется на базе потоков (IP-адрес/порт отправителя и IP-адрес/порт получателя), чтобы пакеты приходили в правильном порядке. Поэтому нам нужно создать два потока. Нет ничего проще: 1) ping непосредственно с msk-arbat-gw1 на 103.0.0.1 2) подключаемся телнетом на msk-arbat-gw1 (не забыв настроить параметры) с любого другого маршрутизатора и запускаем пинг с указанием источника (чтобы потоки чем-то отличались друг от друга)

После этого один пинг пойдёт через один линк, а второй через другой. Проверено

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

router bgp 64500
bgp dmzlink-bw
neighbor 101.0.0.1 dmzlink-bw
neighbor 102.0.0.1 dmzlink-bw

Конфигурация устройств

Схема: Общая схема сети Условие: ЛинкМиАп получает от обоих провайдеров маршрут по умолчанию.

Задание: Настроить балансировку исходящего трафика между маршрутами по умолчанию от провайдеров Балаган Телеком и Филькин Сертификат в пропорции 3 к 1.

Подробности задачи тут =====================

Распределение нагрузки

Совсем другая песня с распределением – это более тонкая настройка путей исходящего и входящего трафика.

Исходящий

Исходящий трафик направляется в соответствии с маршрутами, полученными свыше. Соответственно ими и надо управлять. Напомним схему нашей сети

Итак, есть следующие способы: 1) Настройка Weight. Это цисковский внутренний параметр – никуда не передаётся – работает в пределах маршрутизатора. У других вендоров тоже часто бывают аналоги (например, PreVal у Huawei). Тут ничего специфического – не будем даже останавливаться. (по умолчанию – 0)

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

neighbor 192.168.1.1 weight 500

Применение через route-map:

route-map SET_WEIGHT permit 10
set weight 500
!
router bgp 64500
neighbor 102.0.0.1 route-map SET_WEIGHT in

2) Local Preference. Это параметр стандартный. По умолчанию 100 для всех маршрутов. Если вы хотите трафик на определённые подсети направлять в определённые линки, то Local Preference незаменим.

Выше мы уже рассматривали пример использования данного параметра.

3) Вышеуказанная балансировка командой maximum-paths.

Схема: Общая схема сети Условие: ЛинкМиАп получает Full View от обоих провайдеров.

Задание: Не используя атрибуты weight, local preference или фильтрацию, настроить маршрутизатор msk-arbat-gw1 так, чтобы для исходящего трафика Балаган Телеком был основным, а Филькин Сертификат резервным.

Подробности задачи тут =====================

Входящий

Тут всё сложно. Дело в том, что даже у крупных провайдеров исходящий трафик незначителен в сравнении со входящим. И там так остро не замечается неровное распределение.

Зато если речь идёт о Центрах Обработки Данных или хостинг-провайдерах, то ситуация обратная и вопрос балансировки стоит очень остро.

Тут мы крайне стеснены в средствах:

1) AS-Path Prepend

Один из самых частых приёмов – “ухудшение” пути. Нередко бывает так, что через одного провайдера ваши маршруты будут переданы с длиной AS-path больше, чем через другого. Разумеется, BGP выбирает первого, безапелляционно, и только через него будет передавать трафик. Чтобы выровнять ситуацию при анонсировании маршрутов можно добавить лишний “хоп” в AS-Path.

А бывает такая ситуация, что один провайдер предоставляет более широкий канал за небольшие деньги, но при этом путь через него длиннее и весь трафик уходит в другой – дорогой и узкий. Нам эта ситуация невыгодна и мы бы хотели, чтобы узкий канал стал резервным. Вот её и разберём. Но придётся взять совершенно вырожденную ситуацию. К примеру, доступ из Балаган Телекома к сети ЛикМиАп.

Вот так выглядит таблица BGP и маршрутизации на провайдере Балаган Телеком в обычной ситуации:

Если мы хотим ухудшить основной путь (прямой линк между ними), то нужно добавить AS в список AS-Path:

router bgp 64500
neighbor 101.0.0.1 route-map AS_PATH_PREP out

route-map AS_PATH_PREP permit 10
set as-path prepend 64500 64500

Тогда выглядеть картинка будет так

Разумеется, выбирается путь с меньшей длиной AS-Path, то есть через Филькин Сертификат (AS64502)

Этот маршрут и добавится в таблицу маршрутизации.

Заметим, что обычно в AS-Path добавляют именно свой номер AS. Можно, конечно, и чужую, но вас не поймут в приличном обществе.

Таким образом мы добились того, что трафик пойдёт намеченным нами путём.

Естественно, при падении одного из каналов трафик переключится на второй, независимо от настроенных AS-Path Prepend’ов.

Конфигурация устройств.

2) MED

Multiexit Discriminator. В cisco он называется метрикой (Inter-AS метрика). MED является слабым атрибутом. Слабым, потому что он проверяется лишь на шестом шаге при выборе маршрута и оказывает по сути слабое влияние. Если Local Preference влияет на выбор пути выхода трафика из Автономной системы, то MED передаётся в соседние AS и таким образом влияет на пути входа трафика. Вообще MED и Local Preference часто путают новички, поэтому опишем в табличке разницу

Не будем на нём останавливаться, потому что используют его редко, да и наша сеть для этого не подходит – должно быть несколько соединений между двумя AS, а у нас только по одному в каждую.

3) Анонс разных префиксов через разных ISP

Ещё один способ распределить нагрузку – раздавать разные сети разным провайдерам.

Сейчас в сети ЦОДа наши анонсы выглядят так:

То есть наша сеть 100.0.0.0/23 известна через два пути, но в таблицу маршрутизации добавится только один. Соответственно и весь трафик назад пойдёт одним – лучшим путём.

Но! Мы можем разделить её на две подсети /24 и одну отдавать в Балаган Телеком, а другую в Филькин Сертификат. Соответственно ЦОД будет знать про эти подсети через разные пути:

Настраивается это так.

Во-первых, мы прописываем все свои подсети – все 3: одну большую /23 и две маленькие /24:

router bgp 64500
network 100.0.0.0 mask 255.255.254.0
network 100.0.0.0 mask 255.255.255.0
network 100.0.1.0 mask 255.255.255.0

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

ip route 100.0.0.0 255.255.254.0 Null0
ip route 100.0.0.0 255.255.255.0 Null0
ip route 100.0.1.0 255.255.255.0 Null0

А теперь создаём префикс-листы, которые разрешают каждый только одну подсеть /24 и общую /23.

ip prefix-list LIST_OUT1 seq 5 permit 100.0.0.0/24
ip prefix-list LIST_OUT1 seq 10 permit 100.0.0.0/23
! 
ip prefix-list LIST_OUT2 seq 5 permit 100.0.1.0/24
ip prefix-list LIST_OUT2 seq 10 permit 100.0.0.0/23

Осталось привязать префикс-листы к соседям.

router bgp 64500
neighbor 101.0.0.1 remote-as 64501
neighbor 101.0.0.1 prefix-list LIST_OUT1 out
neighbor 102.0.0.1 remote-as 64502
neighbor 102.0.0.1 prefix-list LIST_OUT2 out

Привязываем мы их на OUT – на исходящий, потому что речь о маршрутах, которые мы отправляем вовне.

Итак, соседу 101.0.0.1 (Балаган Телеком) мы будем анонсировать сети 100.0.0.0/24 и 100.0.0.0/23. А соседу 102.0.0.1 (Филькин Сертификат) – сети 100.0.1.0/24 и 100.0.0.0/23.

Результат будет таким:

Вроде бы, неправильно, потому что у нас по два маршрута в каждую сеть /24 – через Балаган Телеком и через Филькин Сертификат. Но если приглядеться, то вы увидите, что согласно AS-Path у нас такие маршруты:

То есть, по сути всё правильно. Да и в таблицу маршрутизации всё помещается правильно:

Теперь осталось ответить на вопрос какого лешего мы тащили за собой большую подсеть /23? Ведь согласно правилу Longest prefix match более точные маршруты предпочтительней, то есть /23, как бы и не нужен, когда есть /24.

Но вообразим себе ситуацию, когда падает сеть Балаган Телеком. Что при этом произойдёт

Существуют также специальные организации, которые отслеживают анонсы BGP в Интернете и, если вдруг происходит что-то неожиданное, может уведомить владельца сети. Подсеть 100.0.0.0/24 перестанет быть известной в интернете – ведь только Балаган Телеком что-то знал о ней благодаря нашей настройке. Соответственно, ляжет и часть нашей сети. Но! Нас спасает более общий маршрут 100.0.0.0/23. Филькин Сертификат знает о нём и анонсирует его в Интернет. Соответственно, хоть ЦОД и не знает про сеть 100.0.0.0/24, он знает про 100.0.0.0/23 и пустит трафик в сторону Филькина Сертификата.

То есть, слава Лейбницу, мы застрахованы от такой ситуации.

Надо иметь ввиду, что помимо настройки маршрутизатора вам придётся завести все три сети в базе данных RIPE. Там должны быть и обе сети /24 и сеть /23.

Конфигурация устройств

4) BGP Community

C помощью BGP Community можно давать провайдеру указания, что делать с префиксом, кому передавать, кому нет, какой local preference у себя ставить и т.д. Рассматривать этот вариант сейчас не будем, потому что тему коммьюнити мы перенесём в следующий выпуск.

Схема: Общая схема сети

Условие: На маршрутизаторе msk-arbat-gw1 настроено управление входящим и исходящим трафиком. Основной провайдер Балаган Телеком, резервый – Филькин Сертификат. При проверке настроек оказалось, что исходящий трафик передается правильно. При проверке входящего трафика, оказалось, что входящий трафик идет и через провайдера Балаган Телеком, но когда отключается Балаган Телеком, входящий трафик не идет через Филькин Сертификат.

Задание: Исправить настройки.

Подробности задачи и конфигурация тут =====================

Инструкция по видам балансировки и распределения нагрузки

Наташа Самойленко — автор xgu.ru подготовила для нас презентацию

Вы можете её качать и использовать, как пожелаете с указанием авторства.

PBR

Все технологии маршрутизации, которые мы применяли до этого момента в наших статьях, будь то статическая маршрутизация, динамическая маршрутизация (IGP или EGP), в своей работе принимали во внимание только один признак пакета: адрес назначения. Все они, упрощенно, действовали по одному принципу: смотрели, куда идет пакет, находили в таблице маршрутизации наиболее специфичный маршрут до пункта назначения (longest match), и переправляли пакет в тот интерфейс, который был записан в таблице напротив этого самого маршрута. В этом, в общем-то, и состоит суть маршрутизации. А что, если такой порядок вещей нас не устраивает? Что, если мы хотим маршрутизировать пакет, отталкиваясь от адреса источника? Или нам нужно мальчики HTTP направо, девочки SNMP налево?

В такой ситуации нам приходит на помощь маршрутизация на базе политик ака PBR (Policy based routing). Эта технология позволяет нам управлять трафиком, базируясь на следующих признаках пакета:

  • Адрес источника (или комбинация адрес источника-адрес получателя)

  • Информация 7 уровня (приложений) OSI

  • Интерфейс, в который пришел пакет

  • QoS-метки

  • Вообще говоря, любая информация, используемая в extended-ACL (порт источника\получателя, протокол и прочее, в любых комбинациях). Т.е. если мы можем выделить интересующий нас трафик с помощью расширенного ACL, мы сможем его смаршрутизировать, как нам будет угодно.

Плюсы использования PBR очевидны: невероятная гибкость маршрутизации. Но и минусы тоже присутствуют:

  • Все нужно писать руками, отсюда много работы и риск ошибки

  • Производительность. На большинстве железок PBR работает медленнее, чем обычный роутинг (исключение составляют каталисты 6500, к ним есть супервайзер с железной поддержкой PBR)

Политика, на основе которой осуществляется PBR, создается командой route map POLICY_NAME, и содержит два раздела:

  • Выделение нужного трафика. Осуществляется либо с помощью ACL, либо в зависимости от интерфейса, в который трафик пришел. За это отвечает команда match в режиме конфигурации route map

  • Применение действия к этому трафику. За это отвечает команда set

Немного практики для закрепления

Имеем вот такую топологию:

В данный момент трафик R1-R5 и обратно идет по маршруту R1-R2-R4-R5, для удобства, адреса присвоены так, чтобы последняя цифра адреса была номером маршрутизатора:

R1#traceroute 192.168.100.5 1 192.168.0.2 20 msec 36 msec 20 msec 2 192.168.2.4 40 msec 44 msec 16 msec 3 192.168.100.5 56 msec * 84 msec

R5#traceroute 192.168.0.1 1 192.168.100.4 56 msec 40 msec 8 msec 2 192.168.2.2 20 msec 24 msec 16 msec 3 192.168.0.1 64 msec * 84 msec

Для примера, предположим, что нам нужно, чтобы обратно трафик от R5 (с его адресом в источнике) шел по маршруту R5-R4-R3-R1. По схеме очевидно, что решение об этом должен принимать R4. На нем сначала создаем ACL, который отбирает нужные нам пакеты:

R4(config)#access-list 100 permit ip host 192.168.100.5 any

Затем создаем политику маршрутизации с именем “BACK”:

R4(config)#route-map BACK

Внутри нее говорим, какой трафик нас интересует:

R4(config-route-map)#match ip address 100

И что с ним делать:

R4(config-route-map)#set ip next-hop 192.168.3.3

После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:

R4(config)#int fa1/0
R4(config-if)#ip policy route-map BACK

Проверяем:

R5#traceroute 192.168.0.1 1 192.168.100.4 40 msec 40 msec 16 msec 2 192.168.3.3 52 msec 52 msec 44 msec 3 192.168.1.1 56 msec * 68 msec

Работает! А теперь посмотрим внимательно на схему и подумаем: все ли хорошо?

А вот и нет! Следуя данному ACL, у нас заворачивается на R3 весь трафик с источником R5. А это значит, что если, например, R5 захочет попасть на R2, он, вместо короткого и очевидного маршрута R5-R4-R2, будет послан по маршруту R5-R4-R3-R1-R2. Поэтому, нужно очень аккуратно и вдумчиво составлять ACL для PBR, делая его максимально специфичным.

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

  • set ip next-hop

  • set interface

  • set ip default next-hop

  • set default interface

С первыми двумя все относительно понятно – они переопределяют некстхоп и интерфейс, из которого пакет будет выходить (чаще всего set interface применяется для point-to-point линков). А в случае, если мы применяем команды set ip default next-hop или set default interface, роутер сначала смотрит таблицу маршрутизации, и, если там имеется маршрут для проверяемого пакет, отправляет его соответственно таблице. Если маршрута нет, пакет отправляется, как сказано в политике. К примеру, если бы мы в нашей топологии вместо set ip next-hop 192.168.3.3 скомандовали set ip default next-hop 192.168.3.3, ничего бы не поменялось, так как у R4 есть маршрут к R1 (через R2). Но если бы он отсутствовал, трафик направлялся бы к R3.

Вообще говоря, с помощью команды set можно изменять очень много в подопытном пакете: начиная от меток QoS или MPLS и заканчивая атрибутами BGP

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP). Схема и конфигурация. Маршрутизаторы провайдеров также не используют BGP.

Задание: Настроить переключение между провайдерами. Маршрут по умолчанию к Балаган Телеком должен использоваться до тех пор, пока приходят icmp-ответы на пинг google (103.0.0.10) ИЛИ yandex (103.0.0.20). Запросы должны отправляться через Балаган Телеком. Если ни один из указанных ресурсов не отвечает, маршрут по умолчанию должен переключиться на провайдера Филькин Сертификат. Для того чтобы переключение не происходило из-за временной потери отдельных icmp-ответов, необходимо установить задержку переключения, как минимум, 5 секунд.

Подробности задачи тут =====================

IP SLA

А теперь самое вкусное: представим, что в нашей схеме основной путь R4-R2-R1 обслуживает один провайдер, а запасной R4-R3-R1 – другой. Иногда у первого провайдера бывают проблемы с нагрузкой, которые приводят к тому, что наш голосовой трафик начинает страдать. При этом, другой маршрут ненагружен и хорошо бы в этот момент перенести голос на него. Ок, пишем роут-мап, как мы делали выше, который выделяет голосовой трафик и направляем его через нормально работающего провайдера. А тут – оп, ситуация поменялась на противоположную – опять надо менять все обратно. Будни техподдержки: “И такая дребедень целый день: то тюлень позвонит, то олень”. А вот бы было круто, если можно было бы отслеживать нужные нам характеристики основного канала (например, задержку или джиттер), и в, зависимости от их значения, автоматически направлять голос или видео по основному или резервному каналу, да? Так вот, чудеса бывают. В нашем случае чудо называется IP SLA.

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

Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер:

R4(config)#ip sla 1

Так-с, что мы тут можем мониторить?

R4(config-ip-sla)#? IP SLAs entry configuration commands: dhcp DHCP Operation dns DNS Query Operation exit Exit Operation Configuration frame-relay Frame-relay Operation ftp FTP Operation http HTTP Operation icmp-echo ICMP Echo Operation icmp-jitter ICMP Jitter Operation mpls MPLS Operation path-echo Path Discovered ICMP Echo Operation path-jitter Path Discovered ICMP Jitter Operation slm SLM Operation tcp-connect TCP Connect Operation udp-echo UDP Echo Operation udp-jitter UDP Jitter Operation voip Voice Over IP Operation

Нужно сказать, что синтаксис команд, относящихся к IP SLA, претерпел некоторые изменения: начиная с IOS 12.4(4)T он такой, как в статье, до этого некоторые команды писались по другому. Например, вместо ip sla 1 было rtr 1 или вместо ip sla responder – rtr responder

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

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

Задание: Настроить маршрутизацию таким образом, чтобы HTTP-трафик из локальной сети 10.0.1.0 шел через Балаган Телеком, а весь трафик из сети 10.0.2.0 через Филькин Сертификат. Если в адресе отправителя фигурирует любой другой адрес, трафик должен быть отброшен, а не маршрутизироваться по стандартной таблице маршрутизации (задание надо выполнить не используя фильтрацию с помощью ACL, примененных на интерфейсе). Дополнительное условие: Правила PBR должны работать так только если соответствующий провайдер доступен (в данной задаче достаточно проверки доступности ближайшего устройства провайдера). Иначе должна использоваться стандартная таблица маршрутизации.

Подробности задачи тут =====================

Обычно, работу IP SLA рассматривают на простейшем примере icmp-echo. То есть, в случае, если мы можем пинговать тот конец линии, трафик идет по ней, если не можем – по другой. Но мы пойдем путем чуть посложнее. Итак, нас интересуют характеристики канала, важные для голосового трафика, например, джиттер. Конкретнее, udp-jitter, поэтому пишем

R4(config-ip-sla)#udp-jitter 192.168.200.1 55555

В этой команде после указания вида проверки (udp-jitter) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до 192.168.200.1 – это лупбек на R1) и порт (от балды 55555). Затем можно настроить частоту проверок (по умолчанию 60 секунд):

R4(config-ip-sla-jitter)#frequency 10

и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности:

R4(config-ip-sla-jitter)#threshold 10

Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш udp-jitter требует, поэтому, прежде чем запускать измерения, нужно подготовить R1:

R1(config)#ip sla responder

Теперь нам нужно запустить сбор статистики. Командуем

R4(config)#ip sla schedule 1 start-time now life forever

Т.е. запускаем объект мониторинга 1 прямо сейчас и до конца дней.

Мы не можем менять параметры объекта, если запущен сбор статистики. Т.е. чтобы поменять, например, частоту проб, нам нужно сначала выключить сбор информации с него: no ip sla schedule 1

Теперь уже можем посмотреть, что у нас там собирается:

R4#sh ip sla statistics 1

Round Trip Time (RTT) for Index 1 Latest RTT: 36 milliseconds Latest operation start time: *00:39:01.531 UTC Fri Mar 1 2002 Latest operation return code: OK RTT Values: Number Of RTT: 10 RTT Min/Avg/Max: 19/36/52 milliseconds Latency one-way time: Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds Jitter Time: Number of SD Jitter Samples: 9 Number of DS Jitter Samples: 9 Source to Destination Jitter Min/Avg/Max: 0/5/20 milliseconds Destination to Source Jitter Min/Avg/Max: 0/16/28 milliseconds Packet Loss Values: Loss Source to Destination: 0 Loss Destination to Source: 0 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0 Packet Skipped: 0 Voice Score Values: Calculated Planning Impairment Factor (ICPIF): 0 Mean Opinion Score (MOS): 0 Number of successes: 12 Number of failures: 0 Operation time to live: Forever

а также что мы там наконфигурировали

R4#sh ip sla conf IP SLAs Infrastructure Engine-II Entry number: 1 Owner: Tag: Type of operation to perform: udp-jitter Target address/Source address: 192.168.200.1/0.0.0.0 Target port/Source port: 55555/0 Request size (ARR data portion): 32 Operation timeout (milliseconds): 5000 Packet Interval (milliseconds)/Number of packets: 20/10 Type Of Service parameters: 0x0 Verify data: No Vrf Name: Control Packets: enabled Schedule: Operation frequency (seconds): 10 (not considered if randomly scheduled) Next Scheduled Start Time: Pending trigger Group Scheduled: FALSE Randomly Scheduled: FALSE Life (seconds): 3600 Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): Active Threshold (milliseconds): 10 Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): 4294967295 Enhanced History:

Теперь настраиваем так называемый track (неправильный, но понятный перевод “отслеживатель”). Именно к его состоянию привязываются впоследствии действия в роут-мапе. В track можно выставить задержку переключения между состояниями, что позволяет решить проблему, когда у нас по одной неудачной пробе меняется маршрутизация, а по следующей, уже удачной, меняется обратно. Указываем номер track и к какому номеру объекта ip sla мы его подключаем (rtr 1):

R4(config)#track 1 rtr 1

Настраиваем задержку:

R4(config-track)#delay up 10 down 15

Это означает: если объект мониторинга упал и не поднялся в течение 15 секунд, переводим track в состояние down. Если объект был в состоянии down, но поднялся и находится в поднятом состоянии хотя бы 10 секунд, переводим track в состояние up. Следующим действием нам нужно привязать track к нашей роут-мапе. Напомню, стандартный путь от R5 к R1 идет через R2, но у нас имеется роут-мапа BACK, переназначающая стандартное положение вещей в случае, если источник R5:

R4#sh run | sec route-map ip policy route-map BACK route-map BACK permit 10 match ip address 100 set ip next-hop 192.168.3.3

Если мы привяжем наш мониторинг к этой мапе, заменив команду set ip next-hop 192.168.3.3 на set ip next-hop verify-availability 192.168.3.3 10 track 1, получим обратный нужному эффект: в случае падения трека (из-за превышения показателя джиттера в sla 1), мапа не будет отрабатываться (все будет идти согласно таблице маршрутизации), и наоборот, в случае нормальных значений, трек будет up, и трафик будет идти через R3.

Как это работает: роутер видит, что пакет подпадает под условия match, но потом не сразу делает set, как в предыдущем примере с PBR, а промежуточным действием проверяет сначала состояние трека 1, а затем, если он поднят (up), уже делается set, если нет – переходит к следующей строчке роут-мапы.

Для того, чтобы наша мапа заработала, как надо, нам нужно как-то инвертировать значение трека, т.е. когда джиттер большой, наш трек должен быть UP, и наоборот. В этом нам поможет такая штука, как track list. В IP SLA существует возможность объединять в треке список других треков (которые, по сути, выдают на выходе 1 или 0) и производить над ними логические операции OR или AND, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист:

R4(config)#track 2 list boolean or

Единственным в этом “списке” будет логическое отрицание значения трека 1:

R4(config-track)#object 1 not

Теперь привязываем роут-мап к этому треку

R4(config)#route-map BACK
R4(config-route-map)#no set ip next-hop 192.168.3.3
R4(config-route-map)#set ip next-hop verify-availability 192.168.3.3 10 tr 2

Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так:

route-map BACK permit 10
match ip address 100
set ip next-hop verify-availability 192.168.3.3 10 track 1
set ip next-hop verify-availability 192.168.2.2 20 track 2

Тут такая логика: выбираем трафик, подпадающий под ACL 100, затем идет промежуточная проверка track 1, если он up, ставим пакету некстхоп 192.168.3.3, если down, переходим к следующему порядковому номеру (20 в данном случае), опять же промежуточно проверяем состояние трека (уже другого, 2), в зависимости от результата, ставим некстхоп 192.168.2.2 или отправляем с миром (маршрутизироваться на общих основаниях).

Давайте теперь немножко словами порассуждаем, что же мы такое накрутили: итак, измерения джиттера у нас идут от источника R4 к респондеру R1 по маршруту через R2. Максимальное допустимое значение джиттера на этом маршруте у нас – 10. В случае, если джиттер превышает это значение и держится на этом уровне 15 секунд, мы переключаем трафик, генерируемый R5, на маршрут через R3. Если джиттер падает ниже 10 и держится там минимум 10 секунд, пускаем трафик от R5 по стандартному маршруту. Попробуйте для закрепления материала найти, в каких командах задаются все эти значения.

Итак, мы достигли цели: теперь, в случае ухудшения качества основного канала (ну, по крайней мере, значений udp-джиттера), мы переходим на резервный. Но что, если и там тоже не очень? Может, попробуем с помощью IP SLA решить и эту проблему?

Попробуем выстроить логику того, что мы хотим сделать. Мы хотим перед переключением на резервный канал проверять, как у нас обстоит дело с джиттером на нем. Для этого нам нужно завести дополнительный объект мониторинга, который будет считать джиттер на пути R4-R3-R1, пусть это будет 2. Сделаем его аналогичным первому, с теми же значениями. Условием переключения на резервный канал тогда будет: объект 1 down И объект 2 up. Чтобы измерять джиттер не по основному каналу, придется пойти на хитрость: сделать loopback-интерфейсы на R1 и R4, прописать статические маршруты через R3 туда-обратно, и использовать эти адреса для объекта SLA 2.

R1(config)#int lo1
R1(config-if)#ip add 192.168.30.1 255.255.255.0
R1(config-if)#exit
R1(config)#ip route 192.168.31.0 255.255.255.0 192.168.1.3

R3(config)#ip route 192.168.30.0 255.255.255.0 192.168.1.1
R3(config)#ip route 192.168.31.0 255.255.255.0 192.168.3.4

R4(config)#int lo0
R4(config-if)#ip add 192.168.31.4 255.255.255.0
R4(config-ip-sla-jitter)#exit
R4(config)#ip sla 2
R4(config-ip-sla)#udp-jitter 192.168.30.1 55555 source-ip 192.168.31.4
R4(config-ip-sla-jitter)#threshold 10
R4(config-ip-sla-jitter)#frequency 10
R4(config-ip-sla-jitter)#exit
R4(config)#ip route 192.168.30.0 255.255.255.0 192.168.3.3
R4(config)#ip sla schedule 2 start-time now life forever
R4(config)#track 3 rtr 2

Теперь меняем условие трека 2, к которому привязана роут-мапа:

R4(config)#track 2 list boolean and
R4(config-track)#object 1 not
R4(config-track)#object 3

Вуаля, теперь трафик R5->R1 переключается на запасной маршрут только в том случае, если джиттер основного канала больше 10 и, в это же время, джиттер запасного меньше 10. В случае, если высокий джиттер наблюдается на обоих каналах, трафик идет по основному и молча страдает.

Состояние трека можно привязать также к статическому маршруту: например, мы можем командой ip route 0.0.0.0 0.0.0.0 192.168.1.1 track 1 сделать шлюзом по умолчанию 192.168.1.1, который будет связан с треком 1 (который, в свою очередь, может проверять наличие этого самого 192.168.1.1 в сети или измерять какие-нибудь важные характеристики качества связи с ним). В случае, если связанный трек падает, маршрут убирается из таблицы маршрутизации.

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

Схема: как и для других задач по PBR. Конфигурация ниже.

Условие: ЛинкМиАп использует статические маршруты к провайдерам (не BGP).

На маршрутизаторе msk-arbat-gw1 настроена PBR: HTTP-трафик должен идти через провайдера Филькин Сертификат, а трафик из сети 10.0.2.0 должен идти через Балаган Телеком. Указанный трафик передается правильно, но не маршрутизируется остальной трафик из локальной сети, который должен передаваться через провайдера Балаган Телеком.

Задание: Исправить настройки таким образом, чтобы они соответствовали условиям.

Подробности задачи и конфигурация тут =====================

Полезные ссылки

BGP

IP SLA

Статью для вас подготовили eucariot и Gluck. За помощь спасибо JDima. Задачки нам написала несравненная Наташа Самойленко.<

Last updated