GLBP (Gateway Load Balancing Protocol)

Полностью взято c xgu.ru
Описание куда более живое и внятное.

GLBP (Gateway Load Balancing Protocol) — проприетарный протокол Cisco, предназначенный для увеличения доступности маршрутизаторов выполняющих роль шлюза по умолчанию и балансировки нагрузки между этими маршрутизаторами.

Описание протокола

GLBP работает аналогично, но не идентично другим протоколам резервирования шлюза, такими как HSRP и VRRP. Эти протоколы позволяют нескольким маршрутизаторам участвовать в сконфигурированной виртуальной группе маршрутизаторов с общим виртуальным IP-адресом. Один член группы выбирается активным маршрутизатором, в то время как другие остаются неактивными до тех пор, пока не произойдет сбой с активным маршрутизатором. При этом эти резервные маршрутизаторы обладают ресурсами, которые почти не используются в течение всего времени эксплуатации этой системы. GLBP обеспечивает распределение нагрузки на несколько маршрутизаторов (шлюзов) используя один виртуальный IP-адрес и несколько виртуальных MAC-адресов. Каждый хост сконфигурирован с одинаковым виртуальным IP-адресом и все маршрутизаторы в виртуальной группе участвуют в передаче пакетов.

Терминология протокола

Члены GLBP группы выбирают один шлюз который будет активным виртуальным шлюзом active virtual gateway (AVG) для этой группы. Другие члены группы обеспечивают резервирование для AVG в случае если AVG станет недоступным. AVG назначает виртуальный MAC адрес для каждого члена GLBP группы. Каждый член группы участвует в передаче пакетов, используя виртуальный MAC адрес, выданный AVG. Этих членов группы называют active virtual forwarders (AVFs). AVG ответственен за выдачу ответов по протоколу Address Resolution Protocol (ARP) на запросы к виртуальному IP-адресу. Распределение нагрузки достигается тем что AVG отвечает на ARP запросы используя разные виртуальные MAC-адреса.

На следующем рисунке маршрутизатор A является AVG для GLBP группы, и ответственен за виртуальный IP-адрес 10.24.0.1. Маршрутизатор A так же является AVF для виртуального MAC адреса 0007.b400.0204. Маршрутизатор B член той же GLBP группы и назначенный AVF для виртуального MAC адреса 0007.b400.0205. На клиентах устанавливается шлюз по умолчанию с IP-адресом 10.24.0.1 и MAC адресом шлюза 0007.b400.0204. В то время как на другом клиенте MAC-адрес шлюза по умолчанию будет 0007.b400.0205 и таким образом маршрутизатор A будет распределять нагрузку с маршрутизатором B.

В GLBP поддерживает до 4 маршрутизаторов в группе и до 1024 групп Взаимодействие между маршрутизаторами в групп.

Маршрутизаторы отправляют друг другу сообщения hello каждые 3 секунды. Сообщения отправляются на адрес 224.0.0.102, UDP порт 3222 (отправителя и получателя).

GLBP Gateway Priority

GLBP Gateway Priority определяет роль, которую каждый маршрутизатор AVF играет в группе. Т.е. с помощью этого свойства можно определить последовательность выбора нового AVG, если старый AVG станет недоступным. Приоритет можно определить на каждом маршрутизаторе значением от 1 до 255 командой: glbp priority. Маршрутизатор с большим приоритетом становиться AVG.

По умолчанию схема выбора AVG только на основе приоритета выключена. Запасной AVF станет AVG только если текущий AVG станет недоступным. Что бы разрешить выборы AVG на основе приоритета нужно ввести команду:
glbp preempt

Режимы балансировки нагрузки

GLBP поддерживает следующие режимы балансировки нагрузки:

None - режим, при котором коммутатор не обеспечивает балансировку нагрузки. На все запросы клиентов он отвечает своим МАК адресом. Второй коммутатор начинает работу только после того как основной коммутатор (AVG) выйдет из строя или станет недоступным.

