From: David Ahern <dsa@cumulusnetworks•com>
To: Julian Anastasov <ja@ssi•bg>
Cc: netdev@vger•kernel.org
Subject: Re: [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops
Date: Tue, 29 Mar 2016 22:16:21 -0500 [thread overview]
Message-ID: <56FB4505.8000208@cumulusnetworks.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1603251024390.1896@ja.home.ssi.bg>
On 3/25/16 4:05 AM, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 24 Mar 2016, David Ahern wrote:
>
>> On 3/24/16 4:33 PM, Julian Anastasov wrote:
>>> But for multipath routes we can also consider the
>>> nexthops as "alternatives", so it depends on how one uses
>>> the multipath mechanism. The ability to fallback to
>>> another nexthop assumes one connection is allowed to
>>> move from one ISP to another. What if the second ISP
>>> decides to reject the connection? What we have is a
>>> broken connection just because the retransmits
>>> were diverted to wrong place in the hurry. So, the
>>> nexthops can be compatible or incompatible. For your
>>> setup they are, for others they are not.
>>
>> I am not sure I completely understand your point. Are you saying that within a
>> single multipath route some connections to nexthops are allowed and others are
>> not?
>>
>> So to put that paragraph into an example
>>
>> 15.0.0.0/16
>> nexthop via 12.0.0.2 dev swp1 weight 1
>> nexthop via 12.0.0.3 dev swp1 weight 1
>>
>> Hosts from 15.0/16 could have TCP connections use 12.0.0.2, but not 12.0.0.3
>> because 12.0.0.3 could be a different ISP and not allow TCP connections from
>> this address space?
>
> Yes. Two cases are possible:
>
> 1. ISP2 filters saddr, traffic with saddr from ISP1 is dropped.
>
> 2. ISP2 allows any saddr. But how the responses from
> world with daddr=IP_from_ISP1 will come from ISP2 link?
> If the nexthops are for different ISP the connection
> can survive only if sticks to its ISP. An ISP will
> not work as a backup link for another ISP.
Seems to me this is a problem that is addressed by VRFs, not multipath
routes where some nexthops are actually deadends because they attempt to
cross ISPs.
>> After that if it has information that says that a nexthop is dead, why would
>> it continue to try to probe? Any traffic that selects that nh is dead. That to
>
> If entry becomes FAILED this state is preserved
> if we do not direct traffic to this entry. If there was a
> single connection that was rejected after 3 failed probes
> the next connection (with your patch) will fallback to
> another neigh and the first entry will remain in FAILED
> state until expiration. If one wants to refresh the state
> often, a script/tool that pings all GWs is needed, so that
> you can notice the available or failed paths faster.
>
>> me defies the basis of having multiple paths.
>
> We do not know how long is the outage. Long living
> connections may prefer to survive with retransmits.
> Say you are using SSH via wifi link doing important work.
> Do you want your connection to break just because link was
> down for a while?
neighbor entries have a timeout and when it drops from the cache the arp
will try again. This suggested patch is not saying 'never try a nexthop
again' it is saying 'I have multiple paths and since path 1 is down try
another one'.
I'll send an updated patch when I get time (traveling at the moment); I
guess a sysctl is going to be needed if the behavior you mention with
ISPs is reasonable.
prev parent reply other threads:[~2016-03-30 3:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 15:25 [PATCH net] net: ipv4: Multipath needs to handle unreachable nexthops David Ahern
2016-03-24 16:45 ` Eric Dumazet
2016-03-24 17:43 ` David Ahern
2016-03-24 17:55 ` Eric Dumazet
2016-03-24 18:26 ` David Miller
2016-03-24 22:33 ` Julian Anastasov
2016-03-25 2:05 ` David Ahern
2016-03-25 9:05 ` Julian Anastasov
2016-03-30 3:16 ` David Ahern [this message]
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=56FB4505.8000208@cumulusnetworks.com \
--to=dsa@cumulusnetworks$(echo .)com \
--cc=ja@ssi$(echo .)bg \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox