Опубликовано Ilya 9 Май , 2011

Доброго дня всем!

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

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

Поначалу немного адаптированного перевода, дальше пойдем моими словами.

1. Что же такое OER?

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

Чтобы это побороть и была придумана технология Optimized Edge Routing (OER) или ее новое название — Performance Routing (PfR). Для этого в OER выделяются классы трафика (например приложения или подсети). Производительность (комплексное понятие, может включать в себя задержку, пропускную способность, потери и т.п.) каждого класса периодически измеряется и сравнивается с установленными правилами (политиками). По результатам этих сравнений OER  выбирает лучший выход из сети или гейт для данного класса трафика.

2. Когда это нужно?

Рассмотрим классическую топологию домашней сети крупного предприятия.

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

OER мониторит и управляет исходящим трафиком на двух CE, называемых в терминологии OER по-другому: border routers (BRs).

Замечание. В  Cisco IOS версиях 12.4(9)T, 12.2(33)SRB and более поздних,  появилась возможность мониторить и управлять входящим трафиком.

OER измеряет время отклика и доступность пути с внешних интерфейсов BR1, BR2 и BR3. Изменения в производительности выходного линка на BR определяются попрефиксно. Если производительность падает ниже дефолтной или пользовательской политики  маршрутизация «исправляется» для повышения производительности. Например, в случае перегрузки внешнего интерфейса BR2, обычная маршрутизация не в состоянии ничего сделать, а OER может определить проблемное состояние и переправить трафик через другой выход.

Это фантастика? И да, и нет. Давайте посмотрим, что нам для этого предлагает OER.

3. Пять шагов к успеху

Итак, чтобы достичь состояния дзен для нашей сети, OER использует следующие пять этапов (фаз).

OER Profile Phase

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

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

OER Measure Phase

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

• Пассивный мониторинг — измерение метрик производительности потока трафика во время его прохождения через устройство. Работает не для всех классов трафика и не для всех устройств и не для всех версий IOS 🙂 .
• Активный мониторинг фактически состоиет в генерации искусственного тафика для эмуляции активности данного класса.

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

OER Apply Policy Phase

После сбора метрик производительности для данного класса, OER сравнивает эти результаты с набором граничных значений для каждой метрики. Если какая-то метрика, а значит и политика, выходит за граничные значения — происходит событие Out-of-Policy (OOP). Данные сравниваются двумя способами: либо как отклонение от среднего, либо как выход за границу. Возможно и то, и другое сразу 🙂

В OER существует два вида политик:

• Политики классов трафика (traffic class policies) — создаются для префиксов или для приложений.
• Политики линков (link policies) — создаются для выходов за границу сети.

Оба типа политик определяют критерии для генерации события OOP. Политики применяются глобально (для всех классов трафика) или локально (только дл некоторых классов).

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

OER Control Phase

Этой фазе OER (еще ее называют «фаза усиления» (enforce phase), прям звукоообработка какая-то),  трафик контролируется для увеличения производительности. Способ этого контроля зависит от способа задания класса трафика.

• Если класс трафика задан только с использованием префикса — будет скорректирована информация о достижимости префиксаа (добавление/удаление статики, изменение метрик и даже (о ужас!) — используя хитрости BGP).
• Если класс трафика задан приложением, т.е. префиксом и дополнительными условиями, OER уже не сможет использовать обычный протокол маршрутизации и здесь уже на помощь придет PBR.

Вам уже страшно? То ли еще будет.

OER Verify Phase

В этой фазе, если класс трафика вышел за границы, предусмотренные политикой (OOP), OER начинает вмешиваться с целью повлиять (улучшить, кхе) на трафик этого класса. Например с помощью уже упомянутых статических маршрутов или маршрутов BGP. После вмешательства OER удостоверяется, что оптимизируемый трафик использует тот гейтвей, который нужен. Если после этого трафику лучше не стало, то OER отменит изменения и повторит перечисленные фазы сначала.

А с чем у нас суп? Или компоненты сети под управлением OER.

