[c-nsp] Good practices for peering

[Danny McPherson]

On Jan 2, 2006, at 12:16 PM, Richard J. Sears wrote:

> Danny -
>
> You said :
>
> < I'd explicitly set next-hop-self on the sessions>
>
> What is the benefit to doing this in a peering relationship...?

I'm a fan of setting the BGP next hop to "self" explicitly on external
BGP peering sessions (and internal ones, though with different
motivations) for a couple of reasons.  The first of which is that it's
otherwise derived dynamically depending on media type and may
result in either routing OR forwarding brokenness (the former of
which may result in the latter as well :-).

Consider a multi-access network such as Ethernet where there are
three BGP speakers residing on the same IP subnet.  Routers A & B
are in the same AS (or not, doesn't really matter) and router C is in
another AS.  Router A and router B iBGP peer, and router B also has
an eBGP peering session with router C.  Typical BGP rules would
suggest that when router B receives a route from router A and it
advertises that route on to router C it preserves the BGP next hop
because the peers reside on the same IP subnet.  This should be
fine so long as this is a true broadcast multi-access network (no
VLANs between peers, etc..) and router C can forward packets
directly to router A.

However, if this were NBMA media such as Frame Relay or ATM,
or if some policy was employed such that router C couldn't forward
packets directly to router A (such as MAC filtering), forwarding
would be broken as router C wouldn't be able to reach the next
hop that was advertised by router A.

One occurrence of this in the real world was when some of the
traditional multi-access NAPs employed true multi-access media
(e.g., FDDI) and a common IP subnet for participants.  This evolved
to NBMA with ATM VCs provisioned between peers while a common
IP subnet still existed and was used by some.  In cases before where
FDDI provided connectivity for folks that were advertising routes and
preserving the BGP next hop in the past, this was now broken unless
a VC[s] was provisioned between two routers that weren't "officially"
peers.

What made this really interesting was that folks began [albeit quite
questionably] providing transit services via the NAP fabric and
would advertise the "customer" routes to peers with the original
BGP next hop, and advertise peer routes to the "customers" with
the original next hop.  In essence what they were doing is enabling
control plane connectivity but would never need to be in the actual
data path - this changed with NBMA that required provisioning of
VCs between all folks that intended to exchange traffic directly.
It also changed when folks that were being "gamed" at the time
instituted MAC layer and similar filters and reset BGP next hops
to the peers IP address explicitly in order to to discourage such a
practice.

Given, there are instances where preserving the next hop and
enabling this "optimal forwarding path" is desirable, but in those
cases I'd recommend setting it explicitly, not default to behavior as
such.

Note that this only effects NLRI advertised to the peer, not
received from the peer.  On routes received from peers I'm a fan
of setting the received next hop to that of the peers IP address
for reasons outlined above.

As far as iBGP is concerned, setting next hop to self has many
benefits.  E.g.,  update packing optimization per fewer next hops
existing, converge quicker by setting it to an IP address in the IGP
(don't put external subnets in or IGP unless absolutely necessary
- as Arnold mentioned as well), load-balancing, TE, etc..

HTH,

-danny