Subject: RE: "third party" next-hop

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 26 Jul 2002 12:49:04 -0400

I think it boils down to:
   IF (nexthop is on subnet of interface used to reach peer) OR (ebgp
multi-hop enabled) OR (IBGP) THEN
    Accept it
ELSE
    Toss it

Older IOS (less than 12.0.?) did accept any next-hop.

Of course you could have another shared subnet that you are not peering
across--I don't think this case was ever considered/implemented.  So you
have a point (there are many things like this in the RFC).  I don't think
implementing this to the letter would be practical (and it would be
difficult to write, if possible at all).

-$0.02

-----Original Message-----
From: Sprzaczkowski, Krzysztof [mailto:[email-masked]] 
Sent: Friday, July 26, 2002 12:31 PM
To: [email-masked]
Subject: "third party" next-hop 

I have a question about 'third party' next-hop in the context of IPv6 routes
sending over IPv4 session. Does 'third party' next-hop make sense in such
situation? Both documents draft-ietf-idr-bgp4-17 (chapter 5.1.3 NEXT_HOP)
and RFC 2858 (chapter 2 Multiprotocol Reachable NLRI - MP_REACH_NLRI) say
that for 'third party' next-hop peer X should share a common subnet with
received next-hop address. According to this, should we compare next-hop
address subnet with peer X address subnet (not with interface's address
subnet where a given peer is established)?

Krzysztof Sprzaczkowski

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Jul 2002 14:00:14 -0400

On Fri, Jul 26, 2002 at 12:49:04PM -0400, Natale, Jonathan wrote:
> across--I don't think this case was ever considered/implemented.

This is fine so long as you don't receive a third-party nexthop
for an subnets that you both have configured, but aren't actually
the same subnet.

(Think separate rfc 1918 subnets that are similarly numbered.)

If you are concerned about receiving third party announcements,
force the nexthop to be first party to your peering session.  That
will result in sub-optimal forwarding, but it should still work.

-- 
Jeff Haas 
NextHop Technologies