Subject: [Idr] BGP nexthop calculation question

From: Mike Cleary <[email-masked]>
Date: Thu, 24 Feb 2005 15:19:51 -0500

Hello,
I have a question with regards to the nexthop of BGP updates.  See the 
attached diagram.  As noted in the Diagram TR1 is connected to RUT via 
external BGP on network 10.10.10.0/24, TR2 is connected to RUT via 
Internal BGP.  RUT has a static route to network 2.2.2.0/24 with the 
nexthop set to TR3's network 0 ip address (10.10.10.36).  RUT is 
configured to redistribute static routes to BGP.  RUT uses itself on 
network 0 (10.10.10.Y) as the nexthop when advertising this route to TR1 
and TR2 even though nexthop self is not set to enabled.  I was 
wondering, is this behavior is correct?  I looked at section 5.1.3 of 
draft-ietf-bgp4-26 for this information and found the wording to be a 
little confusing.  Are static routes considered locally originated?
Thanks,
~Mike

-- 
*********************************************
Michael Cleary     Email: [email-masked]
IPv4 Consortium      UNH InterOperability Lab
121 Technology Dr., Suite 2, Durham, NH 03824
Phone: 603-862-3941    http://www.iol.unh.edu
*********************************************

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Nader Salehi <[email-masked]>
Date: Thu, 24 Feb 2005 17:00:16 -0800

Mike,

Assuming that TR1, RUT, and TR3 are not on a multi-access media
(Ethernet, Frame Relay), this is a correct behavior.  RUT advertises
2.2.2/24 to an eBGP peer, so the next hop will be the IP address of
the RUT.

As for your other question, if you source a route into BGP --via
either the 'network' or the 'redistribute' commands-- the route is
considered local and is advertised to peers as such.  The only
difference between 'network' and 'redistribute' commands is in the
ORIGIN attribute.  The former sets the origin to IGP whereas the
latter sets the origin to Unknown.

Hope this helps.

Nader

---

From: [email-masked]
Date: Fri, 25 Feb 2005 08:10:54 -0500

Should RUT advertise this route to the iBGP peer with the nexthop set 
to itself
also?

---

From: Mike Cleary <[email-masked]>
Date: Fri, 25 Feb 2005 10:01:54 -0500

Nader,
What is the case when this route is being advertised to an IBGP peer? 
 This quote from section 5.1.3 is a little confusing:

      When announcing a locally 
      originated route to an internal peer, the BGP speaker SHOULD use
      as the NEXT_HOP the interface address of the router through which
      the announced network is reachable for the speaker; if the route
      is directly connected to the speaker, or the interface address of
      the router through which the announced network is reachable for
      the speaker is the internal peer's address, then the BGP speaker
      SHOULD use for the NEXT_HOP attribute its own IP address (the
      address of the interface that is used to reach the peer).

Take my example where RUT is originating a static route with the nexthop 
set to TR3 (10.10.10.X), is "the router" from the first part of the 
sentance refering to TR3 or is it refering to RUT?  If this is refering 
to TR3 than the nexthop should be 10.10.10.X right?
Thanks,
~Mike

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 25 Feb 2005 09:40:37 -0500

Mike,

> Should RUT advertise this route to the iBGP peer with the nexthop set 

In general:

If the nexthop on a router is being sent to a BGP peer (internal or
external) and it shares a logical subnet with that nexthop, it MAY
send the BGP update with the original nexthop.

If the nexthop on a router is being sent to an eBGP peer and
the nexthop is not on the same logical subnet, it will in almost
every case announce the route as a first party nexthop and thus
use the IP address of the local end of the peering session with the eBGP
peer as the nexthop.  (An exception is multihop eBGP peering and the
behavior is somewhat out of spec.)

If the nexthop on a router is being sent to an iBGP peer, then the
nexthop is typically sent unaltered.  This behavior may be modified
via a "next-hop-self" feature.  

Confederation behavior is slightly different.  It is permissable
for nexthops to be sent unaltered (like iBGP) in a confederation.
This means if the implementation chooses to enforce nexthop on subnet
on a confederation eBGP peering session, it is conformant.  However,
this is atypical behavior.

-- 
Jeff Haas 
NextHop Technologies

---

From: Mike Cleary <[email-masked]>
Date: Fri, 25 Feb 2005 10:46:55 -0500

Jeffrey,
So if the nexthop self feature is not enabled than it should send the 
original nexthop to an iBGP peer right?
~Mike

---

From: Acharya <[email-masked]>
Date: Mon, 28 Feb 2005 01:38:37 +0000 (GMT)

"the router" is TR3 in your topology. And your right
in saying that the NH should be 10.10.10.X in
advertisements to both TR1 and TR2. If NHSelf is
configured on RUT for Nbr TR2&/TR1, the NH will be
changed to RUT's IF-addresses accordingly.

Acharya

> >>little confusing.  Are static routes considered

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: Acharya <[email-masked]>
Date: Mon, 28 Feb 2005 02:48:20 +0000 (GMT)

Jeff,

Infact, since the latest versions of BSD, and Linux
since the start, allow IF-address configuration as in:
eth1 = 10.10.10.1/24 and eth2 = 10.10.10.2/24, its
next to imppossible to actually detect, on the RUT,
whether two Nbrs have direct connectivity or not.
Infact, this change in behaviour, in BSD, is to allow
for IPv6-LinkLocal addresses, which by default reside
in the same subnet.

So, Id like to suggest that, in the latest BGP-draft,
we add a sentence saying:

"The default behaviour for directly connected subnets
is that the NextHop goes unchanged (whether
advertisement is to an EBGP or IBGP neighbor), but it
is the administrators responsibility to ensure that
the router specified as the Nexthop is infact directly
reachable to the advertised neighbor. If the Nexthop
is not directly reachable to the advertised neighbor,
it MUST be configurable to set the Nexthop to the
address of the interface that is used to reach the
neighbor".

The above statement makes the provision of a command
akin to "nexthop-self" mandatory.

This would become a requirement if both TR2 and TR1,
in Cleary's example, are IPv6-Link-local neighbors
which donot have direct reachability to each other.
Then its impossible for the RUT to check whether "the
router" is reachable for the neighbor!

I feel that the NextHop related statements in MP-BGP
RFC 2858 (which just reflected the statements in the
then BGP-draft) are far more messed up than the ones
we have here in draft-26 and need to be re-worked as
well.

Acharya.