M-LAG как альтернатива STP и стека / Хабр

Общее описание схемы и подготовка underlay

В фабрике будет использоваться 2 Spine и 4 Leaf (2 из которых объединены в m-lag пару). Между Spine и Leaf коммутаторами используются point to point подсети с 31 маской и увеличен MTU. Используется симметричный IRB. Spine коммутаторы так же будут выполнять роль BGP route reflector. Инкапсуляция и деинкапсуляция будет производиться на Leaf коммутаторах.

Начну с настройки m-lag пары leaf коммутаторов, для правильной работы нужен keepalive линк и peer линк. По peer линку может идти полезная нагрузка поэтому необходимо учитывать полосу пропускания этого линка. Так же следует учитывать, что m-lag в исполнении Huawei накладывает некоторые ограничения, например нельзя построить ospf соседство через агрегированный интерфейс (или можно но с костылями):

dfs-group 1
 priority 150
 source ip 192.168.1.1 # IP адрес keepalive линка
#
stp bridge-address 0039-0039-0039 #для правильной работы STP задаем одинаковый bridge id
#
lacp m-lag system-id 0010-0011-0012 #задаем system id для LACP
#
interface Eth-Trunk0 #создаем peer линк
 trunkport INTERFACE #добавляем интерфейс в LAG 
 stp disable
 mode lacp-static
 peer-link 1
#
interface Eth-Trunk1 #пример агрегированного интерфейса в сторону сервера например 
 mode lacp-static
 dfs-group 1 m-lag 1

https://www.youtube.com/watch?v=KTUTc_C-1Ls

Проверяем, что m-lag пара собралась:

Пример настройки интерфейса внутри фабрики:

interface GE1/0/0
 undo portswitch  #переводим интерфейс в режим L3
 undo shutdown  #административно включаем интерфейс
 ip address 192.168.0.1 31
 ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point
 mtu 9200 #увеличиваем MTU интерфейса

В качестве underlay протокола маршрутизации используется OSPF:

ospf 1 router-id 10.1.1.11
 area 0.0.0.0
  network 10.1.1.1 0.0.0.0 #анонсируем anycast lo только с m-lag пары
  network 10.1.1.11 0.0.0.0
  network 192.168.0.0 0.0.255.255

Так же в качестве протокола маршрутизации можно использовать два BGP процесса, один для underlay маршрутизации и второй для overlay маршрутизации.

bgp AS_UNDERLAY #процесс для underlay маршрутизации
 <settings>
bgp AS_OVERLAY instance EVPN_NAME #процесс для overlay маршрутизации
 <settings>

С базовыми настройками закончили, проверим, что OSPF собрался и маршруты балансируются между Spine коммутаторами.

Соседство собралось, проверим маршрутную информацию:

M-lag как альтернатива stp и стека

Одними из основных проблем в сети являются «петли» и «единая точка отказа».

Традиционным способом победить «петли» является использование протокола STP. Но в то же время этот протокол приносит проблему неэффективного использования пропускной способности портов и линков коммутатора. При наличии нескольких возможных линков, активным будет один, все-равно, что купить домой крутой и дорогой компьютер для игры в пасьянс «Косынку» — не используется весь потенциал устройства. Низкая сходимость, особенно в сложных топологиях. А если в сети бегает голос или потоковое видео? Путь между двумя соседними коммутаторами может идти через корневой – не оптимально.

Традиционным способом уйти от «единой точки отказа» и сделать сеть отказоустойчивой является использование стека. Не поспоришь, вариант хорош, но все-равно возникает ряд вопросов: какое будет время сходимости при выходе из строя master-node? Хватит ли пропускной способности стека между коммутаторами (хотим больше скорость – платим больше)? Как себя будет вести стек при “split-brain”? Об этом под катом.

Эти проблемы и вопросы с успехом может решить технология Extreme Networks – M-LAG.

