Next-hop self for in a eBGP session? Yes – definitely at Internet Exchanges.

Except for a small red notice by Jarek Rek from Hacking Cisco (CCIE R&S Practice Journal) and a great post by Petr Lapukhov Understanding third-party next-hop, some case studies etc – most of the world-wide-web-spread copy/paste-ready tutorials keep on teaching you that BGP next-hop in external BGP session is always set to the IP address of the neighbor that announces the route. Well, not always … – when all peers share the same segment (like they do at Internet Exchanges – IXPs), the prefixes re-advertised over that shared segment do not have their next-hop changed.
Let’s have a look into a situation as depicted below:

3rd party next-hop at IXP

Here, R2 announces prefix 2001:db8::/48 to R1 (with next-hop = B) and R1 re-advertises it to R3. By default, next-hop for 2001:db8::/48 is preserved by R1 and R3 receives 2001:db8::/48 from R1 with next-hop B. Consequently, R3 will send the traffic toward a prefix he has actually learned from R1 to some third-party – R2. This might even be an undesirable path for R3, specially if R3 and R2 do not peer at all.
To avoid situations like this, it is a very common advise to set the next-hop to self when advertising prefixes at the IXP. Of course, the next-hop can be overwritten by a receiver and some experts strongly recommend applying an inbound route policy to IXP bilateral peerings which sets the next-hop for accepted prefixes to the BGP peer that sent the prefix.

Well, most IXPs use route-reflectors anyway :-). Nevertheless, it is good to keep this default BGP behaviour in mind when setting bilateral peerings over some shared media.