Load-balancing
Описание load-balancing
Load balancing между равнозначными линками дает возможность передавать трафик к одному и тому же dest address сразу по двум ликам, распределяю нагрузку между ними.
Балансировка может быть настроена одним из методов: per-packet или per-flow.
PER-PACKET
Пакеты передаются в произвольном порядке (round-robin) по равнозначным (с одинаковой стоимостью) путям. При этом равнозначные линки загружаются равномерно. Но создается дополнительная нагрузка на сеть: в процессе передачи пакетов, к хосту назначения пакеты могут прийти в неверном порядке, что приводит к тому, что хост назначения должен заниматься реордерингом пакетов, либо хост источник должен будет пересылать заново потерянные пакеты. Всё это - дополнительная нагрузка на сеть.
PER-FLOW
Индивидуальные потоки трафика передаются по одному или второму линку. При этом уходит проблема с реордерингом пакетов >> на application level меньше зажержек. Также становится возможным эффективное внедрение QOS, т.к. на сети одинаковый пользовательский трафик будет гулять потоками.
По умолчанию поток (flow) - это трафик, имеющий один вх интерфейс, одинаковый src и dst address, а также одинаковый протокол. Можно включить дополнительные элементы 3 и 4 уровня, но это требует доп конфигурации.
Для распознавания потока по параметрам 3/4 уровней, настраиваем hash-key:
set forwarding-options hash-key family inet layer-3 set forwarding-options hash-key family inet layer-4 set forwarding-options hash-key family mpls label-1 set forwarding-options hash-key family mpls label-2 set forwarding-options hash-key family mpls payload ip set forwarding-options hash-key family multiservice source-mac set forwarding-options hash-key family multiservice destination-mac set forwarding-options hash-key family multiservice payload ip layer-3
Для IP обязательно указывать l3 и l4. Иначе не будет работать ни l3, ни l4. Для ipv6 load-balancing по дефолту делается по l3 и l4, так что дополнительной настойки не требует. Для mpls [family mpls] и vpls [family multiservice] также можно поменять дефолтные hash-key.
IGP load-balancing: выбирается один возможный путь к адресу назначения. Даже есть есть обходные пути. Когда добавляются или удаляются возможные next-hop - junos заново делает выбор пути.
BGP load-balancing = per-prefix load balancing: включается в случае, когда у маршруты получены от IBGP соседа с одинаковым next-hop. Далее роутер резолвит next-hop и в случает, если до него есть несколько путей, трафик до него пойдет по рандомно-выбранным путям. Но при этом трафик до каждого префикса будет следовать только по одному выбранному пути.
То есть если от ibgp-пира прилетело 20 префиксов, где в качестве hext-hop стоит ip ibgp-пира: рандомным образом (используя hashing алгоритм) трафик до ibgp-пира будет выбран одним из путей. То есть для 15-ти префиксов трафик до ibgp-пира пойдет одним путем, для 5ти - другим. (или 10/10, то есть из-за рандомности может возникнуть вариант распределения 20/0 - тогда ни о какой балансировке речи и не идёт). Поэтому погалаться полностью на дефолтное поведение не стоило бы.
Конфигурация
Настраиваем политику и применяем ее. В политике можно указать конкретные префиксы, в сторону которых будет балансироваться трафик. Либо если не будет конкретики по префиксам, то баланситься будет весь трафик.
set policy-options policy-statement load-balance then load-balance per-packet set routing-options forwarding-table export load-balance
Несмотря на то, что в конфиге задаем load-balance per-packet, но всех современных роутерах это равнозначно per-flow. Балансировка будет работать per=flow! Только для роутерах в процессором Internet Processor I ASIC реально будет per-packet
Мониторинг
До применения:
> show route forwarding-table vpn mgmt destination 10.11.0.72/29
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs,
Destination Type RtRef Next hop Type Index NhRef Netif
10.11.0.72/29 user 0 indr 1052491 22
ulst 1051444 2
212.1.241.53 Push 35 11727 2 xe-1/0/4.10
После применения:
> show route forwarding-table vpn mgmt destination 10.11.0.72/29
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs,
Destination Type RtRef Next hop Type Index NhRef Netif
10.11.0.72/29 user 0 indr 1052491 22
212.1.240.179 Push 35, Push 933692(top) 12775 2 ae26.910
212.1.241.53 Push 35 11727 2 xe-1/0/4.10
Примененные изменения в load-balancing можно увидеть только в forwarding-table! В routing-table всё будет как прежде.
ulst - это список unicast ip next-hop. Пакеты, посленнаые к этому next-hop, отправляются к любому из next-hop в листе.
Filter-based forwarding
При этом методе балансировки на выбор пути будет влиять не только dst адрес, что делает данный тип балансировки более гибким. С помощью firewall filter пакеты классифицируются и для них определяется путь в рамках данного роутера.
Поддерживается для IPv4 и IPv6.
Можем пустить трафик от src address 10.10.0.0/24 до dst address 1.1.1.1/32 через одного ISP2, а трафик от src address 10.10.1.0/24 до dst address 1.1.1.1/32 через второго ISP2.
Конфигурация
R1: Добавляем и применяем фильтр:
set family inet filter regions-to-cdn term match-region-1 from source-address 10.10.0.0/24 set family inet filter regions-to-cdn term match-region-1 then routing-instance ISP-1 set family inet filter regions-to-cdn term match-region-2 from source-address 10.10.1.0/24 set family inet filter regions-to-cdn term match-region-2 then routing-instance ISP-2 set family inet filter regions-to-cdn term all-accept then accept set interfaces xe-0/0/0 unit 0 family inet filter input regions-to-cdn
Последний терм добавляем, чтобы остальной трафик, кроме src 10.10.0.0/24 и src 10.10.0.0/24 не дропался на интерфейсе, где будет применен filter regions-to-cdn.
Для каждого ISP добавляем RI:
set routing-instances ISP-1 instance-type forwarding set routing-instances ISP-1 routing-options static route 0.0.0.0/0 next-hop 172.16.0.2 set routing-instances ISP-2 instance-type forwarding set routing-instances ISP-2 routing-options static route 0.0.0.0/0 next-hop 172.16.0.6
Для копирования интерфейсных маршрутов, которые необходимы для next-hop resolve создаем rib-groups:
set routing-options interface-routes rib-group inet ISP-to-inet0 set routing-options rib-groups ISP-to-inet0 import-rib inet.0 set routing-options rib-groups ISP-to-inet0 import-rib ISP-1.inet.0 set routing-options rib-groups ISP-to-inet0 import-rib ISP-2.inet.0
Проверка
В RI кроме static route должны появиться маршруты src и p2p ISP сетей.
> show route table ISP-1.inet.0 > show route table ISP-2.inet.0
Трассировка с src netw 10.10.0.0/24 и 10.10.1.0/24 покажет разные маршруты до 1.1.1.1/32
instance-import вместо rib-group
Для тех, что не хочет использовать rib-groups, можно применить аналогичный по результату метод: instance-import
set policy-options policy-statement ISP-1-import from instance master = inet.0 set policy-options policy-statement ISP-1-import then accept
set routing-instances ISP-1 instance-type forwarding set routing-instances ISP-1 routing-options static route 0.0.0.0/0 next-hop 172.16.0.2 set routing-instances ISP-1 routing-options instance-import ISP-1-import
Multitopolgy
Для каждого типа трафика можно создать свою тополонию сети >> свою forwarding-table. Можно использовать для inet и inet6 family. Пакеты одного forwarding-class определяем в ту или иную топологию. По умолчанию, весь трафик использует одну топологию для разных forwarding-class.
Конфигурация
Inet family
set routing-options topologies family inet topology voice-topology set interfaces xe-0/0/1 unit 0 family inet filter input voice-filter set firewall family inet filter voice-filter term af-traffic from forwarding-class assured-forwarding set firewall family inet filter voice-filter term af-traffic then topology voice-topology
Inet6 family
set routing-options topologies family inet topology voice-topology set interfaces xe-0/0/0 unit 0 family inet6 filter input cdn-filter set firewall family inet6 filter cdn-filter term ef-traffic from forwarding-class ef set firewall family inet6 filter cdn-filter term ef-traffic then topology cdn-topology
Дополнительная информация
© Наталия Бобкова 2014—2022