Справедливости ради стоит упомянуть о том, что подобные технологии есть и других производителей, но с некоторыми различиями. Также, часто используют комбинации, например: стек M-LAG.

В данной статье мы рассмотрим именно M-LAG от Extreme Networks как отдельную технологию.

M-LAG – Multi-Chassis Link Aggregation, модификация обычной аггрегации. Отличие и преимущество в том, что в данном случае линки начинаются на одном устройстве, а заканчиваются на двух, то есть резервирование не только линка как в LAG, но и резервирование устройства.

Со стороны Device1 настраивается обычный LAG, со стороны Device2 и Device3 все немного сложнее.

Давайте рассмотрим принцип работы M-LAG.

Между Device2 и Device3 должен быть линк на котором настраивается ISC (Inter-Switch Connection).
ISC покрывает несколько задач:

1. Поскольку со стороны Device1 настроен LAG, то в зависимости от алгоритма балансировки, пакеты могут передаваться разным коммутаторам. Поскольку это 2 разных коммутатора, data plane каждого работает самостоятельно – обеспечивается загрузка обоих линков. Но нам нужна синхронная и совместная работа control plane обоих устройств (синхронизация таблиц коммутации), для этого и нужен ISC (Inter-Switch Connection).

2. Из рисунка видно, что у нас организовалась «петля». ISC блокирует клиентский трафик при нормальной работе, если нет падений линка или отказа коммутаторов.

Также, стоит упомянуть особенность M-LAG: коммутаторы между которыми настраивается ISC должны быть одного производителя, мало того, строго рекомендуется чтоб эти коммутаторы были одного типа и серии, с одинаковой версией ExtremeXOS. К тому же желательно использовать коммутаторы с одинаковым количеством портов, например: Summit X460-24t & Summit X460-24x; BlackDiamond 8900-G48X-xl & BlackDiamond 8900-G48T-x. В то же время, нижестоящие или вышестоящие устройства, на которых настраивается LAG могут быть различных производителей.

Справедливости ради нужно указать, что на данный момент можно настроить 1 пир M-LAG, но в то же время количество M-LAG-ов для каждой пары коммутаторов может достигать 768.
M-LAG поддерживается всеми коммутаторами Extreme Networks за исключением L2 коммутаторов.

Это все относится к обычной работе M-LAG. Но что же происходит при появлении fault?

Рассмотрим несколько вариантов отказов:

1. Выход из строя одного из пары коммутаторов:

В этом случае все просто – весь трафик плавно утечет на линк между Device1 и Device3.

2. Выход из строя линка между Device2 и Device1

Тут открывается ISC и трафик перенаправляется через него. Для исключения данного отказа используется схема, когда на таких линках, например: между Device2 и Device1 настраивается LAG

3. Выход из строя ISC (так называемый split-brain)

В данном случае Device1 не будет знать об отказе ISC, Device2 и Device3 сохранят свои System Identifier, трафик от Device1 будет отправляться согласно алгоритма балансировки, а Device2 и Device3 будут направлять трафик согласно своих правил коммутации.
В то же время для исключения проблемы пропадания линка ISC на нем настраивается LAG:

Собрав стенд, мы можем посмотреть время сходимости при имитации отказов.

При экспериментировании:
1. Отключались линки между Summit X440-48t и X460-24x, X460-24t
2. Отключались линки между Summit X460-24p и X460-24x, X460-24t
3. Отключался линк ISC между X460-24x и X460-24t

Extreme Networks утверждает, что время сходимости:

Попробуем запустить PING от одного ПК к другому, при выставлении интервала ICMP Echo 50мс:

Видно, что время сходимости составляет не более 50 мс.

Причем, данные показаны при выходе из строя линка LAG, а при пропадании линка ISC — потерь пакетов вообще не наблюдалось.

Но мы не сдаемся и посмотрим при интервале ICMP Echo = 10мс:

При пропадании линка LAG время сходимости равно 40-70 мс, а при пропадании ISC потерь пакетов вновь не наблюдается.

