With the eBGP session between PE1 and CE1 established but advertising nothing, this video configures the route policy needed to start advertising CE1’s loopback address into BGP — then works through the next-hop-self problem that prevents other PE routers from using iBGP routes received from PE1.

BGP on JunOS only advertises what you explicitly tell it to advertise through route policy. To export CE1’s loopback address of 11.11.11.11/32 towards PE1 we create a policy statement on CE1 that matches routes from the direct protocol with an exact prefix match of 11.11.11.11/32 and sets the action to accept. This policy is then applied as an export policy to CE1’s external BGP group. Once committed, show bgp neighbor on CE1 confirms advertised prefixes has gone from zero to one.

On PE1 we verify the route is being received from CE1 using show route receive-protocol bgp with the peer address. The route appears correctly with its AS path showing 65001 and an origin code of IGP. So far so good.

The problem becomes apparent on PE2 and PE3. Using show route protocol bgp we find no routes — but adding the hidden flag reveals the route is there but marked as hidden and unverified. The explanation is a fundamental iBGP behaviour — when PE1 received the route from CE1, the next hop in the BGP update is CE1’s interface address 172.16.1.111. PE2 and PE3 have no route to that address, so they can’t resolve the next hop and the route is unusable.

The fix is a next-hop-self policy on PE1 applied to the internal BGP group as an export policy. This policy has a single term — set the next hop to self — which means PE1 rewrites the next hop on any BGP routes it advertises to its iBGP neighbours to point to itself rather than the original source. Once applied PE2 and PE3 can now resolve the next hop via their OSPF-learned route to PE1’s loopback, and the routes appear correctly in their routing tables.

The video closes by explaining the iBGP route reflection problem — PE4 still doesn’t receive the route because iBGP split horizon prevents PE2 or PE3 from forwarding a BGP-learned route to another iBGP neighbour. The solution — a route reflector rather than a full mesh — is introduced conceptually and flagged as the subject of an upcoming video.