есть 2 машины с solaris10 x86 - one, two
есть 2 свича - switch1 switch2
one воткнут в switch1
two воткнут в switch1 (bnx0)и в swintch2(bnx1) и на этих интерфейсх настроен IPMP (link-based failure detection)

на two стоит ipfilter со state-ами

делаем ssh с one на two - через некоторое время сессия замирает и потом отваливается по timeout-у

происходит это в тот момент когда two шлет ARP ответ машине one со своим MAC-адресом, в ответ на broadcast ARP запрос своего MAC адреса от машины one.

ssh (как и любое другое tcp соединение) блочится из-за странной вещи, после того как мы отослали ARP ответ исходяшие пакеты на one начинают отсылаться с другого интерфейса из IPMP группы. То есть если до этого мы получали и принимали через bnx0, то будет отсылаться через bnx1, а в следующий раз опять и прием и передача будут через bnx0.

сам ARP ответ уходит через bnx0 и в нем стоит MAC адрес bnx0

причем если в тот момент когда пакеты физически отсылаются через bnx1 (видно по snoop)
two# route get one
говорит маршрут на one через interface: bnx0

да, bnx1 сконфигурен просто:
ifconfig bnx1 plumb
ifconfig bnx1 group twogrp up

адрес на нем 0.0.0.0 и маска 0xff000000

да, ipfilter не понимает переключения сессий с одного интерфейса не другой, это понятно, но с какой стати исходящий трафик меняет интерфейс после ARP ответа - вот вопрос.

• Глюки IPMP на Solaris10 x86,kolayshkin, 06:19 , 18-Июл-09
  • Глюки IPMP на Solaris10 x86,Dmitry, 12:55 , 20-Июл-09
• Глюки IPMP на Solaris10 x86,Валерий, 11:01 , 12-Ноя-09

Если оба интерфейса настроены Active/Active, а не Active/Standby, то исходящий трафик распараллеливается между всеми интерфейсами IPMP группы. Настрой второй интерфейс как StandBy и наверное настанет счастье.

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

>Если оба интерфейса настроены Active/Active, а не Active/Standby, то исходящий трафик распараллеливается
>между всеми интерфейсами IPMP группы. Настрой второй интерфейс как StandBy и
>наверное настанет счастье.

ищи документ "IPMP Rearchitecture: High-Level Design Specification"

в Active-Active IPMP может отвечать 1) с любого активного интерфейса 2) использовать в исходящем пакете любой из IP адресов в качестве Source address

3.2 Outbound Load-Spreading
Currently, the IP module load-spreads outbound traffic for each IP destination address across any
active interface in the group, where active is defined as an interface that is not marked FAILED,
INACTIVE, or OFFLINE, and has at least one UP address14. This will be unchanged in the new
model.
3.3 Source Address Selection
Currently, if the application does not bind to a specific source address, the IP module will select
a source address from the set of addresses in the IPMP group. The purpose of varying the source
address is to affect inbound load-spreading. Specifically, in the current model, all addresses hosted
on a given interface are associated with that interface’s hardware address. Thus, currently, if one
connection uses a source address on ce0, and another a source address on ce1, then each connection
will use a different interface for inbound traffic. It’s important to note that choice of outbound
interface is independent from choice of source address. Thus, it is quite common to have
a connection which sends packets through ce0, using a source address hosted on ce1, and thus
receives the response on ce1 (this is necessary to spread outbound load when the set of available
source addresses is smaller than the set of available outbound interfaces).