Weighted load-balancing - балансировка нагрузки производится в соответствии с весом каждого коммутатора. Вес коммутатора назначается инженером на каждом коммутаторе отдельно. Например если в GLBP группе два коммутатора, у AVG вес 70 а у AVF 140, то нагрузка будет распределяться 1:2. Другими словами из трех полученный запросов на MAC-адрес AVG один раз ответит своим MAC-адресом и дважды MAC-адресом AVF коммутатора.

Host-dependent load-balancing - этот режим используется в случае если есть необходимость в реализации трансляции адресов Network Address Translation (NAT), так как этот режим гарантирует возвращение клиенту того же MAC-адреса AVF коммутатора который он использовал ранее и следовательно NAT сессия у клиента не прерывается. Клиенты будут получать те же MAC-адреса AVF до тех пор, пока количество коммутаторов в GLBP группе не изменится.

Round-robin load-balancing -- режим используется по умолчанию. В этом режиме AVG выдает MAC-адреса AVF попеременно.


Необходимо отметить, что все методы реализуют балансировку количества хостов на один узел, а не трафика.

Источник: Cisco GLBP Load Balancing Options (англ.)

Настройка на маршрутизаторах Cisco

Включение GLBP на интерфейсе

glbp <group> ip [ip-address [secondary]]

 Режим preempt

В GLBP есть два режима preempt:
для AVG -- по умолчанию отключен,
для AVF -- по умолчанию включен, с задержкой 30 секунд.

По умолчанию режим preempt для AVG отключен. То есть, backup virtual gateway может стать AVG только если текущий AVG выйдет из строя.

Включение режима preempt для AVG:

dyn1(config-if)# glbp 1 preempt

Включение режима preempt для AVF:

dyn1(config-if)# glbp 1 forwarder preempt [delay minimum <seconds>]

Балансировка нагрузки между маршрутизаторами

Настройка метода балансировки нагрузки между маршрутизаторами (по умолчанию round-robin):

dyn1(config-if)# glbp 1 load-balancing <host-dependent | round-robin | weighted>

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

dyn1(config-if)# glbp 1 load-balancing host-dependent

Отключение балансировки нагрузки: 

dyn1(config-if)# no glbp 1 load-balancing

Настройка таймеров

Настройка интервала между отправкой AVG сообщений hello в группе GLBP: 

dyn1(config-if)# glbp <group> timers [msec] <hellotime> [msec] <holdtime>
dyn1(config-if)# glbp <group> timers redirect <redirect> <timeout>

Параметры команды:
redirect -- настраивает интервал в течении которого AVG продолжает перенаправлять клиентов AVF. По умолчанию 600 секунд (10 минут).
timeout -- указывает интервал в секундах до того как secondary virtual forwarder станет invalid. По умолчанию 14,400 секунд (4 часа).



Хотя диапазон значений параметра redirect позволяет использовать значение 0, фактически оно не должно использоваться. Это приведет к тому, что таймер redirect никогда не истечет и, в случае выхода из строя маршрутизатора, хосты всё равно будут отправляться на него.

Object Tracking 

dyn1(config)# track 1 interface FastEthernet1/0 line-protocol

Указание объекта, который будет влиять на вес GLBP, если интерфейс выключается, то вес уменьшается на 11 (по умолчанию на 10): 

dyn1(config-if)# glbp 1 weighting track 1 decrement 11

Настройка пороговых значений веса, которые регулируют будет ли маршрутизатор выполнять роль GLBP gateway. Для данного примера, начальное значение 200. Если интерфейс fa1/0 выключается, то значение становится 189. Так как оно меньше, чем значение lower, то маршрутизатор не может выполнять роль active forwarder. Когда интерфейс включится, то значение станет снова 200. Так как это больше чем значение upper, то маршрутизатор снова становится active forwarder:

dyn1(config-if)# glbp 1 weighting 200 lower 192 upper 195

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

GLBP Client Cache

По умолчанию функция GLBP Client Cache отключена. После включения функции AVG начинает сохранять у себя информацию о том какие хосты используют какой gateway.

Включение GLBP Client Cache: 
dyn1(config-if)# glbp 1 client-cache

Просмотр информации о GLBP Client Cache (хранится только на AVG): 
dyn1# show glbp detail

Просмотр информации

Просмотр краткой информации о группах: 

