В данной статье разберем примеры настройки балансировки трафика в агрегирующих интерфейсах (bundle-ether) и ECMP, а также рассмотрим применение FAT метки.
В качестве примера будем использовать следующую схему включения, изображенную на рисунке 1.
Рисунок 1 — Схема включения
На рисунке 1 изображены две AS 64500 и AS 64501, где в AS 64500 настроено следующее:
1. Адресация на интерфейсах
2. ISIS
3. IBGP
4. EBGP
5. MPLS LDP
6. Заведены и анонсированы сети: 192.168.16.0/24 и 11.1.0.0/24
В AS 64500 настроен EBGP, где заведены, а также анонсированы сети: 192.168.17.0/24 и 10.3.0.0/24.
Таким образом, маршрутизатор R3 получает следующую маршрутную информацию по BGP:
0/ME5100:R3# show bgp Mon Jul 10 15:57:41 2023 BGP router identifier 3.3.3.3, local AS number 64500 Graceful Restart is disabled BGP table state: active BGP scan interval: 120 secs Status codes: d damped, h history, > best, b backup, S stale, * active, u untracked, i internal Origin codes: i igp, e egp, ? incomplete Network Next hop Metric LocPrf Weight Path ------------------------ ---------------- ------- ------- ------- ----- *>i 10.3.0.0/24 2.2.2.2 0 100 0 64501 i * i 10.3.0.0/24 5.5.5.5 0 100 0 64501 i > 11.1.0.0/24 0 100 32768 i > 192.168.16.0/24 0 100 32768 i *>i 192.168.17.0/24 2.2.2.2 0 100 0 64501 i * i 192.168.17.0/24 5.5.5.5 0 100 0 64501 i Total entries: 6
Маршрутизатор R4:
0/ME5200:R4# show bgp Mon Jul 10 15:59:29 2023 BGP router identifier 4.4.4.4, local AS number 64501 Graceful Restart is disabled BGP table state: active BGP scan interval: 120 secs Status codes: d damped, h history, > best, b backup, S stale, * active, u untracked, i internal Origin codes: i igp, e egp, ? incomplete Network Next hop Metric LocPrf Weight Path ------------------------ ---------------- ------- ------- ------- ----- > 10.3.0.0/24 0 100 32768 i * 11.1.0.0/24 10.0.0.6 0 100 0 64500 i *> 11.1.0.0/24 10.0.0.4 0 100 0 64500 i *> 192.168.16.0/24 10.0.0.6 0 100 0 64500 i * 192.168.16.0/24 10.0.0.4 0 100 0 64500 i > 192.168.17.0/24 0 100 32768 i Total entries: 6
Сначала рассмотрим балансировку ECMP (Equal Cost Multiple Paths).
Данный функционал позволяет передавать пакеты одному получателю по нескольким лучшим маршрутам, что позволяет распределить нагрузку по нескольким путям. ECMP может работать как с статическими маршрутами, так и с протоколами динамической маршрутизации (ISIS, OSPF. BGP).
Для того чтобы учитывались ECMP маршруты в GRT, необходимо включить: «router equal-cost», а если в vrf, то необходимо указать имя vrf: «router equal-cost vrf <vrf_name>».
Из вывода выше (show bgp), а также по схеме включения, видно, что маршрутизатор R3 или R4 узнает о маршрутах от двух разных маршрутизаторов:
0/ME5100:R3# show bgp ipv4 unicast 192.168.17.0/24
Fri Jul 7 14:10:45 2023
BGP router identifier 3.3.3.3, local AS number 64500
BGP routing table entry for 192.168.17.0/24
Path #0
AS path: 64501
2.2.2.2 from 2.2.2.2 (2.2.2.2)
Origin igp, metric 0, local-pref 100, weight 0, active, internal, best
Address family: ipv4/unicast
NLRI pathID: 0
Aggregator AS: 0, Address: 0.0.0.0, Atomic aggregate: absent
Is not stale, is not history
Route flap penalty: 0, flap count 0, is not suppressed
Route flap time left: 00:00:00, time start: never
Route is ECMP <=====================
Path #1
AS path: 64501
5.5.5.5 from 5.5.5.5 (5.5.5.5)
Origin igp, metric 0, local-pref 100, weight 0, active, internal
Address family: ipv4/unicast
NLRI pathID: 0
Aggregator AS: 0, Address: 0.0.0.0, Atomic aggregate: absent
Is not stale, is not history
Route flap penalty: 0, flap count 0, is not suppressed
Route flap time left: 00:00:00, time start: never
Route is ECMP <=====================
Total entries: 2
В выводе данной команды мы видим, что маршрут был получен от двух разных маршрутизаторов и эти маршруты являются равнозначными (Одинаковый: weight, local pref, as path и т.д.). Так как данные маршруты являются равнозначными, то они будут помечены как ECMP. Также можем увидеть эту информацию при просмотре маршрута:
0/ME5100:R3# show route 192.168.17.1
Fri Jul 7 14:14:56 2023
Routing entry for 192.168.17.0/24
Last update: 04h11m59s
Routing Descriptor Blocks
10.0.0.3, via te0/0/2.302
Known via bgp, distance 200, metric 0
type bgp-internal, protection ecmp, route-type remote
Routing entry for 192.168.17.0/24
Last update: 04h11m59s
Routing Descriptor Blocks
10.0.0.1, via te0/0/5.305
Known via bgp, distance 200, metric 0
type bgp-internal, protection ecmp, route-type remote
Entries: 2
Проверим forwarding, в какие интерфейсы будет направлен трафик:
0/ME5100:R3# show l3forwarding 192.168.17.1
Fri Jul 7 17:22:44 2023
Subnet: 192.168.17.0/24 Nexthop: 10.0.0.3
Interface: Tengigabitethernet0/0/2.302
Src MAC: e0:d9:e3:ff:62:02
Dst MAC: e0:d9:e3:ff:60:c3
Outer VID: 302 Inner VID: 0
MTU: 1500
Outgoing label: --
HW information:
FEC: 0x2000040a, ECMP FEC: 0x20000001, encap-id: 0x4000200c
Subnet: 192.168.17.0/24 Nexthop: 10.0.0.1
Interface: Tengigabitethernet0/0/5.305
Src MAC: e0:d9:e3:ff:62:05
Dst MAC: e0:d9:e3:ff:48:03
Outer VID: 305 Inner VID: 0
MTU: 1500
Outgoing label: --
HW information:
FEC: 0x20000409, ECMP FEC: 0x20000001, encap-id: 0x4000200a
0/ME5100:R3#
Исходя из этого, нам необходимо обеспечить балансировку трафика между интерфейсами ten0/0/2 и ten0/0/5, для этого нам необходимо определиться с типом трафика, проходящего через маршрутизаторы. В качестве примера будет генерироваться на интерфейс ten0/0/20 следующий тип трафика:
UDP, 10 Mbit, 10 потоков.
TCP, 10 Mbit, 10 потоков.
Учитывая выше сказанное, мы укажем следующие поля для учета при балансировки трафика:
load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields port-dst load-balancing hash-fields port-src
Запустим трафик в два направление между маршрутизаторами R3 и R4.
0/ME5100:R3# show interfaces utilization Mon Jul 10 13:28:59 2023 Interface Period, s Sent, Kbit/s Recv, Kbit/s Frames sent, pps Frames recv, pps ---------------- ---------- ------------- ------------- ----------------- ----------------- ... te0/0/2 20 2501 4993 233 456 te0/0/5 20 7486 4994 679 456 te0/0/20 20 10001 10001 892 892 ... 0/ME5100:R3#
Мы видим, что исходящий трафик балансируется между интерфейсами te0/0/2 и te0/0/5, но не равномерно. В таком случае необходимо задать дополнительные значения для вычисления hash. Укажем, на какое количество бит сместить результат hash, например: «load-balancing ecmp shift 3», данное число было взято эмпирическим путем, так как зависит от входящего трафика. Проверяем балансировку:
0/ME5100:R3# show interfaces utilization Mon Jul 10 13:48:45 2023 Interface Period, s Sent, Kbit/s Recv, Kbit/s Frames sent, pps Frames recv, pps ---------------- ---------- ------------- ------------- ----------------- ----------------- ... te0/0/2 20 4993 4993 456 456 te0/0/5 20 4994 4993 456 456 te0/0/20 20 10000 10000 892 892 ... 0/ME5100:R3#
Входящий трафик на интерфейсах te0/0/2 и te0/0/5, был заранее разбалансирован на маршрутизаторе R4, аналогичным образом.
Итого были выставлены следующие поля:
load-balancing ecmp shift 3 load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields port-dst load-balancing hash-fields port-src
Для достижения равномерного распределения трафика между интерфейсами, также можно использовать дополнительный параметр: «load-balancing ecmp seed <number>», которая указывает начальное значение для генерации ключа.
Теперь рассмотрим пример балансировки агрегирующих интерфейсов (bundle-ether) между маршрутизаторами R2 и R4.
Учитывая ранее настроенную балансировку ECMP, трафик будет распределен между маршрутизаторами R5 и R2, как изображено на рисунке 2.
Рисунок 2 - Распределение трафика
Смотреть загрузку будем на интерфейсах ten0/0/4 и ten0/0/6 маршрутизатора R2. Настройка интерфейса lacp bundle-ether 1:
lacp
interface bundle-ether 1
exit
interface tengigabitethernet 0/0/4 <===============
bundle id 1
bundle mode active
exit
interface tengigabitethernet 0/0/6 <===============
bundle id 1
bundle mode active
exit
Запускаем трафик и проверяем загрузку по интерфейсам:
0/ME5100:R2# show interfaces utilization | include 0/0/4|0/0/6 te0/0/4 20 4986 3142 446 281 te0/0/6 20 0 1844 0 165
Добавляем поля для учета балансировки :
load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields port-dst load-balancing hash-fields port-src
Снова проверяем балансировку на bundle-ether 1 :
0/ME5100:R2# show interfaces utilization | include 0/0/4|0/0/6 Mon Jul 10 13:58:53 2023 te0/0/4 20 3491 3142 312 281 te0/0/6 20 1495 1843 133 165
Как видно, часть трафика получилось разбалансировать, но не весь. Чтобы добиться баланса между двумя интерфейсами te0/0/4 и te0/0/6, также добавим дополнительные параметры для расчета hash. Аналогичным образом настроим балансировку на маршрутизаторе R4.
Добавили следующий параметр: load-balancing lag shift 5
После внесения изменений, проверяем нагрузку между интерфейсами:
0/ME5100:R2# show interfaces utilization | include 0/0/4|0/0/6 Mon Jul 10 17:00:50 2023 te0/0/4 20 2445 2542 218 227 te0/0/6 20 2541 2442 227 218 0/ME5100:R2#
Итого использовались следующие поля:
load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields port-dst load-balancing hash-fields port-src load-balancing lag shift 5
Также для дополнительного расчета hash функции, можно учитывать агрегированные линки, используемая команда: «load-balancing lag in-port».
В дополнение рассмотрим балансировку трафика при помощи FAT метки (Flow Aware Transport of psewdowires).
Для этого поднимем сервис L2VPN между маршрутизаторами R3 и R2, как изображено на рисунке 3.
Рисунок 3 — Схема организации L2VPN
На маршрутизаторе R3 настроим xconnect:
pw-class kv_test
encapsulation mpls signaling-type pseudowire-id-fec-signaling
exit
xconnect-group pw_kv_test
p2p kv_test_2203201
interface tengigabitethernet 0/0/20.2203201
pw 2.2.2.2 2203201
pw-class kv_test
exit
exit
exit
Аналогично на R2:
pw-class kv_test
encapsulation mpls signaling-type pseudowire-id-fec-signaling
exit
xconnect-group kv_test_group
p2p pw_kv_test
interface bundle-ether 1.2204400
pw 3.3.3.3 2203201
pw-class kv_test
exit
exit
exit
Используем ранее настроенные поля load-balancing:
load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields port-dst load-balancing hash-fields port-src load-balancing lag in-port load-balancing lag shift 5
Генерируем трафик: однонаправленный, 10 Mbit, IPv4,10 потоков.
Проверяем балансировку:
0/ME5100:R2# show interfaces utilization | include 0/0/4|0/0/6 Fri Jul 14 11:31:40 2023 te0/0/4 20 1 0 0 0 te0/0/6 20 10000 0 9766 0 0/ME5100:R2#
Причиной отсутствия балансировки трафика является то, что решение по распределению трафика между интерфейсами принимается на основе входящего трафика. В нашем случае на вход интерфейса te0/0/3 маршрутизатора R2, приходит трафик MPLS без транспортной метки, но с сервисной меткой. Для того чтобы разбалансировать данный трафик, необходимо добавить поле labels: load-balancing hash-fields mpls labels.
Однако сервисная метка одна и распределить трафик на основе одной метки не получится. Для того чтобы разложить трафик по интерфейсам, необходимо добавить ещё одну метку. Для этого будем использовать FAT метку.
Добавим FAT метку на R3:
xconnect-group pw_kv_test
p2p kv_test_2203201
pw 2.2.2.2 2203201
fat both
exit
exit
exit
Маршрутизатор R2:
xconnect-group kv_test_group
p2p pw_kv_test
pw 3.3.3.3 2203201
fat both
exit
exit
exit
Проверяем балансировку:
0/ME5100:R2# show interfaces utilization | include 0/0/4|0/0/6 Fri Jul 14 11:48:51 2023 te0/0/4 20 5002 0 4883 0 te0/0/6 20 5000 0 4883 0 0/ME5100:R2#
В результате видим равномерное распределение трафика.
Использовались следующие поля:
load-balancing hash-fields ip-dst load-balancing hash-fields ip-src load-balancing hash-fields mpls labels load-balancing hash-fields port-dst load-balancing hash-fields port-src load-balancing lag in-port load-balancing lag shift 5