Hi Paolo,
Unfortunately there's no change when using 'nfacctd_as: bgp' and
'nfacctd_net: flow' combo. I still end up with the the same next hop
regardless of the path the flow takes which makes the as-path for the
multipathed destinations invalid since bgp lookup is always done with
the same next hop address. From what I can see in pkt_handlers.c
pbgp->peer_dst_ip.address.ipv4 is always set to NF9_BGP_IPV4_NEXT_HOP
(if set in the flow export) and in my case it's always set to the first
nexthop entry in the forwarding table for the destination that have
multiple paths. I ended up writing a small patch that adds a new config
directive "force_ip_next_hop" and if set and NF9_IPV4_NEXT_HOP is there
it will use it instead of NF9_BGP_IPV4_NEXT_HOP. In my use case this
works fine since all bgp peers are on /31 or /30 ptp links and their ip
is always equal to the ip of the other side of the ptp link.
Andrej
On 21.5.2021. 21:18, Paolo Lucente wrote:
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