ipoe: implemented new load balancing mechanism

[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 является специальным, используется для обозначения интерфейса который будет резервным, т.е. при получении любого веса от другого сервера, сессия будет останавливаться,
таким образом сессия запустится только если никто больше не отвечает.

[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,

[Dmitry]

they communicate by special broadcast dhcp messages

[brodayga]

Данный механизм работает до или после попытке авторизации?

[dimka88]

После, т.е. обращение к RADIUS будет, если речь об этом.

[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-й порт не слушает.

[dimka88]

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

[taf_321]

Странно. Сейчас запустил на стенде, DISCOVER переотправляются нормально с 67 на 67. ночью попробую перезапустить брасы.

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

[dimka88]

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

[taf_321]

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