Subject: issue 61

From: Yakov Rekhter <[email-masked]>
Date: Thu, 17 Oct 2002 09:01:52 -0700

61) Next Hop for Redistributed Routes
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: There was text suggested, but no discussion.
  
  Discussion:
  
  Jonathan began this thread with:
  
  I propose adding:
       
  "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)."
       
  AFTER
  
  "When sending a message to an internal peer, the BGP speaker
        should not modify the NEXT_HOP attribute, unless it has been
        explicitly configured to announce its own IP address as the
        NEXT_HOP."
  
  There has been no discussion on this.
  
  This is discussed in the "Next hop for redistributed routes" thread.
  
  Issue 14 closed in favor of this issue.
  
  In response to Yakov's call for input, Michael responded that:
  
  Section 5.1.3 explictly states what to do when originating to an
  etternal peer.  #2 covers one hop away, #3 covers more than on hop away.
    #1 talks about sending to an iBGP peer, but only when propergating a
  route received from an eBGP peer.
  
         1) When sending a message to an internal peer, the BGP speaker
         should not modify the NEXT_HOP attribute, unless it has been
         explicitly configured to announce its own IP address as the
         NEXT_HOP.

  Text similar to #2 shoud be added, in their own bullit items to #1 such
  as what was suggested by Jonathan Natale (text is above.)

Replace:

  1) When sending a message to an internal peer, the BGP speaker
  should not modify the NEXT_HOP attribute, unless it has been
  explicitly configured to announce its own IP address as the
  NEXT_HOP.

with:

  1) When sending a message to an internal peer, if the route is
  not locally originated the BGP speaker should not modify the
  NEXT_HOP attribute, unless it has been explicitly configured to
  announce its own IP address as the NEXT_HOP. 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).

In the absence of objections I'll make the above change.

Yakov.

---

From: [email-masked]
Date: Fri, 18 Oct 2002 11:10:22 +0200

I have some trouble in understanding part of the proposed text.
 " if 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)."

The way i understand this is:
We have a route in the routing database, whose next-hop happens  to be equal to
the address of one of the iBGP peers. (who in this case must be an internal BGP
peer which is exactly one hop away).

In this case we can avertise this route to this iBGP peer as long as we put the
next-hop field to the Ip-address which is assigned to our router on the interface
connecting us to the internal peer.

But, if my way of understanding the text is correct, then i get the impression we
have created a routing loop, as we have announced a route to a peer that actually
is routed through that peer. Therefore I guess my understanding of the text is
wrong, and i hope that somebody can put me straight here.

thanks,
hans.