На мой взгляд, результаты тестирования показали замечательные значения сходимости при отказах, да и получше STP.
Из чего делаем вывод: M-LAG отличная альтернатива устоявшимся технологиям STP и Стекирования, легок в конфигурировании, да и не требует дополнительного капиталовложения, не лицензируется, доступен в базовой лицензии ExtremeXOS.

Заключение:
Хотелось бы отметить, что M-LAG отличная технология, которая имеет огромный спектр применений, но она не является «пилюлей от всех болезней», поэтому применять можно в совокупности с тем же STP и стеком. Все зависит от топологии сети и задач которые ставятся перед ней. Также, есть перспективные, более интересные, на мой взгляд, решения, такие как TRILL (Transparent Interconnection of Lots of Links) или набирающий бешенной популярности SDN (Software-Defined Networking), но это уже отдельная тема для статьи. Да и коммутаторы Extreme Networks имеют поддержку данных технологий.

---

---

МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание

Подготовка l2 vxlan

Сперва создадим NVE интерфейс отвечающий за инкапсуляцию/деинкапсуляцию пакетиков:

interface Nve1 #создаем NVE интерфейс
 source 10.1.1.1 #для m-lag пары используем anycast ip адрес
 mac-address 0000-5e00-0199 #обязательно для m-lag пары на обоих коммутаторах настраиваем одинаковый MAC адрес, это необходимо для работы L3 VXLAN

Для организации L2 VXLAN необходимо создать bridge-domain и примапить к нему vlan, l2 подинтефейс или интерфейс целиком. К одному bridge-domain могут быть примаплены разные VLANs.

bridge-domain 150 #создаем bridge-domain
vlan 150 access-port interface Eth-Trunk12 #можно мапить vlan в конфигурации bridge-domain, а можно в создавать l2 подинтерфейс
 vxlan vni 22150 #определяем vni
 evpn #создаем evpn instance
  route-distinguisher 10.1.1.11:22150
  vpn-target 65000:22150 export-extcommunity
  vpn-target 65000:23500 export-extcommunity #этот rt нужен в будущем для L3 VXLAN
  vpn-target 65000:22150 import-extcommunity
#
interface GE1/0/9.150 mode l2 #создаем подинтерфейс
 encapsulation [default,dot1q,untag,qinq] #выбираем тип инкапсуляции
 bridge-domain 150 #мапим к нужному bridge-domain
#
interface Nve1 
 vni 22150 head-end peer-list protocol bgp #определяем, что для BUM трафика будет использоваться ingress replication list с автообнаружением по BGP

Проделываем такую же работу на остальных коммутаторах и проверяем работу. На коммутаторах должны появиться EVPN маршруты типа 3:

Посмотрим попристальнее на анонс полученный от соседа:

BUM трафик должен ходить, можно приступать к проверке связности между хостами. Для этого с хоста VM1 пропингуем хост VM2:

ubuntu@test-vxlan-01:~$ ping 192.168.50.3
PING 192.168.50.3 (192.168.50.3) 56(84) bytes of data.
64 bytes from 192.168.50.3: icmp_seq=1 ttl=64 time=0.291 ms
--- 192.168.50.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms
#
ubuntu@test-vxlan-01:~$ ip neigh
192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE

В это время на сети должны появиться анонсы 2 типа. Проверим:

Посмотрим анонс пристальнее:

Проверяем CAM таблицу коммутатора:

Подготовка l3 vxlan

Настало время выпустить хосты за пределы своей подсети, для этого будем использовать distributed gateway.

Для начала создадим нужный VRF:

ip vpn-instance EVPN
 ipv4-family
  route-distinguisher 10.1.1.11:23500
  vpn-target 65000: 23500 export-extcommunity evpn
  vpn-target 65000: 23500 import-extcommunity evpn
 vxlan vni 23500

