Date: Sun, 1 May 2011 16:33:32 +0200 From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de> To: Schoch Christian <e0326715@student.tuwien.ac.at> Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] ICMP unreachable message reenables data transmit Message-ID: <13E5D4BB-5B2C-42B3-A43E-0F260317DE6B@lurchi.franken.de> In-Reply-To: <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at> References: <20110430091148.31393q3py4j4bg38@webmail.tuwien.ac.at> <FD1FC82D-29D1-4186-A0AC-504653C28D85@lurchi.franken.de> <20110430121518.25761cpmtrp0jtpy@webmail.tuwien.ac.at> <F4802366-A9B4-4515-8E6D-E5C80C06408B@lurchi.franken.de> <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 1, 2011, at 1:10 PM, Schoch Christian wrote: >> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >>>=20 >>>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> It looks as the ICMP message is reseting the inactive state back = to active without reseting RTO. >>>>>=20 >>>>> This behavior is triggered by a returning heartbeat message when = no ICMP unreachable by data is sent quite before. >>>>>=20 >>>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem = host between. >>>>>=20 >>>>> A wireshark log can be provided on demand (quite large). >>>> Hi Christian, >>>>=20 >>>> 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... >>>=20 >>> 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. >>=20 >> 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? >=20 > Setup looks like this: >=20 > -------- ----cut--- > Host A WANem Host B > -------- ---------- >=20 > 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. >=20 > 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 >=20 >> 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. >>=20 >> Sending on an inactive path is OK, as soon as you enter the dormant >> state, which means all your paths are inactive. >>=20 > Transfer is still running on second link which is active. That sounds good. >=20 >> Are you using the PF support for CMT? >=20 > Yes, but without NR-SACK and DAC. OK. >=20 > I uploaded the pcap file to: > http://37116.vs.webtropia.com/cmt_2.pcap That was helpful! >=20 > Best regards, > Christian >=20 >>=20 >> Best regards >> Michael >>>=20 >>>>=20 >>>> Are you using IPv4 or IPv6? >>>>=20 >>>=20 >>> IPv4 >>>=20 >>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> 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-unsubscribe@freebsd.org" >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13E5D4BB-5B2C-42B3-A43E-0F260317DE6B>