• OER Master Controller — маршрутизатор, координирующий работу OER по всей сети. Может выполнять только эту функцию, может так же быть пограничным роутером (BR). Master наблюдает за исходящим трафиком с помощью пассивного или активного мониторинга и применяет к этим потокам имеющиеся политики для оптимизации маршрутизации, являсь по сути централизованным центром управления (и точкой отказа, хе-хе) для всех пограничных роутеров.
• OER Border Router — нормальный такой CE c одним или несколькими линками к провайдерам. Именно на нем (или на них, если их несколько) все изменения, принятые MC, внедряются в жизнь. BR тоже участвует в мониторинге, сообщая данные MC. И наконец, (о счастье!) BR может быть одновременно и MC.
• OER-Managed Network Interfaces — (собственно, а слуги кто?) — то, чем управляет OER. И тут вот логичное требование: сеть под управлением OER должна иметь как минимум два исходящих (external) интерфейса для трафика, текущего наружу. Иначем просто оптимизировать нечего!. На каждом BR так же должен быть хотя бы один интерфейс, достижимый из внутренней сети, чтобы его можно было пометить как «internal» для пассивного мониторинга. И есть еще локальный интерфейс (local) для взаимодействия между MC и BR.

Итого, в нашей замечательной топологии нам нужно выделить внешние и внутренние интерфейсы, BR и еще какой-то маршрутизатор должен за всем этим следить и называться MC.

Но проницательный читатель наверное давно поймал меня на одной подлости. Подлость эта называется PAT. Но и эта подлость учтена OER и я почти приступаю к ее рассмотрению 🙂

Теперь я заканчиваю идти путем теоретиков и предлагаю посмотреть простенькую  схему, часто встречающуюся в нашем колхозе на нашем форуме: а именно

Задачка. Single router with dual-ISP

Картина маслом выглядит так:

Т.е. у нас есть некоторая внутренняя сеть с пограничным маршрутизатором и двумя подключениями к провайдерам, каждый из которых строго блюдет правила RPF. Все мы знаем, что в этом случае возможна только статическая балансировка нагрузки с помощью PBR, поскольку если начать балансировать трафик между ISP без учета сессий — либо RPF задушит, либо TCP-сессии порвутся. Но нет, OER говорит, что мы можем выкинуть свои знания на помойку 🙂

Естественно за неимением другого этот несчастный роутер  будет у нас и MC, и BR, и NAT-транслятором. Все претензии можно отсылать ВВП жадному боссу конторы, который платит админу за умение настроить OER, но не хочет покупать железки.

Изменение в командах настройки над подкупающе просто — ключевое  слово oer, добавленное в конце команды ip nat inside source. Например, так:

ip nat inside source route-map ISP1 interface FastEthernet0/0 overload oer
ip nat inside source route-map ISP2 interface FastEthernet0/1 overload oer

После того, как мы так сконфигурировали NАТ, новые NAT-трансляции получает в качестве адреса источника адрес интерфейса, который OER выберет для потока. А последующие пакеты в потоке будут с помощью OER отправлены тем путем, куда указывает созданная NAT-трансляция.

Иными словами, в такой конфигурации OER выполняет две функции:

1. Балансирует выбор интерфейсов для новых потоков.
2. Направляет имеющиеся потоки туда, где уже единожды была создана трансляция.

2siv: не уверен, что ты это прочитаешь, но помнишь мы с тобой обсуждали, как такое сделать? Вот ответ 🙂

Что еще надо? Настроить это дело 🙂 Настраивать будем на

Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.1(4)M
Cisco 7206VXR (NPE400) processor (revision A) with 245760K/16384K bytes of memory

Извините, ничего другого с 15м IOS под рукой не оказалось. В 12.4 все почти так же, только первое слово pfr меняется на oer.

Настройка BR/MC/NAT.

Посмотрим на наши интерфесы:

R1#sh ip int brief

Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            172.16.1.1      YES manual up                    up      
FastEthernet0/1            172.16.2.1      YES manual up                    up  
FastEthernet1/0            192.168.1.1     YES manual up                    up      
Loopback0                  192.168.2.1     YES manual up                    up

Здесь fa 0/0 и fa 0/1 — внешние интерфейсы, смотрящие на два ISP, fa 1/0 — внутренний интерфейс, смотрящий в локалку, lo 0 — локальный интерфейс для взаимодействия MC и BR.

Конфигурируем мастера.

Сначала базовая настройка (без политик).

Входим в режим
(config)# pfr master

Включаем логгирование активности
(config-pfr-mc)#logging

