All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Steve Hill <steve.hill@dialogic.com>
Cc: netdev@vger.kernel.org, lksctp-developers@lists.sourceforge.net,
	Sridhar Samudrala <sri@us.ibm.com>
Subject: Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Date: Tue, 06 Feb 2007 16:48:42 -0500	[thread overview]
Message-ID: <45C8F7BA.6010007@hp.com> (raw)
In-Reply-To: <E096369D937D3A4DB271B382850C5C5F48E60D@pysmail.eicon.com>

Steve Hill wrote:
> 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.

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.

> 
>> 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

  reply	other threads:[~2007-02-06 21:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06  9:26 [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage Steve Hill
2007-02-06 21:48 ` Vlad Yasevich [this message]
2007-02-07 20:45 ` Vlad Yasevich
2007-02-08 14:07   ` Steve Hill
2007-02-08 14:15     ` Vlad Yasevich
  -- strict thread matches above, loose matches on Subject: below --
2007-02-05 17:26 Steve Hill
2007-02-05 20:34 ` Vlad Yasevich
2007-02-05 16:53 Steve Hill
2007-02-05 17:07 ` Vlad Yasevich
2007-02-05 14:13 Steve Hill
2007-02-05 16:39 ` Vlad Yasevich
2007-01-03 23:46 Andrew Morton
2007-01-04  0:59 ` Sridhar Samudrala
2007-01-10 11:55   ` Steve Hill
2007-01-10 20:10     ` Sridhar Samudrala
2007-01-11 10:10       ` Steve Hill
2007-01-25 16:32         ` [Lksctp-developers] " Vlad Yasevich
2007-01-25 16:37           ` Vlad Yasevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45C8F7BA.6010007@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=sri@us.ibm.com \
    --cc=steve.hill@dialogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.