|
The NEXT_HOP attribute is a well-known
mandatory attribute (type code 3). In IGP, the next hop to reach a
route is the IP address of the router that has announced the route.
The NEXT_HOP concept with BGP is
slightly more elaborate and takes one of the following three forms:
- For EBGP sessions, the next hop is
the IP address of the neighbor that announced the route.
- For IBGP sessions, for routes
originated inside the AS, the next-hop is the IP address of the
neighbor that announced the route.
For routes injected into the AS via
EBGP, the next hop learned from EBGP is carried unaltered into IBGP.
The next hop is the IP address of the EBGP neighbor from which the
route was learned.
- When the route is advertised on a
multiaccess media (such as Ethernet, Frame Relay, and so on),
the next-hop is usually the IP address of the interface of the
router, connected to that media, that originated the route.
Figure
illustrates the BGP NEXT_HOP attribute environment.
The San Francisco router is running
an EBGP session with the Los Angeles router and an IBGP session with
the San Jose router. The San Francisco router is learning route
128.213.1.0/24 from the Los Angeles router. In turn, the San
Francisco router is injecting the local route 128.212.1.0/24 into
BGP.
The San Jose router learns route
192.212.1.0/24 via 2.2.2.2, the IP address of the IBGP peer
announcing the route. Thus, 2.2.2.2 is the next hop, according to
the definition, for San Jose to reach 192.212.1.0/24. Similarly, the
San Francisco router sees 128.213.1.0/24 coming from the Los Angeles
router via NEXT_HOP 1.1.1.1. When it passes this route update to the
San Jose router via IBGP, San Francisco includes the NEXT_HOP information, unaltered. Thus, the San Jose router would receive the
BGP update about 128.213.1.0/24 with NEXT_HOP1.1.1.1. This is an
example of the EBGP next hop being carried into IBGP.
As you can see from the preceding
example, the NEXT_HOP is not necessarily reachable via a direct
connection. San Jose's next-hop for 128.213.1.0/24, for example, is
1.1.1.1, but reaching it requires a pathway through 3.3.3.3. Thus,
the next-hop behavior mandates a recursive IP lookup for a router to
know where to send the packet. To reach the NEXT_HOP 1.1.1.1, the
San Jose router will recursively look into its IGP routing table to
see if and how 1.1.1.1 is reachable. This recursive search continues
until the router associates destination 1.1.1.1 with an outgoing
interface. The same recursive behavior is performed to reach
NEXT_HOP 2.2.2.2. If a hop is not reachable, BGP would consider the
route as being inaccessible.
The following is a sample of how IP
recursive lookup is used to direct the traffic toward the final
destination. Figures
and list
the BGP and IP routing tables for the San Jose router illustrated in
Figure .
Figure
indicates that 128.213.1.0/24 is reachable via NEXT_HOP 1.1.1.1. The
IP routing table shows that network 1.1.1.0/24 is reachable via
NEXT_HOP 3.3.3.3. Another recursive lookup in the IP routing table
indicates that network 3.3.3.0/24 is directly connected via Serial
0. This would indicate that traffic toward NEXT_HOP 1.1.1.1 should
go via Serial 0. The same reasoning applies to deliver traffic
toward NEXT_HOP 2.2.2.2.
Care must be taken to ensure that
reachability of the NEXT_HOP is advertised via some IGP or static
routing. In case the BGP NEXT_HOP cannot be reached, the BGP route
would be considered inaccessible.
|