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

Jeffrey Haas <jhaas@nexthop.com> Fri, 28 October 2005 15:03 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVlN-0003Nc-BL; Fri, 28 Oct 2005 11:03:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVlM-0003NB-Ic for rtg-bfd@megatron.ietf.org; Fri, 28 Oct 2005 11:03:24 -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 LAA22790 for <rtg-bfd@ietf.org>; Fri, 28 Oct 2005 11:03:08 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVyr-0008Vf-UN for rtg-bfd@ietf.org; Fri, 28 Oct 2005 11:17:27 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with SMTP id 854F712DA1F; Fri, 28 Oct 2005 15:00:05 +0000 (GMT)
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 245JJbo8j0155Mo1; Fri, 28 Oct 2005 14:59:36 GMT
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 047JJbo8Z0046Mo1; Fri, 28 Oct 2005 14:59:25 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.26F); Fri, 28 Oct 2005 14:59:25 GMT
X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw2.EXCHPROD.USA.NET
X-USANET-MsgId: XID409JJbo8A1256Xo1
Received: from localhost ([65.247.36.31]) by gw2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:59:25 -0600
Date: Fri, 28 Oct 2005 10:59:24 -0400
From: Jeffrey Haas <jhaas@nexthop.com>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20051028145924.GG18406@nexthop.com>
References: <BF852362.149BF%dward@cisco.com> <Pine.LNX.4.64.0510280829120.15380@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0510280829120.15380@netcore.fi>
User-Agent: Mutt/1.4.2.1i
X-OriginalArrivalTime: 28 Oct 2005 14:59:25.0587 (UTC) FILETIME=[300E9630:01C5DBD0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: rtg-bfd@ietf.org, David Ward <dward@cisco.com>, 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

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


-- 
Jeff Haas 
NextHop Technologies