[SCTP] ICMP unreachable message reenables data transmit

Michael Tüxen Michael.Tuexen at lurchi.franken.de
Sun May 1 14:33:48 UTC 2011


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 at freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> freebsd-net at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 



More information about the freebsd-net mailing list