dyn1# show glbp brief 
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Fa0/0       1    -   200 Active   192.168.1.100   local           192.168.1.3
Fa0/0       1    1   -   Active   0007.b400.0101  local           -
Fa0/0       1    2   -   Listen   0007.b400.0102  192.168.1.3     -

Просмотр информации о всех включенных группах GLBP:

dyn1# show glbp
FastEthernet0/0 - Group 1
  State is Active
    2 state changes, last state change 08:46:44
  Virtual IP address is 192.168.1.100
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 1.136 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Authentication text "Cisco"
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 192.168.1.3, priority 100 (expires in 9.948 sec)
  Priority 200 (configured)
  Weighting 200 (configured 200), thresholds: lower 190, upper 195
    Track object 1 state Up decrement 6
  Load balancing: host-dependent
  Group members:
    0016.3e01.0001 (192.168.1.1) local
    0016.3e01.0201 (192.168.1.3)
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 08:46:34
    MAC address is 0007.b400.0101 (default)
    Owner ID is 0016.3e01.0001
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 200
  Forwarder 2
    State is Listen
      2 state changes, last state change 08:42:08
    MAC address is 0007.b400.0102 (learnt)
    Owner ID is 0016.3e01.0201
    Redirection enabled, 599.036 sec remaining (maximum 600 sec)
    Time to live: 14399.036 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 192.168.1.3 (primary), weighting 100 (expires in 9.032 sec)

VRRP (Virtual Router Redundancy Protocol)

 
VRRP differs from HSRP in the following ways:

• VRRP is an IEEE standard (RFC 2338) for router redundancy; HSRP is a Cisco-proprietary protocol.
• The virtual router represents a group of routers, known as a VRRP group or virtual router group.
• The active router is referred to as the master virtual router.
• The master virtual router may have the same IP address as the virtual router group.
• Multiple routers can function as backup routers.
• VRRP is supported on Ethernet, Fast Ethernet, and Gigabit Ethernet interfaces, and with Multiprotocol Label Switching (MPLS), virtual private networks (VPNs), and VLANs. 

HSRP (Hot Standby Router Protocol)

Включение HSRP на интерфейсе

Создание групп и назначение виртуальных IP-адресов на маршрутизаторах (включение HSRP): 

R1(config-if)# standby [group-number] ip [ip-address [secondary]]

Если не указывать номер группы в команде standby ip, то будет использоваться номер 0.
 
В HSRP существует ещё большое количество настроек, которые могут быть выполнены после включения HSRP на интерфейсе. Однако, рекомендуется сначала выполнить все настройки (например, аутентификация, таймеры), а затем включить HSRP на интерфейсе.
Пример настройки двух групп для R1 и R3 
(настройки одинаковые на обоих маршрутизаторах): 
R1(config)# int fa0/0 
R1(config-if)# standby 1 ip 192.168.1.11 
R1(config-if)# standby 3 ip 192.168.1.33

Хотя, для того чтобы HSRP работал достаточно указать виртуальный IP-адрес только на одном маршрутизаторе, Cisco рекомендует указывать адрес на всех маршрутизаторах.


URL:
http://xgu.ru/wiki/HSRP_в_Cisco

18:13:22.743: %AMDP2_FE-6-EXCESSCOLL: Ethernet1/1 TDR=0, TRC=0

logging discriminator EXCESS severity drops 6 msg-body drops EXCESSCOLL
logging buffered 50000
logging console discriminator EXCESS

EtherChannel

В самом курсе всё очень вяло и тухло в силу давности, так что обратимся, как всегда, к статье на xgu.ru

========================================================================

Проверка настройки:

sw1# sh etherchannel summary

sw1# sh etherchannel port-channel 

========================================================================

Проверка настройки:

sw1# sh etherchannel summary

sw1# sh etherchannel port-channel 
sw2# sh etherchannel port-channel

sw1# sh lacp 1 internal

sw1# sh lacp 1 neighbor

sw1# sh lacp sys-id 

=================================================================================

Проверка настройки:
sw1# sh etherchannel summary 
sw1# sh etherchannel port-channel
sw2# sh etherchannel port-channel
sw1# sh pagp internal 

sw1# sh pagp counters

