Назад | Перейти на главную страницу

Linux: ускорение трафика, направляемого на сам мост

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

Единственный порт моста - это связующее устройство, которое может усложнить проблему. Дистрибутив - это Ubuntu Server 18.04.1 LTS. Вот мой план сети:

---
network:
  version: 2
  renderer: networkd
  ethernets:
    trunkports:
      match: { name: "eno[1234]" }
  bonds:
    bond0:
      interfaces: [trunkports]
      parameters:
        mode: 802.3ad
        transmit-hash-policy: layer3+4
        mii-monitor-interval: 100
        lacp-rate: fast
  vlans:
    bond252:
      link: bond0
      id: 252
  bridges:
    br0:
      interfaces: [bond0]
      parameters:
        forward-delay: 0
        stp: false
      addresses:
        - 10.1.10.2/24
        - 10.1.10.10/24
      gateway4: 10.1.10.1
    br252:
      interfaces: [bond252]
      parameters:
        forward-delay: 0
        stp: false
      addresses:
        - 192.168.252.2/24

РЕДАКТИРОВАТЬ: Я подозреваю, что дисциплина очередности «noqueue», установленная по умолчанию на всех виртуальных (т.е. связанных и мостовых) устройствах, означает, что эта настройка производительности больше не является строго необходимой, но я хотел бы получить подтверждение по этому поводу.

РЕДАКТИРОВАТЬ 2: Вот команда ebtables, которую я выдаю:

/sbin/ebtables -t broute -A BROUTING -d $(< /sys/class/net/br0/address) -p ipv4 -j redirect --redirect-target DROP