Problem Statement :

On MX10003 (jade-re0, AS 65000) with two eBGP peers:

Peer     AS     Router ID Interface BGP NEXT_HOP

192.168.1.2 AS65200 (rack02) 10.2.2.2     et-0/1/0.0 192.168.1.2
192.168.2.2 AS65300 (rack03) 10.3.3.3     et-0/1/2.0 192.168.2.2

Both peers advertise prefix 172.16.100.0/24 (originated in AS65400 via rack04). ECMP multipath is enabled. Inline-jflow is configured on et-0/1/9 (ingress).

Observed jflow output:

NextHop:  192.168.2.2  (forwarding nexthop)
BGPNextHop: 192.168.1.2  (BGP nexthop)

Customer question: "Why does iBGP show BGPNextHop = 192.168.2.2 (matching NextHop) but eBGP shows BGPNextHop = 192.168.1.2 (not matching NextHop)?"

Topology: 

iBGP show BGPNextHop = 192.168.2.2 (matching NextHop) but eBGP shows BGPNextHop = 192.168.1.2 (not matching NextHop)

The jflow BGPNextHop field (RFC 3954 field 18) reports the BGP NEXT_HOP attribute as received in the BGP UPDATE message for the best-path route. For prefix 172.16.100.0/24, BGP best-path selection chose the route received from AS65200 peer 192.168.1.2 (lower Router ID 10.2.2.2 vs 10.3.3.3).

The received BGP NEXT_HOP of that route is 192.168.1.2. RPD correctly reports this as BGPNextHop. The NextHop/Gateway field (192.168.2.2) is the ECMP representative forwarding nexthop selected for the inline-jflow route record. These two fields represent different protocol layers and are not required to be equal.

The iBGP scenario appearing "correct" (BGPNextHop = Gateway = 192.168.2.2) is coincidental: the iBGP best-path winner happened to be peer 192.168.2.2, whose next-hop-self address matches the selected ECMP leg. This same alignment does not occur in eBGP because BGP best-path selected AS65200 (peer 192.168.1.2) while the ECMP representative leg is via AS65300 (peer 192.168.2.2).

For the broader limitation of inline-jflow with ECMP (where the same Gateway is reported for all flows regardless of which ECMP member actually forwarded each packet), refer to KB25308 [juniper.net]

Detailed Explanation:

Step 1: BGP best-path selection for 172.16.100.0/24

Both routes are equal on all attributes (localpref 100, same MED, same AS path length) until the Router ID tiebreak:

AS65200 route: Router ID 10.2.2.2
AS65300 route: Router ID 10.3.3.3

Winner: AS65200 (10.2.2.2 < 10.3.3.3) -> active/best-path route

Result:

* Active route: BGP from peer 192.168.1.2 (AS65200), received BGP NEXT_HOP = 192.168.1.2
* MultipathContrib: BGP from peer 192.168.2.2 (AS65300), contributes nexthop to ECMP list

Step 2: ECMP forwarding table

Both routes are installed as ECMP. PFE hashes per-flow across both members:

NHDB 1048574 (Unilist):

 857 Unicast 192.168.1.2 et-0/1/0.0  Active Installed
 859 Unicast 192.168.2.2 et-0/1/2.0  Active Installed

Step 3: Inline-jflow route record (SRRD) --- one record per prefix

RPD sends one route record per prefix to the PFE via SRRD:

show sample-rr route-tbl ipv4 vrf 0 prefix 172.16.100.0/24
 Rec# OIF Gateway    BGP-Nexthop  AS-Idx
  1  110 192.168.2.2  192.168.1.2   7

* Gateway (OIF 110 = et-0/1/2.0): The RNICF_SELECTED representative ECMP leg = 192.168.2.2

* BGPNextHop: The received BGP NEXT_HOP attribute (bgpm_nexthop) of the active/best-path route = 192.168.1.2

These are two different fields with different RFC-defined semantics (RFC 3954 / RFC 7012):

Field         RFC Meaning                Value     Source

NextHop / Gateway Actual forwarding nexthop        192.168.2.2 ECMP selected leg

BGPNextHop     BGP NEXT_HOP attribute from received UPDATE. 192.168.1.2 Active route's bgpm_nexthop

Why iBGP Appears Correct --- Coincidence, Not Design

In the iBGP test scenario, both peers (192.168.1.2 = rack02, 192.168.2.2 = rack03) are in AS 65000 with next-hop-self configured.

BGP best-path for iBGP case uses Originator ID tiebreak:

Route via 192.168.2.2 (rack03): Originator ID 172.16.100.1
Route via 192.168.1.2 (rack02): Originator ID 192.168.3.2

Winner: rack03 (172.16.100.1 < 192.168.3.2) -> active route

Active route is from peer 192.168.2.2, which uses next-hop-self -> received BGP NEXT_HOP = 192.168.2.2.

The RNICF_SELECTED ECMP leg is also 192.168.2.2 (same peer).

Therefore:

BGPNextHop = bgpm_nexthop of active route = 192.168.2.2
Gateway  = RNICF_SELECTED leg     = 192.168.2.2
-> They match --- but purely by coincidence

If any route policy change caused the active route to flip to peer 192.168.1.2, iBGP would show the same "mismatch" as eBGP. The iBGP behavior is not by design.

iBGP code path unconditionally creates INH for all internal routes (Int flag) and there is no exception even when the nexthop is directly connected (e.g., next-hop-self). INH is still created.

But, in eBGP case, INH is not created for single-hop eBGP (Current PR case)

From the topology:

MX10003 (AS 65000) <-> rack02 (AS 65200, 192.168.1.2) --- directly connected on 192.168.1.0/30 via et-0/1/0.0
MX10003 (AS 65000) <-> rack03 (AS 65300, 192.168.2.2) --- directly connected on 192.168.2.0/30 via et-0/1/2.0

Both eBGP peers are on directly connected subnets -> single-hop eBGP -> no INH, direct Router NH.

Multi-hop eBGP follows the iBGP path --- INH is created for recursive resolution.

Regarding "multi-bgp-path" option under the hierarchy level "[edit services flow-monitoring version9 template template-name]": 

(Junos OS only) Enable multiple BGP path support for reporting an accurate BGP next-hop address for traffic load-balanced over multiple BGP peers in the ingress direction only. Without this statement, we report only the first in a list of next hops. To contain this accurate BGP next-hop address, we use the IPv4 BGP Nexthop Address (IE 18) field in the IPv4 and MPLS-IPv4 templates and the IPv6 BGP Nexthop Address (IE 63) field in the IPv6 and MPLS-IPv6 templates, for both the IPFIX and the version 9 formats. For IPv6 and MPLS-IPv6 flows, you also need to configure the ipv6-extended-attrib statement at the [edit chassis fpc slot-number inline-services flow-table-size] hierarchy level. When this feature is enabled, the fragmentIdentification (IE 54) field reports a value of 0.

Existing flows must be manually cleared using the clear services accounting flow inline-jflow fpc-slot slot-number command when this feature is enabled or disabled, because common memory is used both for the fragmentIdentification (IE 54) field and for this feature. Otherwise, the export thread may wrongly misunderstand the fragment identifier of an existing flow as a next-hop address when enabled, or wrongly misunderstand the next-hop address of an existing flow as a fragment identifier when disabled. To avoid this situation, existing flows must be cleared from all FPC slots on which inline active flow monitoring is enabled.