==================================================

 



sw1# show etherchannel summary

========================================================================

MSTP

UPD. Проверка закончена данные актуальны.

Наконец-то дошлёпали до MSTP.
С чего всё начиналось или зачем было вставать с дивана:
Вначале появились петли коммутации. Чтобы с ними бороться был придуман STP, и всё в нём вроде было хорошо, один инстанс на все вланы, процессор не грузит, но балансировку не сделать. 

Захотели балансировку, придумали PVST ( тогда ещё под ISL ) , затем допилили под PVST+ и Rapid PVST+ ( под 802.1q транки) и вроде опять всё хорошо, дали каждому влану по инстансу и вроде как успокоились пока не завели 500 вланов и сеть загнулась от нагрузки просчёта 500 инстансов.

Опять пришлось вставать с дивана и придумать MSTP. Теперь в его основу заложили работу с инстансами(логическими топологиями) и привязке вланов к инстансам для балансировки. И вроде всё стало хорошо, мало инстансов -- меньше нагрузка на процессор, ещё и балансировку можно сделать, но региональную балансировку -- нельзя, ждём продолжения

Несколько базовых концептов и тезисов:
1) Первичны при настройке MSTP -- инстансы. Затем вланы привязаывают к инстансам.
2) boundary switch -- свитч которые имеет boundary порты, т.е. находящийся на границе региона и имеющий связь с другими(м) регионами(ом)
3) Инстанс 0 создаётся по-умолчанию, к нему приписаны все вланы, в нём же гоняют BPDU-шки и он же связывает регионы.
4) Внутренние инстансы у каждого региона свои, они ими между регионами не обмениваются.
5) Revision не меняется при изменении в инстансе

 

По поводу выборов  Regional Root, возникло тонны непоняток, тезисы противопоставления такие:

Тезис Первый: Regional Root  выбирается только из Boundary Switch

утверждают несколько документов и людей, в различных документах, основной авторитет у нас вот этот вебинар 

http://www.youtube.com/watch?v=J7j2iNG77PM

автор: Руслан Савченко, Учебный центр IBA, CCNP-шник, вроде как авторитетное тело и оснований верить не было, я поверил, до тех пока не собрал топологию, я ж никогда на слово в таких вещах не верю. Топология показала, что работает правило ближайшего свитча, т.е. как ни старался, CIST Root инстанса ноль всегда становился Regional Root для этого региона, и циске был совершенно плевать на наличие или отсутствие boundary портов у этого свитча. По полученным данным включился гугл и пару дней изучения различных источников по MSTP ( порой, мне кажется, что я перебрал все корневые внятные источники, не считая кучи копипастов ), отсюда пришёл второй тезис.

Тезис Второй: Regional Root instance 0 выбирается из любого свитча по правилу ближайщего по цене. Что равносильно выражению: CIST Root instance 0 всегда будет CIST Regional Root.

Источники:

 https://community.extremenetworks.com/extreme/topics/about_mstp_802_1s_configuration

CIST Regional Root 

The MSTB in each Region having the lowest path cost to the CST Root.

и primary источник с офф сайт циско

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/CLIConfigurationGuide/MST.pdf

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

If the CIST root is in the region, the CIST regional root is the CIST root. Otherwise, the CIST regional root is the closest switch to the CIST root in the region. The CIST regional root acts as a root bridge for the IST.

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

дословный перевод: 
Если CIST Root находится в регионе, CIST Regional Root это CIST Root.
В противном случае, CIST Regional Root ближайший boundary свитч к CIST Root в текущем регионе.
Именно так,  во втором случае будет именно boundary, хотя в оригинале текста это слово отсутствует. 
Вот теперь сошлось. Причём по всем пунктам.

Лирическое отступление:
1) Все эти жертвы были бы ненужны, если бы в открытом доступе имелась актуальная документация по стандарту IEEE 802.1s ( >> 802.1Q)
2) http://habrahabr.ru/post/195596/ что делают эти товарищи вообще непонятно ни разу, отсутствует логические разделы: а) задача б) реализация в) рассуждения и выводы, отсуствует графическая топология сети, ни одного конфига и show, херня короче какая-то, только зря время потерял.