балансировка нагрузки нескольких подключений по нескольким ссылкам

Насколько я понимаю (на основе документации ядра) установка "arp_filter = 1" требует использования политика маршрутизации на основе источника чтобы позволить нескольким интерфейсам маршрутизировать трафик, потенциально (но не обязательно) между отключенными сегментами сети.

ВОПРОС 1) Требуется ли "arp_filter = 1" для использования полосы пропускания нескольких каналов?

В любом случае, для балансировки нагрузки я использовал маршрут по умолчанию с несколькими ближайшими точками. В этот момент, если я использую «ip route get [addr]» (для адреса за пределами локальной подсети), кажется, предполагается, что использование нескольких nexthops для балансировки нагрузки работает ...

[root@localhost ~]# ip route get 10.20.44.100
10.20.44.100 via 10.20.30.1 dev eth2  src 10.20.30.42
    cache
[root@localhost ~]# ip route get 10.20.44.100
10.20.44.100 via 10.20.30.1 dev eth3  src 10.20.30.43
    cache
[root@localhost ~]# ip route get 10.20.44.100
10.20.44.100 via 10.20.30.1 dev eth2  src 10.20.30.42
    cache
[root@localhost ~]# ip route get 10.20.44.100
10.20.44.100 via 10.20.30.1 dev eth0  src 10.20.30.40
    cache

Однако если я проведу тот же эксперимент с адресом на тем же подсети, то для исходящего трафика используется только интерфейс по умолчанию.

[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 dev eth0  src 10.20.30.40
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 dev eth0  src 10.20.30.40
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 dev eth0  src 10.20.30.40
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 dev eth0  src 10.20.30.40
    cache

ВОПРОС 2) Есть ли способ получить дополнительную информацию о том, из какой таблицы маршрутизации исходит этот маршрут? И какое правило было использовано для этого?

Теперь у меня было предположение, что сбой балансировки нагрузки был вызван тем фактом, что в основной таблице маршрутизации есть маршруты области связи, которые совпадали до того, как можно было использовать маршрут по умолчанию ... Я проверил эту теорию, вставив тот же маршрут по умолчанию с несколькими следующими переходами в таблицу, которая будет соответствовать раньше, чем основная таблица маршрутизации

[root@localhost ~]# ip rule
0:      from all lookup local
32761:  from all to 10.20.30.0/24 lookup 100
...
32766:  from all lookup main
32767:  from all lookup default
[root@localhost ~]# ip route show table 100
default
        nexthop via 10.20.30.1  dev eth0 weight 1
        nexthop via 10.20.30.1  dev eth1 weight 1
        nexthop via 10.20.30.1  dev eth2 weight 1
        nexthop via 10.20.30.1  dev eth3 weight 1

Правильно это или нет, но результат был правильным: мой трафик теперь был «сбалансирован по нагрузке» (не идеально, но все же) по всем интерфейсам:

[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 via 10.20.30.1 dev eth0  src 10.20.30.40
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 via 10.20.30.1 dev eth3  src 10.20.30.43
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 via 10.20.30.1 dev eth2  src 10.20.30.42
    cache
[root@localhost ~]# ip route get 10.20.30.100
10.20.30.100 via 10.20.30.1 dev eth0  src 10.20.30.40
    cache

Самая большая проблема, которую я здесь вижу, заключается в том, что, насколько я могу судить, я только что сделал так, чтобы трафик, который в противном случае никогда бы не прошел мимо моего локального коммутатора, теперь будет маршрутизироваться (возможно, несколько переходов на мой маршрут по умолчанию) нет от того, что.

ВОПРОС 3) Есть ли более простой / лучший способ управления балансировкой нагрузки между и внутри подсетей, кроме использования дополнительной таблицы маршрутов по умолчанию?