RE: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage

Vlad Yasevich wrote on 05 February 2007 20:35:

would you mind terribly, changing the -d "$net" to the
-i "$net", and run the script with the interface name instead?

I seem to get the same failure when dropping traffic based on interface
as I do when dropping based on address.

When I block at the ip address, I see the path failover
in an odd state.  It looks like it happened, but the flow is
not resumed.  Receive still doesn't get traffic. I think I might

This sounds like it might be the same problem I'm seeing.

My sender is running the 2.6.16.1 kernel with your patch applied, the
receiver is running Fedora Core 6's 2.6.18-1.2798.fc6 kernel.  The
iptables rules are being set on the receiver (so there should be no odd
interactions between the sender's SCTP stack and iptables - as far as
the sender knows the packets have been transmitted and lost in transit).

Thanks.

 - Steve Hill
   Software Engineer
   Dialogic
   Fordingbridge, Hampshire, UK
   +44-1425-651392
   steve.hill@dialogic.com

Steve Hill wrote:

Vlad Yasevich wrote on 05 February 2007 20:35:

quoted

would you mind terribly, changing the -d "$net" to the
-i "$net", and run the script with the interface name instead?

I seem to get the same failure when dropping traffic based on interface
as I do when dropping based on address.

Hmm... can you try with a more recent sender please.  Running 2.6.19 or
2.6.20 with my patch, I don't see this problem when a single interface fails.

I see a full path failover withing the 5 second timeout of the table rule.
Once failover happens, the traffic is using the second interface.

I haven't tried forcing the failover back to the first one, but I can
try flip-flopping them and see what happens.

quoted

When I block at the ip address, I see the path failover
in an odd state.  It looks like it happened, but the flow is
not resumed.  Receive still doesn't get traffic. I think I might

This sounds like it might be the same problem I'm seeing.

My sender is running the 2.6.16.1 kernel with your patch applied, the
receiver is running Fedora Core 6's 2.6.18-1.2798.fc6 kernel.  The
iptables rules are being set on the receiver (so there should be no odd
interactions between the sender's SCTP stack and iptables - as far as
the sender knows the packets have been transmitted and lost in transit).

Yes, that's what I am doing as well.  I'll see if I can run a more recent
receiver.

Thanks
-vlad

Hi Steve

I think I've tracked this down.  Can you apply the attached patch on top
of the one I posted before and re-run your test.

With both patches, I was able flip-flop the downed interface multiple times
and in all cases path failover completed and data flow resumed.

Here is the modified script I was running:

#!/bin/sh

net1="$1"
net2="$2"

flush() {
    iptables -F
    echo "Flush"
    exit
}

trap flush EXIT

while true; do
    # clear table
    iptables -F
    echo "flushed"
    sleep 5

    # block net1
    iptables -A INPUT -i "$net1" -p sctp -j DROP
    echo "set net1"
    sleep 5

    # clear table
    iptables -F
    echo "flushed"
    sleep 5

    # block net2
    iptables -A INPUT -i "$net2" -p sctp -j DROP
    echo "set net2"
    sleep 5
done

I was able to run this script for 10 minutes sustaining the message flow.

-vlad

On Wed, 7 Feb 2007, Vlad Yasevich wrote:

I think I've tracked this down.  Can you apply the attached patch on top
of the one I posted before and re-run your test.

Using the 2.6.20 kernel on the sending side with both patches applied, the
problem seems to be fixed.

Thanks.

-- 
 - Steve Hill
   Software Engineer
   Dialogic
   Fordingbridge, Hampshire, UK
   +44-1425-651392
   steve.hill@dialogic.com

Steve Hill wrote:

On Wed, 7 Feb 2007, Vlad Yasevich wrote:

quoted

I think I've tracked this down.  Can you apply the attached patch on top
of the one I posted before and re-run your test.

Using the 2.6.20 kernel on the sending side with both patches applied, the
problem seems to be fixed.

Thanks.

Excellent.  I'll push out the new ones to Sridhar today.

-vlad