Repository navigation
bgp_agent_map - map multiple bgp_id to 0.0.0.0/0 (all sflow agent IDs). Is this supported? #551
Description
Activity
Related I see this verbiage in the docs which makes me think a primary/backup setup is possible (at least for pmacctd/uacctd), but I may be wrong (or this is not applicable fo sfacctd):
pmacctd and uacctd daemons are required to use this map with at most two "catch-all" entries working in a primary/backup fashion (see for more info bgp_agent.map.example in the examples section): this is because these daemons do not have a NetFlow/sFlow source address to match to.In so few words a primary/backup bgp rib to sflow agent mapping is what I am looking to achieve here.
Dear Jeremiah ( @floatingstatic ),
Thanks for asking this. Effectively the way this is supported today, like you said, is with the help of something that would remove the map entry if the BGP session is down - or would push it down so that another entry would take priority. The verbiage leads to think that things are more auto-magical than that, instead.
Despite the status quo, i see how this feature would be useful - at least for the 0.0.0.0/0 (catch-all) use-case. I propose to keep this on the radar, leave this issue open and mark it as an enhancement.
Paolo
Thanks @paololucente . I was thinking a little deeper about our use case the other day and I think another solution (again for my use case) would be to have a feature flag where we could enable a global rib that all bgp peer routes are added to instead of keeping a rib per peer. A quick look at the source code makes me think this is not a trivial change however. I appreciate the response. I will look into managing this externally for now.
Indeed, @floatingstatic , i see how that could work. Unfortunately i confirm your assessment, it is by far not a quick win.
Description
Currently I have a bgp_agent_map that looks something like this:
The
bgp_ipaddresses are route collectors / servers that have all possible routes I expect to see in my flow data. I want to map this to any sflow agent from which we receive flow data. In normal operation bgp rib enrichment works just fine, the rib from192.0.2.1is used to map flows to prefixes. However if the bgp session for192.0.2.1is down we no longer have prefix information for sflow populating in aggregated flows (kafka), even though the bgp session for192.0.2.2is up and is a valid source for that data. It seems the bgp_agent_map operates on a first-match basis and sticks with that match as long as the bgp_agent_map is not reloaded.Short of some external script that monitors logs and re-orders/hot-reloads (SIGUSR2) the bgp agent map, is there a supported way of providing a failover mechanism for bgp rib enrichment to sflow agents?
Version
Appreciation
Please consider starring this project to boost our reach on github!
DONE!