Adjusting the Next-Hop Attribute

Problem

Your IBGP routers need to be able to resolve the BGP next hop of routes that are in external ASs.

Solution

To have IBGP routers reach addresses in external ASs, you change the BGP next-hop attribute on routes when it is distributed from EBGP into IBGP so that the routes always point to a next-hop address inside the local AS. You do this with a routing policy that defines the next hop as self (that is, this router):

[edit policy-options] aviva@RouterF# set policy-statement next-hop-self term 1 from protocol bgp aviva@RouterF# set policy-statement next-hop-self term 1 then next-hop self

Then apply the policy as an export policy in the IBGP group on the border router:

[edit protocols bgp] aviva@RouterF# set group internal-within-AS65500 export next-hop-self

Discussion

When an EBGP route arrives from another AS, it contains the physical address of the remote interface as the BGP next hop. If the EBGP router advertises this route within its IBGP network, the IGP routing table may not know about that next hop because it is a physical interface in another AS and might not have a way to reach it. Setting up a next-hop self policy allows the EBGP router that is advertising the route to IBGP to use itself as the next hop for the EBGP routes.

This recipe creates a simple routing policy that takes all BGP routes and defines the next hop of the route as self, which is the router on which the route resides. As with all JUNOS routing policies, you need to apply ithere, to the IBGP peer group as an export policy. It would be a mistake to apply the policy as an import policy in the EBGP group, because then all EBGP routes would be installed in the routing table with the local router as the BGP next hop, which would make the routes unusable.

See Also

Recipe 9.1