BGP - next hop self command.

Question

Hi,
I am learning bgp...need your help...
Connectivity is like as follows:
Router A (ebgp)  Router B (ibgp) Router C (ibgp) Router D
when loopback subnet of Router A is received at Router C, defalult with next hop address of outgoing interface of router A.
after configuring next hop self command on router B to C, on Router C then show next hop add outgoing interface of router B. k no prob.
but same subnet isn't received on router D because of ibgp split horizon rule; used route-reflector client on router C. then router D received subnet of Router A; but shows next hop address outgoing interface of router B. even though i used next hop self on router C towards D.; router D didn't show next hop add of router C. Why ??
Its ok i used IGP i.e. EIGRP in between router B, C & D. it works.
=> why next hop self doesn't work in this scenario ?? & is it the reaseon we need to use IGP into IBGP AS ??
--Sandy.

Answer 1

Hi,
I agree with Milan, you can use a route-map applied in the outbound direction to rewrite the next-hop.
Another option is to use the "next-hop-self all" (note the keyword all), that will update the next hop of both iBGP and eBGP learned prefixes:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html#wp4972925610
The use case for this (next-hop-self all) is I see is in a DMVPN Network, but not for an ISP - MPLS/VPN Provider.
Regarding BGP and the need of IGP, think that different protocols have different purposes. The IGP, specially used in large-scale deployments, is used to build the topology and provide reachability to internal prefixes. The IGPs used in large-scale designs, IS-IS/OSPF, are good here because as they are link-state protocols and have a complete view of the network and will detect fast a change and run SPF for a new topology if needed. Furthermore, they have extensions to use MPLS/Traffic Engineering.
Once the topology is build and the routers have reachability to internal prefixes, then you can run iBGP (typically between loopbacks) to provide reachability to external prefixes. BGP is very good to transport a good amount of prefixes, as it is based in TCP. If the IGPs could handle the amount of prefixes can handle BGP, then you would not need iBGP, you would redistribute (which is another option) them to the IGP and we will only have external BGP. However, in order to provide reachability and build and scalable network, you need BGP plus an IGP.
The reason of having the need of an iBGP full mesh is to prevent black-holes in the network. Think that routers A-B-C, A is running iBGP with C, which are edge routers receiving prefixes from other ASN´s. As B is not running BGP, when it receives a packet destined to an external network it will drop that packet as it has no information in the RIB.
There was also an old rule called synchronization that prevented the problem of advertising a black hole to another AS. The rule was that if the prefix is not in the IGP, BGP will not advertise that prefix. So, redistribution solved in the old days the problem of black holes and the rule of sync the problem of advertising them to other ASNs. As the networks got bigger and bigger, there was no point to redistribute the external prefixes to the IGP, so iBGP full-mesh/RRs were deployed and the sync rule disabled.
Hope this helps,
Jose.