[sisyphus] bond + bridge

[sisyphus] bond + bridge

[Вячеслав]

Как правильне:

(bond на которой ip) повесить и его в бридж а в него виртуалки
или 
boond, его в (бридж на которй ip), а в него виртуалки

при первом варианте сыплются месаги
bond0: received packet with  own address as source address

ip a
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master bond0 state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:ec brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
master bond0 state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:ec brd ff:ff:ff:ff:ff:ff
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue 
state UP
    link/ether 00:15:17:b1:6c:ec brd ff:ff:ff:ff:ff:ff
5: breth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state 
UNKNOWN
    link/ether xx:xx:xx:xx:xx:ec brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.6/27 scope global breth0
6: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue 
state UNKNOWN
    link/void
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 
UNKNOWN qlen 500
    link/ether xx:xx:xx:xx:xx:ec brd ff:ff:ff:ff:ff:ff

ip -r
10.1.0.0/27 dev breth0  proto kernel  scope link  src 10.1.0.6
default via 10.1.0.1 dev breth0

Re: [sisyphus] bond + bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On Thu, Feb 04, 2010 at 02:10:14PM +0200, Вячеслав wrote:
> Как правильне:
> 
> (bond на которой ip) повесить и его в бридж а в него виртуалки
> или 
> bond, его в (бридж на которй ip), а в него виртуалки

Правильный вариант - второй.  Вообще при любом использовании bridge
интерфейсы, включаемые туда, не должны иметь IP-адресов.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] bond + bridge

[Michael A. Kangin]

В сообщении от Четверг 04 февраля 2010 17:47:38 автор Sergey Vlasov написал:

> Правильный вариант - второй.  Вообще при любом использовании bridge
> интерфейсы, включаемые туда, не должны иметь IP-адресов.
> 

Как-то приходилось "присваивать" члену бриджа адрес 0.0.0.0/0, чтобы этот 
интерфейс засветился в /proc/sys/net/ipv4/conf/

-- 
wbr, Michael A. Kangin

Re: [sisyphus] bond + bridge

[Вячеслав]

On Friday 05 February 2010 09:24:16 Michael A. Kangin wrote:
> В сообщении от Четверг 04 февраля 2010 17:47:38 автор Sergey Vlasov написал:
> > Правильный вариант - второй.  Вообще при любом использовании bridge
> > интерфейсы, включаемые туда, не должны иметь IP-адресов.
>
> Как-то приходилось "присваивать" члену бриджа адрес 0.0.0.0/0, чтобы этот
> интерфейс засветился в /proc/sys/net/ipv4/conf/

как тогда боротся с этим

bond0: received packet with  own address as source address

Re: [sisyphus] bond + bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Fri, Feb 05, 2010 at 09:45:45AM +0200, Вячеслав wrote:
> On Friday 05 February 2010 09:24:16 Michael A. Kangin wrote:
> > В сообщении от Четверг 04 февраля 2010 17:47:38 автор Sergey Vlasov написал:
> > > Правильный вариант - второй.  Вообще при любом использовании bridge
> > > интерфейсы, включаемые туда, не должны иметь IP-адресов.
> >
> > Как-то приходилось "присваивать" члену бриджа адрес 0.0.0.0/0, чтобы этот
> > интерфейс засветился в /proc/sys/net/ipv4/conf/
> 
> как тогда боротся с этим
> 
> bond0: received packet with  own address as source address

А какой именно режим используется для bond0, и как настроен
коммутатор, в который включены соответствующие кабели?

mode=5 и mode=6 точно не работают совместно с bridge; mode=4 (802.3ad)
работает, но требует соответствующей настройки и со стороны
коммутатора.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] bond + bridge

[Вячеслав]

On Friday 05 February 2010 15:44:56 Sergey Vlasov wrote:
> On Fri, Feb 05, 2010 at 09:45:45AM +0200, Вячеслав wrote:
> > On Friday 05 February 2010 09:24:16 Michael A. Kangin wrote:
> > > В сообщении от Четверг 04 февраля 2010 17:47:38 автор Sergey Vlasov 
написал:
> > > > Правильный вариант - второй.  Вообще при любом использовании bridge
> > > > интерфейсы, включаемые туда, не должны иметь IP-адресов.
> > >
> > > Как-то приходилось "присваивать" члену бриджа адрес 0.0.0.0/0, чтобы
> > > этот интерфейс засветился в /proc/sys/net/ipv4/conf/
> >
> > как тогда боротся с этим
> >
> > bond0: received packet with  own address as source address
>
> А какой именно режим используется для bond0, и как настроен
> коммутатор, в который включены соответствующие кабели?
>
> mode=5 и mode=6 точно не работают совместно с bridge; mode=4 (802.3ad)
> работает, но требует соответствующей настройки и со стороны
> коммутатора.

