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

Reply via email to