Understanding the NEXT_HOP Attribute in BGP

In BGP, every route that gets advertised comes with some additional information known as path attributes. One of the most important and commonly seen among them is the NEXT_HOP attribute.

This attribute simply tells the router:

“If you want to reach this network, send the packet to this IP address (i.e., this is your next hop).”

---

What is NEXT_HOP in BGP?

The NEXT_HOP is a path attribute that is attached to all BGP route advertisements.

It tells the receiving router which IP should be used as the next hop to reach a particular network.

This is different from protocols like OSPF or EIGRP, where the next hop is usually just the IP of the router that sent the route. In BGP, the next hop can be a different router altogether – depending on how the route was learned and forwarded.

Let’s look at a few common scenarios to understand how the NEXT_HOP attribute behaves.

---

Scenario 1: eBGP Peering

When BGP peers are in different autonomous systems (i.e., eBGP), the behavior is straightforward.

• If R1 sends a route to R2 over an eBGP session,
• The NEXT_HOP will be the IP address of the interface that R1 uses to reach R2.

In the above topology, we have three routers connected in a straight path:

• R1 in AS100
• R2 in AS200
• R3 in AS300

The network 10.0.0.0/8 is connected to R1. When R1 advertises this network to R2 over eBGP, the NEXT_HOP is set to 1.1.1.1, which is the IP of R1’s interface facing R2.

Next, when R2 advertises the same route to R3 (again over eBGP), it updates the NEXT_HOP to 2.2.2.1 – the IP of R2’s interface that connects to R3.

This is how BGP behaves in eBGP peering – the NEXT_HOP is always updated to the IP address of the interface used to send the BGP update.

This is usually fine, since eBGP peers are directly connected and can reach each other easily.

In this case, the next hop is the advertising router itself, just like what you’d expect.

---

Scenario 2: iBGP Peering (Split Horizon Applies)

When BGP peers are in the same autonomous system (i.e., iBGP), the situation is different.

Here, BGP follows the split horizon rule, which says:

A route learned from one iBGP peer cannot be advertised to another iBGP peer.

So, in most cases, an iBGP router won’t receive a route from another iBGP router unless it’s the original source.

As a result, NEXT_HOP doesn’t even come into play in regular iBGP-to-iBGP forwarding – because the route isn’t passed on.

---

Special Case: Route Learned from eBGP, Forwarded to iBGP

There’s one special case that often creates confusion:

• A router learns a route from an eBGP peer.
• Then it advertises that route to an iBGP peer.

In this case, the NEXT_HOP is not updated to the IP of the internal router that is forwarding the route.

Instead, the original next hop – the IP of the eBGP peer – remains in the update.

In the above  topology, the setup is slightly more complex:

• R1 is in AS100
• R2, R3, and R4 are all in AS200
• R1 and R2 have an eBGP peering
• R2 and R4 have an iBGP peering
• R3 is not running BGP, but is part of the AS and may be used to send packets out

R1 has a directly connected network: 10.0.0.0/8. When R1 advertises this route to R2 over an eBGP session, the NEXT_HOP is set to 1.1.1.1 — R1’s IP.

Now, when R2 advertises this same route to R4 (both are in the same AS and are iBGP peers), the NEXT_HOP remains 1.1.1.1.

Unlike eBGP, in this case BGP does not change the NEXT_HOP, even though the update is coming from R2. This is a common behavior when a route learned from an eBGP peer is passed to an iBGP peer.

This design allows other routers inside the AS (like R4) to choose their own best path to exit the AS – either via R2 or R3 – based on reachability to the original next hop (1.1.1.1).

---

Why is this behavior useful?

If R2 had replaced the NEXT_HOP with its own IP while advertising to R3, then all internal traffic would be forced to exit via R2, even if R3 had a better path to the destination.

By preserving the original next hop (R1’s IP), routers inside AS200 (like R4) have the flexibility to choose whether to send the data out via R2 or R3 – depending on internal IGP metrics, interface load, or policy.

This rule allows more flexible outbound routing within an autonomous system.

Most enterprise or ISP networks have multiple edge routers that connect to external networks. If every edge router replaced the NEXT_HOP with its own IP, then:

• All internal routers would end up forwarding packets to that one edge router.
• Even if there were other, better exit points, they wouldn’t be used.

By preserving the original next hop, internal routers can choose different exit points based on IGP reachability or policy.

This helps in:

• Load balancing outbound traffic
• Avoiding unnecessary congestion on a single edge router
• Designing more flexible and scalable AS-level routing

---

The ORIGIN Path Attribute in BGP

The ORIGIN attribute in BGP is used to indicate how the route was originated at the source router – i.e., how the prefix first entered the BGP domain.

This information is attached by the originating router and stays with the route as it propagates through other BGP routers.

---

How ORIGIN is Set

There are three ways the ORIGIN value can be set, depending on how the router learned or injected the route into BGP.

---

1. IGP (i) – When network is advertised using network command

This is the most common case. In Cisco and similar routers, we advertise a prefix into BGP using the network command:

router bgp 100

 network 10.0.0.0 mask 255.0.0.0

Here, the router is telling BGP:

“I want to advertise this network which is reachable inside my AS.”

In this case, the ORIGIN is set to IGP, and represented by the letter i.
As per RFC 4271, IGP means the NLRI is interior to the originating AS.

---

2. INCOMPLETE (?) – When network is learned via redistribution

If we don’t use the network command and instead redistribute routes from another protocol (like OSPF or static routes) into BGP, then the ORIGIN is marked as INCOMPLETE.

In this case, BGP doesn’t have clear information about where the route came from originally, so the ORIGIN value is shown as:

? → INCOMPLETE

This doesn’t affect functionality – but BGP considers it a lower preference compared to IGP.

---

3. EGP (e) – When learned from an old EGP router

If the route is learned from a neighbor running EGP (Exterior Gateway Protocol), the ORIGIN is set to:

e → EGP

This is rarely seen today, since EGP has been mostly replaced by BGP. But the value is still supported for compatibility.

---

Preference Order of ORIGIN Values

When BGP receives multiple routes to the same destination, and all other factors (like local preference, AS path, etc.) are equal, BGP uses the ORIGIN attribute as a tie-breaker.

The preference order is:

IGP (i) > EGP (e) > INCOMPLETE (?)

So if one path has ORIGIN i, and another has ?, BGP will prefer the one with i.

---

Summary :

• NEXT_HOP tells a router where to forward packets to reach a given network.
• In eBGP, the next hop is the advertising router’s IP.
• In iBGP, routes are not re-advertised due to split horizon — so NEXT_HOP is usually not involved.
• Exception: When an eBGP-learned route is forwarded to an iBGP peer, the NEXT_HOP is not changed. This behavior allows internal routers to choose their own best exit point from the AS.

• ORIGIN is a BGP path attribute that tells how a route was originated.
• It is set once by the originating router and remains unchanged as the route propagates.
• Three possible values:
  • i → IGP: Route originated from within the AS (e.g., via network command)
  • e → EGP: Route received from an old EGP neighbor
  • ? → INCOMPLETE: Route redistributed from another protocol or unknown source
• Preference order: i > e > ?

This attribute helps when BGP has to choose between otherwise equal paths, and also gives useful visibility during troubleshooting or route analysis.