Конфигурируем подконтрольный бордер (мы сами)
(config-pfr-mc)# border 192.168.2.1 key-chain test

У бордера настраиваем интерфейсы:
(config-pfr-mc-br)# interface FastEthernet1/0 internal
(config-pfr-mc-br)# interface FastEthernet0/0 external
(config-pfr-mc-br)# interface FastEthernet0/1 external

Конфигурируем бордера.

Входим в режим
pfr border

Включаем логгирование
logging

Указываем локальный интерфейс
local Loopback 0

Указываем на мастера
master 192.168.2.1 key-chain test

Вуаля, можем полюбоваться:

R1#sh pfr border

OER BR 192.168.2.1 ACTIVE, MC 192.168.2.1 UP/DOWN: UP 04:24:49,
Auth Failures: 0
Conn Status: SUCCESS
OER Netflow Status: ENABLED, PORT: 3949
Version: 3.0
MC Version: 3.0
Exits 
Fa0/0           EXTERNAL
Fa0/1           EXTERNAL
Fa1/0           INTERNAL

R1#sh pfr master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Version: 3.0
Number of Border routers: 1
Number of Exits: 2
Number of monitored prefixes: 0 (max 2500)
Max prefixes: total 2500 learn 2500
Prefix count: total 0, learn 0, cfg 0
PBR Requirements met
Nbar Status: Inactive
Border           Status   UP/DOWN             AuthFail  Version
192.168.2.1      ACTIVE   UP       04:27:16          0  3.0

 

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

Для начала настроим пропускную способность наших линков (а вернее бордерских), т.е. заходим в режим бордера и понеслось (в килобитах):

(config-pfr-mc)# border 192.168.2.1 key-chain test
(config-pfr-mc-br)# interface FastEthernet0/0 external
(config-pfr-mc-br-if)# max-xmit-utilization absolute 15
(config-pfr-mc-br)# interface FastEthernet0/1 external
(config-pfr-mc-br-if)# max-xmit-utilization absolute 60

В этой статье положимся на умение нашей кошки определять наиболее прожорливые сессии с помощью Netflow. Для этого включим автоопределение
learn

Теперь укажем, что именно хотим следить именно за пропускной
throughput

Указываем, как часто запускать поиск новых префиксов
periodic-interval 1

Далее указываем, с длинну итервала анализа трафика на наличие новых префиксов, в минутах (по дефолту 5)
monitor-period 2

Указываем, сколько хранить префиксы в базе (за память не бойтесь, есть заглушка), в минутах
expire after time 15

Указываем, как объединять маршруты (по дефолту — в сети /24, но мы же хотим fine tuning :), другие варианты рассмотрим в другой раз
aggregation-type prefix-length 32

Далее, конфигурируем backoff таймер (в секундах)
backoff 180 360

Этот таймер задает промежуточное время, в течение которого MC анализирует ООР-префикс. Фактически, он выжидает это время, прежде чем начать что-либо делать.

Формат такой:

backoff min-timer max-timer

• min-timer — минимальный период срабатывания. Если текущий префикс удовлетворяет политике, когда этот таймер истекает — ничего не делаем и таймер сбрасывается. Если данный префикс вне границ политики — PfR переместит префикс в  in-policy и опять-таки сбросит таймер.
• max-timer — максимальное время, в течение которого PfR удерживает ООР-префикс, когда нет ни одного PfR-контролируемого in-policy префикса. Если все PfR-контролируемые префиксы вне границ политики и этот таймер истекает, PfR  выберет наилучший доступный выход из AS и сбросит минимальный таймер.

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

Включаем автоизменение маршрутов
mode route control

Включаем выбор наилучшего (а не первого из находящихся в границах выхода)
mode select-exit best

Пересчитывать политики раз 3 минуты (для относительных значений)
periodic 180

И учитывать загрузку наших линков
resolve utilization priority 1 variance 1

Как это выглядит до вмешательства OER?

Для начала — наша таблица маршрутизации без вмешательства OER, в ней главное — два маршута к провайдерам.

R1#sh ip ro
Gateway of last resort is 172.16.2.2 to network 0.0.0.0
S*    0.0.0.0/0 [1/0] via 172.16.2.2
               [1/0] via 172.16.1.2

172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks

C        172.16.1.0/24 is directly connected, FastEthernet0/0
C        172.16.2.0/24 is directly connected, FastEthernet0/1

