Subject: third party nexthop

From: [email-masked] (Vivian_Lu)
Date: Mon, 24 Nov 1997 16:24:36 -0500

Hi,

We are currently implementing bgp4, and have the following questions.

In the latest draft, (section 5.1.3 NEXT_HOP)

  "The NEXT_HOP path attribute defines the IP address of the border
   router that should be used as the next hop to the destinations listed
   in the UPDATE message.  When advertising a NEXT_HOP attribute to an
   external peer, a router may use one of its own interface addresses in
   the NEXT_HOP attribute provided the external peer to which the route
   is being advertised shares a common subnet with the NEXT_HOP address.
   This is known as a "first party" NEXT_HOP attribute.  A BGP speaker
                                                         ^^^^^^^^^^^^^
   can advertise to an external peer an interface of any internal peer
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   router in the NEXT_HOP attribute provided the external peer to which
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the route is being advertised shares a common subnet with the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   NEXT_HOP address.  This is known as a "third party" NEXT_HOP
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   attribute.  A BGP speaker can advertise any external peer router in
   ^^^^^^^^^
   the NEXT_HOP attribute provided that the IP address of this border
   router was learned from an external peer and the external peer to
   which the route is being advertised shares a common subnet with the
   NEXT_HOP address.  This is a second form of "third party" NEXT_HOP
   attribute."

It seems to me with the underlined restriction in the "third party" 
NEXT_HOP case, the internal peer whose interface address is advertised
in the NEXT_HOP attribute by the BGP speaker must be on the same subnet
as BGP speaker and its external peer.

My question is when and how does this get used in the real world scenario?
why will there be a need of a IBGP and EBGP running on two different machines
on the same subnet?
and how many vendors actually enforce this checking?

Your help is very much appreciated.

Vivian.
------------------------------------------------------------------------
Vivian H. Lu                 E-MAIL: [email-masked]
NetEdge Systems, Inc.        PHONE: (508)670-2934
85 Rangeway Road,            FAX: (508)262-0802
Billerica, Massachusetts.
------------------------------------------------------------------------

---

From: Tony Li <[email-masked]>
Date: 24 Nov 1997 15:12:41 -0800

> as BGP speaker and its external peer.

Yup, that's what that's trying to say.

> My question is when and how does this get used in the real world scenario?

How IS it used, or how COULD it be used?  Suppose that you had a LAN for an
inter-domain interconnect where particular providers showed up with more
than one router.  One router could be used to distribute routing info to
neighbors, and this feature would cause traffic to actually short cut this
router.

I'm not aware of anyone who actually makes use of this as the redundancy in
this mechanism is somewhat lacking...

> and how many vendors actually enforce this checking?

I know of at least two implementations that check this.  Further, not
checking is pretty much guaranteed to be suicidal (to your traffic).

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 02 Dec 1997 16:45:57 -0500

> My question is when and how does this get used in the real world scenario?

Major providers at a major interconnect.

> why will there be a need of a IBGP and EBGP running on two different machines

Redundancy.  One or more providers may have two or more routers each
on the same media.

> and how many vendors actually enforce this checking?

I don't know of any that don't enforce this.  It can be overridden for
multihop EBGP but that's a hack used more for testing and for some very
ugly hacks.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 02 Dec 1997 17:16:56 -0500

> this mechanism is somewhat lacking...

Tony,

Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old
NSFNET days and send tons of third party routes?  I thought for a
while you wrote the BGP code on the Barrnet side of this and I wrote
the BGP code on the NSFNET side.  (Senility?  Yours or mine? :)

Still goes on today.  We have two routers at some NAPs and two or more
at some private interconnects and so do other providers.

In any case, you do need to implement third party routing and you do
need to get it right and the quoted section of the RFC is correct.

Cheers,

Curtis

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Dec 1997 14:23:58 -0800 (PST)

Curtis,

Well, it's definitely senility cause I don't know of an ENSS that was ever
at Hayward.  Stanford, yes....  ;-)

I don't dispute that the code is out there to support it.  I just don't
know of people using it.

   Still goes on today.

Ok, I sit educated.  ;-)

Tony

---

From: Erik Sherk <[email-masked]>
Date: Tue, 02 Dec 1997 17:57:34 -0500

> at Hayward.  Stanford, yes....  ;-)

We certainly used it on ENSS136. Jeez, what does it say when I can
remember that number, but can't remember what my wife wants me to pick
up at the store tonight? Must be Senility :-)
 
> I don't dispute that the code is out there to support it.  I just don't

Yes, we use it extensivly today, mainly in a BGP confederation context.

Erik

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Dec 1997 14:13:15 -0500

> at Hayward.  Stanford, yes....  ;-)

Oops.  Off by one hop.

> I don't dispute that the code is out there to support it.  I just don't

The problems with partial connectivity in bridged or switched level 2
broadcast media have prompted many to disable third party routing
using next-hop-self.  Where problems have not occurred (for example,
single level 2 switch without this sort of bug or physical level 2
segment.

It is probably worth mentioning that it is a good idea to have a per
peer configurable option to disable third party routing and substitute
ones own interface address.  Doesn't hurt to call that option
next-hop-self since people are used to that name.

Curtis