Page 1 of 1

ipoe: implemented new load balancing mechanism

Posted: 27 Dec 2017, 10:31
by Dmitry

Code: Select all

commit 1d6f68a518cd7f8cc182080b57d76ed16dc3973a
Author: Dmitry Kozlov <xeb@mail.ru>
Date:   Wed Dec 27 13:19:48 2017 +0300

    ipoe: implemented new load balancing mechanism
    
    new config options:
    [ipoe]
    weight=N - global weight
    interface=ethX,weight=N - per-interface weight
    
    How it works:
    On reception of DHCPDISCOVER accel-ppp sends broadcast DHCP message to port 67 with same xid and add special vendor-specific option
    where encodes its current session count multipled by weight.
    On reception of such message accel-ppp searches session with same xid and compares weight.
    If received weight is less than session's weight then it terminates this session.
    per-interface weight=0 has special meaning as backup (fail-over) interface, f.e. it terminates session on any received weight.
    
    By default weight based load balancing is disabled.
    To enable need to specify global or/and per-interface weight.
Реализован новый способ распределения нагрузки основанный на весах.
Работает следующим образом:
в конфиге задаётся
[ipoe]
weight=N - глобальный вес
interface=ethX,weight=N - интерфейсный вес

при получении DHCPDISCOVER accel-ppp отправляет широковещательный DHCP пакет с таким-же xid и добавляет спец. venodor-specific опцию
куда записывает свой вес: глобальный weight умноженный на общее кол-во сессий, либо, если задан интерфейсный вес, то интрефейсный вес умноженный на кол-во сессий на интерфейсе.
Получив такое сообщение от другого accel-ppp, происходит поиск сессий по xid и сравнивается её вес с принятым, если принятый вес меньше, то сессия останавливается.
Интерфейсный weight=0 является специальным, используется для обозначения интерфейса который будет резервным, т.е. при получении любого веса от другого сервера, сессия будет останавливаться,
таким образом сессия запустится только если никто больше не отвечает.

Re: ipoe: implemented new load balancing mechanism

Posted: 25 Jan 2018, 09:02
by uesleycorrea
I need testing this. In this case, both accel-ppp communicates? And swap information for weight, how it works? I don't understand this.

Regards,

Re: ipoe: implemented new load balancing mechanism

Posted: 25 Jan 2018, 10:04
by Dmitry
they communicate by special broadcast dhcp messages

Re: ipoe: implemented new load balancing mechanism

Posted: 20 Aug 2018, 12:54
by brodayga
Данный механизм работает до или после попытке авторизации?

Re: ipoe: implemented new load balancing mechanism

Posted: 09 Sep 2019, 20:07
by dimka88
После, т.е. обращение к RADIUS будет, если речь об этом.

Re: ipoe: implemented new load balancing mechanism

Posted: 26 Mar 2023, 16:39
by taf_321
Приветствую!

Пытаюсь воспользоваться этой фичей. В сети 4 браса в параллели, клиенты подключены по схеме qinq, авторизация по DHCP-запросу. версия из git'а cc8f2bada5635768d425e2fa2bafb095acda8ca9

Кусок конфига:

Code: Select all

[ipoe]
verbose=1
username=ifname
password=username
lease-time=300
max-lease-time=3600
shared=0
ifcfg=1
mode=L2
start=dhcpv4
ip-unnumbered=1
proxy-arp=1
weight=10
attr-dhcp-client-ip=Framed-IP-Address
vlan-mon=re:^ipoe(\d+)$
vlan-timeout=600
vlan-name=pppe%P.%N
idle-timeout=600
interface=re:^pppe(\d+)\.(\d+)$,mtu=1500,ipv6=1
gw-ip-address=100.64.0.1/10
gw-ip-address=172.16.0.1/12
По итогу получаю такое:

Code: Select all

00:22:21.753845 2c:c8:1b:e3:a9:55 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 3096, p 0, ethertype 802.1Q, vlan 1420, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 2c:c8:1b:e3:a9:55, length 300
00:22:21.753852 f8:f2:1e:eb:81:15 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 3096, p 0, ethertype 802.1Q, vlan 1420, p 0, ethertype IPv4, A.B.C.D.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
00:22:21.753905 00:1b:21:bc:ef:46 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 3096, p 0, ethertype 802.1Q, vlan 1420, p 0, ethertype IPv4, A.B.C.D.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
00:22:21.754051 f8:f2:1e:eb:85:f5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 3096, p 0, ethertype 802.1Q, vlan 1420, p 0, ethertype IPv4, A.B.C.D.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
00:22:21.754060 00:1b:21:bc:61:71 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 350: vlan 3096, p 0, ethertype 802.1Q, vlan 1420, p 0, ethertype IPv4, A.B.C.D.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
A.B.C.D и 2c:c8:1b:e3:a9:55 мак и ip клиента, остальный маки это брасы. Получается, что accel-ppp шлет пакеты не на 67-й порт, а на 68-й, хотя по исходникам прописано слать как раз на 67-й:

Code: Select all

...
void dhcpv4_send_notify(struct dhcpv4_serv *serv, struct dhcpv4_packet *req, unsigned int weight)
...
        dhcpv4_send_raw(serv, pack, 0, INADDR_BROADCAST, DHCP_SERV_PORT);
...
Я что-то просмотрел в настройках, или это баг? Ведь сам accel 68-й порт не слушает.

Re: ipoe: implemented new load balancing mechanism

Posted: 27 Mar 2023, 14:21
by dimka88
Приветствую. Должен отсылать с 67 на 67, все верно. Такое впечатление что параметр weight не применился из конфигурационного файла.
Еще нюанс, в схеме более 2х серверов, работать будет не совсем корректно. Лучше в сторону offer delay смотреть

Re: ipoe: implemented new load balancing mechanism

Posted: 28 Mar 2023, 06:15
by taf_321
Странно. Сейчас запустил на стенде, DISCOVER переотправляются нормально с 67 на 67. ночью попробую перезапустить брасы.

А в чем могут быть проблемы с этой опцией при количестве брасов более двух?

Re: ipoe: implemented new load balancing mechanism

Posted: 28 Mar 2023, 14:54
by dimka88
Я не думаю что код отработает как задумано
https://github.com/accel-ppp/accel-ppp/ ... oe.c#L1812
https://github.com/accel-ppp/accel-ppp/ ... oe.c#L1766
Т.е. От первого сервера получает меньше вес и магию, начинает стартовать сессию на втором, и тут приходит еще пакет от третьего и четвертого, но решение уже было принято по check_notify()

Re: ipoe: implemented new load balancing mechanism

Posted: 28 Mar 2023, 15:40
by taf_321
Хм... Клиентский DHCPDISCOVER прилетает на все брасы, они все рассылают свои DHCPDISCOVER, а так как check_notify отрабатывает на каждый прилетающий дисковер (https://github.com/accel-ppp/accel-ppp/ ... oe.c#L1796), в итоге живая сессия должна остаться только на самом предпочтительном. Единственно вызывает сомнение переотправка DISCOVER от другого браса. Практической пользы от него нет, а вот поймать логически заколькоцанный броадкаст шторм весьма вероятно.