В конфигурацию BGP Leaf коммутаторов добавляем анонс IRB:

bgp 65000
l2vpn-family evpn
  peer rr advertise irb

Создаем L3 интерфейс для маршрутизации в нужном VRF:

interface Vbdif150 #номер должен совпадать с номером bridge-domain
 ip binding vpn-instance EVPN
 ip address 192.168.50.254 24
 mac-address 0000-5e00-0101
 vxlan anycast-gateway enable
 arp collect host enable #генерация маршрута второго типа на основании arp записи

Повторяем конфигурации на других Leaf коммутаторах и проверяем:

На некоторых моделях коммутаторов (лучше свериться с официальной документацией) необходимо создание специального сервисного интерфейса для продвижения L3 VXLAN трафика. Полоса этого интерфейса должна быть в два раза больше пиковой полосы для L3 VXLAN трафика. При наличии большого количества Vbdif интерфейсов (более 2 тысяч) требуется создание дополнительных сервисных интерфейсов.

interface Eth-TrunkXXX
 service type tunnel
 trunkport 40GE1/1/1

На этом настройка L3 VXLAN завершена. Проверим доступность между хостами из разных подсетей:

ubuntu@test-vxlan-01:~$ ping 192.168.51.1
PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data.
64 bytes from 192.168.51.1: icmp_seq=1 ttl=63 time=0.508 ms

--- 192.168.51.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms

Связность есть, теперь проверим маршрутную информацию:

Появились маршруты второго типа включающие в себя IP адреса. Теперь проверим перетекли ли маршруты в нужный VRF:

Подготовка overlay

Для начала необходимо глобально включить поддержку EVPN на коммутаторе:

evpn-overlay enable

Spine коммутаторы выполняют роль Route-reflector. Плюс нужно добавить строку undo policy vpn-target в соответствующей address family, чтобы Spine смог принять все маршруты и переслать их клиентам. Соседство строим на loopback адресах.

bgp 65000
 group leafs internal
 peer leafs connect-interface LoopBack0
 peer 10.1.1.11 as-number 65000
 peer 10.1.1.11 group leafs
 peer 10.1.1.12 as-number 65000
 peer 10.1.1.12 group leafs
 peer 10.1.1.2 as-number 65000
 peer 10.1.1.2 group leafs
 peer 10.1.1.3 as-number 65000
 peer 10.1.1.3 group leafs
 #
 ipv4-family unicast
  undo peer leafs enable
  undo peer 10.1.1.11 enable
  undo peer 10.1.1.12 enable
  undo peer 10.1.1.2 enable
  undo peer 10.1.1.3 enable
 #
 l2vpn-family evpn
  undo policy vpn-target
  peer leafs enable
  peer leafs reflect-client
  peer 10.1.1.11 enable
  peer 10.1.1.11 group leafs
  peer 10.1.1.12 enable
  peer 10.1.1.12 group leafs
  peer 10.1.1.2 enable
  peer 10.1.1.2 group leafs
  peer 10.1.1.3 enable
  peer 10.1.1.3 group leafs

На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:

bgp 65000
 group rr internal
 peer rr connect-interface LoopBack0
 peer 10.1.1.100 as-number 65000
 peer 10.1.1.100 group rr
 peer 10.1.1.101 as-number 65000
 peer 10.1.1.101 group rr
 #
 ipv4-family unicast
  undo peer rr enable
  undo peer 10.1.1.100 enable
  undo peer 10.1.1.101 enable
 #
 l2vpn-family evpn
  policy vpn-target
  peer rr enable
  peer 10.1.1.100 enable
  peer 10.1.1.100 group rr
  peer 10.1.1.101 enable
  peer 10.1.1.101 group rr

Проверяем, что overlay control plane собрался:

Заключение

В данной статье я попытался описать процесс настройки EVPN VXLAN фабрики на базе оборудования Huawei и привести некоторые команды необходимые в процессе отладки.

Спасибо за внимание!