Re: BFD w/ static routes and single-hop eBGP

David Ward <dward@cisco.com> Fri, 28 October 2005 15:58 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWci-0005lS-Ch; Fri, 28 Oct 2005 11:58:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWcg-0005lK-AI for rtg-bfd@megatron.ietf.org; Fri, 28 Oct 2005 11:58:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26026 for <rtg-bfd@ietf.org>; Fri, 28 Oct 2005 11:58:13 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWqH-0001oZ-5j for rtg-bfd@ietf.org; Fri, 28 Oct 2005 12:12:33 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2005 08:58:21 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9SFwAJn029036; Fri, 28 Oct 2005 08:58:18 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:58:16 -0700
Received: from [171.71.139.74] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:58:15 -0700
User-Agent: Microsoft-Entourage/10.1.6.040913.0
Date: Fri, 28 Oct 2005 10:58:28 -0500
From: David Ward <dward@cisco.com>
To: Jeffrey Haas <jhaas@nexthop.com>, Pekka Savola <pekkas@netcore.fi>
Message-ID: <BF87B4D4.15BFF%dward@cisco.com>
In-Reply-To: <20051028145924.GG18406@nexthop.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 28 Oct 2005 15:58:16.0089 (UTC) FILETIME=[68667090:01C5DBD8]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org, Dave Katz <dkatz@juniper.net>
Subject: Re: BFD w/ static routes and single-hop eBGP
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Jeff -


On 10/28/05 9:59 AM, "Jeffrey Haas" <jhaas@nexthop.com> wrote:

> On Fri, Oct 28, 2005 at 08:35:21AM +0300, Pekka Savola wrote:
>>>> [Jeff]
>>>> The third party nexthop case is the more interesting one.  I believe
>>>> you'd want a BFD session for each third party nexthop.
>>>> 
>>> [Dave]
>>> I disagree here. The reason being ... What do you care about the
>>> intermediate NHs wrt the EBGP bootstrapping since you can route to/through
>>> different intermediate NH? [...]
>> 
>> [Pekka]
>> I agree with Dave here.  BGP hello mechanism does not monitor the
>> liveness of the 3rd party nexthops, and therefore I think it goes
>> beyond the scope of BFD to do that, even though BFD is meant to detect
>> forwarding problems (which obviously would happen if the 3rd party
>> next-hop would go away).
> 
> BFD to monitor the liveness of the BGP peering session is good.

No, it is bad :-) We state that you can attempt to use BFD for control plane
liveness (you can do anything you want) but, BFD is for the control plane
and we don't suggest that you use it for the control plane liveness at all.
We suggest that control protocols Hello packets run sedate and instead, use
BFD just for the forwarding plane.

> In most eBGP cases, this is also sufficient to monitor the ability of
> the announced nexthop (usually the same as the address of the peering
> session) to forward traffic.
> 
> In the case of third party nexthops, it isn't.
> 
> To give an example that may have bitten some people in this working
> group, presume an exchange point where peering is done via eBGP.
> In the case that third party nexthops are permitted, you can announce
> a nexthop that would normally be considered reachable because you are
> on a shared subnet.  If the nexthop is not reachable for some reason,
> but the peering session is up, a blackhole will occur.
> 
> Solutions: 
> - Disallow third party nexthops.
> - Run a BFD session on your nexthop.

Run a BFD session on the NH but, don't have it test the BGP session. Only
the NH. Echo mode is wonderful for this :-)

-DWard