Refer to the exhibit.

All iBGP routes should have the iBGP peer as the next hop address. Why is this not the case for
BGP routes learned between R1 and R2?

A.
R2 is missing the next-hop-self option under the neighbor command for R1

B.
ISP-A is missing the next-hop-self option under the neighbor command for R1

C.
ISP-B is missing the next-hop-self option under the neighbor command for R1

D.
R2, ISP-A, and ISP-B are missing the next-hop-self option under the neighbor command for R1

Explanation:
When you have an e-bgp peer, the next hop is always changed to your peering IP address (nexthop-self, or setting the IP to its own). This is because ebgp peers don’t have any need to know
about all the details inside another ASN. Next hops are measured by an AS Path.
In i-bgp peers, information is not changed. The theory is that everyone know about everything
inside the same AS! Now, this is nice as long as that’s true!
What happens when the link between two e-bgp peers (obviously known to the edge router
because it’s connected) is NOT exchanged via any IGP? Suddenly other internal routers learn ibgp routes that appear to be unreachable. They show an unknown IP as the next hop.
Ascii digram:
(AS 100) — 10.100.1.1———-10.100.1.2 (AS200-R1)10.200.1.1——-10.200.1.2(AS200-R2)
AS 200 routers are i-bgp peers (who could be multiple hops away from each other but this is a
short example!). AS100-200 exchange routes over 10.100.1.0 network.
R1 shows all routes with 10.100.1.1 as the next hop. This is simple and per spec, and is reachable
because it’s connected.
UNLESS R2 is aware of the 10.100.1.0 network, it will learn all of AS100’s routes and will view
them all as unreachable.
If R1 sets “next-hop-self” when pointing to R2s neighbor statement, all of the routes will be
changed to reflect 10.200.1.1 as the next hop which is reachable.