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 соседство через агрегированный интерфейс (или можно но с костылями):

<code>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</code>

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

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

<code>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 интерфейса</code>

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

<code>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</code>

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше про Хуавей:  Huawei Pay в России получил поддержку новых смартфонов. Как платить -

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

M-LAG как альтернатива STP и стека / Хабр
Со стороны 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. Выход из строя одного из пары коммутаторов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше про Хуавей:  Huawei P30 Lite 128 ГБ / 4 ГБ – купить мобильный телефон, сравнение цен интернет-магазинов: фото, характеристики, описание | E-Katalog

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

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



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

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

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

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

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

<code>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</code>

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

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

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

<code>[email protected]:~$ 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
#
[email protected]:~$ ip neigh
192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE</code>

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

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

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

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

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

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

<code>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</code>

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

<code>bgp 65000
l2vpn-family evpn
  peer rr advertise irb</code>

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

<code>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 записи</code>

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

Больше про Хуавей:  Не устанавливается Ватсап: что делать - WhatsApp Messenger

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

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

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

<code>[email protected]:~$ 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</code>

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

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

Подготовка overlay

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

<code>evpn-overlay enable</code>

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

<code>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</code>

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

<code>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</code>

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

Заключение

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

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

1 Звездаслабоватона троечкухорошо!просто отлично! (1 оценок, среднее: 5,00 из 5)
Загрузка...

Расскажите нам ваше мнение:

Ваш адрес email не будет опубликован. Обязательные поля помечены *