`cat options`
TYPE=bond
HOST='eth0 eth1'
BONDOPTIONS="mode=0 miimon=100"
DISABLED=no
BOOTPROTO=static
NM_CONTROLLED=no
ONBOOT=yes

Re: [sisyphus] bond + bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]

On Fri, Feb 05, 2010 at 03:52:43PM +0200, Вячеслав wrote:
> > > bond0: received packet with  own address as source address
> >
> > А какой именно режим используется для bond0, и как настроен
> > коммутатор, в который включены соответствующие кабели?
> >
> > mode=5 и mode=6 точно не работают совместно с bridge; mode=4 (802.3ad)
> > работает, но требует соответствующей настройки и со стороны
> > коммутатора.
> 
> `cat options`
> TYPE=bond
> HOST='eth0 eth1'
> BONDOPTIONS="mode=0 miimon=100"
> DISABLED=no
> BOOTPROTO=static
> NM_CONTROLLED=no
> ONBOOT=yes

mode=0 требует настройки статического агрегирования на коммутаторе без
использования протокола LACP; без этой настройки будут как раз такие
ошибки (пакеты, переданные в один из портов, будут возвращаться назад
через другой).

Кроме того, при использовании mode=0 возможно изменение порядка
пакетов в пределах одного соединения, что может вызывать проблемы,
например, повторные передачи в TCP, если такое переупорядочивание
будет обработано как признак перегрузки в сети.  Этой проблемы можно
избежать, если использовать mode=2 и xmit_hash_policy=layer2 или
layer2+3 (вариант layer3+4 может приводить к изменению порядка пакетов
в редких случаях, когда используется фрагментация на уровне IP).
Настройки коммутатора для mode=2 требуются те же, что и для mode=0 -
статическое агрегирование без использования LACP.

При использовании bonding в комбинации с bridge и виртуальными
машинами нужно учитывать, что при обработке xmit_hash_policy код
bonding не использует MAC-адрес отправителя в исходящих пакетах; в
результате, если несколько разных ВМ отправляют пакеты на один и тот
же MAC-адрес (например, на маршрутизатор), все эти пакеты при
использовании xmit_hash_policy=layer2 будут попадать в один канал.
Для борьбы с этим можно использовать xmit_hash_policy=layer2+3 (в этом
случае учитываются оба IP-адреса в пакете, в результате пакеты от
разных ВМ могут быть распределены по разным интерфейсам даже при
обмене с одним и тем же MAC и IP).

Режима, поддерживающего балансировку нагрузки, совместимого с
использованием bridge, и при этом не требующего специальных настроек
коммутатора, в модуле bonding в настоящее время нет (в режимах
balance-alb и balance-tlb модуль bonding меняет MAC-адреса в исходящих
пакетах, не учитывая того, что эти пакеты могут исходить от ВМ со
своими собственными MAC).  В Citrix XenServer добавляли режим
balance-slb, который якобы умеет разносить трафик от разных ВМ по
разным интерфейсам (заявлена динамическая балансировка нагрузки по
алгоритмам, аналогичным balance-alb, но с использованием source MAC в
качестве ключа), однако этот патч придётся искать где-то внутри общей
свалки исходников:

  http://www.citrix.com/lang/English/lp/lp_1688623.asp

Хотя сейчас ещё есть http://openvswitch.org/ (причём в Xen Cloud
Platform перешли именно на него, так что пропихивать куда-то поддержку
balance-slb разработчики, похоже, уже не будут).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] bond + bridge

[Вячеслав]

On Friday 05 February 2010 17:43:15 Sergey Vlasov wrote:
> On Fri, Feb 05, 2010 at 03:52:43PM +0200, Вячеслав wrote:
> > > > bond0: received packet with  own address as source address
> > >
> > > А какой именно режим используется для bond0, и как настроен
> > > коммутатор, в который включены соответствующие кабели?
> > >
> > > mode=5 и mode=6 точно не работают совместно с bridge; mode=4 (802.3ad)
> > > работает, но требует соответствующей настройки и со стороны
> > > коммутатора.
> >
> > `cat options`
> > TYPE=bond
> > HOST='eth0 eth1'
> > BONDOPTIONS="mode=0 miimon=100"
> > DISABLED=no
> > BOOTPROTO=static
> > NM_CONTROLLED=no
> > ONBOOT=yes
>
> mode=0 требует настройки статического агрегирования на коммутаторе без
> использования протокола LACP; без этой настройки будут как раз такие
> ошибки (пакеты, переданные в один из портов, будут возвращаться назад
> через другой).

Спасибо за развернутый ответ.