192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, FastEthernet1/0

192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, Loopback0

И настройка NAT:

ip nat inside source route-map ISP1 interface FastEthernet0/0 overload oer
ip nat inside source route-map ISP2 interface FastEthernet0/1 overload oer

Теперь еще рут-мапы, чтобы показать, что и как транслируем:

route-map ISP2 permit 10 
match ip address NAT
 match interface FastEthernet0/1

route-map ISP1 permit 10 
match ip address NAT
 match interface FastEthernet0/0

И ACL:

ip access-list extended NAT 
permit ip 192.168.1.0 0.0.0.255 any

 

Теперь как это выглядит после.

Запускаем пинги с двух хостов, которые нам создают трафик (поначалу оба потока почему-то сразу ушли одним путем… ну и ладно, не жалко):

*May  8 16:42:44.554: %OER_MC-5-NOTICE: Load OOP BR 192.168.2.1, i/f Fa0/1,  load 40 policy 25
*May  8 16:42:44.554: %OER_MC-5-NOTICE: Exit 192.168.2.1 intf Fa0/1 OOP, Tx BW 40, Rx BW 40, Tx Load 0, Rx Load 0
*May  8 16:42:50.566: %OER_BR-5-NOTICE: Prefix Learning STOPPED
*May  8 16:42:50.578: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
*May  8 16:43:18.162: %OER_MC-5-NOTICE: Discovered Exit for Prefix 2.2.2.2/32, BR 192.168.2.1, i/f Fa0/1
*May  8 16:43:18.166: %OER_MC-5-NOTICE: Discovered Exit for Prefix 1.1.1.1/32, BR 192.168.2.1, i/f Fa0/1

А вот и наши найденные префиксы:

R1#sh pfr master prefix

OER Prefix Statistics:
Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),
P - Percentage below threshold, Jit - Jitter (ms),
MOS - Mean Opinion Score
Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),
E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable
U - unknown, * - uncontrolled, + - control more specific, @ - active probe all
# - Prefix monitor mode is Special, & - Blackholed Prefix
% - Force Next-Hop, ^ - Prefix is denied
Prefix                  State     Time Curr BR         CurrI/F         Protocol

PasSDly  PasLDly   PasSUn   PasLUn  PasSLos  PasLLos
ActSDly  ActLDly   ActSUn   ActLUn      EBw      IBw
ActSJit  ActPMOS  ActSLos  ActLLos

-------------------------------------------------------------------------------------------

1.1.1.1/32              DEFAULT*      @57 192.168.2.1     Fa0/1           U
U        U        0        0        0        0
16       16        0        0       10        0
N        N

2.2.2.2/32              DEFAULT*      @57 192.168.2.1     Fa0/1           U
U        U        0        0        0        0
20       20        0        0       10        0
N        N

Еще немного подумав, OER вмешивается:

*May  8 16:44:21.290: %OER_MC-5-NOTICE: Route changed Prefix 2.2.2.2/32, BR 192.168.2.1, i/f Fa0/0, Reason Utilization, OOP Reason Utilization

R1#sh ip route
Gateway of last resort is 172.16.2.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 172.16.2.2  
                           [1/0] via 172.16.1.2

1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 172.16.2.2, FastEthernet0/1

2.0.0.0/32 is subnetted, 1 subnets
S        2.2.2.2 [1/0] via 172.16.1.2, FastEthernet0/0

Т.е. раскидал 🙂 умница! Новые потоки к этим адресам пойдут по новому пути. Вот.

В сухом остатке:

1. Мы задали пропускную способность одного линка в 15кбит/с, другого — в 60.
2. При превышении загрузки одного из каналов, OER узнает об этом и попытается переписать маршрут с целью переправить его через другой выход.
3. Т.к. у нас нат, существующие потоки будут уходить согласно трансляциям, остальные — согласно изменяемой таблице маршрутизации и традиционной балансировке.
4. Из п.3 следует и минус: если у нас долгоживущий прожорливый поток — балансировка будет плохо работать.
5. Но главный плюс — мы можем одновременно использовать обоих провайдеров в афффтоматическом режиме.

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

 

С уважением,

Илья

Метки: oer, pfr, маршрутизатор, маршрутизация
Опубликовано: Маршрутизаторы и коммутаторы