Балансировка и распределение нагрузки
Last updated
Last updated
“А какие вы знаете способы балансировки трафика в BGP?” Это вопрос, который любят задавать на собеседованиях.
Начиная готовиться к этой статьей, я имел разговор с нашей Наташей, из которого стало понятно, что в BGP балансировка и распределение – это две большие разницы. *
Рассматриваемое дальше разделение условно и существуют альтернативные взгляды
Балансировка нагрузки
Под балансировкой обычно понимается распределение между несколькими линками трафика, направленного в одну сеть.
Включается она просто
При этом должны выполняться следующие условия:
Не менее двух маршрутов в таблице BGP для этой сети.
Оба маршрута идут через одного провайдера
Параметры Weight, Local Preference, AS-Path, Origin, MED, метрика IGP совпадают.
Параметр Next Hop должен быть разным для двух маршрутов.
Последнее условие обходится скрытой командой
В этом случае умаляется также условие полного совпадения AS-path, но длина должна быть по-прежнему одинаковой.
Как мы можем проверить это на нашей сети? Нам ведь нужно убедиться, что балансировка работает.
Балансировка обычно осуществляется на базе потоков (IP-адрес/порт отправителя и IP-адрес/порт получателя), чтобы пакеты приходили в правильном порядке. Поэтому нам нужно создать два потока. Нет ничего проще: 1) ping непосредственно с msk-arbat-gw1 на 103.0.0.1 2) подключаемся телнетом на msk-arbat-gw1 (не забыв настроить параметры) с любого другого маршрутизатора и запускаем пинг с указанием источника (чтобы потоки чем-то отличались друг от друга)
После этого один пинг пойдёт через один линк, а второй через другой. Проверено
По умолчанию никак не учитывается пропускная способность внешних каналов. Такая возможность однако реализована и запускается командами
Схема: Общая схема сети Условие: ЛинкМиАп получает от обоих провайдеров маршрут по умолчанию.
Задание: Настроить балансировку исходящего трафика между маршрутами по умолчанию от провайдеров Балаган Телеком и Филькин Сертификат в пропорции 3 к 1.
Подробности задачи тут =====================
Совсем другая песня с распределением – это более тонкая настройка путей исходящего и входящего трафика.
Исходящий трафик направляется в соответствии с маршрутами, полученными свыше. Соответственно ими и надо управлять. Напомним схему нашей сети
Итак, есть следующие способы: 1) Настройка Weight. Это цисковский внутренний параметр – никуда не передаётся – работает в пределах маршрутизатора. У других вендоров тоже часто бывают аналоги (например, PreVal у Huawei). Тут ничего специфического – не будем даже останавливаться. (по умолчанию – 0)
Применение ко всем маршрутам полученным от соседа:
Применение через route-map:
2) Local Preference. Это параметр стандартный. По умолчанию 100 для всех маршрутов. Если вы хотите трафик на определённые подсети направлять в определённые линки, то Local Preference незаменим.
Выше мы уже рассматривали пример использования данного параметра.
3) Вышеуказанная балансировка командой maximum-paths.
Схема: Общая схема сети Условие: ЛинкМиАп получает Full View от обоих провайдеров.
Задание: Не используя атрибуты weight, local preference или фильтрацию, настроить маршрутизатор msk-arbat-gw1 так, чтобы для исходящего трафика Балаган Телеком был основным, а Филькин Сертификат резервным.
Подробности задачи тут =====================
Тут всё сложно. Дело в том, что даже у крупных провайдеров исходящий трафик незначителен в сравнении со входящим. И там так остро не замечается неровное распределение.
Зато если речь идёт о Центрах Обработки Данных или хостинг-провайдерах, то ситуация обратная и вопрос балансировки стоит очень остро.
Тут мы крайне стеснены в средствах:
Один из самых частых приёмов – “ухудшение” пути. Нередко бывает так, что через одного провайдера ваши маршруты будут переданы с длиной AS-path больше, чем через другого. Разумеется, BGP выбирает первого, безапелляционно, и только через него будет передавать трафик. Чтобы выровнять ситуацию при анонсировании маршрутов можно добавить лишний “хоп” в AS-Path.
А бывает такая ситуация, что один провайдер предоставляет более широкий канал за небольшие деньги, но при этом путь через него длиннее и весь трафик уходит в другой – дорогой и узкий. Нам эта ситуация невыгодна и мы бы хотели, чтобы узкий канал стал резервным. Вот её и разберём. Но придётся взять совершенно вырожденную ситуацию. К примеру, доступ из Балаган Телекома к сети ЛикМиАп.
Вот так выглядит таблица BGP и маршрутизации на провайдере Балаган Телеком в обычной ситуации:
Если мы хотим ухудшить основной путь (прямой линк между ними), то нужно добавить AS в список AS-Path:
Тогда выглядеть картинка будет так
Разумеется, выбирается путь с меньшей длиной AS-Path, то есть через Филькин Сертификат (AS64502)
Этот маршрут и добавится в таблицу маршрутизации.
Заметим, что обычно в AS-Path добавляют именно свой номер AS. Можно, конечно, и чужую, но вас не поймут в приличном обществе.
Таким образом мы добились того, что трафик пойдёт намеченным нами путём.
Естественно, при падении одного из каналов трафик переключится на второй, независимо от настроенных AS-Path Prepend’ов.
Multiexit Discriminator. В cisco он называется метрикой (Inter-AS метрика). MED является слабым атрибутом. Слабым, потому что он проверяется лишь на шестом шаге при выборе маршрута и оказывает по сути слабое влияние. Если Local Preference влияет на выбор пути выхода трафика из Автономной системы, то MED передаётся в соседние AS и таким образом влияет на пути входа трафика. Вообще MED и Local Preference часто путают новички, поэтому опишем в табличке разницу
Local Preference | MED |
Определяет приоритет пути для выхода трафика | Определяет приоритет пути для входа трафика |
Действует только внутри AS. Никак не передаётся в другие AS | Передаётся в другие AS и намекает через какой путь передавать трафик предпочтительнее |
Может работать при подключении к разным AS | Работает только при нескольких подключениях к одной AS |
Чем больше значение, тем выше приоритет | Чем больше значение, тем ниже приоритет |
Не будем на нём останавливаться, потому что используют его редко, да и наша сеть для этого не подходит – должно быть несколько соединений между двумя AS, а у нас только по одному в каждую.
Ещё один способ распределить нагрузку – раздавать разные сети разным провайдерам.
Сейчас в сети ЦОДа наши анонсы выглядят так:
То есть наша сеть 100.0.0.0/23 известна через два пути, но в таблицу маршрутизации добавится только один. Соответственно и весь трафик назад пойдёт одним – лучшим путём.
Но! Мы можем разделить её на две подсети /24 и одну отдавать в Балаган Телеком, а другую в Филькин Сертификат. Соответственно ЦОД будет знать про эти подсети через разные пути:
Настраивается это так.
Во-первых, мы прописываем все свои подсети – все 3: одну большую /23 и две маленькие /24:
Для того, чтобы они могли быть анонсированы, нужно создать маршруты до этих подсетей.
А теперь создаём префикс-листы, которые разрешают каждый только одну подсеть /24 и общую /23.
Осталось привязать префикс-листы к соседям.
Привязываем мы их на 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.
C помощью BGP Community можно давать провайдеру указания, что делать с префиксом, кому передавать, кому нет, какой local preference у себя ставить и т.д. Рассматривать этот вариант сейчас не будем, потому что тему коммьюнити мы перенесём в следующий выпуск.
Схема: Общая схема сети
Условие: На маршрутизаторе msk-arbat-gw1 настроено управление входящим и исходящим трафиком. Основной провайдер Балаган Телеком, резервый – Филькин Сертификат. При проверке настроек оказалось, что исходящий трафик передается правильно. При проверке входящего трафика, оказалось, что входящий трафик идет и через провайдера Балаган Телеком, но когда отключается Балаган Телеком, входящий трафик не идет через Филькин Сертификат.
Задание: Исправить настройки.
Подробности задачи и конфигурация тут =====================
Инструкция по видам балансировки и распределения нагрузки
Наташа Самойленко — автор xgu.ru подготовила для нас презентацию
Вы можете её качать и использовать, как пожелаете с указанием авторства.
Все технологии маршрутизации, которые мы применяли до этого момента в наших статьях, будь то статическая маршрутизация, динамическая маршрутизация (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, который отбирает нужные нам пакеты:
Затем создаем политику маршрутизации с именем “BACK”:
Внутри нее говорим, какой трафик нас интересует:
И что с ним делать:
После чего заходим на интерфейс, который смотрит в сторону R5 (PBR работает с входящим трафиком!) и применяем на нем полученную политику:
Проверяем:
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 секунд.
Подробности задачи тут =====================
А теперь самое вкусное: представим, что в нашей схеме основной путь R4-R2-R1 обслуживает один провайдер, а запасной R4-R3-R1 – другой. Иногда у первого провайдера бывают проблемы с нагрузкой, которые приводят к тому, что наш голосовой трафик начинает страдать. При этом, другой маршрут ненагружен и хорошо бы в этот момент перенести голос на него. Ок, пишем роут-мап, как мы делали выше, который выделяет голосовой трафик и направляем его через нормально работающего провайдера. А тут – оп, ситуация поменялась на противоположную – опять надо менять все обратно. Будни техподдержки: “И такая дребедень целый день: то тюлень позвонит, то олень”. А вот бы было круто, если можно было бы отслеживать нужные нам характеристики основного канала (например, задержку или джиттер), и в, зависимости от их значения, автоматически направлять голос или видео по основному или резервному каналу, да? Так вот, чудеса бывают. В нашем случае чудо называется IP SLA.
Эта технология, по сути, есть активный мониторинг сети, т.е. генерирование некоего трафика с целью оценить ту или иную характеристику сети. Но мониторингом все не заканчивается – роутер может, используя полученные данные, влиять на принятие решений по маршрутизации, таким образом реагируя и разрешая проблему. К примеру, разгружать занятой канал, распределяя нагрузку по другим.
Без лишних слов, сразу к настройке. Для начала, нам нужно сказать, что мы хотим мониторить. Создаем объект мониторинга, назначаем ему номер:
Так-с, что мы тут можем мониторить?
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, поэтому пишем
В этой команде после указания вида проверки (udp-jitter) идет ip адрес, куда будут отсылаться пробы (т.е. меряем от нас до 192.168.200.1 – это лупбек на R1) и порт (от балды 55555). Затем можно настроить частоту проверок (по умолчанию 60 секунд):
и предельное значение, при превышении которого объект ip sla 1 рапортует о недоступности:
Некоторые виды измерений в IP SLA требуют наличия “на той стороне” так называемого “ответчика” (responder), некоторые (например, FTP, HTTP, DHCP, DNS) нет. Наш udp-jitter требует, поэтому, прежде чем запускать измерения, нужно подготовить R1:
Теперь нам нужно запустить сбор статистики. Командуем
Т.е. запускаем объект мониторинга 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):
Настраиваем задержку:
Это означает: если объект мониторинга упал и не поднялся в течение 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, а результатом этих операций будет состояние этого трека. Кроме этого, мы можем применить логическое отрицание к состоянию трека. Создаем трек-лист:
Единственным в этом “списке” будет логическое отрицание значения трека 1:
Теперь привязываем роут-мап к этому треку
Цифра 10 после адреса некстхопа – это его порядковый номер (sequence number). Мы можем, к примеру, использовать его так:
Тут такая логика: выбираем трафик, подпадающий под 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.
Теперь меняем условие трека 2, к которому привязана роут-мапа:
Вуаля, теперь трафик 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
Конфигурация устройств: базовый BGP,* AS-PATH ACL, AS-PATH Prepend, Load Balancing, Load Sharing на основе Prefix List, Prefix List, Route Map
Статью для вас подготовили eucariot и Gluck. За помощь спасибо JDima. Задачки нам написала несравненная Наташа Самойленко.<
===================== Задача №5
===================== Задача №6
===================== Задача №7
===================== Задача №8
===================== Задача №9
===================== Задача №10