Вроде получилось, вот только не знаю как протестировать. ;(

SERVER

cat /proc/net/bonding/bond0

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 52
        Partner Mac Address: xx:xx:xx:xx:xx:80  (МАК свича)

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: xx:xx:xx:xx:xx:ec
Aggregator ID: 2

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: xx:xx:xx:xx:xx:ed
Aggregator ID: 2

cat /etc/net/ifaces/bond0/options
TYPE=bond
HOST='eth0 eth1'
BONDOPTIONS="mode=4 miimon=100 xmit_hash_policy=1 lacp_rate=fast"
DISABLED=no
BOOTPROTO=static
NM_CONTROLLED=no
ONBOOT=yes

cat /etc/net/ifaces/breth0/options
TYPE=bri
HOST='bond0'
DISABLED=no
BOOTPROTO=static
NM_CONTROLLED=no
ONBOOT=yes

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0        0.0.0.0         255.255.255.224 U     0      0        0 breth0
0.0.0.0         10.1.0.1        0.0.0.0         UG    0      0        0 breth0

Свич hp procurve 3400cl

trunk 7,18 Trk1 LACP

7,18 порты сервера

vlan 2
   name "SERVER"
   untagged 1,5,Trk1
   ip address 10.1.0.1 255.255.255.224
   ip helper-address 10.1.0.2
   ip forward-protocol udp 10.1.0.6 netbios-ns
   ip forward-protocol udp 10.1.0.6 netbios-dgm
   exit

sh trunks
 Load Balancing

  Port | Name                             Type      | Group Type
  ---- + -------------------------------- --------- + ----- -----
  7    | srv_bond_a               100/1000T | Trk1  LACP
  18   | srv_bond_b               100/1000T | Trk1  LACP

sh lacp
                           LACP

   PORT   LACP      TRUNK     PORT      LACP      LACP
   NUMB   ENABLED   GROUP     STATUS    PARTNER   STATUS
   ----   -------   -------   -------   -------   -------
   7      Active    Trk1      Up        Yes       Success
   18     Active    Trk1      Up        Yes       Success

sh interfaces brief
                  | Intrusion                           MDI   Flow  Bcast
  Port    Type      | Alert     Enabled Status Mode       Mode  Ctrl  Limit
  ------- --------- + --------- ------- ------ ---------- ----- ----- ------
7-Trk1  100/1000T | No        Yes     Up     1000FDx    MDI   off   0
18-Trk1 100/1000T | No        Yes     Up     1000FDx    MDIX  off   0

Теперь вопросы:
вроде все работает но увеличение скорости не заметно.
Даже если она не должна сумироватся, а распределятся между клиентами.

Тестировал iperf
два клиента подкл. гигабитами замер на серевер с boond

Если по одному
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec    590 MBytes    495 Mbits/sec
[  4]  0.0-10.0 sec    905 MBytes    758 Mbits/sec

Два одновременно
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0-10.0 sec    245 MBytes    206 Mbits/sec
[  4]  0.0-10.0 sec    849 MBytes    711 Mbits/sec

Теперь сервер без boond, на гигабите + два клиента по гигабиту

[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec    567 MBytes    475 Mbits/sec
[  5]  0.0-10.0 sec    521 MBytes    437 Mbits/sec

т.е. както от boond не видно ни прироста ни расределения без падения
Может чтото не докрутил?

Или другим софтом надо тестировать?

Re: [sisyphus] bond + bridge

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

On Mon, Feb 08, 2010 at 11:14:13AM +0200, Вячеслав wrote:
[...]
> sh interfaces brief
>                   | Intrusion                           MDI   Flow  Bcast
>   Port    Type      | Alert     Enabled Status Mode       Mode  Ctrl  Limit
>   ------- --------- + --------- ------- ------ ---------- ----- ----- ------
> 7-Trk1  100/1000T | No        Yes     Up     1000FDx    MDI   off   0
> 18-Trk1 100/1000T | No        Yes     Up     1000FDx    MDIX  off   0

Почему на одном интерфейса MDI, на другом MDIX - какая-то путаница с
кабелями?

> Теперь вопросы:
> вроде все работает но увеличение скорости не заметно.
> Даже если она не должна сумироватся, а распределятся между клиентами.
> 
> Тестировал iperf
> два клиента подкл. гигабитами замер на серевер с boond
> 
> Если по одному
> [ ID] Interval       Transfer     Bandwidth
> [  5]  0.0-10.0 sec    590 MBytes    495 Mbits/sec
> [  4]  0.0-10.0 sec    905 MBytes    758 Mbits/sec

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

> Два одновременно
> [ ID] Interval       Transfer     Bandwidth
> [  6]  0.0-10.0 sec    245 MBytes    206 Mbits/sec
> [  4]  0.0-10.0 sec    849 MBytes    711 Mbits/sec
> 
> Теперь сервер без boond, на гигабите + два клиента по гигабиту
> 
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec    567 MBytes    475 Mbits/sec
> [  5]  0.0-10.0 sec    521 MBytes    437 Mbits/sec
> 
> т.е. както от boond не видно ни прироста ни расределения без падения
> Может чтото не докрутил?

Если передача потока данных шла от сервера к клиентам - возможно,
хеширование по MAC+IP засунуло всё в один канал; наблюдать действие
этого можно, если сменить у одного из клиентов младший бит IP-адреса и
повторить тот же тест.

Если данные передавались от клиентов к серверу - проблема может быть
та же, только настраивать политику балансировки нагрузки в этом
направлении нужно уже со стороны коммутатора; конкретных команд
настройки для ProCurve не знаю.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] bond + bridge

[Вячеслав]

On Monday 08 February 2010 13:50:07 Sergey Vlasov wrote:
> On Mon, Feb 08, 2010 at 11:14:13AM +0200, Вячеслав wrote:
> [...]
>
> > sh interfaces brief
> >
> >                   | Intrusion                           MDI   Flow  Bcast
> >
> >   Port    Type      | Alert     Enabled Status Mode       Mode  Ctrl 
> > Limit ------- --------- + --------- ------- ------ ---------- ----- -----
> > ------ 7-Trk1  100/1000T | No        Yes     Up     1000FDx    MDI   off 
> >  0 18-Trk1 100/1000T | No        Yes     Up     1000FDx    MDIX  off   0
>
> Почему на одном интерфейса MDI, на другом MDIX - какая-то путаница с
> кабелями?
Сам удивился но:
патч корды одинаковые по 2 Метра сетевые тоже, обе наборные
[   10.982752] igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) xx:ec
[   10.982829] igb 0000:01:00.0: eth0: PBA No: 1030ff-0ff
[   11.090803] igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) xx:ed
[   11.090880] igb 0000:01:00.1: eth1: PBA No: 1030ff-0ff

