When tunneling IPv6 traffic over an MPLS IPv4 network (6PE), if IPv6 ingress sampling is enabled on the CE-facing interface, NextHop might not be reported in the inline Jflow data records.
As detailed in this article, enabling nexthop-learning with ipv4-template will resolve this issue.
nexthop-learning
ipv4-template
Test Topology
JFLOW collector | | 10.1.1.4/30 10.1.1.8/30 | .5 .6 .9 .10 CE1----------------PE1----------------PE2-----------------PE3----------------CE2 <---- eBGP ----> <---- iBGP ----> <---- eBGP ----> <-------------- iBGP -------------->
CE1 lo0=1:1:1::1/128 PE1 lo0=1:1:1::2/128, 1.1.1.2/32 PE2 lo0=1:1:1::3/128, 1.1.1.3/32 PE3 lo0=1:1:1::4/128, 1.1.1.4/32 CE2 lo0=1:1:1::5/128
CE1 lo0=1:1:1::1/128
PE1 lo0=1:1:1::2/128, 1.1.1.2/32
PE2 lo0=1:1:1::3/128, 1.1.1.3/32
PE3 lo0=1:1:1::4/128, 1.1.1.4/32
CE2 lo0=1:1:1::5/128
The 6PE configuration is up between PE1 -- PE2 and PE1 -- PE3.
Enable ingress sampling on the PE1 (CE1 facing) interface.
Send traffic from CE1 to PE2.
The Jflow data records are exported to the JFLOW collector on active timeout, but the NextHop value is not reported properly in the exported data records.
User@CE1> ping 1:1:1::3 source 1:1:1::1 logical-system CE1 rapid count 99999999 PING6(56=40+8+8 bytes) 1:1:1::1 --> 1:1:1::3 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The NextHop field is null when nexthop-learning is not configured.
##### nexthop-learning is not configured on both IPv4 and IPv6 templates #####
User@PE1-re0> show configuration services flow-monitoring { version9 { template MONITOR_IPv4 { flow-active-timeout 10; flow-inactive-timeout 15; template-refresh-rate { seconds 180; } option-refresh-rate { seconds 180; } ipv4-template; } template MONITOR_IPv6 { flow-active-timeout 10; flow-inactive-timeout 15; template-refresh-rate { seconds 180; } option-refresh-rate { seconds 180; } ipv6-template; } } } User@flow_collector> monitor traffic interface xe-0/0/3 size 8000 write-file jflow_nhl_dis.cap Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on xe-0/0/3, capture size 8000 bytes ^C === jflow_nhl_dis.cap === No. Time Source Destination Protocol Length Info 1 0.000000 98.0.0.1 98.0.0.2 CFLOW 211 total: 1 (v9) record Obs-Domain-ID=589824 [Data:321] Frame 1: 211 bytes on wire (1688 bits), 211 bytes captured (1688 bits) Juniper Ethernet Internet Protocol Version 4, Src: 98.0.0.1, Dst: 98.0.0.2 User Datagram Protocol, Src Port: 50102, Dst Port: 60027 Cisco NetFlow/IPFIX Version: 9 Count: 1 SysUptime: 362.000000000 seconds Timestamp: Mar 30, 2021 18:12:56.000000000 Tokyo Standard Time FlowSequence: 6 SourceId: 589824 FlowSet 1 [id=321] (1 flows) FlowSet Id: (Data) (321) FlowSet Length: 137 [Template Frame: 39 (received after this frame)] Flow 1 SrcAddr: 1:1:1::1 DstAddr: 1:1:1::3 IP ToS: 0x00 Protocol: ICMPv6 (58) SrcPort: 0 DstPort: 0 IPv6 ICMP Type: 128 IPv6 ICMP Code: 0 InputInt: 518 Vlan Id: 0 SrcMask: 128 DstMask: 128 SrcAS: 1 DstAS: 2 NextHop: :: <--------------------------- address null BGPNextHop: ::ffff:1.1.1.3 TCP Flags: 0x00 OutputInt: 0 MinTTL: 64 MaxTTL: 64 Flow End Reason: Active timeout (2) Direction: Unknown (255) Dot1q Vlan Id: 0 Dot1q Customer Vlan Id: 0 fragIdent: 0 IPv6 Extension Headers: 0x00000000 Octets: 112 Packets: 2 [Duration: 22.272000000 seconds (switched)]
Starting in Junos OS Release 16.1, you can enable learning of next-hop addresses to correctly report the next-hop address, output SNMP, destination IP address, and destination IP mask values in flow records when a destination is reachable through multiple paths.
By default, however, this behavior of learning the next-hop addresses is disabled for inline active flow monitoring.
NextHop is reported properly after enabling nexthop-learning with ipv4-template .
The correct NextHop field is added when nexthop-learning is configured with ipv4-template .
##### nexthop-learning is enabled on IPv4 templates #####
User@PE1-re0> show configuration services flow-monitoring { version9 { template MONITOR_IPv4 { flow-active-timeout 10; flow-inactive-timeout 15; nexthop-learning { enable; <-------------------- enabled } template-refresh-rate { seconds 180; } option-refresh-rate { seconds 180; } ipv4-template; } template MONITOR_IPv6 { flow-active-timeout 10; flow-inactive-timeout 15; template-refresh-rate { seconds 180; } option-refresh-rate { seconds 180; } ipv6-template; } } } User@flow_collector> monitor traffic interface xe-0/0/3 size 8000 write-file jflow_nhl_ipv4_ena.cap Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on xe-0/0/3, capture size 8000 bytes ^C === jflow_nhl_ipv4_ena.cap === No. Time Source Destination Protocol Length Info 1 0.000000 98.0.0.1 98.0.0.2 CFLOW 211 total: 1 (v9) record Obs-Domain-ID=589824 [Data:321] Frame 1: 211 bytes on wire (1688 bits), 211 bytes captured (1688 bits) Juniper Ethernet Internet Protocol Version 4, Src: 98.0.0.1, Dst: 98.0.0.2 User Datagram Protocol, Src Port: 50102, Dst Port: 60027 Cisco NetFlow/IPFIX Version: 9 Count: 1 SysUptime: 1805914.000000000 seconds Timestamp: Apr 20, 2021 22:34:02.000000000 Tokyo Standard Time FlowSequence: 203 SourceId: 589824 FlowSet 1 [id=321] (1 flows) FlowSet Id: (Data) (321) FlowSet Length: 137 [Template Frame: 26 (received after this frame)] Flow 1 SrcAddr: 1:1:1::1 DstAddr: 1:1:1::3 IP ToS: 0x00 Protocol: ICMPv6 (58) SrcPort: 0 DstPort: 0 IPv6 ICMP Type: 128 IPv6 ICMP Code: 0 InputInt: 518 Vlan Id: 0 SrcMask: 128 DstMask: 128 SrcAS: 1 DstAS: 2 NextHop: ::ffff:10.1.1.6 <-------------------- ok BGPNextHop: ::ffff:1.1.1.3 TCP Flags: 0x00 OutputInt: 529 MinTTL: 64 MaxTTL: 64 Flow End Reason: Active timeout (2) Direction: Unknown (255) Dot1q Vlan Id: 0 Dot1q Customer Vlan Id: 0 fragIdent: 0 IPv6 Extension Headers: 0x00000000 Octets: 56 Packets: 1 [Duration: 13.056000000 seconds (switched)]
23-12-2024: added PR1840626 analysis as internal note