On May 1, 2011, at 1:10 PM, Schoch Christian wrote: >> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >>> >>>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >>>> >>>>> During a measurement with CMT-SCTP and PF i figured out, that sometimes a >>>>> ICMP Destination unreachable message triggers a message transmission on >>>>> an inactive data path that has been primary before. >>>>> >>>>> It looks as the ICMP message is reseting the inactive state back to >>>>> active without reseting RTO. >>>>> >>>>> This behavior is triggered by a returning heartbeat message when no ICMP >>>>> unreachable by data is sent quite before. >>>>> >>>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem host >>>>> between. >>>>> >>>>> A wireshark log can be provided on demand (quite large). >>>> Hi Christian, >>>> >>>> any chance to upgrade the FreeBSD machines to head or to use newer >>>> SCTP sources, which I could provide? It would require a recompilation >>>> of the kernel... >>> >>> It is possible, but the results could be provided not until next week >>> if a reboot is necessary. >>> I can use any sources you could provide me since nothing else is done at >>> this systems. >> OK, but maybe I can try to understand what is going on. >> >> How many paths do you have? One is inactive, but was primary, so it >> is confirmed. On another one, you get an ICMP (which one? Port unreachable, >> host unreachable, ...). Do you have more than two paths? > > Setup looks like this: > > -------- ----cut--- > Host A WANem Host B > -------- ---------- > > Transfer is running on both path from A to B till the primary link is cut > between WANem and the receiver and the whole transfer switches to the second > path. The ICMP message (Host not reachable with a Heartbeat as attachment) is > received on the primary interface from WANem host. OK, understood. > > As I tested this morning, the primary path is switching to unreachable due to > the ICMP message but should be in this state quite before by exceeding > path.max_retrans. > So this ICMP message does two things: > - Set the primary path to unreachable > - Triggers something to retry data transfer on the primary path. After looking at the tracefile, I somewhat agree. * Do you see something like ICMP (thresh ??/??) takes interface ?? down on the console? This would be printed if the ICMP takes the path to unreachable? (It should also be in /var/log/messages) * If the path is already unreachable, nothing should happen in response to the ICMP message.
So the question is: Is the path unreachable before the ICMP message is received? Is your application monitoring the SCTP notification? What about the above printout from the kernel? Best regards Michael > >> The ICMP message would not reset the RTO, since you need an ACKed TSN >> or a HB-ACK to to that. Since it is inactive, it is missing these. >> >> Sending on an inactive path is OK, as soon as you enter the dormant >> state, which means all your paths are inactive. >> > Transfer is still running on second link which is active. That sounds good. > >> Are you using the PF support for CMT? > > Yes, but without NR-SACK and DAC. OK. > > I uploaded the pcap file to: > http://37116.vs.webtropia.com/cmt_2.pcap That was helpful! > > Best regards, > Christian > >> >> Best regards >> Michael >>> >>>> >>>> Are you using IPv4 or IPv6? >>>> >>> >>> IPv4 >>> >>> >>>> Best regards >>>> Michael >>>>> >>>>> Regards, >>>>> Schoch Christian >>>>> _______________________________________________ >>>>> 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" >>>> >>> >>> >> >> > > > _______________________________________________ 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"