>
> > Теперь вопросы:
> > вроде все работает но увеличение скорости не заметно.
> > Даже если она не должна сумироватся, а распределятся между клиентами.
> >
> > Тестировал iperf
> > два клиента подкл. гигабитами замер на серевер с boond
> >
> > Если по одному
> > [ ID] Interval       Transfer     Bandwidth
> > [  5]  0.0-10.0 sec    590 MBytes    495 Mbits/sec
> > [  4]  0.0-10.0 sec    905 MBytes    758 Mbits/sec
>
> А почему результаты клиентов при работе по одному разные - это
> какая-то разница между клиентами, или тоже особенность, наблюдаемая
> только при работе через bond?  Стоит сначала проверить связь просто по
> гигабитному интерфейсу без bond (причём по каждому из них).
Разные клиенты (два рядом стоящие сервака)
если с моей раб. станиции (подкл. по 1 Gb) то вообще выдает
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1011 MBytes    848 Mbits/sec

>
> > Два одновременно
> > [ ID] Interval       Transfer     Bandwidth
> > [  6]  0.0-10.0 sec    245 MBytes    206 Mbits/sec
> > [  4]  0.0-10.0 sec    849 MBytes    711 Mbits/sec
> >
> > Теперь сервер без boond, на гигабите + два клиента по гигабиту
> >
> > [ ID] Interval       Transfer     Bandwidth
> > [  4]  0.0-10.0 sec    567 MBytes    475 Mbits/sec
> > [  5]  0.0-10.0 sec    521 MBytes    437 Mbits/sec
> >
> > т.е. както от boond не видно ни прироста ни расределения без падения
> > Может чтото не докрутил?
>
> Если передача потока данных шла от сервера к клиентам - возможно,
> хеширование по MAC+IP засунуло всё в один канал; наблюдать действие
> этого можно, если сменить у одного из клиентов младший бит IP-адреса и
> повторить тот же тест.
iperf как сервер запущен на сервере с boond т.е. от него к клиентам
>
> Если данные передавались от клиентов к серверу - проблема может быть
> та же, только настраивать политику балансировки нагрузки в этом
> направлении нужно уже со стороны коммутатора; конкретных команд
> настройки для ProCurve не знаю.
какой режим посоветуете для bond может вернутся к 0  (balance-rr)?

Re: [sisyphus] bond + bridge

[Anton Gorlov]

Вячеслав пишет:
> какой режим посоветуете для bond может вернутся к 0  (balance-rr)?

Я использую 4 (802.3ad) + lacp_rate=fast xmit_hash_policy=1