On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: > I did some test with multihoming and failover. My problem is that if one > transport failes it never comes back to active (no heartbeats are sent any > more). > > My setup: > > FreeBSD 8.1 Linux 2.6.36 > 172.16.1.4 --------- 172.16.1.3 > 172.17.1.4 --------- 172.17.1.3 > > Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. > > The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. Which side is the client, which one is the server? Which side is sending user data? > If the transfer on this transport failes, it is switching to 17.1.4 & 17.1.3 > as expected. How do you fail the connection? Disconnecting the cable? Configuring dummynet? > 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which address? 172.16.1.3? > Now, if the first connection is available again, the first transport address > of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 > Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to > 16.1.3 (which is dropped). > > So why are HBs sent from new primary instead of received address ? As > specified in RFC it should sent back from address, it receives the HB packet. Correct. Somethings seems strange. Please answer the above and I will try to reproduce the problem.
Thanks for the report. Best regards Michael > > Regards, > Christian > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
