Hi Andrej,
It is possible that you may find joy with the following combo
'nfacctd_as: bgp' and 'nfacctd_net: flow'. The next-hop for something
not intuitive (but that i can explain and is documented) is tied to
'nfacctd_net'. Can you give it a try? If positive, we can take it from
there, keep me posted.
Paolo
On 20/5/21 09:20, Andrej Brkic wrote:
Hi,
I have quite a few Juniper boxes doing inline jflow and exporting flows
to nfacctd.
All was working fine until we had to upgrade junos on those which broke
nexthop-learning
for ipfix. What happens now is that for all destinations that are
multipathed the
bgp_ipv4_next_hop will be set to the value of the first nexthop entry in
the forwarding
table for the prefix which has multiple paths. Naturally this breaks the
as_path lookup
(we're using BGP + add_paths to correctly resolve as path using
bgp_next_hop). JTAC is
of no help here since they claim this was never supported on these
platforms and the
fact it worked on the old junos versions is pure luck.
I tried setting "use_ip_next_hop" to true but it had no effect. Is it
even possible to
use it in a combo with nfacctd_as: bgp and have internal bgpd ignore
bgp_next_hop in
the flow and use the ip_next_hop to correctly resolve as path for
multipathed
prefixes ? Quick look at pkt_handlers.c shows that if bgp_ip_next_hop is
set in the
flow export peer_ds_ip.address.ipv4 will never be set to ip_next_hop
regardless of
use_ip_next_hop being set to true.
Thanks,
Andrej
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
